[Ksummit-2012-discuss] [ATTEND] structuring of tools et.al and linux-devel.git repo
joe at perches.com
Tue Jun 19 18:55:41 UTC 2012
On Tue, 2012-06-19 at 14:39 -0400, Steven Rostedt wrote:
> On Tue, 2012-06-19 at 11:22 -0700, Joe Perches wrote:
> > Well, perhaps git bisect could just be smarter
> > about bisecting with reverted commits.
> And may I ask what purpose would it be to have "what didn't work" in the
> git history? To me, it causes more harm than being useful.
> If it was tried and released, that's one thing. But if it was tried in
> development and is proven to be broken, that's something else. Post
> patches to the mailing and let the mailing list archive be the location
> of what didn't work.
That's an out-of-line location and isn't part
of git history.
> If you included 10 patches where the first one is reverted later, but
> instead of rebasing and removing that patch and only submitting the 9
> good ones, how would a git bisect work in such a case? If the bisect hit
> patch 5, it would include the reverted commit.
Not if git bisect was smarter about testing and/or
I don't see any issue with people having private
branches and not pushing things to -next. I also
just don't see an actual problem with -next as-is.
Making stuff wait 6+ months for inclusion into
a nominal master tree seems inefficient and
More information about the Ksummit-2012-discuss