threads / discuss / 20871

What's cooking in git.git (Sep 2009, #02; Mon, 07)

Subject: What's cooking in git.git (Sep 2009, #02; Mon, 07)

## tl;dr

24 messages between Sep 8, 2009 and Sep 12, 2009.

replies: 23people: 8as markdown or json

Junio C Hamano· Sep 8, 2009, 00:56 UTC · lore

What's cooking in git.git (Sep 2009, #02; Mon, 07) --------------------------------------------------

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 integration branches, but I am still holding onto them.

In 1.7.0, we plan to correct handful of warts in the interfaces everybody agrees that they were mistakes. The resulting system may not be strictly backward compatible. Currently planeed changes are:

 * refuse push to update the checked out branch in a non-bare repo by
   default
   Make "git push" into a repository to update the branch that is checked
   out fail by default.  You can countermand this default by setting a
   configuration variable in the receiving repository.
   http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
 * refuse push to delete the current branch by default
   Make "git push $there :$killed" to delete the branch that is pointed at
   by its HEAD fail by default.  You can countermand this default by
   setting a configuration variable in the receiving repository.
   http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
 * git-send-email won't make deep threads by default
   Many people said that by default when sending more than 2 patches the
   threading git-send-email makes by default is hard to read, and they
   prefer the default be one cover letter and each patch as a direct
   follow-up to the cover letter.  You can countermand this by setting a
   configuration variable.
   http://article.gmane.org/gmane.comp.version-control.git/109790
 * git-status won't be "git-commit --dry-run" anymore
   http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
 * "git-diff -w --exit-code" will exit success if only differences it
   found are whitespace changes that are stripped away from the output.
   http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
During 1.6.5 cycle, 'next' will hold topics meant for 1.6.5 and 1.7.0.

I tagged and pushed out 1.6.5-rc0. There are still some topics cooking in 'next' I would rather not leave out, but I've been hoping to keep this cycle short, and I'm also hoping to tag the real 1.6.5 before I vanish for about a week and half later in the month. so in the worst case there may have to be a 1.6.6 to include the leftover topics.

-------------------------------------------------- [Graduated to "master"]

* np/maint-1.6.3-deepen (2009-09-03) 2 commits
  (merged to 'next' on 2009-09-06 at d597fba)
 + pack-objects: free preferred base memory after usage
 + make shallow repository deepening more network efficient

Further optimization and fixing of the object transfer around the "shallow repository" codepaths.

* js/stash-dwim (2009-07-27) 1 commit.
  (merged to 'next' on 2009-08-16 at 67896c4)
 + Make 'git stash -k' a short form for 'git stash save --keep-index'
 (this branch is used by tr/reset-checkout-patch.)
* tr/reset-checkout-patch (2009-08-18) 10 commits.
  (merged to 'next' on 2009-09-03 at d4f2ed7)
 + stash: simplify defaulting to "save" and reject unknown options
  (merged to 'next' on 2009-08-27 at d314281)
 + Make test case number unique
  (merged to 'next' on 2009-08-18 at e465bb3)
 + tests: disable interactive hunk selection tests if perl is not available
  (merged to 'next' on 2009-08-16 at 67896c4)
 + DWIM 'git stash save -p' for 'git stash -p'
 + Implement 'git stash save --patch'
 + Implement 'git checkout --patch'
 + Implement 'git reset --patch'
 + builtin-add: refactor the meat of interactive_add()
 + Add a small patch-mode testing library
 + git-apply--interactive: Refactor patch mode code
 (this branch uses js/stash-dwim.)

DWIMmery of the two series tightened for safety a few days ago. Otherwise the same as what have been cooking in 'next' for a few weeks.

* jc/upload-pack-hook (2009-08-28) 2 commits
  (merged to 'next' on 2009-08-31 at f9933a5)
 + upload-pack: feed "kind [clone|fetch]" to post-upload-pack hook
 + upload-pack: add a trigger for post-upload-pack hook
* jk/clone-b (2009-08-26) 1 commit
  (merged to 'next' on 2009-08-30 at 10a68d1)
 + clone: add --branch option to select a different HEAD
* jc/mailinfo-scissors (2009-08-26) 5 commits
  (merged to 'next' on 2009-08-30 at 5fc6248)
 + mailinfo.scissors: new configuration
 + am/mailinfo: Disable scissors processing by default
 + Documentation: describe the scissors mark support of "git am"
 + Teach mailinfo to ignore everything before -- >8 -- mark
 + builtin-mailinfo.c: fix confusing internal API to mailinfo()

I didn't pick up the patch to simplify the definition of scissors. I do not have strong opinion on it either way, and nobody on the list seemed to care too much either.

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

* cb/maint-1.6.3-grep-relative-up (2009-09-05) 2 commits.
  (merged to 'next' on 2009-09-07 at f9b5b48)
 + grep: accept relative paths outside current working directory
 + grep: fix exit status if external_grep() punts
1.6.5 material.
* jk/1.7.0-status (2009-09-05) 5 commits
 - docs: note that status configuration affects only long format
  (merged to 'next' on 2009-09-07 at 8a7c563)
 + commit: support alternate status formats
 + status: add --porcelain output format
 + status: refactor format option parsing
 + status: refactor short-mode printing to its own function
 (this branch uses jc/1.7.0-status.)

Gives the --short output format to post 1.7.0 "git commit --dry-run" that is similar to that of post 1.7.0 "git status".

It might be a good idea to make the --short format part of 1.6.6 without waiting for 1.7.0; it would require some branch shuffling to bring the short-status patch earlier than the one that makes "status" different from "commit --dry-run", though.

* jk/unwanted-advices (2009-09-06) 2 commits
 - status: make "how to stage" messages optional
 - push: make non-fast-forward help message configurable

Post 1.3.0 "newbie friendliness drive" introduced a lot of "helpful" advice messages that are sometimes found to be irritating once the user got used to working with git. This series introduces a general mechanism to allow us to make them less loud using the config mechanism. The config option hierarchy in these two are "message.*" but it is planned to be renamed to "advice.*".

* jn/gitweb-show-size (2009-09-07) 1 commit
 - gitweb: Add 'show-sizes' feature to show blob sizes in tree view
* jt/pushinsteadof (2009-09-07) 2 commits
 - Add url.<base>.pushInsteadOf: URL rewriting for push only
 - Wrap rewrite globals in a struct in preparation for adding another set
Probably 1.6.5 material.
* lt/maint-traverse-trees-fix (2009-09-06) 1 commit.
 - Prepare 'traverse_trees()' for D/F conflict lookahead

