Re: git-checkout sometimes silently fails
- From
- Andrew Morton <akpm@linux-foundation.org>
- Date
- May 7, 2008, 00:54 UTC
- Message-ID
- <20080506175442.845ca8fa.akpm@linux-foundation.org>
- In-Reply-To
- <20080507001919.GA8633@sigill.intra.peff.net>
On Tue, 6 May 2008 20:19:19 -0400 Jeff King <peff@peff.net> wrote:
Show 35 quoted lines
> 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=$2cd $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.