Although Git interally has the facility to differentiate between
porcelain and plubmbing commands and appropriately print errors,
several shell scripts invoke plubming commands triggering cryptic
plumbing errors to be displayed on a porcelain interface. This patch
replaces the "needs update" message in git-pull and git-rebase, when
`git update-index` is run, with a more friendly message.
Reported-by: Joshua Jensen <jjensen@workspacewhiz.com>
Reported-by: Thore Husfeldt <thore.husfeldt@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Prior to c85c792 (pull --rebase: be cleverer with rebased upstream
branches, 2008-01-26), pull --rebase would run
git rebase $merge_head
which resulted in a call to
git format-patch ... --ignore-if-in-upstream $merge_head..$cur_branch
This resulted in patches from $merge_head..$cur_branch being applied, as
long as they did not already exist in $cur_branch..$merge_head.
Unfortunately, when upstream is rebased, $merge_head..$cur_branch also
refers to "old" commits that have already been rebased upstream, meaning
that many patches that were already fixed upstream would be reapplied.
This could result in many spurious conflicts, as well as reintroduce
patches that were intentionally dropped upstream.
So the algorithm was changed in c85c792 (pull --rebase: be cleverer with
rebased upstream branches, 2008-01-26) and d44e712 (pull: support rebased
upstream + fetch + pull --rebase, 2009-07-19). Defining $old_remote_ref to
be the most recent entry in the reflog for @{upstream} that is an ancestor
of $cur_branch, pull --rebase was changed to run
git rebase --onto $merge_head $old_remote_ref
which results in a call to
git format-patch ... --ignore-if-in-upstream $old_remote_ref..$cur_branch
The whole point of this change was to reduce the number of commits being
reapplied, by avoiding commits that upstream already has or had.
In the rebased upstream case, this change achieved that purpose. It is
worth noting, though, that since $old_remote_ref is always an ancestor of
$cur_branch (by its definition), format-patch will not know what upstream
is and thus will not be able to determine if any patches are already
upstream; they will all be reapplied.
In the non-rebased upstream case, this new form is usually the same as the
original code but in some cases $old_remote_ref can be an ancestor of
$(git merge-base $merge_head $cur_branch)
meaning that instead of avoiding reapplying commits that upstream already
has, it actually includes more such commits. Combined with the fact that
format-patch can no longer detect commits that are already upstream (since
it is no longer told what upstream is), results in lots of confusion for
users (e.g. "git is giving me lots of conflicts in stuff I didn't even
change since my last push.")
Cases where additional commits could be reapplied include forking from a
commit other than the tracking branch, or amending/rebasing after pushing.
Cases where the inability to detect upstreamed commits cause problems
include independent discovery of a fix and having your patches get
upstreamed by some alternative route (e.g. pulling your changes to a third
machine, pushing from there, and then going back to your original machine
and trying to pull --rebase).
Fix the non-rebased upstream case by ignoring $old_remote_ref whenever it
is contained in $(git merge-base $merge_head $cur_branch). This should
have no affect on the rebased upstream case.
Acked-by: Santi Béjar <santi@agolina.net>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pull was never meant to take --dry-run at all. However, it
passes unknown arguments to git-fetch, which does do a
dry-run. Unfortunately, pull then attempts to merge whatever
cruft was in FETCH_HEAD (which the dry-run fetch will not
have written to).
Even though we never advertise --dry-run as something that
should work, it is still worth being defensive because:
1. Other commands (including fetch) take --dry-run, so a
user might try it.
2. Rather than simply producing an error, it actually
changes the repository in totally unexpected ways.
This patch makes "pull --dry-run" equivalent to "fetch
--dry-run".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Update draft release notes to 1.7.0.3
fetch: Fix minor memory leak
fetch: Future-proof initialization of a refspec on stack
fetch: Check for a "^{}" suffix with suffixcmp()
daemon: parse_host_and_port SIGSEGV if port is specified
Makefile: Fix CDPATH problem
pull: replace unnecessary sed invocation
Getting the shortened branch name is as easy as using the shell's
parameter expansion.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Note that in the documentation for git-pull, documentation for the
--progress option is displayed under the "Options related to fetching"
subtitle via fetch-options.txt.
Also, update the documentation of the -q/--quiet option for git-pull to
mention its effect on progress reporting during fetching.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
14e5d40 (pull: Fix parsing of -X<option>, 2010-01-17) forgot that
merge_name needs to stay as a single non-interpolated string.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ap/merge-backend-opts:
Document that merge strategies can now take their own options
Extend merge-subtree tests to test -Xsubtree=dir.
Make "subtree" part more orthogonal to the rest of merge-recursive.
pull: Fix parsing of -X<option>
Teach git-pull to pass -X<option> to git-merge
git merge -X<option>
git-merge-file --ours, --theirs
Conflicts:
git-compat-util.h
As -X parameter can contain arbitrary $IFS characters, we need to
properly quote it from the shell while forming the command line.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This needs the usual sq then eval trick to allow IFS characters
in the option.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Various commands refuse to run in the presence of conflicts (commit,
merge, pull, cherry-pick/revert). They all used to provide rough, and
inconsistant error messages.
A new variable advice.resolveconflict is introduced, and allows more
verbose messages, pointing the user to the appropriate solution.
For commit, the error message used to look like this:
$ git commit
foo.txt: needs merge
foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169)
foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030)
foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4)
error: Error building trees
The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN
option to make the output more consistant with the other porcelain
commands, and catch the error in return, to stop with a clean error
message. The next lines were displayed by a call to cache_tree_update(),
which is not reached anymore if we noticed the conflict.
The new output looks like:
U foo.txt
fatal: 'commit' is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>' as
appropriate to mark resolution and make a commit, or use 'git commit -a'.
Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD
exists instead of waiting for merge to complain.
The behavior of merge and the test-case are slightly modified to reflect
the usual flow: start with conflicts, fix them, and afterwards get rid of
MERGE_HEAD, with different error messages at each stage.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit c0ecb07048 "git-pull.sh:
Fix call to git-merge for new command format" and
commit b81e00a965 "git-merge: a deprecation
notice of the ancient command line syntax".
They caused a "git pull" (without any arguments, and without any local
commits---only to update to the other side) to warn that commit log
message is ignored because the merge resulted in a fast-forward.
Another possible solution is to add an extra option to "git merge" so that
"git pull" can tell it that the message given is not coming from the end
user (the canned message is passed just in case the merge resulted in a
non-ff and caused commit), but I think it is easier _not_ to deprecate the
old syntax.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When pull --rebase fails because it cannot find what branch to
merge against, the error message implies we are trying to merge.
Say "rebase against" instead of "merge with" to avoid confusion.
The configuration suggested to remedy the situation uses a
confusing syntax, with variables specified in the dotted form
accepted by 'git config' but separated from their values by the
'=' delimiter used by config files. Since the user will have to
edit this output anyway, it is more helpful to provide a config
file snippet to paste into an editor and modify.
Signed-off-by: Jan Krüger <jk@jk.gs>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now "git merge <msg> HEAD" is officially deprecated, we should
clean our own use as well.
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For convenience in scripts and aliases, add the option
--ff-only to only allow fast-forwards (and up-to-date,
despite the name).
Disallow combining --ff-only and --no-ff, since they
flatly contradict each other.
Allow all other options to be combined with --ff-only
(i.e. do not add any code to handle them specially),
including the following options:
* --strategy (one or more): As long as the chosen merge
strategy results in up-to-date or fast-forward, the
command will succeed.
* --squash: I cannot imagine why anyone would want to
squash commits only if fast-forward is possible, but I
also see no reason why it should not be allowed.
* --message: The message will always be ignored, but I see
no need to explicitly disallow providing a redundant message.
Acknowledgements: I did look at Yuval Kogman's earlier
patch (107768 in gmane), mainly as shortcut to find my
way in the code, but I did not copy anything directly.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are several reasons a git-pull invocation might not
have anything marked for merge:
1. We're not on a branch, so there is no branch
configuration.
2. We're on a branch, but there is no configuration for
this branch.
3. We fetched from the configured remote, but the
configured branch to merge didn't get fetched (either
it doesn't exist, or wasn't part of the fetch refspec).
4. We fetched from the non-default remote, but didn't
specify a branch to merge. We can't use the configured
one because it applies to the default remote.
5. We fetched from a specified remote, and a refspec was
given, but it ended up not fetching anything (this is
actually hard to do; if the refspec points to a remote
branch and it doesn't exist, then fetch will fail and
we never make it to this code path. But if you provide
a wildcard refspec like
refs/bogus/*:refs/remotes/origin/*
then you can see this failure).
We have handled (1) and (2) for some time. Recently, commit
a6dbf88 added code to handle case (3).
This patch handles cases (4) and (5), which previously just
fell under other cases, producing a confusing message.
While we're at it, let's rewrap the text for case (3), which
looks terribly ugly as it is.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Back when a74b170 (git-pull: disallow implicit merging to detached HEAD,
2007-01-15) added this check, $? referred to the error status of reading
HEAD as a symbolic-ref; but cd67e4d (Teach 'git pull' about --rebase,
2007-11-28) moved the command away from where the check is, and nobody
noticed the breakage. Ever since, $? has always been 0 (tr at the end of
the pipe to find merge_head never fails) and other case arms were never
reached.
These days, error_on_no_merge_candidates function is prepared to handle a
detached HEAD case, which was what the code this patch removes used to
handle.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the remote branch we asked for merging did not exist in the set of
fetched refs, we unconditionally hinted that it was because of lack of
configuration. It is not necessarily so, and risks sending users for a
wild goose chase.
Make sure to check if that is indeed the case before telling a wild guess
to the user.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When doing a "pull --rebase", we check to make sure that the index and
working tree are clean. The index-clean check compares the index against
HEAD. The test erroneously reports dirtiness if we don't have a HEAD yet.
In such an "unborn branch" case, by definition, a non-empty index won't
be based on whatever we are pulling down from the remote, and will lose
the local change. Just check if $GIT_DIR/index exists and error out.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
You cannot do a "git pull --rebase" with a rebased upstream, if you have
already run "git fetch". Try to behave as if the "git fetch" was not run.
In other words, find the fork point of the current branch, where
the tip of upstream branch used to be, and use it as the upstream
parameter of "git rebase".
This patch computes the fork point by walking the reflog to find the first
commit which is an ancestor of the current branch. Maybe there are
smarter ways to compute it, but this is a straight forward implementation.
Signed-off-by: Santi Béjar <santi@agolina.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sb/pull-rebase:
parse-remote: remove unused functions
parse-remote: support default reflist in get_remote_merge_branch
parse-remote: function to get the tracking branch to be merge
The only user of get_remote_refs_for_fetch was "git pull --rebase" and
it only wanted the tracking branch to be merge. So, add a simple
function (get_remote_merge_branch) with this new meaning.
No behavior changes. The new function behaves like the old code in
"git pull --rebase". In particular, it only works with the default
refspec mapping and with remote branches, not tags.
Signed-off-by: Santi Béjar <santi@agolina.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A minor fix that eliminates usage of "2>/dev/null" when --quiet or
-q has already been implemented.
Signed-off-by: Dan Loewenherz <daniel.loewenherz@yale.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Forwards the --stat, --no-stat, and --summary options on to git-rebase.
Signed-off-by: Tor Arne Vestbø <torarnv@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It does not make sense to provide multiple upstream branches to either
git pull --rebase, or to git rebase, so disallow both.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To support counting -q/-v options in git pull retain
them by concatenating.
Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Implement git-pull --quiet and git-pull --verbose by
adding the options to git-pull and fixing verbosity
handling in git-fetch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some misguided documents floating on the Net suggest this sequence:
mkdir newdir && cd newdir
git init
git remote add origin $url
git pull origin master:master
"git pull" has known about misguided "pull" that lets the underlying fetch
update the current branch for a long time. It also has known about
"git pull origin master" into a branch yet to be born.
These two workarounds however were not aware of the existence of each
other and did not work well together. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a companion patch to 6848d58c(Ignore dirty submodule states
during rebase and stash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you misuse a git command, you are shown the usage string.
But this is currently shown in the dashed form. So if you just
copy what you see, it will not work, when the dashed form
is no longer supported.
This patch makes git commands show the dash-less version.
For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
generates a dash-less usage string now.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When rebasing fails during "pull --rebase", you cannot just clean up the
working directory and call "pull --rebase" again, since the remote branch
was already fetched.
Therefore, die early when the working directory is dirty.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These are the command line option equivalents of the 'merge.log' config
variable.
The patch also updates documentation and bash completion accordingly, and
adds a test.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option has the same effect as '--(no-)summary' (i.e. whether to
show a diffsat at the end of the merge or not), and it is consistent
with the '--stat' option of other git commands.
Documentation, tests, and bash completion are updaed accordingly, and the
old --summary option is marked as being deprected.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase supports --strategy, so pull should pass the option along to it.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the upstream branch is tracked, we can detect if that branch
was rebased since it was last fetched. Teach git to use that
information to rebase from the old remote head onto the new remote head.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git pull --tags" is run without any other arguments, the
standard error message "You told me to fetch and merge stuff but
there is nothing to merge! You might want to fix your config"
is given.
While the error may be technically correct, fixing the config
would not help, as "git pull --tags" itself tells "git fetch"
not to use the configured refspecs.
This commit makes "git pull --tags" to issue a different error
message to avoid confusion. This is merely an interim solution.
In the longer term, it would be a better approach to change the
semantics of --tags option to make "git fetch" and "git pull"
to:
(1) behave as if no --tags was given (so an explicit refspec on
the command line overrides configured ones, or no explicit
refspecs on the command line takes configured ones); but
(2) no auto-following of tags is made even when using
configured refspecs; and
(3) fetch all tags as not-for-merge entries".
Then we would not need to have this separate error message, as
the ordinary merge will happen even with the --tags option.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When calling 'git pull' with the '--rebase' option, it performs a
fetch + rebase instead of a fetch + merge.
This behavior is more desirable than fetch + pull when a topic branch
is ready to be submitted and needs to be update.
fetch + rebase might also be considered a better workflow with shared
repositories in any case, or for contributors to a centrally managed
repository, such as WINE's.
As a convenience, you can set the default behavior for a branch by
defining the config variable branch.<name>.rebase, which is
interpreted as a bool. This setting can be overridden on the command
line by --rebase and --no-rebase.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
--text follows this line--
These commands currently lack OPTIONS_SPEC; allow people to
easily list with "git grep 'OPTIONS_SPEC=$'" what they can help
improving.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These options are supported by git-merge, but git-pull didn't know about
them.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A lot of shell scripts contained stuff starting with
while case "$#" in 0) break ;; esac
and similar. I consider breaking out of the condition instead of the
body od the loop ugly, and the implied "true" value of the
non-matching case is not really obvious to humans at first glance. It
happens not to be obvious to some BSD shells, either, but that's
because they are not POSIX-compliant. In most cases, this has been
replaced by a straight condition using "test". "case" has the
advantage of being faster than "test" on vintage shells where "test"
is not a builtin. Since none of them is likely to run the git
scripts, anyway, the added readability should be worth the change.
A few loops have had their termination condition expressed
differently.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The diffstat can be controlled either with command-line options
(--summary|--no-summary) or with merge.diffstat. The default is
left as it was: diffstat is active by default.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead, we complain to the user and suggest that they explicitly
specify the remote and branch. We depend on the exit status of
git-symbolic-ref, so let's go ahead and document that.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates five commands (merge, pull, rebase, revert and cherry-pick)
so that they can be started from a subdirectory.
This may not actually be what we want to do. These commands are
inherently whole-tree operations, and an inexperienced user may
mistakenly expect a "git pull" from a subdirectory would merge
only the subdirectory the command started from.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user tries to run a porcelainish command which requires
a working directory in a bare repository they may get unexpected
results which are difficult to predict and may differ from command
to command.
Instead we should detect that the current repository is a bare
repository and refuse to run the command there, as there is no
working directory associated with it.
[jc: updated Shawn's original somewhat -- bugs are mine.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
After a pull that results in a conflicted merge, a new user
often tries another "git pull" in desperation. When the index
is unmerged, merge backends correctly bail out without touching
either index nor the working tree, so this does not make the
wound any worse.
The user will however see several lines of messsages during this
process, such as "filename: needs merge", "you need to resolve
your current index first", "Merging...", and "Entry ... would be
overwritten by merge. Cannot merge.". They are unnecessarily
alarming, and cause useful conflict messages from the first pull
scroll off the top of the terminal.
This changes pull and merge to run "git-ls-files -u" upfront and
stop them much earlier than we currently do. Old timers may
know better and would not to try pulling again before cleaning
things up; this change adds extra overhead that is unnecessary
for them. But this would be worth paying for to save new people
from needless confusion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that git-merge knows how to use the pull.{twohead,octopus}
configuration options to select the default merge strategy there
is no reason for git-pull to do the same immediately prior to
invoking git-merge.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If git-merge exits with a non-zero exit status so should git-pull.
This way the caller of git-pull knows the task did not complete
successfully simply by checking the process exit status.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio rightly pointed out that the --reflog-action parameter
was starting to get out of control, as most porcelain code
needed to hand it to other porcelain and plumbing alike to
ensure the reflog contained the top-level user action and
not the lower-level actions it invoked.
At Junio's suggestion we are introducing the new set_reflog_action
function to all shell scripts, allowing them to declare early on
what their default reflog name should be, but this setting only
takes effect if the caller has not already set the GIT_REFLOG_ACTION
environment variable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The warning triggered even when running "git fetch" only
when resulting .git/FETCH_HEAD only contained
branches marked as 'not-for-merge'.
Signed-off-by: Josef Weidendorfer <weidendo@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to complain that we cannot merge anything we fetched
with a local branch that does not exist yet. Just treat the
case as a natural extension of fast forwarding and make the
local branch'es tip point at the same commit we just fetched.
After all an empty repository without an initial commit is an
ancestor of any commit.
[jc: I added a trivial test. We've become sloppy but we should
stick to the discipline of covering new behaviour with new
tests. ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When git-merge updates HEAD as a result of a merge record what
happened during the merge into the reflog associated with HEAD
(if any). The log reports who caused the update (git-merge or
git-pull, by invoking git-merge), what the remote ref names were
and the type of merge process used.
The merge information can be useful when reviewing a reflog for
a branch such as `master` where fast forward and trivial in index
merges might be common as the user tracks an upstream.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When git-fetch updates a reference record in the associated reflog
what type of update took place and who caused it (git-fetch or
git-pull, by invoking git-fetch).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some implementations of "expr" (e.g. FreeBSD's) fail, if an
argument starts with a dash.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some people tend to do many little commits on a topic branch,
recording all the trials and errors, and when the topic is
reasonably cooked well, would want to record the net effect of
the series as one commit on top of the mainline, removing the
cruft from the history. The topic is then abandoned or forked
off again from that point at the mainline.
The barebone porcelainish that comes with core git tools does
not officially support such operation, but you can fake it by
using "git pull --no-merge" when such a topic branch is not a
strict superset of the mainline, like this:
git checkout mainline
git pull --no-commit . that-topic-branch
: fix conflicts if any
rm -f .git/MERGE_HEAD
git commit -a -m 'consolidated commit log message'
git branch -f that-topic-branch ;# now fully merged
This however does not work when the topic branch is a fast
forward of the mainline, because normal "git pull" will never
create a merge commit in such a case, and there is nothing
special --no-commit could do to begin with.
This patch introduces a new option, --squash, to support such a
workflow officially in both fast-forward case and true merge
case. The user-level operation would be the same in both cases:
git checkout mainline
git pull --squash . that-topic-branch
: fix conflicts if any -- naturally, there would be
: no conflict if fast forward.
git commit -a -m 'consolidated commit log message'
git branch -f that-topic-branch ;# now fully merged
When the current branch is already up-to-date with respect to
the other branch, there truly is nothing to do, so the new
option does not have any effect.
This was brought up in #git IRC channel recently.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Running 'git pull' while on the tracking branch has a built-in
safety valve to fast-forward the index and working tree to match
the branch head, but it errs on the safe side too cautiously.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user does not set a merge strategy for git-pull,
let git-merge calculate a default strategy.
[jc: with minor stylistic tweaks]
Signed-off-by: Mark Hollomon <markhollomon@comcast.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is to be nicer to people with unusable GECOS field.
"git-var -l" is currently broken in that when used by a user who
does not have a usable GECOS field and has not corrected it by
exporting GIT_COMMITTER_NAME environment variable it dies when
it tries to output GIT_COMMITTER_IDENT (same thing for AUTHOR).
"git-pull" used "git-var -l" only because it needed to get a
configuration variable before "git-repo-config --get" was
introduced. Use the latter tool designed exactly for this
purpose.
"git-sh-setup" used "git-var GIT_AUTHOR_IDENT" without actually
wanting to use its value. The only purpose was to cause the
command to check and barf if the repository format version
recorded in the $GIT_DIR/config file is too new for us to deal
with correctly. Instead, use "repo-config --get" on a random
property and see if it die()s, and check if the exit status is
128 (comes from die -- missing variable is reported with exit
status 1, so we can tell that case apart).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now all the users of this script detect its exit status and die,
complaining that it is outside git repository. So move the code
that dies from all callers to git-sh-setup script.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