Beginning of the fix to a rather nasty longstanding issue of merging trees with ("a" "a-b"), ("a/b" "a-b") and just ("a-b").

* ne/rev-cache (2009-09-07) 7 commits
 . support for commit grafts, slight change to general mechanism
 . support for path name caching in rev-cache
 . full integration of rev-cache into git, completed test suite
 . administrative functions for rev-cache, start of integration into git
 . support for non-commit object caching in rev-cache
 . basic revision cache system, no integration or features
 . man page and technical discussion for rev-cache
Replaced but I do not think this is ready for 'pu' yet.

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

* jh/notes (2009-08-27) 12 commits.
 - Add '%N'-format for pretty-printing commit notes
 - Add flags to get_commit_notes() to control the format of the note string
 - notes.c: Implement simple memory pooling of leaf nodes
 - Selftests verifying semantics when loading notes trees with various fanouts
 - Teach the notes lookup code to parse notes trees with various fanout schemes
 - t3302-notes-index-expensive: Speed up create_repo()
 - fast-import: Add support for importing commit notes
 - Teach "-m <msg>" and "-F <file>" to "git notes edit"
 - Add an expensive test for git-notes
 - Speed up git notes lookup
 - Add a script to edit/inspect notes
 - Introduce commit notes

I heard the cvs-helper series depends on this one. It seems that the fan-out strategy is being rethought?

* je/send-email-no-subject (2009-08-05) 1 commit
  (merged to 'next' on 2009-08-30 at b6455c2)
 + send-email: confirm on empty mail subjects

The existing tests to covers the positive case (i.e. as long as the user says "yes" to the "do you really want to send this message that lacks subject", the message is sent) of this feature, but the feature itself needs its own test to verify the negative case (i.e. does it correctly stop if the user says "no"?)

* db/vcs-helper (2009-09-03) 16 commits
 - Allow helpers to report in "list" command that the ref is unchanged
 - Add support for "import" helper command
 - Add a config option for remotes to specify a foreign vcs
 - Allow programs to not depend on remotes having urls
 - Allow fetch to modify refs
 - Use a function to determine whether a remote is valid
 - Use a clearer style to issue commands to remote helpers
 - Make the "traditionally-supported" URLs a special case
  (merged to 'next' on 2009-08-07 at f3533ba)
 + Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
 + Makefile: do not link three copies of git-remote-* programs
 + Makefile: git-http-fetch does not need expat
  (merged to 'next' on 2009-08-06 at 15da79d)
 + http-fetch: Fix Makefile dependancies
 + Add transport native helper executables to .gitignore
  (merged to 'next' on 2009-08-05 at 33d491e)
 + git-http-fetch: not a builtin
 + Use an external program to implement fetching with curl
 + Add support for external programs for handling native fetches
 (this branch is used by jh/cvs-helper.)

I'd really want to have this in 1.6.5 so that we can eject -lcurl from the main "git" binary. The patches in 'pu' got some review comments, and I thought Daniel's responses were sensible. Comments?

* jh/cvs-helper (2009-08-18) 8 commits
 - More fixes to the git-remote-cvs installation procedure
 - Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
 - Add simple selftests of git-remote-cvs functionality
 - git-remote-cvs: Remote helper program for CVS repositories
 - 2/2: Add Python support library for CVS remote helper
 - 1/2: Add Python support library for CVS remote helper
 - Basic build infrastructure for Python scripts
 - Allow helpers to request marks for fast-import
 (this branch uses db/vcs-helper.)
Builds on db/vcs-helper.  There is a re-roll planned.
* cc/sequencer-rebase-i (2009-08-28) 15 commits
 - rebase -i: use "git sequencer--helper --cherry-pick"
 - sequencer: add "--cherry-pick" option to "git sequencer--helper"
 - sequencer: add "do_commit()" and related functions working on "next_commit"
 - pick: libify "pick_help_msg()"
 - revert: libify cherry-pick and revert functionnality
 - rebase -i: use "git sequencer--helper --fast-forward"
 - sequencer: let "git sequencer--helper" callers set "allow_dirty"
 - sequencer: add "--fast-forward" option to "git sequencer--helper"
 - sequencer: add "do_fast_forward()" to perform a fast forward
 - rebase -i: use "git sequencer--helper --reset-hard"
 - sequencer: add "--reset-hard" option to "git sequencer--helper"
 - sequencer: add "reset_almost_hard()" and related functions
 - rebase -i: use "git sequencer--helper --make-patch"
 - sequencer: add "make_patch" function to save a patch
 - sequencer: add "builtin-sequencer--helper.c"

Migrating "rebase -i" bit by bit to C. Not a 1.6.5 material yet.

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

* pk/fast-import-tars (2009-09-03) 1 commit
  (merged to 'next' on 2009-09-07 at 8fbf027)
 + import-tars: Allow per-tar author and commit message.
* jc/maint-1.6.0-blank-at-eof (2009-09-05) 10 commits.
  (merged to 'next' on 2009-09-07 at 165dc3c)
 + core.whitespace: split trailing-space into blank-at-{eol,eof}
 + diff --color: color blank-at-eof
 + diff --whitespace=warn/error: fix blank-at-eof check
 + diff --whitespace=warn/error: obey blank-at-eof
 + diff.c: the builtin_diff() deals with only two-file comparison
 + apply --whitespace: warn blank but not necessarily empty lines at EOF
 + apply --whitespace=warn/error: diagnose blank at EOF
 + apply.c: split check_whitespace() into two
 + apply --whitespace=fix: detect new blank lines at eof correctly
 + apply --whitespace=fix: fix handling of blank lines at the eof
Hopefully in 1.6.5
* pk/fast-import-dirs (2009-09-03) 1 commit
  (merged to 'next' on 2009-09-07 at 836cba2)
 + Add script for importing bits-and-pieces to Git.

With an updated key-value quoting rules, which I haven't carefully looked at. I have to wonder if there are standard libraries to do this sort of thing without having to hand-roll these logic every time. But perhaps I shouldn't be too picky on contrib/ material.

* jn/gitweb-blame (2009-09-01) 5 commits
 - gitweb: Minify gitweb.js if JSMIN is defined
 - gitweb: Create links leading to 'blame_incremental' using JavaScript
  (merged to 'next' on 2009-09-07 at 3622199)
 + gitweb: Colorize 'blame_incremental' view during processing
 + gitweb: Incremental blame (using JavaScript)
 + gitweb: Add optional "time to generate page" info in footer
