Re: git-checkout sometimes silently fails

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2008.05.06 17:54:42 -0700, Andrew Morton wrote:
> On Tue, 6 May 2008 20:19:19 -0400 Jeff King <peff@peff.net> wrote:
> 
> > On Tue, May 06, 2008 at 05:10:52PM -0700, Andrew Morton wrote:
> > 
> > > > > y:/usr/src/git26> git-checkout master
> > > > > Switched to branch "master"
> > > > > y:/usr/src/git26> cat kernel/*.c|sum
> > > > > 34439  2057
> > > > > y:/usr/src/git26> git-checkout linux-next
> > > > > Switched to branch "linux-next"
> > > > > y:/usr/src/git26> cat kernel/*.c|sum     
> > > > > 34439  2057
> > > > 
> > > > This is not a good indication of a failed checkout (they could point
> > > > to the same commit, for one).
> > > 
> > > How could they?  linux-next includes a directory called ./Next and a file
> > > in that directory called ./Next/Trees, and that is not present after the
> > > `git-checkout linux-next'.
> > 
> > But you don't show us that in your example. There is nothing in your
> > example to indicate that they are not simply pointing at the same
> > commit...
> > 
> > > > Try "gitk master...linux-next" (or "git
> > > > log master..linux-next", "git diff master linux-next")
> > > 
> > > These come up empty.  But there is a 12.4MB diff between mainline and
> > > linux-next.
> > 
> > And if these all come up empty, then they _are_ pointing to the same
> > commit. When you say "but there is a 12.4MB diff..." do you mean "there
> > _should_ be such a diff?" In that case, it seems that your linux-next
> > ref is pointing to an unexpected commit.
> > 
> > So the problem is not with git-checkout, but rather that you are not
> > checking out what you think you are checking out.
> 
> That sounds a decent theory.
> 
> > And so we need to
> > figure out how you got into that state.
> 
> Well it happens pretty regularly.  I have now lost that state but I'll save
> it next time.  I'm not able to pinpoint exactly what causes it to occur.
> 
> > What command did you use to create the linux-next branch?
> 
> I edited 
> 
> y:/usr/src/git26> cat .git/branches/linux-next 
> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> 
> and did git-fetch once per day, approx.
> 
> > Have you used
> > git-reset to move the branch tip around?
> 
> My git-fetching script does that:
> 
> doit()
> {
> 	tree=$1
> 	upstream=$2
> 
> 	cd $GIT_TREE
> 	git reset --hard "$upstream"
> 	git fetch "$tree" || exit 1
> 	git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null
> 
> 	{
> 		git_header "$tree"
> 		git log --no-merges ORIG_HEAD..FETCH_HEAD
> 		git diff --patch-with-stat ORIG_HEAD
> 	} >$PULL/$tree.patch
> 	{
> 		echo DESC
> 		echo $tree.patch
> 		echo EDESC
> 		git_header "$tree"
> 		git log --no-merges ORIG_HEAD..FETCH_HEAD
> 	} >$PULL/$tree.txt
> 	git reset --hard "$upstream"
> }
> 
> (Linus suggested an updated version of this but afaict that won't change
> anything)
> 
> But, as I say, usually this script leaves the tree in a sane state.  But
> sometimes it leaves it in a i-cant-check-stuff-out state.  It's not
> specific to linux-next, either: I've seen this for a long time, on and off.
> Prior to linux-next's existence.

Hm, that very much looks like it would mess things up whenever you're
not on the upstream branch already.

While this should do no harm:
git checkout master
doit linux-next master

This will make your linux-next branch point to the same commit as
master:
git checkout linux-next
doit linux-next master

Adding a '"git checkout "$upstream"' (maybe with -f?) before the first
reset --hard should avoid that then.

Björn