git checkout --merge --conflict=diff3 can be used to present conflict
hunks including text from the common ancestor. The added information
is helpful for resolving a merge by hand, and merge tools tend to
understand it because it is very similar to what ‘diff3 -m’ produces.
Unlike current git, diff3 -m includes a label for the merge base on
the ||||||| line, and unfortunately, some tools cannot parse the
conflict hunks without it. Humans can benefit from a cue when
learning to interpreting the format, too. Mark the start of the text
from the old branch with a label based on the branch’s name.
git rerere does not have trouble parsing this output and its preimage
ids are unchanged since it includes its own code for recreating
conflict hunks. No other code in git tries to parse conflict hunks.
Requested-by: Stefan Monnier <monnier@iro.umontreal.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git checkout --conflict=diff3 can be used to present conflicts hunks
including text from the common ancestor:
<<<<<<< ours
ourside
|||||||
original
=======
theirside
>>>>>>> theirs
The added information is helpful for resolving a merge by hand, and
merge tools can usually understand it without trouble because it looks
like output from ‘diff3 -m’.
diff3 includes a label for the merge base on the ||||||| line, and it
seems some tools (for example, Emacs 22’s smerge-mode) cannot parse
conflict hunks without such a label. Humans could use help in
interpreting the output, too. So change the marker for the start of the
text from the common ancestor to include the label “base”.
git rerere’s conflict identifiers are not affected: to parse conflict
hunks, rerere looks for whitespace after the ||||||| marker rather
than a newline, and to compute preimage ids, rerere has its own code
for creating conflict hunks. No other code in git tries to parse
conflict hunks.
Requested-by: Stefan Monnier <monnier@iro.umontreal.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commands using the ll_merge() function will present conflict hunks
imitating ‘diff3 -m’ output if the merge.conflictstyle configuration
option is set appropriately. Unlike ‘diff3 -m’, the output does not
include a label for the merge base on the ||||||| line of the output,
and some tools misparse the conflict hunks without that.
Add a new ancestor_label parameter to ll_merge() to give callers the
power to rectify this situation. If ancestor_label is NULL, the output
format is unchanged. All callers pass NULL for now.
Requested-by: Stefan Monnier <monnier@iro.umontreal.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This shrinks the top-level directory a bit, and makes it much more
pleasant to use auto-completion on the thing. Instead of
[torvalds@nehalem git]$ em buil<tab>
Display all 180 possibilities? (y or n)
[torvalds@nehalem git]$ em builtin-sh
builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c
builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o
[torvalds@nehalem git]$ em builtin-shor<tab>
builtin-shortlog.c builtin-shortlog.o
[torvalds@nehalem git]$ em builtin-shortlog.c
you get
[torvalds@nehalem git]$ em buil<tab> [type]
builtin/ builtin.h
[torvalds@nehalem git]$ em builtin [auto-completes to]
[torvalds@nehalem git]$ em builtin/sh<tab> [type]
shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o
[torvalds@nehalem git]$ em builtin/sho [auto-completes to]
[torvalds@nehalem git]$ em builtin/shor<tab> [type]
shortlog.c shortlog.o
[torvalds@nehalem git]$ em builtin/shortlog.c
which doesn't seem all that different, but not having that annoying
break in "Display all 180 possibilities?" is quite a relief.
NOTE! If you do this in a clean tree (no object files etc), or using an
editor that has auto-completion rules that ignores '*.o' files, you
won't see that annoying 'Display all 180 possibilities?' message - it
will just show the choices instead. I think bash has some cut-off
around 100 choices or something.
So the reason I see this is that I'm using an odd editory, and thus
don't have the rules to cut down on auto-completion. But you can
simulate that by using 'ls' instead, or something similar.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The following function is duplicated:
fill_mm
Move it to xdiff-interface.c and rename it 'read_mmblob', as suggested
by Junio C Hamano.
Also, change parameters order for consistency with read_mmfile().
Signed-off-by: Michael Lukashov <michael.lukashov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old "advice" message explained how to create a branch after going into
a detached HEAD state but didn't make it clear why the user may want to do
so. Also "moving to ... which isn't a local branch" was unclear if it is
complaining, if it is describing the new state, or if it is explaining why
the HEAD is detached (the true reason is the last one).
Give the established phrase 'detached HEAD' first to make it easy for
users to look up the concept in documentation, and briefly describe what
can be done in the state (i.e. play around without having to clean up)
before telling the user how to keep what was done during the temporary
state.
Allow the long description to be hidden by setting advice.detachedHead
configuration to false.
We might want to customize the advice depending on how the commit to check
out was spelled (e.g. instead of "new-branch-name", we way want to say
"topic" when "git checkout origin/topic" triggered this message) in later
updates, but this encapsulates that into a separate function and it should
be a good first step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When switching to a different commit, we first see the named rev exists
as a commit using lookup_commit_reference_gently(), and set new.path to
a string "refs/heads/" followed by the name the user gave us (but after
taking into special short-hands like @{-1} == "previous branch" and
"@{upstream}" == "the branch we merge with" into account). If the
resulting string names an existsing ref, then we are switching to that
branch (and will be building new commits on top of it); otherwise we are
detaching HEAD at that commit.
When the "master..." syntax is used as a short-hand for "master...HEAD",
we do want to detach HEAD at the merge base. However, on Windows, when
asked if ".git/refs/heads/master..." exists, the filesystem happily says
"it does" when ".git/refs/heads/master" exists.
Work this issue around by first calling check_ref_format(new.path) to see
if the string can possibly be a valid ref under "refs/heads/", before
asking resolve_ref().
We used to run another lookup_commit_reference(rev) even though we know it
succeeded and we have a good commit in new.commit already; this has been
with us from 782c2d6 (Build in checkout, 2008-02-07), the first version we
had "git checkout" implemented in C. Drop it.
Noticed by Alex Riesen.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If switching from an unborn branch (= empty tree) to a valid commit failed
without -m, it would fail with -m option as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We should tell ll_merge() that the 3-way merge between stages #2 and #3 is
an outermost merge, not a virtual-ancestor creation.
Back when this code was originally written, users couldn't write custom
merge drivers easily, so the bug didn't matter, but these days it does.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Once you resolved conflicts by "git add path", you cannot recreate the
conflicted state with "git checkout -m path", because you lost information
from higher stages in the index when you resolved them.
Since we record the necessary information in the resolve-undo index
extension these days, we can reproduce the unmerged state in the index and
check it out.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When resolving a conflict using "git add" to create a stage #0 entry, or
"git rm" to remove entries at higher stages, remove_index_entry_at()
function is eventually called to remove unmerged (i.e. higher stage)
entries from the index. Introduce a "resolve_undo_info" structure and
keep track of the removed cache entries, and save it in a new index
extension section in the index_state.
Operations like "read-tree -m", "merge", "checkout [-m] <branch>" and
"reset" are signs that recorded information in the index is no longer
necessary. The data is removed from the index extension when operations
start; they may leave conflicted entries in the index, and later user
actions like "git add" will record their conflicted states afresh.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Porcelains may want to make sure their calls to "git checkout" will
reliably fail regardless of the presense of random remote tracking
branches by the new DWIMmery introduced.
Luckily all existing in-tree callers have extra checks to make sure they
feed local branch name when they want to switch, or they explicitly ask to
detach HEAD at the given commit, so there is no need to add this option
for them.
As this is strictly script-only option, do not even bother to document it,
and do bother to hide it from "git checkout -h".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pretty_print_commit() has a bunch of rarely-used arguments, and
introducing more of them requires yet another update of all the call
sites. Refactor most of them into a struct to make future extensions
easier.
The ones that stay "plain" arguments were chosen on the grounds that
all callers put real arguments there, whereas some callers have 0/NULL
for all arguments that were factored into the struct.
We declare the struct 'const' to ensure none of the callers are bitten
by the changed (no longer call-by-value) semantics.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When flipping commits around on topic branches, I often end up doing
this sequence:
* Run "log --oneline next..jc/frotz" to find out the first commit
on 'jc/frotz' branch not yet merged to 'next';
* Run "checkout $that_commit^" to detach HEAD to the parent of it;
* Rebuild the series on top of that commit; and
* "show-branch jc/frotz HEAD" and "diff jc/frotz HEAD" to verify.
Introduce a new syntax to "git checkout" to name the commit to switch to,
to make the first two steps easier. When the branch to switch to is
specified as A...B (you can omit either A or B but not both, and HEAD
is used instead of the omitted side), the merge base between these two
commits are computed, and if there is one unique one, we detach the HEAD
at that commit.
With this, I can say "checkout next...jc/frotz".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When 'frotz' is not a valid object name and not a tracked filename,
we used to complain and failed this command. When there is only
one remote that has 'frotz' as one of its tracking branches, we can
DWIM it as a request to create a local branch 'frotz' forking from
the matching remote tracking branch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git branch, checkout, clean, mv and tag all have an option -f to override
certain checks. This patch makes them accept the long option --force as
a synonym.
While we're at it, document that checkout support --quiet as synonym for
its short option -q.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When checkout sees that HEAD points to a non-existent ref,
it currently acts as if "-f" was given; this behavior dates
back to 5a03e7f, which enabled checkout from unborn branches
in the shell version of "git-checkout". The reasoning given
is to avoid the code path which tries to merge the tree
contents. When checkout was converted to C, this code
remained intact.
The unfortunate side effect of this strategy is that the
"force" code path will overwrite working tree and index
state that may be precious to the user. Instead of enabling
"force", this patch uses the normal "merge" codepath for an
unborn branch, but substitutes the empty tree for the "old"
commit.
This means that in the absence of an index, any files in the
working tree will be treated as untracked files, and a
checkout which would overwrite them is aborted. Similarly,
any paths in the index will be merged with an empty entry
as the base, meaning that unless the new branch's content is
identical to what's in the index, there will be a conflict
and the checkout will be aborted.
The user is then free to correct the situation or proceed
with "-f" as appropriate.
This patch also removes the "warning: you are on a branch
yet to be born" message. Its function was to warn the user
that we were enabling the "-f" option. Since we are no
longer doing that, there is no reason for the user to care
whether we are switching away from an unborn branch.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This introduces a --patch mode for git-checkout. In the index usage
git checkout --patch -- [files...]
it lets the user discard edits from the <files> at the granularity of
hunks (by selecting hunks from 'git diff' and then reverse applying
them to the worktree).
We also accept a revision argument. In the case
git checkout --patch HEAD -- [files...]
we offer hunks from the difference between HEAD and the worktree, and
reverse applies them to both index and worktree, allowing you to
discard staged changes completely. In the non-HEAD usage
git checkout --patch <revision> -- [files...]
it offers hunks from the difference between the worktree and
<revision>. The chosen hunks are then applied to both index and
worktree.
The application to worktree and index is done "atomically" in the
sense that we first check if the patch applies to the index (it should
always apply to the worktree). If it does not, we give the user a
choice to either abort or apply to the worktree anyway.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To give OPT_FILENAME the prefix, we pass the prefix to parse_options()
which passes the prefix to parse_options_start() which sets the prefix
member of parse_opts_ctx accordingly. If there isn't a prefix in the
calling context, passing NULL will suffice.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, checkout would tell the user this message before moving HEAD,
without regard to whether the upcoming move will result in success.
If the move failed, this causes confusion.
Show the message after the move, unless the move failed.
Signed-off-by: Daniel Cordero <theappleman@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The logic in 83ae209 (checkout branch: prime cache-tree fully,
2009-04-20) is bogus; checkout can switch branches with a dirty
index and in such a case the tree won't match HEAD.
Add t2014-switch to catch this breakage.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes git checkout know to use the threaded index preloading if it
is enabled in the config file. You need to have
[core]
preloadindex = true
in your config file to see it, and for that feature to make sense your
filesystem needs to be able to do concurrent 'lstat()' lookups, but when
that is the case (especially NFS over a high-latency network), this can
be a noticeable performance win.
But with a low-latency network and at least older Linux NFS clients, this
will clearly potentially cause a lot of lock contention. It may still
speed up the uncached case, but the threading and locking overhead will
result in the cached case likely slowing down.
That was almost certainly fixed by Linux commit fc0f684c2 ("NFS: Remove
BKL from NFS lookup code"), but that one got merged into 2.6.27-rc1, so
older kernel versions than 2.6.27 will not scale very well.
But regardless, it's the right thing to do. If your filesystem doesn't
scale, don't enable index preloading.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When switching to another branch, the earlier code relied on incremental
invalidation of cache-tree entries to degrade it. While it is not wrong
per-se, we know that the resulting index must fully match the branch we
are switching to unless the -m (merge) option is used.
We should simply fully re-prime the cache-tree using the new tree object
in such a case. And for safety, invalidate the cache-tree as a whole in
other cases.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <jari.aalto@cante.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While 'git checkout <submodule>' should not update the submodule's
working directory, it should update the index. This is in line with
how submodules are handled in the rest of Git.
While at it, test 'git reset [<commit>] <submodule>', too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows a common calling sequence
strbuf_branchname(&ref, name);
strbuf_splice(&ref, 0, 0, "refs/heads/", 11);
if (check_ref_format(ref.buf))
die(...);
to be refactored into
if (strbuf_check_branch_ref(&ref, name))
die(...);
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function takes a user-supplied string that is supposed to be a branch
name, and puts it in a strbuf after expanding possible shorthand notation.
A handful of open coded sequence to do this in the existing code have been
changed to use this helper function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These allow you to say "git checkout @{-2}" to switch to the branch two
"branch switching" ago by pretending as if you typed the name of that
branch. As it is likely that we will be introducing more short-hands to
write the name of a branch without writing it explicitly, rename the
functions from "nth_last_branch" to more generic "branch_name", to prepare
for different semantics.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Code that calls diff_setup(), including via init_revisions(), should later call
diff_setup_done(), possibly via setup_revisions(). Failure to do so could cause
errors, especially in the future when we add responsibilities to
diff_setup_done(). This instance causes no known errors with the present code.
But it resulted in an error with an experimental patch.
Signed-off-by: Keith Cascio <keith@cs.ucla.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By having flags represented as bits in the new member variable 'flags',
it will be easier to use parse_options when dir_struct is involved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Have '-' mean the same as '@{-1}', i.e., the last branch we were on.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Have the lookup only look at "interesting" checkouts, meaning those
that tell you "Already on ..." don't count even though they also cause
a reflog entry.
Let interpret_nth_last_branch() return the number of characters
parsed, so that git-checkout can verify that the branch spec was
@{-N}, not @{-1}^2 or something like that. (The latter will be added
later.)
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Implement a shortcut @{-N} for the N-th last branch checked out, that
works by parsing the reflog for the message added by previous
git-checkout invocations. We expand the @{-N} to the branch name, so
that you end up on an attached HEAD on that branch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A function that runs a hook is used in several Git commands.
builtin-commit.c has the one that is most general for cases without
piping. The one in builtin-gc.c prints some useful warnings.
This patch moves a merged version of these variants into libgit and
lets the other builtins use this libified run_hook().
The run_hook() function used in receive-pack.c feeds the standard
input of the pre-receive or post-receive hooks. This function is
renamed to run_receive_hook() because the libified run_hook() cannot
handle this.
Mentored-by: Daniel Barkalow <barkalow@iabervon.org>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the case of
git init
echo exit >.git/hooks/post-checkout
chmod +x .git/hooks/post-checkout
touch foo
git add foo
rm foo
git checkout -- foo
git-checkout resulted in a Segmentation fault, because there is no new
branch set for the post-checkout hook.
This patch makes use of the null SHA as it is set for the old branch.
While at it, I removed the xstrdup() around the sha1_to_hex(...) calls
in builtin-checkout.c/post_checkout_hook() because sha1_to_hex()
uses four buffers for the hex-dumped SHA and we only need two.
(Duplicating one buffer is only needed if we need more than four.)
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Both versions have the same functionality. This removes any
redundancy.
This also adds makes two extensions to match_pathspec:
- If pathspec is NULL, return 1. This reflects the behavior of git
commands, for which no paths usually means "match all paths".
- If seen is NULL, do not use it.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git checkout -b newbranch $commit^{tree}" mistakenly created a new branch
rooted at the current HEAD, because in that case, the two structure fields
used to see if the command was invoked without any argument (hence it
needs to default to checking out the HEAD) were populated incorrectly.
Upon seeing a command line argument that we took as a rev, we should store
that string in new.name, even if that does not name a commit. This will
correctly trigger the existing safety logic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
I think it's unnecessary to warn that the checkout has been forced due to an
unborn current branch if -f has been explicitly passed. For one project, I am
using git-new-workdir to create workdirs from a bare repository whose HEAD is
set to an unborn branch, and this warning started to irritate me.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier commit 5521883 (checkout: do not lose staged removal, 2008-09-07)
tightened the rule to prevent switching branches from losing local
changes, so that staged removal of paths can be protected, while
attempting to keep a loophole to still allow a special case of switching
out of an un-checked-out state.
However, the loophole was made a bit too tight, and did not allow
switching from one branch (in an un-checked-out state) to check out
another branch.
The change to builtin-checkout.c in this commit loosens it to allow this,
by not insisting the original commit and the new commit to be the same.
It also introduces a new function, is_index_unborn (and an associated
macro, is_cache_unborn), to check if the repository is truly in an
un-checked-out state more reliably, by making sure that $GIT_INDEX_FILE
did not exist when populating the in-core index structure. A few places
the earlier commit 5521883 added the check for the initial checkout
condition are updated to use this function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using alternates, it is possible for HEAD to end up pointing to
an invalid commit. git checkout should be able to recover from that
situation without crashing.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code to complain when -b is not given but an explicit --track/--no-track
override was given from the command line was unchanged on one branch and
reworked on the other branch. The merge result incorrectly kept it.
Spotted by Matt McCutchen.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many call sites use strbuf_init(&foo, 0) to initialize local
strbuf variable "foo" which has not been accessed since its
declaration. These can be replaced with a static initialization
using the STRBUF_INIT macro which is just as readable, saves a
function call, and takes up fewer lines.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If you fail to update refs to change branches in checkout, your index
and working tree are left already updated. We don't have an easy way
to undo this, but at least we can check things that would make the
creation of a new branch fail. These checks were in the shell version,
and were lost in the C conversion.
The messages are from the shell version, and should probably be made nicer.
[jc: added test to t7201]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The logic to checkout a different commit implements the safety to never
lose user's local changes. For example, switching from a commit to
another commit, when you have changed a path that is different between
them, need to merge your changes to the version from the switched-to
commit, which you may not necessarily be able to resolve easily. By
default, "git checkout" refused to switch branches, to give you a chance
to stash your local changes (or use "-m" to merge, accepting the risks of
getting conflicts).
This safety, however, had one deliberate hole since early June 2005. When
your local change was to remove a path (and optionally to stage that
removal), the command checked out the path from the switched-to commit
nevertheless.
This was to allow an initial checkout to happen smoothly (e.g. an initial
checkout is done by starting with an empty index and switching from the
commit at the HEAD to the same commit). We can tighten the rule slightly
to allow this special case to pass, without losing sight of removal
explicitly done by the user, by noticing if the index is truly empty when
the operation begins.
For historical background, see:
http://thread.gmane.org/gmane.comp.version-control.git/4641/focus=4646
This case is marked as *0* in the message, which both Linus and I said "it
feels somewhat wrong but otherwise we cannot start from an empty index".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jonathan Nieder