threads / discuss / 18148

What's cooking in git.git (Mar 2009, #02; Thu, 05)

Subject: What's cooking in git.git (Mar 2009, #02; Thu, 05)

## tl;dr

10 messages between Mar 5, 2009 and Mar 5, 2009.

replies: 9people: 6as markdown or json

Junio C Hamano· Mar 5, 2009, 10:07 UTC · lore

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the branches, but I am still holding onto them.

The topics list the commits in reverse chronological order. The topics meant to be merged to the maintenance series have "maint-" in their names.

The master branch is slightly past 1.6.2, but embarrasingly enough we already have a real commit on 'maint'.

---------------------------------------------------------------- [New Topics]

* hv/cvsimport-tests (Mon Mar 2 18:59:36 2009 +0100) 1 commit
 - cvsimport: add test illustrating a bug in cvsps
Yet more tests without fixing anything...
* jc/clone-branch-rebase (Tue Mar 3 22:29:55 2009 -0800) 1 commit
 - Make git-clone respect branch.autosetuprebase
This is rewrite of a patch from Pat Notz.
* mg/maint-submodule-normalize-path (Tue Mar 3 16:08:21 2009 +0100) 2 commits
 - git submodule: Fix adding of submodules at paths with ./, .. and //
 - git submodule: Add test cases for git submodule add
* kb/tracking-count-no-merges (Wed Mar 4 18:47:39 2009 +0100) 1 commit
 - stat_tracking_info(): only count real commits

This gives the merge commits zero weight when talking about how many commits you have ahead (or behind) of the branch you are tracking. Even though I agree that they should carry much less weight than the "real" commits, because your repeated merge from the other branch does not really add any real value to the end result, giving them absolute zero weight somehow feels wrong. At least it shows that your have been _active_ on the branch. But I do not feel very strongly about it.

* js/rebase-i-opt (Tue Mar 3 10:55:31 2009 +0100) 1 commit
 - rebase -i: avoid 'git reset' when possible

---------------------------------------------------------------- [Will merge to 'master' soon]

* jk/sane-relative-time (Tue Feb 24 00:42:16 2009 -0500) 1 commit
 + never fallback relative times to absolute

I think I sent out a "here is how" patch for something related to --date=<format> option that may be related to this topic; I seem to have lost it.

* js/send-email (Mon Mar 2 23:52:18 2009 -0500) 5 commits
 + send-email: add --confirm option and configuration setting
 + send-email: don't create temporary compose file until it is needed
 + send-email: --suppress-cc improvements
 + send-email: handle multiple Cc addresses when reading mbox message
 + send-email: allow send-email to run outside a repo
* sg/rerere-cleanup (Sat Feb 14 23:21:04 2009 +0100) 1 commit
 + rerere: remove duplicated functions
* jc/add-p-unquote (Mon Feb 16 22:43:43 2009 -0800) 1 commit
 + git-add -i/-p: learn to unwrap C-quoted paths
* jw/imap-preformatted-html (Thu Feb 12 08:58:12 2009 -0600) 1 commit
 + imap.preformattedHTML to tell Thunderbird to send non-flowed text

The patch text should be identical to Jeremy's "Virtual Patch", except that the configuration variable was renamed per list discussion.

* jw/format-patch-attach (Thu Feb 12 09:51:55 2009 -0600) 1 commit
 + Enable setting attach as the default in .gitconfig for git-format-
   patch.
* sr/force-rebase (Fri Feb 13 23:48:01 2009 +0100) 1 commit
 + Teach rebase to rebase even if upstream is up to date
* fg/exclude-bq (Tue Feb 10 15:20:17 2009 +0100) 1 commit
 + Support "\" in non-wildcard exclusion entries
* dm/add-i-edit-abort (Thu Feb 12 00:19:41 2009 -0500) 1 commit
 + add -i: revisit hunk on editor failure
* tp/completion (Sat Feb 21 15:48:43 2009 +0100) 6 commits
 + Fixup: Add bare repository indicator for __git_ps1
 + Add bare repository indicator for __git_ps1
 + completion: More fixes to prevent unbound variable errors
 + completion: Better __git_ps1 support when not in working directory
 + completion: Use consistent if [...] convention, not "test"
 + completion: For consistency, change "git rev-parse" to __gitdir
   calls
