[Mailman-Developers] [Merge] lp:~wacky/postorius/csrf into lp:postorius

[Stephen J. Turnbull]

Barry Warsaw writes:
 > I don't want to side track too long into a vcs discussion, so I'll respond
 > here and then you can have the last word.  :)
 > 
 > On May 21, 2012, at 12:21 PM, Stephen J. Turnbull wrote:

 > >No VCS "requires" rebase, or removing commits from history.
 > 
 > Agreed, but just about every git fan I've ever talked to always
 > emphasizes rebase [...].  [W]hen I merge your branch into mine, all
 > your intermediate commits get slapped right onto my branch, one at
 > a time.  Which means that if your branch introduced a regression,
 > and I want to bisect to find it, I have to bisect through all your
 > intermediate commits.

All true, but if it's my branch that introduced the regression, you
have to bisect the whole thing either way.  Worse, in your workflow,
if you have 25 commits and I have 25 commits on our respective
branches, it's not uncommon for bisect to "localize" the regression to
the set of those 50 commits (ie, only the final merge commit exhibits
the regression).

The implication is that your workflow is happiest with many small
feature branches; at the very least, bisect would not work well with
kernel-style development where there are a fair number of long-lived
feature branches.

I don't think there are many projects like the kernel, though.  Most
projects are happier with many small feature branches.  The point is
simply that the kernel has special needs, and git is mostly developed
by kernel developers, they are going to prefer the workflow they are
used to.  (Other projects may have more than a little kernel envy. :-)

 > This has implications for logging too, which would show
 > me all your intermediate commits as well.  If I saw that all the
 > time, I'd think it would suck too.

Touche -- but your comment about graphical log viewers applies here,
too.

 > Admittedly, I'm not speaking from rich first hand experience, so
 > feel free to correct the FUD.  But I really like the bzr way of
 > seeing my merge of your branch as one clearly labeled revision on
 > my branch.  I can dig into your intermediate commits if I want
 > (there's often valuable information there), but most of the time I
 > don't care, and my tool allows me to not care, until I do.

git allows this; you can select only merge commits for logging (and
other DAG-traversal operations IIRC).  It's not the default because
the git and kernel developers prefer the rebase-based workflow.

 > > > In a well-developed branch, that rationale should be included in
 > > > the intermediate commit messages of the proposed branch (not to
 > > > mention good comments in the code <wink>).  Rebasing that away just
 > > > seems *wrong* to me.
 > >
 > >That is not the purpose of rebase, and I doubt any well-managed
 > >project permits it.
 > 
 > Isn't this essentially how the kernel works?  When I talk to developers of
 > git-run projects, it does always seem to come down to this.

No, it's not.  They don't "rebase away" the intermediate commits; they
create a new presentation of the changes, sequencing the commits "as
if" they were carefully planned, and crafting new commit messages as
documentation of those changes.  If you send a branch to Linus with
change/message skew, you'd better be prepared for massive skin grafts
in the near future (and that's the good case, it means your patch is
deemed to have some socially redeeming value :-).

 > > > Folks getting Mailman via tarball or distro package won't have
 > > > access to the VCS history anyway.
 > >
 > >False.  It's less convenient for them, but they can browse launchpad.
 > 
 > If they can find it.  I still think a NEWS file or ACKNOWLEDGMENTS file
 > (suitably maintained :/ ) is more accessible to more folks.

No question incldued files are "more accessible to more folks", but
the people who care in the way that Wacky and I are describing are
generally going to have a checkout anyway.  The "suitably maintained"
caveat is also a biggie.

 > Probably the best way to handle this is for George's NEWS file entries to
 > include that information.  If George really did merge a mentor's
 > branch

That's why I used a "mentor" example.  The mentor probably shouldn't
be maintaining branches for application to George's code, right?  But
if the description is sufficiently explicit, the git attribution
machinery allows a commit with "author:wacky committer:george".

 > A plain text file in the tree is still going to be a better place
 > to record contributions, IMHO.

Depends on policy.  I have a patch in the Emacs tree, but since RMS
put it into final form, I don't have an AUTHORS entry.  (And that's
all right by me, but that's another story....)