Re: git-checkout sometimes silently fails

[Andrew Morton <akpm@linux-foundation.org>]

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.