emacs.git mirror status

emacs.git mirror status

[Jim Meyering]

As you may recall, I maintain a GIT mirror of the emacs CVS repository.
There were some initial hassles (no branches at first, and then an infloop
due to unexpected log messages in a few ,v files), but everything seems
to be running smoothly, now.  Currently the mirror-updating process runs
approximately every 30 minutes, but note that if it runs right after
you've checked in a change, that change will not be propagated to the
GIT repository immediately[*], and you will have to wait for the next
iteration to see it here:

    http://git.sv.gnu.org/gitweb/?p=emacs.git

You can check out a copy of the repository like this:

    git-clone git://git.sv.gnu.org/emacs

That'll write about 325MB into emacs/, of which 230MB is in emacs/.git,
your local repository, including full history.

[*] cvsps deems a change "too recent" if it's less than 5 or 10min old.
cvsps has to do this, because of the way it aggregates individual
changes (separate CVS commits) into "change sets".

Re: emacs.git mirror status

[dhruva]

Hi,

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.

My experience using GIT on M$:
For the others on the list on M$, GIT on M$ runs fine for almost all
of the usual commands. People can start using the M$ port.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: emacs.git mirror status

[Jim Meyering]

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.

Re: emacs.git mirror status

[David Kastrup]

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.

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.

-- 
David Kastrup

Re: emacs.git mirror status

[Jim Meyering]

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.

Re: emacs.git mirror status

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> 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.

I have created an alternate GIT tree that is converted with a modified
version of git-cvsimport.  You can have a look at it at
<http://ftp.suse.com/pub/people/schwab/emacs/emacs.git>.  One advantage
of this tree is that it contains some merge information gathered from
the arch logs, and I have also corrected some author information.  If it
turned out to be useful I can provide the script and authors file I have
used.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> 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.
>
> I have created an alternate GIT tree that is converted with a modified
> version of git-cvsimport.  You can have a look at it at
> <http://ftp.suse.com/pub/people/schwab/emacs/emacs.git>.  One advantage
> of this tree is that it contains some merge information gathered from
> the arch logs, and I have also corrected some author information.  If it
> turned out to be useful I can provide the script and authors file I have
> used.

dak@lisa:/rep/git-andreas$ git clone http://ftp.suse.com/pub/people/schwab/emacs/emacs.git
Initialized empty Git repository in /rep/git-andreas/emacs/.git/
cat: /rep/git-andreas/emacs/.git/refs/remotes/origin/master: No such file or directory
cd: 460: can't cd to /rep/git-andreas/emacs/.git/refs/remotes/origin
fatal: : not a valid SHA1
fatal: Not a valid object name HEAD
dak@lisa:/rep/git-andreas$ 

-- 
David Kastrup

Re: emacs.git mirror status

[Jim Meyering]

Andreas Schwab <schwab@suse.de> wrote:

> David Kastrup <dak@gnu.org> writes:
>
>> 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.
>
> I have created an alternate GIT tree that is converted with a modified
> version of git-cvsimport.  You can have a look at it at
> <http://ftp.suse.com/pub/people/schwab/emacs/emacs.git>.  One advantage
> of this tree is that it contains some merge information gathered from
> the arch logs, and I have also corrected some author information.  If it
> turned out to be useful I can provide the script and authors file I have
> used.

Sounds good (but like David, I couldn't clone your repo).
If everyone likes the changes (and I don't see why they wouldn't),
I'll be happy to switch the repository on savannah to use the
new version of git-cvsimport.  BTW, the repo there already has
some author information.  If your authors file is improved, then I'll
use that, too.

Re: emacs.git mirror status

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> dak@lisa:/rep/git-andreas$ git clone http://ftp.suse.com/pub/people/schwab/emacs/emacs.git
> Initialized empty Git repository in /rep/git-andreas/emacs/.git/
> cat: /rep/git-andreas/emacs/.git/refs/remotes/origin/master: No such file or directory

Please try again in about half an hour (the staging area is synched out
only every 30 minutes).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> 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.
>
> I have created an alternate GIT tree that is converted with a modified
> version of git-cvsimport.  You can have a look at it at
> <http://ftp.suse.com/pub/people/schwab/emacs/emacs.git>.  One advantage
> of this tree is that it contains some merge information gathered from
> the arch logs, and I have also corrected some author information.  If it
> turned out to be useful I can provide the script and authors file I have
> used.

Well, if I use something like

git-gui --blame src/xterm.c

in the trunk, it is still Miles who indiscriminately gets all the
blame for multi-tty.

-- 
David Kastrup

Re: emacs.git mirror status

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Well, if I use something like
>
> git-gui --blame src/xterm.c
>
> in the trunk, it is still Miles who indiscriminately gets all the
> blame for multi-tty.

Ok, the problem is that I didn't match the log message from the big
multi-tty merge last May.  I'll see what I can do, I'll probably have to
recreate the whole tree.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[Andreas Schwab]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Well, if I use something like
>>
>> git-gui --blame src/xterm.c
>>
>> in the trunk, it is still Miles who indiscriminately gets all the
>> blame for multi-tty.
>
> Ok, the problem is that I didn't match the log message from the big
> multi-tty merge last May.

Looking closer, this wasn't a merge, but an import.  So the history is
lost, unfortunately.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Well, if I use something like
>>
>> git-gui --blame src/xterm.c
>>
>> in the trunk, it is still Miles who indiscriminately gets all the
>> blame for multi-tty.
>
> Ok, the problem is that I didn't match the log message from the big
> multi-tty merge last May.  I'll see what I can do, I'll probably have to
> recreate the whole tree.

Well, it would minimally probably mean that one takes a look at "merge
change from branch" commit messages and then merge the changes with a
strategy of "ours":

	ours
	   This resolves any number of heads, but the result of the
	   merge is always the current branch head. It is meant to
	   be used to supersede old development history of side
	   branches.

Something like that.

-- 
David Kastrup

Re: emacs.git mirror status

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> Well, if I use something like
>>>
>>> git-gui --blame src/xterm.c
>>>
>>> in the trunk, it is still Miles who indiscriminately gets all the
>>> blame for multi-tty.
>>
>> Ok, the problem is that I didn't match the log message from the big
>> multi-tty merge last May.
>
> Looking closer, this wasn't a merge, but an import.  So the history is
> lost, unfortunately.

For git, the sole difference between a merge and an import is that the
former has the branch as a parent commit.  All the other history is
reconstructed by git on the fly rather than tracked.  So just
redeclaring the respective CVS checkins (which can be discerned by the
log messages) as merges from the respective branch commit should be
sufficient to let git figure out the corresponding original checkins
in the branch.

-- 
David Kastrup

Re: emacs.git mirror status

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> Andreas Schwab <schwab@suse.de> writes:
>>
>>> David Kastrup <dak@gnu.org> writes:
>>>
>>>> Well, if I use something like
>>>>
>>>> git-gui --blame src/xterm.c
>>>>
>>>> in the trunk, it is still Miles who indiscriminately gets all the
>>>> blame for multi-tty.
>>>
>>> Ok, the problem is that I didn't match the log message from the big
>>> multi-tty merge last May.
>>
>> Looking closer, this wasn't a merge, but an import.  So the history is
>> lost, unfortunately.
>
> For git, the sole difference between a merge and an import is that the
> former has the branch as a parent commit.  All the other history is
> reconstructed by git on the fly rather than tracked.  So just
> redeclaring the respective CVS checkins (which can be discerned by the
> log messages) as merges from the respective branch commit should be
> sufficient to let git figure out the corresponding original checkins
> in the branch.

This should be doable with the

git-rewrite-history

command using its --parent-filter option.


-- 
David Kastrup

Re: emacs.git mirror status

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> For git, the sole difference between a merge and an import is that the
> former has the branch as a parent commit.  All the other history is
> reconstructed by git on the fly rather than tracked.  So just
> redeclaring the respective CVS checkins

There are no such checkins.  The history is located only in the various
arch trees of Miles and Karoly.  I'm currently trying to see if I'm able
to combine the cvs and arch imports in any useful way.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> For git, the sole difference between a merge and an import is that the
>> former has the branch as a parent commit.  All the other history is
>> reconstructed by git on the fly rather than tracked.  So just
>> redeclaring the respective CVS checkins
>
> There are no such checkins.

Huh?  Miles never checked anything into CVS?

> The history is located only in the various arch trees of Miles and
> Karoly.  I'm currently trying to see if I'm able to combine the cvs
> and arch imports in any useful way.

Again: all that needs to be done is to add the (then current) branch
head of the branch to the parent of Miles' merging commits.  git does
not track any history apart from that.

-- 
David Kastrup

Re: emacs.git mirror status

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> This should be doable with the
>
> git-rewrite-history

Where can I find it? (It's not part of git-core.)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> For git, the sole difference between a merge and an import is that the
>>> former has the branch as a parent commit.  All the other history is
>>> reconstructed by git on the fly rather than tracked.  So just
>>> redeclaring the respective CVS checkins
>>
>> There are no such checkins.
>
> Huh?  Miles never checked anything into CVS?

Not before the initial multi-tty import.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Well, if I use something like
>
> git-gui --blame src/xterm.c
>
> in the trunk, it is still Miles who indiscriminately gets all the
> blame for multi-tty.

Note that all commits from before the multi-tty import are from Karoly,
so you can just s/Miles/Karoly/ to get the real blame.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Andreas Schwab <schwab@suse.de> writes:
>>
>>> David Kastrup <dak@gnu.org> writes:
>>>
>>>> For git, the sole difference between a merge and an import is that the
>>>> former has the branch as a parent commit.  All the other history is
>>>> reconstructed by git on the fly rather than tracked.  So just
>>>> redeclaring the respective CVS checkins
>>>
>>> There are no such checkins.
>>
>> Huh?  Miles never checked anything into CVS?
>
> Not before the initial multi-tty import.

So what?  That is the commit I was talking about.

-- 
David Kastrup

Re: emacs.git mirror status

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> This should be doable with the
>>
>> git-rewrite-history
>
> Where can I find it? (It's not part of git-core.)

Brain fried.  I rather mean git-filter-branch, sorry.

-- 
David Kastrup

Re: emacs.git mirror status

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Well, if I use something like
>>
>> git-gui --blame src/xterm.c
>>
>> in the trunk, it is still Miles who indiscriminately gets all the
>> blame for multi-tty.
>
> Note that all commits from before the multi-tty import are from Karoly,
> so you can just s/Miles/Karoly/ to get the real blame.

It is pretty unimportant for me _who_ to blame.  Much more important
is what _commit_ to blame so that one can figure out the "why" and the
history of a change.

Once git knows that the merge is a merge, it will trace the origin of
the change back to the original commit.

-- 
David Kastrup

Re: emacs.git mirror status

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> Andreas Schwab <schwab@suse.de> writes:
>>>
>>>> David Kastrup <dak@gnu.org> writes:
>>>>
>>>>> For git, the sole difference between a merge and an import is that the
>>>>> former has the branch as a parent commit.  All the other history is
>>>>> reconstructed by git on the fly rather than tracked.  So just
>>>>> redeclaring the respective CVS checkins
>>>>
>>>> There are no such checkins.
>>>
>>> Huh?  Miles never checked anything into CVS?
>>
>> Not before the initial multi-tty import.
>
> So what?  That is the commit I was talking about.

There is only this very commit representing the import.  The CVS tree
contains no history before that point.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Brain fried.  I rather mean git-filter-branch, sorry.

Looks like it is not included in git 1.5.2.4.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[Andreas Schwab]

Jim Meyering <jim@meyering.net> writes:

> I'll be happy to switch the repository on savannah to use the
> new version of git-cvsimport.  BTW, the repo there already has
> some author information.  If your authors file is improved, then I'll
> use that, too.

I have uploaded the scripts and the authors file to
<ftp://ftp.suse.com/pub/people/schwab/emacs>.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Brain fried.  I rather mean git-filter-branch, sorry.
>
> Looks like it is not included in git 1.5.2.4.

It's part of 1.5.3.

-- 
David Kastrup

Re: emacs.git mirror status

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Andreas Schwab <schwab@suse.de> writes:
>>
>>> David Kastrup <dak@gnu.org> writes:
>>>
>>>> Andreas Schwab <schwab@suse.de> writes:
>>>>
>>>>> David Kastrup <dak@gnu.org> writes:
>>>>>
>>>>>> For git, the sole difference between a merge and an import is that the
>>>>>> former has the branch as a parent commit.  All the other history is
>>>>>> reconstructed by git on the fly rather than tracked.  So just
>>>>>> redeclaring the respective CVS checkins
>>>>>
>>>>> There are no such checkins.
>>>>
>>>> Huh?  Miles never checked anything into CVS?
>>>
>>> Not before the initial multi-tty import.
>>
>> So what?  That is the commit I was talking about.
>
> There is only this very commit representing the import.  The CVS tree
> contains no history before that point.

Indeed.  On the 13th of May, Miles imported just the current state and
none of the history in the multi-tty arch repository into his arch
repository.

We could presumably fix this in git by importing the upstream
multi-tty arch repository into git as a separate branch starting from
the branch-off point of multi-tty, then make this the branch parent
rather than Miles import.  Something like that.

git is pretty good at mangling history after the fact.  Whether we
have a reasonable chance to get this sort of thing done in the CVS or
arch repositories is a different question.  Probably not.

-- 
David Kastrup

Re: emacs.git mirror status

[Richard Stallman]

    Indeed.  On the 13th of May, Miles imported just the current state and
    none of the history in the multi-tty arch repository into his arch
    repository.

I can't make sense of all these nested messages.  It looks like
something was done wrong, and that history is missing from the CVS
repository where it ought to be.  But I cannot tell which parts
of the history are missing, or where they are missing from.

Can someone please post a self-contained full description of this problem?
What is missing, and where should it have been?
 
   We could presumably fix this in git by importing the upstream
    multi-tty arch repository into git as a separate branch starting from
    the branch-off point of multi-tty, then make this the branch parent
    rather than Miles import.  Something like that.

What about fixing this in CVS?

Re: emacs.git mirror status

[Richard Stallman]

    > For git, the sole difference between a merge and an import is that the
    > former has the branch as a parent commit.  All the other history is
    > reconstructed by git on the fly rather than tracked.  So just
    > redeclaring the respective CVS checkins

    There are no such checkins.  The history is located only in the various
    arch trees of Miles and Karoly.

People spoke of the "multi-tty branch".  I presumed that meant a
branch in our CVS repository.  Is that not so?

(I don't know enough about CVS to find out for myself.)

Re: emacs.git mirror status

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Indeed.  On the 13th of May, Miles imported just the current state and
>     none of the history in the multi-tty arch repository into his arch
>     repository.
>
> I can't make sense of all these nested messages.  It looks like
> something was done wrong, and that history is missing from the CVS
> repository where it ought to be.  But I cannot tell which parts of
> the history are missing, or where they are missing from.

I don't see that anything was done wrong here: the alternative would
likely have been not to do anything at all, given the constraints of
CVS.

> Can someone please post a self-contained full description of this
> problem?

The private development history of multi-tty before it was first
placed into our CVS is not there checkin by checkin.  That makes it
hard to find the rationale (using mechanisms like cvs annotate) for
individual lines since all their history according to CVS boils down
to "merged into our CVS by Miles on 2007/05/13".

> What is missing, and where should it have been?

I really don't think that there is much that could have been done: CVS
does not lend itself to faking a history that has not actually been
there.

>    We could presumably fix this in git by importing the upstream
>    multi-tty arch repository into git as a separate branch starting
>    from the branch-off point of multi-tty, then make this the branch
>    parent rather than Miles import.  Something like that.
>
> What about fixing this in CVS?

I don't see that there is much we can do about this in CVS.  But git
is pretty good at mangling history, so if we offer a git repository,
chances are that we can with reasonable effort merge the histories
from several repositories into it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacs.git mirror status

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     > For git, the sole difference between a merge and an import is that the
>     > former has the branch as a parent commit.  All the other history is
>     > reconstructed by git on the fly rather than tracked.  So just
>     > redeclaring the respective CVS checkins
>
>     There are no such checkins.  The history is located only in the various
>     arch trees of Miles and Karoly.
>
> People spoke of the "multi-tty branch".  I presumed that meant a
> branch in our CVS repository.  Is that not so?

Yes.  The multi-tty branch started life at Karoly's arch repo 3½ years
ago, was earlier this year imported into Miles's arch repo, who checked
the result of the merge into CVS as a single commit.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[Jim Meyering]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

Andreas Schwab <schwab@suse.de> wrote:
> Jim Meyering <jim@meyering.net> writes:
>> I'll be happy to switch the repository on savannah to use the
>> new version of git-cvsimport.  BTW, the repo there already has
>> some author information.  If your authors file is improved, then I'll
>> use that, too.
>
> I have uploaded the scripts and the authors file to
> <ftp://ftp.suse.com/pub/people/schwab/emacs>.

I've compared our files and added the 18 name/email pairs from yours that
mine lacked.  Mine has 9 that yours lacks, and there remain some differing
addresses -- and a few names.  Back when I constructed my username/email
list, I chose to use the historical email address from the ChangeLog,
when I could find that.  It looks like some of the addresses you used
are more modern.  I don't care much, either way.

And I do recall that "law" was not Jeff -- you could tell from
the nearby ChangeLog delta.  There were a couple of others like that,
like maybe mycroft.  Not sure about that one.

In case anyone cares to investigate, here are the two files
(Andreas, I sorted yours and removed a single duplicate line):


[-- Attachment #2: emacs-git-user-map.as --]
[-- Type: application/octet-stream, Size: 8277 bytes --]

3diff=Brian Youmans <3diff@gnu.org>
JYavner=Jonathan Yavner <jyavner@member.fsf.org>
abraham=Per Abrahamsen <abraham@dina.kvl.dk>
acmacm=Alan Mackenzie <acm@muc.de>
akochoi=Andrew Choi <akochoi@shaw.ca>
albinus=Michael Albinus <michael.albinus@gmx.de>
alex=Alex Schroeder <alex@gnu.org>
andrewi=Andrew Innes <andrewi@gnu.org>
as=Alex Schroeder <alex@gnu.org>
bfox=Brian Fox <bfox@gnu.org>
bje=Ben Elliston <bje@air.net.au>
bkey1=Ben Key <bkey1@tampabay.rr.com>
blaak=Ray Blaak <blaak@infomatch.com>
bob=Robert J. Chassell <bob@rattlesnake.com>
boris=Boris Goldowsky <boris@gnu.org>
bothner=Per Bothner <bothner@cygnus.com>
bwarsaw=Barry A. Warsaw <barry@zope.org>
cadilhac=Michaël Cadilhac <michael.cadilhac@lrde.org>
cd=Carsten Dominik <dominik@science.uva.nl>
cdominik=Carsten Dominik <dominik@science.uva.nl>
cks=Chris Siebenmann <cks@hawkwind.utcs.utoronto.ca>
coxs=Stan Cox <scox@redhat.com>
cph=Chris Hanson <cph@gnu.org>
cyd=Chong Yidong <cyd@stupidchicken.com>
dak=David Kastrup <dak@gnu.org>
dann=Dan Nicolaescu <dann@ics.uci.edu>
deego=Deepak Goel <deego@gnufans.org>
devnull=Joel N. Weber II <devnull@gnu.org>
dje=Doug Evans <dje@gnu.org>
djm=David J. MacKenzie <djm@gnu.org>
dominik=Carsten Dominik <dominik@science.uva.nl>
done=Dan Nicolaescu <done@ece.arizona.edu>
dpe=David Ponce <david@dponce.com>
drepper=Ulrich Drepper <drepper@redhat.com>
eggert=Paul Eggert <eggert@twinsun.com>
elgin=Jim Elgin <elgin@gnu.org>
eliz=Eli Zaretskii <eliz@is.elta.co.il>
enberg=Henrik Enberg <henrik.enberg@telia.com>
eric=Eric S. Raymond <esr@snark.thyrsus.com>
ericding=Eric Ding <ericding@mit.edu>
erich=Erich Stefan Boleyn <erich@uruk.org>
erik=Erik Naggum <erik@naggum.no>
esr=Eric S. Raymond <esr@snark.thyrsus.com>
fp=Fred Pierresteguy <F.Pierresteguy@frcl.bull.fr>
friedman=Noah Friedman <friedman@splode.com>
fx=Dave Love <fx@gnu.org>
gerd=Gerd Moellmann <gerd@gnu.org>
gildea=Stephen Gildea <gildea@stop.mail-abuse.org>
gm=Glenn Morris <rgm@gnu.org>
gnu=John Gilmore <gnu@toad.com>
hag=Daniel Hagerty <hag@gnu.org>
handa=Kenichi Handa <handa@m17n.org>
harder=Jesper Harder <harder@ifa.au.dk>
hassey=John Hassey <hassey@dg-rtp.dg.com>
hexmode=Mark A. Hershberger <mah@everybody.org>
himi=Miyashita Hisashi <himi@meadowy.org>
ian=Ian Lance Taylor <ian@cygnus.com>
jai=Jaeyoun Chung <jay@kldp.org
jai=Jaeyoun Chung <jay@kldp.org>
jas=Simon Josefsson <jas@extundo.com>
jasonr=Jason Rumney <jasonr@gnu.org>
jbailey=Jeff Bailey <jbailey@raspberryginger.com>
jchonig=Jeffrey C Honig <jch@bsdi.com>
jdsmith=J.D. Smith <jdsmith@as.arizona.edu>
jet=Masatake YAMATO <jet@gyve.org>
jhd=Jan Djärv <jan.h.d@swipnet.se>
jimb=Jim Blandy <jimb@redhat.com>
jla=Joseph Arceneaux <jla@gnu.org>
joelh=Joel Ray Holveck <joelh@piquan.org>
johnw=John Wiegley <johnw@newartisans.com>
jpb=Jay Belanger <jay.p.belanger@gmail.com>
jpw=John Paul Wallington <jpw@pobox.com>
juhp=Jens Petersen <petersen@redhat.com>
jurta=Juri Linkov <juri@jurta.org>
jvromans=Johan Vromans <jvromans@squirrel.nl>
kai=Kai Großjohann <kgrossjo@eu.uu.net>
karl=Karl Berry <karl@gnu.org>
kenner=Richard Kenner <kenner@gnu.org>
kevingal=Kevin Gallagher <Kevin.Gallagher@boeing.com>
kfogel=Karl Fogel <kfogel@red-bean.com>
kfstorm=Kim F. Storm <storm@cua.dk>
kifer=Michael Kifer <kifer@cs.stonybrook.edu>
kitaro=Raul Acevedo <kitaro@gnu.org>
kwzh=Karl Heuer <kwzh@gnu.org>
larsi=Lars Magne Ingebrigtsen <larsi@gnus.org>
law=Jeff Law <law@redhat.com>
lborgman=Lennart Borgman <lennart.borgman.073@student.lu.se>
legoscia=Magnus Henoch <mange@freemail.hu>
lektu=Juanma Barranquero <lekktu@gmail.com>
lh=Lars Hansen <larsh@soem.dk>
liberte=Daniel LaLiberte <liberte@gnu.org>
lorentey=Károly Lőrentey <lorentey@elte.hu>
lute=Lute Kamstra <lute@gnu.org>
m061211=Martin Rudalics <rudalics@gmx.at>
marcelo=Marcelo Toledo <marcelo@gnu.org>
martinl=Martin Lorentzson <martinl@gnu.org>
mast=Martin Stjernholm <mast@lysator.liu.se>
mathiasdahl=Mathias Dahl <mathias.dahl@gmail.com>
mdb=Mark D. Baushke <mdb@gnu.org>
mdub=Mike Williams <mdub@bigfoot.com>
meissner=Michael Meissner <gnu@the-meissners.org>
melissa=Melissa Weisshaus <melissa@gnu.org>
meyering=Jim Meyering <jim@meyering.net>
mib=Michael I. Bushnell <mib@gnu.org>
miles=Miles Bader <miles@gnu.org>
mituharu=YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
monnier=Stefan Monnier <monnier@iro.umontreal.ca>
mrs=Mike Stump <mrs@apple.com>
mthunder=Steve Morningthunder <mthunder@gnu.org>
mtr=Mike Rowan <mtr@gnu.org>
mwolson=Michael Olson <mwolson@gnu.org>
mycroft=Charles Hannum <mycroft@gnu.org>
nickrob=Nick Roberts <nickrob@snap.net.nz>
os10000=Oliver Seidel <os10000@seidel-space.de>
pbreton=Peter Breton <pbreton@attbi.com>
pfeiffer=Daniel Pfeiffer <occitan@esperanto.org>
pj=Pavel Janík <Pavel@Janik.cz>
pjr=Richard M. Stallman <rms@gnu.org>
pmr-sav=Paul Reilly  <pmr@pajato.com>
pmr=Paul Reilly  <pmr@pajato.com>
pot=Francesco Potortì <pot@gnu.org>
psg=Peter Galbraith <galbraith@mixing.qc.dfo.ca>
psmith=Paul D. Smith <psmith@BayNetworks.com>
raeburn=Ken Raeburn <raeburn@raeburn.org>
ramprasadb=Ramprasad B <ramprasad_i82@yahoo.com>
rao=Paul Fisher <rao@gnu.org>
rassilon=Brian Preble <rassilon@gnu.org>
reingold=Edward M. Reingold  <reingold@emr.cs.iit.edu>
reto=Reto Zimmermann <reto@gnu.org>
rfrancoise=Romain Francoise <romain@orebokech.com>
rlb=Rob Browning <rlb@defaultvalue.org>
rms=Richard M. Stallman <rms@gnu.org>
rogue=Christopher Zaborsky <rogue@erratum.com>
roland=Roland McGrath <roland@gnu.org>
rost=Markus Rost <rost@math.uni-bielefeld.de>
rsteib=Reiner Steib <Reiner.Steib@gmx.de>
rudy=Rudy Gevaert <rudy@webworm.org>
rutt=Benjamin Rutt <brutt@bloomington.in.us>
rv=Rajesh Vaidheeswarran <rv@gnu.org>
satyakid=Satyaki Das <satyaki@theforce.stanford.edu>
schwab=Andreas Schwab <schwab@suse.de>
sds=Sam Steingold <sds@gnu.org>
seidel=Oliver Seidel <os10000@seidel-space.de>
simon=Simon Marshall <simon@gnu.org>
sk=Sebastian Kremer <sk@thp.uni-koeln.de>
spiegel=André Spiegel <spiegel@gnu.org>
stephen=Stephen Eglen <stephen@gnu.org>
swift=Matthew Swift <swift@alum.mit.edu>
tale=David Lawrence <tale@gnu.org>
tamm=Steven Tamm <steventamm@mac.com>
tege=Torbjorn Granlund <tege@swox.com>
teirllm=Luc Teirlinck <teirllm@auburn.edu>
terra=Morten Welinder <terra@diku.dk>
thomas=Thomas Bushnell, BSG <thomas@gnu.org>
tower=Leonard H. Tower Jr. <tower@art.net>
tromey=Tom Tromey <tromey@redhat.com>
ttn=Thien-Thi Nguyen <ttn@gnuvola.org>
tzz=Teodor Zlatanov <tzz@lifelogs.com>
uid65566=Richard M. Stallman <rms@gnu.org>
uid65598=Kim F. Storm <storm@cua.dk>
uid65600=John Wiegley <johnw@newartisans.com>
uid65604=Sam Steingold <sds@gnu.org>
uid65610=Michael Kifer <kifer@cs.stonybrook.edu>
uid65611=Robert J. Chassell <bob@rattlesnake.com>
uid65615=Thien-Thi Nguyen <ttn@gnuvola.org>
uid65618=Miles Bader <miles@gnu.org>
uid65620=Kenichi Handa <handa@m17n.org>
uid65624=André Spiegel <spiegel@gnu.org>
uid65625=Jason Rumney <jasonr@gnu.org>
uid65627=Eli Zaretskii <eliz@is.elta.co.il>
uid65629=Andreas Schwab <schwab@suse.de>
uid65630=Stefan Monnier <monnier@iro.umontreal.ca>
uid65632=Paul Eggert <eggert@twinsun.com>
uid65641=Per Abrahamsen <abraham@dina.kvl.dk>
uid65818=Karl Berry <karl@gnu.org>
uid65992=John Paul Wallington <jpw@pobox.com>
uid66361=Markus Rost <rost@math.uni-bielefeld.de>
uid66490=Martin Stjernholm <mast@lysator.liu.se>
uid66518=Jan Djärv <jan.h.d@swipnet.se>
uid66762=David Kastrup <dak@gnu.org>
uid66918=Glenn Morris <rgm@gnu.org>
uid66976=Simon Josefsson <jas@extundo.com>
uid67111=Steven Tamm <steventamm@mac.com>
uid67241=Nick Roberts <nickrob@snap.net.nz>
uid67419=Jonathan Yavner <jyavner@member.fsf.org>
uid67483=Stephen Eglen <stephen@gnu.org>
uid68116=Vinicius Jose Latorre <viniciusjl@ig.com.br>
uid68472=Luc Teirlinck <teirllm@auburn.edu>
uid68798=Lars Hansen <larsh@soem.dk>
uid69204=Benjamin Rutt <brutt@bloomington.in.us>
viniciusjl=Vinicius Jose Latorre <viniciusjl@ig.com.br>
voelker=Geoff Voelker <voelker@cs.washington.edu>
walters=Colin Walters <walters@gnu.org>
wilson=Jim Wilson <wilson@gnu.org>
winkler=Roland Winkler <Roland.Winkler@physik.uni-erlangen.de>
wl=Werner LEMBERG <wl@gnu.org>
wmperry=William M. Perry <wmperry@aventail.com>
wohler=Bill Wohler <wohler@newt.com>
yamaoka=Katsumi Yamaoka <yamaoka@jpl.org>
zappo=Eric M. Ludlam <zappo@gnu.org>
zsh=ShengHuo ZHU <zsh@cs.rochester.edu>

[-- Attachment #3: emacs-git-user-map.jm --]
[-- Type: application/octet-stream, Size: 8678 bytes --]

[-- Attachment #4: Type: text/plain, Size: 33 bytes --]


I'll look at your script later.

[-- Attachment #5: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: emacs.git mirror status

[Andreas Schwab]

Jim Meyering <jim@meyering.net> writes:

> I've compared our files and added the 18 name/email pairs from yours that
> mine lacked.  Mine has 9 that yours lacks,

My author list only contains the actual user names recorded in the
history.  There are 8 current members at Savannah that never committed
to CVS, and I doesn't look like the 9 authors from your list have any
commits either.

> Back when I constructed my username/email list, I chose to use the
> historical email address from the ChangeLog, when I could find that.
> It looks like some of the addresses you used are more modern.  I don't
> care much, either way.

I generally used the newest mail address that I could find in the change
logs (some are even less modern than yours :-) ).  But I don't care
much, either.

> And I do recall that "law" was not Jeff -- you could tell from
> the nearby ChangeLog delta.

The changes from "law" are only on config.sub/config.guess, which were
symlinked to shared RCS files at this time, so there are no change log
entries that belong to any of his commits.  I'm pretty sure he is the
same law who is the current owner of law @fencepost.

> There were a couple of others like that, like maybe mycroft.  Not sure
> about that one.

"mycroft" is similar, except that there is no such account @fencepost
any more.  There are more such differences from the
config.guess/config.sub accounts.

I think you are wrong about uid65624: from looking at the commit log
style it looks more like André committed on Benjamin's behalf (and I
don't think Benjamin ever had commit access).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[Jim Meyering]

Andreas Schwab <schwab@suse.de> wrote:
> Jim Meyering <jim@meyering.net> writes:
>> I've compared our files and added the 18 name/email pairs from yours that
>> mine lacked.  Mine has 9 that yours lacks,
>
> My author list only contains the actual user names recorded in the
> history.  There are 8 current members at Savannah that never committed
> to CVS, and I doesn't look like the 9 authors from your list have any
> commits either.

Oh yeah.  I just reused a user/email map file from another project.
Having extra pairs is fine.

>> Back when I constructed my username/email list, I chose to use the
>> historical email address from the ChangeLog, when I could find that.
>> It looks like some of the addresses you used are more modern.  I don't
>> care much, either way.
>
> I generally used the newest mail address that I could find in the change
> logs (some are even less modern than yours :-) ).  But I don't care
> much, either.
>
>> And I do recall that "law" was not Jeff -- you could tell from
>> the nearby ChangeLog delta.
>
> The changes from "law" are only on config.sub/config.guess, which were
> symlinked to shared RCS files at this time, so there are no change log
> entries that belong to any of his commits.  I'm pretty sure he is the
> same law who is the current owner of law @fencepost.

I had to look up some using other means (e.g., google),
and maybe that was one of them.  I didn't keep notes.

>> There were a couple of others like that, like maybe mycroft.  Not sure
>> about that one.
>
> "mycroft" is similar, except that there is no such account @fencepost
> any more.  There are more such differences from the
> config.guess/config.sub accounts.
>
> I think you are wrong about uid65624: from looking at the commit log
> style it looks more like André committed on Benjamin's behalf (and I
> don't think Benjamin ever had commit access).

In that case, perhaps I found/used the author name, rather
than the committer name.  IMHO, that's what should be used
in any case, to properly credit the author.  And it's probably ok,
since there were so few changes by that uid.

Re: emacs.git mirror status

[Richard Stallman]

    > People spoke of the "multi-tty branch".  I presumed that meant a
    > branch in our CVS repository.  Is that not so?

    Yes.  The multi-tty branch started life at Karoly's arch repo 3œ years
    ago, was earlier this year imported into Miles's arch repo, who checked
    the result of the merge into CVS as a single commit.

In other words, the history before that commit into CVS
is not in CVS -- is that the issue?

How about putting that history into the ChangeLog files?

Re: emacs.git mirror status

[Glenn Morris]

Richard Stallman wrote:

>     Yes. The multi-tty branch started life at Karoly's arch repo 3œ
>     years ago, was earlier this year imported into Miles's arch
>     repo, who checked the result of the merge into CVS as a single
>     commit.
>
> In other words, the history before that commit into CVS is not in
> CVS -- is that the issue?
>
> How about putting that history into the ChangeLog files?

Argh! You specifically requested this history be taken out
("simplifying" or "crunching" the ChangeLogs) before the merge could
be done!

This was neither simple nor fun to achieve (once again, Dan Nicolaescu
did most of the work).

Re: emacs.git mirror status

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > People spoke of the "multi-tty branch".  I presumed that meant a
>     > branch in our CVS repository.  Is that not so?
>
>     Yes.  The multi-tty branch started life at Karoly's arch repo 3œ years
>     ago, was earlier this year imported into Miles's arch repo, who checked
>     the result of the merge into CVS as a single commit.
>
> In other words, the history before that commit into CVS
> is not in CVS -- is that the issue?
>
> How about putting that history into the ChangeLog files?

Completely useless for using "cvs annotate" and similar.  For git, it
should be possible to import the old arch-like archive (if it is still
to be found somewhere) into a separate branch, and then use a "graft"
for linking it to Miles' large checkin.

For the kind of reverse engineering we need to do on the multitty
branch, namely what went where for what reason, a ChangeLog entry is
not really enough.  We need the actual connection with the code
movement.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacs.git mirror status

[Richard Stallman]

    > How about putting that history into the ChangeLog files?

    Argh! You specifically requested this history be taken out
    ("simplifying" or "crunching" the ChangeLogs) before the merge could
    be done!

I did not realize we were talking about that information.  Oops!

Why is the information about early changes in multi-tty so important?
Did they put explanations of reasons and problems into the change log?
We normally put that information into comments in the code, which is
the best place for it; as a consequence, crunching the old change log
history doesn't lose those explanations.

Re: emacs.git mirror status

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > How about putting that history into the ChangeLog files?
>
>     Argh! You specifically requested this history be taken out
>     ("simplifying" or "crunching" the ChangeLogs) before the merge could
>     be done!
>
> I did not realize we were talking about that information.  Oops!

Well, at least I wasn't.  I was talking about per-commit information.

> Why is the information about early changes in multi-tty so
> important?  Did they put explanations of reasons and problems into
> the change log?

The fine-grained history of changes makes it possible to see what
changes belong together and are likely to constitute one change set
with one meaning.  This would be important for figuring out the
relation between things even if there were no ChangeLog entries, and
no commit logs.  While I have not looked at the original Bazaar
archive yet, it would be my hope that there _are_ some commit logs in
there, too.

> We normally put that information into comments in the code, which is
> the best place for it; as a consequence, crunching the old change
> log history doesn't lose those explanations.

But the explanations don't help with figuring out which exact lines
were involved with what change.

-- 
David Kastrup

Re: emacs.git mirror status

[Glenn Morris]

Richard Stallman wrote:

> Why is the information about early changes in multi-tty so important?

I really don't think it is, and if I were you, I would not worry about
this. I really doubt that the thing stopping people figuring out
multi-tty code is an inability to see the individual commits and their
associated logs.

Re: emacs.git mirror status

[Stefan Monnier]

>> Why is the information about early changes in multi-tty so important?

> I really don't think it is, and if I were you, I would not worry about
> this. I really doubt that the thing stopping people figuring out
> multi-tty code is an inability to see the individual commits and their
> associated logs.

Agreed.


        Stefan "working on the emacsclient/server.el interface"

Re: emacs.git mirror status

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Well, if I use something like
>
> git-gui --blame src/xterm.c
>
> in the trunk, it is still Miles who indiscriminately gets all the
> blame for multi-tty.

I have now modified my git tree and plugged the multi-tty history from
Karoly's arch tree into it.  Please give it a try.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Well, if I use something like
>>
>> git-gui --blame src/xterm.c
>>
>> in the trunk, it is still Miles who indiscriminately gets all the
>> blame for multi-tty.
>
> I have now modified my git tree and plugged the multi-tty history
> from Karoly's arch tree into it.  Please give it a try.

Well, the synch is progressing at glacial speed so I can't say
anything about it yet.  I hope that it was no mistake to do git-pull
rather than a fresh clone.

Anyway: great news!

-- 
David Kastrup

Re: emacs.git mirror status

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Well, the synch is progressing at glacial speed so I can't say
> anything about it yet.

Yes, I see that here, too (independent of the transport protocol, it
spends all the time in indexing the objects).  It might be related to
the way the tree is structured.

> I hope that it was no mistake to do git-pull rather than a fresh
> clone.

A clone has the same problem.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Well, the synch is progressing at glacial speed so I can't say
>> anything about it yet.
>
> Yes, I see that here, too (independent of the transport protocol, it
> spends all the time in indexing the objects).  It might be related to
> the way the tree is structured.
>
>> I hope that it was no mistake to do git-pull rather than a fresh
>> clone.
>
> A clone has the same problem.

But the pull dropped out with merge conflicts.  So I did a fresh
clone, and it too was slow as molasses.  Maybe running git-gc on your
repository would help, but at least on my clone, git-gc was finished
very fast and thus probably did not do much anymore.

Anyway: the quality of the results is very good.  This makes it much
easier to figure out things about the multi-tty branch.

Thanks very much!

-- 
David Kastrup

Re: emacs.git mirror status

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> Well, the synch is progressing at glacial speed so I can't say
>>> anything about it yet.
>>
>> Yes, I see that here, too (independent of the transport protocol, it
>> spends all the time in indexing the objects).  It might be related to
>> the way the tree is structured.
>>
>>> I hope that it was no mistake to do git-pull rather than a fresh
>>> clone.
>>
>> A clone has the same problem.
>
> But the pull dropped out with merge conflicts.  So I did a fresh
> clone, and it too was slow as molasses.

Note: that can be a general problem with the http repository access:
it is not efficient.  So if your server setup does not allow anything
else, maybe you could check with Jim whether it would be feasible to
push this into the "official" Emacs git mirror?  Would be good to
have, anyway.

-- 
David Kastrup

Re: emacs.git mirror status

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

>> But the pull dropped out with merge conflicts.

Of course, it does.  Much of the history has been rewritten.

> Note: that can be a general problem with the http repository access:
> it is not efficient.

All the work is done on the client, the server just provides the packs
and tags for download (as you can easily see: after the packs are
downloaded no further communication is done).  Note that the tree was
freshly gc'd as of yesterday.  This really does not have anything to do
with the transport.

> So if your server setup does not allow anything else, maybe you could
> check with Jim whether it would be feasible to push this into the
> "official" Emacs git mirror?

The tree is meant to be temporary, only for testing.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs.git mirror status

[Jim Meyering]

Andreas Schwab <schwab@suse.de> wrote:
> David Kastrup <dak@gnu.org> writes:
>
>>> But the pull dropped out with merge conflicts.
>
> Of course, it does.  Much of the history has been rewritten.
>
>> Note: that can be a general problem with the http repository access:
>> it is not efficient.
>
> All the work is done on the client, the server just provides the packs
> and tags for download (as you can easily see: after the packs are
> downloaded no further communication is done).  Note that the tree was
> freshly gc'd as of yesterday.  This really does not have anything to do
> with the transport.
>
>> So if your server setup does not allow anything else, maybe you could
>> check with Jim whether it would be feasible to push this into the
>> "official" Emacs git mirror?
>
> The tree is meant to be temporary, only for testing.

If you guys are happy with Andreas' tree, let me know.
Then I'll put it on savannah and use it as a basis when
sync'ing every 30-40min.

Re: emacs.git mirror status

[David Kastrup]

Jim Meyering <jim@meyering.net> writes:

> Andreas Schwab <schwab@suse.de> wrote:
>> David Kastrup <dak@gnu.org> writes:
>>
>>> So if your server setup does not allow anything else, maybe you could
>>> check with Jim whether it would be feasible to push this into the
>>> "official" Emacs git mirror?
>>
>> The tree is meant to be temporary, only for testing.
>
> If you guys are happy with Andreas' tree, let me know.
> Then I'll put it on savannah and use it as a basis when
> sync'ing every 30-40min.

I have used it just a bit up to now, but I very much liked what I saw.

-- 
David Kastrup

Re: emacs.git mirror status

[Jim Meyering]

David Kastrup <dak@gnu.org> wrote:

> Jim Meyering <jim@meyering.net> writes:
>
>> Andreas Schwab <schwab@suse.de> wrote:
>>> David Kastrup <dak@gnu.org> writes:
>>>
>>>> So if your server setup does not allow anything else, maybe you could
>>>> check with Jim whether it would be feasible to push this into the
>>>> "official" Emacs git mirror?
>>>
>>> The tree is meant to be temporary, only for testing.
>>
>> If you guys are happy with Andreas' tree, let me know.
>> Then I'll put it on savannah and use it as a basis when
>> sync'ing every 30-40min.
>
> I have used it just a bit up to now, but I very much liked what I saw.

Ok.  If no one objects soon, I'll switch.

Re: emacs.git mirror status

[Jim Meyering]

Jim Meyering <jim@meyering.net> wrote:
...
>>> If you guys are happy with Andreas' tree, let me know.
>>> Then I'll put it on savannah and use it as a basis when
>>> sync'ing every 30-40min.
>>
>> I have used it just a bit up to now, but I very much liked what I saw.
>
> Ok.  If no one objects soon, I'll switch.

I've just copied Andreas' tree and sync'd the last few days
worth of deltas into it.  FWIW, after running git-cvsimport,
my push to the public repo took a *lot* of CPU cycles.
I didn't time it, but I think it was over 15 minutes worth,
maybe even 25 or 30.

Of course, refs have changed, so you might want to start afresh:

    git-clone --reference emacs/.git --no-hardlinks \
      git://git.sv.gnu.org/emacs emacs-new

That command creates a sibling hierarchy, emacs-new/,
assuming you have an existing emacs/.git, reusing what
bits it can, to save network bandwidth.