Re: git and the loss of revision numbers

From: Guido Falsi <madpilot_at_FreeBSD.org>
Date: Tue, 29 Dec 2020 19:12:40 +0100
On 29/12/20 18:38, Andriy Gapon wrote:
> On 2020-12-29 17:11, monochrome wrote:
>> ok, this appears to be what I was looking for
>>
>> example:
>> git reset --hard f20c0e331
>> then:
>> git pull --ff-only
>> is again able to update as normal
>>
>> I should point out also that this is from the point of view of any
>> random person just building freebsd from source, not a developer, so
>> there are no local changes. Though it does blow away changes to the conf
>> file, that's a lesser issue to deal with.
> 
> git stash [save] and git stash pop can be used to try[*] to preserve
> minor local changes.
> 
> [*] there can be merge conflicts after stash pop if the same file(s) are
> changed upstream as well.
> 

Anyone who already uses git knows this, probably, but for the sake of 
people who have no experience with it "git stash pop" behaviour can be 
startling(at least, it was for me when I first used it):

after a "git stash pop" which causes conflicts git will set up to 
actaully create a commit in the branch with the resolved conflict, which 
(usually for me) is not what one really wants.

I usually just do "git reset; git stash drop" in this case and then fix 
conflicts, to leave me with no extra commits, the changes in my checkout 
as I want them and no stashed ones (gt does not remove the stash until 
you commit the resolved changes, which, as I said is not what I want to 
do usually)

I hope I clearly explained this, and if this was obvious to everyone, 
sorry for the noise!

-- 
Guido Falsi <madpilot_at_FreeBSD.org>
Received on Tue Dec 29 2020 - 17:12:42 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:26 UTC