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

-

[ message continues ]

Just git-commit. git-mv is only so you don't have to run git add on




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

-

[ message continues ]

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

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

-

[ message continues ]

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

[ message continues ]

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

Gruesse,
-- 
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
-

[ message continues ]

m
[ message continues ]

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

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

Yep, no problem, just a bit of scripting. Just make sure no one has



?

-

[ message continues ]

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


-

[ message continues ]