tokkee.org

t9200: Re-code non-ascii path test in UTF-8

For the purpose of this test we do not really care if the paths
are in latin-1, but people on Cygwin seem to be having problem
on foreign-looking pathnames that do not play well with their
locale.

Let's try to re-code them in UTF-8 and see who screams,
thanks, or reports no-improvements.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Update git-cat-file documentation

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation: "git-checkout <tree> <path>" takes any tree-ish

Especially, it is not limited to branch.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Improved error message from git-rebase

If the index wasn't clean, git-rebase would simply show the output from
git-diff-index with no further comment to the user.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix git-update-index to work with relative pathnames.

In particular, it fixes the following (typical for cygwin) problem:

    $ git-update-index --chmod=-x ../wrapper/Jamfile
    fatal: git-update-index: cannot chmod -x '../wrapper/Jamfile'

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Escape --upload-pack from expr.

Recent commit ae1dffcb28ee89a23f8d2747be65e17c8eab1690 by Junio
changed the way --upload-pack was passed around between clone,
fetch and ls-remote and modified the handling of the command
line parameter parsing.

Unfortunately FreeBSD 6.1 insists that the expression

  expr --upload-pack=git-upload-pack : '-[^=]*=\(.*\)'

is illegal, as the --upload-pack option is not supported by their
implementation of expr.

Elsewhere in Git we use z as a leading prefix of both arguments,
ensuring the -- isn't seen by expr.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Don't coredump on bad refs in update-server-info.

Apparently if we are unable to parse an object update-server-info
coredumps, as it doesn't bother to check the return value of its
call to parse_object.

Instead of coredumping, skip the ref.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

tone down the detached head warning

This is not meant to frighten people or even to suggest they might be
doing something wrong, but rather to notify them of a state change and
provide a likely option in the case this state was entered by mistake.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix git-tag -u

... which I broke when we introduced user.signingkey configuration.
There was no reason to add a new variable keyid to the script.

Signed-off-by: Junio C Hamano <junkio@cox.net>

user-manual: todo's

Update todo's.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

user-manual: point to README for gitweb information

I'd like complete gitweb setup instructions some day, but for now just
refer to the gitweb README.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

Merge branch 'master' into sp/gfi

git-fast-import requires use of inttypes.h, but the master branch has
added it to git-compat-util differently than git-fast-import originally
had used it.  This merge back of master to the fast-import topic is to
get (and use) inttypes.h the way master is using it.

This is a partially evil merge to remove the call to setup_ident(),
as the master branch now contains a change which makes this implicit
and therefore removed the function declaration. (commit 01754769).

Conflicts:

git-compat-util.h

blameview: Use git-cat-file to read the file content.

Fix blameview to use git-cat-file to read the file content.
This make sure we show the right content when we have modified
file in the working directory which is not committed.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-fetch: Allow fetching the remote HEAD

... with:

$ git fetch ${remote} HEAD

Also

$ git fetch ${remote} :${localref}

worked, but

$ git fetch ${remote} HEAD:{localref}

didn't. Now both are equivalent.

Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-send-email: remove debugging output.

rfc2047 unquoter spitted out an annoying "- unquoted" which was
added during debugging but I forgot to remove.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Add a missing fork() error check.

Signed-off-by: Junio C Hamano <junkio@cox.net>

git-blame: somewhat better commenting.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Make fsck and fsck-objects be builtins.

The earlier change df391b192 to rename fsck-objects to fsck broke
fsck-objects.  This should fix it again.

Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-gui: Assign background colors to each blame hunk.

To help the user visually see which lines are associated with each other
in the file we attempt to sign a unique background color to each commit
and then render all text associated with that commit using that color.

This works out OK for a file which has very few commits in it; but
most files don't have that property.

What we really need to do is look at what colors are used by our
neighboring commits (if known yet) and pick a color which does not
conflict with our neighbor.  If we have run out of colors then we
should force our neighbor to recolor too.  Yes, its the graph coloring
problem.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Use a grid layout for the blame viewer.

Using a panedwindow to display the blame viewer's individual columns
just doesn't make sense.  Most of the important data fits within the
columns we have allocated, and those that don't the leading part fits
and that's good enough.  There are just too many columns within this
viewer to let the user sanely control individual column widths.  This
change shouldn't really be an issue for most git-gui users as their
displays should be large enough to accept this massive dump of data.

