Gerrit has an option to “pick” rather than “merge” contributions when they are accepted. We could ask for this option to be enabled
However, for user contributions, given the (awful) performances of Rebase compared to Merge (especially on EGit; not sure about command-line Git), and the additional
set of conflicts this brings (Conflicts need to be solved for each individual commit rather than latest state), I’m not sure it’s a good idea to “enforce” it. We could define rebase as a recommended practice however, for big parallel development branches (Which
are more likely to result in sneaky conflicts).
Camille
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de MAGGI Benoit
Envoyé : vendredi 16 janvier 2015 10:56
À : Papyrus Project list
Objet : [PROVENANCE INTERNET] Re: [mdt-papyrus.dev] [PROVENANCE INTERNET] Re: Lost commit from merged gerrit, how could it happen?
Hi Michael,
It’s indeed coming from a merge commit. (That’s also why you can find the commit in the branch but not in the standard history)
ð
There was discussion in this mailing-list about recommending
rebase against merge. IMHO, we should adopt the rule and enforce it in gerrit (if it’s possible)
(With this rule we will have a linear history, which is a lot easier to read but lose the timing history
So : see when the work is integrated in master vs when the work was really done)
Details for your use case here :
Here is the merge erasing the part of the code you are referencing :
http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=819225bc9d115e1a40fcc106654fcd6088183dce
You can find it with the history view (It’s the 819225b not the highlighted one )

Regards,
Benoit MAGGI
Hi Michael,
That’s indeed very surprising. I suspect a merge commit did override this contribution. And Merge commits don’t really “change” the files by themselves (The
changes are brought by the merged commit rather than the merge commit)
I’ve already seen cases of merge commits erasing a previous contribution silently (i.e. the History doesn’t say anything about a change), although I don’t know
in which case this might happen.
Camille
De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx
[mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Michael Golubev
Envoyé : jeudi 15 janvier 2015 23:24
À : Papyrus Project list
Objet : [mdt-papyrus.dev] Lost commit from merged gerrit, how could it happen?
Hello,
We have found a weird situation with one of the commits from Montages team and I would like to ask for a help.
I have checked and re-checked everything, but still have no idea whats going on and how this could happen.
So, there is a gerrit review #36952 [1] from Dec 8, 2014 8:45 AM, with status Merged.
There is also corresponding commit in git web view [2].
So far so good, now the mistery part:
Here is the actual state [3] of the same file in git web UI, with the change from gerrit not applied.
Note that the actual latest revision for master branch is from commit 7f7c96689f903d784acccd32355f219d223779b2, from Nov 27, 2014, so before the gerrit merge date.
Note also that the git log for the same file [4] does not include the above commit from gerrit (and no December commits at all).
I most probably have missed something trivial but it looks at least disturbing, does not it?
--
![]()
Michael "Borlander" Golubev
Eclipse Committer (GMF, UML2Tools)
at Montages Think Tank, Prague, Czech Republic
1165/1 Dvorecka, 14700, Prague-4 Podoli