Ajax-y blame.
* sr/gfi-options (2009-09-06) 6 commits
  (merged to 'next' on 2009-09-07 at 5f6b0ff)
 + fast-import: test the new option command
 + fast-import: add option command
 + fast-import: test the new feature command
 + fast-import: add feature command
 + fast-import: put marks reading in it's own function
 + fast-import: put option parsing code in separate functions
Perhaps 1.6.5 material but I wasn't sure.
* nd/sparse (2009-08-20) 19 commits
 - sparse checkout: inhibit empty worktree
 - Add tests for sparse checkout
 - read-tree: add --no-sparse-checkout to disable sparse checkout support
 - unpack-trees(): ignore worktree check outside checkout area
 - unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
 - unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
 - unpack-trees.c: generalize verify_* functions
 - unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
 - Introduce "sparse checkout"
 - dir.c: export excluded_1() and add_excludes_from_file_1()
 - excluded_1(): support exclude files in index
 - unpack-trees(): carry skip-worktree bit over in merged_entry()
 - Read .gitignore from index if it is skip-worktree
 - Avoid writing to buffer in add_excludes_from_file_1()
 - Teach Git to respect skip-worktree bit (writing part)
 - Teach Git to respect skip-worktree bit (reading part)
 - Introduce "skip-worktree" bit in index, teach Git to get/set this bit
 - Add test-index-version
 - update-index: refactor mark_valid() in preparation for new options

-------------------------------------------------- [For 1.7.0]

* jc/1.7.0-status (2009-09-05) 4 commits
  (merged to 'next' on 2009-09-06 at 19d4beb)
 + status: typo fix in usage
  (merged to 'next' on 2009-08-22 at b3507bb)
 + git status: not "commit --dry-run" anymore
 + git stat -s: short status output
 + git stat: the beginning of "status that is not a dry-run of commit"
 (this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
  (merged to 'next' on 2009-08-22 at 5106de8)
 + send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
  (merged to 'next' on 2009-08-30 at 0623572)
 + diff.c: fix typoes in comments
  (merged to 'next' on 2009-08-27 at 81fb2bd)
 + Make test case number unique
  (merged to 'next' on 2009-08-02 at 9c08420)
 + diff: Rename QUIET internal option to QUICK
 + diff: change semantics of "ignore whitespace" options

This changes exit code from "git diff --ignore-whitespace" and friends when there is no actual output. It is a backward incompatible change, but we could argue that it is a bugfix.

* jc/1.7.0-push-safety (2009-02-09) 2 commits
  (merged to 'next' on 2009-08-02 at 38b82fe)
 + Refuse deleting the current branch via push
 + Refuse updating the current branch in a non-bare repository via push

-------------------------------------------------- [I have been too busy to purge these]

* jc/log-tz (2009-03-03) 1 commit.
 - Allow --date=local --date=other-format to work as expected
Maybe some people care about this.  I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
 - mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this.  I dunno.
* lt/read-directory (2009-05-15) 3 commits.
 . Add initial support for pathname conversion to UTF-8
 . read_directory(): infrastructure for pathname character set conversion
 . Add 'fill_directory()' helper function for directory traversal
Nanako Shiraishi· Sep 8, 2009, 06:31 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)

Quoting Junio C Hamano <gitster@pobox.com>
Show 5 quoted lines
> I tagged and pushed out 1.6.5-rc0.  There are still some topics cooking in
> 'next' I would rather not leave out, but I've been hoping to keep this
> cycle short, and I'm also hoping to tag the real 1.6.5 before I vanish for
> about a week and half later in the month. so in the worst case there may
> have to be a 1.6.6 to include the leftover topics.
Are you coming to Japan to promote your book, perhaps giving autographs at bookstores?
-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
Junio C Hamano· Sep 8, 2009, 06:48 UTC · re: Nanako Shiraishi · lore

Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)

Nanako Shiraishi <nanako3@lavabit.com> writes:
Show 6 quoted lines
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> ... I'm also hoping to tag the real 1.6.5 before I vanish for
>> about a week and half later in the month....
>
> Are you coming to Japan to promote your book, perhaps giving autographs at bookstores?

It will come out around 19th if things go as planned, but I'll be arriving the week after that so I'll be too late for that kind of thing.

Besides, who would want an autographed copy of a technical book?

I should start asking the usual suspect to take things over while I'm offline...

Jakub Narebski· Sep 8, 2009, 13:10 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)

Junio C Hamano <gitster@pobox.com> writes:
> * jn/gitweb-show-size (2009-09-07) 1 commit
>  - gitweb: Add 'show-sizes' feature to show blob sizes in tree view
This is an RFC, because of a) feature naming, and b) tests.
It does work correctly, though.
 
> * jn/gitweb-blame (2009-09-01) 5 commits
>  - gitweb: Minify gitweb.js if JSMIN is defined
>  - gitweb: Create links leading to 'blame_incremental' using JavaScript
>   (merged to 'next' on 2009-09-07 at 3622199)

I plan on reverting the order of those two patches, as JSMIN patch is more ready than 'blame_incremental' linking.

With JSMIN there is perhaps question of documenting it, and whether git-instaweb.sh should use minified JavaScript or not (curently it does not). With 'blame_incremental' linking there are quite a few issues:

 1. When to do JavaScript detection
    a. on load (current solution)
    b. on click (via event handler)
 2. How to invoke actions requiring JavaScript
    a. add 'js=1' parameter (perhaps limiting URLs, as not to
       add it e.g. to http://git-scm.com/ $home_link)
    b. rewrite action parameter, e.g. from 'blame' to
       'blame_incremental' (troubles with path_info URLs)
    c. use cookies
Current solution works, but I think is suboptimal.
Show 5 quoted lines
>  + gitweb: Colorize 'blame_incremental' view during processing
>  + gitweb: Incremental blame (using JavaScript)
>  + gitweb: Add optional "time to generate page" info in footer
> 
> Ajax-y blame.

I'd very much like for others to check if it works with other browsers (Internet Explorer 6, 7, 8; Opera 9, 10; Safari; Firefox 2, 3, 3.5)

-- 
Jakub Narebski
Poland
ShadeHawk on #git
Sverre Rabbelier· Sep 8, 2009, 13:17 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)

