Re: emacs.git mirror status

[Jim Meyering <jim@meyering.net>]

David Kastrup <dak@gnu.org> wrote:
> Jim Meyering <jim@meyering.net> writes:
>> dhruva <dhruvakm@gmail.com> wrote:
>>> On 9/14/07, Jim Meyering <jim@meyering.net> wrote:
>>>> You can check out a copy of the repository like this:
>>>
>>> I have been using it for sometime and hooked to it. Thank you all the
>>> efforts you have put in to get Emacs on GIT. GIT supports a CVS server
>>> enabling CVS clients to access the GIT repository. Could this be a
>>> possible transition plan.
>>
>> Yes, it is possible.
>> However, currently I would not want to allow commit access
>> through the git cvsserver emulation.  IMHO, it is not mature enough.
>>
>> Within the next few days, I expect to set up for (read-only) cvs pserver
>> access to the gnulib git mirror.  If that goes well, we'll soon switch
>> primary upstream development from cvs to git.
>>
>> If all goes well there, it should be easy to do the same for emacs.
>
> I am afraid that this is not feasible in the current state of affairs:
> as long as all multi-tty material in the current trunk is only tracked
> and blamed to a point where Miles was synching rather than the
> original checkin, one can't seriously work with it.  Presumably the
> information loss is not yet there in the arch repository from Miles,
> so one needs to either make cvsps understand the arch information
> present in CVS ChangeLog entries, or import from arch rather than CVS.

Too bad.  I hope someone has the time to work on that.  I don't.

> Of course I am aware that the CVS workflow already _is_ hampered by
> the information loss, too, but since CVS is rather bad at handling
> such information anyway, it might not be as apparent.

It's very apparent to me :-)
Just compare the git summary of a project that makes a point of having
one commit per change set (e.g., git itself) and emacs.
The fact that every change comes with a separate commit to ChangeLog
that often has no commit log entry means that cvsps does not aggregate
that commit with the change to which it applies.

However, if the ChangeLog commit were done with the same log entry as
all other changes in a change set (ideally, all in the same commit), then
tools like cvsps would be able to reconstruct the change set.  Ideally,
someone would take the time to adapt cvsps or a similar tool to use a
heuristic to aggregate a ChangeLog delta -- perhaps by looking at the diff --
with a nearby change set even though their log messages don't match.