Re: VC mode and git

[martin rudalics <rudalics@gmx.at>]

A few further comments on the last version of GitQuickStartForEmacsDevs:

   Optionally, before doing a commit, you can do git status and git diff to
   view the changes which will be committed by git commit -a (with no
   filename arguments).

Couldn't we formulate this in a slightly more appealing way?  Somehow in
the sense of "in order to avoid commiting things you probably do not
want to commit" do a 'git status' which will tell you which files are
affected by the commit or 'git diff' which will give you the details.


   It is a good idea to examine what you are about to push, before
   actually doing so, because fixing mistakes before pushing is much
   easier (see the next section). To do that, use the command git diff
   origin/master. If you want to show your unpushed commits with their
   commit log messages, use git show origin/master.. instead. If you only
   have one local commit you want to push, just git show is enough.

And here I would try to tell that the outputs of plain 'git diff' and
'git status' are different from their outputs before the commit.  When I
noticed that for the first time I was confused.


   To re-do the commit from scratch, use git reset HEAD^, then fix
   whatever needs fixing, and commit again.

Maybe we should reassure readers here that their changes are not lost
when they do that.


   error: Your local changes to the following files would be overwritten by merge:
          file1
   Please, commit your changes or stash them before you can merge.
   Aborting

   To fix this, commit the offending files with

Please tell readers here that git does not even try to check whether
their changes would conflict with changes in the upstream repository.
Otherwise, the cited section will confuse readers who expect conflicts
exclusively due to the earlier ...

   This merge could fail due to conflicts between your changes and
   changes by others in the same portions of the same files.

... in particular the "in the same portions" part.  At least I was
initially stupefied by this when it happened the first time.


   In addition, saving any file whose conflicts were completely resolved
   (i.e., no conflict markers remain in it) invokes the git add command
   on that file, which prepares the file for merging and committing.

Are we really 100% sure that 'git add' gets executed with all reasonable
user customizations?  Shouldn't we tell here how our reader can check
whether the 'git add' was really performed?


    (It is recommended to do a git status before a commit without
    filename arguments to check for inadvertent changes that would be
    committed.)

Doesn't this come now a bit late in the text given you latest changes?

martin