* js/branch-symref (Wed Feb 18 22:34:44 2009 -0500) 4 commits
 + add basic branch display tests
 + branch: clean up repeated strlen
 + Avoid segfault with 'git branch' when the HEAD is detached
 + builtin-branch: improve output when displaying remote branches
* al/ansi-color (Fri Feb 13 22:53:41 2009 +0100) 2 commits
 + builtin-branch.c: Rename branch category color names
 + Clean up use of ANSI color sequences
* js/valgrind (Thu Feb 5 22:03:00 2009 +0100) 9 commits
 + valgrind: do not require valgrind 3.4.0 or newer
 + test-lib: avoid assuming that templates/ are in the GIT_EXEC_PATH
 + Tests: let --valgrind imply --verbose and --tee
 + Add a script to coalesce the valgrind outputs
 + t/Makefile: provide a 'valgrind' target
 + test-lib.sh: optionally output to test-results/$TEST.out, too
 + Valgrind support: check for more than just programming errors
 + valgrind: ignore ldso and more libz errors
 + Add valgrind support in test scripts
* fc/config-editor (Sat Feb 21 02:48:54 2009 +0200) 3 commits
 + git config: trivial cleanup for editor action
 + git config: codestyle cleanups
 + config: Add new option to open an editor.
Rerolled and looked sane.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
 + blame: show "previous" information in --porcelain/--incremental
   format
 + git-blame: refactor code to emit "porcelain format" output

This gives Porcelains (like gitweb) the information on the commit _before_ the one that the final blame is laid on, which should save them one rev-parse to dig further. Jakub seems to want this for gitweb.

* ns/pretty-format (Tue Feb 24 15:33:29 2009 +0200) 5 commits
 + bash completion: add --format= and --oneline options for "git log"
 + Add tests for git log --pretty, --format and --oneline.
 + Add --oneline that is a synonym to "--pretty=oneline --abbrev-
   commit"
 + Give short-hands to --pretty=tformat:%formatstring
 + Add --format that is a synonym to --pretty

---------------------------------------------------------------- [Discarded]

* js/clone-depth-local (Fri Feb 27 00:04:06 2009 -0800) 3 commits
 . parse_options(): do not "increment" boolean
 . clone: ignore --depth when cloning locally (implicitly --local)
 . clone: do not ignore --no-local option

Jeff had a good suggestion for this series but it was tripped by a misfeature in parse_options().

* ns/stash-keep (Thu Feb 12 06:25:14 2009 +0900) 1 commit
 . stash: --keep option just saves

---------------------------------------------------------------- [Stalled and may need help and prodding to go forward]

* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 1 commit
 - archive.c: add support for --submodules[=(all|checkedout)]
Discussion stalled on the submodule selection criteria.
* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit
 - git-merge-file: allow converting the results for the work tree
This is a feature waiting for a user.

We did not give scripted Porcelains a way to say "this temporary file I am using for merging is for this path, so use the core.autocrlf and attributes rules for that final path". Instead, merge-file simply wrote out the data in the canonical repository representation.

rerere has the same issue, but it is a lot worse. It reads the three files (preimage, postimage and thisimage) from the work tree in the work tree representation, merges them without converting them to the canonical representation first but inserts the conflict markers with the canonical representation and writes the resulting mess out. It needs to be fixed to read with convert_to_git(), merge them while they are still in the canonical representation and possibly add conflict markers, and then write the results out after convert_to_working_tree(). It also needs to write in binary mode as well.

* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
 - Support fetching from foreign VCSes
 - Add specification of git-vcs helpers
 - Add "vcs" config option in remotes

The "spec" did not seem quite well cooked yet, but in the longer term I think something like this to allow interoperating with other SCMs as if the other end is a native git repository is a very worthy goal.

* cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
 - builtin-replace: use "usage_msg_opt" to give better error messages
 - parse-options: add new function "usage_msg_opt"
 - builtin-replace: teach "git replace" to actually replace
 - Add new "git replace" command
 - environment: add global variable to disable replacement
 - mktag: call "check_sha1_signature" with the replacement sha1
 - replace_object: add a test case
 - object: call "check_sha1_signature" with the replacement sha1
 - sha1_file: add a "read_sha1_file_repl" function
 - replace_object: add mechanism to replace objects found in
   "refs/replace/"
 - refs: add a "for_each_replace_ref" function

