Re: how to move with history?

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

Oliver Kullmann, Mon, Jun 18, 2007 22:29:18 +0200:
> > Git does not keep "renaming history". It does not have to, as it keeps
> > how your project looked at each commit (point in history).
> 
> For my purposes, that is a bad thing, since I want to get rid off some parts
> of the history (specifically I want to eliminate some files from history),
> as explained in that last paragraph in my e-mail (with the motivation):
> 
> Is this possible in git?

Yes. You wont be able to change the history after someone copied it
from you (cloned or fetched), because it's "his" now, but you're free
to do anything with your part (or whole) of the history. Happens all
the time. Look at git-cherry-pick, git-format-patch and git-am (and
the new git-filter-branch, but is more for automated mass-rewriting of
big histories).

> And is it possible to add the history of some file to the history
> of another file (in the above application this would be the renamed
> file) ?

Yes, git-format-patch accept pathnames, and its output can be passed
to git-am, which will apply the changes to this file only. git-am also
accepts -pN, so you can move file up a bit. For more complex path
manipulations you'll have to modify the patches (or git-filter-branch
again).

> Altogether, I want to completely change history: It must look as
> if the old files never has been there (from the git-history that is),
> but as it would have had always the new name.

Yep, no problem, just a bit of scripting. Just make sure no one has
that "old" history: it will be hell to merge with them.

> If this is not possible with Git (this "history surgery"),

no, it is not.

> then I hope that at least the future "git-submodule" will not have
> the files in the history which have been filtered out?

depends on how you write the history for that submodule

> So that in this way at least files can be hidden in (sub-)clones (but
> they cannot be renamed) ?

?