Implement merges and vcs-revert for git

[Stéphane Bidoul (Acsone)]

Title says it all.

[Georges Racinet (gracinet)]

Thanks for working on this. This'll allow partial automation of derivated works such as OCB with buildout and a CI bot.

[Georges Racinet (gracinet)]

Someone suggested to me that it'd be interesting to perform a rebase, so that the merged branch commits always seem to be on top.

I'm not (yet) knowledgeable enough about Git to assert whether that's a good idea or not.

In Mercurial, that would certainly depend if the merge is meant to be committed and pushed (derivative version use-case) or not. If pushed, it's there to stay, and therefore a subsequent execution would give rise to problems (best-cases scenario: totally defeat the idea of rebasing by actually repeating the changesets)

Maybe should-we add an option for that later ?

[Stéphane Bidoul (Acsone) (sbi)]

So far I had not thought of scenarios where the result of buildout merge-ins would be pushed. Must think about it.

[Georges Racinet (gracinet)]

I did some experiments this evening with git rebase (merely to teach myself what it really does).
For the 'derivative' use-case (merge with push, similar to ocb merging from odoo), rebase would not work.
For the 'apply-patch' use-case, rebase would work but would require prior revert (reset --hard origin/master, actually)

PS: I think your implementation of revert() lacks the origin/ prefix, since the intent is indeed to revert to the remote commit.
In bzr and hg, there's no distinction after pull of remote and local heads, but merges are local modifications, whereas in git a merge is a commit and makes a difference between origin/master and master (if not pushed)

[Stéphane Bidoul (Acsone) (sbi)]

Regarding rebase, I agree. So far I believe it's better with a simple merge as default behaviour.

Regarding revert, I noticed that too. rev 530 should be ok (and there is a test for that).

[Georges Racinet (gracinet)]

great !

We'll think about rebase later (still an interesting idea to keep around)

About revert, I'm realizing that while resetting to origin/master is the wished behaviour for the two use-cases of the merges-in feature, it's really dangerous for other cases, since it would drop unpushed original changesets (so far the only use-case for revert is to redo a merge).

Maybe we could have that method react in different way if triggered via on-merge ? What do you think ?
In any case, we'll have to warn strongly in doc.

[Stéphane Bidoul (Acsone) (sbi)]

I agree revert is a potentially dangerous operations.

Now, if I understand correctly, it is only triggered when using vcs-revert = on-merge, in which case a complete revert including unpushed changes is the desired behaviour.