On Thu, May 28, 2009 at 11:04 AM, Greg Stark <stark@enterprisedb.com> wrote:
> On Thu, May 28, 2009 at 3:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>> Robert Haas wrote:
>>>> That would suck for me. I use git log a lot to see how things have
>>>> changed over time.
>>
>>> Indeed. Losing the history is not an acceptable option.
>>
>> I think the same. If git is not able to maintain our project history
>> then it is not mature enough to be considered as our official VCS.
>> This is not a negotiable requirement.
>
> I think the idea is that you could choose, for example, the level of
> granularity you want to keep. That could be interesting in the future
> -- someone who submitted a patch (or anyone who was working in that
> area) might want to keep all their intermediate commits and not just
> the one big commit for the whole feature.
I don't think that was the idea - Aidan floated the idea of just
checking the current version of each branch into git, rather than
importing the full history from CVS (and letting indivdual cloners fix
their own history if they were so inclined). I think that's a
non-starter.
I'm still not sure who is going to take responsibility for fixing the
git tree we have now. I don't think it's going to work for us to
leave it broken until we're ready to do "the cutover", and then do one
monolithic move. If the tools we're using to do the import now have
broken our tree, then we need to fix it, and them. Ideally I'd like
to get a bi-directional conversion working, so that committers could
commit via either CVS or GIT during the transition, but I'm not sure
whether that's feasible.
...Robert