incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <>
Subject Re: [docs] Initial Import Best Practice
Date Sun, 16 Mar 2008 21:07:33 GMT

El jue, 13-03-2008 a las 20:20 +0000, Robert Burrell Donkin escribió: 
> i'm trying to pull together some best practice documentation for the initial
> code import. i'm going to throw some (quite possibly incoherent) opinions
> out there to start discussion but if anyone has opinions feel free to ignore
> the strawman...
> IMO the original sources covered by the appropriate agreement should be
> available as part of the public record of the project. JIRA most likely
> covers this. checking in the unconverted code most definitely covers this
> (where? into a stage/inport directory? into position?).

I'm not sure about the current procedures but I'm doing some academic
work related with historical analysis of code bases. As part of it I'm
testing the use of git-format-patch/git-diff-tree (similar to cvsps) to
convert a git history tree into a set of mail messages that can be later
imported with git-am, preserving history (except for a "Committer:"
header added). I'm quite sure that a similar "export" exists for most in
not all scm products, and it means that we could preserve history very
easily, even if the code is moved into/from a different repository or
set of those.

> it is better to
> convert the originals outside and commit only cleaned up code to the
> repository? (this has the advantage that uncleaned code is not committed to
> the code stream).

I'm not sure about current practices, but trying to preserve code
history is important for a number of reasons, specially in those
contributions that are coming from an Open Source project and a public
repository still exists. I'd prefer to have the cleanup done as a commit
or set of commits, be it in the original repository or in ours, rather
than "breaking" the continuity of commits.

The idea is that, both for audit purposes and for historic/research
analysis, it is better if code that is already in a repository is kept
in the form of a tree/graph of revisions.

> useful tools for relicensing (i know about those in
> committers)?

I'm also interested in a script to detect, using a set of heuristics,
different licenses inside our code. I'll probably start writing
something myself if I can't find one. They could go together, in a
sense, as detection of license content is a first step towards


> - robert
Santiago Gala

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message