Splitting up a changeset

Splitting up a changeset

[Frank Showman]

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

Re: Splitting up a changeset

[Adam Roben]

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

Re: Splitting up a changeset

[Alex Riesen]

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-change

If 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

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

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>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]