Re: Splitting up a changeset

From: Alex Riesen <raa.lkml@gmail.com>
Date: Aug 20, 2007, 19:31 UTC
Message-ID: <20070820193128.GC5544@steel.home>
In-Reply-To: <e1bf234c0708200632g3a2282bfr76863555493d513@mail.gmail.com>

Frank Showman, Mon, Aug 20, 2007 15:32:11 +0200:

Show 6 quoted lines

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