docs/checkout: clarify what "non-branch" means

In the code we literally stick "refs/heads/" on the front
and see if it resolves, so that is probably the best
explanation.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

doc/checkout: split checkout and branch creation in synopsis

These can really be thought of as two different modes, since
the "<branch>" parameter is treated differently in the two
(in one it is the branch to be checked out, but in the other
it is really a start-point for branch creation).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

doc/checkout: refer to git-branch(1) as appropriate

Most of description for the branch creation options is
simply cut and paste from git-branch. There are two reasons
to fix this:

  1. It can grow stale with respect to what's in "git
     branch" (which it is now is).

  2. It is not just an implementation detail, but rather the
     desired mental model for the command that we are using
     "git branch" here. Being explicit about that can help
     the user understand what is going on.

It also makes sense to strip the branch creation options
from the synopsis, as they are making it a long,
hard-to-read line. They are still easily discovered by
reading the options list, and --track is explicitly
referenced when branch creation is described.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

doc: refer to tracking configuration as "upstream"

The term "tracking" often creates confusion between remote
tracking branches and local branches which track a remote
branch. The term "upstream" captures more clearly the idea
of "branch A is based on branch B in some way", so it makes
sense to mention it.

At the same time, upstream branches are used for more
than just git-pull these days; let's mention that here.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

doc: clarify --no-track option

It is not really about ignoring the config option; it is
about turning off tracking, _even if_ the config option is
set.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

gitignore git-bisect--helper

Signed-off-by: Junio C Hamano <redacted>

git-am: teach git-am to apply a patch to an unborn branch

People sometimes wonder why they cannot apply a patch that only
creates new files to an unborn branch.

Signed-off-by: Nanako Shiraishi <redacted>
Signed-off-by: Junio C Hamano <redacted>

Mark t1301 permission test to depend on POSIXPERM

This prepares the topic for inclusion to master.

process_{tree,blob}: show objects without buffering

Here's a less trivial thing, and slightly more dubious one.

I was looking at that "struct object_array objects", and wondering why we
do that. I have honestly totally forgotten. Why not just call the "show()"
function as we encounter the objects? Rather than add the objects to the
object_array, and then at the very end going through the array and doing a
'show' on all, just do things more incrementally.

Now, there are possible downsides to this:

 - the "buffer using object_array" _can_ in theory result in at least
   better I-cache usage (two tight loops rather than one more spread out
   one). I don't think this is a real issue, but in theory..

 - this _does_ change the order of the objects printed. Instead of doing a
   "process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
   over the commits (which puts all the root trees _first_ in the object
   list, this patch just adds them to the list of pending objects, and
   then we'll traverse them in that order (and thus show each root tree
   object together with the objects we discover under it)

   I _think_ the new ordering actually makes more sense, but the object
   ordering is actually a subtle thing when it comes to packing
   efficiency, so any change in order is going to have implications for
   packing. Good or bad, I dunno.

 - There may be some reason why we did it that odd way with the object
   array, that I have simply forgotten.

Anyway, now that we don't buffer up the objects before showing them
that may actually result in lower memory usage during that whole
traverse_commit_list() phase.

This is seriously not very deeply tested. It makes sense to me, it seems
to pass all the tests, it looks ok, but...

Does anybody remember why we did that "object_array" thing? It used to be
an "object_list" a long long time ago, but got changed into the array due
to better memory usage patterns (those linked lists of obejcts are
horrible from a memory allocation standpoint). But I wonder why we didn't
do this back then. Maybe there's a reason for it.

Or maybe there _used_ to be a reason, and no longer is.

Signed-off-by: Junio C Hamano <redacted>

show_object(): push path_name() call further down

In particular, pushing the "path_name()" call _into_ the show() function
would seem to allow

 - more clarity into who "owns" the name (ie now when we free the name in
   the show_object callback, it's because we generated it ourselves by
   calling path_name())

 - not calling path_name() at all, either because we don't care about the
   name in the first place, or because we are actually happy walking the
   linked list of "struct name_path *" and the last component.

Now, I didn't do that latter optimization, because it would require some
more coding, but especially looking at "builtin-pack-objects.c", we really
don't even want the whole pathname, we really would be better off with the
list of path components.