Heya,
On Tue, Sep 8, 2009 at 02:56, Junio C Hamano<gitster@pobox.com> wrote:
Show 10 quoted lines
> * sr/gfi-options (2009-09-06) 6 commits
>  (merged to 'next' on 2009-09-07 at 5f6b0ff)
>  + fast-import: test the new option command
>  + fast-import: add option command
>  + fast-import: test the new feature command
>  + fast-import: add feature command
>  + fast-import: put marks reading in it's own function
>  + fast-import: put option parsing code in separate functions
>
> Perhaps 1.6.5 material but I wasn't sure.

Shawn, what's your opinion of v7? I think it handles pretty much everything we need for at least a draft and is good for 1.6.5, but it's up to you of course :).

-- 
Cheers,

Sverre Rabbelier
Jeff King· Sep 9, 2009, 11:59 UTC · re: Junio C Hamano · lore

jk/1.7.0-status, was: What's cooking in git.git (Sep 2009, #02; Mon, 07)

On Mon, Sep 07, 2009 at 05:56:53PM -0700, Junio C Hamano wrote:
Show 16 quoted lines
> * jk/1.7.0-status (2009-09-05) 5 commits
>  - docs: note that status configuration affects only long format
>   (merged to 'next' on 2009-09-07 at 8a7c563)
>  + commit: support alternate status formats
>  + status: add --porcelain output format
>  + status: refactor format option parsing
>  + status: refactor short-mode printing to its own function
>  (this branch uses jc/1.7.0-status.)
> 
> Gives the --short output format to post 1.7.0 "git commit --dry-run" that
> is similar to that of post 1.7.0 "git status".
> 
> It might be a good idea to make the --short format part of 1.6.6 without
> waiting for 1.7.0; it would require some branch shuffling to bring the
> short-status patch earlier than the one that makes "status" different from
> "commit --dry-run", though.

It looks like the short-status patch is already right before "commit --dry-run", but it is of course part of "git stat". So we could get by with branching from jc/1.7.0-status^, and do one of:

 1. develop as if we were a totally separate topic, refactoring, adding
    --porcelain mode, etc.
 2. just support "--short" from "git status" with as small a change as
    possible, and let the rest of the enhancements stay where they are,
    for 1.7.0

Option (1) is what I would usually do, but I think in this case it is just going to end up with me re-doing lots of work as the almost-duplicated refactoring happening in the two branches is going to make a gigantic conflict.

And of course option (3) is to just let --short rest until 1.7.0.
-Peff
Daniel Barkalow· Sep 10, 2009, 16:18 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)

On Mon, 7 Sep 2009, Junio C Hamano wrote:
Show 25 quoted lines
> * db/vcs-helper (2009-09-03) 16 commits
>  - Allow helpers to report in "list" command that the ref is unchanged
>  - Add support for "import" helper command
>  - Add a config option for remotes to specify a foreign vcs
>  - Allow programs to not depend on remotes having urls
>  - Allow fetch to modify refs
>  - Use a function to determine whether a remote is valid
>  - Use a clearer style to issue commands to remote helpers
>  - Make the "traditionally-supported" URLs a special case
>   (merged to 'next' on 2009-08-07 at f3533ba)
>  + Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
>  + Makefile: do not link three copies of git-remote-* programs
>  + Makefile: git-http-fetch does not need expat
>   (merged to 'next' on 2009-08-06 at 15da79d)
>  + http-fetch: Fix Makefile dependancies
>  + Add transport native helper executables to .gitignore
>   (merged to 'next' on 2009-08-05 at 33d491e)
>  + git-http-fetch: not a builtin
>  + Use an external program to implement fetching with curl
>  + Add support for external programs for handling native fetches
>  (this branch is used by jh/cvs-helper.)
> 
> I'd really want to have this in 1.6.5 so that we can eject -lcurl from the
> main "git" binary.  The patches in 'pu' got some review comments, and I
> thought Daniel's responses were sensible.  Comments?

I'm pretty sure that there were no objections to 'Make the "traditonally-supported"...' patch, and directly after that is a reasonable stopping point (everything that used to work works the same, nothing new and user-visible is introduced, the implementation is reasonably straightforward and tidy, and the git binary doesn't link against -lcurl). I'd suggest putting everything up to that point into master and debating the rest of the series on its own merits (and likely deferring it to post-1.6.5, since it doesn't have an in-tree user to exercise it yet).

	-Daniel
*This .sig left intentionally blank*
Johannes Schindelin· Sep 10, 2009, 16:53 UTC · re: Daniel Barkalow · lore

Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)

Hi,
On Thu, 10 Sep 2009, Daniel Barkalow wrote:
> I'm pretty sure that there were no objections to 'Make the 
> "traditonally-supported"...' patch,
Well, there were.  By me.

There is a reason why you call the series "foreign" vcs helpers. And that's because it would be very wrong to pretend that they are the rule, and the current URL schemes the exception. Very wrong, indeed.

Thankyouvermuch, Dscho

Daniel Barkalow· Sep 10, 2009, 17:55 UTC · re: Johannes Schindelin · lore

Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)

On Thu, 10 Sep 2009, Johannes Schindelin wrote:
Show 12 quoted lines
> Hi,
> 
> On Thu, 10 Sep 2009, Daniel Barkalow wrote:
> 
> > I'm pretty sure that there were no objections to 'Make the 
> > "traditonally-supported"...' patch,
> 
> Well, there were.  By me.
> 
> There is a reason why you call the series "foreign" vcs helpers.  And 
> that's because it would be very wrong to pretend that they are the rule, 
> and the current URL schemes the exception.  Very wrong, indeed.

The current URL scheme *is* an "exception" to the "rule" that all remotes are foreign, or the current "rule" that all remotes are ssh-style. Any patterns that we currently support are handled by recognizing a particular pattern (starts with "git://", starts with "rsync://", starts with "https://", is a local file, is a local directory, etc), so they're all special cases. They're further special cases by virtue of the fact that the code to handle them is in the git distribution.

	-Daniel
*This .sig left intentionally blank*
Junio C Hamano· Sep 10, 2009, 18:41 UTC · re: Johannes Schindelin · lore

Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> There is a reason why you call the series "foreign" vcs helpers.  And 
> that's because it would be very wrong to pretend that they are the rule, 
> and the current URL schemes the exception.  Very wrong, indeed.
I do not know what you mean by "very wrong".

If the name bothers you, you can think of the earlier part of the series cleaning up the transport code so that it makes easier to choose which transport, either internal or external, and ports the native transport support to use the mechanism. Then the rest of the series builds on it to add further support for "foreign" vcs helpers.

Nicolas Sebrecht· Sep 11, 2009, 00:09 UTC · re: Junio C Hamano · lore

