Re: RFC: git bisect should accept paths-to-be-excluded
Hi, On Mon, Sep 16, 2013 at 2:39 PM, Toralf Förster toralf.foers...@gmx.de wrote: I'm bisecting a linux kernel issue and want to ignore all commits just touching something in ./drives/staging. Currently the only way would be to specify all dir/subdir combination under ./linux except that particular directory, right ? Yeah, you are right, currently the only way would be to specify all dir/subdir combination under ./linux except the particular directory you want to exclude. It might indeed be useful to have a way to exclude some directories or files. In practice though, as git bisect is a kind of binary search, if what you want to exclude is exclusively touched by half the commits, it will only add one more bisection step if you don't exclude it. Best regards, Christian. -- 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
Re: RFC: git bisect should accept paths-to-be-excluded
Christian Couder christian.cou...@gmail.com writes: In practice though, as git bisect is a kind of binary search, if what you want to exclude is exclusively touched by half the commits, it will only add one more bisection step if you don't exclude it. Actually, I think the same remark would apply to any other Git command that deal with a set of revisions. If you want to review code with git log -p, but you don't care about a subdirectory, you may want a git log -p --ignore-dir foo/ or so, too. And then, the it's logarithmic argument doesn't work anymore ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
Re: RFC: git bisect should accept paths-to-be-excluded
On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Christian Couder christian.cou...@gmail.com writes: In practice though, as git bisect is a kind of binary search, if what you want to exclude is exclusively touched by half the commits, it will only add one more bisection step if you don't exclude it. Actually, I think the same remark would apply to any other Git command that deal with a set of revisions. If you want to review code with git log -p, but you don't care about a subdirectory, you may want a git log -p --ignore-dir foo/ or so, too. Yeah, and there was a patch series about that 2 years ago: http://thread.gmane.org/gmane.comp.version-control.git/182830/ And then, the it's logarithmic argument doesn't work anymore ;-). Sure. Best regards, Christian. -- 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
Re: RFC: git bisect should accept paths-to-be-excluded
On Tue, Sep 17, 2013 at 4:03 PM, Christian Couder christian.cou...@gmail.com wrote: On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Christian Couder christian.cou...@gmail.com writes: In practice though, as git bisect is a kind of binary search, if what you want to exclude is exclusively touched by half the commits, it will only add one more bisection step if you don't exclude it. Actually, I think the same remark would apply to any other Git command that deal with a set of revisions. If you want to review code with git log -p, but you don't care about a subdirectory, you may want a git log -p --ignore-dir foo/ or so, too. Yeah, and there was a patch series about that 2 years ago: http://thread.gmane.org/gmane.comp.version-control.git/182830/ And that's just one of the few attempts if I remember correctly. I guess it's time revisit it. A few things to sort out before we get to the implementation: Support flat or nested negation (i.e.include A, ignore A/B, but include A/B/C..). Nested thing complicates things so I'm towards the flat exclusion (exclude B means all inside B, no buts nor excepts) and probably cover most use cases Interaction with git grep --depth Syntax. I guess --ignore (or --exclude) is more intuitive than :(exclude)something but then it might collide with existing options (I did not check if --ignore or --exclude is used anywhere though). The latter also enables combining with other filters, such as case-insensitive matching.. -- Duy -- 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
Re: RFC: git bisect should accept paths-to-be-excluded
On 09/17/2013 09:26 AM, Christian Couder wrote: Hi, On Mon, Sep 16, 2013 at 2:39 PM, Toralf Förster toralf.foers...@gmx.de wrote: I'm bisecting a linux kernel issue and want to ignore all commits just touching something in ./drives/staging. Currently the only way would be to specify all dir/subdir combination under ./linux except that particular directory, right ? Yeah, you are right, currently the only way would be to specify all dir/subdir combination under ./linux except the particular directory you want to exclude. It might indeed be useful to have a way to exclude some directories or files. Great to hear In practice though, as git bisect is a kind of binary search, if what you want to exclude is exclusively touched by half the commits, it will only add one more bisection step if you don't exclude it. Unfortunately not. Linus pulls from Greg's staging tree usually once in a merge window. It is not uncommon to have hundreds of commits in that merge. If now (by accident) the merge point is marked as BAD and the base is GOOD, then git bisect falls into that trap and wastes about ld(few hundreds) steps - and this happened here for me and each bisect step took hours ... Best regards, Christian. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- 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
Re: RFC: git bisect should accept paths-to-be-excluded
Duy Nguyen pclo...@gmail.com writes: On Tue, Sep 17, 2013 at 4:03 PM, Christian Couder christian.cou...@gmail.com wrote: On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Christian Couder christian.cou...@gmail.com writes: In practice though, as git bisect is a kind of binary search, if what you want to exclude is exclusively touched by half the commits, it will only add one more bisection step if you don't exclude it. Actually, I think the same remark would apply to any other Git command that deal with a set of revisions. If you want to review code with git log -p, but you don't care about a subdirectory, you may want a git log -p --ignore-dir foo/ or so, too. Yeah, and there was a patch series about that 2 years ago: http://thread.gmane.org/gmane.comp.version-control.git/182830/ And that's just one of the few attempts if I remember correctly. I guess it's time revisit it. A few things to sort out before we get to the implementation: Support flat or nested negation (i.e.include A, ignore A/B, but include A/B/C..). Nested thing complicates things so I'm towards the flat exclusion (exclude B means all inside B, no buts nor excepts) and probably cover most use cases Yeah, it is easy to say that git log -- A ':(exclude)A/B' A/B/C has two positive (A, A/B/C) and one negative (A/B), and then the most specific one A/B/C matches a path A/B/C/D and hence A/B/C/D is included. But to actually _design_ it, there are ambiguities that makes understanding and explaining the semantics, especially given pathspecs can have wildcards, icase matches, etc. For example, is :(exclude,icase)A/B/? more specific than A/?/C or less? So I tend to agree that we should aim for an easier to explain, if less capable, approach. Interaction with git grep --depth I am not sure how that affects anything. Conceptually, isn't --depth an independent axis to filter out paths that have too many components after given positive pathspec elements? E.g. given git grep --depth=2 pattern -- A B/C we will grab paths from two levels starting at A and B/C (so A/1/2 and B/C/1/2 may hit but not A/1/2/3 nor B/C/1/2/3). Shouldn't negative pathspecs just filter that depth filtering, i.e. if you have :(exclude)*/1/*, even though both A/1/2 and A/a/b may pass the --depth=2 filter, the former is excluded while the latter is not. Syntax. I guess --ignore (or --exclude) is more intuitive than :(exclude)something but then it might collide with existing options (I did not check if --ignore or --exclude is used anywhere though). The latter also enables combining with other filters, such as case-insensitive matching.. I do not think it is an option to do this with any mechanism other than negative pathspecs. -- 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
Re: RFC: git bisect should accept paths-to-be-excluded
Junio C Hamano gits...@pobox.com napisał: Yeah, it is easy to say that git log -- A ':(exclude)A/B' A/B/C has two positive (A, A/B/C) and one negative (A/B), and then the most specific one A/B/C matches a path A/B/C/D and hence A/B/C/D is included. But to actually _design_ it, there are ambiguities that makes understanding and explaining the semantics, especially given pathspecs can have wildcards, icase matches, etc. For example, is :(exclude,icase)A/B/? more specific than A/?/C or less? What about simply iterating over options in order in which they are specified and the last option that matches specifies the result? -- Piotr Krukowiecki -- 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
Re: RFC: git bisect should accept paths-to-be-excluded
Piotr Krukowiecki piotr.krukowie...@gmail.com writes: What about simply iterating over options in order in which they are specified and the last option that matches specifies the result? But isn't it very inconsistent from the way normal pathspec works? git log -- A B and git log -- B A would give the same result. -- 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
Re: RFC: git bisect should accept paths-to-be-excluded
On Tue, Sep 17, 2013 at 9:04 PM, Junio C Hamano gits...@pobox.com wrote: Piotr Krukowiecki piotr.krukowie...@gmail.com writes: What about simply iterating over options in order in which they are specified and the last option that matches specifies the result? But isn't it very inconsistent from the way normal pathspec works? git log -- A B and git log -- B A would give the same result. Both are include-type filters. --include A --include B will give the same result as --include B --include A too. Are there existing include/exclude filters where order does not matter? For example gitattributes(5) says When more than one pattern matches the path, a later line overrides an earlier line. Ignoring (possible) inconsistency thing, I think they are easy to understand and use. -- Piotr Krukowiecki -- 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
Re: RFC: git bisect should accept paths-to-be-excluded
Piotr Krukowiecki piotr.krukowie...@gmail.com writes: Ignoring (possible) inconsistency thing, I think they are easy to understand and use. Probably you are right (in the sense that I do not offhand think of a confusing and ambiguous set of positive and negative pathspecs; others may find holes in my/our thinking). I am not sure if it will fit well to the current struct pathspec design, though. We could start from when there is any negative pathspec, disable the 'optimize away the common leading prefix' thing, I guess. -- 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
RFC: git bisect should accept paths-to-be-excluded
I'm bisecting a linux kernel issue and want to ignore all commits just touching something in ./drives/staging. Currently the only way would be to specify all dir/subdir combination under ./linux except that particular directory, right ? -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- 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
