Patch mgmt workflow proposal
also sprach Ben Finney <email@example.com> [2011.08.02.0223 +0200]:
> > This comes about ¾ of the way to the history pollution done by TopGit.
> I consider it very useful information, when needed. It's only pollution
> if you let it be so.
That is a very wise statement, and I agree.
> > Not only would users potentially get confused by this additional
> > branch (which is an implementation detail), it would also get in
> > the way in gitk output (cf. pristine-tar) and annoy even the
> > unconfused.
> That's an argument not for hobbling a useful branching-and-merging
> workflow, but for improving the output of those programs. Advocate
> with Git (and other VCSen) to hide merged revisions by default,
> the way Bazaar does.
One person's reasonable default is another person's nightmare.
Fact is that we have new contributors who are being shyed away by
Fact is also that you can already hide information explicitly.
I have already dipped my foot in the water on this
[http://bugs.debian.org/636228], but I feel somewhat it's an
In the end, the best solution is one that doesn't expose
implementation details in the first place. The discussion at
is shaping up to be interesting.
.'`. martin f. krafft <firstname.lastname@example.org> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems