Re: [PATCH] First cut at libifying revlist generation

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

 



Hi,

beware of that patch. It breaks at least one thing: cloning a repository 
with a tag pointing to a tag object (the tag is cloned, but not the tag 
object).

Sorry to not fix it right away, but I am just too tired.

By way of figuring this out, I just found a (warning: irony) "cute 
feature" of git-bisect. I needed to apply a certain patch to trigger a 
certain bug. So I always applied that patch after bisect chose the next 
rev, and of course committed it so that bisect could continue.

(In hindsight, I probably should've applied the patch, 
git-update-index'ed the file, and hoped that the merge mechanism take care 
of it.)

Now, short of finding the correct commit, bisect would loop endlessly, 
giving me the same rev to test over and over again (saying "2 revs to go 
after this"), because I would label the current rev (which was the applied 
patch, not the bad rev) as bad.

So, in a very real sense, it might not be such a phantastic idea as was 
suggested earlier on this list, that you are able to commit on top of a 
bisected rev.

Good night and good luck,
Dscho

-
: 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]