Hades Blag comments on Git Is Your Friend not a Foe Vol. 2: Branches

Comment on Git Is Your Friend not a Foe Vol. 2: Branches by Edward

2010-01-25T21:00:58Z

Okay, I’ll try to clarify that in next post, thanks.

Comment on Git Is Your Friend not a Foe Vol. 2: Branches by Marcos Dione

2010-01-25T20:55:32Z

The first article in this series was great. in this one you got me lots when you started to explain detached heads. I think it stems from the point were you talk about checkouts while not explaining what they are. Maybe a couple more of graphs would explain better?

Comment on Git Is Your Friend not a Foe Vol. 2: Branches by Edward

2010-01-24T20:07:46Z

The way I work in subversion it happens that fixes in released versions are merged into trunk and also that features are backported. With git I have apparently to only work in one direction.

(I presume you meant “that fixes are backported”)

No, you have not. That document describes a typical workflow agreement, that is followed by git.git. As it says, “Do not always take them [the rules] literally; you should value good reasons for your actions higher than manpages such as this one”. I’ve worked in a project, where fixes were backported too — with cherry-pick. And it worked out just fine. Git gives you the freedom to create your own workflow, not imposing you a single one.

The direction of work is a question of taste; AFAIK, most people consider it easier (from a programmer’s perspective) to forward-port fixes, not backport them.

Comment on Git Is Your Friend not a Foe Vol. 2: Branches by Christoph Bartoschek

2010-01-24T18:50:40Z

Nobody said that it is unfair. git merge and svn merge are just differnt concepts and one should know what to compare. svn merge with merge tracking is better than git cherry-pick. And git merge is better because svn does not have such a thing.

Given the workflows and concepts of svn there is no need for a functionality like git merge.

The git workflow has different problems than the svn one. The rules mentioned in the document Edward linked should be followed. For example the rule “Merge upwards”. The way I work in subversion it happens that fixes in released versions are merged into trunk and also that features are backported. With git I have apparently to only work in one direction.

However I do not want to defend subversion. Considering everything I would like to switch to git. The only issue that prevents me is a useful svn:externals equivalent to git. git submodules are not usable.

Comment on Git Is Your Friend not a Foe Vol. 2: Branches by Ian Monroe

2010-01-24T15:14:23Z

So it’s unfair to compare svn merge and git merge, since the latter is so much better? At least that’s how I read it.

Of course SVN and Git have very different workflows, Edward is just making the argument that Git’s is better.

Comment on Git Is Your Friend not a Foe Vol. 2: Branches by Edward

2010-01-24T13:38:49Z

There is a manual page called gitworkflows (http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html) that hopefully answers your question.

I tried to cover some of the pitfalls I’ve seen new Git people falling into (including myself), maybe I will post about more complicated things later.

Comment on Git Is Your Friend not a Foe Vol. 2: Branches by Christoph Bartoschek

2010-01-24T12:19:23Z

I would say that you overstimate the complexity of subversion merges. Especially in recent versions it got better.

However one cannot compare git merges and subversion merges because, as subversion does not know branching as it is done in git, it does not know merging. If one wants to compare, then one has to compare git cherry-pick with svn merge. And here svn has now a way better implementation. Git cherry-pick has the same problems the old svn merge implementation had.

My biggest problem with git is that I do not completely grasp how the workflow looks like when there are different versions of a software and how fixes are distributed between the versions. With subversion this is easy because one just merges the changes but if I understand it correctly the flow of changes is important in git to not mess up during merges. Are you going to explain how the interactions between development, trunk, beta and released versions are?

Comment on Git Is Your Friend not a Foe Vol. 2: Branches by arwa

2010-01-24T12:21:21Z

Regarding svn: “If you want to merge it back, you need to remember the revision number, when you created the branch”. This is no longer true in up to date svn versions since a year or so. This is handled by svn internally now what really is a big step for svn.