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

Re: Splitting up a changeset

From
JHJan Hudec <bulb@ucw.cz>
Date
Aug 20, 2007, 19:53 UTC
Message-ID
<20070820195351.GF8542@efreet.light.src>
In-Reply-To
<20070820193128.GC5544@steel.home>
On Mon, Aug 20, 2007 at 21:31:28 +0200, Alex Riesen wrote:
Show 8 quoted lines
> Frank Showman, Mon, Aug 20, 2007 15:32:11 +0200:
> > What happens to remote repositories that already have the big
> > original changeset (and possibly changes based on it)?
> 
> If someone (or something) has already fetched, pulled, cloned or
> otherwise copied them, you basically can't do anything anymore.
> It is a thing you fundamentally cannot do, unless you're prepared to
> deal with consequences. Not hard, but can be unexpected for some.

If something might already be based on the unsplit change, you probably want to make the last commit of the split be a merge from the unsplit. Merge will notice that the changes on both sides are the same and resolve them cleanly and any further merges won't see them as differences.

If only you or only people you know may have changes based on unsplit, you can rebase those changes to split for slightly simpler history.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>
Previous: Alex Riesen
Message 4 of 4 in “Splitting up a changeset”
  1. Frank ShowmanAug 20, 2007
  2. Adam RobenAug 20, 2007
  3. Alex RiesenAug 20, 2007
  4. Jan HudecAug 20, 2007

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.