Hi Thomas,
Thanks for starting this thread.
Not copying the history and just linking in the commit message to the old
repository only works if you have the guarantee that the old repository
will not get deleted or assimilated into another, rewriting history.
Or better yet, what happens if, in 2 years we switch to a new versioning
tool with its own optimum layout? I`m looking at commits from SVN that are
now moved to git and they all have a commit message like "git-svn-id:
https://svn.xwiki.org/svnroot/xwiki/xwiki-platform/core/trunk@9889f329d543-…quot;.
Having an SVN revision number it is
not trivial to obtain the GIT hash corresponding to the commit; and you
have to do this from the command line.
Isn't this a bit risky on the long run?
P.S.: If we do decide that not copying history is ok, here's my big +1 to
at least mentioning in the commit log in the new repository the parent
commit from the old repository.
Thanks,
Eduard
On Tue, Feb 28, 2012 at 1:17 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
Hi devs,
Since I plan to move some stuff from platform to commons I would like
to know what you think of the history in this case.
Pros including history:
* can access easily the whole history of a moved file. But sometimes
changing packages etc make too much difference for git to see it's
actually the same file so you loose it anyway.
Cons including history:
* double the history which make tools like ohloh indicate wrong
informations
* it's a lot easier to move without history
WDYT ?
Even if it was looking a bit weird to me at first I'm actually +1 to
not move the history in this case.
Eduard was proposing to include in the first commit of the new
repository the id of the last commit containing the files (basically
the id of the parent of the commit deleting the files) in the old
repository so that it's easier to find it. I'm +1 for this.
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs