This allows "git checkout -m <other-branch>" to notice renames and
carry local changes in the working tree forward.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This converts scripts that do "cd $(rev-parse --show-cdup)" by
hand to use cd_to_toplevel.
I think git-fetch does not have to go to the toplevel, but that
should be dealt with in a separate patch.
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>
When switching branches, we usually first try read-tree to make
sure that we do not lose the local changes and then updated the
HEAD using update-ref. However, we detached and updated HEAD
before these checks, which was quite bad in a repository with
local changes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Checking for reachability from refs does not help much if the
state we are currently on is somewhere in the middle. We will
lose where we were.
So this makes sureh that HEAD is something directly pointed at
by one of the existing refs (most likely a tag for a user who
has been "sightseeing").
Signed-off-by: Junio C Hamano <junkio@cox.net>
When switching branches with "git checkout", we internally did $arg^0
(aka $arg^{commit}) suffix but there was no need to.
The improvement is easily visible in the change to an existing
test t/3200-branch.sh in this commit; it was expecting rather
ugly message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
After making commits in the detached HEAD state, if you run "git
checkout" to switch to an existing branch, you will lose your
work. Make sure the switched-to branch is a fast-forward of the
current HEAD, or require -f when switching.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to say "you are not on a branch" before the initial
commit. This is incorrect -- the user is on a branch yet to be
born, but its name has been already determined.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows "git checkout v1.4.3" to dissociate the HEAD of
repository from any branch. After this point, "git branch"
starts reporting that you are not on any branch. You can go
back to an existing branch by saying "git checkout master", for
example.
This is still experimental. While I think it makes sense to
allow commits on top of detached HEAD, it is rather dangerous
unless you are careful in the current form. Next "git checkout
master" will obviously lose what you have done, so we might want
to require "git checkout -f" out of a detached HEAD if we find
that the HEAD commit is not an ancestor of any other branches.
There is no such safety valve implemented right now.
On the other hand, the reason the user did not start the ad-hoc
work on a new branch with "git checkout -b" was probably because
the work was of a throw-away nature, so the convenience of not
having that safety valve might be even better. The user, after
accumulating some commits on top of a detached HEAD, can always
create a new branch with "git checkout -b" not to lose useful
work done while the HEAD was detached.
We'll see.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This uses the previous update to read-tree in Porcelain-ish
commands "git checkout" and "git merge" to loosen the check
when switching branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is often wanted on the #git channel that this were to work to
recover removed directory:
rm -fr Documentation
git checkout -- Documentation
git checkout HEAD -- Documentation ;# alternatively
Now it does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I've seen some users get into situtations where their HEAD
symbolic-ref is pointing at a non-existant ref. (Sometimes this
happens during clone when the remote repository lacks a 'master'
branch.) If this happens the user is unable to use git-checkout
to switch branches as there is no prior commit to merge from.
So instead of giving the user low-level errors about how HEAD
can't be resolved and how not a single revision was given change
the type of checkout to be a force and go through with the user's
request anyway.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This actually "turns on" the packed ref file format, now that the
infrastructure to do so sanely exists (ie notably the change to make the
reference reading logic take refnames rather than pathnames to the loose
objects that no longer necessarily even exist).
In particular, when the ref lookup hits a refname that has no loose file
associated with it, it falls back on the packed-ref information. Also, the
ref-locking code, while still using a loose file for the locking itself
(and _creating_ a loose file for the new ref) no longer requires that the
old ref be in such an unpacked state.
Finally, this does a minimal hack to git-checkout.sh to rather than check
the ref-file directly, do a "git-rev-parse" on the "heads/$refname".
That's not really wonderful - we should rather really have a special
routine to verify the names as proper branch head names, but it is a
workable solution for now.
With this, I can literally do something like
git pack-refs
find .git/refs -type f -print0 | xargs -0 rm -f --
and the end result is a largely working repository (ie I've done two
commits - which creates _one_ unpacked ref file - done things like run
"gitk" and "git log" etc, and it all looks ok).
There are probably things missing, but I'm hoping that the missing things
are now of the "small and obvious" kind, and that somebody else might want
to start looking at this too. Hint hint ;)
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
That way, it doesn't care how the refs are stored any more
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we updated "read-tree -m -u" to be careful about not
removing untracked working tree files, we broke "checkout -m" to
switch between branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier we did not consider untracked working tree files
"precious", but we have always considered them fair game to
clobber. These days, branch switching by read-tree is more
careful and tries to protect untracked working tree files. This
caused the following workflow to stop working:
git checkout one-branch-with-file-F
git checkout -f another-without-file-F
git pull . one-branch-with-file-F
Because the second checkout leaves F from the previous state as
untracked file in the working tree, the merge would fail, trying
to protect F from being clobbered.
This changes "git checkout -f" to remove working tree files that
are known to git in the switched-from state but do not exist in
the switched-to state, borrowing the same logic from "reset --hard".
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user supplies -l to git-branch when creating a new branch
then the new branch's log should be created automatically and the
branch creation should be logged in that log.
Further if a branch is being deleted and it had a log then also
verify that the log was deleted.
Test git-checkout -b foo -l for creating a new branch foo with a
log and checking out that branch.
Fixed git-checkout -b foo -l as the branch variable name was
incorrect in the script.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Switch git checkout -b to use git-update-ref rather than echo and
a shell I/O redirection. This is more in line with typical GIT
commands and allows -b to be logged according to the normal ref
logging rules.
Added -l option to allow users to create the ref log at the same
time as creating a branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
After doing an in-index 3-way merge, we always do the stock
"merge-index merge-one-file" without doing anything fancy;
use of --aggressive helps performance quite a bit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
After doing an in-index 3-way merge, we always do the stock
"merge-index merge-one-file" without doing anything fancy;
use of --aggressive helps performance quite a bit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we refused to switch branches, we incorrectly showed
differences from the branch we would have switched to.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, when we switched a branch we used diff-files to show
paths that are dirty in the working tree. But we allow switching
branches with updated index ("read-tree -m -u $old $new" works that
way), and only showing paths that have differences in the working
tree but not paths that are different in index was confusing.
This shows both as modified from the top commit of the branch we
just have switched to.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This shows your working file state when you switch branches. As
a side effect, "git checkout" without any branch name (i.e. stay
on the current branch) becomes a more concise shorthand for the
"git status" command.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* Instead of going interactive, introduce a command line switch
'-m' to allow merging changes when normal two-way merge by
read-tree prevents branch switching.
* Leave the unmerged stages intact if automerge fails, but
reset index entries of cleanly merged paths to that of the
new branch, so that "git diff" (not "git diff HEAD") would
show the local modifications.
* Swap the order of trees in read-tree three-way merge used in
the fallback, so that `git diff` to show the conflicts become
more natural.
* Describe the new option and give more examples in the documentation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When switching branches, if the working tree has a local
modification at paths that are different between current and new
branches, we refused the operation saying "cannot merge." This
attempts to do an automerge for such paths.
This is still experimental.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-checkout does two very different things, and what they
should do when run from subdirectory are quite different.
It does not make any sense to run the one that switches the
current head from anywhere other than the toplevel:
git-checkout [-f] <branch>
git-checkout [-b <branch>] <committish>
We could of course chdir to top and do the whole-tree checkout
in git-checkout, but the point is the operation does not make
sense on a partial tree. The whole tree is checked out.
The other form is to update the index file and working tree file
selectively:
git-checkout <treeish> <file>... ;# out of tree to index and file
git-checkout -- <file>... ;# out of index to file
This form _does_ make sense to run from subdirectory; and I
myself often wish we supported this.
So here is a patch to do both.
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>
git-update-index --index-info can almost be usable to read from ls-tree
output to update the index (and not the working tree file) to HEAD commit,
but not quite. It was designed to read from git-apply --index-info
output, and does not want " blob " in ls-tree output. Accept that as well.
This lets us update "git-checkout <ent> <path>" that used to filter the
extra " blob " string out. Noted by Luben.
Signed-off-by: Junio C Hamano <junkio@cox.net>
"git-checkout -b frotz/nitfol master" failed to create
$GIT_DIR/refs/heads/frotz/nitfol but went ahead and updated
$GIT_DIR/HEAD to point at it, resulting in a corrupt repository.
Exit when we cannot create the new branch with an error status.
While we are at it, there is no reason to forbid subdirectories
in refs/heads, so make sure we handle that correctly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When extra paths arguments are given, git-checkout reverts only those
paths to either the version recorded in the index or the version
recorded in the given tree-ish.
This has been on the TODO list for quite a while.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update check_ref_format() function to reject ref names that:
* has a path component that begins with a ".", or
* has a double dots "..", or
* has ASCII control character, "~", "^", ":" or SP, anywhere, or
* ends with a "/".
Use it in 'git-checkout -b', 'git-branch', and 'git-tag' to make sure
that newly created refs are well-formed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update check_ref_format() function to reject ref names that:
* has a path component that begins with a ".", or
* has a double dots "..", or
* has ASCII control character, "~", "^", ":" or SP, anywhere, or
* ends with a "/".
Use it in 'git-checkout -b', 'git-branch', and 'git-tag' to make sure
that newly created refs are well-formed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the counterpart of git-update-ref that lets you read
and create "symbolic refs". By default it uses a symbolic link
to represent ".git/HEAD -> refs/heads/master", but it can be compiled
to use the textfile symbolic ref.
The places that did 'readlink .git/HEAD' and 'ln -s refs/heads/blah
.git/HEAD' have been converted to use new git-symbolic-ref command, so
that they can deal with either implementation.
Signed-off-by: Junio C Hamano <junio@twinsun.com>
The target to check out does not need to be a branch. The _result_ of the
checkout needs to be a branch. Don't confuse the two, and then insult the
user.
Insulting is ok, but I personally get really pissed off is a tool is both
confused and insulting. At least be _correct_ and insulting.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you make a commit on a path, and then make the path
cache-dirty afterwards without changing its contents, 'git
checkout' to switch to another branch is prevented because
switching the branches done with 'read-tree -m -u $current
$next' detects that the path is cache-dirty, but it does not
bother noticing that the contents of the path has not been
actualy changed.
Since switching branches would involve checking out paths
different in the two branches, hence it is reasonably expensive
operation, we can afford to run update-index before running
read-tree to reduce this kind of false change from triggering
the check needlessly.
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>
Sometimes the git-read-tree in git-checkout-script fails for me.
Make sure that the failed status is passed up to caller.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch changes rev-parse users that pass a single argument
that is supposed to be a rev parameter to use "--verify".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In particular, if we check out something that isn't an old branch, it
now requires a new branch-name to check the thing out into.
So, for example:
git checkout -b my-branch v2.6.12
will create the new branch "my-branch", and start it at v2.6.12, while
git checkout master
will just switch back to the master branch.
Of course, if you want to create a new branch "my-branch" and _not_
check it out, you could have done so with just
git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch
which I think I will codify as "git branch".
We still need to create a new branch if it didn't refer to an existing
branch, otherwise our HEAD will continue to point to something totally
different than what we just checked out.
I'll need to think about it. Maybe only do it with "-f" and force it to
the "master" branch?
Junio C Hamano