All of lore.kernel.org
 help / color / mirror / Atom feed
* What's cooking in git.git (Jan 2013, #08; Tue, 22)
@ 2013-01-22 22:44 Junio C Hamano
  2013-01-22 23:45 ` John Keeping
  0 siblings, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2013-01-22 22:44 UTC (permalink / raw)
  To: git

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

 Update tcsh command line completion so that an unwanted space is
 not added to a single directory name.


* mz/reset-misc (2013-01-16) 20 commits
  (merged to 'next' on 2013-01-16 at 937bc20)
 + reset: update documentation to require only tree-ish with paths
  (merged to 'next' on 2013-01-15 at a93b394)
 + reset [--mixed]: use diff-based reset whether or not pathspec was given
 + reset: allow reset on unborn branch
 + reset $sha1 $pathspec: require $sha1 only to be treeish
 + reset.c: inline update_index_refresh()
 + reset.c: finish entire cmd_reset() whether or not pathspec is given
 + reset [--mixed]: only write index file once
 + reset.c: move lock, write and commit out of update_index_refresh()
 + reset.c: move update_index_refresh() call out of read_from_tree()
 + reset.c: replace switch by if-else
 + reset: avoid redundant error message
 + reset --keep: only write index file once
 + reset.c: share call to die_if_unmerged_cache()
 + reset.c: extract function for updating {ORIG_,}HEAD
 + reset.c: remove unnecessary variable 'i'
 + reset.c: extract function for parsing arguments
 + reset: don't allow "git reset -- $pathspec" in bare repo
 + reset.c: pass pathspec around instead of (prefix, argv) pair
 + reset $pathspec: exit with code 0 if successful
 + reset $pathspec: no need to discard index

 Various 'reset' optimizations and clean-ups, followed by a change
 to allow "git reset" to work even on an unborn branch.


* nd/attr-debug-fix (2013-01-15) 1 commit
  (merged to 'next' on 2013-01-15 at 8460acf)
 + attr: make it build with DEBUG_ATTR again

 Fix debugging support that was broken in earlier change.


* nd/clone-no-separate-git-dir-with-bare (2013-01-10) 1 commit
  (merged to 'next' on 2013-01-15 at 64f441a)
 + clone: forbid --bare --separate-git-dir <dir>

 Forbid a useless combination of options to "git clone".


* nd/fix-directory-attrs-off-by-one (2013-01-16) 2 commits
  (merged to 'next' on 2013-01-16 at bd63e61)
 + attr: avoid calling find_basename() twice per path
  (merged to 'next' on 2013-01-15 at e0a0129)
 + attr: fix off-by-one directory component length calculation

 Fix performance regression introduced by an earlier change to let
 attributes apply to directories.


* nd/fix-perf-parameters-in-tests (2013-01-15) 1 commit
  (merged to 'next' on 2013-01-15 at fedbdb9)
 + test-lib.sh: unfilter GIT_PERF_*

 Allow GIT_PERF_* environment variables to be passed through the
 test framework.


* pe/doc-email-env-is-trumped-by-config (2013-01-10) 1 commit
  (merged to 'next' on 2013-01-14 at 6b4d555)
 + git-commit-tree(1): correct description of defaults

 In the precedence order, the environment variable $EMAIL comes
 between the built-in default (i.e. taking value by asking the
 system's gethostname() etc.) and the user.email configuration
 variable; the documentation implied that it is stronger than the
 configuration like $GIT_COMMITTER_EMAIL is, which is wrong.


* ph/rebase-preserve-all-merges (2013-01-14) 1 commit
  (merged to 'next' on 2013-01-15 at 3a67878)
 + rebase --preserve-merges: keep all merge commits including empty ones

 An earlier change to add --keep-empty option broke "git rebase
 --preserve-merges" and lost merge commits that end up being the
 same as its parent.


* pw/p4-branch-fixes (2013-01-15) 14 commits
  (merged to 'next' on 2013-01-15 at 1ee379e)
 + git p4: fix submit when no master branch
 + git p4 test: keep P4CLIENT changes inside subshells
 + git p4: fix sync --branch when no master branch
 + git p4: fail gracefully on sync with no master branch
 + git p4: rearrange self.initialParent use
 + git p4: allow short ref names to --branch
 + git p4 doc: fix branch detection example
 + git p4: clone --branch should checkout master
 + git p4: verify expected refs in clone --bare test
 + git p4: create p4/HEAD on initial clone
 + git p4: inline listExistingP4GitBranches
 + git p4: add comments to p4BranchesInGit
 + git p4: rearrange and simplify hasOrigin handling
 + git p4: test sync/clone --branch behavior

 Fix "git p4" around branch handling.


* rs/pretty-use-prefixcmp (2013-01-14) 1 commit
  (merged to 'next' on 2013-01-15 at d76452d)
 + pretty: use prefixcmp instead of memcmp on NUL-terminated strings


* rt/commit-cleanup-config (2013-01-10) 1 commit
  (merged to 'next' on 2013-01-15 at c4742ae)
 + commit: make default of "cleanup" option configurable

 Add a configuration variable to set default clean-up mode other
 than "strip".


* ss/help-htmlpath-config-doc (2013-01-15) 1 commit
  (merged to 'next' on 2013-01-17 at 99bfae2)
 + config.txt: Document help.htmlpath config parameter

 Add missing doc.


* zk/clean-report-failure (2013-01-14) 1 commit
  (merged to 'next' on 2013-01-15 at 5b31614)
 + git-clean: Display more accurate delete messages

 "git clean" states what it is going to remove and then goes on to
 remove it, but sometimes it only discovers things that cannot be
 removed after recursing into a directory, which makes the output
 confusing and even wrong.

--------------------------------------------------
[Stalled]

* mp/complete-paths (2013-01-11) 1 commit
 - git-completion.bash: add support for path completion

 The completion script used to let the default completer to suggest
 pathnames, which gave too many irrelevant choices (e.g. "git add"
 would not want to add an unmodified path).  Teach it to use a more
 git-aware logic to enumerate only relevant ones.

 Waiting for area-experts' help and review.


* jl/submodule-deinit (2012-12-04) 1 commit
 - submodule: add 'deinit' command

 There was no Porcelain way to say "I no longer am interested in
 this submodule", once you express your interest in a submodule with
 "submodule init".  "submodule deinit" is the way to do so.

 Expecting a reroll.
 $gmane/212884


* jk/lua-hackery (2012-10-07) 6 commits
 - pretty: fix up one-off format_commit_message calls
 - Minimum compilation fixup
 - Makefile: make "lua" a bit more configurable
 - add a "lua" pretty format
 - add basic lua infrastructure
 - pretty: make some commit-parsing helpers more public

 Interesting exercise. When we do this for real, we probably would want
 to wrap a commit to make it more like an "object" with methods like
 "parents", etc.


* rc/maint-complete-git-p4 (2012-09-24) 1 commit
 - Teach git-completion about git p4

 Comment from Pete will need to be addressed ($gmane/206172).


* jc/maint-name-rev (2012-09-17) 7 commits
 - describe --contains: use "name-rev --algorithm=weight"
 - name-rev --algorithm=weight: tests and documentation
 - name-rev --algorithm=weight: cache the computed weight in notes
 - name-rev --algorithm=weight: trivial optimization
 - name-rev: --algorithm option
 - name_rev: clarify the logic to assign a new tip-name to a commit
 - name-rev: lose unnecessary typedef

 "git name-rev" names the given revision based on a ref that can be
 reached in the smallest number of steps from the rev, but that is
 not useful when the caller wants to know which tag is the oldest one
 that contains the rev.  This teaches a new mode to the command that
 uses the oldest ref among those which contain the rev.

 I am not sure if this is worth it; for one thing, even with the help
 from notes-cache, it seems to make the "describe --contains" even
 slower. Also the command will be unusably slow for a user who does
 not have a write access (hence unable to create or update the
 notes-cache).

 Stalled mostly due to lack of responses.


* jc/xprm-generation (2012-09-14) 1 commit
 - test-generation: compute generation numbers and clock skews

 A toy to analyze how bad the clock skews are in histories of real
 world projects.

 Stalled mostly due to lack of responses.


* jc/add-delete-default (2012-08-13) 1 commit
 - git add: notice removal of tracked paths by default

 "git add dir/" updated modified files and added new files, but does
 not notice removed files, which may be "Huh?" to some users.  They
 can of course use "git add -A dir/", but why should they?

 Resurrected from graveyard, as I thought it was a worthwhile thing
 to do in the longer term.

 Stalled mostly due to lack of responses.


* mb/remote-default-nn-origin (2012-07-11) 6 commits
 - Teach get_default_remote to respect remote.default.
 - Test that plain "git fetch" uses remote.default when on a detached HEAD.
 - Teach clone to set remote.default.
 - Teach "git remote" about remote.default.
 - Teach remote.c about the remote.default configuration setting.
 - Rename remote.c's default_remote_name static variables.

 When the user does not specify what remote to interact with, we
 often attempt to use 'origin'.  This can now be customized via a
 configuration variable.

 Expecting a reroll.
 $gmane/210151

 "The first remote becomes the default" bit is better done as a
 separate step.

--------------------------------------------------
[Cooking]

* mh/imap-send-shrinkage (2013-01-15) 14 commits
  (merged to 'next' on 2013-01-18 at 1b7c5ba)
 + imap-send.c: simplify logic in lf_to_crlf()
 + imap-send.c: fold struct store into struct imap_store
 + imap-send.c: remove unused field imap_store::uidvalidity
 + imap-send.c: use struct imap_store instead of struct store
 + imap-send.c: remove unused field imap_store::trashnc
 + imap-send.c: remove namespace fields from struct imap
 + imap-send.c: remove struct imap argument to parse_imap_list_l()
 + imap-send.c: inline parse_imap_list() in parse_list()
 + imap-send.c: remove some unused fields from struct store
 + imap-send.c: remove struct message
 + imap-send.c: remove struct store_conf
 + iamp-send.c: remove unused struct imap_store_conf
 + imap-send.c: remove struct msg_data
 + imap-send.c: remove msg_data::flags, which was always zero

 Remove a lot of unused code from "git imap-send".

 Will merge to 'master'.


* cr/push-force-tag-update (2013-01-21) 4 commits
 - push: further simplify the logic to assign rejection status
 - push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
 - push: further clean up fields of "struct ref"
  (merged to 'next' on 2013-01-18 at c9091d5)
 + push: fix "refs/tags/ hierarchy cannot be updated without --force"

 Regression fix (the bottom one), and error/advice message
 improvements (the rest).

 Will merge to 'master' the bottom one soonish.
 The remainder can cook in 'next' like any other topic.


* jk/suppress-clang-warning (2013-01-16) 1 commit
  (merged to 'next' on 2013-01-18 at 7c0bda7)
 + fix clang -Wunused-value warnings for error functions

 Will merge to 'master'.


* rs/clarify-entry-cmp-sslice (2013-01-16) 1 commit
  (merged to 'next' on 2013-01-18 at d584dc6)
 + refs: use strncmp() instead of strlen() and memcmp()

 Will merge to 'master'.


* ch/add-auto-submitted-in-sample-post-receive-email (2013-01-17) 1 commit
  (merged to 'next' on 2013-01-18 at e3205db)
 + Add Auto-Submitted header to post-receive-email

 Will merge to 'master'.


* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit
 - simplify-merges: drop merge from irrelevant side branch

 The --simplify-merges logic did not cull irrelevant parents from a
 merge that is otherwise not interesting with respect to the paths
 we are following.

 As this touches a fairly core part of the revision traversal
 infrastructure, it is appreciated to have an extra set of eyes for
 sanity check.

 Waiting for comments.


* jk/remote-helpers-in-python-3 (2013-01-20) 8 commits
 - git-remote-testpy: call print as a function
 - git-remote-testpy: don't do unbuffered text I/O
 - git-remote-testpy: hash bytes explicitly
 - svn-fe: allow svnrdump_sim.py to run with Python 3
 - git_remote_helpers: use 2to3 if building with Python 3
 - git_remote_helpers: force rebuild if python version changes
 - git_remote_helpers: fix input when running under Python 3
 - git_remote_helpers: allow building with Python 3

 Prepare remote-helper test written in Python to be run with Python3.

 Will merge to 'next'.


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


* as/pre-push-hook (2013-01-18) 3 commits
  (merged to 'next' on 2013-01-18 at 37fc4e8)
 + Add sample pre-push hook script
 + push: Add support for pre-push hooks
 + hooks: Add function to check if a hook exists

 Add an extra hook so that "git push" that is run without making
 sure what is being pushed is sane can be checked and rejected (as
 opposed to the user deciding not pushing).

 Will merge to 'master'.


* dl/am-hg-locale (2013-01-18) 1 commit
 - am: invoke perl's strftime in C locale

 Datestamp recorded in "Hg" format patch was reformatted incorrectly
 to an e-mail looking date using locale dependant strftime, causing
 patch application to fail.

 Will merge to 'next'.


* jk/config-parsing-cleanup (2013-01-14) 7 commits
 - [DONTMERGE] reroll coming
 - submodule: simplify memory handling in config parsing
 - submodule: use match_config_key when parsing config
 - userdiff: drop parse_driver function
 - convert some config callbacks to match_config_key
 - archive-tar: use match_config_key when parsing config
 - config: add helper function for parsing key names

 Expecting a reroll.


* mp/diff-algo-config (2013-01-16) 3 commits
 - diff: Introduce --diff-algorithm command line option
 - config: Introduce diff.algorithm variable
 - git-completion.bash: Autocomplete --minimal and --histogram for git-diff

 Add diff.algorithm configuration so that the user does not type
 "diff --histogram".

 Looking better; may want tests to protect it from future breakages,
 but otherwise it looks ready for 'next'.

 Waiting for a follow-up to add tests.


* rs/archive-tar-config-parsing-fix (2013-01-14) 1 commit
 - archive-tar: fix sanity check in config parsing

 Configuration parsing for tar.* configuration variables were
 broken; Peff's config parsing clean-up topic will address the same
 breakage, so this may be superseded by that other topic.

 Waiting for the other topic to make this unneeded.


* jc/custom-comment-char (2013-01-16) 1 commit
 - Allow custom "comment char"

 An illustration to show codepaths that need to be touched to change
 the hint lines in the edited text to begin with something other
 than '#'.

 This is half my work and half by Ralf Thielow.  There may still be
 leftover '#' lurking around, though.  My "git grep" says C code
 should be already fine, but git-rebase--interactive.sh could be
 converted (it should not matter, as the file is not really a
 free-form text).

 I don't know how useful this will be in real life, though.

 Will merge to 'next'.


* nd/fetch-depth-is-broken (2013-01-11) 3 commits
  (merged to 'next' on 2013-01-15 at 70a5ca7)
 + fetch: elaborate --depth action
 + upload-pack: fix off-by-one depth calculation in shallow clone
 + fetch: add --unshallow for turning shallow repo into complete one

 "git fetch --depth" was broken in at least three ways.  The
 resulting history was deeper than specified by one commit, it was
 unclear how to wipe the shallowness of the repository with the
 command, and documentation was misleading.

 Will cook in 'next'.


* jc/no-git-config-in-clone (2013-01-11) 1 commit
  (merged to 'next' on 2013-01-15 at feeffe1)
 + clone: do not export and unexport GIT_CONFIG

 We stopped paying attention to $GIT_CONFIG environment that points
 at a single configuration file from any command other than "git config"
 quite a while ago, but "git clone" internally set, exported, and
 then unexported the variable during its operation unnecessarily.

 Will cook in 'next'.


* dg/subtree-fixes (2013-01-08) 7 commits
 - contrib/subtree: mkdir the manual directory if needed
 - contrib/subtree: honor $(DESTDIR)
 - contrib/subtree: fix synopsis and command help
 - contrib/subtree: better error handling for "add"
 - contrib/subtree: add --unannotate option
 - contrib/subtree: use %B for split Subject/Body
 - t7900: remove test number comments

 contrib/subtree updates; there are a few more from T. Zheng that
 were posted separately, with an overlap.

 Expecting a reroll.


* jc/push-2.0-default-to-simple (2013-01-16) 14 commits
  (merged to 'next' on 2013-01-16 at 23f5df2)
 + t5570: do not assume the "matching" push is the default
 + t5551: do not assume the "matching" push is the default
 + t5550: do not assume the "matching" push is the default
  (merged to 'next' on 2013-01-09 at 74c3498)
 + doc: push.default is no longer "matching"
 + push: switch default from "matching" to "simple"
 + t9401: do not assume the "matching" push is the default
 + t9400: do not assume the "matching" push is the default
 + t7406: do not assume the "matching" push is the default
 + t5531: do not assume the "matching" push is the default
 + t5519: do not assume the "matching" push is the default
 + t5517: do not assume the "matching" push is the default
 + t5516: do not assume the "matching" push is the default
 + t5505: do not assume the "matching" push is the default
 + t5404: do not assume the "matching" push is the default

 Will cook in 'next' until Git 2.0 ;-).


* nd/parse-pathspec (2013-01-11) 20 commits
 . Convert more init_pathspec() to parse_pathspec()
 . Convert add_files_to_cache to take struct pathspec
 . Convert {read,fill}_directory to take struct pathspec
 . Convert refresh_index to take struct pathspec
 . Convert report_path_error to take struct pathspec
 . checkout: convert read_tree_some to take struct pathspec
 . Convert unmerge_cache to take struct pathspec
 . Convert read_cache_preload() to take struct pathspec
 . add: convert to use parse_pathspec
 . archive: convert to use parse_pathspec
 . ls-files: convert to use parse_pathspec
 . rm: convert to use parse_pathspec
 . checkout: convert to use parse_pathspec
 . rerere: convert to use parse_pathspec
 . status: convert to use parse_pathspec
 . commit: convert to use parse_pathspec
 . clean: convert to use parse_pathspec
 . Export parse_pathspec() and convert some get_pathspec() calls
 . Add parse_pathspec() that converts cmdline args to struct pathspec
 . pathspec: save the non-wildcard length part

 Uses the parsed pathspec structure in more places where we used to
 use the raw "array of strings" pathspec.

 Ejected from 'pu' for now; will take a look at the rerolled one
 later ($gmane/213340).


* jc/doc-maintainer (2013-01-03) 2 commits
  (merged to 'next' on 2013-01-11 at f35d582)
 + howto/maintain: mark titles for asciidoc
 + Documentation: update "howto maintain git"

 Describe tools for automation that were invented since this
 document was originally written.


* mo/cvs-server-updates (2012-12-09) 18 commits
  (merged to 'next' on 2013-01-08 at 75e2d11)
 + t9402: Use TABs for indentation
 + t9402: Rename check.cvsCount and check.list
 + t9402: Simplify git ls-tree
 + t9402: Add missing &&; Code style
 + t9402: No space after IO-redirection
 + t9402: Dont use test_must_fail cvs
 + t9402: improve check_end_tree() and check_end_full_tree()
 + t9402: sed -i is not portable
 + cvsserver Documentation: new cvs ... -r support
 + cvsserver: add t9402 to test branch and tag refs
 + cvsserver: support -r and sticky tags for most operations
 + cvsserver: Add version awareness to argsfromdir
 + cvsserver: generalize getmeta() to recognize commit refs
 + cvsserver: implement req_Sticky and related utilities
 + cvsserver: add misc commit lookup, file meta data, and file listing functions
 + cvsserver: define a tag name character escape mechanism
 + cvsserver: cleanup extra slashes in filename arguments
 + cvsserver: factor out git-log parsing logic

 Various git-cvsserver updates.

 Will merge to 'master'.


* as/check-ignore (2013-01-16) 13 commits
  (merged to 'next' on 2013-01-18 at ef45aff)
 + clean.c, ls-files.c: respect encapsulation of exclude_list_groups
  (merged to 'next' on 2013-01-14 at 9df2afc)
 + t0008: avoid brace expansion
 + add git-check-ignore sub-command
 + setup.c: document get_pathspec()
 + add.c: extract new die_if_path_beyond_symlink() for reuse
 + add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse
 + pathspec.c: rename newly public functions for clarity
 + add.c: move pathspec matchers into new pathspec.c for reuse
 + add.c: remove unused argument from validate_pathspec()
 + dir.c: improve docs for match_pathspec() and match_pathspec_depth()
 + dir.c: provide clear_directory() for reclaiming dir_struct memory
 + dir.c: keep track of where patterns came from
 + dir.c: use a single struct exclude_list per source of excludes

 Add a new command "git check-ignore" for debugging .gitignore
 files.

 The variable names may want to get cleaned up but that can be done
 in-tree.

 Will merge to 'master'.


* nd/retire-fnmatch (2013-01-01) 7 commits
  (merged to 'next' on 2013-01-07 at ab31f9b)
 + Makefile: add USE_WILDMATCH to use wildmatch as fnmatch
 + wildmatch: advance faster in <asterisk> + <literal> patterns
 + wildmatch: make a special case for "*/" with FNM_PATHNAME
 + test-wildmatch: add "perf" command to compare wildmatch and fnmatch
 + wildmatch: support "no FNM_PATHNAME" mode
 + wildmatch: make dowild() take arbitrary flags
 + wildmatch: rename constants and update prototype

 Originally merged to 'next' on 2013-01-04

 Replace our use of fnmatch(3) with a more feature-rich wildmatch.
 A handful patches at the bottom have been moved to nd/wildmatch to
 graduate as part of that branch, before this series solidifies.

 Will merge to 'master'.


* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
 - Highlight the link target line in Gitweb using CSS

 Expecting a reroll.
 $gmane/211935


* bc/append-signed-off-by (2013-01-21) 10 commits
 - Unify appending signoff in format-patch, commit and sequencer
 - format-patch: update append_signoff prototype
 - t4014: more tests about appending s-o-b lines
 - sequencer.c: teach append_signoff to avoid adding a duplicate newline
 - sequencer.c: teach append_signoff how to detect duplicate s-o-b
 - sequencer.c: always separate "(cherry picked from" from commit body
 - sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
 - t/t3511: add some tests of 'cherry-pick -s' functionality
 - t/test-lib-functions.sh: allow to specify the tag name to test_commit
 - sequencer.c: remove broken support for rfc2822 continuation in footer

 Rerolled.

 Seems that we will see another round.

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

* er/replace-cvsimport (2013-01-12) 7 commits
 . t/lib-cvs: cvsimport no longer works without Python >= 2.7
 . t9605: test for cvsps commit ordering bug
 . t9604: fixup for new cvsimport
 . t9600: fixup for new cvsimport
 . t/lib-cvs.sh: allow cvsps version 3.x.
 . t/t960[123]: remove leftover scripts
 . cvsimport: rewrite to use cvsps 3.x to fix major bugs

 Rerolled as jc/cvsimport-upgrade.


* jc/valgrind-memcmp-bsearch (2013-01-14) 1 commit
 . ignore memcmp() overreading in bsearch() callback

 Squelch false positive in valgrind tests; made unnecessary by
 rewriting the callsite that confuses the tool.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
  2013-01-22 22:44 What's cooking in git.git (Jan 2013, #08; Tue, 22) Junio C Hamano
@ 2013-01-22 23:45 ` John Keeping
  2013-01-23  0:11   ` Junio C Hamano
  0 siblings, 1 reply; 15+ messages in thread
From: John Keeping @ 2013-01-22 23:45 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
  2013-01-22 23:45 ` John Keeping
@ 2013-01-23  0:11   ` Junio C Hamano
  2013-01-23  9:28     ` John Keeping
  0 siblings, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2013-01-23  0:11 UTC (permalink / raw)
  To: John Keeping; +Cc: git, Eric S. Raymond, Chris Rorvick

John Keeping <john@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?

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
  2013-01-23  0:11   ` Junio C Hamano
@ 2013-01-23  9:28     ` John Keeping
  2013-01-23 13:26       ` Chris Rorvick
  2013-01-23 17:13       ` Junio C Hamano
  0 siblings, 2 replies; 15+ messages in thread
From: John Keeping @ 2013-01-23  9:28 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Eric S. Raymond, Chris Rorvick

On Tue, Jan 22, 2013 at 04:11:59PM -0800, Junio C Hamano wrote:
> John Keeping <john@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

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
  2013-01-23  9:28     ` John Keeping
@ 2013-01-23 13:26       ` Chris Rorvick
  2013-01-23 13:55         ` John Keeping
  2013-01-23 17:13       ` Junio C Hamano
  1 sibling, 1 reply; 15+ messages in thread
From: Chris Rorvick @ 2013-01-23 13:26 UTC (permalink / raw)
  To: John Keeping; +Cc: Junio C Hamano, git, Eric S. Raymond

