Re: [ECOS] Replacing CVS - decision time: part 2

[BjÃrn Forsman <bjorn dot forsman at gmail dot com>]

Hi Jonathan,

2010/4/29 Jonathan Larmour <jifl@jifvik.org>:
> On 29/04/10 14:25, BjÃrn Forsman wrote:
>> Hi,
>>
>> 2010/4/28 Alex Schuilenburg <alexs@ecoscentric.com>:
>>> On 2010-04-28 20:26, BjÃrn Forsman wrote:
>>>> [,,,]
>>>> Git may be worse than hg on Windows, but IMHO git has better branching
>>>> and tagging.
>>>>
>>> Could you please explain why you think git has better branching and tagging?
>>
>> This below is what I *think* is correct, based on my current knowledge. It
>> may very well be wrong. If so, maybe someone will enlighten me?
>>
>> hg branching (skipping unnamed branches and entire repo forks/clones):
>> * either bookmark branches (local branch)
>> * or named branches (global branch)
>>
>> A hg bookmark is a lightweight branch that can only be used locally. It
>> cannot be pushed to another repo. A named branch can be pushed to another
>> repo. So when using hg one would have to choose branch type at branch
>> creation time. With git you create branches and later choose to push them
>> if you want to.
>
> A branch is just a pointer to a revision head. So if you have an hg
> lightweight branch (bookmark) and you want to be able to push it, all you
> should need to do is set the branch based on the bookmark.

So in effect, there is no need to choose branch type up front then. I
didn't know that. But I still think it's cleaner to have one branch
type, like git has. (Ok, I know about remote branches, but... they are
remote... It just feels like a different thing.)

> You won't have
> the advantage of having the earlier changes associated with that bookmark
> marked in the metadata as associated with the new branch up to that point,
> but having branches in metadata isn't something git gives you at any point
> anyway, so hg is still better off than git in this respect.

Would you mind explaining why this makes hg better than git?

>> You can also push specific branches, not just all at
>> once like hg does.
>
> hg push -b <branch>

I didn't know about that. However, wouldn't it be an accident waiting to
happen if the SCM system *defaults* to push everything? IMHO git seems
a bit safer in this respect.

>> You can also rename git branches. Hg named branches are stored as
>> metadata in changesets which makes it impossible to rename them.
>> Named branches cannot be deleted either, only hidden.
>
> This is for the excellent principle that named branches are first class
> revision-controlled objects and history should not be mutable. You should
> not be able to easily change history in a version control system. If
> you're using named branches, that's presumably because you want to be able
> to push them, in which case they should be under version control just as
> much as anything else.

Maybe we feel a bit differently about what a SCM system should be able
to do with respect to history. I think git's ability to change history
is one of its best features. Without it I would feel like a Unix shell
user without the 'rm' command. Note that git is a *lot* less dangerous
than a pure 'rm' command. Git operations that are said to change or
delete history is really just about creating a new alternative history.
The old history is still there and you must run 'git gc --prune' if you
want to clean up unreferenced history. And even that command does not
delete commits that are younger than 2 weeks or so (configurable). So it
is virtually impossible to do something that is not undoable. Every git
user knows (or should know!) that rebasing (changing history) should
never be done in public repos. It's just something to help you manage
you local repo. git would never change history behind you back. For
instance, if someone broke the rule and changed history in a public
repo, others pulling from that repo will be able to figure it out.

> That said, it is evidently possible to do so if you jump through some hoops:
> http://mercurial.selenic.com/wiki/PruningDeadBranches
> but really marking the old branch inactive (the first option) would be the
> best option. If you don't want to see inactive branches by default in the
> output of 'hg branches' you can add this to ~/.hgrc:
>
> [defaults]
> branches = -a

It seems hg is gaining git features bit by bit. I'm particularly
thinking about rebasing and the staging area, and as you note, branch
deletion. hg and git really seem to converge over time.

>> About tagging:
>> hg supports local and global tags. local tags cannot be transferred to
>> other repos. global tags can be pushed to other repos and are stored in a
>> .hgtags file, versioned as any other file.
>> This means:
>> * When tagging changesetN, changesetN+1 is the one that has the newly
>> Â created tag included in .hgtags. A bit confusing?
>
> I agree it seems unexpected, but makes sense once you understand it
> (although I admit that that sort of argument is something I've mentioned
> many times over as a problem with git). All you have to remember is not to
> look at .hgtags to see the tags - use 'hg tags' which is there for exactly
> that purpose.

Maybe .hgtags should have been in the .hg/ directory then?

>> * hg must scan all versions of .hgtags in all branches to find its tags
>
> Yes - this would take a trivial amount of time surely? I would hope a
> well-managed repository will not have many hundreds of active branches
> ('hg tags' does not look at inactive branches).
>
>> * *all* tags in .hgtags will be transferred to other repos upon push
>
> NB hg has local tags, using 'hg tag -l'. I believe you know that, but I
> realise I didn't note that in my first comparison email.
>
> Again the reason tags in .hgtags are transferred is because that's the
> distinctive purpose of those sort of tags, rather than local tags. When
> people clone the repo, they should get the tags people want to come with
> it as well. It is of course trivial to create a first class tag from a
> local tag.
>
>> git allows pushing specific tags, I don't have to choose up front whether
>> this new tag is to be global or not. I create it and later decide if I want
>> to push it. This seems more flexible to me. git supports annotated tags and
>> simple tags, but both seems to be able to be selectively pushed to other
>> repos.
>
> In hg, you would create local tags, and then can choose to make them
> properly version controlled tags in .hgtags.
>
> If you forget until you're pushing, then you can always retag as a
> lightweight tag and delete the old tag, before you push so upstream never
> sees it in practice (especially if using mercurial queues).
>
>> I found [1] very helpful in understanding more about hg branching. It also
>> compares hg branching to git. And [2] is great for comparing hg vs. git
>> consepts. It is easy to read.
>
> I've already looked at those, although [1] isn't entirely complete (or is
> partially obsolete).
>
>> BTW, about two years ago I was in the process of deciding between git and
>> hg myself. It was a very close call, but I choose hg because it had better
>> Windows support (at least at that time) and was written in Python. However,
>> nearly all projects I worked with after that point was using git, so I
>> became a git user. I love the way git completely changed the way I think
>> about and work with a SCM system. But I guess hg users feel just the same
>> way :-)
>
> I suspect there's a lot in common to any DVCS. As has been said, the
> switch to any sort of DVCS will be a huge step forward. Albeit, in either
> case, also requiring a step change from eCos users in understanding DVCS
> concepts - what's been under debate is how much for hg vs. git; but both
> involve some amount of learning curve.
>
> Given hg-git, either way round, no-one will be that disenfranchised.

Yeah, I'm going to be very pleased either way, hg or git. It's a big
leap forwards from CVS.

Thanks for your feedback. I know more about hg now.

Best regards,
BjÃrn Forsman

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss