Gitlab workflow

Fri Jul 12 14:55:25 UTC 2019

This thread has helped my shift some of my perceptions, but,

On 7/11/19 6:49 PM, Sven Panne wrote:

 > Am Do., 11. Juli 2019 um 14:32 Uhr schrieb Bryan Richter
 > <b at chreekat.net>:
 >
 > > [...] When references to commits (in emails etc.) get invalidated,
 > > it adds confusion and extra work. Seeing this happen is what led
 > > me to wonder why people even prefer this strategy.
 >
 >
 > I think there is a misunderstanding here: You never ever force-push
 > rebased commits to a public repo, this would indeed change commit
 > hashes and annoy all your collaborators like hell.

This current thread started precisely because history was rewritten
and GitLab could not ascertain that a merge had happened. :)

Even if GitLab develops a feature that synchronizes these upstream
rebases with the relevant merge request, the problem will still remain
in downstream repositories. The source branch of a rebased merge
request always ends up orphaned on forks and local repositories.

I see why people might make that trade-off, however. And I see that
`git cherry` specifically considers this workflow:

     Determine whether there are commits in <head>..<upstream> that are
     equivalent to those in the range <limit>..<head>.

     The equivalence test is based on the diff, after removing
     whitespace and line numbers. git-cherry therefore detects when
     commits have been "copied" by means of git-cherry-pick(1),
     git-am(1) or git-rebase(1).

     - git-cherry(1)

-Bryan