On Wed, Jan 23, 2013 at 3:28 AM, John Keeping <john@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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
  2013-01-23 13:26       ` Chris Rorvick
@ 2013-01-23 13:55         ` John Keeping
  0 siblings, 0 replies; 15+ messages in thread
From: John Keeping @ 2013-01-23 13:55 UTC (permalink / raw)
  To: Chris Rorvick; +Cc: Junio C Hamano, git, Eric S. Raymond

On Wed, Jan 23, 2013 at 07:26:24AM -0600, Chris Rorvick wrote:
> On Wed, Jan 23, 2013 at 3:28 AM, John Keeping <john@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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
  2013-01-23  9:28     ` John Keeping
  2013-01-23 13:26       ` Chris Rorvick
@ 2013-01-23 17:13       ` Junio C Hamano
  2013-01-23 21:12         ` John Keeping
  1 sibling, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2013-01-23 17:13 UTC (permalink / raw)
  To: John Keeping; +Cc: git, Eric S. Raymond, Chris Rorvick

John Keeping <john@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?

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
  2013-01-23 17:13       ` Junio C Hamano
@ 2013-01-23 21:12         ` John Keeping
  2013-01-24  5:04           ` Junio C Hamano
  2013-01-25  4:55           ` What's cooking in git.git (Jan 2013, #08; Tue, 22) Chris Rorvick
  0 siblings, 2 replies; 15+ messages in thread