scissors definition and documentation

The 07/09/09, Junio C Hamano wrote:
Show 12 quoted lines
> 
> * jc/mailinfo-scissors (2009-08-26) 5 commits
>   (merged to 'next' on 2009-08-30 at 5fc6248)
>  + mailinfo.scissors: new configuration
>  + am/mailinfo: Disable scissors processing by default
>  + Documentation: describe the scissors mark support of "git am"
>  + Teach mailinfo to ignore everything before -- >8 -- mark
>  + builtin-mailinfo.c: fix confusing internal API to mailinfo()
> 
> I didn't pick up the patch to simplify the definition of scissors. I do
> not have strong opinion on it either way, and nobody on the list seemed to
> care too much either.

Since --scissors is an option instead of the default behaviour, I believe that the definition of scissors is much less critical.

The following two patches is only about documentation.

The last patch mixes documentation of both mailinfo.scissors and --no--scissors because I think they are very tied from the user POV.

 [PATCH 1/2] mailinfo: add '--scissors' to usage message
 [PATCH 2/2] add documentation for mailinfo.scissors and '--no-scissors'
---
 Documentation/git-am.txt       |    2 +-
 Documentation/git-mailinfo.txt |    6 ++++++
 builtin-mailinfo.c             |    2 +-
 git-am.sh                      |    1 +
 4 files changed, 9 insertions(+), 2 deletions(-)
Nicolas Sebrecht· Sep 11, 2009, 00:09 UTC · re: Junio C Hamano · lore

[PATCH 1/2] mailinfo: add '--scissors' to usage message

Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---
 builtin-mailinfo.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 03cbcad..7d22fd7 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -1004,7 +1004,7 @@ static int git_mailinfo_config(const char *var, const char *value, void *unused)
 }
 
 static const char mailinfo_usage[] =
-	"git mailinfo [-k] [-u | --encoding=<encoding> | -n] msg patch <mail >info";
+	"git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors] msg patch < mail >info";
 
 int cmd_mailinfo(int argc, const char **argv, const char *prefix)
 {
-- 
1.6.5.rc0.164.g5f6b0
Nicolas Sebrecht· Sep 11, 2009, 00:09 UTC · re: Junio C Hamano · lore

[PATCH 2/2] add documentation for mailinfo.scissors and '--no-scissors'

Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---
 Documentation/git-am.txt       |    2 +-
 Documentation/git-mailinfo.txt |    6 ++++++
 builtin-mailinfo.c             |    2 +-
 git-am.sh                      |    1 +
 4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 87781f4..8b2897b 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -13,7 +13,7 @@ SYNOPSIS
 	 [--3way] [--interactive] [--committer-date-is-author-date]
 	 [--ignore-date] [--ignore-space-change | --ignore-whitespace]
 	 [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
-	 [--reject] [-q | --quiet] [--scissors]
+	 [--reject] [-q | --quiet] [--scissors | --no-scissors]
 	 [<mbox> | <Maildir>...]
 'git am' (--skip | --resolved | --abort)
 
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 823ab82..55b8c5e 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -62,6 +62,12 @@ This is useful if you want to begin your message in a discussion thread
 with comments and suggestions on the message you are responding to, and to
 conclude it with a patch submission, separating the discussion and the
 beginning of the proposed commit log message with a scissors line.
++
+This can enabled by default with the configuration option mailinfo.scissors.
+
+--no-scissors::
+	Do not obey to a scissors line. This is only useful if mailinfo.scissors is
+	enabled (see --scissors).
 
 <msg>::
 	The commit log message extracted from e-mail, usually
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 7d22fd7..d498b1c 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -1004,7 +1004,7 @@ static int git_mailinfo_config(const char *var, const char *value, void *unused)
 }
 
 static const char mailinfo_usage[] =
-	"git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors] msg patch < mail >info";
+	"git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors | --no-scissors] msg patch < mail >info";
 
 int cmd_mailinfo(int argc, const char **argv, const char *prefix)
 {
diff --git a/git-am.sh b/git-am.sh
index 26ffe70..f242d1a 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -16,6 +16,7 @@ s,signoff       add a Signed-off-by line to the commit message
 u,utf8          recode into utf8 (default)
 k,keep          pass -k flag to git-mailinfo
 c,scissors      strip everything before a scissors line
+no-scissors     don't obey to a scissors line (default)
 whitespace=     pass it through git-apply
 ignore-space-change pass it through git-apply
 ignore-whitespace pass it through git-apply
-- 
1.6.5.rc0.164.g5f6b0
Nicolas Sebrecht· Sep 11, 2009, 00:29 UTC · re: Nicolas Sebrecht · lore

[PATCH v2] add documentation for mailinfo.scissors and '--no-scissors'

Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---

I've missed the documentation of --no-scissors in git-am.txt in the previous round (second hunks here).

Sorry for inconvenience.
 Documentation/git-am.txt       |    5 ++++-
 Documentation/git-mailinfo.txt |    6 ++++++
 builtin-mailinfo.c             |    2 +-
 git-am.sh                      |    1 +
 4 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 87781f4..14ae3a5 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -13,7 +13,7 @@ SYNOPSIS
 	 [--3way] [--interactive] [--committer-date-is-author-date]
 	 [--ignore-date] [--ignore-space-change | --ignore-whitespace]
 	 [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
-	 [--reject] [-q | --quiet] [--scissors]
+	 [--reject] [-q | --quiet] [--scissors | --no-scissors]
 	 [<mbox> | <Maildir>...]
 'git am' (--skip | --resolved | --abort)
 
@@ -44,6 +44,9 @@ OPTIONS
 	Remove everything in body before a scissors line (see
 	linkgit:git-mailinfo[1]).
 
+---no-scissors::
+	Do not obey to a scissors line (see linkgit:git-mailinfo[1]).
+
 -q::
 --quiet::
 	Be quiet. Only print error messages.
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 823ab82..55b8c5e 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -62,6 +62,12 @@ This is useful if you want to begin your message in a discussion thread
 with comments and suggestions on the message you are responding to, and to
 conclude it with a patch submission, separating the discussion and the
 beginning of the proposed commit log message with a scissors line.
++
+This can enabled by default with the configuration option mailinfo.scissors.
+
+--no-scissors::
+	Do not obey to a scissors line. This is only useful if mailinfo.scissors is
+	enabled (see --scissors).
 
 <msg>::
 	The commit log message extracted from e-mail, usually
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 7d22fd7..d498b1c 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -1004,7 +1004,7 @@ static int git_mailinfo_config(const char *var, const char *value, void *unused)
 }
 
 static const char mailinfo_usage[] =
-	"git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors] msg patch < mail >info";
+	"git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors | --no-scissors] msg patch < mail >info";
 
 int cmd_mailinfo(int argc, const char **argv, const char *prefix)
 {
diff --git a/git-am.sh b/git-am.sh
index 26ffe70..f242d1a 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -16,6 +16,7 @@ s,signoff       add a Signed-off-by line to the commit message
 u,utf8          recode into utf8 (default)
 k,keep          pass -k flag to git-mailinfo
 c,scissors      strip everything before a scissors line
+no-scissors     don't obey to a scissors line (default)
 whitespace=     pass it through git-apply
 ignore-space-change pass it through git-apply
 ignore-whitespace pass it through git-apply
-- 
1.6.5.rc0.168.gdcd6e
Junio C Hamano· Sep 11, 2009, 07:19 UTC · re: Nicolas Sebrecht · lore

Re: [PATCH v2] add documentation for mailinfo.scissors and '--no-scissors'

Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> +---no-scissors::
> +	Do not obey to a scissors line (see linkgit:git-mailinfo[1]).
> +

obey is v.t. so "do not obey a scissors line" would be grammatical; I think "ignore scissors lines" would be better.

> +--no-scissors::
> +	Do not obey to a scissors line. This is only useful if mailinfo.scissors is
> +	enabled (see --scissors).

Ditto; also it is useful in general if you do not know which way it is configured. Saying "_only_" is misleading.

	Ignore scissors lines; useful for overriding mailinfo.scissors
	settings.
Show 12 quoted lines
> diff --git a/git-am.sh b/git-am.sh
> index 26ffe70..f242d1a 100755
> --- a/git-am.sh
> +++ b/git-am.sh
> @@ -16,6 +16,7 @@ s,signoff       add a Signed-off-by line to the commit message
>  u,utf8          recode into utf8 (default)
>  k,keep          pass -k flag to git-mailinfo
>  c,scissors      strip everything before a scissors line
> +no-scissors     don't obey to a scissors line (default)
>  whitespace=     pass it through git-apply
>  ignore-space-change pass it through git-apply
>  ignore-whitespace pass it through git-apply

Do we want it to allow --no-no-scissors? I do not think this hunk is necessary at all.

Nicolas Sebrecht· Sep 11, 2009, 13:41 UTC · re: Junio C Hamano · lore

[PATCH v2] Re: add documentation for mailinfo.scissors and '--no-scissors'

[ Thank you for this review. ]
The 11/09/09, Junio C Hamano wrote:
Show 17 quoted lines
> Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> 
> > diff --git a/git-am.sh b/git-am.sh
> > index 26ffe70..f242d1a 100755
> > --- a/git-am.sh
> > +++ b/git-am.sh
> > @@ -16,6 +16,7 @@ s,signoff       add a Signed-off-by line to the commit message
> >  u,utf8          recode into utf8 (default)
> >  k,keep          pass -k flag to git-mailinfo
> >  c,scissors      strip everything before a scissors line
> > +no-scissors     don't obey to a scissors line (default)
> >  whitespace=     pass it through git-apply
> >  ignore-space-change pass it through git-apply
> >  ignore-whitespace pass it through git-apply
> 
> Do we want it to allow --no-no-scissors?  I do not think this hunk is
> necessary at all.

I don't understand your point here. This hunk doesn't allow --no-no-scissors but add --no-scissors to usage of 'git am', no?

Do I miss something around $OPTIONS_SPEC?
-- 
Nicolas Sebrecht
Junio C Hamano· Sep 11, 2009, 18:53 UTC · re: Nicolas Sebrecht · lore

Re: [PATCH v2] Re: add documentation for mailinfo.scissors and '--no-scissors'

Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> I don't understand your point here. This hunk doesn't allow
> --no-no-scissors but add --no-scissors to usage of 'git am', no?
>
> Do I miss something around $OPTIONS_SPEC?
You missed two thirds of the issue and I missed the other one third ;-)

As scissors is not marked with ! (see PARSEOPT section in the rev-parse documentation), no-scissors is already available without that hunk, and that is why your patch is unnecessary.

Your patch did not mark no-scissors with ! either, so it makes the call to rev-parse --parseopt to process your OPTIONS_SPEC pass --no-no-scissors.

However, you did not add --no-no-scissors arm to the case statement that processes rev-parse --parseopt output, so the command as the whole still rejects --no-no-scissors as invalid (this is the last third I missed).

Nicolas Sebrecht· Sep 11, 2009, 20:08 UTC · re: Junio C Hamano · lore

[PATCH v2] Re: add documentation for mailinfo.scissors and '--no-scissors'

The 11/09/09, Junio C Hamano wrote:
Show 8 quoted lines
> Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> 
> As scissors is not marked with ! (see PARSEOPT section in the rev-parse
> documentation), no-scissors is already available without that hunk, and
> that is why your patch is unnecessary.
> 
> Your patch did not mark no-scissors with ! either, so it makes the call to
> rev-parse --parseopt to process your OPTIONS_SPEC pass --no-no-scissors.

Ok. So, the fact that the usage of git-am doesn't tell about --no-scissors is the expected behaviour?

Without changing the current implementation of rev-parse, I can't see a smart way to add --no-scissors in the 'git am' usage. Yes, there's still the possibility to negate both "c,scissors" and "no-scissors" but this would defeate some of the PARSE_OPT_NONEG purpose, right?

Oh, and I still feel a bit disoriented by this "rev-parse --parseopt" thing. I guess I need to read the code. :-)

-- 
Nicolas Sebrecht
Junio C Hamano· Sep 11, 2009, 21:00 UTC · re: Nicolas Sebrecht · lore

Re: [PATCH v2] Re: add documentation for mailinfo.scissors and '--no-scissors'

Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> Ok. So, the fact that the usage of git-am doesn't tell about
> --no-scissors is the expected behaviour?

You _could_ argue that we _could_ describe a long option "frotz" that lacks the '!' flag in OPTIONS_SPEC as "--[no-]frotz" in the output by changing the rev-parse --parseopt, if you really want to.

However, I think that is not done deliberately to avoid cluttering the output. I Cc'ed the primary guilty party ;-) of the parse-options infrastructure.

Currently, non-bool options are not marked with '!'. Nobody sane would say "git am --no-directory foo", but "rev-parse --parseopt" acccepts such a nonsense input, and it is up to the calling script to catch it and barf. But "rev-parse --parseopt" will start saying "--[no-]directory=" with such a change, which is not good.

And --no-scissors is not that special. We could add --no-signoff to say "I do not want to sign-off this one time" explicitly, and it is crazy if we had to add another line in OPTIONS_SPEC when we want to do so, when it is clear "signoff" option is a boolean.

As a long term direction, I'd rather not to see "no-" in OPTIONS_SPEC, but have that taken care of by "rev-parse --parseopt" to keep our sanity. The only existing offender is "no-verify" in "rebase -i". Let's solve it (if there is anything to solve, which I doubt) without adding new ones.

Nicolas Sebrecht· Sep 12, 2009, 03:03 UTC · re: Junio C Hamano · lore

[PATCH v2] Re: add documentation for mailinfo.scissors and '--no-scissors'

[ Thank you (again) for this very good explanation. ]
The 11/09/09, Junio C Hamano wrote:
Show 12 quoted lines
> Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> 
> > Ok. So, the fact that the usage of git-am doesn't tell about
> > --no-scissors is the expected behaviour?
> 
> You _could_ argue that we _could_ describe a long option "frotz" that
> lacks the '!' flag in OPTIONS_SPEC as "--[no-]frotz" in the output by
> changing the rev-parse --parseopt, if you really want to.
> 
> However, I think that is not done deliberately to avoid cluttering the
> output.  I Cc'ed the primary guilty party ;-) of the parse-options
> infrastructure.

Well, if it is expected to not have the "--[no-]frotz" in usage where applicable I'll be fine with that (even if it may sounds a bit odd for a sane user). Otherwise, I believe it could be a (small) improvement for the UI.

Show 15 quoted lines
> Currently, non-bool options are not marked with '!'.  Nobody sane would
> say "git am --no-directory foo", but "rev-parse --parseopt" acccepts such
> a nonsense input, and it is up to the calling script to catch it and barf.
> But "rev-parse --parseopt" will start saying "--[no-]directory=" with such
> a change, which is not good.
> 
> And --no-scissors is not that special.  We could add --no-signoff to say
> "I do not want to sign-off this one time" explicitly, and it is crazy if
> we had to add another line in OPTIONS_SPEC when we want to do so, when it
> is clear "signoff" option is a boolean.
> 
> As a long term direction, I'd rather not to see "no-" in OPTIONS_SPEC, but
> have that taken care of by "rev-parse --parseopt" to keep our sanity.  The
> only existing offender is "no-verify" in "rebase -i".  Let's solve it (if
> there is anything to solve, which I doubt) without adding new ones.

