Re: Question about 'branch -d' safety

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 ----- Original Message -----
From: Will Palmer
Date: 7/19/2010 1:45 PM
On Mon, 2010-07-19 at 11:16 -0600, Joshua Jensen wrote:
My brain has become muddied with all the ~2 stuff.  Explain again why it
can't be as simple as this?
...snip...
git checkout -b integration HEAD@{1}  (or 8000000)

-Josh
Because:
  1) The HEAD reflog is the wrong place to stick things which weren't
recently checked-out.
  and 2) the previous tip is currently the easiest-to-recover part of a
deleted branch. What's lost is all the reflog data: order of states, and
how they were reached.

However, I /do/ think it's as simple as "don't delete the reflog right
away when you delete a branch", and other edge-cases and niceties in
terms of UI (such as ref renaming, resurrection of refs for tracking
unrelated data, etc) can be taken care of later, if there's actually a
need for them.
Thanks for the extra clarification.

For my sake, how is the previous tip the easiest-to-recover part of a deleted branch? How do you go about finding the lost object?

Josh
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]