Re: git-cvsexportcommit and commit date

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

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

> 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?
>
> git rebase will drop those "empty" commits by default and you'll end up with the
> cvs-imported version.

> On Feb 10, 2008 12:45 AM, Robin Rosenberg
> <robin.rosenberg.lists@dewire.com> wrote:
> > 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 Feb 10, 2008 1:01 AM, Derek Mahar <derek.mahar@gmail.com> wrote:
> > On Feb 10, 2008 12:45 AM, Robin Rosenberg
> > <robin.rosenberg.lists@dewire.com> wrote:
> > > 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.

> On Feb 10, 2008 8:15 AM, Robin Rosenberg
> <robin.rosenberg.lists@dewire.com> 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,
> 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).