Re: Splitting up a changeset

[Alex Riesen <raa.lkml@gmail.com>]

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.