From: Martin Langhoff <hidden> Date: 2016-06-15 22:44:11
Derek Mahar wrote:
Thank you. You've pointed out another good reason to dislike (or
despise?) CVS. I feel very unfortunate that I must still use CVS. Makes
me even miss Perforce. git-cvsexportcommit certainly helps, but the fact
that it cannot require CVS to preserve the original Git timestamps means
that in order to make the commit times between Git and CVS roughly the
same, I'll have to commit to both Git an CVS at the same time. Is this
how you usually work with git-cvsexportcommit?
I just don't worry about the timestamps ;-)
I normally track the Moodle CVS tree, and do all my "new feature" and
"client customization" branches in git. The feature branches I rebase
aggressively, until they are ready to be "landed" in CVS. It is in that
"landing in cvs" that I use cvsexportcommit, usually with a long list of
commits!
cheers,
m
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
NZ: +64(4)916-7224 MOB: +64(21)364-017 UK: 0845 868 5733 ext 7224
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
Martin Langhoff <martin <at> catalyst.net.nz> writes:
I just don't worry about the timestamps
I normally track the Moodle CVS tree, and do all my "new feature" and
"client customization" branches in git. The feature branches I rebase
aggressively, until they are ready to be "landed" in CVS. It is in that
"landing in cvs" that I use cvsexportcommit, usually with a long list of
commits!
How do you get git-cvsimport to avoid the "duplicate" commit that it creates
when it imports a commit that you "landed" in CVS with git-cvsexportcommit? I
call this commit a duplicate because though it has a different SHA1 identifier,
commit timestamp, and even committer email address, it refers to the same tree
identifier as the landed commit. However, because it has the same textual
difference as the landed commit, the duplicate commit introduces no new textual
difference. It is essentially an "empty" commit. Do you just accept and ignore
this empty commit?
Derek
From: Robin Rosenberg <hidden> Date: 2016-06-15 22:44:12
söndagen den 10 februari 2008 skrev Derek Mahar:
How do you get git-cvsimport to avoid the "duplicate" commit that it creates
when it imports a commit that you "landed" in CVS with git-cvsexportcommit? I
call this commit a duplicate because though it has a different SHA1 identifier,
commit timestamp, and even committer email address, it refers to the same tree
identifier as the landed commit. However, because it has the same textual
difference as the landed commit, the duplicate commit introduces no new textual
difference. It is essentially an "empty" commit. Do you just accept and ignore
this empty commit?
git rebase will drop those "empty" commits by default and you'll end up with the
cvs-imported version.
-- robin
On Feb 10, 2008 12:45 AM, Robin Rosenberg
[off-list ref] wrote:
söndagen den 10 februari 2008 skrev Derek Mahar:
quoted
How do you get git-cvsimport to avoid the "duplicate" commit that it creates
when it imports a commit that you "landed" in CVS with git-cvsexportcommit?
git rebase will drop those "empty" commits by default and you'll end up with the
cvs-imported version.
How do I perform this rebase if the empty commit is on the same
branch, say the master branch, as the original CVS landed commit? I
attempted such a git-rebase using 1.5.4, but, iirc, git-rebase
responded that the branch was already up-to-date.
Derek
On Feb 10, 2008 1:01 AM, Derek Mahar [off-list ref] wrote:
On Feb 10, 2008 12:45 AM, Robin Rosenberg
[off-list ref] wrote:
quoted
git rebase will drop those "empty" commits by default and you'll end up with the
cvs-imported version.
How do I perform this rebase if the empty commit is on the same
branch, say the master branch, as the original CVS landed commit? I
attempted such a git-rebase using 1.5.4, but, iirc, git-rebase
responded that the branch was already up-to-date.
On second thought, I don't recall with what message git-rebase
responded, but I do recall that the commit was still on the master
branch.
Derek
From: Robin Rosenberg <hidden> Date: 2016-06-15 22:44:12
söndagen den 10 februari 2008 skrev Derek Mahar:
On Feb 10, 2008 1:01 AM, Derek Mahar [off-list ref] wrote:
quoted
On Feb 10, 2008 12:45 AM, Robin Rosenberg
[off-list ref] wrote:
quoted
git rebase will drop those "empty" commits by default and you'll end up with the
cvs-imported version.
How do I perform this rebase if the empty commit is on the same
branch, say the master branch, as the original CVS landed commit? I
attempted such a git-rebase using 1.5.4, but, iirc, git-rebase
responded that the branch was already up-to-date.
On second thought, I don't recall with what message git-rebase
responded, but I do recall that the commit was still on the master
branch.
As I recall it (I'm using fromcvs, not git-cvsimport) cvs HEAD get imported
into origin which on initial import gets copied to master. So I think you
should git rebase origin
-- robin
On Feb 10, 2008 8:15 AM, Robin Rosenberg
[off-list ref] wrote:
söndagen den 10 februari 2008 skrev Derek Mahar:
As I recall it (I'm using fromcvs, not git-cvsimport) cvs HEAD get imported
into origin which on initial import gets copied to master. So I think you
should git rebase origin
When it drops the extra commit, is there a way to ask git-rebase to
keep the textual change of the original commit, but use the commit
information from the imported CVS commit? This way, the resulting Git
repository would match that of another user who performs an initial
git-cvsimport of the entire CVS repository.
Can fromcvs read from a remote CVS repository via pserver or does it
only parse the RCS files directly? I have only pserver access to our
CVS repo,
Derek
From: Robin Rosenberg <hidden> Date: 2016-06-15 22:44:12
söndagen den 10 februari 2008 skrev Derek Mahar:
On Feb 10, 2008 8:15 AM, Robin Rosenberg
[off-list ref] wrote:
quoted
söndagen den 10 februari 2008 skrev Derek Mahar:
As I recall it (I'm using fromcvs, not git-cvsimport) cvs HEAD get imported
into origin which on initial import gets copied to master. So I think you
should git rebase origin
When it drops the extra commit, is there a way to ask git-rebase to
keep the textual change of the original commit, but use the commit
information from the imported CVS commit? This way, the resulting Git
repository would match that of another user who performs an initial
git-cvsimport of the entire CVS repository.
No, for that to happen the full history must match. Maybe theoretically
possible, but then, in theory, you could use only Git and not worry about
CVS.
If you involve CVS (or any other SCM) you must rebase on top of the
CVS imported version, whether your repo is a clone or not. The changed
commit to me also means I can see wheter it s a pure git checkin or
whether it is from the official CVS repo, which is a "good" thing.
Can fromcvs read from a remote CVS repository via pserver or does it
only parse the RCS files directly? I have only pserver access to our
CVS repo,
RCS only. Note that sometimes you have rsync access. If not politely ask
the admin of the repo that you get read access to the raw files. (the CVSROOT/*
files are not needed in case that is a concern).
-- robin
On Feb 10, 2008 11:17 AM, Robin Rosenberg
[off-list ref] wrote:
If you involve CVS (or any other SCM) you must rebase on top of the
CVS imported version, whether your repo is a clone or not. The changed
commit to me also means I can see wheter it s a pure git checkin or
whether it is from the official CVS repo, which is a "good" thing.
Good point. I can also keep a second "pure" git clone of the CVS repo
from which other users make copies.
quoted
Can fromcvs read from a remote CVS repository via pserver or does it
only parse the RCS files directly? I have only pserver access to our
CVS repo,
RCS only. Note that sometimes you have rsync access. If not politely ask
the admin of the repo that you get read access to the raw files. (the CVSROOT/*
files are not needed in case that is a concern).