This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Replacing CVS - decision time: part 2


2010/5/1 Alex Schuilenburg <alexs@ecoscentric.com>:
> On 2010-04-30 16:04, BjÃrn Forsman wrote:
>> 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.)
>>
> I disagree. ÂIn a commercial environment with multiple projects there
> are a wide variety of demands that are placed on the DRCS. I certainly
> have made use of all the different branch types and each has been very
> useful in the context it was required. Âhg is stronger than git with
> respect to branches IMHO, which is why I originally posed my question to
> you.

What exactly makes hg branching stronger? Because it has more branch
types? I don't feel git is lacking anything in this respect, rather I
find it a bit simpler and more flexible. Maybe we should agree to
disagree on what system has the better branching model.

> [...]
>>>> 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.
>>
> I disagree. Think about it in opposite terms. ÂWhen you pull, surely you
> want all the changes, not just the branch you are currently checked
> out? ÂSo why should pushing be different?

Having thought about it a bit more, I think I understand why "push"
works differently in hg and git. In git it makes sense not to push
everything by default because in git branches are often used for
experimental stuff that may not be ready for upstream. In hg it makes
sense to push all by default because if there are named branches they
must surely be meant for upstream. (A hg user wanting to keep stuff
hidden from upstrem should use queues or local branches.)

> Also, why should the current
> state of your working directory have any bearing on the repository when
> you push/pull? All you are doing is synchronising what is under the hood
> so that it is available to you when you want.
>
> Mercurial to me seems more open in this respect. If you don't want your
> changes published, you should be using mercurial queues or lcocal
> branches. ÂYou can check what changes will be published with the
> outgoing command and you always get prompted if you push a new branch
> (so little risk in publishing a branch until you are ready). IMHO there
> is a greater risk of something being forgotten if only your current
> branch is pushed.

The hg workflow just seems more complex to me: use a queue or local
branch and if it's good, create a named branch and push it. With git I
create a branch and if it's good I push it.

Git also allows me to see what would happen when I push. It is also
possible to push everything at once with the --all flag.

> I guess it really comes down to the way you use the DRCS.

Agree.

>>>> 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.
>>
> Rewriting history is IMHO very very dangerous and defeats the purpose of
> a RCS. ÂThat purpose is after all to track changes to your code. ÂIMHO
> this ability to change history is more about protecting an individual's
> vanity than anything else. If you need to work at a level where you are
> fixing typo's in commits, then you are IMHO using the DRCS incorrectly.
> You should be using queues for tracking rapid prototyping and you should
> be making sure that your commits do not break the code base, and if they
> do (accidents do happen), then a full history of how to fix it is
> preserved for those who ended up with the broken code.
>
> Yes, you can recover in git, just like taking backups. But why should
> anyone need to figure anything out? ÂIf you don't hand out rope, people
> will not hang themselves...

Rewriting history in *public* trees is bad. In local trees it's really
nice. Isn't hg queues a way to allow "history rewriting" locally? So I
guess we actually agree on this one :-)

> IMHO you should not be able to rewrite history in a shared repository,
> period. ÂThat is asking for confusion and trouble. If we want eCos users
> to use the eCos public repository to make commercial products based on
> eCos, which we do, you should not be able to mess them around. When
> making and supporting commercial releases, one of the *most* important
> things is to be able to reproduce what is shipped to a customer. ÂYou
> should not have to play around with tarballs of sources to ensure that
> you can create a working directory with the same state as what was
> shipped. ÂI cannot think of a single instance when you would want
> anything different. ÂIf you make a mistake, you need to track how the
> mistake was fixed so those effected have a history of what went wrong
> and what the fix is, not for history to be rewritten so the mistake can
> be hidden.

I agree with you.

>>> 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.
>>
> Both gain each other's features over time IMHO, which is a good thing.
>
> This is why anyone arguing in terms of functionality that hg is better
> than git or git is better than hg is likely going to be wrong in a
> couple of months.
>
> I'll give you that git has more of it's internals exposed so that some
> operations can be done with fewer commands, but that really is only of
> benefit to a small handful of power-users. ÂIn these respects it will be
> like putting a novice driver behind the wheel of a dragster when all
> they want to get is from A to B and if you give people enough rope...
> And of course the power-users will not lose out because of hg-git or
> git-hg or whatever...

I'm not aware of a tool like hg-git [1] that works the other way around.
Having such a tool would be great! Do you have a link?

[1]: http://hg-git.github.com/

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]