On 07/03/13 08:49, Peter Kjellerstedt wrote:
>> -----Original Message-----
>> From: Tom Hacohen [mailto:tom.hacohen@...]
>> Sent: den 27 februari 2013 16:19
>> To: Enlightenment developer list
>> Cc: enlightenment-git@...; Cedric BAIL
>> Subject: Re: [E-devel] [EGIT] [core/elementary] master 02/02: Merge
>> branch 'master' of ssh://git.enlightenment.org/core/elementary
>> On 27/02/13 15:13, Rafael Antognolli wrote:
>>> Ah, and there should be few people needing such permission. For
>>> instance, I still can't imagine a situation where I would need it.
>> Yeah. Well, the only time you might want to need it is if you'd like to
>> merge your topic branch, but I think rebasing on top of master is
>> better anyway. I don't see a point in merging as well, so...
> Using rebase simplifies the history, no doubt about that. And for a
> project where you have multiple people with push access it may be
> easier for everyone. And if you are used to SVN this is probably
> easier as well. ;)
> However, the benefit of using merge to integrate topic branches is
> that you can tell which commits make up a change. At the company I
> work for we even require that all topic branches are merged using
> --no-ff, i.e., there will be an explicit merge even if a fast forward
> merge would have been possible. That way, if a change (which can be
> made up of multiple commits) needs to be reverted, we can easily see
> which commits are involved.
> Another situation where merging topic branches is more beneficial is
> if you have to maintain multiple versions of your code at the same
> time. This is typically done using multiple target branches (master
> being one of them). If you use rebasing you would have to duplicate
> your changes for each target branch. Using merge, as long as the
> topic branch was branched off from a point prior to the starting
> point of each target branch, you can just merge the topic branch
> into each target branch where it is appropriate.
Yes, I complete agree with your point about the topic branch and
--no-ff. Daniel and I actually talked about it the other day and I came
to the conclusion I'd like to do something really nice:
Rebase a topic branch, and then merge with no-ff. This means that the
merge commit will always appear but will always be empty. This will make
a bunch of commits package into their own stream while still retaining
the benefits of having linear history.
However, the whole rebase only policy is just for the meanwhile, until
we decide how exactly we would like to do everything.