Re: Gitlab workflow

12 Jul 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
:
...
[...] 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