how to move with history?

how to move with history?

[Oliver Kullmann]

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

Re: how to move with history?

[Alex Riesen]

Oliver Kullmann, Mon, Jun 18, 2007 21:16:07 +0200:
> 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).

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.

> So a hack is to use "git commit -a".  Apparently this works.

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

> 4. Now I have "new_file" in the repository, but without history
> (except of the renaming operation),

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

> and I have still "file" in this history, but I can no longer get
> access to the history of "file" via "gitk file" ?

Well, you didn't commit the change yet.

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

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

Re: how to move with history?

[Oliver Kullmann]

On Mon, Jun 18, 2007 at 09:49:07PM +0200, Alex Riesen wrote:
> Oliver Kullmann, Mon, Jun 18, 2007 21:16:07 +0200:
> > 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).
> 
> 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" afterwards.
> 
> > So a hack is to use "git commit -a".  Apparently this works.
> 
> Even a plain "mv file new_file; git add new_file" would have worked.
> 
> > 4. Now I have "new_file" in the repository, but without history
> > (except of the renaming operation),
> 
> It does. Try "git log file new_file". After committing, that is
> 
> > and I have still "file" in this history, but I can no longer get
> > access to the history of "file" via "gitk file" ?
> 
> Well, you didn't commit the change yet.
> 
> > This looks a bit strange to me (the renamed file has
> > no history, the old file still lurking around, but not
> > easily accessible).
> 


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:

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

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

> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: how to move with history?

[J. Bruce Fields]

On Mon, Jun 18, 2007 at 09:29:18PM +0100, Oliver Kullmann wrote:
> On Mon, Jun 18, 2007 at 09:49:07PM +0200, Alex Riesen wrote:
> > 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):

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.

Re: how to move with history?

[Frank Lichtenheld]

On Mon, Jun 18, 2007 at 04:31:16PM -0400, J. Bruce Fields wrote:
> On Mon, Jun 18, 2007 at 09:29:18PM +0100, Oliver Kullmann wrote:
> 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....

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

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

Re: how to move with history?

[Robin Rosenberg]

måndag 18 juni 2007 skrev Oliver Kullmann:
> > 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?
>
> 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) ?

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

Re: how to move with history?

[Alex Riesen]

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

?

Re: how to move with history?

[Oliver Kullmann]

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

Re: how to move with history?

[Jakub Narebski]

Oliver Kullmann wrote:

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

git-filter-branch _is_ cg-admin-rewritehist (or at least should be).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git