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

Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy

From
Avery Pennarun <apenwarr@gmail.com>
Date
Jul 28, 2008, 20:00 UTC
Message-ID
<32541b130807281300yb93884anf28f3ddb2cc507d@mail.gmail.com>
In-Reply-To
<20080728192651.GA26677@sigill.intra.peff.net>
On 7/28/08, Jeff King <peff@peff.net> wrote:
Show 14 quoted lines
> My situation was two long-running branches, "stable" and "devel",
>  both of which were worked on by many developers. One person was in
>  charge of integration and branch management. They wanted "stable" to
>  get the contents of "devel" (which were now ready for release), ignoring
>  any small fixes that had been done on "stable" (since they had all been
>  moved over to "devel" previously, but in subtly different ways that
>  would create conflicts). And "git reset" was not an option, because they
>  wanted to keep the history of "stable" in case those fixes needed to be
>  looked at later.
>
>  So the logical sequence was:
>
>   git checkout production
>   git merge -s theirs master

I have to say, this somehow feels wrong to me. What you're saying is essentially that "stable has already been merged into devel" followed by "and now we want to catch stable up to devel."

It really is two separate thoughts, and merging devel directly into stable - literally by *undoing* all the changes from stable - doesn't sound like it should be considered a safe operation.

Personally, I've started enjoying the "--no-ff" option to git-merge. That way I can do

   git checkout master
   git merge production
   git checkout production
   git merge --no-ff master

The latter merge isn't really a "merge" since it could have been just fast forwarded. But it avoids the aesthetic problems of commits like "merge production into master" showing up in the master branch. It also means that "git reset --hard HEAD^" works whether or not a fastforward would have been theoretically possible.

Of course, this whole discussion is really just about how to make your log look cleaner, and we could debate forever about that. It may make sense to simply provide "theirs" as an exact mirror of "ours" if only in the name of symmetry.

Have fun,
Avery
Previous: Jeff KingNext: Johannes Schindelin
Message 7 of 28 in “theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy”
  1. Sverre RabbelierJul 28, 2008
  2. Miklos VajnaJul 28, 2008
  3. Sverre RabbelierJul 28, 2008
  4. Jeff KingJul 28, 2008
  5. Johannes SchindelinJul 28, 2008
  6. Jeff KingJul 28, 2008
  7. Avery PennarunJul 28, 2008
  8. Johannes SchindelinJul 28, 2008
  9. Sverre RabbelierJul 29, 2008
  10. Jeff KingJul 29, 2008
  11. Jeff KingJul 29, 2008
  12. Johannes SchindelinJul 29, 2008
  13. Jeff KingJul 29, 2008
  14. Sverre RabbelierJul 29, 2008
  15. Junio C HamanoJul 29, 2008
  16. Jeff KingJul 29, 2008
  17. Mike RalphsonJul 29, 2008
  18. Jeff KingJul 29, 2008
  19. Sverre RabbelierJul 28, 2008
  20. Junio C HamanoJul 28, 2008
  21. Sverre RabbelierJul 28, 2008
  22. Junio C HamanoJul 28, 2008
  23. Sverre RabbelierJul 28, 2008
  24. Junio C HamanoJul 28, 2008
  25. Junio C HamanoJul 28, 2008
  26. Sverre RabbelierJul 28, 2008
  27. Jeff KingJul 29, 2008
  28. Junio C HamanoJul 29, 2008

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.