From: John Keeping @ 2013-01-23 21:12 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Eric S. Raymond, Chris Rorvick

On Wed, Jan 23, 2013 at 09:13:27AM -0800, Junio C Hamano wrote:
> John Keeping <john@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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
  2013-01-23 21:12         ` John Keeping
@ 2013-01-24  5:04           ` Junio C Hamano
  2013-01-24 19:18             ` [PATCH] git-cvsimport.txt: cvsps-2 is deprecated John Keeping
  2013-01-25  4:55           ` What's cooking in git.git (Jan 2013, #08; Tue, 22) Chris Rorvick
  1 sibling, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2013-01-24  5:04 UTC (permalink / raw)
  To: John Keeping; +Cc: git, Eric S. Raymond, Chris Rorvick

John Keeping <john@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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH] git-cvsimport.txt: cvsps-2 is deprecated
  2013-01-24  5:04           ` Junio C Hamano
@ 2013-01-24 19:18             ` John Keeping
  2013-01-24 20:04               ` Junio C Hamano
  0 siblings, 1 reply; 15+ messages in thread
From: John Keeping @ 2013-01-24 19:18 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Eric S. Raymond, Chris Rorvick

git-cvsimport relies on version 2 of cvsps and does not work with the
new version 3.  Since cvsps 3.x does not currently work as well as
version 2 for incremental import, document this fact.

Specifically, there is no way to make new git-cvsimport that supports
cvsps 3.x and have a seamless transition for existing users since cvsps
3.x needs a time from which to continue importing and git-cvsimport does
not save the time of the last import or import into a specific namespace
so there is no safe way to calculate the time of the last import.

Signed-off-by: John Keeping <john@keeping.me.uk>
---
On Wed, Jan 23, 2013 at 09:04:12PM -0800, Junio C Hamano wrote:
> Care to roll a proper patch with a log message?  I'll discard the
> topic for now and replace it with your documentation update.

Here it is.

 Documentation/git-cvsimport.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 9d5353e..f059ea9 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -18,6 +18,12 @@ 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
+link:http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or
+link:https://github.com/BartMassey/parsecvs[parsecvs].
+
 Imports a CVS repository into git. It will either create a new
 repository, or incrementally import into an existing one.
 
-- 
1.8.1

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH] git-cvsimport.txt: cvsps-2 is deprecated
  2013-01-24 19:18             ` [PATCH] git-cvsimport.txt: cvsps-2 is deprecated John Keeping
