Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
* Branch Management questions
@ 2020-10-15  9:51 Leam Hall
  2020-10-15  9:55 ` Konstantin Tokarev
  2020-10-15 19:57 ` Jeff King
  0 siblings, 2 replies; 5+ messages in thread
From: Leam Hall @ 2020-10-15  9:51 UTC (permalink / raw)
  To: git

1. Two developers.
   Dev A is working on Branch A, off a release_candidate branch.
   Dev B is working on Branch B, off the same release_candidate branch.
   Branches usually run 1-4 weeks.
   Dev A does some work that would help Branch B.
   How does Dev A get the Branch B work that is needed, in a
     way that does not confuse the merge process at the end
     of the release cycle?


2. One developer.
   Working on Branch P, realizes that a new functionality X is
     needed.
   X isn't specific to Branch P, but critical to it.
   What is the best way to deal with X, knowing that further work
     on X will need to be done?




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Branch Management questions
  2020-10-15  9:51 Branch Management questions Leam Hall
@ 2020-10-15  9:55 ` Konstantin Tokarev
  2020-10-15 10:30   ` Leam Hall
  2020-10-15 19:57 ` Jeff King
  1 sibling, 1 reply; 5+ messages in thread
From: Konstantin Tokarev @ 2020-10-15  9:55 UTC (permalink / raw)
  To: Leam Hall, git



15.10.2020, 12:51, "Leam Hall" <leamhall@gmail.com>:
> 1. Two developers.
>    Dev A is working on Branch A, off a release_candidate branch.
>    Dev B is working on Branch B, off the same release_candidate branch.
>    Branches usually run 1-4 weeks.
>    Dev A does some work that would help Branch B.
>    How does Dev A get the Branch B work that is needed, in a
>      way that does not confuse the merge process at the end
>      of the release cycle?

Avoid long-living branches and integrate atomic parts of work into base
branch as soon as it's done and reviewed.

>
> 2. One developer.
>    Working on Branch P, realizes that a new functionality X is
>      needed.
>    X isn't specific to Branch P, but critical to it.
>    What is the best way to deal with X, knowing that further work
>      on X will need to be done?

Rebase P to the top of parent branch after X is integrated (see above).

-- 
Regards,
Konstantin

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Branch Management questions
  2020-10-15  9:55 ` Konstantin Tokarev
@ 2020-10-15 10:30   ` Leam Hall
  2020-10-15 10:39     ` Konstantin Tokarev
  0 siblings, 1 reply; 5+ messages in thread
From: Leam Hall @ 2020-10-15 10:30 UTC (permalink / raw)
  To: Konstantin Tokarev, git

On 10/15/20 5:55 AM, Konstantin Tokarev wrote:
> 
> 
> 15.10.2020, 12:51, "Leam Hall" <leamhall@gmail.com>:
>> 1. Two developers.
>>     Dev A is working on Branch A, off a release_candidate branch.
>>     Dev B is working on Branch B, off the same release_candidate branch.
>>     Branches usually run 1-4 weeks.
>>     Dev A does some work that would help Branch B.
>>     How does Dev A get the Branch B work that is needed, in a
>>       way that does not confuse the merge process at the end
>>       of the release cycle?
> 
> Avoid long-living branches and integrate atomic parts of work into base
> branch as soon as it's done and reviewed.

Unfortunately, for some tasks 1-4 weeks is atomic. The review process is 
being improved as well. We still need a way to integrate the 
longer-lived branches cleanly. We've already had issues where attempts 
meant lost code.


>> 2. One developer.
>>     Working on Branch P, realizes that a new functionality X is
>>       needed.
>>     X isn't specific to Branch P, but critical to it.
>>     What is the best way to deal with X, knowing that further work
>>       on X will need to be done?
> 
> Rebase P to the top of parent branch after X is integrated (see above).

Ah, so "Stop work on P, Resolve X, Rebase P from updated parent"? Let me 
go read up on that, it makes sense.

Thanks!

Leam


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Branch Management questions
  2020-10-15 10:30   ` Leam Hall
@ 2020-10-15 10:39     ` Konstantin Tokarev
  0 siblings, 0 replies; 5+ messages in thread
From: Konstantin Tokarev @ 2020-10-15 10:39 UTC (permalink / raw)
  To: Leam Hall, git



