[Ksummit-2012-discuss] [ATTEND] structuring of tools et.al and linux-devel.git repo
rostedt at goodmis.org
Tue Jun 19 18:39:28 UTC 2012
On Tue, 2012-06-19 at 11:22 -0700, Joe Perches wrote:
> > I constantly rebase my work before I push it public, so that I have a
> > nice bisectable history. I have branches that last for a year, that
> > basically works, but still is being tweaked upon. Just not 'ready for
> > mainline' bit.
> 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.
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.
More information about the Ksummit-2012-discuss