Why? We use that name for two things:
 - add_preferred_base_object(), which actually _wants_ to traverse the
   path, and now does it by looking for '/' characters!
 - for 'name_hash()', which only cares about the last 16 characters of a
   name, so again, generating the full name seems to be just unnecessary
   work.

Anyway, so I didn't look any closer at those things, but it did convince
me that the "show_object()" calling convention was crazy, and we're
actually better off doing _less_ in list-objects.c, and giving people
access to the internal data structures so that they can decide whether
they want to generate a path-name or not.

This patch does that, and then for people who did use the name (even if
they might do something more clever in the future), it just does the
straightforward "name = path_name(path, component); .. free(name);" thing.

Signed-off-by: Linus Torvalds <redacted>
Signed-off-by: Junio C Hamano <redacted>

GIT 1.6.3-rc0

Signed-off-by: Junio C Hamano <redacted>

Documentation/git.txt: GIT 1.6.2.2 has been out for a while

These links inside "stalenotes" section need to be updated on the master
branch every time a new stable or maintenance release is made.

Signed-off-by: Nanako Shiraishi <redacted>
Signed-off-by: Junio C Hamano <redacted>

Merge branch 'jk/no-perl'

* jk/no-perl:
  tests: skip perl tests if NO_PERL is defined
  Makefile: allow building without perl

Merge branch 'sb/doc-upstream-branch'

* sb/doc-upstream-branch:
  Documentation: Introduce "upstream branch"

Merge branch 'jk/show-upstream'

* jk/show-upstream:
  branch: show upstream branch when double verbose
  make get_short_ref a public function
  for-each-ref: add "upstream" format field
  for-each-ref: refactor refname handling
  for-each-ref: refactor get_short_ref function

Merge branch 'fg/remote-prune'

* fg/remote-prune:
  add tests for remote groups
  git remote update: Fallback to remote if group does not exist
  remote: New function remote_is_configured()
  git remote update: Report error for non-existing groups
  git remote update: New option --prune
  builtin-remote.c: Split out prune_remote as a separate function.

Merge branch 'cc/sha1-bsearch'

* cc/sha1-bsearch:
  sha1-lookup: fix up the assertion message

Merge branch 'cc/bisect-filter'

* cc/bisect-filter: (21 commits)
  rev-list: add "int bisect_show_flags" in "struct rev_list_info"
  rev-list: remove last static vars used in "show_commit"
  list-objects: add "void *data" parameter to show functions
  bisect--helper: string output variables together with "&&"
  rev-list: pass "int flags" as last argument of "show_bisect_vars"
  t6030: test bisecting with paths
  bisect: use "bisect--helper" and remove "filter_skipped" function
  bisect: implement "read_bisect_paths" to read paths in "$GIT_DIR/BISECT_NAMES"
  bisect--helper: implement "git bisect--helper"
  bisect: use the new generic "sha1_pos" function to lookup sha1
  rev-list: call new "filter_skip" function
  patch-ids: use the new generic "sha1_pos" function to lookup sha1
  sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
  rev-list: pass "revs" to "show_bisect_vars"
  rev-list: make "show_bisect_vars" non static
  rev-list: move code to show bisect vars into its own function
  rev-list: move bisect related code into its own file
  rev-list: make "bisect_list" variable local to "cmd_rev_list"
  refs: add "for_each_ref_in" function to refactor "for_each_*_ref" functions
  quote: add "sq_dequote_to_argv" to put unwrapped args in an argv array
  ...

Merge branch 'maint'

* maint:
  GIT 1.6.2.3
  State the effect of filter-branch on graft explicitly
  process_{tree,blob}: Remove useless xstrdup calls

Conflicts:
GIT-VERSION-GEN

GIT 1.6.2.3

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'maint-1.6.1' into maint

* maint-1.6.1:
  State the effect of filter-branch on graft explicitly
  process_{tree,blob}: Remove useless xstrdup calls

Merge branch 'maint-1.6.0' into maint-1.6.1

* maint-1.6.0:
  State the effect of filter-branch on graft explicitly
  process_{tree,blob}: Remove useless xstrdup calls

mergetool--lib: simplify API usage by removing more global variables

The mergetool--lib scriplet was tricky to use because it relied upon
the existance of several global shell variables.  This removes more
global variables so that things are simpler for callers.

A side effect is that some variables are recomputed each time
run_merge_tool() is called, but the overhead for recomputing
them is justified by the simpler implementation.

