On Sunday, May 4, 2014 3:53:14 AM UTC-7, Thomas Ferris Nicolaisen wrote:
>
>
>
> On Saturday, May 3, 2014 2:09:35 AM UTC+2, joeri...@gmail.com wrote:
>>
>>
>>> Are you aware that the BFG will only remove files that have been 
>>> actually removed from the latest version of the repository? If there are 
>>> other files with the same name that still exist, they won't be cleaned out.
>>>
>>
>> That is not true.  BFG will happily delete files that have not been 
>> removed from any branch, without regard to path.
>> For example, suppose I have files named bar and foo/bar on two branches, 
>> with different content on each branch.
>> Assume HEAD is set to master.  If I then clone the archive, run bfg -D 
>> bar on the clone, then push the cloned archive,
>> the original repo will only have the files bar and foo/bar in the master 
>> branch, they are gone from the others.
>>
>
> Do the files also exist in master? By default, only the files in HEAD 
> (which you say is master when running BFG) will be protected. Quoting the 
> docs:
>
> By default the HEAD branch is protected, and while it's history will be 
>> cleaned, the very latest commit (the 'tip') is a protected commit and it's 
>> file-hierarchy won't be changed at all.
>> If you want to protect the tips of several branches or tags (not just 
>> HEAD), just name them for the BFG:
>> $ bfg --strip-biggest-blobs 100 --protect-blobs-from master,maint,next 
>> repo.git 
>
>
> If this is not what happens, you'd better file a bug report. 
>

They exist in master, so that's okay.  The issue for me is that because BFG 
doesn't distinguish paths, I cannot use it for arbitrary filenames. 

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to