@ 2013-01-24 20:04               ` Junio C Hamano
  2013-01-24 20:13                 ` John Keeping
  0 siblings, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2013-01-24 20:04 UTC (permalink / raw)
  To: John Keeping; +Cc: git, Eric S. Raymond, Chris Rorvick

John Keeping <john@keeping.me.uk> writes:

> git-cvsimport relies on version 2 of cvsps and does not work with the
> new version 3.  Since cvsps 3.x does not currently work as well as
> version 2 for incremental import, document this fact.
>
> Specifically, there is no way to make new git-cvsimport that supports
> cvsps 3.x and have a seamless transition for existing users since cvsps
> 3.x needs a time from which to continue importing and git-cvsimport does
> not save the time of the last import or import into a specific namespace
> so there is no safe way to calculate the time of the last import.

Isn't the whole "and git-cvsimport does not save the time..."  part
something that can be fixed in the new cvsimport that reads the
output from cvsps3?

To me, it sounds more like

    cvsps2 + cvsimport has an unfixable bugs and there have been an
    effort to rewrite cvsps2 from scratch.  The resulting cvsp3
    currently is unusable with cvsimport, especially when importing
    the history incrementally, and it isn't expected that it will
    ever be usable with cvsimport again.

    There are other tools that analyse the original history better
    and emits more correct output when used to convert the whole
    history, and hopefully cvsps3 + fast-import would become one of
    them.  Suggest users to use them instead of cvsimport when they
    are not doing an incremental import.

