Re: Rebasing commits that have been pushed to remote

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

 





On 26/12/2021 11:49 pm, rsbecker@xxxxxxxxxxxxx wrote:
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


Me too. I don't follow that either. My statement
was sent with the purposes of ___sarcasm___.



[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