Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files

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

 



On Mon, Oct 08, 2007 at 08:22:42AM +0200, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
>> The rationale was this: filter-branch recently learnt how to rewrite many 
>> branches, and it might be tedious to find out which ones.  But then, there 
>> is git log --no-walk --all, so maybe I really should get rid of 
>> refs/original/*?
>> I'd like to have some comments from the heavier filter-branch users on 
>> that...
>
> IMHO, a backup of the original refs is needed.

And we can't rely instead on reflogs or some other existing mechanism?

> However, it may be wise to store them in the refs/heads namespace so
> that 'git branch -d' can delete them and 'git branch -m' can move them
> back if something went wrong.

If people want backups like this it'd seem easier to turn this on
optionally with commandline switches, like patch's --backup, --prefix,
--suffix options.

Having it by default leave these backups around, even when everything
succeeds, makes for unnecessary cleanup work in the normal case, and is
inconsistent with the behavior of other git commands that destroy or
rewrite history.

--b.
-
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]

  Powered by Linux