how to move with history?

Hello,

I try to understand "git mv"; here is how far I got:

1. Suppose I have "file" (under git control).

2. I issue "git mv file new_file".

3. Then I have to commit the renaming.
I can't find anything on how to do this
(neither in the git-mv- nor in the
git-commit-documentation).
So a hack is to use "git commit -a".
Apparently this works.

4. Now I have "new_file" in the repository, but
without history (except of the renaming operation),
and I have still "file" in this history, but
I can no longer get access to the history of
"file" via "gitk file" ?

This looks a bit strange to me (the renamed file has no history, the old file still lurking around, but not easily accessible).

But perhaps this is as it is (since other solutions might be even stranger under certain circumstances)?

Is it then possible to complete the move, that is, to really "move" the history of "file" to the history of "new_file", so that after that except of some moving-information there is no trace left of "file", while "new_file" has taken over the old history?

(The motivation is as follows: I want to make the library I've developed available as a clone, but I have the problem that there are special files which I do not want to make available. So I hope that in the future with "git-submodule" I can filter out the special files, creating a (sub-)repository without the special files which then can be freely cloned. Now the special files yet are spread around, and to solve this I want to introduce a special naming-pattern for the special files (so that it becomes easy to separate the special files from the rest). But in order to do so I need the ability to fully move the special files to their renamed versions, completely with history (otherwise by browsing the history of the clone the special files would be revealed).)

I would be glad for any help!

Oliver

Oliver Kullmann, Mon, Jun 18, 2007 21:16:07 +0200:

Just git-commit. git-mv is only so you don't have to run git add on the new file name and don't need to run "git-commit -a" afterwords.

Even a plain "mv file new_file; git add new_file" would have worked.

It does. Try "git log file new_file". After committing, that is

Well, you didn't commit the change yet.

Git does not keep "renaming history". It does not have to, as it keeps how your project looked at each commit (point in history).

On Mon, Jun 18, 2007 at 09:49:07PM +0200, Alex Riesen wrote:

I think, there is a bit of a misunderstanding going on, but this doesn't matter,
I believe now that I understand what "git mv" is doing (thanks!).
 
So that leaves then 2 open question:

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?

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) ?

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.

If this is not possible with Git (this "history surgery"), then I hope that at least the future "git-submodule" will not have the files in the history which have been filtered out?

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

On Mon, Jun 18, 2007 at 09:29:18PM +0100, Oliver Kullmann wrote:

Oh, so even if somebody checks out a previous version of the project, you don't want them to see that file at the old name any more?

The git history is totally immutable, by design--the SHA1 name of a commit is taken over the commit, the contents of the entire tree at that point, and any commit(s) that precede this commit--hence it recursively summarizes the entire history of the project.

So if you want to erase all memory of a path from the git history, then you have to rebuild it all. Which is possible--it'd just mean creating a new project and writing a script to import every version into the new project....

--b.

On Mon, Jun 18, 2007 at 04:31:16PM -0400, J. Bruce Fields wrote:

Isn't that what git-filter-branch is for?

Gruesse,

måndag 18 juni 2007 skrev Oliver Kullmann:

Git does not keep file histories at all. As a consequence it does not track renames either.

The history in Git is the history of the *whole* tree as a chunk, not a sum of file histories. It takes snapshots of your project, that's all. Then there are tools to do magic on top of that (e.g. git-blame).

There are tools to rewrite histories, but then you are violating of the key principles of git, that history is immutable so git may not be nice to you after history rewriting. Cogito has a powerful command.

-- robin

Oliver Kullmann, Mon, Jun 18, 2007 22:29:18 +0200:

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

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

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.

no, it is not.

depends on how you write the history for that submodule

?

Thanks for all the replies!

Now I see pretty clear; a quick summary (in case somebody else wants to learn from this):

1.

"git mv file new_file" seems to be (exactly?) equivalent to

mv file new_file git rm file git add new_file

(Perhaps this information could be added to the git-mv-documentation? I would have found it useful (since I had a different expectation).)

2. To do something with the history, for example to rename "file"
to "new_file" also in the whole history, a new repository (or
a new branch) has to be created. Three possibilities:
 
 (a) Using the basic git-functionality, re-creating a repository
     by re-creating all commits (with appropriate changes) by "hand"
     or "script".
 (b) More convenient, the upcoming "git-filter-branch" apparently
     makes filtering out easier.
 (c) Or, apparently more powerful, with "cg-admin-rewritehis"
     (part of the cogito-tool) we have quite a powerful tool
     for creating a branch with a (re-created and modified)
     history (the documentation explicitely mentions how to
     remove a file from history --- that is, in the new branch).

Hope that's correct.

Thanks a lot to all!

Oliver

Oliver Kullmann wrote:

git-filter-branch _is_ cg-admin-rewritehist (or at least should be).