RE: Rebasing commits that have been pushed to remote

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On December 26, 2021 4:58 AM, Lemuria wrote:
> On 26/12/2021 4:44 pm, Erik Cervin Edin wrote:
> >> Alright. I'll take this into account. Unfortunately, before you got
> >> to me, I reworded the commits on my local and pushed them to the
> >> remote, which resulted in a messy history with duplicate comments.
> >
> > This easily happens
> > Usually when you merge old history back onto rewritten history It's
> > easy to confuse what is what when rewriting history
> >
> > If you find yourself rewriting and force pushing a lot you might find
> > the following script helpful
> > https://gist.github.com/CervEdin/2e72388c3f7d9b30d961ec3b64d08761
> > It shows:
> > - The graphs of differences between local and upstream of a branch
> > - The difference between local and upstream
> > - Prompts to force push with lease
> 
> I don't force push a lot, but regardless I'll make a note of that.

The process is used by some teams, like OpenSSL, for WIP pull requests. It follows a git rebase --autosquash -i. The principle is to clean up the PR down to a single final commit for approval. It is more work for the contributor, but the committers seem to prefer having everything in one commit. This requires a git push -f.

> >
> >> But at least my GitHub page has more green on it!
> >
> > If you want green you can fork
> > https://github.com/cervEdin/vanity
> >
> 
> I'm surprised how GitHub hasn't taken that down yet. Well, spamming
> commits means more green and isn't that good for the environment, right?

I don’t follow this. Sorry.

-Randall




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux