On Tue, 6 May 2008 20:19:19 -0400 Jeff King <peff@xxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
