Serious flaws in git cvsimport
Hello, I really hate working with CVS, so I have set up a cronjob running git cvsimport on regular basis to create a mirror of gnuplot sources. I would use another tool, but until a few days ago I wasn't aware of anything else that supported incremental updates, so that I could run the conversion every few hours without the need to trash the old conversions and make all my local/testing branches incompatible with future development. I had a lot of problems with the tool, but I was tolerating it (in the spirit of numerous warnings that the tool isn't working properly): - Files that have been deleted from CVS long ago don't get removed from git (that's very very very annoying) - I have numerous problems with file permissions (executable vs. non-executable) - The first time when I do the import, all seems fine. But soon after that I start getting numerous warnings during conversion in the spirit of revision 1.X of file Y is tagged but not present But maybe that's a bug in CVS. But recently I discovered that a commit in the main branch of CVS (trunk/master/whatever-they-call-it-in-cvs) which was important to me was simply ignored by git cvsimport. The commit modified three files. Immediately after the commit, cvsimport claimed the repository was already up-to-date. After other changes have been done in CVS, bits and pieces from that important commit started appearing randomly, together with other commits to CVS – for example when the same file was modified in another commit, changes from that important commit to the same file were included as well in that later commit (but they didn't belong to each other). My understanding was that warnings about bad behaviour of git cvsimport were related mostly to inability to reproduce complicated branching and merging with zillions of branches. That would be acceptable to me because I wasn't interested in those zillions of branches and tags anyway. But it turned out that whatever is currently in the master branch of the repository created by git cvsimport isn't even corresponding to what's currently in CVS and some commits are simply missing from history along with their commit messages. The git repository contains too many files (those that have been deleted in CVS) and random other differences in random files, so that I'm not even able to compile the project any longer as a consequence. I'm willing to provide the exact details about the failures, but from what I understand the previous maintainer of the underlying tool (cvsps) deprecated it due to too numerous problems and flawed design, so I'm not sure if anyone would be willing to fix the bugs I'm running into. I'm currently testing cvs-fast-export of which I only heard a few days ago in the desperate search for a replacement for git cvsimport. It would be nice to see if manuals of cvsimport would at least mention the existence of that tool in the same way as it mentions cvs2git (it took me a while to learn about cvs-fast-export) or even better, to consider it as an alternative for cvsps via a special argument to cvsimport if that's possible. Thank you very much, Mojca (Please CC me in replies.) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
inconsistent logs when displayed on screen / piped to a file
Hello, I'm trying to use git log to generate ChangeLog for a project recently migrated from CVS. The problem is that git log --summary --stat --no-merges --date=short --decorate=short behaves differently when the result is displayed on screen and when it is piped to a file. For example, running the commands: a) git log --summary --stat --no-merges --date=short --decorate=short e9f65aa976 b) git log --summary --stat --no-merges --date=short --decorate=short e9f65aa976 /tmp/log.txt would result in two different outputs: a) aquaterm/Docs/gptProtocol.rtf | 316 ++ aquaterm/English.lproj/GPTInfoWindow.nib/classes.nib | 12 + aquaterm/English.lproj/GPTInfoWindow.nib/info.nib | 12 + aquaterm/English.lproj/GPTInfoWindow.nib/objects.nib | Bin 0 - 1010 bytes aquaterm/English.lproj/GPTInfoWindow~.nib/classes.nib |4 + aquaterm/English.lproj/GPTInfoWindow~.nib/info.nib| 12 + aquaterm/English.lproj/GPTInfoWindow~.nib/objects.nib | Bin 0 - 1232 bytes aquaterm/English.lproj/GPTWindow.nib/classes.nib | 13 ++ aquaterm/English.lproj/GPTWindow.nib/info.nib | 12 + b) aquaterm/Docs/gptProtocol.rtf | 316 ++ .../English.lproj/GPTInfoWindow.nib/classes.nib| 12 + aquaterm/English.lproj/GPTInfoWindow.nib/info.nib | 12 + .../English.lproj/GPTInfoWindow.nib/objects.nib| Bin 0 - 1010 bytes .../English.lproj/GPTInfoWindow~.nib/classes.nib |4 + aquaterm/English.lproj/GPTInfoWindow~.nib/info.nib | 12 + .../English.lproj/GPTInfoWindow~.nib/objects.nib | Bin 0 - 1232 bytes aquaterm/English.lproj/GPTWindow.nib/classes.nib | 13 + aquaterm/English.lproj/GPTWindow.nib/info.nib | 12 + The project where the results could be easily reproduced is the following: https://github.com/AquaTerm/AquaTerm git://github.com/AquaTerm/AquaTerm.git It is possible that I screwed up something when importing the project from CVS. In that case I would be happy if someone could point me out what exactly I did wrong, and I can still rewrite the history before the first release of the project using git. But in any case I find it weird that I get two different outputs. I would be grateful for any clues or hints about what goes wrong. Mojca -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: inconsistent logs when displayed on screen / piped to a file
On Mon, Jul 30, 2012 at 3:39 PM, Michael J Gruber wrote: Mojca Miklavec venit, vidit, dixit 30.07.2012 14:25: I'm trying to use git log to generate ChangeLog for a project recently migrated from CVS. The problem is that git log --summary --stat --no-merges --date=short --decorate=short behaves differently when the result is displayed on screen and when it is piped to a file. The only difference that I see is the formatting. (... is merely an abbreviation for a leading path.) a) probes your terminal for the number of columns and uses all available space. b) goes to a file and has no connected terminal, thus uses a default column number. You can change that number using COLUMNS=YourNumber git log YourArgs YourFile Wow, perfect, thank you very much. Setting COLUMNS=200 (the high number just in case) solved the problem. Mojca -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
