Hi Phillip, Le 2023-01-06 à 09:29, Phillip Wood a écrit : > Hi Philippe & Erik > > On 05/01/2023 00:11, Philippe Blain wrote: >> Hi Phillip and Erik, >> >> Le 2021-12-16 à 11:44, Erik Cervin Edin a écrit : >>> Hi Phillip, >>> >>> Yes, I know. >>> It's just that I was under the impression ORIG_HEAD was to be reverted >>> to .git/rebase-merge/orig-head at the finish of the rebase. >>> Personally, it's the behavior I would expect. >>> >>> Thanks for the tips. >> >> I just hit the same bug (I think it qualifies as one). In fact git-rebase(1) explicitely mentions >> that ORIG_HEAD is set to the branch tip before the rebase starts: > > Strictly speaking that is what we do so we're documentation the > implemented behavior. What's not clear from the documentation is that > if the user run 'git reset' while rebasing then ORIG_HEAD will be > overwritten. Yes, I agree. I think we could highlight it in the doc. > We could update ORIG_HEAD at the end of the rebase as > you suggested but I wouldn't be surprised if some else complains that > ORIG_HEAD no longer points to the commit that the reset while running > rebase. I also wonder if users would expect 'git rebase --continue' > to update ORIG_HEAD to point to the pre-rebase HEAD so it is > consistent each time rebase stops. Basically I think the situation is > confusing and I don't have a clear idea as to how to make it better. > If someone submits a patch to try and clean things up I'll happily > look at it but unless I'm hit by a bright idea as to how to fix it I > probably wont work on it myself. Thanks for your thoughts. I think you make good points, it's true that some people might be relying on the current behaviour. I'll try to send a few updates to the doc to make this hopefully clearer. Cheers, Philippe.