Now (with all this background in mind), I agree that the "no-" in OPTIONS_SPEC looks ugly.

<If there were something to change>

As you say, we can't blindly rely on the "is a boolean" and "option name begin with 'no-'" things altogether. Perhaps a new magic character ('-'?) beside the current flags of PARSEOPT could smartly do the trick?

</>
Pierre, opinion?
-- 
Nicolas Sebrecht
Nicolas Sebrecht· Sep 11, 2009, 19:50 UTC · re: Junio C Hamano · lore

[PATCH v3 2/2] add documentation for mailinfo.scissors and '--no-scissors'

The 11/09/09, Junio C Hamano wrote:
Show 34 quoted lines
> Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> 
> > +---no-scissors::
> > +   Do not obey to a scissors line (see linkgit:git-mailinfo[1]).
> > +
> 
> obey is v.t. so "do not obey a scissors line" would be grammatical; I
> think "ignore scissors lines" would be better.
> 
> > +--no-scissors::
> > +   Do not obey to a scissors line. This is only useful if mailinfo.scissors is
> > +   enabled (see --scissors).
> 
> Ditto; also it is useful in general if you do not know which way it is
> configured.  Saying "_only_" is misleading.
> 
>       Ignore scissors lines; useful for overriding mailinfo.scissors
>       settings.
> 
> > diff --git a/git-am.sh b/git-am.sh
> > index 26ffe70..f242d1a 100755
> > --- a/git-am.sh
> > +++ b/git-am.sh
> > @@ -16,6 +16,7 @@ s,signoff       add a Signed-off-by line to the commit message
> >  u,utf8          recode into utf8 (default)
> >  k,keep          pass -k flag to git-mailinfo
> >  c,scissors      strip everything before a scissors line
> > +no-scissors     don't obey to a scissors line (default)
> >  whitespace=     pass it through git-apply
> >  ignore-space-change pass it through git-apply
> >  ignore-whitespace pass it through git-apply
> 
> Do we want it to allow --no-no-scissors?  I do not think this hunk is
> necessary at all.
This version includes the above comments.
Thanks,
-- >8 --
Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---
 Documentation/git-am.txt       |    5 ++++-
 Documentation/git-mailinfo.txt |    5 +++++
 builtin-mailinfo.c             |    2 +-
 3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 87781f4..06e6ea6 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -13,7 +13,7 @@ SYNOPSIS
 	 [--3way] [--interactive] [--committer-date-is-author-date]
 	 [--ignore-date] [--ignore-space-change | --ignore-whitespace]
 	 [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
-	 [--reject] [-q | --quiet] [--scissors]
+	 [--reject] [-q | --quiet] [--scissors | --no-scissors]
 	 [<mbox> | <Maildir>...]
 'git am' (--skip | --resolved | --abort)
 
@@ -44,6 +44,9 @@ OPTIONS
 	Remove everything in body before a scissors line (see
 	linkgit:git-mailinfo[1]).
 
+---no-scissors::
+	ignore scissors lines (see linkgit:git-mailinfo[1]).
+
 -q::
 --quiet::
 	Be quiet. Only print error messages.
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 823ab82..d1f9cb8 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -62,6 +62,11 @@ This is useful if you want to begin your message in a discussion thread
 with comments and suggestions on the message you are responding to, and to
 conclude it with a patch submission, separating the discussion and the
 beginning of the proposed commit log message with a scissors line.
++
+This can enabled by default with the configuration option mailinfo.scissors.
+
+--no-scissors::
+	ignore scissors lines; useful for overriding mailinfo.scissors settings.
 
 <msg>::
 	The commit log message extracted from e-mail, usually
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 7d22fd7..d498b1c 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -1004,7 +1004,7 @@ static int git_mailinfo_config(const char *var, const char *value, void *unused)
 }
 
 static const char mailinfo_usage[] =
