John Reese wrote:
>>> c) with cheap, efficient, and easily mergeable branches, we can begin to
>>> use staging/edge/testing branches for commits, which can then be
>>> reviewed by others before being merged to master/trunk
>> Nothing blocks you from doing this with Subversion, or any other VCS for
>> that matter. Not as easy at least, sure.
> Not as easy being the exact point I'm trying to make.
The "we can begin to use..." part of your previous message sounded like
it would be impossible otherwise.
> They don't require separate checkouts, but their usage of inline
> branching is not as streamlined or robust feeling as that of Git. This
> is probably one of the better explanations I've found of why I feel this
"Robust feeling" is a strange argument. Are we discussing which tool is
best suited for the task, or which tool we like it better? Because even
nowadays people still like CVS... The whole discussion is pointless if
we argue on what we like instead of what is better.
And if it is a question of taste, Mercurial offers you bookmarks, that
is another way to do branches that is very, very similar to Git's view
> I'm talking about the fact that *I* think it's much simpler and easier
> to do in Git over Hg/Bzr, not just in normal usage, but in resolving
> conflicts, using interactive rebase, etc.
> And why should I want a DVCS that needs a separate plugin to do it?
And what is the problem with software that is modularly designed?
Plugin design is a feature, you don't pay for what you don't need. It
allows you to customize your usage of the tool. If I don't like
Mercurial's transplant, for example, I can do my own and load it
dynamically by adding a line to a config file, without touching the
The Mercurial and Bazaar model allows for you to use only the parts that
you need. The KISS principle: less complexity, easier to maintain, more
reliable. You may even think about embedding the versioning tool in
> I think you missed *my* point. You start making changes to your files,
> and then in the middle of your changes, you realize you need to fix or
> modify something else in the same files you've already edited. So you
> make your changes.
> Now, with SVN, you have to commit all that as a single changeset.
Wait... in this point of your message you were talking about how you
think Git is better than other DVCSes, now you compare it back to SVN...
> with Git's interactive add/commit, you can selectively choose individual
> changes to files that you want to commit. So you can commit the changes
> on lines 150-200, but leave the changes on lines 60-90 for a later
> commit. *That's* the point I'm trying to make where the staging
> area/index is really starting to shine as a useful tool for manipulating
> your changes in preparation for commit.
You definitely don't need the index to achieve that. What you described
is just interactive commit, or cherry-picking of changes.
While in Git you have to use the index and spread it in various
interactions before the final commit, in other DVCSes that support
interactive commits, you do this all during the single commit phase. If
you think it is bad or cumbersome to do all cherry-picking during the
commit, you may temporarily store (using cherry-picking) what you don't
want to commit, using patch queues or bzr shelve.
>> The index helps if your personal workflow is a mess. Otherwise, the
>> index could very well be ditched or disabled by default, and user would
>> use selective commits and stash for that matter, both which make a lot
>> more sense and is easier to understand.
> Just because I use the index to my advantage doesn't mean my workflow is
> a mess. You don't need to stoop to personal attacks to get your point
> across, please.
That "if your personal workflow" in my message was impersonal use of
"your" since it follows the conditional "if". So, it was not intended to
point at you. Sorry if it looked as a personal attack.
My point is that it is generally regarded as a bad programming practice
to commit changes without testing. The index allows and incentives
exactly that, to commit changes that you are not really sure they are
actually correct, since you didn't test what you are committing.
In this use-case, specifically, the correct would be to shelve (bzr
terminology) the changes you don't want to commit, *test* the
application with the selected changes, commit them, than unshelve the
remaining changes back.
> And stash isn't always the best option, although I do
> like it and it is quite useful.
Because Git's stash is very poor, compared for example with bzr shelve.
In bzr shelve, you "stash" specific files and interactively select
specific changes in those files that you want to store away.
> True, which is once again why I have the *opinion* that Git is better.
> However, I quote myself again to get my point across:
Ok. You are fine with your opinion. But then, please, don't say that
other DVCSes are worse because they supposedly don't have a specific
feature, specially if you cannot attest that as a fact.
Note that I didn't say which one is my DVCS of choice until now, except
that it clearly isn't Git. That is because it is not my goal to convince
people that my DVCS of choice is better, but to instigate investigation
about what are the best features each tool has to offer for the project.
For that, we use facts, not personal opinion. (I don't intend to sound
harsh here, but to move the discussion to more profitable grounds).
Juliano F. Ravasi ·· http://juliano.info/
5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96
"A candle loses nothing by lighting another candle." -- Erin Majors
* NOTE: Don't try to reach me through this address, use "contact@" instead.