git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Commiting changes onto more than one branch

From
MJMike Jarmy <mjarmy@gmail.com>
Date
Nov 25, 2009, 19:43 UTC
Message-ID
<6b4a562b0911251143s63f09f7bwe4b67d6871d8a1b2@mail.gmail.com>
In-Reply-To
<7vaayazb2a.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> I take it to mean that even though v[345] have diverged, the area that the
> particular change you have in mind has to touch haven't changed since they
> forked.

Correct. Sometimes, there might be unrelated changes to a given file or files, in which case conflict resolution will be done manually. But generally speaking, bugfixes will tend to go on quite cleanly.

Show 21 quoted lines
> Instead, you can fork such a topic from the latest common.
>
>        o--o--o--o--o--o--o--o v4
>       /
>    --o--x--x--x--x--x--x--x v3
>       \
>        Y---Y
>            your change(s)
>
> and merging this to v3 and v4 will have the desired effect.
>
>        o--o--o--o--o--o--o--o---------M v4
>       /                              /
>    --o--x--x--x--x--x--x--x---M v3  /
>       \                      /     /
>        Y---Y----------------.-----.
>            your change(s)
>
> The merges will incorporate this particular change alone without dragging
> anything else.  When you merge it to v4, none of the unrelated 'x' will be
> merged into it.
That sounds a whole lot like what I need.

Right now I'm thinking that the right approach is that once we have released v3, and started working on v4 heavily, we will probably not want to check any commits directly into v3. Bugfixes will have their own branch. If there is a whole new project or whatever being done on top of v3, it will have its own branch as well.

So once v3 is in beta or whatever and we declare a code freeze, we could have a rule that all commits must be merge-commits coming from dedicated branches with descriptive, intelligible names. For each dedicated branch, some thought will have to be given as to just where off of v3 to branch it from (not just carelessly off the latest tip). Meanwhile, new development will continue on v4, with lots of commits going right into the branch (or into v4 sub-branches with occasional merge-commits into v4).

Previous: Junio C HamanoNext: Daniel Barkalow
Message 6 of 12 in “Commiting changes onto more than one branch”
  1. Mike JarmyNov 25, 2009
  2. Eugene SajineNov 25, 2009
  3. Mike JarmyNov 25, 2009
  4. Avery PennarunNov 25, 2009
  5. Junio C HamanoNov 25, 2009
  6. Mike JarmyNov 25, 2009
  7. Daniel BarkalowNov 25, 2009
  8. Andreas SchwabNov 25, 2009
  9. Thomas RastNov 25, 2009
  10. Jakub NarebskiNov 25, 2009
  11. Mike JarmyNov 25, 2009
  12. Nicolas PitreNov 25, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.