-	"git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors] msg patch < mail >info";
+	"git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors | --no-scissors] msg patch < mail >info";
 
 int cmd_mailinfo(int argc, const char **argv, const char *prefix)
 {
-- 
1.6.5.rc0.166.g46a82
Junio C Hamano· Sep 12, 2009, 00:33 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)

This is an abbreviated preview of issue #03 for this month; the message primarily covers potential 1.6.5 material and omits topics without much urgency for the purpose of pushing 1.6.5-rc1 out.

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

* jc/merge-saner-messages (2009-09-07) 1 commit
  (merged to 'next' on 2009-09-11 at 4efab98)
 + merge-recursive: give less scary messages when merge did not start
I think this should be safe for 1.6.5.
* rc/maint-http-no-head-pack-check (2009-09-09) 1 commit.
 - http.c: remove verification of remote packs

This is the response to infamous "github sometimes gives status 500 error for a HEAD request even when GET request for the same URL happily serves the content error-free." problem.

I am hoping this is safe for 1.6.5, but will wait for a response to my inquiry earlier.

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

* jh/notes (2009-08-27) 12 commits.

The reroll was discussed on the list; unfortunately it did not quite apply to any of my branches. I do not think this has to be in 1.6.5, but I just want to get us unstuck if Johan was waiting for me to apply the current series before making his next move.

* je/send-email-no-subject (2009-08-05) 1 commit
  (merged to 'next' on 2009-08-30 at b6455c2)
 + send-email: confirm on empty mail subjects

It would be a good change for 1.6.5 when done properly, but this does not honor --confirm=never but talks to the terminal. Nor it honors any existing sendemail.confirm configuration settings.

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

* db/vcs-helper (2009-09-03) 16 commits
 - ...
  (merged to 'next' on 2009-09-11 at a275aa3)
 + Use a clearer style to issue commands to remote helpers
 + Make the "traditionally-supported" URLs a special case
  (merged to 'next' on 2009-08-07 at f3533ba)
 + Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
 + Makefile: do not link three copies of git-remote-* programs
 + Makefile: git-http-fetch does not need expat
  (merged to 'next' on 2009-08-06 at 15da79d)
 + http-fetch: Fix Makefile dependancies
 + Add transport native helper executables to .gitignore
  (merged to 'next' on 2009-08-05 at 33d491e)
 + git-http-fetch: not a builtin
 + Use an external program to implement fetching with curl
 + Add support for external programs for handling native fetches
 (this branch is used by jh/cvs-helper.)

Up to the part that eject -lcurl from the main "git" binary cleanly are now in 'next' and is ready for 1.6.5.

* cb/maint-1.6.3-grep-relative-up (2009-09-05) 2 commits.
  (merged to 'next' on 2009-09-07 at f9b5b48)
 + grep: accept relative paths outside current working directory
 + grep: fix exit status if external_grep() punts
1.6.5 material.
* jk/unwanted-advices (2009-09-06) 2 commits
 - status: make "how to stage" messages optional
 - push: make non-fast-forward help message configurable

If I missed the v2 or later that uses 'advice.*" instead, I am sorry, and please let me know. At least the first one should be in 1.6.5, I think, and probably both.

* jt/pushinsteadof (2009-09-07) 2 commits
  (merged to 'next' on 2009-09-11 at cf3eb57)
 + Add url.<base>.pushInsteadOf: URL rewriting for push only
 + Wrap rewrite globals in a struct in preparation for adding another set
Probably 1.6.5 material.
* pk/fast-import-tars (2009-09-03) 1 commit
  (merged to 'next' on 2009-09-07 at 8fbf027)
 + import-tars: Allow per-tar author and commit message.
* pk/fast-import-dirs (2009-09-03) 1 commit
  (merged to 'next' on 2009-09-07 at 836cba2)
 + Add script for importing bits-and-pieces to Git.

I have to wonder if there are standard libraries to do this sort of thing without having to hand-roll these logic every time, but I decided not to be picky about contrib/ material. Both will be in 1.6.5

* jc/maint-1.6.0-blank-at-eof (2009-09-05) 10 commits.
  (merged to 'next' on 2009-09-07 at 165dc3c)

Possibly a 1.6.5 material, but it started rather late in the cycle so we might want to cook it for a while in 'next' and do 1.6.5 without it.

* sr/gfi-options (2009-09-06) 6 commits
  (merged to 'next' on 2009-09-07 at 5f6b0ff)
 + fast-import: test the new option command
 + fast-import: add option command
 + fast-import: test the new feature command
 + fast-import: add feature command
 + fast-import: put marks reading in it's own function
 + fast-import: put option parsing code in separate functions

Perhaps 1.6.5 material but I wasn't sure. I saw Sverre asking Shawn for opinion but I may have missed the response.

* lt/maint-traverse-trees-fix (2009-09-06) 1 commit.
 - Prepare 'traverse_trees()' for D/F conflict lookahead

Beginning of the fix to a rather nasty longstanding issue of merging trees with ("a" "a-b"), ("a/b" "a-b") and just ("a-b"), but my reading of it is that it is just the first step to demonstrate one-entry lookahead and not a full solution yet.

This is a good problem to tackle but the bug has been there from the beginning of unpack_trees(), i.e. lacks urgency, and the full solution is expected to be much larger. I am tempted to say that 1.6.5 shouldn't wait for this series.

Junio C Hamano· Sep 12, 2009, 04:38 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)

Junio C Hamano <gitster@pobox.com> writes:
Show 6 quoted lines
> * jk/unwanted-advices (2009-09-06) 2 commits
>  - status: make "how to stage" messages optional
>  - push: make non-fast-forward help message configurable
>
> If I missed the v2 or later that uses 'advice.*" instead, I am sorry, and
> please let me know.
Found them; thanks.
Sverre Rabbelier· Sep 12, 2009, 11:46 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)

Heya,
On Sat, Sep 12, 2009 at 02:33, Junio C Hamano <gitster@pobox.com> wrote:
Show 11 quoted lines
> * sr/gfi-options (2009-09-06) 6 commits
>  (merged to 'next' on 2009-09-07 at 5f6b0ff)
>  + fast-import: test the new option command
>  + fast-import: add option command
>  + fast-import: test the new feature command
>  + fast-import: add feature command
>  + fast-import: put marks reading in it's own function
>  + fast-import: put option parsing code in separate functions
>
> Perhaps 1.6.5 material but I wasn't sure.  I saw Sverre asking Shawn for
> opinion but I may have missed the response.
No response from Shawn so far, I assume he's short on Git budget :).
-- 
Cheers,

Sverre Rabbelier

← back to recent threads