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

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

[Junio C Hamano]

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

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

[Nanako Shiraishi]

Quoting Junio C Hamano <gitster@pobox.com>

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

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

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

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

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

[Jakub Narebski]

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.

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

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

[Sverre Rabbelier]

Heya,

On Tue, Sep 8, 2009 at 02:56, Junio C Hamano<gitster@pobox.com> wrote:
> * 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

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

[Jeff King]

On Mon, Sep 07, 2009 at 05:56:53PM -0700, Junio C Hamano wrote:

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

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

[Daniel Barkalow]

On Mon, 7 Sep 2009, Junio C Hamano wrote:

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

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

[Johannes Schindelin]

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

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

[Daniel Barkalow]

On Thu, 10 Sep 2009, Johannes Schindelin wrote:

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

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

[Junio C Hamano]

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.

scissors definition and documentation

[Nicolas Sebrecht]

The 07/09/09, Junio C Hamano wrote:
> 
> * 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(-)

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

[Nicolas Sebrecht]

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

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

[Nicolas Sebrecht]

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

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

[Nicolas Sebrecht]

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

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

[Junio C Hamano]

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.

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

[Nicolas Sebrecht]

[ Thank you for this review. ]

The 11/09/09, Junio C Hamano wrote:
> 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

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

[Junio C Hamano]

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

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

[Nicolas Sebrecht]

The 11/09/09, Junio C Hamano wrote:
> 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

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

[Nicolas Sebrecht]

The 11/09/09, Junio C Hamano wrote:
> 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

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

[Junio C Hamano]

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.

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

[Junio C Hamano]

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.

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

[Nicolas Sebrecht]

[ Thank you (again) for this very good explanation. ]

The 11/09/09, Junio C Hamano wrote:
> 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.

> 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

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

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

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

[Sverre Rabbelier]

Heya,

On Sat, Sep 12, 2009 at 02:33, Junio C Hamano <gitster@pobox.com> wrote:
> * 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