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...@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
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
