Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: David A. Greene (greened_at_[hidden])
Date: 2012-02-08 18:42:16

Thomas Heller <thom.heller_at_[hidden]> writes:

> On 02/08/2012 07:30 AM, Steven Samuel Cole wrote:

>> A quick read on submitting bugs on boost.org, svn co yadi yadi, fix the
>> typos locally. Of course I don't have write privileges to the repo, so
>> the best I can do for now is create a patch and attach that to a bug
>> report. Within minutes, someone takes care of the bug, comments and
>> takes ownership. Excellent! Smithers, money fight!
>
> Great! Now with something like github you create your own fork, push
> to that and eventually create a pull request and wait until it gets
> applied ... as you described. The process didn't change. You just
> named the steps differently.

No.  The fundamental part you're missing is that the source control
utility (git in this case) handles it for you.  There is no need to go
outside the sournce control utility to make additional changes.

>> What are my options now ? Revert my changes, base the new ones on the
>> head revision and send another patch ? Create a new patch file and
>> manually remove the diffs of the old changes I already sent ? How will
>> the upstream maintainer know which changes are based on what version ?
>
> Simple. Update the bug you already filed with the patch containing all
> fixes. What would be the options with git? Update the pull request?
> Again, same thing, different name.

No, not the same thing.  Again, this is all happening within the source
control utility.

Steven is relating real issues with svn.  I have encountered them many
times.  I have found that git eliminates them.

>> Also, I notice a few other things that in my opinion could be done
>> better to facilitate adoption of the iostreams library. 

> So with git you pushed them to your personal fork. Over time, your
> fork and the upstream version eventually diverge. You have to maintain
> your changes. Same thing when the changes lurk on your local svn
> working.

There are several advantages to a git fork over an svn local workarea.

- You can make a new branch for each feature, keeping the code for
  logical features separate.  You can submit them whenever you want, in
  whatever order you want.

- You can share the forks and branches with others.

- You can massage the fork/branch over time to respond to review
  feedback, all supported directly by the source control utility.  IME,
  git rebase -i and git add -i are killer features for the code review
  process.

>> A couple of hours later: I get an email from boost bugs/svn; the
>> upstream maintainer has committed my changes. However, I actually
>> receive not one, but two emails, because the upstream guy chose to split
>> my patch into changes on documentation and changes on source code (which
>> presumably required extra work on his part).
>
> Frankly, I don't see how this would change with git.

Actually, git would make things easier for the maintainer here.  Either
he/she could request the submitter to break up the patch, which is
easily done with rebase -i/add -i or the maintainer could use the same
tools to do it him/herself.

>> I do an svn up and now have to deal with conflicts between my local
>> changes and the new commits: I make a note of my second set of changes
>> and overwrite my local files with the new repo versions, then bring the
>> second set back in.
>
> Same again. How is this significantly different to what you'd do with git?

It's all within the utility.  There's no need to back out patches (the
second set of changes in this case) manually from the source and
re-apply them manually after update.  Because each feature is in its own
(local) branch, updates of one branch don't conflict with unrelated
features in other branches.  Yes, you'll need to resolve conflicts but
it's much less messy with this kind of separation.

>> Uff! That's a lot of work just to fix some typos! And these are just
>> cosmetic issues in discrete chunks that do not require any testing;
>> contributing changes to source code would take even more effort and more
>> caution - build and test on several platforms, peer review, etc.
>
> Right, all that wouldn't change with having git as the tool of choice.

It does, dramatically.  git actually directly supports workflows that
developers use when working on large projects.  svn does not and there
are all sorts of hacks out there to work around those problems.  I've
written a fair number myself.  I don't need any of them with git.

>> I don't have to wait for the first set of changes to be merged into
>> the trunk before I resync, resolve conflicts and base the second
>> set on the new head revision; I simply create a new branch for
>> a new change set and send a new pull request once my work is complete.
>
> Errm ... you can still do that with svn. just continue working. Make a
> new patch, update the patch in the bug report you filed, yes trac can
> do that. There really is no need to wait for anything.

But now you're conflating multiple features.  Many times I have a
feature in-progress and another feature I'd like to work on that's
unrelated to the first feature.  I don't want to disturb the source tree
of the first feature because I might have to update it (respond to
feedback, etc.).  I need to be able to test both features in isolation.

>> The upstream maintainer has no peer pressure to merge any changes in:
>> He/she is sitting on the head revision and is looking at a number of
>> pull requests for change sets in various personal forks like mine;
>
> So, how is it really different from the current trac system?

svn doesn't support distributed operation so it can't support
cherry-picking from multiple developers.  You have to go outside the
tool (manual diff/patch) to do it.  That is painful.

> I think i miss something fundamental here.

Yes, you are.  You're missing that every operation Steven is talking
about is directly supported in git.  You use the source control tool to
manage source changes, always.  There's no need to ever do a manual
diff/patch.  git manages multiple changes for you and organizes them in
a logical way.  It is easy to change among them, apply some, test them,
revert some of them and so on.

It's incredibly easy and productive compared to doing the same in svn.

> While there are shortcomings in the current process, they won't be
> solved by changing tools.

Many will be.

                               -Dave