By the way, do we want to make any recommendation to the distro
folks which cvsps they should ship?  It appears that not shipping
cvsps2 would be a major regression if cvsps3 does not plan to
support incrementals, so shipping both might be the safest way for
them to support their users with different needs.

Thanks.  I think the patch text itself is good.

> Signed-off-by: John Keeping <john@keeping.me.uk>
> ---
> On Wed, Jan 23, 2013 at 09:04:12PM -0800, Junio C Hamano wrote:
>> Care to roll a proper patch with a log message?  I'll discard the
>> topic for now and replace it with your documentation update.
>
> Here it is.
>
>  Documentation/git-cvsimport.txt | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
> index 9d5353e..f059ea9 100644
> --- a/Documentation/git-cvsimport.txt
> +++ b/Documentation/git-cvsimport.txt
> @@ -18,6 +18,12 @@ 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
> +link:http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or
> +link:https://github.com/BartMassey/parsecvs[parsecvs].
> +
>  Imports a CVS repository into git. It will either create a new
>  repository, or incrementally import into an existing one.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] git-cvsimport.txt: cvsps-2 is deprecated
  2013-01-24 20:04               ` Junio C Hamano
@ 2013-01-24 20:13                 ` John Keeping
  2013-01-24 20:58                   ` Junio C Hamano
  0 siblings, 1 reply; 15+ messages in thread
From: John Keeping @ 2013-01-24 20:13 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Eric S. Raymond, Chris Rorvick

On Thu, Jan 24, 2013 at 12:04:11PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
> 
> > git-cvsimport relies on version 2 of cvsps and does not work with the
> > new version 3.  Since cvsps 3.x does not currently work as well as
> > version 2 for incremental import, document this fact.
> >
> > Specifically, there is no way to make new git-cvsimport that supports
> > cvsps 3.x and have a seamless transition for existing users since cvsps
> > 3.x needs a time from which to continue importing and git-cvsimport does
> > not save the time of the last import or import into a specific namespace
> > so there is no safe way to calculate the time of the last import.
> 
> Isn't the whole "and git-cvsimport does not save the time..."  part
> something that can be fixed in the new cvsimport that reads the
> output from cvsps3?

Yes it can be fixed there (and I have patches to do that) - my argument
here is that there cannot be a seamless upgrade for people who are
currently using git-cvsimport incrementally.  If you don't have that
file then how do you create it to reflect the current state of your
repository?

> To me, it sounds more like
> 
>     cvsps2 + cvsimport has an unfixable bugs and there have been an
>     effort to rewrite cvsps2 from scratch.  The resulting cvsp3
>     currently is unusable with cvsimport, especially when importing
>     the history incrementally, and it isn't expected that it will
>     ever be usable with cvsimport again.

cvsps3 isn't a re-write, it's cvsps2 with a lot of things ripped out and
a fast-export mode added.  And in fast-export mode it cannot inspect the
Git repository in the same way that git-cvsimport does.

>     There are other tools that analyse the original history better
>     and emits more correct output when used to convert the whole
>     history, and hopefully cvsps3 + fast-import would become one of
>     them.  Suggest users to use them instead of cvsimport when they
>     are not doing an incremental import.

Yes.  The consensus seems to be that cvs2git is the most correct.

> By the way, do we want to make any recommendation to the distro
> folks which cvsps they should ship?  It appears that not shipping
> cvsps2 would be a major regression if cvsps3 does not plan to
> support incrementals, so shipping both might be the safest way for
> them to support their users with different needs.

I agree.  cvsps is only one binary and a man page so I don't think it
would be too hard to ship both.


John

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] git-cvsimport.txt: cvsps-2 is deprecated
  2013-01-24 20:13                 ` John Keeping
