* Rebasing commits that have been pushed to remote
@ 2021-12-22 7:55 Lemuria
2021-12-22 19:34 ` Junio C Hamano
0 siblings, 1 reply; 7+ messages in thread
From: Lemuria @ 2021-12-22 7:55 UTC (permalink / raw)
To: git
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Rebasing commits that have been pushed to remote
2021-12-22 7:55 Rebasing commits that have been pushed to remote Lemuria
@ 2021-12-22 19:34 ` Junio C Hamano
2021-12-23 3:11 ` Lemuria
0 siblings, 1 reply; 7+ messages in thread
From: Junio C Hamano @ 2021-12-22 19:34 UTC (permalink / raw)
To: Lemuria; +Cc: git
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Rebasing commits that have been pushed to remote
2021-12-22 19:34 ` Junio C Hamano
@ 2021-12-23 3:11 ` Lemuria
2021-12-26 8:44 ` Erik Cervin Edin
0 siblings, 1 reply; 7+ messages in thread
From: Lemuria @ 2021-12-23 3:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
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:
> 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.
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Rebasing commits that have been pushed to remote
2021-12-23 3:11 ` Lemuria
@ 2021-12-26 8:44 ` Erik Cervin Edin
2021-12-26 9:58 ` Lemuria
0 siblings, 1 reply; 7+ messages in thread
From: Erik Cervin Edin @ 2021-12-26 8:44 UTC (permalink / raw)
To: Lemuria; +Cc: Junio C Hamano, git
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Rebasing commits that have been pushed to remote
2021-12-26 8:44 ` Erik Cervin Edin
@ 2021-12-26 9:58 ` Lemuria
2021-12-26 15:49 ` rsbecker
0 siblings, 1 reply; 7+ messages in thread
From: Lemuria @ 2021-12-26 9:58 UTC (permalink / raw)
To: Erik Cervin Edin; +Cc: Junio C Hamano, git
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.
>
>> 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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: Rebasing commits that have been pushed to remote
2021-12-26 9:58 ` Lemuria
@ 2021-12-26 15:49 ` rsbecker
2021-12-27 2:28 ` Lemuria
0 siblings, 1 reply; 7+ messages in thread
From: rsbecker @ 2021-12-26 15:49 UTC (permalink / raw)
To: 'Lemuria', 'Erik Cervin Edin'
Cc: 'Junio C Hamano', git
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Rebasing commits that have been pushed to remote
2021-12-26 15:49 ` rsbecker
@ 2021-12-27 2:28 ` Lemuria
0 siblings, 0 replies; 7+ messages in thread
From: Lemuria @ 2021-12-27 2:28 UTC (permalink / raw)
To: rsbecker, 'Erik Cervin Edin'; +Cc: 'Junio C Hamano', git
On 26/12/2021 11:49 pm, rsbecker@nexbridge.com 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___.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-12-27 2:28 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-22 7:55 Rebasing commits that have been pushed to remote Lemuria
2021-12-22 19:34 ` Junio C Hamano
2021-12-23 3:11 ` Lemuria
2021-12-26 8:44 ` Erik Cervin Edin
2021-12-26 9:58 ` Lemuria
2021-12-26 15:49 ` rsbecker
2021-12-27 2:28 ` Lemuria
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).