We now also have a properly working horizontal scrollbar for the
current file data area.  This makes it easier to get away with a
narrow window when screen space is limited, as you can still scroll
around within the file content.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Install column headers in blame viewer.

I started to get confused about what each column meant in the blame
viewer, and I'm the guy who wrote the code!  So now git-gui hints to
the user about what each column is by drawing headers at the top.
Unfortunately this meant I had to use those dreaded frame objects
which seem to cause so much pain on Windows.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Display original filename and line number in blame.

When we annotate a file and show its line data, we're already asking
for copy and movement detection (-M -C).  This costs extra time, but
gives extra data.  Since we are asking for the extra data we really
should show it to the user.

Now the blame UI has two additional columns, one for the original
filename (in the case of a move/copy between files) and one for the
original line number of the current line of code.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-commit -s: no extra space when sign-offs appear at the end already.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Replace perl code with pure shell code

Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

lock_any_ref_for_update(): do not accept malformatted refs.

We used to use lock_any_ref_for_update() because the command
needs to also update HEAD (which is not under refs/, so
lock_ref_sha1() cannot be used).  The function however did not
check for refs with illegal characters in them.

Use check_ref_format() to catch malformed refs.  For this check,
we specifically do not want to say having less than two levels
in the name is illegal to allow HEAD (and perhaps other special
refs in the future).

Signed-off-by: Junio C Hamano <junkio@cox.net>

git-gui: Correctly handle spaces in filepaths.

Anytime are about to open a pipe on what may be user data we need to
make sure the value is escaped correctly into a Tcl list, so that the
executed subprocess will receive the right arguments.  For the most
part we were already doing this correctly, but a handful of locations
did not.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Use -M and -C when running blame.

Since we run blame incrementally in the background we might as well get
as much data as we can from the file.  Adding -M and -C definately makes
it take longer to compute the revision annotations, but since they are
streamed in and updated as they are discovered we'll get recent data
almost immediately anyway.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Allow users to edit user.name, user.email from options.

Users may need to be able to alter their user.name or user.email
configuration settings.  If they are mostly a git-gui user they
should be able to view/set these important values from within
the git-gui environment, rather than needing to edit a raw text
file on their local filesystem.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Display the current branch name in browsers.

Rather than using HEAD for the current branch, use the actual name of
the current branch in the browser.  This way the user knows what a
browser is browsing if they open up different browsers while on different
branches.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Improve the icons used in the browser display.

Real icons which seem to indicate going up to the parent (an up arrow)
and a subdirectory (an open folder).  Files are now drawn with the
file_mod icon, like a modified file is.  This just looks better as it
is more consistent with the rest of our UI.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Two small typofixes.

Signed-off-by: Junio C Hamano <junkio@cox.net>

user-manual: SHA1 -> object name

Prefer "object name" to SHA1, at least in higher level documentation.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

user-manual: document git-show-branch example

Document Junio's show-branch trick for finding out which tags are
descendents of a given comit.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

user-manual: minor "TODO" updates

I still really want a section on interoperability with CVS, subversion,
etc., but I'm not getting around to it very fast, so just add this to
the TODO section for now.  And a few other minor todo updates.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

user-manual: rewrap a few long lines

Rewrap some long lines.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

user-manual: reflogs, other recovery

Add a brief discussion of reflogs.  Also recovery of dangling commits
seems to fit in here, so move some of the discussion out of Linus's
email to here.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

git-gui: Implemented file browser and incremental blame.

This rather huge change provides a browser for the current branch.  The
browser simply shows the contents of tree HEAD, and lets the user drill
down through the tree.  The icons used really stink, as I just copied in
icon which we already had.  I really need to replace the file_dir and
file_uplevel icons with something more useful.

If the user double clicks on a file within the browser we open it in
a blame viewer.  This makes use of the new incremental blame feature
that Linus just added yesterday to core Git.  Fortunately the feature
will be in 1.5.0 final so we can rely on having it available here.

Since the blame engine is incremental the user will get blame data
for groups which can be determined early.  Git will slowly fill in
the remaining lines as it goes.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Test for Cygwin differently than from Windows.

Running on Cygwin is different than if we were running through MinGW.

In the Cygwin case we have cygpath available to us, we need to perform
UNIX<->Windows path translation sometimes, and we need to perform odd
things like spawning our own login shells to perform network operations.
But in the MinGW case these don't occur.  Git knows native Windows file
paths, and login shells may not even exist.

Now git-gui will avoid running cygpath unless it knows its on Cygwin.
It also uses a different shortcut type when Cygwin is not present, and
it avoids invoking /bin/sh to execute hooks if Cygwin is not present.
This latter part probably needs more testing in the MinGW case.

This change also improves how we start gitk.  If the user is on any type
of Windows system its known that gitk won't start right if ~/.gitk exists.
So we delete it before starting if we are running on any type of Windows
operating system.  We always use the same wish executable which launched
git-gui to start gitk; this way on Windows we don't have to jump back to
/bin/sh just to go into the first wish found in the user's PATH.  This
should help on MinGW when we probably don't want to spawn a shell just
to start gitk.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Offer quick access to the HTML formatted documentation.

Users may want to be able to read Git documentation, even if they
are not command line users.  There are many important concepts and
terms covered within the standard Git documentation which would be
useful to even non command line using people.

We now try to offer an 'Online Documentation' menu option within the
Help menu.  First we try to guess to see what browser the user has
setup.  We default to instaweb.browser, if set, as this is probably
accurate for the user's configuration.  If not then we try to guess
based on the operating system and the available browsers for each.
We prefer documentation which is installed parallel to Git's own
executables, e.g. `git --exec-path`/../Documentation/index.html, as
that is how I typically install the HTML docs.  If those are not found
then we open the documentation published on kernel.org.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

user-manual: fix a header level

Oops.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

user-manual: typo fix

Oops

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

user-manual: add references to git-config man page

Direct editing of config files may be more natural for users than using
the git-config commandline; but we should still reference the
git-config man page when we describe such editing, so people know where
to go for details on the config file syntax and meanings of the
variables.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

user-manual: repo-config -> config

Looks like we're going to allow git-config as the preferred alias to
git-repo-config, so let's document that instead.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

user-manual: fsck-objects -> fsck

There seems to be an agreement to rename fsck-objects to fsck.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

user-manual: git-fsck, dangling objects

Initial import of fsck and dangling objects discussion, mostly lifted from
an email from Linus.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

git-fsck-objects is now synonym to git-fsck

Signed-off-by: Junio C Hamano <junkio@cox.net>

[PATCH] Rename git-repo-config to git-config.

Signed-off-by: Tom Prince <tom.prince@ualberta.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Heavily expanded update hook to send more useful emails than the old hook

I know it's only an example, but having this might save someone else the
trouble of writing an enhanced version for themselves.

It basically does the same job as the old update hook, but with these
differences:
 * The recipients list is read from the repository config file from
   hooks.mailinglist
 * Updating unannotated tags can be allowed by setting
   hooks.allowunannotated
 * Announcement emails (via annotated tag creation) can be sent to a
   different mailing list by setting hooks.announcelist
 * Output email is more verbose and generates specific content depending
   on whether the ref is a tag, an annotated tag, a branch, or a
   tracking branch
 * The email is easier to filter; the subject line is prefixed with
   [SCM] and a project description pulled from the "description" file
 * It catches (and displays differently) branch updates that are
   performed with a --force

Obviously, it's nothing that clever - it's the update hook I use on my
repositories but I've tried to keep it general, and tried to make the
output always relevant to the type of update.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

UNIX reference time of 1970-01-01 00:00 is UTC timezone, not local time zone

I got bitten because in the UK (where one would expect 1970-01-01 00:00
to be UTC 0) some politicians decided to mess around with daylight
savings time from 1968 to 1971; it was permanently BST (+0100).  That
means that on my computer the following is true:

$ date --date="1970-01-01 00:00" +"%F %T %z (%Z)"
1970-01-01 00:00:00 +0100 (BST)

This of course means that the --date argument to date is specified in
local time, not UTC.  So when the hooks--update script does this:

date=$(date --date="1970-01-01 00:00:00 $ts seconds")

It's actually saying (in my timezone) "1970-01-01 01:00:00 UTC" + $ts.
Clearly this is wrong.  The UNIX epoch started at midnight UTC not 1am
UTC.

This leads to the tagged time in hooks--update being shown as one hour
earlier than the true tagged time (in my timezone).  The problem would
be worse for other timezones.  For a +1300 timezone on 1970-01-01, the
tagged time would be 13 hours earlier.  Oops.