@ 2013-01-24 20:58                   ` Junio C Hamano
  0 siblings, 0 replies; 15+ messages in thread
From: Junio C Hamano @ 2013-01-24 20:58 UTC (permalink / raw)
  To: John Keeping; +Cc: git, Eric S. Raymond, Chris Rorvick

John Keeping <john@keeping.me.uk> writes:

> On Thu, Jan 24, 2013 at 12:04:11PM -0800, Junio C Hamano wrote:
>> John Keeping <john@keeping.me.uk> writes:
>> 
>> > git-cvsimport relies on version 2 of cvsps and does not work with the
>> > new version 3.  Since cvsps 3.x does not currently work as well as
>> > version 2 for incremental import, document this fact.
>> >
>> > Specifically, there is no way to make new git-cvsimport that supports
>> > cvsps 3.x and have a seamless transition for existing users since cvsps
>> > 3.x needs a time from which to continue importing and git-cvsimport does
>> > not save the time of the last import or import into a specific namespace
>> > so there is no safe way to calculate the time of the last import.
>> 
>> Isn't the whole "and git-cvsimport does not save the time..."  part
>> something that can be fixed in the new cvsimport that reads the
>> output from cvsps3?
>
> Yes it can be fixed there (and I have patches to do that) - my argument
> here is that there cannot be a seamless upgrade for people who are
> currently using git-cvsimport incrementally.  If you don't have that
> file then how do you create it to reflect the current state of your
> repository?

I am not disagreeing with your patch text to warn the current users
that cvsimport will be made unusable if they lose cvsps2, and they
are better off using other tools when doing a whole-history import.

I was trying to make sure that my understanding of the current
situation and future possibilities matches yours.

Thanks, I think you clarified the situation better with your
response.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
  2013-01-23 21:12         ` John Keeping
  2013-01-24  5:04           ` Junio C Hamano
@ 2013-01-25  4:55           ` Chris Rorvick
  2013-01-25  9:09             ` John Keeping
  1 sibling, 1 reply; 15+ messages in thread
From: Chris Rorvick @ 2013-01-25  4:55 UTC (permalink / raw)
  To: John Keeping; +Cc: Junio C Hamano, git, Eric S. Raymond

On Wed, Jan 23, 2013 at 3:12 PM, John Keeping <john@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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
  2013-01-25  4:55           ` What's cooking in git.git (Jan 2013, #08; Tue, 22) Chris Rorvick
@ 2013-01-25  9:09             ` John Keeping
  0 siblings, 0 replies; 15+ messages in thread
From: John Keeping @ 2013-01-25  9:09 UTC (permalink / raw)
  To: Chris Rorvick; +Cc: Junio C Hamano, git, Eric S. Raymond

On Thu, Jan 24, 2013 at 10:55:57PM -0600, Chris Rorvick wrote:
> On Wed, Jan 23, 2013 at 3:12 PM, John Keeping <john@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

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2013-01-25  9:20 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-22 22:44 What's cooking in git.git (Jan 2013, #08; Tue, 22) Junio C Hamano
2013-01-22 23:45 ` John Keeping
2013-01-23  0:11   ` Junio C Hamano
2013-01-23  9:28     ` John Keeping
2013-01-23 13:26       ` Chris Rorvick
2013-01-23 13:55         ` John Keeping
2013-01-23 17:13       ` Junio C Hamano
2013-01-23 21:12         ` John Keeping
2013-01-24  5:04           ` Junio C Hamano
2013-01-24 19:18             ` [PATCH] git-cvsimport.txt: cvsps-2 is deprecated John Keeping
2013-01-24 20:04               ` Junio C Hamano
2013-01-24 20:13                 ` John Keeping
2013-01-24 20:58                   ` Junio C Hamano
2013-01-25  4:55           ` What's cooking in git.git (Jan 2013, #08; Tue, 22) Chris Rorvick
2013-01-25  9:09             ` John Keeping

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.