I think the code is much cleaner than the first round, but I am not convinced it is doing the right thing in the connectivity traverser. Independent review sorely needed.

* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
 - gitweb: Optional grouping of projects by category
 - gitweb: Split git_project_list_body in two functions
 - gitweb: Modularized git_get_project_description to be more generic

Design discussion between Jakub and Sebastien seems to have stalled, but Jakub seems to be taking this over, so I'll probably discard these three shortly.

---------------------------------------------------------------- [Actively cooking]

* kb/checkout-optim (Wed Mar 4 18:47:40 2009 +0100) 15 commits
 - better introduction of GIT with USE_NSEC defined
 + write_index(): update index_state->timestamp after flushing to
   disk
 + verify_uptodate(): add ce_uptodate(ce) test
 + make USE_NSEC work as expected
 + fix compile error when USE_NSEC is defined
 + check_updates(): effective removal of cache entries marked
   CE_REMOVE
 + lstat_cache(): print a warning if doing ping-pong between cache
   types
 + show_patch_diff(): remove a call to fstat()
 + write_entry(): use fstat() instead of lstat() when file is open
 + write_entry(): cleanup of some duplicated code
 + create_directories(): remove some memcpy() and strchr() calls
 + unlink_entry(): introduce schedule_dir_for_removal()
 + lstat_cache(): swap func(length, string) into func(string, length)
 + lstat_cache(): generalise longest_match_lstat_cache()
 + lstat_cache(): small cleanup and optimisation
* rs/memmem (Tue Mar 3 00:19:30 2009 +0100) 2 commits
 - optimize compat/ memmem()
 - diffcore-pickaxe: use memmem()
As always with patches from René, this is already next material.
* jc/push-to-create (Mon Mar 2 22:36:16 2009 -0800) 1 commit
 - Push to create

This was a failed weatherbaloon patch to allow creation of a new repository from the remote side. Will discard.

* mv/parseopt-ls-files (Tue Feb 17 15:27:11 2009 +0100) 2 commits
 - parse-opt: migrate builtin-ls-files.
 - Turn the flags in struct dir_struct into a single variable
* tv/rebase-stat (Sun Mar 1 22:28:28 2009 +0100) 2 commits
 - git-pull: Allow --stat and --no-stat to be used with --rebase
 - git-rebase: Add --stat and --no-stat for producing diffstat on
   rebase
* jk/clone-post-checkout (Tue Mar 3 00:37:51 2009 -0500) 1 commit
 - clone: run post-checkout hook when checking out
* js/remote-improvements (Wed Feb 25 03:32:28 2009 -0500) 22 commits
 - builtin-remote: new show output style for push refspecs
 - builtin-remote: new show output style
 - remote: make guess_remote_head() use exact HEAD lookup if it is
   available
 - builtin-remote: add set-head subcommand
 - builtin-remote: teach show to display remote HEAD
 - builtin-remote: fix two inconsistencies in the output of "show
   <remote>"
 - builtin-remote: make get_remote_ref_states() always populate
   states.tracked
 - builtin-remote: rename variables and eliminate redundant function
   call
 - builtin-remote: remove unused code in get_ref_states
 - builtin-remote: refactor duplicated cleanup code
 - string-list: new for_each_string_list() function
 - remote: make match_refs() not short-circuit
 - remote: make match_refs() copy src ref before assigning to
   peer_ref
 - remote: let guess_remote_head() optionally return all matches
 - remote: make copy_ref() perform a deep copy
 - remote: simplify guess_remote_head()
 - move locate_head() to remote.c
 - move duplicated ref_newer() to remote.c
 - move duplicated get_local_heads() to remote.c
 - refactor find_ref_by_name() to accept const list
 - add basic http clone/fetch tests
 - test scripts: refactor start_httpd helper
* fc/parseopt-config (Sat Feb 21 02:49:29 2009 +0200) 11 commits
 - git config: don't allow --get-color* and variable type
 - git config: don't allow extra arguments for -e or -l.
 - git config: don't allow multiple variable types
 - git config: don't allow multiple config file locations
 - git config: reorganize to use parseopt
 - git config: reorganize get_color*
 - git config: trivial rename in preparation for parseopt
 - git_config(): not having a per-repo config file is not an error
 + git config: trivial cleanup for editor action
 + git config: codestyle cleanups
 + config: Add new option to open an editor.
* tr/format-patch-thread (Thu Feb 19 22:26:33 2009 +0100) 4 commits
 - format-patch: support deep threading
 - format-patch: thread as reply to cover letter even with in-reply-
   to
 - format-patch: track several references
 - format-patch: threading test reactivation
* el/blame-date (Fri Feb 20 14:51:11 2009 -0800) 1 commit
 - Make git blame's date output format configurable, like git log

I think the above seven series were basically Ok; I'll hopefully have time to re-read them and merge them to 'next'.

* mh/cvsimport-tests (Mon Feb 23 06:08:14 2009 +0100) 5 commits
 - Add a test of "git cvsimport"'s handling of tags and branches
 - Add some tests of git-cvsimport's handling of vendor branches
 - Test contents of entire cvsimported "master" tree contents
 - Use CVS's -f option if available (ignore user's ~/.cvsrc file)
 - Start a library for cvsimport-related tests
Tests without fixes are of dubious value.  Any takers?
* tr/maint-1.6.0-send-email-irt (Sun Mar 1 23:45:41 2009 +0100) 1 commit
 - send-email: respect in-reply-to regardless of threading
Tests?
* jc/maint-1.6.0-keep-pack (Sat Feb 28 00:37:19 2009 -0800) 6 commits
 + is_kept_pack(): final clean-up
 + Simplify is_kept_pack()
 + Consolidate ignore_packed logic more
 + has_sha1_kept_pack(): take "struct rev_info"
 + has_sha1_pack(): refactor "pretend these packs do not exist"
   interface
 + git-repack: resist stray environment variable
This is in response to Linus's "Really slow 'git gc'" ($gmane/110743)
* en/maint-hash-object (Sat Feb 28 12:56:49 2009 -0700) 1 commit
 + Ensure proper setup of git_dir for git-hash-object
Obvious fix that can also go to 1.6.1.X
* tr/gcov (Thu Feb 19 12:13:42 2009 +0100) 8 commits
 - Test git-patch-id
 - Test rev-list --parents/--children
 - Test log --decorate
 - Test fsck a bit harder
 - Test log --graph
 - Test diff --dirstat functionality
 - Test that diff can read from stdin
 - Support coverage testing with GCC/gcov
* js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
 - tests: fix "export var=val"
 - notes: refuse to edit notes outside refs/notes/
 - t3301: use test_must_fail instead of !
 - t3301: fix confusing quoting in test for valid notes ref
 - notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
 - notes: only clean up message file when editing
 - handle empty notes gracefully
 - git notes show: test empty notes
 - git-notes: fix printing of multi-line notes
 - notes: fix core.notesRef documentation
 - Add an expensive test for git-notes
 - Speed up git notes lookup
 - Add a script to edit/inspect notes
 - Introduce commit notes

Rebased and then kicked back to 'pu' to give the author a chance to rearrange if necessary. I might do some trivial squashing myself.

---------------------------------------------------------------- [On Hold]

* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit
 - receive-pack: default receive.denyDeleteCurrent to refuse
* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit
 - Refuse updating the current branch in a non-bare repository via
   push

These are for 1.7.0, but the messages when they trigger together may need to be rethought.

* jc/commit-assume-also-during-merge (Thu Jan 22 22:21:49 2009 -0800) 3 commits
 - git commit: pathspec without -i/-o implies -i semantics during a
   merge
 - builtin-commit: shorten eye-sore overlong lines
 - Add "partial commit" tests during a conflicted merge

This was only meant as a weatherballoon to help facilitate discussion. Will be discarded.

Nanako Shiraishi· Mar 5, 2009, 10:12 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)

Quoting Junio C Hamano <gitster@pobox.com>:
Show 6 quoted lines
> * jk/sane-relative-time (Tue Feb 24 00:42:16 2009 -0500) 1 commit
>  + never fallback relative times to absolute
>
> I think I sent out a "here is how" patch for something related to
> --date=<format> option that may be related to this topic; I seem to have
> lost it.
Do you mean this one?
	http://article.gmane.org/gmane.comp.version-control.git/112033
-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
Junio C Hamano· Mar 5, 2009, 10:22 UTC · re: Nanako Shiraishi · lore

Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)

