This does two things:
- It changes the hardcoded default merge strategy for two-head
git-pull from resolve to recursive.
- .git/config file acquires two configuration items.
pull.twohead names the strategy for two-head case, and
pull.octopus names the strategy for octopus merge.
IOW you are paranoid, you can have the following lines in your
.git/config file and keep using git-merge-resolve when pulling
one remote:
[pull]
twohead = resolve
OTOH, you can say this:
[pull]
twohead = resolve
twohead = recursive
to try quicker resolve first, and when it fails, fall back to
recursive.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Junio 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: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio 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: Junio 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: Junio 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: Junio 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: Junio 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: Junio C Hamano <junkio@cox.net>
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: Junio 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: Junio 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: Junio 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: Junio 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: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus 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.
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.
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.
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: Junio 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.
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: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Linus 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..
They sure as hell aren't perfect, but they allow you to do:
./git-pull-script {other-git-directory}
to do the initial merge, and if that had content clashes, you do
merge-cache ./git-merge-one-file-script -a
which tries to auto-merge. When/if the auto-merge fails, it will
leave the last file in your working directory, and you can edit
it and then when you're happy you can do "update-cache filename"
on it. Re-do the merge-cache thing until there are no files left
to be merged, and now you can write the tree and commit:
write-tree
commit-tree .... -p $(cat .git/HEAD) -p $(cat .git/MERGE_HEAD)
and you're done.
Junio C Hamano