reflogs generated by git-cvsimport

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]