On Fri, Aug 9, 2013 at 2:50 AM, Johannes Sixt <j.s...@viscovery.net> wrote:
> Am 8/9/2013 8:33, schrieb shawn wilson:
>> On Fri, Aug 9, 2013 at 2:25 AM, Johannes Sixt <j.s...@viscovery.net> wrote:
>>> Am 8/8/2013 23:11, schrieb Phil Hord:
>>>> On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson <ag4ve...@gmail.com> wrote:
>>>>> On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt <j.s...@viscovery.net> 
>>>>> wrote:
>>>>>> Am 8/7/2013 8:24, schrieb shawn wilson:> ... create a repo for one of
>>>>>>> these scripts and I'd like to keep the commit history.
>>>>>>> Ok, so:
>>>>>>> % find -type f ! -iname "webban.pl" | while read f; do git
>>>>>>> filter-branch -f --index-filter "git rm --cached --ignore-unmatch $f"
>>>>>>> HEAD ; done
>>> I'm not sure. On second thought, my suggested command is not sufficient.
>>> It does remove the empty commits, but it does not remove the other files.
>>> So, Shawn's original filter-branch invocations are still needed.
>> Yeah, I have tried this and haven't gotten any closer. I can either
>> remove all of the history or that one commit that has nothing to do
>> with my file is there. This is also reproducable in a new repo.
>> Is this a bug with filter-branch or git? This doesn't seem like a
>> feature (or how things should act).
> Let's check: After running your command above to remove other files, does
> the command
>    git filter-branch -f HEAD webban.pl

Ahha, no but:
git filter-branch -f HEAD -- webban.pl


The question still stands though - why is that unassociated commit left there?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to