Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
On Thu, Jan 24, 2013 at 10:55:57PM -0600, Chris Rorvick wrote: On Wed, Jan 23, 2013 at 3:12 PM, John Keeping j...@keeping.me.uk wrote: The existing script (git-cvsimport.perl) won't ever work with cvsps-3 since features it relies on have been removed. Not reporting the ancestry branch seems to be the big one. Are there others? For some reason I thought the non-fast-export output mode had already been removed, but now that I check it looks like it's still there just with a warning that it may be removed in the future. John -- 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: What's cooking in git.git (Jan 2013, #08; Tue, 22)
On Wed, Jan 23, 2013 at 3:12 PM, John Keeping j...@keeping.me.uk wrote: The existing script (git-cvsimport.perl) won't ever work with cvsps-3 since features it relies on have been removed. Not reporting the ancestry branch seems to be the big one. Are there others? I had a version of the Perl script sort of working, but only well enough to pass the t9600 and t9604 tests. Chris -- 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: What's cooking in git.git (Jan 2013, #08; Tue, 22)
On Tue, Jan 22, 2013 at 04:11:59PM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: Would you mind holding off on this? As it stands there are a couple of issues with the cvsimport-3 script including: ... Actually I do. I think this, at least the early part of it, should be merged to 'next' as soon as possible, *unless* (1) The cvsimport-2 cvsps2 combo this series ships gives worse experience than cvsimport we ship in v1.8.1 to end users of the current cvsimport with cvsps2; and/or (2) The cvsimport-3 in this series, which is a copy of an older version of what Eric has, is so broken that we are better off starting cvsimport-3 by getting a fresh copy from Eric which has been rewritten in a major way, than applying huge incremental update patches that amounts to a total rewrite. The point (1) is important from no regression point of view, and in a sense more important between the two because it is the first step in the overall transition plan. Even though there may be remaining issues in cvsimport-3 and cvsps3 (what new piece of software don't have issues?), my limited observation of the exchanges between you and Eric suggests me that the problem is not something that requires a total rewrite of how cvsimport-3 works, so I do not expect the point (2) to be true, either, but if I am mistaken, please let me know. ESR's cvsimport.py in the cvsps repository has no fixes over what's here. I think his comment in [1] indicates that he won't do any more work on git-cvsimport. [1] http://article.gmane.org/gmane.comp.version-control.git/214057 In my opinion the incremental import support really is substantially worse in cvsimport-3 than cvsimport-2. cvsimport-2 looks at the output of git-for-each-ref to calculate the dates from which to continue each branch. cvsps cannot be told this information and so the cvsimport-3 script just takes the date of the last commit on the current branch. On top of that, the incremental switch to cvsps-3 just causes it to output: from: refs/heads/branch^0 on the first commit for each branch, which I can't see working if a new branch is created in CVS. By advancing the topic to 'next', we will give people a more solid (read: not getting rewound) foundation to work with than if you are really interested, grab the tip of 'pu', replace it with even newer copy from Eric's repository and try it out, so that more people can help us polish the scaffolding to let us ship two versions and also find issues in the new cvsimport-3 and help fixing them. At least, that is what I've been hoping. That's what I've done and it's convinced me that cvsps-3 is not ready for use with incremental imports as it stands. I could stop at the first three patches, that is, introducing the version switch wrapper that switches between cvsps2+cvsimport-2 combo and nothing, and then let you and Eric redo the start adding cvsps 3.x support and later patches when cvsimport-3 is ready. That would give you a larger lattitude to rework cvsimport-3. Is that preferrable? My preference would be for something like this, possibly with an expanded examples section showing how to pipe the output of cvsps-3 or cvs2git into git-fast-import: -- 8 -- diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index 9d5353e..20b846e 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -18,6 +18,11 @@ SYNOPSIS DESCRIPTION --- +*WARNING:* `git cvsimport` uses cvsps version 2, which is considered +deprecated; it does not work with cvsps version 3 and later. If you are +performing a one-shot import of a CVS repository consider using cvsps-3, +cvs2git or parsecvs directly. + Imports a CVS repository into git. It will either create a new repository, or incrementally import into an existing one. -- 8 -- John -- 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: What's cooking in git.git (Jan 2013, #08; Tue, 22)
On Wed, Jan 23, 2013 at 3:28 AM, John Keeping j...@keeping.me.uk wrote: In my opinion the incremental import support really is substantially worse in cvsimport-3 than cvsimport-2. cvsimport-2 looks at the output of git-for-each-ref to calculate the dates from which to continue each branch. cvsps cannot be told this information and so the cvsimport-3 script just takes the date of the last commit on the current branch. Do you really need a timestamp per branch, though? If you have branches A and B, and B has a commit timestamp 5 minutes after A, you can infer that nothing happened on A for those five minutes, right? So maybe a single timestamp is sufficient, it just may not be picking the right one. Instead cvsimport-3 should compute the latest timestamp across all import branches. Chris -- 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: What's cooking in git.git (Jan 2013, #08; Tue, 22)
On Wed, Jan 23, 2013 at 07:26:24AM -0600, Chris Rorvick wrote: On Wed, Jan 23, 2013 at 3:28 AM, John Keeping j...@keeping.me.uk wrote: In my opinion the incremental import support really is substantially worse in cvsimport-3 than cvsimport-2. cvsimport-2 looks at the output of git-for-each-ref to calculate the dates from which to continue each branch. cvsps cannot be told this information and so the cvsimport-3 script just takes the date of the last commit on the current branch. Do you really need a timestamp per branch, though? If you have branches A and B, and B has a commit timestamp 5 minutes after A, you can infer that nothing happened on A for those five minutes, right? So maybe a single timestamp is sufficient, it just may not be picking the right one. Instead cvsimport-3 should compute the latest timestamp across all import branches. The problem is telling which is an import branch, since it currently just used refs/heads/branch. I do have a change to write the timestamp to a file, which takes the newest commit across all of the branches that have changed during an import. That may well be good enough but doesn't let you incrementally update a repository that has been cloned from elsewhere. John -- 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: What's cooking in git.git (Jan 2013, #08; Tue, 22)
John Keeping j...@keeping.me.uk writes: My preference would be for something like this, possibly with an expanded examples section showing how to pipe the output of cvsps-3 or cvs2git into git-fast-import: -- 8 -- diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index 9d5353e..20b846e 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -18,6 +18,11 @@ SYNOPSIS DESCRIPTION --- +*WARNING:* `git cvsimport` uses cvsps version 2, which is considered +deprecated; it does not work with cvsps version 3 and later. If you are +performing a one-shot import of a CVS repository consider using cvsps-3, +cvs2git or parsecvs directly. + Imports a CVS repository into git. It will either create a new repository, or incrementally import into an existing one. -- 8 -- OK, that is certainly a lot simpler to explain. Is it it does not work yet with cvsps3, or it will not ever work with cvsps3? The impression I am getting is that it is the latter. Also, should we have a suggestion to people who are *not* performing a one-shot import, i.e. doing incremental or bidirectional? -- 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: What's cooking in git.git (Jan 2013, #08; Tue, 22)
On Wed, Jan 23, 2013 at 09:13:27AM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: My preference would be for something like this, possibly with an expanded examples section showing how to pipe the output of cvsps-3 or cvs2git into git-fast-import: -- 8 -- diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index 9d5353e..20b846e 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -18,6 +18,11 @@ SYNOPSIS DESCRIPTION --- +*WARNING:* `git cvsimport` uses cvsps version 2, which is considered +deprecated; it does not work with cvsps version 3 and later. If you are +performing a one-shot import of a CVS repository consider using cvsps-3, +cvs2git or parsecvs directly. + Imports a CVS repository into git. It will either create a new repository, or incrementally import into an existing one. -- 8 -- OK, that is certainly a lot simpler to explain. Is it it does not work yet with cvsps3, or it will not ever work with cvsps3? The impression I am getting is that it is the latter. The existing script (git-cvsimport.perl) won't ever work with cvsps-3 since features it relies on have been removed. Also, should we have a suggestion to people who are *not* performing a one-shot import, i.e. doing incremental or bidirectional? As far as I know cvsps is the only backend that attempts to support partial exports but the support for that in its fast-export mode needs work before I would consider it reliable. For now the existing git-cvsimport is the best option I'm aware of. John -- 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: What's cooking in git.git (Jan 2013, #08; Tue, 22)
John Keeping j...@keeping.me.uk writes: Is it it does not work yet with cvsps3, or it will not ever work with cvsps3? The impression I am getting is that it is the latter. The existing script (git-cvsimport.perl) won't ever work with cvsps-3 since features it relies on have been removed. I think you knew I already knew that. I was hoping that cvsimport-3 that has multiple backend support may be able to start working by reading the fast-import stream cvsps3 produces, once you sort out the last exported timestamp issue out. As far as the end users are concerned, they would still be using cvsimport, even though the wrapper may redirect the invocation to cvsimport-3. In any case, something like that will not happen in the near term, if ever, so cvsimport will not work if you only have cvsps3 is a good thing to add to its documentation. Care to roll a proper patch with a log message? I'll discard the topic for now and replace it with your documentation update. Also, should we have a suggestion to people who are *not* performing a one-shot import, i.e. doing incremental or bidirectional? As far as I know cvsps is the only backend that attempts to support partial exports but the support for that in its fast-export mode needs work before I would consider it reliable. For now the existing git-cvsimport is the best option I'm aware of. Thanks. -- 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
What's cooking in git.git (Jan 2013, #08; Tue, 22)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. As usual, this cycle is expected to last for 8 to 10 weeks, with a preview -rc0 sometime in the middle of next month. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * bc/fix-array-syntax-for-3.0-in-completion-bash (2013-01-18) 1 commit - git-completion.bash: replace zsh notation that breaks bash 3.X Fix use of an array notation that older versions of bash do not understand. Will merge to 'next'. * jc/help (2013-01-18) 1 commit - help: include common-cmds.h only in one file A header file that has the definition of a static array was included in two places, wasting the space. Will merge to 'next'. * jc/hidden-refs (2013-01-18) 2 commits - upload-pack: allow hiding ref hiearchies - upload-pack: share more code Allow the server side to unclutter the refs/ namespace it shows by default, while still allowing requests for histories leading to the tips of hidden refs by updated clients (which are not written yet). * jk/update-install-for-p4 (2013-01-20) 1 commit - INSTALL: git-p4 doesn't support Python 3 Will merge to 'next'. * tb/t0050-maint (2013-01-21) 3 commits - t0050: Use TAB for indentation - t0050: honor CASE_INSENSITIVE_FS in add (with different case) - t0050: known breakage vanished in merge (case change) Will merge to 'next'. * nd/magic-pathspec-from-root (2013-01-21) 2 commits - grep: avoid accepting ambiguous revision - Update :/abc ambiguity check Will merge to 'next'. * ta/doc-no-small-caps (2013-01-21) 7 commits - Add rule for when to use 'git' and when to use 'Git' - Change 'git' to 'Git' whenever the whole system is referred to #4 - Change 'git' to 'Git' whenever the whole system is referred to #3 - Change 'git' to 'Git' whenever the whole system is referred to #2 - Change 'git' to 'Git' whenever the whole system is referred to #1 - Documentation: update two leftover small caps - Documentation: avoid poor-man's small caps Update documentation to change GIT which was a poor-man's small caps to Git which was the intended spelling. Also change git spelled in all-lowercase to Git when it refers to the system as the whole or the concept it embodies, as opposed to the command the end users would type. * rr/minimal-stat (2013-01-22) 1 commit - Enable minimal stat checking Some reimplementations of Git does not write all the stat info back to the index due to their implementation limitations (e.g. jgit running on Java). A configuration option can tell Git to ignore changes to most of the stat fields and only pay attention to mtime and size, which these implementations can reliably update. This avoids excessive revalidation of contents. Will merge to 'next'. -- [Graduated to master] * ap/log-mailmap (2013-01-10) 11 commits (merged to 'next' on 2013-01-10 at 8544084) + log --use-mailmap: optimize for cases without --author/--committer search + log: add log.mailmap configuration option + log: grep author/committer using mailmap + test: add test for --use-mailmap option + log: add --use-mailmap option + pretty: use mailmap to display username and email + mailmap: add mailmap structure to rev_info and pp + mailmap: simplify map_user() interface + mailmap: remove email copy and length limitation + Use split_ident_line to parse author and committer + string-list: allow case-insensitive string list Teach commands in the log family to optionally pay attention to the mailmap. * ds/completion-silence-in-tree-path-probe (2013-01-11) 1 commit (merged to 'next' on 2013-01-15 at 7542d21) + git-completion.bash: silence not a valid object errors An internal ls-tree call made by completion code only to probe if a path exists in the tree recorded in a commit object leaked error messages when the path is not there. It is not an error at all and should not be shown to the end user. * fc/remote-hg-fixup-url (2013-01-15) 1 commit (merged to 'next' on 2013-01-15 at d2acb2d) + remote-hg: store converted URL Update to the Hg remote helper (in contrib/). * jn/maint-trim-vim-contrib (2013-01-10) 1 commit (merged to 'next' on 2013-01-15 at ad80a9d) + contrib/vim: simplify instructions for old vim support Remove stale insn to support older versions of vim and point users to the upstream resources. * mh/remote-hg-mode-bits-fix (2013-01-15) 1 commit (merged to 'next' on 2013-01-15 at ad57d9f) + remote-hg: fix handling of file perms when pushing Update to the Hg remote helper (in contrib/). * mk/complete-tcsh (2013-01-07) 1 commit (merged to 'next' on 2013-01-11 at b8b30b1) + Prevent space after directories in tcsh completion
Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
On Tue, Jan 22, 2013 at 02:44:48PM -0800, Junio C Hamano wrote: * jc/cvsimport-upgrade (2013-01-14) 8 commits - t9600: adjust for new cvsimport - t9600: further prepare for sharing - cvsimport-3: add a sample test - cvsimport: make tests reusable for cvsimport-3 - cvsimport: start adding cvsps 3.x support - cvsimport: introduce a version-switch wrapper - cvsimport: allow setting a custom cvsps (2.x) program name - Makefile: add description on PERL/PYTHON_PATH The most important part of this series is the addition of the new cvsimport by Eric Raymond that works with cvsps 3.x. Given some distros have inertia to be conservative, Git with cvsimport that does not work with both 3.x will block adoption of cvsps 3.x by them, and shipping Git with cvsimport that does not work with cvsps 2.x will block such a version of Git, so we'll do the proven both old and new are available, but we aim to deprecate and remove the old one in due time strategy that we used successfully in the past. Will merge to 'next'. Would you mind holding off on this? As it stands there are a couple of issues with the cvsimport-3 script including: * It doesn't read any configuration from git config as git-cvsimport-2 does. * Incremental import is copmletely broken - it needs to pass -i to cvsps-3 and even then timestamp handling is completely broken. I have fixes for these that are nearly ready, but to fully fix the incremental import issue I'll need to persuade ESR to take a patch which lets us feed cvsps-3 a mapping from branch names to last commit times. I suspect people are already used to the ways in which cvsimport-2 is broken so I think we should take a bit more time to get this right with cvsimport-3, especially since the people most likely to be using this will be those regularly updating from a CVS repository with incremental updates. John -- 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: What's cooking in git.git (Jan 2013, #08; Tue, 22)
John Keeping j...@keeping.me.uk writes: On Tue, Jan 22, 2013 at 02:44:48PM -0800, Junio C Hamano wrote: * jc/cvsimport-upgrade (2013-01-14) 8 commits - t9600: adjust for new cvsimport - t9600: further prepare for sharing - cvsimport-3: add a sample test - cvsimport: make tests reusable for cvsimport-3 - cvsimport: start adding cvsps 3.x support - cvsimport: introduce a version-switch wrapper - cvsimport: allow setting a custom cvsps (2.x) program name - Makefile: add description on PERL/PYTHON_PATH The most important part of this series is the addition of the new cvsimport by Eric Raymond that works with cvsps 3.x. Given some distros have inertia to be conservative, Git with cvsimport that does not work with both 3.x will block adoption of cvsps 3.x by them, and shipping Git with cvsimport that does not work with cvsps 2.x will block such a version of Git, so we'll do the proven both old and new are available, but we aim to deprecate and remove the old one in due time strategy that we used successfully in the past. Will merge to 'next'. Would you mind holding off on this? As it stands there are a couple of issues with the cvsimport-3 script including: ... Actually I do. I think this, at least the early part of it, should be merged to 'next' as soon as possible, *unless* (1) The cvsimport-2 cvsps2 combo this series ships gives worse experience than cvsimport we ship in v1.8.1 to end users of the current cvsimport with cvsps2; and/or (2) The cvsimport-3 in this series, which is a copy of an older version of what Eric has, is so broken that we are better off starting cvsimport-3 by getting a fresh copy from Eric which has been rewritten in a major way, than applying huge incremental update patches that amounts to a total rewrite. The point (1) is important from no regression point of view, and in a sense more important between the two because it is the first step in the overall transition plan. Even though there may be remaining issues in cvsimport-3 and cvsps3 (what new piece of software don't have issues?), my limited observation of the exchanges between you and Eric suggests me that the problem is not something that requires a total rewrite of how cvsimport-3 works, so I do not expect the point (2) to be true, either, but if I am mistaken, please let me know. By advancing the topic to 'next', we will give people a more solid (read: not getting rewound) foundation to work with than if you are really interested, grab the tip of 'pu', replace it with even newer copy from Eric's repository and try it out, so that more people can help us polish the scaffolding to let us ship two versions and also find issues in the new cvsimport-3 and help fixing them. At least, that is what I've been hoping. I could stop at the first three patches, that is, introducing the version switch wrapper that switches between cvsps2+cvsimport-2 combo and nothing, and then let you and Eric redo the start adding cvsps 3.x support and later patches when cvsimport-3 is ready. That would give you a larger lattitude to rework cvsimport-3. Is that preferrable? -- 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
