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

Re: git merge and cherry-pick and duplicated commits?

From
Sitaram Chamarty <sitaramc@gmail.com>
Date
Jan 14, 2009, 15:53 UTC
Message-ID
<slrngms2k7.s3e.sitaramc@sitaramc.homelinux.net>
In-Reply-To
<2729632a0901132333h6caf9facu871869abce5597c1@mail.gmail.com>
On 2009-01-14, skillzero@gmail.com <skillzero@gmail.com> wrote:
Show 20 quoted lines
> I guess maybe a better question is how do people normally handle
> situations like mine where I did some work on branch X and I later
> realize I need only a portion of that work on branch Y? I'm not sure
> how I can change my workflow to completely eliminate these situations.
> For example, I often start a branch to add a new feature and I end up
> fixing bug A on that branch. Then other people on my team decide they
> need the fix for bug A immediately and can't wait for me to finish my
> feature branch and do a full merge.
>
> Is there some way I can change my workflow such that I can fix bug A
> (maybe on a separate branch?) and somehow apply it to both both
> branches in a way that won't result in duplicate commits?
>
> Does this kind of thing ever happen with the Linux kernel or git
> itself: somebody does a fix as part of their topic branch and the
> Linux kernel or git master wants that particular fix now, but is not
> ready for the full topic branch? Would they just suggest the fix be
> separated into its own topic branch and that merged? If so, how would
> that new topic branch merge into the original topic branch without
> resulting in a duplicate commit when it's later merged into master?

If I understand you right, you're talking about a situation where a particular change is in two different branches, but the SHA is different.

And yet, in your scenario, both of these branches somehow get merged into the final branch.

In other words, a DAG of branches merging itself has a merge, if that makes sense :-)

You may need to think about how commits flow from branch to branch, and what branches are private, and therefore can be rebased or change history, and what are public, and how often and when the private ones rebase off of the public ones.

Previous: skillzero@gmail.com
Message 16 of 16 in “git merge and cherry-pick and duplicated commits?”
  1. skillzero@gmail.comJan 14, 2009
  2. Brian GernhardtJan 14, 2009
  3. skillzero@gmail.comJan 14, 2009
  4. Johannes SixtJan 14, 2009
  5. skillzero@gmail.comJan 14, 2009
  6. Johannes SixtJan 14, 2009
  7. skillzero@gmail.comJan 14, 2009
  8. Peter BaumannJan 14, 2009
  9. Junio C HamanoJan 14, 2009
  10. Markus HeidelbergJan 15, 2009
  11. Boaz HarroshJan 14, 2009
  12. Nanako ShiraishiJan 14, 2009
  13. Thomas RastJan 14, 2009
  14. Alex RiesenJan 14, 2009
  15. skillzero@gmail.comJan 14, 2009
  16. Sitaram ChamartyJan 14, 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.