The solution is to force the reference time to UTC, which is what this
patch does.  In my timezone:

$ date --date="1970-01-01 00:00 +0000" +"%F %T %z (%Z)"
1970-01-01 01:00:00 +0100 (BST)

Much better.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>

Teach for-each-ref about a little language called Tcl.

Love it or hate it, some people actually still program in Tcl.  Some
of those programs are meant for interfacing with Git.  Programs such as
gitk and git-gui.  It may be useful to have Tcl-safe output available
from for-each-ref, just like shell, Perl and Python already enjoy.

Thanks to Sergey Vlasov for pointing out the horrible flaws in the
first and second version of this patch, and steering me in the right
direction for Tcl value quoting.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Add a sample program 'blameview' to show how to use git-blame --incremental

Signed-off-by: Junio C Hamano <junkio@cox.net>

git-push through git protocol

This allows pushing over the git:// protocol, and while it's not
authenticated, it could make sense from within a firewalled
setup where nobody but trusted internal people can reach the git
port.  git-daemon is possibly easier and faster to set up in the
kind of situation where you set up git instead of CVS inside a
company.

"git-receive-pack" is disabled by default, so you need to enable it
explicitly by starting git-daemon with the "--enable=receive-pack"
command line argument, or by having your config enable it automatically.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Document 'git-blame --incremental'

Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation/config.txt: Fix documentation of colour config tweaks.

  * The description of valid colour specifications was rather
    incomplete, so fix it so that it actually describes colour specs as
    accepted by color_parse().

  * The list of colour items allowed in color.diff.BLAH was missing the
    `commit' and `whitespace' entries.

Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>

