Re: [MIT-Scheme-devel] git pull is failing again

[Matt Birkholz]

> From: Taylor R Campbell <address@hidden>
> Date: Fri, 21 Aug 2009 11:30:34 -0400
> 
> Now `git pull' is failing very badly in my work repository:
> 
> % git pull
> remote: Counting objects: 2966, done.
> remote: Compressing objects: 100% (108/108), done.
> remote: Total 1580 (delta 1476), reused 1568 (delta 1468)
> Receiving objects: 100% (1580/1580), 404.93 KiB | 647 KiB/s, done.
> Resolving deltas: 100% (1476/1476), completed with 1321 local objects.
> >From ssh://git.sv.gnu.org/srv/git/mit-scheme
>  + 8acc2b0...a996c47 HEAD       -> origin/HEAD  (forced update)
> error: Ref refs/remotes/origin/master is at a996c47f0b70804af9c42cc25b63a14=
> 460f56283 but expected 8acc2b030731d65913522fd3d63e18aacd1f20d0

8acc2b0 is Chris's commit on the 17th.  I am surprised (as is git!)
that your refs/remotes/origin/master is a996c47 and not 8acc2b0.

a996c47 is:

        $ git log -1 a996c47
        commit a996c47f0b70804af9c42cc25b63a14460f56283
        Author: Chris Hanson <org/chris-hanson/cph>
        Date:   Sat May 9 16:21:16 2009 -0700

            Fix thinko.

This is where the website says HEAD is at.  See:

        http://git.savannah.gnu.org/cgit/mit-scheme.git/

I have often wondered why the website reports master's last commit as
e.g. 39 hours old, while HEAD is 3 MONTHS old.  I cannot find any
other refs on a996c47.

I think our HEAD has become detached at the repo.

>  ! 8acc2b0..a617168  master     -> origin/master  (unable to update local ref)

a617168 is my most recent commit.  I suppose 8acc2b0..a617168 means
the changesets for the last two commits are being sent.  They probably
cannot update the local ref because it (refs/remotes/origin/master) is
at a996c47 (detached HEAD) and not 8acc2b0 (master).  ?

> If I repeat `git pull', it gives a different error:
> 
> % git pull         =20
> >From ssh://git.sv.gnu.org/srv/git/mit-scheme
>    a996c47..a617168  master     -> origin/master
> Updating 944e600..a617168
> error: Entry 'src/microcode/object.h' not uptodate. Cannot merge.

This time your origin/HEAD and origin/master are the same?  You
fetched the whole chain from a996c47 (detached-HEAD) to a617168
(master) and were able to update your refs/remotes/origin/master
chain.  But you could not merge because your working directory tree
was not clean.

> [...] thinking that `git pull' might behave like `cvs update' and
> revert the files to their current state. That didn't work, so now my
> repository is unhappy and I'm missing those files.

git-pull is git-fetch,git-merge.  git-checkout is what you want to
restore files from the repo.

> I guessed that `git revert' might revert those files for me, but
> apparently it doesn't.

Whoa.  git-revert mucks with the commit chain -- changes your HEAD.
Is it detached now?

> The man page for `git reset' seemed to indicate that it would do
> what I want, namely `Sets the current head to the specified commit
> and optionally resets the working tree to match.', but:
> 
> % git reset src/microcode/bkpt.h
> fatal: ambiguous argument 'src/microcode/bkpt.h': unknown revision or path =
> not in the working tree.
> Use '--' to separate paths from revisions
> % git reset -- src/microcode/bkpt.h=20

I think you are just frobbing the index there.  From the git-reset
manpage:

       The second form with paths is used to revert selected paths in the
       index from a given commit, without moving HEAD.

That would remove changes from the index, replacing the file (in the
index) with a copy from a specified commit.

> Of these files, only mit-syntax.scm and sysmac.scm have changes that I
> care about.  The others either don't exist (the first four) or have
> $Id$ differences.

For the nonexistent and undesirable diffs, I recommend this
incantation:

        $ git checkout master -- <problem files>

> And after running `git reset', src/microcode/bkpt.h didn't do a
> better job of existing than before.

I bet a copy from HEAD is in the index.  Note that "git diff" and "git
diff --cached" compare working to index, and index to repo,
respectively.

> I probably ought not to have deleted some of the files, but surely
> it is not an uncommon task to want to revert a few particular files
> in the working directory -- how can I do this?

git-checkout, maybe git-reset --hard -- <files>.

Just keep your HEAD, or specify master.

I try to keep out of trouble with

        git pull origin master

instead of

        git pull

> Or does the first error that `git pull' threw at me indicate that my
> repository is irreparably screwed?

It is not YOUR repository that is screwed.  Look at the cgit webpage
again and you will see what I mean...