Re: git commit/push and VC

[Yuri Khan <yuri.v.khan@gmail.com>]

On Thu, Nov 20, 2014 at 5:36 AM, Stephen Berman <stephen.berman@gmx.net> wrote:

> GitForEmacsDevs says this:
>
>    If you are a committer, you can merge to the upstream master directly.
>
>    First, update your repository:
>
>          cd $DEVHOME/emacs
>          git checkout master
>          git pull
>          git merge TASKNAME
>          git push
>
>    Run the tests:
>
>          make check
>
>    and then commit
>
>          git status
>          git commit -m "fixes debbugs:12345"
>
>    which merges all your new commits to the upstream master.
>
> I don't understand why `git commit' follows `git push' here (or why
> there isn't another `git push' after `git commit').

Indeed, the instruction quoted above is strange.

Strangeness 1: It assumes that your local master branch has not
diverged from remote master, so “git pull” is a fast-forward. (If this
assumption is incorrect, “git pull” will optionally require you to
resolve merge conflicts, and will introduce a superfluous merge
commit.)

There are two cases how your local master can diverge from remote master:

a. You have some local development going on in local master, unrelated
to TASKNAME. (In a feature-branch-oriented workflow, it should not
happen.)
b. Someone has rewritten the remote history. (By the talks about the
receive.denyNonFastForwards setting on the Emacs central repository
earlier on this list, it looks like the maintainers have decided to
disallow such rewriting.)

Strangeness 2: It suggests to push before running tests.

Presumably, tests exist so that you can check that your work has not
broken anything before sharing it with the world. In that case, you
want to run them before pushing.

Strangeness 3: It tells you to commit after you have just merged and pushed.

Assuming “make check” does not have any effect on the tracked files,
there are no changes that could be committed at this point.

The -m "fixes debbugs:12345" is supposed to go into the commit
message, but there won’t be any commit. Presumably, this line should
go into the message of the merge commit made by “git merge TASKNAME”.

If that merge generates conflicts, you can edit the merge commit
message when committing the merge after having resolved the conflicts.
However, if no conflicts arise, “git merge” will commit the merge
automatically.

To add to the merge commit message, you can either run git merge with
the --no-commit flag and commit manually afterwards, or, immediately
after git merge finishes, you can run git commit --amend.