wt-status: Actually accept `color.status.BLAH' configuration variables.

A stupid typo stopped this from working.

Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-blame --incremental: don't use pager

Starting a pager defeats the purpose of the incremental output
mode.  This changes git-blame to only paginate if --incremental
was not given.

git -p blame --incremental still starts the pager, though.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>

add reflog when moving HEAD to a new branch

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

create_symref(): do not assume pathname from git_path() persists long enough

Being lazy to rely on the cycling N buffers mkpath() and friends
return is nice in general, but it makes it too easy to introduce
new bugs that are "mysterious".

Introduction of read_ref() in create_symref() after calling
git_path() to get the git_HEAD value (i.e. the path to create a
new symref at) consumed more than the available buffers and
broke a later call to mkpath() that derives lockpath from it.

Signed-off-by: Junio C Hamano <junkio@cox.net>

add logref support to git-symbolic-ref

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

move create_symref() past log_ref_write()

This doesn't change the code at all.  It is done to make the next patch
more obvious.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

add reflog entries for HEAD when detached

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

enable separate reflog for HEAD

If HEAD is tied to a branch then both logs/HEAD and logs/heads/<branch> are
updated.  This is also true for any symbolic refs in general, but only HEAD
will see its reflog created automatically.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

lock_ref_sha1_basic(): remember the original name of a ref when resolving it

A ref might be pointing to another ref but only the name of the last ref
is remembered.  Let's remember about the first name as well.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

make reflog filename independent from struct ref_lock

This allows for ref_log_write() to be used in a more flexible way,
and is needed for future changes.

This is only code reorg with no behavior change.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Compute accurate distances in git-describe before output.

My prior change to git-describe attempts to print the distance
between the input commit and the best matching tag, but this distance
was usually only an estimate as we always aborted revision walking
as soon as we overflowed the configured limit on the number of
possible tags (as set by --candidates).

Displaying an estimated distance is not very useful and can just be
downright confusing.  Most users (heck, most Git developers) don't
immediately understand why this distance differs from the output
of common tools such as `git rev-list | wc -l`.  Even worse, the
estimated distance could change in the future (including decreasing
despite no rebase occuring) if we find more possible tags earlier
on during traversal.  (This could happen if more tags are merged
into the branch between queries.)  These factors basically make an
estimated distance useless.

Fortunately we are usually most of the way through an accurate
distance computation by the time we abort (due to reaching the
current --candidates limit).  This means we can simply finish
counting out the revisions still in our commit queue to present
the accurate distance at the end.  The number of commits remaining
in the commit queue is probably less than the number of commits
already traversed, so finishing out the count is not likely to take
very long.  This final distance will then always match the output of
`git rev-list | wc -l`.

We can easily reduce the total number of commits that need to be
walked at the end by stopping as soon as all of the commits in the
commit queue are flagged as being merged into the already selected
best possible tag.  If that's true then there are no remaining
unseen commits which can contribute to our best possible tag's
depth counter, so further traversal is useless.

Basic testing on my Mac OS X system shows there is no noticable
performance difference between this accurate distance counting
version of git-describe and the prior version of git-describe,
at least when run on git.git.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Update describe documentation.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Teach git-describe to display distances from tags.

If you get two different describes at different
times from a non-rewinding branch and they both come up with the same
tag name, you can tell which is the 'newer' one by distance.  This is
rather common in practice, so its incredibly useful.

[jc: still needs documentation and fixups when traversal gives up
 early.]

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-blame --porcelain: quote filename in c-style when needed.

Otherwise a pathname that has funny characters such as LF would
screw up the parsing programs of the output.

Strictly speaking, this is not backward compatible, but the
current output for pathnames that have embedded LF and such
cannot be sanely parsed anyway, and pathnames that only use
characters from the portable pathname character set won't be
affected.

Signed-off-by: Junio C Hamano <junkio@cox.net>

git-blame --incremental

This adds --incremental option to help GUI porcelains to show
the result from git-blame incrementally.  The output gives the
origin information in the same format as the porcelain format.
The first line has commit object name, the line number of the
first line in the group in the original file, the line number of
that file in the final image, and number of lines in the group.
Then subsequent lines show the metainformation for the commit
when the commit is shown for the first time, except the filename
information is always shown (we cannot even make it conditional
to -C option as blame always follows the renaming of the file
wholesale).

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Don't force everybody to call setup_ident().

Back when only handful commands that created commit and tag were
the only users of committer identity information, it made sense
to explicitly call setup_ident() to pre-fill the default value
from the gecos information.  But it is much simpler for programs
to make the call automatic when get_ident() is called these days,
since many more programs want to use the information when updating
the reflog.

Signed-off-by: Junio C Hamano <junkio@cox.net>

git-log -g --pretty=oneline should display the reflog message

In the context of reflog output the reflog message is more useful than
the commit message's first line.  When relevant the reflog message
will contain that line anyway.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Document --check option to git diff.

Signed-off-by: Bill Lear <rael@zopyra.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Allow the tag signing key to be specified in the config file

I did this:

  $ git tag -s test-sign
  gpg: skipped "Andy Parkins <andyparkins@gmail.com>": secret key not available
  gpg: signing failed: secret key not available
  failed to sign the tag with GPG.

The problem is that I have used the comment field in my key's UID
definition.

  $ gpg --list-keys andy
  pub   1024D/4F712F6D 2003-08-14
  uid                  Andy Parkins (Google) <andyparkins@gmail.com>

So when git-tag looks for "Andy Parkins <andyparkins@gmail.com>";
obviously it's not going to be found.

There shouldn't be a requirement that I use the same form of my name in
my git repository and my gpg key - I might want to be formal (Andrew) in
my gpg key and informal (Andy) in the repository.  Further I might have
multiple keys in my keyring, and might want to use one that doesn't
match up with the address I use in commit messages.

This patch adds a configuration entry "user.signingkey" which, if
present, will be passed to the "-u" switch for gpg, allowing the tag
signing key to be overridden.  If the entry is not present, the fallback
is the original method, which means existing behaviour will continue
untouched.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-gui: Reword meaning of merge.summary.

OK, its official, I'm not reading documentation as well as I should be.
Core Git's merge.summary configuration option is used to control the
generation of the text appearing within the merge commit itself.  It
is not (and never has been) used to default the --no-summary command
line option, which disables the diffstat at the end of the merge.

I completely blame Git for naming two unrelated options almost the
exact same thing.  But its my own fault for allowing git-gui to
confuse the two.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

If abbrev is set to zero in git-describe, don't add the unique suffix

When on a non-tag commit, git-describe normally outputs descriptions of
the form
  v1.0.0-g1234567890
Some scripts (for example the update hook script) might just want to
know the name of the nearest tag, so they then have to do
 x=$(git-describe HEAD | sed 's/-g*//')
This is costly, but more importantly is fragile as it is relying on the
output format of git-describe, which we would then have to maintain
forever.

This patch adds support for setting the --abbrev option to zero.  In
that case git-describe does as it always has, but outputs only the
nearest found tag instead of a completely unique name.  This means that
scripts would not have to parse the output format and won't need
changing if the git-describe suffix is ever changed.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

fix suggested branch creation command when detaching head

Doing:

$ git checkout HEAD^

Generates the following message:

|warning: you are not on ANY branch anymore.
|If you meant to create a new branch from the commit, you need -b to
|associate a new branch with the wanted checkout.  Example:
|  git checkout -b <new_branch_name> HEAD^

Of course if the user does as told at this point the created branch
won't be located at the expected commit.  Reword this message a bit to
avoid such confusion.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

user-manual: reorganize fetch discussion, add internals, etc.

Keep git remote discussion in the first chapter, but postpone
lower-level git fetch usage (to fetch individual branches) till later.

Import a bunch of slightly modified text from the readme to give an
architectural overview at the end.

Add more discussion of history rewriting.

And a bunch of other miscellaneous changes....

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

write_in_full: size_t is unsigned.

It received the return value from xwrite() in a size_t variable
'written' and expected comparison with 0 would catch an error
from xwrite().

Signed-off-by: Junio C Hamano <junkio@cox.net>

create_symref: check error return from open().

Signed-off-by: Junio C Hamano <junkio@cox.net>

vc-git.el: Take into account the destination name in vc-checkout.

This is necessary for vc-version-other-window. Based on a patch by Sam
Vilain <sam.vilain@catalyst.net.nz>.

Currently, the vc-git-checkout function uses `git checkout' to fetch a
file from the git repository to the working copy.  However, it is
completely ignoring the input argument that specifies the destination
file.  `git-checkout' does not support specifying this, so we have to
use `git-cat-file', capture the output in a buffer and then save it.

Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-merge: leave sensible reflog message when used as the first level UI.

