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

[Richard Wackerbarth]

If I am not mistaken, both git and bzr are capable of generating and displaying the same graphical structure.

As for the merging of branches, git is perfectly capable of merging a branch as a single merge point in the graph (use the -no-ff option).
And, I am sure that you could cause bzr to emulate the git "one at a time" incremental merge behavior, if you so wish.
Good, or bad, those are not the defaults (unless you set your personal preferences to override the vendor default).
Many (most?) users simply use the system default and never realize that they have other options.

Again, I will comment that my preference for git is largely based on the lack of support for bzr on Mac OSX. If we had the same GUI support that is provided by, for example GitX, and we had integration with the Xcode IDE, then I am sure that I would not care which DVCS was used as the backend.

But, IFAIK, that support is not available. And, it is through that support that I do almost all of the things that I need to do on a routine basis.
For the few remaining cases, I do not mind reverting to the command line (with the man pages in another window since I never remember the esoteric syntax of each VCS).

Perhaps we can have the best of both worlds by setting up a "bot" to export/import the bzr tree to a git tree on a routine basis.
I presently maintain both the underlying .git and .bzr directories in my development trees.

Richard

On May 21, 2012, at 10:13 AM, Barry Warsaw wrote:

> 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:
> 
>> Barry Warsaw writes:
>> 
>>> I personally think that rebase is an abomination generally required
>>> by workflow policies that try to overcome tool deficiencies.  By
>>> not *requiring* rebase (it is of course possible), it means that
>>> all your intermediate commits are preserved
>> 
>> No VCS "requires" rebase, or removing commits from history.
> 
> Agreed, but just about every git fan I've ever talked to always emphasizes
> rebase as an important part of the merge workflow.  When I dig deeper into why
> that is, it always seems to come down to this: when 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.
> 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.
> 
> 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.
> 
>>> because sometimes they are useful.  Most of the time you can ignore
>>> them which is exactly how it should be, IMHO.
>> 
>> This is the nub of the argument.  bzr mandates a presentation of
>> history that bzr fans like, and some folks don't.  I'm not a big fan
>> of bzr log -n# for any value of # AFAIK ;-), but I'm willing to try
>> different things as they seem useful.
> 
> There are some good graphical representations of that history, for folks who
> like that sort of thing.  I think they can make digging into those branch
> sidings nicer.
> 
>>> 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.
> 
>>> As far as the attributions go, I think the best place to be
>>> explicit is in the NEWS file.  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.
> 
>> Anyway, the NEWS file is way too coarse for the purposes that Wacky
>> and I have in mind.  Eg, George may need some changes to the IArchiver
>> interface, and send you a branch that makes them.  But a crucial patch
>> may have been suggested and supplied by a mentor.  I trust that you'll
>> mention George in NEWS, but will you even be aware of the
>> contributions by third parties?
> 
> 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 for
> the crucial patch, and then I merged George's branch, the history of that will
> be reflected in the bzr revision history.  It may be off in a 2-level deep
> siding, but it's there.  The usefulness of that seems independent of the vcs
> being used.  A plain text file in the tree is still going to be a better place
> to record contributions, IMHO.
> 
> -Barry
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/richard%40nfsnet.org
> 
> Security Policy: http://wiki.list.org/x/QIA9