Re: git patch

[Johannes Schindelin]

Hi,

On Wed, 6 Dec 2006, Graham Percival wrote:

> Johannes Schindelin wrote:
> > Hi,
> > 
> > On Tue, 5 Dec 2006, Graham Percival wrote:
> > 
> > > # Updated but not checked in:
> > > #   (will commit)
> > > #
> > > #       modified:   .gitignore
> > > #       modified:   Documentation/topdocs/NEWS.tely
> > > ...
> > 
> > This means that you do have modifications in those files. Could you please
> > try a
> > 
> > $ git -p diff HEAD
> > 
> > to see what are the modifications? If they are trivial, you might want to
> > undo them.
> 
> I get a 54k diff file (when redirected to a file) that has a huge number of
> valid-looking patches.  I mean, it's not some kind of weird binary vs. ascii
> file transfer thing, nor missing files.

Just a guess: at some stage, you said "git read-tree"?

> Now the question is "did git do something really weird?", or "did I make 
> git do something really weird?"

I am a little worried that it _could_ be Git doing something weird (which 
I only missed because I use another workflow).

I am even more worried that this happens to new users all over this 
planet, and they turn away from an otherwise good system.

> But I'm starting to think that I should just reset git and try using it 
> sensibly for a while -- particularly since I can't remember everything I 
> did to git in order to get to this state.

You are probably right. By investigating your bash history and the 
repository, quite possibly one could reconstruct it, but better get _you_ 
started.

I also suggest to run

$ git repo-config core.logAllRefUpdates true

This turns on logging into .git/logs/<ref> for all updates on the refs 
(branches and tags) in your repository. It also lets you say

$ git show address@hidden

To know what was the state of _your_ master branch one week ago. Of 
course, you have to had logAllRefUpdates enabled already one week ago...

I think this is a such a useful thing that I push to make it the default.

> > So, you still want to undo the modifications, either because they are not
> > important, or you don't know where they came from and they don't make sense,
> > or they are permission changes you did not want in the first place?
> 
> I'm waiting for you to tell me.  :)   They're not mine, they're good patches,
> and I'm sure they exist in the main branch.  Here's an example:
> 
> diff --git a/VERSION b/VERSION
> index 36a6a28..f78e473 100644
> --- a/VERSION
> +++ b/VERSION
> @@ -1,6 +1,6 @@
>  PACKAGE_NAME=LilyPond
>  MAJOR_VERSION=2
>  MINOR_VERSION=11
> -PATCH_LEVEL=0
> +PATCH_LEVEL=1
>  MY_PATCH_LEVEL=
> 
> 
> I'm certain that patch happened after I checked the files out -- and I'm
> certain it was made by Han-Wen, not me.

I suspect that you somehow succeeded in updating the working directory 
without actually merging.

> So, do we do more debugging, or do I
> > $ git reset --hard

If you promise to ask again as soon as you have problems, you may do the 
reset ;-)

And remember: "git status" and "git diff" are your friends. For the 
moment, we lack better tools to tell what is wrong, but we are at work!

Ciao,
Dscho