Linus Torvalds [off-list ref] writes:
On Wed, 18 Jan 2006, Ryan Anderson wrote:
quoted
Assuming both repositories are clean, no extraneous files, and without
testing, of course:
... "coolest merge ever" recipe here ...
No history rewritten,
Right.
quoted
merging with the old repositories should, at least theoretically, work,
etc.
No. This - and the history rewriting - both have a fundamental problem: it
becomes totally impossible to merge back any changes of the subprojects,
at least automatically.
Right.
In the "gitk" case, we could actually continue to merge stuff after a
join, but that was largaly because there was no renaming. That's a very
special case, and it also became impossible to merge back.
Correct.
Now, let's see what Junio comes up with,...
Well, since the reason the original RFI came was "somehow we
forgot these things are together but ended up having to and need
a way to rectify the situation", in this particular case,
merging back the changes to subprojects (which is very awkward
if not impossible after a "coolest merge ever") is a non issue.
Tracking history across renames is something we have only half
of the needed support. We can notice rename points but there is
no way to tell our usability tools to automatically follow it.
IOW "whatchanged r1/hello.c" will stop at the point the
original project renamed hello.c to r1/hello.c in preparation
for the coolest merge and you have to restart whatchanged at
that commit with "whatchanged $that_commit hello.c" to go
further back; but that is true when no project merge is involved
so it may be an issue but it is not a new issue.
So for this case, I think the "coolest merge" is the right thing
to do.
suggest just something like
git clone oldrepo r1
cd r1
git checkout -b join-branch
cd ..
git add r1/.git/refs/heads/join-branch
git commit -m "Join repo 'oldrepo' at 'r1'"
which should actually work except for the fact that we don't like the
".git" component even as part of a sub-component (ie small hack to git
required to make it not ignore that path).
Sorry you lost me with this. The "join-branch" is a file with
commit object name in it, so is this "recording the revision of
the other project this particular version of the project is
linked to" idea?
On Wed, 18 Jan 2006, Junio C Hamano wrote:
Tracking history across renames is something we have only half
of the needed support. We can notice rename points but there is
no way to tell our usability tools to automatically follow it.
IOW "whatchanged r1/hello.c" will stop at the point the
original project renamed hello.c
Note that "whatchanged" really really _really_ must not follow renames.
Why? The whole _point_ of whatchanged is that it takes a path limiter. A
path limiter is much more useful (to me) that following files. A path
limiter works even when the file doesn't _currently_ exist, and you don't
know what happened to it. A path limiter also fundamentally works for
directories and for multiple files.
If you want "git annotate", then do a "git annotate". Don't change what
"git whatchanged" does. The "pathname only" behaviour is in my opinion THE
MOST SINGLE BIGGEST FEATURE of git.
I _much_ more often use a directory to "git-whatchanged" than I look at an
individual file. Maybe other people don't do that, because they don't tend
to look at the "big picture", or because they are stuck in the "single
file only" mentality, but trust me, especially for maintaining big things,
the "track directories" is a lot more important than single-file tracking.
A _LOT_ more.
I realize that this is heresy to people who are used to "annotate" and
want to follow not the path, but the "conceptual inode", but the thing is,
paths really really are a lot more important to a maintainer. Following an
individual file is a secondary issue.
Now, the fact that we still don't have an efficient "git annotate" is not
because we don't have the capability. It _should_ be perfectly easy to do
(and efficient) by just parsing the output of
git-rev-list HEAD -- <filename>
and when you see a "delete" event, you'd look if it was really a rename.
I think qgit does this, but we don't have the textual version in core git.
So the reason core git tracks PATHNAMES and not files is:
- it's fundamentally a much more powerful operation
- it's possible (and not that much harder) to track renames efficiently
using it anyway, so you can emulate the "track file" behaviour using
"track pathname", but you can NOT emulate it the other way around.
In other words, tracking pathnames is really _fundamentally_ a more
powerful operation.
Git does this right. It is - together with multiple branches - the thing
that makes git work better than BK did for me.
quoted
suggest just something like
git clone oldrepo r1
cd r1
git checkout -b join-branch
cd ..
git add r1/.git/refs/heads/join-branch
git commit -m "Join repo 'oldrepo' at 'r1'"
which should actually work except for the fact that we don't like the
".git" component even as part of a sub-component (ie small hack to git
required to make it not ignore that path).
Sorry you lost me with this. The "join-branch" is a file with
commit object name in it, so is this "recording the revision of
the other project this particular version of the project is
linked to" idea?
Yes. It also means that if you update the other project (commit, pull,
whatever), "git diff" in the top level will do the right thing: it won't
be readable, but you'll always have the SHA1 visible, and you can "commit"
the fact that you updated the sub-project in the top project. It's
basically a poor mans "gitlink".
Linus