Re: git patch

[Johannes Schindelin]

Hi,

On Tue, 5 Dec 2006, Graham Percival wrote:

> Johannes Schindelin wrote:
> > Hi,
> > 
> > On Tue, 5 Dec 2006, Graham Percival wrote:
> > 
> > > I'm reluctant to post to the git mailing list because I'm completely
> > > willing
> > > to admit that this is probably a stupid luser problem.  I never seriously
> > 
> > I would like to post your mail (anonymized, of course) to the git list. 
> 
> OK, I just sent it.  (I'm not concerned about not looking like an idiot, 
> but thanks.  :)

I already saw it. This will give some of them something to think about... 
You made a good case.

> > > Trying really trivial in-index merge...
> > > Documentation/user/advanced-notation.itely: needs merge
> > > fatal: you need to resolve your current index first
> > 
> > This is really obscure, you're right. What Git means:
> > advanced-notation.itely was not committed yet.
> 
> Eh?  advanced-notation.itely has been in the tree for over a year!  ... 
> oh wait, this is a cvs/git translation thing, right?  AFAIK, 
> "committing" means "uploading my changes so other people can get them".

Probably. To commit means something akin to the original meaning of the 
English word "to commit": if you commit to something, you want to say that 
you think this is good.

In Git, where the repository is in a subdirectory of the working 
directory, to commit means to make a new revision.

_If_ you want to push that revision (and possibly some ancestors) to a 
public place is totally your decision.

So yes, pushing without committing does not make much sense. But 
committing without pushing does! Sometimes you want to keep something to 
yourself. Or just wait until you are really, really sure.

> > With Git, branches really are a serious tool. Even if Mats and you 
> > thought you were working on the same branch, you really were not! Just 
> > by using git, you already had your own private branch.
> > 
> > So, before trying to merge your work with Mats' work, you _have_ to 
> > commit your changes! This was impossible with CVS, since CVS basically 
> > allows only linear development and makes anything else _hard_.
> > 
> > So, first commit your changes, _then_ merge other's work.
> 
> I'm pretty certain that I committed all my changes, though... I remember 
> doing "git commit Documentation/user/advanced.itely".  When I do "gitk", 
> I can see all my changes.  I just can't see any changes that happed 
> after I did my initial checkout.

Okay, we come to that later.

> How do I tell git "ignore whatever you think I've done to .gitignore. 
> Just go online and give me the most recent version" ?  :)

If you still want that -- after my explanation of your "git status" 
output -- I will tell you.

> > Again, you can just commit it (if it is not already in the repository, you
> > will need to add it with "git add .gitignore"), and _then_ merge your work.
> 
> tsubasa:~/usr/src/lilypond gperciva$ git status
> # Updated but not checked in:
> #   (will commit)
> #
> #       modified:   .gitignore
> #       modified:   Documentation/topdocs/NEWS.tely
> #       modified:   Documentation/user/advanced-notation.itely
> #       modified:   Documentation/user/basic-notation.itely
> #       modified:   Documentation/user/spacing.itely
> #       modified:   GNUmakefile.in
> #       modified:   SConstruct
> #       modified:   THANKS
> ...

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.

But it could be that they are not trivial. In this case, you have either

- modified the files yourself (by editing, or applying a patch), or
- git did something really weird.

> I changed advanced-notation.itely, but everything else was done by other 
> people (mainly Han-Wen).  I want to get their changes.  Is that what 
> "modified" means?  I thought it meant that _I_ had changed a file.

Modified means: the file in the working directory does not match what is 
in the "HEAD" revision.

It could be a lot of things. If you are on a permission-challenged 
filesystem (such as FAT, which cannot tell fish^H^H^H^Hexecutable files 
from non-executables), there is a problem. Git views permission changes as 
trackable changes, too.

> > I try to translate:
> > 
> > $ git clone blah blah
> > $ while (true) {
> > $    git pull          # get latest changes; you must have a clean working 
> > dir
> > $    vi foo/bar/baz.txt
> > $    make; make web
> > $    git commit -a # you will be prompted for a meaningful message
> > $ # alternatively: git commit foo/bar/baz.txt
> > $ }
> 
> Ok.  I think I'll delete my current ~/usr/src/lilypond and start again 
> > from scratch.

I hope you don't need to.

The nice thing for me about Git: you never lose anything. Unless you say 
"git prune" (in which case you really should know what you are doing), you 
do not lose (committed) data.

Now, I promised to tell you what to do if all the files seem modified. Did 
you look through "git -p diff"? (BTW with recent Git you only need "git 
diff" and it will pipe the result into your pager automatically.)

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?

$ git reset --hard

What does this command do? I really actively loses all your _uncommitted_ 
changes. It is equivalent to "cvs update -C". Really undo all my changes. 
I don't care. Just do it.

That is what "git reset --hard" does. The "--hard" means "yes, not only 
the staging area. Also the working directory. I want it. Do it."

Hth,
Dscho