Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Friday 29 February 2008 8:29:07 am Otavio Salvador wrote:
> Colin Watson <cjwatson@debian.org> writes:
> > On Fri, Feb 29, 2008 at 09:16:59AM -0300, Otavio Salvador wrote:
> >> Ian Jackson <ian@davenant.greenend.org.uk> writes:
> >> > What I am trying to achieve is to use git in the proper way: that is,
> >> > in a way which makes merging work properly.
> >> >
> >> > Insisting that I use git in a manner which makes merges break but
> >> > gives prettier logfiles is absurd.
> >>
> >> 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.
>
> I'm not saying that it couldn't be made public for review however I
> suppose noone will ask for review if it's still at start of
> development process.
The moment you commit a patch on the branch is the moment it potentially is
interesting.
Here's an example. I'm looking at evaluating Redmine, a web-based project
management tool, sorta like *forge but smaller, easier, faster, and better.
Redmine's SVN tree has integration with Darcs, Mercurial, etc. -- but not
git.
So someone made a Git branch of it that has Git support. This support will
certainly be integrated into mainline at some point. Meanwhile, even if he
is still working to refine it, it's useful to me to see it because I'd want
Git integration. I understand the risks of running bleeding-edge code, and
in this case maybe it's worth it, and maybe I'm interested in helping to
test, too.
-- John
Reply to: