LemuriaHow do you reword messages of commits that have been pushed to remotes (in this case GitHub)? Do I simply perform an interactive rebase operation on the commits and simply push?
threads / discuss / 57135
Rebasing commits that have been pushed to remote
Subject: Rebasing commits that have been pushed to remote
Lemuria
Junio C HamanoRe: Rebasing commits that have been pushed to remote
Lemuria <nekadek457@gmail.com> writes:
> How do you reword messages of commits that have been pushed to remotes > (in this case GitHub)? Do I simply perform an interactive rebase > operation on the commits and simply push?
It is up to each project if it is an acceptable practice to rewind-and-rebuild a branch that has already been published, but if the projects participants are OK with it, then "'rebase -i' and 'push -f'" is how you would do it.
LemuriaRe: Rebasing commits that have been pushed to remote
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.
The project in question is a public project of mine, and I'm the only person actively working on it, so I guess rewinding and rebuilding is acceptable per my standards.
But at least my GitHub page has more green on it!
And I definitely will rebase -i and push -f next time I need to rewrite some remote history. -----------------------------------------------------------------------
On 23/12/2021 3:34 am, Junio C Hamano wrote:
Show 11 quoted lines
> Lemuria <nekadek457@gmail.com> writes: > >> How do you reword messages of commits that have been pushed to remotes >> (in this case GitHub)? Do I simply perform an interactive rebase >> operation on the commits and simply push? > > It is up to each project if it is an acceptable practice to > rewind-and-rebuild a branch that has already been published, but > if the projects participants are OK with it, then "'rebase -i' > and 'push -f'" is how you would do it. >
Re: Rebasing commits that have been pushed to remote
> 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
> But at least my GitHub page has more green on it!
If you want green you can fork https://github.com/cervEdin/vanity
LemuriaRe: Rebasing commits that have been pushed to remote
On 26/12/2021 4:44 pm, Erik Cervin Edin wrote:
Show 15 quoted lines
>> 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.
Show 6 quoted lines
> >> 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?
rsbecker@nexbridge.comRE: Rebasing commits that have been pushed to remote
On December 26, 2021 4:58 AM, Lemuria wrote:
Show 18 quoted lines
> 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.
Show 9 quoted lines
> > > >> 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
LemuriaRe: Rebasing commits that have been pushed to remote
On 26/12/2021 11:49 pm, rsbecker@nexbridge.com wrote:
Show 36 quoted lines
> 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___.