On 2008.05.06 17:54:42 -0700, Andrew Morton wrote:
> 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.
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
--
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