Signed-off-by: David Aguilar <redacted>
Signed-off-by: Junio C Hamano <redacted>

State the effect of filter-branch on graft explicitly

Signed-off-by: Daniel Cheng (aka SDiZ) <redacted>
Signed-off-by: Junio C Hamano <redacted>

process_{tree,blob}: Remove useless xstrdup calls

On Wed, 8 Apr 2009, Björn Steinbrink wrote:
>
> The name of the processed object was duplicated for passing it to
> add_object(), but that already calls path_name, which allocates a new
> string anyway. So the memory allocated by the xstrdup calls just went
> nowhere, leaking memory.

Ack, ack.

There's another easy 5% or so for the built-in object walker: once we've
created the hash from the name, the name isn't interesting any more, and
so something trivial like this can help a bit.

Does it matter? Probably not on its own. But a few more memory saving
tricks and it might all make a difference.

Linus

Signed-off-by: Junio C Hamano <redacted>

t1301-shared-repo: fix forced modes test

This test was added recently (5a688fe, "core.sharedrepository = 0mode"
should set, not loosen; 2009-03-28). It checked the result of a sed
invocation for emptyness, but in some cases it forgot to print anything
at all, so that those checks would never be false.

Due to this mistake, it went unnoticed that the files in objects/info are
not necessarily 0440, but can also be 0660.  Because the 0mode setting
tries to guarantee that the files are accessible only to the people they
are meant to be used by, we should only make sure that they are readable
by the user and the group when the configuration is set to 0660.  It is a
separate matter from the core.shredrepository settings that w-bit from
immutable object files under objects/[0-9a-f][0-9a-f] directories should
be dropped.

COMMIT_EDITMSG is still world-readable, but it (and any transient files
that are meant for repositories with a work tree) does not matter.  If you
are working on a shared machine and on a sekrit stuff, the root of the
work tree would be with mode 0700 (or 0750 to allow peeking by other
people in the group), and that would mean that .git/COMMIT_EDITMSG in such
a repository would not be readable by the strangers anyway.

Also, in the real-world use case, .git/COMMIT_EDITMSG will be given to an
arbitrary editor the user happens to use, and we have no guarantee what it
does (e.g. it may create a new file with umask and replace, it may rewrite
in place, it may leave an editor backup file but use umask to create it,
etc.), and the protection of the file lies majorly on the protection of
the root of the work tree.

This test cannot be run on Windows; it requires POSIXPERM when merged to
'master'.

Signed-off-by: Johannes Sixt <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-add: introduce --edit (to edit the diff vs. the index)

With "git add -e [<files>]", Git will fire up an editor with the current
diff relative to the index (i.e. what you would get with "git diff
[<files>]").

Now you can edit the patch as much as you like, including adding/removing
lines, editing the text, whatever.  Make sure, though, that the first
character of the hunk lines is still a space, a plus or a minus.

After you closed the editor, Git will adjust the line counts of the hunks
if necessary, thanks to the --recount option of apply, and commit the
patch.  Except if you deleted everything, in which case nothing happens
(for obvious reasons).

Signed-off-by: Johannes Schindelin <redacted>
Signed-off-by: Junio C Hamano <redacted>

documentation: Makefile accounts for SHELL_PATH setting

Ensure that the Makefile that generates and installs the Documentation is
aware of any SHELL_PATH setting.  Use this value if found or the current
setting for SHELL if not.  This is an accommodation for systems where sh
is not POSIX enough.

Signed-off-by: Ben Walton <redacted>
Signed-off-by: Junio C Hamano <redacted>

Allow users to un-configure rename detection

I told people on the kernel mailing list to please use "-M" when sending
me rename patches, so that I can see what they do while reading email
rather than having to apply the patch and then look at the end result.

I also told them that if they want to make it the default, they can just
add

[diff]
renames

to their ~/.gitconfig file. And while I was thinking about that, I wanted
to also check whether you can then mark individual projects to _not_ have
that default in the per-repository .git/config file.

And you can't. Currently you cannot have a global "enable renames by
default" and then a local ".. but not for _this_ project". Why? Because if
somebody writes

[diff]
renames = no

we simply ignore it, rather than resetting "diff_detect_rename_default"
back to zero.

Fixed thusly.

Signed-off-by: Linus Torvalds <redacted>
Signed-off-by: Junio C Hamano <redacted>

Replace ",<,>,& with their respective XML entities in DAV requests

If the repo url or the user email contain XML special characters, the
remote DAV server is likely to reject the LOCK requests because the XML
is then malformed.

Signed-off-by: Mike Hommey <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-svn: always initialize with core.autocrlf=false

It has been reported time and time again in relation to msysGit that
git-svn does not work well when core.autocrlf has any value other than
'false'.  So let's make it so by default.

Signed-off-by: Johannes Schindelin <redacted>
Acked-by: Eric Wong <redacted>
Signed-off-by: Junio C Hamano <redacted>

Update delta compression message to be less misleading

In the case of a small repository, pack-objects is smart enough to not
start more threads than necessary. However, the output to the user always
reports the value of the pack.threads configuration and not the real
number of threads to be used.

Signed-off-by: Dan McGee <redacted>
Acked-by: Nicolas Pitre <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-svn: Save init/clone --ignore-paths in config

The --ignored-paths argument is now stored as
"svn-remote.$REMOTE_NAME.ignore-paths" in the config file.

[ew: edited subject and message]
Signed-off-by: Ben Jackson <redacted>
Acked-by: Eric Wong <redacted>

git-svn: Add per-svn-remote ignore-paths config

The --ignore-paths option to fetch is very useful for working on a subset
of a SVN repository.  For proper operation, every command that causes a
fetch (explicit or implied) must include a matching --ignore-paths option.

This patch adds a persistent svn-remote.$repo_id.ignore-paths config by
promoting Fetcher::is_path_ignored to a member function and initializing
$self->{ignore_regex} in Fetcher::new.  Command line --ignore-paths is
still recognized and acts in addition to the config value.

Signed-off-by: Ben Jackson <redacted>
Acked-by: Eric Wong <redacted>

git-svn: speed up blame command

'git svn blame' now uses the 'git cat-file --batch' command to
speed up resolving SVN revision number out of commit SHA by
removing fork+exec overhead.

[ew: enforced 80-column line wrap]

Signed-off-by: Boris Byk <redacted>
Acked-by: Eric Wong <redacted>

git-svn: add fetch --parent option

Signed-off-by: Jason Merrill <redacted>
Acked-By: Eric Wong <redacted>

Fix misspelled mergetool.keepBackup

In several places mergetool.keepBackup was misspelled as merge.keepBackup.

Signed-off-by: Ferry Huberts <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-shell: Add 'git-upload-archive' to allowed commands.

This allows for example gitosis to allow use of 'git archive --remote' in a
controlled environment.

Signed-off-by: Erik Broes <redacted>
Signed-off-by: Junio C Hamano <redacted>

Allow users to un-configure rename detection

On Thu, 9 Apr 2009, Linus Torvalds wrote:
>
>  [diff]
>  renames = no

Btw, while doing this, I also though that "renames = on/off" made more
sense, but while we allow yes/no and true/false for booleans, we don't
allow on/off.

Should we? Maybe. Here's a stupid patch.

Linus

Signed-off-by: Junio C Hamano <redacted>

gitk: Add a command to compare two strings of commits

This adds a row context menu command to compare this commit and its
descendants with the marked commit and its descendants.  The results
are shown in the bottom-left pane.  Commits are compared by checking
whether their headlines are the same and their patches have the same
patch ID as generated by git patch-id.

Merges are ignored and skipped over (as long as they have one
descendant).  If two commits have the same patch ID then the process
will continue and compare their descendants, as long as they both have
exactly one descendant.  If either commit has 0 or 2 or more descendants,
the comparison stops there.  There is currently a limit of 100
comparisons.

This can be useful for checking whether one string of commits is just
a rebased version of another string of commits.  Mark the end of one
string (i.e. the oldest commit in the string) and invoke "Compare with
marked commit" on the end of the other string.

As this is implemented, the UI will be unresponsive while the results
are being generated.  This should be fixed.

Signed-off-by: Paul Mackerras <redacted>

add tests for remote groups

This tries to systematically cover existing behavior, and
also mark some expect_failure cases for desired behavior.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Update draft release notes to 1.6.3

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'maint'

* maint:
  Start 1.6.2.3 preparation
  process_{tree,blob}: Remove useless xstrdup calls
  git-pull.sh: better warning message for "git pull" on detached head.

Conflicts:
RelNotes

Start 1.6.2.3 preparation

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'jc/shared-literally' into maint

* jc/shared-literally:
  t1301: loosen test for forced modes
  set_shared_perm(): sometimes we know what the final mode bits should look like
  move_temp_to_file(): do not forget to chmod() in "Coda hack" codepath
  Move chmod(foo, 0444) into move_temp_to_file()
  "core.sharedrepository = 0mode" should set, not loosen

Merge branch 'jc/maint-1.6.0-diff-borrow-carefully' into maint

* jc/maint-1.6.0-diff-borrow-carefully:
  diff --cached: do not borrow from a work tree when a path is marked as assume-unchanged

Merge branch 'maint-1.6.1' into maint

* maint-1.6.1:
  process_{tree,blob}: Remove useless xstrdup calls

Merge branch 'maint-1.6.0' into maint-1.6.1

* maint-1.6.0:
  process_{tree,blob}: Remove useless xstrdup calls

Merge branch 'jc/maint-1.6.0-keep-pack' into maint

* jc/maint-1.6.0-keep-pack:
  pack-objects: don't loosen objects available in alternate or kept packs
  t7700: demonstrate repack flaw which may loosen objects unnecessarily
  Remove --kept-pack-only option and associated infrastructure
  pack-objects: only repack or loosen objects residing in "local" packs
  git-repack.sh: don't use --kept-pack-only option to pack-objects
  t7700-repack: add two new tests demonstrating repacking flaws
  is_kept_pack(): final clean-up
  Simplify is_kept_pack()
  Consolidate ignore_packed logic more
  has_sha1_kept_pack(): take "struct rev_info"
  has_sha1_pack(): refactor "pretend these packs do not exist" interface
  git-repack: resist stray environment variable

Conflicts:
t/t7700-repack.sh

Merge branch 'jc/maint-1.6.0-blame-s' into maint-1.6.1

* jc/maint-1.6.0-blame-s:
  blame: read custom grafts given by -S before calling setup_revisions()

Conflicts:
builtin-blame.c

Merge branch 'bc/maint-1.6.1-branch-deleted-was' into maint-1.6.1

* bc/maint-1.6.1-branch-deleted-was:
  git-branch: display "was sha1" on branch deletion rather than just "sha1"

Merge branch 'js/maint-1.6.0-exec-path-env' into maint-1.6.1

* js/maint-1.6.0-exec-path-env:
  Propagate --exec-path setting to external commands via GIT_EXEC_PATH

Merge branch 'tr/maint-1.6.1-doc-format-patch--root' into maint-1.6.1

* tr/maint-1.6.1-doc-format-patch--root:
  Documentation: format-patch --root clarifications

process_{tree,blob}: Remove useless xstrdup calls

The name of the processed object was duplicated for passing it to
add_object(), but that already calls path_name, which allocates a new
string anyway. So the memory allocated by the xstrdup calls just went
nowhere, leaking memory.

This reduces the RSS usage for a "rev-list --all --objects" by about 10% on
the gentoo repo (fully packed) as well as linux-2.6.git:

    gentoo:
                    | old           | new
    ----------------|-------------------------------
    RSS             |       1537284 |       1388408
    VSZ             |       1816852 |       1667952
    time elapsed    |       1:49.62 |       1:48.99
    min. page faults|        417178 |        379919

    linux-2.6.git:
                    | old           | new
    ----------------|-------------------------------
    RSS             |        324452 |        292996
    VSZ             |        491792 |        460376
    time elapsed    |       0:14.53 |       0:14.28
    min. page faults|         89360 |         81613

Signed-off-by: Björn Steinbrink <redacted>
Signed-off-by: Junio C Hamano <redacted>

tests: skip perl tests if NO_PERL is defined

These scripts all test git programs that are written in
perl, and thus obviously won't work if NO_PERL is defined.
We pass NO_PERL to the scripts from the building Makefile
via the GIT-BUILD-OPTIONS file.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Makefile: allow building without perl

For systems with a missing or broken perl, it is nicer to
explicitly say "we don't want perl" because:

  1. The Makefile knows not to bother with Perl-ish things
     like Git.pm.

  2. We can print a more user-friendly error message
     than "foo is not a git command" or whatever the broken
     perl might barf

  3. Test scripts that require perl can mark themselves and
     such and be skipped

This patch implements parts (1) and (2). The perl/
subdirectory is skipped entirely, gitweb is not built, and
any git commands which rely on perl will print a
human-readable message and exit with an error code.

This patch is based on one from Robin H. Johnson.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

gitk: Add a way to mark a commit, plus a "find descendant" command

This adds a context-menu command to put a mark on this commit.  There
is at most one marked commit at any time, and it is indicated by a box
drawn around the headline.  Once a commit is marked, two other
context-menu commands become available: one to select the marked commit,
and another to find the closest common descendant of this commit and
the marked commit.

The "find common descendant" command uses the displayed parent/child
relationships (i.e. the rewritten parent pointers produced by git log),
not the real parent/child relationships.  Currently the UI will be
unresponsive while gitk is working out the nearest common descendant;
this should be improved in future.

Signed-off-by: Paul Mackerras <redacted>

git-gui: run post-checkout hook after clone

git-gui is using "git-read-tree -u" when cloning which doesn't
invoke the post-checkout hook as a plain git-clone would.
So git-gui must call the hook itself.

Signed-off-by: Jens Lehmann <redacted>
Signed-off-by: Shawn O. Pearce <redacted>

Merge branch 'maint'

* maint:
  git-gui: Ensure consistent usage of mergetool.keepBackup
  git-gui: fix use of undeclared variable diff_empty_count

git-gui: Ensure consistent usage of mergetool.keepBackup

In several places merge.keepBackup is used i.s.o.
mergetool.keepBackup. This patch makes it all
consistent.

Signed-off-by: Ferry Huberts <redacted>
Signed-off-by: Shawn O. Pearce <redacted>

git-gui: fix use of undeclared variable diff_empty_count

Commit 584fa9cc introduced the global variable diff_empty_count, which
is used in diff.tcl. This variable wasn't declared anywhere which
resulted in an ugly error message box instead of the intended
informative message.

Signed-off-by: Joerg Bornemann <redacted>
Signed-off-by: Shawn O. Pearce <redacted>

git-pull.sh: better warning message for "git pull" on detached head.

Otherwise, git complains about not finding a branch to pull from in
'branch..merge', which is hardly understandable. While we're there,
reword the sentences slightly.

Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

difftool/mergetool: refactor commands to use git-mergetool--lib

This consolidates the common functionality from git-mergetool and
git-difftool--helper into a single git-mergetool--lib scriptlet.

Signed-off-by: David Aguilar <redacted>
Signed-off-by: Junio C Hamano <redacted>

make get_short_ref a public function

Often we want to shorten a full ref name to something "prettier"
to show a user. For example, "refs/heads/master" is often shown
simply as "master", or "refs/remotes/origin/master" is shown as
"origin/master".

Many places in the code use a very simple formula: skip common
prefixes like refs/heads, refs/remotes, etc. This is codified in
the prettify_ref function.

for-each-ref has a more correct (but more expensive) approach:
consider the ref lookup rules, and try shortening as much as
possible while remaining unambiguous.

This patch makes the latter strategy globally available as
shorten_unambiguous_ref.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

branch: show upstream branch when double verbose

This information is easily accessible when we are
calculating the relationship. The only reason not to print
it all the time is that it consumes a fair bit of screen
space, and may not be of interest to the user.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

for-each-ref: add "upstream" format field

The logic for determining the upstream ref of a branch is
somewhat complex to perform in a shell script. This patch
provides a plumbing mechanism for scripts to access the C
logic used internally by git-status, git-branch, etc.

For example:

  $ git for-each-ref \
       --format='%(refname:short) %(upstream:short)' \
       refs/heads/
  master origin/master

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

for-each-ref: refactor refname handling

This code handles some special magic like *-deref and the
:short formatting specifier. The next patch will add another
field which outputs a ref and wants to use the same code.

This patch splits the "which ref are we outputting" from the
actual formatting. There should be no behavioral change.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Merge branch 'maint'

* maint:
  Change double quotes to single quotes in message
  Documentation: clarify .gitattributes search
  git-checkout.txt: clarify that <branch> applies when no path is given.
  git-checkout.txt: fix incorrect statement about HEAD and index

Conflicts:
Documentation/git-checkout.txt

Merge branch 'maint-1.6.1' into maint

* maint-1.6.1:
  Documentation: clarify .gitattributes search
  git-checkout.txt: clarify that <branch> applies when no path is given.
  git-checkout.txt: fix incorrect statement about HEAD and index

Change double quotes to single quotes in message

Most of the time when we give branch name in the message, we quote it
inside a pair of single-quotes.  git-checkout uses double-quotes; this
patch corrects the inconsistency.

Signed-off-by: Jari Aalto <redacted>
Signed-off-by: Junio C Hamano <redacted>

Merge branch 'maint-1.6.0' into maint-1.6.1

* maint-1.6.0:
  Documentation: clarify .gitattributes search
  git-checkout.txt: clarify that <branch> applies when no path is given.
  git-checkout.txt: fix incorrect statement about HEAD and index

Merge branch 'lt/reflog-expire'

* lt/reflog-expire:
  Speed up reflog pruning of unreachable commits
  Clean up reflog unreachability pruning decision

Merge branch 'bs/maint-1.6.0-tree-walk-prefix'

* bs/maint-1.6.0-tree-walk-prefix:
  match_tree_entry(): a pathspec only matches at directory boundaries
  tree_entry_interesting: a pathspec only matches at directory boundary

Merge branch 'ms/http-auth'

* ms/http-auth:
  Allow curl to rewind the read buffers

Merge branch 'js/maint-submodule-checkout'

* js/maint-submodule-checkout:
  Fix 'git checkout <submodule>' to update the index

Merge branch 'cb/maint-merge-recursive-submodule-fix'

* cb/maint-merge-recursive-submodule-fix:
  simplify output of conflicting merge
  update cache for conflicting submodule entries
  add tests for merging with submodules

Merge branch 'mh/html-path'

* mh/html-path:
  add --html-path to get the location of installed HTML docs

mergetool: use $( ... ) instead of `backticks`

This makes mergetool consistent with Documentation/CodingGuidelines.

Signed-off-by: David Aguilar <redacted>
Signed-off-by: Junio C Hamano <redacted>

bash completion: add git-difftool

This adds completion for difftool's --tool flag.
The known diff tool names were also consolidated into
a single variable.

Signed-off-by: David Aguilar <redacted>
Signed-off-by: Junio C Hamano <redacted>

difftool: add support for a difftool.prompt config variable

difftool now supports difftool.prompt so that users do not have to
pass --no-prompt or hit enter each time a diff tool is launched.
The --prompt flag overrides the configuration variable.

Signed-off-by: David Aguilar <redacted>
Signed-off-by: Junio C Hamano <redacted>

difftool: add various git-difftool tests

t7800-difftool.sh tests the various command-line flags,
git-config variables, and environment settings supported by
git-difftool.

Signed-off-by: David Aguilar <redacted>
Signed-off-by: Junio C Hamano <redacted>

difftool: move 'git-difftool' out of contrib

This prepares 'git-difftool' and its documentation for
mainstream use.

'git-difftool-helper' became 'git-difftool--helper'
since users should not use it directly.

'git-difftool' was added to the list of commands as
an ancillaryinterrogator.

Signed-off-by: David Aguilar <redacted>
Signed-off-by: Junio C Hamano <redacted>

difftool/mergetool: add diffuse as merge and diff tool

This adds diffuse as a built-in merge tool.

Signed-off-by: Sebastian Pipping <redacted>
Signed-off-by: David Aguilar <redacted>
Signed-off-by: Junio C Hamano <redacted>

difftool: add a -y shortcut for --no-prompt

This is another consistency cleanup to make git-difftool's options
match git-mergetool.

Signed-off-by: David Aguilar <redacted>
Signed-off-by: Junio C Hamano <redacted>

difftool: use perl built-ins when testing for msys

I don't even know what $COMSPEC means so let's be safe and use the
same perly $^O test add--interactive uses.  While we're at it, make
git-difftool match the prevalent git-perl style.

Signed-off-by: David Aguilar <redacted>
Signed-off-by: Junio C Hamano <redacted>

difftool: remove the backup file feature

Most users find the backup file feature annoying and there's no
need for it since diff is supposed to be a read-only operation.

Signed-off-by: David Aguilar <redacted>
Signed-off-by: Junio C Hamano <redacted>

difftool: remove merge options for opendiff, tkdiff, kdiff3 and xxdiff

We shouldn't try to merge files when using difftool, so remove
any merge-specific options.

Signed-off-by: David Aguilar <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-mergetool: add new merge tool TortoiseMerge

TortoiseMerge comes with TortoiseSVN or TortoiseGit for Windows. It can
only be used as a merge tool with an existing base file. It cannot be
used without a base nor as a diff tool.

The documentation only mentions the slash '/' as command line option
prefix, which refused to work, but the parser also accepts the dash '-'

See http://code.google.com/p/msysgit/issues/detail?id=226

Signed-off-by: Markus Heidelberg <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-mergetool/difftool: make (g)vimdiff workable under Windows

Under Windows vimdiff and gvimdiff are not available as symbolic links,
but as batch files vimdiff.bat and gvimdiff.bat. These files weren't
found by 'type vimdiff' which led to the following error:

    The merge tool vimdiff is not available as 'vimdiff'

Even if they were found, it wouldn't work to invoke these batch files
from git-mergetool.

To solve this, use vim and gvim (vim.exe and gvim.exe) and pass the -d
command line switch over to them.

Signed-off-by: Markus Heidelberg <redacted>
Signed-off-by: Junio C Hamano <redacted>

doc/merge-config: list ecmerge as a built-in merge tool

Signed-off-by: Markus Heidelberg <redacted>
Signed-off-by: Junio C Hamano <redacted>

rev-list: add "int bisect_show_flags" in "struct rev_list_info"

This is a cleanup patch to make it easier to use the
"show_bisect_vars" function and take advantage of the rev_list_info
struct.

Signed-off-by: Christian Couder <redacted>
Signed-off-by: Junio C Hamano <redacted>

rev-list: remove last static vars used in "show_commit"

This patch removes the last static variables that were used in
the "show_commit" function.

To do that, we create a new "rev_list_info" struct that we will pass
in the "void *data" argument to "show_commit".

This means that we have to change the first argument to
"show_bisect_vars" too.

While at it, we also remove a "struct commit_list *list" variable
in "cmd_rev_list" that is not really needed.

Signed-off-by: Christian Couder <redacted>
Signed-off-by: Junio C Hamano <redacted>

list-objects: add "void *data" parameter to show functions

The goal of this patch is to get rid of the "static struct rev_info
revs" static variable in "builtin-rev-list.c".

To do that, we need to pass the revs to the "show_commit" function
in "builtin-rev-list.c" and this in turn means that the
"traverse_commit_list" function in "list-objects.c" must be passed
functions pointers to functions with 2 parameters instead of one.

So we have to change all the callers and all the functions passed
to "traverse_commit_list".

Anyway this makes the code more clean and more generic, so it
should be a good thing in the long run.

Signed-off-by: Christian Couder <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-rev-list.txt: make ascii markup uniform with other pages.

Other pages use --option=<argument>, not --option='argument', do the
same here.

Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-send-email.txt: clarify which options take an argument.

Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

for-each-ref: refactor get_short_ref function

This function took a "refinfo" object which is unnecessarily
restrictive; it only ever looked at the refname field. This
patch refactors it to take just the ref name as a string.

While we're touching the relevant lines, let's give it
consistent memory semantics. Previously, some code paths
would return an allocated string and some would return the
original string; now it will always return a malloc'd
string.

This doesn't actually fix a bug or a leak, because
for-each-ref doesn't clean up its memory, but it makes the
function a lot less surprising for reuse (which will
happen in a later patch).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Documentation: Introduce "upstream branch"

Signed-off-by: Santi Béjar <redacted>
Signed-off-by: Junio C Hamano <redacted>

Documentation: clarify .gitattributes search

Use the term "toplevel of the work tree" in gitattributes.txt and
gitignore.txt to define the limits of the search for those files.

Signed-off-by: Jason Merrill <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-checkout.txt: clarify that <branch> applies when no path is given.

Otherwise, the sentence "Defaults to HEAD." can be mis-read to mean
that "git checkout -- hello.c" checks-out from HEAD.

Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-checkout.txt: fix incorrect statement about HEAD and index

The command "git checkout" checks out from the index by default, not
HEAD (the introducing comment were correct, but the detailled
explanation added below were not).

Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>