15.10.2020, 13:30, "Leam Hall" <leamhall@gmail.com>:
> On 10/15/20 5:55 AM, Konstantin Tokarev wrote:
>>  15.10.2020, 12:51, "Leam Hall" <leamhall@gmail.com>:
>>>  1. Two developers.
>>>      Dev A is working on Branch A, off a release_candidate branch.
>>>      Dev B is working on Branch B, off the same release_candidate branch.
>>>      Branches usually run 1-4 weeks.
>>>      Dev A does some work that would help Branch B.
>>>      How does Dev A get the Branch B work that is needed, in a
>>>        way that does not confuse the merge process at the end
>>>        of the release cycle?
>>
>>  Avoid long-living branches and integrate atomic parts of work into base
>>  branch as soon as it's done and reviewed.
>
> Unfortunately, for some tasks 1-4 weeks is atomic. The review process is
> being improved as well. We still need a way to integrate the
> longer-lived branches cleanly. We've already had issues where attempts
> meant lost code.
>
>>>  2. One developer.
>>>      Working on Branch P, realizes that a new functionality X is
>>>        needed.
>>>      X isn't specific to Branch P, but critical to it.
>>>      What is the best way to deal with X, knowing that further work
>>>        on X will need to be done?
>>
>>  Rebase P to the top of parent branch after X is integrated (see above).
>
> Ah, so "Stop work on P, Resolve X, Rebase P from updated parent"? Let me
> go read up on that, it makes sense.

If there are two developers, first working on X and and second working on P it may
be possible to reduce or avoid stopping second developer at the cost of possible
additional conflict resolution later.

1. If X is close enough to finished state so it's API won't have big changes,
you cherry-pick X to P and continue work
2. When X is finished and merged to parent branch, rebase P to updated parent
3. If during rebase you hit conflict on patch X, just skip it (it's already in parent)
4. If you hit conflicts in patches following X, you resolve them according to changes
done to X after you cherry-picked its intermediate revision.


-- 
Regards,
Konstantin

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Branch Management questions
  2020-10-15  9:51 Branch Management questions Leam Hall
  2020-10-15  9:55 ` Konstantin Tokarev
@ 2020-10-15 19:57 ` Jeff King
  1 sibling, 0 replies; 5+ messages in thread
From: Jeff King @ 2020-10-15 19:57 UTC (permalink / raw)
  To: Leam Hall; +Cc: git

On Thu, Oct 15, 2020 at 05:51:39AM -0400, Leam Hall wrote:

> 1. Two developers.
>   Dev A is working on Branch A, off a release_candidate branch.
>   Dev B is working on Branch B, off the same release_candidate branch.
>   Branches usually run 1-4 weeks.
>   Dev A does some work that would help Branch B.
>   How does Dev A get the Branch B work that is needed, in a
>     way that does not confuse the merge process at the end
>     of the release cycle?

If Dev A is OK getting _all_ of branch B, the best thing is to simply:

  git checkout branch-a
  git merge branch-b

That goes from:

  old -- a1 -- a2 -- a3   <-- branch-A
     \
      b1 -- b2 -- b3       <-- branch-B

to: 

  old -- a1 -- a2 -- a3 -- M  <-- branch-A
     \                    /
      b1 -- b2 -- b3 ----+    <-- branch-B

and then later when they merge again (either separately, or into
release_candidate), Git knows that "M" is the merge-base instead of
"old":

  old -- a1 -- a2 -- a3 -- M -- a4 -- a5 -- a6 <-- branch-A
     \                    /
      b1 -- b2 -- b3 ----+-- b4 -- b5 -- b6    <-- branch-B

If you need just parts of the work on b, then you'd probably have to
cherry-pick them. They should usually merge together cleanly eventually,
but if you further modify them (or touch nearby areas), that may result
in a conflict on merge into release_candidate.

> 2. One developer.
>   Working on Branch P, realizes that a new functionality X is
>     needed.
>   X isn't specific to Branch P, but critical to it.
>   What is the best way to deal with X, knowing that further work
>     on X will need to be done?

Create a new branch X for the shared topic, and base it not on P but on
whatever the fork point of P is (i.e., your release_candidate or
whatever). Then do some work on X, and merge X into P as needed.
Likewise for any other branch that builds on X.

If you've already built part of X on top of P, then you could
cherry-pick those parts onto the new branch X, and then either:

  - rebase P on top of X (which will drop the redundant bits)

  - merge X into P. You may have to resolve conflicts around the
    redundant parts, and you'll have some redundant commits left in the
    history (but the new merge will become the base for further merges
    between the branches)

-Peff

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-15  9:51 Branch Management questions Leam Hall
2020-10-15  9:55 ` Konstantin Tokarev
2020-10-15 10:30   ` Leam Hall
2020-10-15 10:39     ` Konstantin Tokarev
2020-10-15 19:57 ` Jeff King

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git