git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git-checkout sometimes silently fails

From
Björn Steinbrink <b.steinbrink@gmx.de>
Date
May 7, 2008, 01:32 UTC
Message-ID
<20080507013240.GA13661@atjola.homenet>
In-Reply-To
<20080506175442.845ca8fa.akpm@linux-foundation.org>
On 2008.05.06 17:54:42 -0700, Andrew Morton wrote:
Show 92 quoted lines
> 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
Previous: Andrew MortonNext: Johannes Sixt
Message 9 of 10 in “git-checkout sometimes silently fails”
  1. Andrew MortonMay 6, 2008
  2. Alex RiesenMay 6, 2008
  3. Andrew MortonMay 7, 2008
  4. Junio C HamanoMay 7, 2008
  5. Andrew MortonMay 7, 2008
  6. J. Bruce FieldsMay 7, 2008
  7. Jeff KingMay 7, 2008
  8. Andrew MortonMay 7, 2008
  9. Björn SteinbrinkMay 7, 2008
  10. Johannes SixtMay 7, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.