7 Mar
2012
7 Mar
'12
3:14 p.m.
On 03/07/2012 06:00 AM, Thomas Mortagne wrote:
I'm doing some experiment and here is another
issue: the common way to
isolate a subproject history is by using git filter-branch
--subdirectory-filter which isolate history based on the provided path
but this obviously is blocked by any modification on this path. In
practice it mean that no history older than the refactoring made when
we moved to git will be kept (and sometime even worst if other change
have been made).
Any other idea to isolate history ?
Yep, I've been using filter-branch with --index-filter and a sed-based
rewriting of paths so that I keep track of all the previous locations of
a module, rewriting to a common path at the same time. It takes some
time to track down the history of a module, especially when it has been
extracted from another module at some point.
I've put a stub at https://gist.github.com/1993357
On Tue, Feb 28, 2012 at 12:17 PM, Thomas Mortagne
<thomas.mortagne(a)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 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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/