Nanako Shiraishi <nanako3@lavabit.com> writes:
Show 12 quoted lines
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> * jk/sane-relative-time (Tue Feb 24 00:42:16 2009 -0500) 1 commit
>>  + never fallback relative times to absolute
>>
>> I think I sent out a "here is how" patch for something related to
>> --date=<format> option that may be related to this topic; I seem to have
>> lost it.
>
> Do you mean this one?
>
> 	http://article.gmane.org/gmane.comp.version-control.git/112033
Yup, that's the one.  Thanks.
Jeff King· Mar 5, 2009, 11:00 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)

On Thu, Mar 05, 2009 at 02:07:26AM -0800, Junio C Hamano wrote:
Show 8 quoted lines
> * mh/cvsimport-tests (Mon Feb 23 06:08:14 2009 +0100) 5 commits
>  - Add a test of "git cvsimport"'s handling of tags and branches
>  - Add some tests of git-cvsimport's handling of vendor branches
>  - Test contents of entire cvsimported "master" tree contents
>  - Use CVS's -f option if available (ignore user's ~/.cvsrc file)
>  - Start a library for cvsimport-related tests
> 
> Tests without fixes are of dubious value.  Any takers?

At the very least, I think the first 3 are nice infrastructure cleanups that will help future tests for cvsimport. So it makes sense to me to apply them to help future testers (otherwise, they would have to know that these patches existed and dig them out of the list).

The final two introduce the new tests. They look fine as far as fitting into the test infrastructure, but I have to admit that I haven't actually looked closely at _what_ they are testing. I assumed since they are adapted from Michael's cvs2svn tests that they are showing real problems that he had faced there. If they are meant to show failings of cvsps-based conversion (which is my understanding from Michael's other messages), then I'm not even sure they _are_ fixable without a total rewrite.

So I don't know whether it makes sense to apply them if we never plan on fixing them. Michael said his goal was to document problems with cvsps-based importing, and I think he has done that in a way that will help anyone who wants to try fixing. We can help people out a little more by carrying the tests in the tree (versus making them pull them from the list); the downside is that it may take the test suite a little longer to run. I don't know how much we care; it might not matter for 2 tests, but I certainly wouldn't want to 30 minutes of testing for something that isn't fixable (and CVS tests tend to be terribly slow).

-Peff
Michael Haggerty· Mar 5, 2009, 15:18 UTC · re: Jeff King · lore

Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)

Jeff King wrote:
Show 21 quoted lines
> On Thu, Mar 05, 2009 at 02:07:26AM -0800, Junio C Hamano wrote:
> 
>> * mh/cvsimport-tests (Mon Feb 23 06:08:14 2009 +0100) 5 commits
>>  - Add a test of "git cvsimport"'s handling of tags and branches
>>  - Add some tests of git-cvsimport's handling of vendor branches
>>  - Test contents of entire cvsimported "master" tree contents
>>  - Use CVS's -f option if available (ignore user's ~/.cvsrc file)
>>  - Start a library for cvsimport-related tests
>>
>> Tests without fixes are of dubious value.  Any takers?
> 
> [...]
> 
> The final two introduce the new tests. They look fine as far as fitting
> into the test infrastructure, but I have to admit that I haven't
> actually looked closely at _what_ they are testing. I assumed since they
> are adapted from Michael's cvs2svn tests that they are showing real
> problems that he had faced there. If they are meant to show failings of
> cvsps-based conversion (which is my understanding from Michael's other
> messages), then I'm not even sure they _are_ fixable without a total
> rewrite.
The test script added by this patch:
  Add some tests of git-cvsimport's handling of vendor branches

indicates a breakage that will occur for any CVS repository that used the CVS "vendor branch" feature by importing a vendor tree more than once. This is a standard-vanilla use of CVS, though probably used in a minority of repositories. In such a case, the master branch of the cvsimported git repository will have different contents than the HEAD branch of the CVS repository. I don't know enough to say whether this is fixable without ditching cvsps.

The test script added by this patch:
  Add a test of "git cvsimport"'s handling of tags and branches

is even more basic. In CVS it is possible, and common, to add some files but not others to a branch or tag, or to add files from multiple source branches to a branch or tag. For some workflows, this is recommended practice in the CVS world. AFAIK cvsps does not attempt to figure out what files were added to a branch but rather assumes that an entire source branch was tagged/branched at a single moment in time. The result of this false assumption is that the contents of the branch/tag as checked out of git are different than those in the same branch/tag in CVS.

