git and the loss of revision numbers

[Guido Falsi]

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>