On Fri, 22 Jul 2011, Jakub Narebski wrote:
On Fri, 22 Jul 2011, David Lang <david@xxxxxxx> wrote:
On Fri, 22 Jul 2011, Nicolas Pitre wrote:
On Fri, 22 Jul 2011, Jakub Narebski wrote:
BTW. with storing generation number in commit header there is a problem
what would old version of git, one which does not understand said header,
do during rebase. Would it strip unknown headers, or would it copy
generation number verbatim - which means that it can be incorrect?
They would indeed be copied verbatim and become incorrect.
how would they become incorrect?
Let's assume that the following history was created with new git, one
that correcly adds generation number header to commits:
A(1)---B(2)---C(3)---D(4)---E(5) <-- master
\
\----x(3)---y(4)---z(5) <-- foo
The numbers are generation numbers in commit object.
Let's assume that this repository is fetched into repository instance
that is managed by older git, one that doesn't understand generation
header.
Then, if we do
[old]$ git rebase master foo
and if old git _copies_ generation number header _verbatim_, we would
get:
A(1)---B(2)---C(3)---D(4)---E(5) <-- master
\
\---x'(3)--y'(4)--z'(5) <-- foo
Those generation numbers are *incorrect*; they should be:
A(1)---B(2)---C(3)---D(4)---E(5) <-- master
\
\---x'(6)--y'(7)--z'(8) <-- foo
That is IF unknown headers are copied verbatim during rebase. For
"encoding" header this is a good thing, for "generation" it isn't.
commit headers are _not_ copied during rebase
a rebase is not the exact same commit, it's a "logically equivalent"
commit.
so when you do a rebase, you change the commit headers (you have to change
the parent headers in any case, and you would have to change the
generation numbers as well)
this was discussed earlier in this thread.
David Lang
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html