The following patch by Heiko Voigt:
* hv/cvsimport-tests (Mon Mar 2 18:59:36 2009 +0100) 1 commit
 - cvsimport: add test illustrating a bug in cvsps

occurs due to out-of-order timestamps in the CVS repo, which can occur whenever CVS *client* clocks are not synchronized.

I have another failing test (patch not yet submitted) that reveals a conversion failure whenever CVS commits are applied to different files in different orders (even if the timestamps are in order). This occurs shockingly often in CVS repositories because commits are not atomic, so commits from two clients can be interleaved. It can also occur if two commits within cvsps's time window coincidentally have the same author and commit message (e.g., a blank commit message). In this case git-cvsimport commits changes *to a single file* in the wrong topological order (e.g., revision 1.3 is overwritten by revision 1.2), also potentially leaving obsolete file contents at HEAD.

In all of these cases *the git content is objectively wrong*. These are not quality-of-conversion quibbles, they are egregious correctness problems that will occur in most nontrivial CVS repositories.

> So I don't know whether it makes sense to apply them if we never plan on
> fixing them. [...]
IMHO there are only two intellectually honest alternatives:
1. Commit the new tests in the hope that somebody will try to fix them,
which probably requires ditching cvsps and starting almost from scratch.
 Until they are fixed add a disclaimer, in big red letters, to the
git-cvsimport documentation, saying that it *should not be trusted* to
make accurate conversions (though it might be useful in very restricted
scenarios requiring incremental synchronization with a CVS repo).  In
this case the tests should be retained as documentation, though perhaps
they should not be run unless the user turns on a particular flag.
2. Remove the git-cvsimport command altogether.

The status quo is untenable. git-cvsimport is broken in ways that casual users might easily overlook. Their source tree might be altered, possibly on HEAD but even more likely on branches and historical tags. By the time they notice, sometime in the future, that their repository is corrupt, it will be too late to fix because git development has taken place on top of the faulty converted repository.

Michael
Jeff King· Mar 5, 2009, 16:28 UTC · re: Michael Haggerty · lore

Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)

On Thu, Mar 05, 2009 at 04:18:46PM +0100, Michael Haggerty wrote:
> In all of these cases *the git content is objectively wrong*.  These are
> not quality-of-conversion quibbles, they are egregious correctness
> problems that will occur in most nontrivial CVS repositories.

Thanks for the detailed descriptions. I don't think anyone is denying that the results are objectively wrong; it is clear that cvsimport doesn't handle complex cases well.

Show 10 quoted lines
> IMHO there are only two intellectually honest alternatives:
> 
> 1. Commit the new tests in the hope that somebody will try to fix them,
> which probably requires ditching cvsps and starting almost from scratch.
>  Until they are fixed add a disclaimer, in big red letters, to the
> git-cvsimport documentation, saying that it *should not be trusted* to
> make accurate conversions (though it might be useful in very restricted
> scenarios requiring incremental synchronization with a CVS repo).  In
> this case the tests should be retained as documentation, though perhaps
> they should not be run unless the user turns on a particular flag.

I think committing the tests and putting a big warning onto cvsimport are two separate things. I don't want to hide the fact that cvsimport sucks, and I don't think anyone does. But I also don't want to bog down the test suite with useless cruft that nobody is actually going to look at.

I think your suggestion of disabling the tests unless flagged is reasonable. The tests themselves don't take up much space in the repository, it's only running them that is painful.

As far as marking cvsimport with a disclaimer, I don't have an objection to warning people in the documentation. It seems like most people who come to the list with a cvsimport problem end up getting the advice to try something else, and then they end up happy. Putting a not-inflammatory disclaimer into the documentation to check results and to consider some other options would save the list a little work.

> 2. Remove the git-cvsimport command altogether.

I don't think this is a good idea. It still has two uses which make it better than nothing:

  1. It's the only (AFAIK) importer that is incremental. When you are
     tracking relatively simple development on an existing CVS repo,
     it is the only choice. Taking that choice away seems
     counterproductive.
  2. It _does_ work on relatively mundane cases, and there _are_ mundane
     CVS repositories. Yes, other tools can also handle these cases, but
     using the bundled cvsimport is much easier using an intermediate
     svn.

I am less sure of (2) above, because naive users might not _know_ that they're screwing up their repository. So safety would dictate spending the extra effort (which is the point you were making, I think).

But certainly cvsimport should hang around for (1), even it is with a disclaimer.

For how long, I don't know. It seems like most people are putting their CVS repos to rest at this point, moving at least to SVN. I know there will be people hanging on to CVS for at least a decade, but I'm not sure at what point we say "there are not enough of you to care; go use a less convenient one-time tool". cvsimport is already suffering from bit-rot as people who like git enough to work on it converted their repos years ago.

-Peff
Johannes Schindelin· Mar 5, 2009, 11:04 UTC · re: Junio C Hamano · lore

notes, was Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)

Hi,
On Thu, 5 Mar 2009, Junio C Hamano wrote:
Show 18 quoted lines
> * js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
>  - tests: fix "export var=val"
>  - notes: refuse to edit notes outside refs/notes/
>  - t3301: use test_must_fail instead of !
>  - t3301: fix confusing quoting in test for valid notes ref
>  - notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
>  - notes: only clean up message file when editing
>  - handle empty notes gracefully
>  - git notes show: test empty notes
>  - git-notes: fix printing of multi-line notes
>  - notes: fix core.notesRef documentation
>  - Add an expensive test for git-notes
>  - Speed up git notes lookup
>  - Add a script to edit/inspect notes
>  - Introduce commit notes
> 
> Rebased and then kicked back to 'pu' to give the author a chance to
> rearrange if necessary.  I might do some trivial squashing myself.
Will do.

Thanks, Dscho

Jonas Fonseca· Mar 5, 2009, 12:40 UTC · re: Johannes Schindelin · lore

Re: notes, was Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)

On Thu, Mar 5, 2009 at 12:04, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 8 quoted lines
> On Thu, 5 Mar 2009, Junio C Hamano wrote:
>
>> * js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
>>
>> Rebased and then kicked back to 'pu' to give the author a chance to
>> rearrange if necessary.  I might do some trivial squashing myself.
>
> Will do.

Although laziness should not be rewarded, this might be something that you could squash in as well.

--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -43,4 +43,4 @@ Documentation by Johannes Schindelin

 GIT
 ---
-Part of the gitlink:git[7] suite
+Part of the linkgit:git[7] suite
-- 
Jonas Fonseca
Junio C Hamano· Mar 5, 2009, 19:23 UTC · re: Jonas Fonseca · lore

Re: notes, was Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)

Jonas Fonseca <jonas.fonseca@gmail.com> writes:
Show 13 quoted lines
> On Thu, Mar 5, 2009 at 12:04, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> On Thu, 5 Mar 2009, Junio C Hamano wrote:
>>
>>> * js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
>>>
>>> Rebased and then kicked back to 'pu' to give the author a chance to
>>> rearrange if necessary.  I might do some trivial squashing myself.
>>
>> Will do.
>
> Although laziness should not be rewarded, this might be something that
> you could squash in as well.

Whose laziness are you accusing? Me giving Dscho a chance to make trivial clean-up of his own series instead of doing it myself???

In any case, I won't be squashing "oops - fixup" patch(es) in the original series to the early parts of the sequence that introduced the "oops" myself, as it would likely end up Dscho and I stepping on each other's paws. I won't be squashing this patch in myself, either.

Show 8 quoted lines
> --- a/Documentation/git-notes.txt
> +++ b/Documentation/git-notes.txt
> @@ -43,4 +43,4 @@ Documentation by Johannes Schindelin
>
>  GIT
>  ---
> -Part of the gitlink:git[7] suite
> +Part of the linkgit:git[7] suite
Jonas Fonseca· Mar 5, 2009, 20:17 UTC · re: Junio C Hamano · lore

Re: notes, was Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)

On Thu, Mar 5, 2009 at 20:23, Junio C Hamano <gitster@pobox.com> wrote:
Show 11 quoted lines
> Jonas Fonseca <jonas.fonseca@gmail.com> writes:
>> On Thu, Mar 5, 2009 at 12:04, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>> On Thu, 5 Mar 2009, Junio C Hamano wrote:
>>>> * js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
>>
>> Although laziness should not be rewarded, this might be something that
>> you could squash in as well.
>
> Whose laziness are you accusing?  Me giving Dscho a chance to make trivial
> clean-up of his own series instead of doing it myself???

I was referring to my own laziness of not sending a proper patch. Sorry for the confusion.

-- 
Jonas Fonseca

← back to recent threads