Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Sat, 1 Mar 2008 11:07:54 -0500, Theodore Tso <tytso@MIT.EDU> said:
> On Fri, Feb 29, 2008 at 12:40:55PM +0000, Colin Watson wrote:
>> > That's why you should avoid using the branch as basis to others
>> > until it's clean and also avoid to make it public (without a
>> > reason) too.
>>
>> This makes it more difficult to ask for review while the branch is in
>> progress, which is a valuable property. It is ridiculous to
>> artificially avoid making branches public; a branch is a useful means
>> of collaboration and we should take advantage of it as such.
> It's a bad idea to base work on a feature where the code is still
> being under review. Even if you keep all of the historical crap on
> the branch, to be preserved for ever, it's going to cause merge
> difficulties for people who base branches based on that patch which is
> under review.
I do not understand this. See, usign topic branches for
upstream code that does reversions and bug fix one off versions, I have
never really encoutered extraordinary difficulties in
merging. Admittedly, the most complex case I have is Emacs, and I merge
in changes from HEAD and sometimes from the lexbind branch, and both
these are under rapid development -- what merge problems have I been
avoiding?
> So you really, REALLY, don't want people basing work on code which is
> still being developed, since it may be that the review may include,
> "why don't you totally refactoring the code *THIS* way", which will
> end up breaking everyone who depends on your new function interface
> anyway.
Well, a complete refactoring would cause me to clone off another
branch, and restart there, abandoning the current branch, but my cases
are far different for the kernel.
Which is significant; we are not talking about a code base with
the size, scope, and contributors like the kernel does; perhaps the
ruls might well be different?
> So how to solve this problem?
> (a) Send patches via e-mail for review. This actually works better,
> because people can respond via e-mail much more easily than if it just
> shows up in a git repository. You can also send an explicit request
> for people to review the patch when it is sent via e-mail.
> (b) Put the patches on a git branch which is *guaranteed* to be
> constantly rewound, and is not to be used as a base for derived
> patches. By convention the 'pu' branch in the git (and e2fsprogs)
> source repository is declared to be one which is used only for people
> who want to test the latest bleeding edge code, but it should not be
> used as the basis of any derived or child branches.
Hmm. OK, how about this picture:
This is my typical workflow. Most of the time, upstream changes
flow down to topic branches and integration branches; and since I use
arch, I do plain old merges.
If I actually rebase any Topic branch for the occasional feed
back to upstream, that would cause problems in the integration branch
(do not merge and rebase in the same tree).
My tentative solution is to clone Topic_A_3.0 in Topic_A_3_Prime,
and rebase the new branch -- which seems deceptively simple. The fact
that no one has proposed that as a solution makes me think that perhaps
this is not as easy as I am making it out to be.
I would really appreciate any comments on this bit.
>> I have never once run into this problem with other revision control
>> systems in which branching and merging are common. Somehow it just
>> never seems to be a real issue. I contend that dpkg is not big enough
>> for it to become a real issue.
> It's not a fatal issue, but in the long run, the code is more
> maintainable if the code revision history is clean. It's like having
> a few goto's in the code. Does that make the code unmaintainable?
> No. But it does make it worse. Or think about how much effort some
> of us spend to make the code gcc -Wall free of warnings. Does not
> doing it make the code fundamentally bad? No. Is it still worth
> doing? Many of us believe that it is worth doing, nevertheless.
While I appreciate the analogy, I am not sure how valid it is. I
lurk on the emacs development list, and pull from the HEAD of the
development branch several times a week. Since this is the HEAD of
development, things might break, so I look at changelogs. Having messy
history, and revocations of changes do not seriously impact my review
of what has changed.
I have often heard people say that clean history makes things
easier, but since I do not see much of a difficulty with unclean
history, I am not sure I find this argument persuasive.
Now, having bisecability could be useful (I have never used a
bisect); I don't know what the effect of a version that does not
compile or is otherwise buggy would have on the work flow.
manoj
--
Actually, what I'd like is a little toy spaceship!!
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: