Re: Linear history *and* share a branch?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5 April 2012 14:06, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> writes:
>> Hi all,
>>
>> We have been using Git for about a year now in a very small team. So
>> far, everyone has worked on their own local branches and been doing
>> "git rebase master" to make sure their local branches stay in synch.
>> This way we have a nice linear history in master.
>>
>> Recently, it has become useful to share one of these local branches
>> between two devs. Of course, when one of the devs does his usual "git
>> rebase master", he screws up the other dev's environment. Our solution
>> has been to keep rebasing the shared branch but to actually work on a
>> local branch that is rebased on the shared branch. By judiciously
>> using "git reset" and "git pull" on the shared branch the two devs can
>> keep the shared branch in synch and then use "git rebase
>> shared-branch" on their local branch to keep it in synch to. While
>> this works, there is probably a better/simpler solution.
>>
>> Should we simply do "git merge master" instead of "git rebase master"?
>
> That certainly is a sensible thing to do.
>
> But if your people are used to rebasing their own 'master' on top of
> shared 'master', I would imagine that it wouldn't be hard at all for these
> two people that work on a topic branch to do the same for their 'topic'
> branch, no?  Just like rebasing their 'master' on shared 'master', they
> would rebase their own 'topic' on shared 'topic'.

I'm not sure I'm following you here. I agree with what you say but I'm
not clear on exactly how it applies to what I asked. :-/

Rebasing the 'local-topic' on 'shared-topic' branch is certainly
possible but that would not help with linear history with regards to
'master', right? And rebasing 'shared-topic' on 'master' (to get its
updates) would "break" one of the dev's environments. Unless you mean
they should both do that separately? I suppose that's possible. I'm
not clear on the consequences.

It seems that (as Aevar said) we should simply ignore linear history
while 'shared-topic' exists and only rebase on master when integrating
it back into master. But I get the impression that you might have a
slightly different approach in mind?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]