It used to throw potentially multi-line log message at reflog.
Just record the heads that were given to be merged at the command
line and the action.

Revert the removal of the check in "git-update-ref -m" I made earlier
which was only a work-around for this.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Make sure we do not write bogus reflog entries.

The file format dictates that entries are LF terminated so
the message cannot have one in it.  Chomp the message to make
sure it only has a single line if necessary, while removing the
leading whitespace.

Signed-off-by: Junio C Hamano <junkio@cox.net>

git-gui: Support merge.summary, merge.verbosity.

Changed our private merge summary config option to be the same as the
merge.summary option supported by core Git.  This means setting the
"Show Merge Summary" flag in git-gui will have the same effect on
the command line.

In the same vein I've also added merge.verbosity to the gui options,
allowing the user to adjust the verbosity level of the recursive
merge strategy.  I happen to like level 1 and suggest that other users
use that, but level 2 is the core Git default right now so we'll use
the same default in git-gui.

Unfortunately it appears as though core Git has broken support for
the merge.summary option, even though its still in the documentation
For the time being we should pass along --no-summary to git-merge if
merge.summary is false.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Always offer scrollbars for branch lists.

Anytime we use a listbox to show branch names its possible for the
listbox to exceed 10 entries (actually its probably very common).
So we should always offer a scrollbar for the Y axis on these
listboxes.  I just forgot to add it when I defined them.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Don't allow merges in the middle of other things.

If the user is in the middle of a commit they have files which are
modified.  These may conflict with any merge that they may want
to perform, which would cause problems if the user wants to abort
a bad merge as we wouldn't have a checkpoint to roll back onto.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Don't allow users to commit a bad octopus merge.

If an octopus merge goes horribly wrong git-merge will leave the
working directory and index dirty, but will not leave behind a
MERGE_HEAD file for a later commit.  Consequently we won't know
its a merge commit and instead would let the user resolve the
conflicts and commit a single-parent commit, which is wrong.

So now if an octopus merge fails we notify the user that the
merge did not work, tell them we will reset the working directory,
and suggest that they merge one branch at a time.  This prevents
the user from committing a bad octopus merge.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Update status bar during a merge.

I got slightly confused when I did two merges in a row, as the status
bar said "merge completed successfully" while the second merge was
still running.  Now we show what branches are actively being merged.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Let users abort with `reset --hard` type logic.

If you get into the middle of a merge that turns out to be horrible
and just not something you want to do right now, odds are you need
to run `git reset --hard` to recover your working directory to a
pre-merge state.

We now offer Merge->Abort Merge for exactly this purpose, however
its also useful to thow away a non-merge, as its basically the same
logic as `git reset --hard`.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Implement local merge operations.

To allow users to merge local heads and tracking branches we now offer
a dialog which lets the user select 1-15 branches and merge them using
the stock `git merge` Grand Unified Merge Driver.

Originally I had wanted to implement this merge internally within git-gui
as I consider GUMD to be mostly Porcelain-ish, but the truth is it does
its job exceedingly well and its a relatively complex chunk of code.
I'll probably circle back later and try to remove the invocation of GUMD
from git-gui, but right now it lets me get the job done faster.

Users cannot start a merge if they are currently in the middle of one,
or if they are amending a commit.  Trying to do either is just stupid
and should be stopped as early as possible.

I've also made it simple for users to startup a gitk session prior to
a merge by offering a Visualize button which runs `gitk $revs --not HEAD`,
where $revs is the list of branches currently selected in the merge
dialog.  This makes it quite simple to find out what the damage will
be to the current branch if you were to carry out the currently proposed
merge.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Remove unnecessary found variable from describe.

Junio added the found variable to enforce commit date order when two
tags have the same distance from the requested commit.  Except it is
unnecessary as match_cnt is already used to record how many possible
tags have been identified thus far.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Use inttypes.h rather than stdint.h.

Older Solaris machines lack stdint.h but have inttypes.h.
The standard has inttypes.h including stdint.h, so at worst
this pollutes the namespace a bit.

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation: pack-refs --all vs default behaviour

Document the recommended way to prime a repository with tons of
references with 'pack-refs --all -prune'.

Signed-off-by: Junio C Hamano <junkio@cox.net>

git-gui: Use builtin version of 'git gc'.

Technically the new git-gc command is strictly Porcelain; its invoking
multiple plumbing commands to do its work.  Since git-gui tries to not
rely on Porclain we shouldn't be invoking git-gc directly, instead we
should perform its tasks on our own.

To make this easy I've created console_chain, which takes a list of
tasks to perform and runs them all in the same console window.  If
any individual task fails then the chain stops running and the window
shows a failure bar.  Only once all tasks have been completed will it
invoke console_done with a successful status.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

show-branch -g: default to HEAD

Signed-off-by: Junio C Hamano <junkio@cox.net>

git-gui: Refactor console success/failure handling.

Because I want to be able to run multiple output-producing commands
in a single 'console' window within git-gui I'm refactoring the
console handling routines to require the "after" argument of console_exec.
This should specify a procedure to execute which will receive two args,
the first is the console window handle and the second is the status of
the last command (0 on failure, 1 on success).

A new procedure console_done can be passed to the last console_exec
command to forward perform all cleanup and enable the Close button.
Its status argument is used to update the final status bar on the
bottom of the console window.

This isn't any real logic changing, and no new functionality is in
this patch.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Add dangling objects tips.

Signed-off-by: Junio C Hamano <junkio@cox.net>

parse-remote: do not barf on a remote shorthand without any refs to fetch.

Signed-off-by: Junio C Hamano <junkio@cox.net>

git-gui: Always use -v option to push.

Right now `git-push -v` is actually not that verbose; it merely adds
the URL it is pushing to.  This can be informative if you are pushing
to a configured remote, as you may not actually remember what URL that
remote is connected to.  That detail can be important if the push
fails and you attempt to communicate the errors to a 3rd party to help
you resolve the issue.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Remove no longer used pull from remote code.

Because we aren't going to support single click pulling of changes from
an existing remote anytime in the near future, I'm moving the code which
used to perform that action.  Hopefully we'll be able to do something
like it in the near-future, but also support local branches just as
easily.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Added arbitrary branch pushing support.

Because its common for some users to push topic branches to a remote
repository for review and merging by other parties, users need an
easy way to push one or more branches to a remote repository without
needing to edit their .git/config file anytime their set of active
branches changes.

We now provide a basic 'Push...' menu action in the Push menu which
opens a dialog allowing the user to select from their set of local
branches (refs/heads, minus tracking branches).  The user can designate
which repository to send the changes to by selecting from an already
configured remote or by entering any valid Git URL.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>