Re: why is git destructive by default? (i suggest it not be!)

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2008.06.24 08:08:13 -0000, David Jeske wrote:
> To re-ask the same question I asked in my last post, using your ascii
> pictures...
> 
> 
> Let's assume we're here..
> 
> .<---.<---.<---A<---X<---Y    <--- master
> \
> \--B<---C    <--- customer_A_branch <=== HEAD
> 
> 
> And this person and everyone else moves their head pointers back to master
> without merging:
> 
> 
> .<---.<---.<---A<---X<---Y    <--- master              <=== HEAD
> \
> \--B<---C    <--- customer_A_branch
> 
> 
> Now, five years down the road, our tree looks like:
> 
> 
> .<---A<---X<---Y<---.<--.<--.(3 years of changes)<---ZZZ<--- master  <=== HEAD
> \
> \--B<---C   <--- customer_A_branch
> 
> And someone does:
> 
> git-branch -f customer_A_branch ZZZ
> 
> To bring us to:
> 
> .<---A<---X<---Y<---.<--.(3 years of changes)<---ZZZ<--- master  <=== HEAD
> \                                           \
> \--B<---C                                   \-- customer_A_branch
> 
> 
> ..at this point, will a GC keep "B<--C", or garbage collect the commits and
> throw them away?

That would throw away the changes in _that_ repository after the reflog
entry has expired. It would not affect any other repo yet, and if that
developer tries to push that new customer_A_branch, it would be refused,
because it is not a fast-forward. And if the repo he's trying to push to
simply doesn't allow any non-fast-forward pushes, then even push -f
won't help him to destroy anything.

Björn