Re: VC mode and git

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 08 Apr 2015 09:05:05 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  >>     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.
>  >
>  > In the new version, "git diff" is no longer mentioned,
> 
> Hmm...  I still see
> 
>    We recommend invoking git status and git diff to view the changes
>    which will be committed, before invoking git commit -a.

Yes, but in that place it's TRT.  This is only suggested before the
commit, with the explicit purpose of showing what's changed and what
will be committed, so why do we have to explain how the output after
the commit is going to be different?

>  > and "git
>  > status" was never mentioned before, so do you still think we need to
>  > say something about that?
> 
> Maybe it's only me.  git adopts a principle epitomized by, for example,
> 
>     Typically you would want comparison with the latest commit, so if you
>     do not give <commit>, it defaults to HEAD.
> 
> which is completely unintuitive IMO.  Why should the output of two "git
> diff"s differ just because I committed something in between?

We no longer suggest using diff except _before_ a commit, precisely
because of this issue.

>  > But the full text says this:
>  >
>  >    This merge could fail due to conflicts between your changes and
>  >    changes by others in the same portions of the same files. The
>  >    conflicts could be in changes you have already committed locally, or
>  >    in uncommitted changes.
>  >
>  > The second sentence refers to uncommitted changes.  Is it really
>  > important to tell that in this case Git will not even start a merge?
>  > How will that help the reader/user when they are in this situation?
> 
> Agreed.  One nitpick still:
> 
>    Now you have conflicts due to local committed changes, described below.
> 
> I would say
> 
>    Now you may have conflicts due to local committed changes, described below.
> 
> instead.

Done.