[xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization
enygma2002 at gmail.com
Tue Feb 28 12:05:27 UTC 2012
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:
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.
On Tue, Feb 28, 2012 at 1:17 PM, Thomas Mortagne
<thomas.mortagne at xwiki.com>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
> * 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 at xwiki.org
More information about the devs