Refactored fetch options into separate fetch-options.txt.
Made git-merge use merge-options.
Made git-fetch use fetch-options.
Made git-pull use merge-options and fetch-options.
Added --help option to git-pull and git-format-patch scripts.
Rewrote Documentation/Makefile to dynamically determine
include dependencies.
Signed-off-by: NJon Loeliger <jdl@freescale.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Pasky and I did overlapping documentation independently; this is to
pick up better wordings from what he sent me.
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

With --no-commit flag, git-pull will perform the merge but pretends as
if the merge needed a hand resolve even if automerge cleanly resolves,
to give the user a chance to add further changes and edit the commit
message.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

This again makes git-pull to use git-merge, so that different merge
strategy can be specified from the command line.  Without explicit
strategy parameter, it defaults to git-merge-resolve if only one
remote is pulled, and git-merge-octopus otherwise, to keep the
default behaviour of the command the same as the original.

Also this brings another usability measure: -n flag from the command
line, if given, is passed to git-merge to prevent it from running the
diffstat at the end of the merge.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This uses the git-update-ref command in scripts for safer updates.
Also places where we used to read HEAD ref by using "cat" were fixed
to use git-rev-parse.  This will matter when we start using symbolic
references.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The refspecs specified in the .git/remotes/<remote> on the "Pull: "
lines are for fetching multiple heads in one go, but most of the time
making an Octopus out of them is not what is wanted.  Make git-fetch
leave the marker in .git/FETCH_HEAD file so that later stages can
tell which heads are for merging and which are not.

Tom Prince made me realize how stupid the original behaviour was.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Including the current branch in the list of heads being merged
was not a good idea, so drop it.  And shorten the message by
grouping branches and tags together to form a single line.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This reverts f887564a commit.

This reverts 63f1aa6c commit.

Linus says that 'of .' to mean the commits came from the local repository
was too confusing and ugly -- I tend to agree with him.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

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

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

As promised, this is the "big tool rename" patch.  The primary differences
since 0.99.6 are:

  (1) git-*-script are no more.  The commands installed do not
      have any such suffix so users do not have to remember if
      something is implemented as a shell script or not.

  (2) Many command names with 'cache' in them are renamed with
      'index' if that is what they mean.

There are backward compatibility symblic links so that you and
Porcelains can keep using the old names, but the backward
compatibility support  is expected to be removed in the near
future.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When the "git pull" command updates the branch head you are
currently on, before doing anything else, first update your
index file and the working tree contents to that of the new
branch head.  Otherwise, the later resolving steps would think
your index file is attempting to revert the change between the
original head commit and the updated head commit.

It uses two-tree fast-forward form of "read-tree -m -u" to
prevent losing whatever local changes you may have in the
working tree to do this update.  I think this would at least
make things safer (a lot safer), and prevent mistakes.

Also "git fetch" command is forbidden from fetching and fast
forwarding the current branch head unless --update-head-ok flag
is given.  "git pull" passes the flag when it internally calls
"git fetch".
Signed-off-by: NJunio C Hamano <junkio@cox.net>

With this, you can finally say "git pull jgarzik sil24 pdc2027x".
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Update git-pull to match updated git-fetch and allow pull to
fetch from multiple remote references.  There is no support for
resolving more than two heads, which will be done with "git
octopus".

Update "git ls-remote" to use git-parse-remote-script.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Since pull and fetch are done often against the same remote
repository repeatedly, keeping the URL to pull from along with
the name of the head to use in $GIT_DIR/branches/$name makes a
lot of sense.  Adopt that convention from Cogito, and try to be
compatible when possible; storing a partial URL and completing
it with a trailing path may not be understood by Cogito.

While we are at it, fix pulling a tag.  Earlier, we updated only
refs/tags/$tag without updating FETCH_HEAD, and called
resolve-script using a stale (or absent) FETCH_HEAD.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

It used to do "Merge $3" as the message, but that ends up being
inconvenient, and much more easily done inside git-pull-script instead.

This makes the third argument to "git resolve" much easier to explain.

It sets up the normal git environment variables and a few helper
functions (currently just "die()"), and returns ok if it all looks like
a git archive.  So use it something like

	. git-sh-setup-script || die "Not a git archive"

to make the rest of the git scripts more careful and readable.

I'd stupidly only tested the non-branch-name version.

We codify the following different heads (in addition to the main "HEAD",
which points to the current branch, of course):

 - FETCH_HEAD

   Populated by "git fetch"

 - ORIG_HEAD

   The old HEAD before a "git pull/resolve" (successful or not)

 - LAST_MERGE

   The HEAD we're currently merging in "git pull/resolve"

 - MERGE_HEAD

   The previous head of a unresolved "git pull", which gets committed by
   a "git commit" after manually resolving the result

We used to have "MERGE_HEAD" be populated directly by the fetch, and we
removed ORIG_HEAD and LAST_MERGE too aggressively.

In particular, make them readable on one line since that's what all the
tools like git-shortlog and gitk end up showing.

Don't continue with a merge if the fetch failed.

This also drops the common ".git" part from the end of the repo
name, and if a non-default head reference is given, makes a nicer
commit message about it.

This allows you to just fetch stuff first, inspect it, and then
resolve the merge separately if everything looks good.

During the mailing list discussion on renaming GIT_ environment
variables, people felt that having one environment that lets the
user (or Porcelain) specify both SHA1_FILE_DIRECTORY (now
GIT_OBJECT_DIRECTORY) and GIT_INDEX_FILE for the default layout
would be handy.  This change introduces GIT_DIR environment
variable, from which the defaults for GIT_INDEX_FILE and
GIT_OBJECT_DIRECTORY are derived.  When GIT_DIR is not defined,
it defaults to ".git".  GIT_INDEX_FILE defaults to
"$GIT_DIR/index" and GIT_OBJECT_DIRECTORY defaults to
"$GIT_DIR/objects".

Special thanks for ideas and discussions go to Petr Baudis and
Daniel Barkalow.  Bugs are mine ;-)
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

Separate out the merge resolve from the actual getting of the
data. Also, update the resolve phase to take advantage of the
fact that we don't need to do the commit->tree object lookup
by hand, since all the actors involved happily just act on a
commit object these days.

This way you always see what the state change was.

People are already starting to use a multi-head model.

This is useful to verify that you got the right thing.

Let's see what else I forgot..

If you set SHA1_FILE_DIRECTORY to something else than .git/objects
git-pull-script will store the fetched files in a location the rest of
the tools does not expect.

git-prune-script also ignores this setting, but I think this is good,
because pruning a shared tree to fit a single project means throwing
away a lot of useful data. :-)
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When the trivial "read-tree" merge fails, fall back on the (equally
trivial) automatic merge script instead of forcing the user to do
it by hand.

When _that_ fails, you get to do a manual merge.

reading a single tree too. That should speed up a
trivial merge noticeably.

Also, don't bother reading back the tree we just wrote
when we committed a real merge. It had better be the
same one we still have..

Also exit gracefully if the HEAD pull failed, rather than use
a possibly stale MERGE_HEAD.

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