What I really want to do is merge a couple of files from a changeset at a time. Given that GIT doesn't track files, the only sensible way to do that seems to split up the changeset (I want GIT to track the merges) and then merge (cherry pick) the split up stuff.
Is there some (reasonably simple) way to do that? What happens to remote repositories that already have the big original changeset (and possibly changes based on it)?
-- Frank
Adam RobenRe: Splitting up a changeset
On Aug 20, 2007, at 6:32 AM, Frank Showman wrote:
> What I really want to do is merge a couple of files from a changeset > at a time. Given that GIT doesn't track files, the only sensible way > to do that seems to split up the changeset (I want GIT to track the > merges) and then merge (cherry pick) the split up stuff. > > Is there some (reasonably simple) way to do that?
One way I've done this in the past is like this:
git cherry-pick -n <rev-to-split-up> git reset HEAD git add <first-batch-of-files> git commit git add <next-batch-of-files> git commit ...
-Adam
Alex RiesenRe: Splitting up a changeset
Frank Showman, Mon, Aug 20, 2007 15:32:11 +0200:
> What I really want to do is merge a couple of files from a changeset > at a time. Given that GIT doesn't track files, the only sensible way > to do that seems to split up the changeset (I want GIT to track the > merges) and then merge (cherry pick) the split up stuff. > > Is there some (reasonably simple) way to do that?
yes. This, for example, will make two commits out of one:
$ git checkout -b split-the-change the-change^
$ git checkout the-change -- files-you-want-in-commit1...
$ git commit -c the-change
$ git checkout the-change -- files-you-want-in-commit2...
$ git commit -c the-changeIf you want also split the changes _in_ the files, you'll have to edit them after that "git checkout the-change -- files...".
The result is in branch starting where the-change was at. You can decide now what you want to do with the commits.
> 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.
Re: Splitting up a changeset
On Mon, Aug 20, 2007 at 21:31:28 +0200, Alex Riesen wrote:
> 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>