From: Kalle Olavi Niemitalo <kon@iki.fi>
To: git@vger.kernel.org
Subject: reflogs generated by git-cvsimport
Date: Fri, 31 Jul 2009 20:42:26 +0300 [thread overview]
Message-ID: <87fxccagvx.fsf@Astalo.kon.iki.fi> (raw)
When I run git cvsimport incrementally, it generates a reflog
entry for each CVS commit, because it runs git-update-ref after
each git-commit-tree. I think it'd be nicer to make just one
reflog entry at the end, when all CVS patchsets have been
imported. I could then use git log cvs/master@{1}..cvs/master
to see all the commits on master that were imported in the
latest run.
If git-cvsimport.perl kept the commit IDs in Perl variables only,
and then updated the refs once at the end, I'd get the reflogs I
prefer. However, if the script were interrupted in the middle,
it would then leave the refs unchanged, and the next cvsimport
run would have to download the same commits again. I suppose
that could be fixed with some $SIG{'INT'} handler. But then how
about the git repack -a -d that git-cvsimport.perl runs every
1024 commits: could that lose some commits that have been
imported from CVS but not yet saved in any ref?
Would it be better to create temporary refs/cvsimport/* and then
finally update the real refs based on those?
There's also another problem with the reflogs. The current
version of git-cvsimport sets GIT_COMMITTER_DATE and related
variables for git-commit-tree, and then leaves them set for
git-update-ref. So git-update-ref saves the author and date of
the CVS commit into the reflog. It would be better to save the
name of the person who is running git cvsimport, and the local
time. That one I've already fixed in my local version, but I'm
not really happy with how the code turned out.
next reply other threads:[~2009-07-31 17:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-31 17:42 Kalle Olavi Niemitalo [this message]
2009-07-31 19:13 ` reflogs generated by git-cvsimport Jeff King
2009-07-31 20:15 ` Kalle Olavi Niemitalo
2009-07-31 20:40 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fxccagvx.fsf@Astalo.kon.iki.fi \
--to=kon@iki.fi \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox