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

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

[Junio C Hamano]

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.

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

[Nanako Shiraishi]

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

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

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

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> 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.

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

[Jeff King]

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?

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

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

[Johannes Schindelin]

Hi,

On Thu, 5 Mar 2009, Junio C Hamano wrote:

> * 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

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

[Jonas Fonseca]

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.

--- 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

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

[Michael Haggerty]

Jeff King wrote:
> 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

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

[Jeff King]

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.

> 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

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

[Junio C Hamano]

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
>>>
>>> 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.

> --- 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

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

[Jonas Fonseca]

On Thu, Mar 5, 2009 at 20:23, Junio C Hamano <gitster@pobox.com> wrote:
> 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