What's cooking in git.git (Aug 2011, #03; Thu, 11)

What's cooking in git.git (Aug 2011, #03; Thu, 11)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.

I am envisioning that we would declare feature freeze after most of the
topics that are in 'next' as of today graduate to 'master' for the next
release, and keep the remainder cooking for the cycle after that. Hopefully
that would happen around 24th.

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

* di/fast-import-ident (2011-08-11) 5 commits
 - fsck: improve committer/author check
 - fsck: add a few committer name tests
 - fast-import: check committer name more strictly
 - fast-import: don't fail on omitted committer name
 - fast-import: add input format tests

* fg/submodule-ff-check-before-push (2011-08-09) 1 commit
 - push: Don't push a repository with unpushed submodules

* hv/submodule-update-none (2011-08-11) 2 commits
 - add update 'none' flag to disable update of submodule by default
 - submodule: move update configuration variable further up

* jc/lookup-object-hash (2011-08-11) 6 commits
 - object hash: replace linear probing with 4-way cuckoo hashing
 - object hash: we know the table size is a power of two
 - object hash: next_size() helper for readability
 - pack-objects --count-only
 - object.c: remove duplicated code for object hashing
 - object.c: code movement for readability

* js/i18n-scripts (2011-08-08) 5 commits
 - submodule: take advantage of gettextln and eval_gettextln.
 - stash: take advantage of eval_gettextln
 - pull: take advantage of eval_gettextln
 - git-am: take advantage of gettextln and eval_gettextln.
 - gettext: add gettextln, eval_gettextln to encode common idiom

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

* cb/partial-commit-relative-pathspec (2011-08-02) 1 commit
  (merged to 'next' on 2011-08-03 at 6918f69)
 + commit: allow partial commits with relative paths

Ideally the pathspec-prefix helper should be renamed to something more
sensible, but we could live with it for now.

* ef/ipv4-connect-error-report (2011-08-01) 2 commits
  (merged to 'next' on 2011-08-03 at ea4842b)
 + connect: only log if all attempts failed (ipv4)
 + Merge branch 'maint' into ef/ipv4-connect-error-report

* jk/fast-export-quote-path (2011-08-05) 1 commit
  (merged to 'next' on 2011-08-05 at a80e5f5)
 + fast-export: quote paths in output

* rc/maint-http-wrong-free (2011-08-03) 2 commits
  (merged to 'next' on 2011-08-05 at cea08ed)
 + Makefile: some changes for http-related flag documentation
 + http.c: fix an invalid free()

* rs/grep-function-context (2011-08-01) 2 commits
  (merged to 'next' on 2011-08-05 at 8d63a8c)
 + grep: long context options
 + grep: add option to show whole function as context

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

* jc/merge-reword (2011-05-25) 2 commits
 - merge: mark the final "Merge made by..." message for l10n
 - merge: reword the final message

Probably the topmost commit should be dropped.

* nk/branch-v-abbrev (2011-07-01) 1 commit
 - branch -v: honor core.abbrev

Perhaps needs an updated commit log message?

* di/fast-import-doc (2011-07-13) 2 commits
 - doc/fast-import: document feature import-marks-if-exists
 - doc/fast-import: clarify notemodify command

Comments from fast-import folks?

* jh/receive-count-limit (2011-05-23) 10 commits
 - receive-pack: Allow server to refuse pushes with too many objects
 - pack-objects: Estimate pack size; abort early if pack size limit is exceeded
 - send-pack/receive-pack: Allow server to refuse pushing too large packs
 - pack-objects: Allow --max-pack-size to be used together with --stdout
 - send-pack/receive-pack: Allow server to refuse pushes with too many commits
 - pack-objects: Teach new option --max-commit-count, limiting #commits in pack
 - receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
 - Tighten rules for matching server capabilities in server_supports()
 - send-pack: Attempt to retrieve remote status even if pack-objects fails
 - Update technical docs to reflect side-band-64k capability in receive-pack

Would need another round to separate per-pack and per-session limits.

* jm/mergetool-pathspec (2011-06-22) 2 commits
 - mergetool: Don't assume paths are unmerged
 - mergetool: Add tests for filename with whitespace

I think this is a good idea, but it probably needs a re-roll.
Cf. $gmane/176254, 176255, 166256

* jk/generation-numbers (2011-07-14) 7 commits
 - limit "contains" traversals based on commit generation
 - check commit generation cache validity against grafts
 - pretty: support %G to show the generation number of a commit
 - commit: add commit_generation function
 - add metadata-cache infrastructure
 - decorate: allow storing values instead of pointers
 - Merge branch 'jk/tag-contains-ab' (early part) into HEAD

The initial "tag --contains" de-pessimization without need for generation
numbers is already in; backburnered.

* en/merge-recursive (2011-08-04) 49 commits
 - t3030: fix accidental success in symlink rename
 - merge-recursive: Fix working copy handling for rename/rename/add/add
 - merge-recursive: add handling for rename/rename/add-dest/add-dest
 - merge-recursive: Have conflict_rename_delete reuse modify/delete code
 - merge-recursive: Make modify/delete handling code reusable
 - merge-recursive: Consider modifications in rename/rename(2to1) conflicts
 - merge-recursive: Create function for merging with branchname:file markers
 - merge-recursive: Record more data needed for merging with dual renames
 - merge-recursive: Defer rename/rename(2to1) handling until process_entry
 - merge-recursive: Small cleanups for conflict_rename_rename_1to2
 - merge-recursive: Fix rename/rename(1to2) resolution for virtual merge base
 - merge-recursive: Introduce a merge_file convenience function
 - merge-recursive: Fix modify/delete resolution in the recursive case
 - merge-recursive: Provide more info in conflict markers with file renames
 - merge-recursive: Cleanup and consolidation of rename_conflict_info
 - merge-recursive: Consolidate process_entry() and process_df_entry()
 - merge-recursive: Improve handling of rename target vs. directory addition
 - merge-recursive: Add comments about handling rename/add-source cases
 - merge-recursive: Make dead code for rename/rename(2to1) conflicts undead
 - merge-recursive: Fix deletion of untracked file in rename/delete conflicts
 - merge-recursive: When we detect we can skip an update, actually skip it
 - merge-recursive: Split update_stages_and_entry; only update stages at end
 - merge-recursive: Consolidate different update_stages functions
 - merge-recursive: Allow make_room_for_path() to remove D/F entries
 - merge-recursive: Split was_tracked() out of would_lose_untracked()
 - merge-recursive: Save D/F conflict filenames instead of unlinking them
 - merge-recursive: Fix code checking for D/F conflicts still being present
 - merge-recursive: Fix sorting order and directory change assumptions
 - merge-recursive: Fix recursive case with D/F conflict via add/add conflict
 - merge-recursive: Avoid working directory changes during recursive case
 - merge-recursive: Remember to free generated unique path names
 - merge-recursive: Mark some diff_filespec struct arguments const
 - merge-recursive: Correct a comment
 - merge-recursive: Make BUG message more legible by adding a newline
 - t6022: Add testcase for merging a renamed file with a simple change
 - t6022: New tests checking for unnecessary updates of files
 - t6022: Remove unnecessary untracked files to make test cleaner
 - t6036: criss-cross + rename/rename(1to2)/add-source + modify/modify
 - t6036: criss-cross w/ rename/rename(1to2)/modify+rename/rename(2to1)/modify
 - t6036: tests for criss-cross merges with various directory/file conflicts
 - t6036: criss-cross with weird content can fool git into clean merge
 - t6036: Add differently resolved modify/delete conflict in criss-cross test
 - t6042: Ensure rename/rename conflicts leave index and workdir in sane state
 - t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts
 - t6042: Add tests for content issues with modify/rename/directory conflicts
 - t6042: Add a testcase where undetected rename causes silent file deletion
 - t6042: Add a pair of cases where undetected renames cause issues
 - t6042: Add failing testcase for rename/modify/add-source conflict
 - t6042: Add a testcase where git deletes an untracked file

Re-roll being worked on.

* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
 - t5800: point out that deleting branches does not work
 - t5800: document inability to push new branch with old content

* po/cygwin-backslash (2011-08-05) 2 commits
 - On Cygwin support both UNIX and DOS style path-names
 - git-compat-util: add generic find_last_dir_sep that respects is_dir_sep

I think a further refactoring (no, not my suggestion) was offered?

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

* cb/maint-ls-files-error-report (2011-08-11) 1 commit
 - ls-files: fix pathspec display on error

Will merge to "next".

* ac/describe-dirty-refresh (2011-08-11) 1 commit
 - describe: Refresh the index when run with --dirty

Will merge to "next".

* jc/maint-combined-diff-work-tree (2011-08-04) 1 commit
  (merged to 'next' on 2011-08-05 at 976a4d4)
 + diff -c/--cc: do not mistake "resolved as deletion" as "use working tree"

Will merge to "master" after cooking for a bit more.

* js/sh-style (2011-08-05) 2 commits
  (merged to 'next' on 2011-08-11 at 4a4c22c)
 + filter-branch.sh: de-dent usage string
 + misc-sh: fix up whitespace in some other .sh files.

* ma/am-exclude (2011-08-09) 2 commits
  (merged to 'next' on 2011-08-11 at cf0ba4d)
 + am: Document new --exclude=<path> option
  (merged to 'next' on 2011-08-05 at 658e57c)
 + am: pass exclude down to apply

Will merge to "master" after cooking for a bit more.

* db/am-skip-blank-at-the-beginning (2011-08-11) 1 commit
  (merged to 'next' on 2011-08-11 at 3637843)
 + am: ignore leading whitespace before patch

Will merge to "master" after cooking for a bit more.

* jc/maint-smart-http-race-upload-pack (2011-08-08) 1 commit
  (merged to 'next' on 2011-08-11 at 3f24b64)
 + helping smart-http/stateless-rpc fetch race

* jn/maint-test-return (2011-08-11) 3 commits
 - t3900: do not reference numbered arguments from the test script
 - test: cope better with use of return for errors
 - test: simplify return value of test_run_

Will merge to "next".

* rt/zlib-smaller-window (2011-08-11) 2 commits
 - test: consolidate definition of $LF
 - Tolerate zlib deflation with window size < 32Kb

Will merge to "next".

* fg/submodule-git-file-git-dir (2011-08-08) 3 commits
 - Move git-dir for submodules
 - fixup! rev-parse: add option --is-well-formed-git-dir
 - rev-parse: add option --is-well-formed-git-dir <path>

* js/bisect-no-checkout (2011-08-09) 11 commits
  (merged to 'next' on 2011-08-11 at 6c94a45)
 + bisect: add support for bisecting bare repositories
 + bisect: further style nitpicks
 + bisect: replace "; then" with "\n<tab>*then"
 + bisect: cleanup whitespace errors in git-bisect.sh.
 + bisect: add documentation for --no-checkout option.
 + bisect: add tests for the --no-checkout option.
 + bisect: introduce --no-checkout support into porcelain.
 + bisect: introduce support for --no-checkout option.
 + bisect: add tests to document expected behaviour in presence of broken trees.
 + bisect: use && to connect statements that are deferred with eval.
 + bisect: move argument parsing before state modification.

* cb/maint-exec-error-report (2011-08-01) 2 commits
  (merged to 'next' on 2011-08-05 at 2764424)
 + notice error exit from pager
 + error_routine: use parent's stderr if exec fails

Will merge to "master" after cooking for a bit more.

* cb/maint-quiet-push (2011-08-08) 2 commits
  (merged to 'next' on 2011-08-08 at 917d73b)
 + receive-pack: do not overstep command line argument array
  (merged to 'next' on 2011-08-01 at 87df938)
 + propagate --quiet to send-pack/receive-pack

Will merge to "master" after cooking for a bit more.

* jk/add-i-hunk-filter (2011-07-27) 5 commits
  (merged to 'next' on 2011-08-11 at 8ff9a56)
 + add--interactive: add option to autosplit hunks
 + add--interactive: allow negatation of hunk filters
 + add--interactive: allow hunk filtering on command line
 + add--interactive: factor out regex error handling
 + add--interactive: refactor patch mode argument processing

* mh/check-attr-listing (2011-08-04) 23 commits
  (merged to 'next' on 2011-08-11 at f73ad50)
 + Rename git_checkattr() to git_check_attr()
 + git-check-attr: Fix command-line handling to match docs
 + git-check-attr: Drive two tests using the same raw data
 + git-check-attr: Add an --all option to show all attributes
 + git-check-attr: Error out if no pathnames are specified
 + git-check-attr: Process command-line args more systematically
 + git-check-attr: Handle each error separately
 + git-check-attr: Extract a function error_with_usage()
 + git-check-attr: Introduce a new variable
 + git-check-attr: Extract a function output_attr()
 + Allow querying all attributes on a file
 + Remove redundant check
 + Remove redundant call to bootstrap_attr_stack()
 + Extract a function collect_all_attrs()
 + Teach prepare_attr_stack() to figure out dirlen itself
 + git-check-attr: Use git_attr_name()
 + Provide access to the name attribute of git_attr
 + git-check-attr: Add tests of command-line parsing
 + git-check-attr: Add missing "&&"
 + Disallow the empty string as an attribute name
 + Remove anachronism from comment
 + doc: Correct git_attr() calls in example code
 + doc: Add a link from gitattributes(5) to git-check-attr(1)
 (this branch is used by mh/check-attr-relative.)

* mh/check-attr-relative (2011-08-04) 6 commits
  (merged to 'next' on 2011-08-11 at f94550c)
 + test-path-utils: Add subcommand "prefix_path"
 + test-path-utils: Add subcommand "absolute_path"
 + git-check-attr: Normalize paths
 + git-check-attr: Demonstrate problems with relative paths
 + git-check-attr: Demonstrate problems with unnormalized paths
 + git-check-attr: test that no output is written to stderr
 (this branch uses mh/check-attr-listing.)

* jk/http-auth-keyring (2011-08-03) 13 commits
  (merged to 'next' on 2011-08-03 at b06e80e)
 + credentials: add "getpass" helper
 + credentials: add "store" helper
 + credentials: add "cache" helper
 + docs: end-user documentation for the credential subsystem
 + http: use hostname in credential description
 + allow the user to configure credential helpers
 + look for credentials in config before prompting
 + http: use credential API to get passwords
 + introduce credentials API
 + http: retry authentication failures for all http requests
 + remote-curl: don't retry auth failures with dumb protocol
 + improve httpd auth tests
 + url: decode buffers that are not NUL-terminated

Looked mostly reasonable except for the limitation that it is not clear
how to deal with a site at which a user needs to use different passwords 
for different repositories.

* js/ref-namespaces (2011-07-21) 5 commits
  (merged to 'next' on 2011-07-25 at 5b7dcfe)
 + ref namespaces: tests
 + ref namespaces: documentation
 + ref namespaces: Support remote repositories via upload-pack and receive-pack
 + ref namespaces: infrastructure
 + Fix prefix handling in ref iteration functions

* rc/histogram-diff (2011-08-08) 12 commits
  (merged to 'next' on 2011-08-11 at 684dfd1)
 + xdiff/xhistogram: drop need for additional variable
 + xdiff/xhistogram: rely on xdl_trim_ends()
 + xdiff/xhistogram: rework handling of recursed results
 + xdiff: do away with xdl_mmfile_next()
  (merged to 'next' on 2011-08-03 at f9e2328)
 + Make test number unique
  (merged to 'next' on 2011-07-25 at 3351028)
 + xdiff/xprepare: use a smaller sample size for histogram diff
 + xdiff/xprepare: skip classification
 + teach --histogram to diff
 + t4033-diff-patience: factor out tests
 + xdiff/xpatience: factor out fall-back-diff function
 + xdiff/xprepare: refactor abort cleanups
 + xdiff/xprepare: use memset()

* rr/revert-cherry-pick-continue (2011-08-08) 18 commits
 - revert: Propagate errors upwards from do_pick_commit
 - revert: Introduce --continue to continue the operation
 - revert: Don't implicitly stomp pending sequencer operation
 - revert: Remove sequencer state when no commits are pending
 - reset: Make reset remove the sequencer state
 - revert: Introduce --reset to remove sequencer state
 - revert: Make pick_commits functionally act on a commit list
 - revert: Save command-line options for continuing operation
 - revert: Save data for continuing after conflict resolution
 - revert: Don't create invalid replay_opts in parse_args
 - revert: Separate cmdline parsing from functional code
 - revert: Introduce struct to keep command-line options
 - revert: Eliminate global "commit" variable
 - revert: Rename no_replay to record_origin
 - revert: Don't check lone argument in get_encoding
 - revert: Simplify and inline add_message_to_msg
 - config: Introduce functions to write non-standard file
 - advice: Introduce error_resolve_conflict

Will merge to "next".

Re: What's cooking in git.git (Aug 2011, #03; Thu, 11) : Guidance for new contributors?

[Philip Oakley]

From: "Junio C Hamano" <gitster@pobox.com>
Subject: What's cooking in git.git (Aug 2011, #03; Thu, 11)

> Here are the topics that have been cooking.  Commits prefixed with '-' are
> only in 'pu' while commits prefixed with '+' are in 'next'.
>
> I am envisioning that we would declare feature freeze after most of the
> topics that are in 'next' as of today graduate to 'master' for the next
> release, and keep the remainder cooking for the cycle after that. 
> Hopefully
> that would happen around 24th.
>

Would it it be possible to include a regular link to an explanation for new 
contributors? It would guide and encourage any new readers of the list.
Would this one be suitable?

+ Guidance for contributions at 
https://git.wiki.kernel.org/index.php/GitCommunity#Submitting

> --------------------------------------------------
> [New Topics]
> ....

Philip Oakley
Scotland UK. 

Re: What's cooking in git.git (Aug 2011, #03; Thu, 11) : Guidance for new contributors?

[Junio C Hamano]

"Philip Oakley" <philipoakley@iee.org> writes:

> Would it it be possible to include a regular link to an explanation
> for new contributors?

After each release from the 'master' branch I try to send out a copy of

  http://git-blame.blogspot.com/p/note-from-maintainer.html

to the list, which is meant to be that piece of information.

Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)

[Ramkumar Ramachandra]

Hi Junio,

Junio C Hamano writes:
> I am envisioning that we would declare feature freeze after most of the
> topics that are in 'next' as of today graduate to 'master' for the next
> release, and keep the remainder cooking for the cycle after that. Hopefully
> that would happen around 24th.

> * rr/revert-cherry-pick-continue (2011-08-08) 18 commits
> [...]
> Will merge to "next".

If this won't graduate to 'next' before the 24th, I have plenty of
time to re-roll fixing all the issues that I've addressed in the
beginning of the new series.  Depending on what you'd prefer, I can:
0. Do nothing.  Get this series merged, and get the fresh series
merged as originally planned.
1. Squash the first few patches in the new series into this series and
post a re-roll.  The new series will then be left with just two
commits.
2. Post a new series that combines both.  I won't introduce any new
code, so no fresh review will be required.  Since both the series have
been reviewed and tested independently, I don't see why this shouldn't
be possible.

Do let me know what you'd like.  Thanks.

-- Ram

Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

>> * rr/revert-cherry-pick-continue (2011-08-08) 18 commits
>> [...]
>> Will merge to "next".
>
> If this won't graduate to 'next' before the 24th, I have plenty of
> time to re-roll fixing all the issues that I've addressed in the
> beginning of the new series.

I take it that you mean by "the new series" the 6-patch "Towards a
generalized sequencer" topic?

It is ultimately up-to-you. If you feel the fix-up is against glaring
errors in the earlier round that you would prefer not to see in the
history cast-in-stone, I am perfectly Ok to wait for a re-roll. On the
other hand, if they are mostly cosmetic fixes without major semantic
changes, it may be easier for everybody to see them fixed in-tree.

Your call.

Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)

[Ramkumar Ramachandra]

Hi Junio,

Junio C Hamano writes:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>>> * rr/revert-cherry-pick-continue (2011-08-08) 18 commits
>>> [...]
>>> Will merge to "next".
>>
>> If this won't graduate to 'next' before the 24th, I have plenty of
>> time to re-roll fixing all the issues that I've addressed in the
>> beginning of the new series.
>
> I take it that you mean by "the new series" the 6-patch "Towards a
> generalized sequencer" topic?

Yes.

> It is ultimately up-to-you. If you feel the fix-up is against glaring
> errors in the earlier round that you would prefer not to see in the
> history cast-in-stone, I am perfectly Ok to wait for a re-roll. On the
> other hand, if they are mostly cosmetic fixes without major semantic
> changes, it may be easier for everybody to see them fixed in-tree.

Hm, I didn't think they were glaring errors.  After reading your
latest review about my '--continue' patch in the generalized
sequencer, I've decided not to re-roll.  Please merge
'rr/revert-cherry-pick-continue' into 'next' as usual.  It'll take me
some more time to think about my "generalized sequencer" series.

Thanks.

-- Ram

Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)

[Pascal Obry]

Junio,

> * po/cygwin-backslash (2011-08-05) 2 commits
>   - On Cygwin support both UNIX and DOS style path-names
>   - git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
>
> I think a further refactoring (no, not my suggestion) was offered?

I think the current patchset is fine. It is always possible to improve 
things but the current patch goes in the right direction. So to me it is 
ready as-is.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)

[Junio C Hamano]

Pascal Obry <pascal@obry.net> writes:

> Junio,
>
>> * po/cygwin-backslash (2011-08-05) 2 commits
>>   - On Cygwin support both UNIX and DOS style path-names
>>   - git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
>>
>> I think a further refactoring (no, not my suggestion) was offered?
>
> I think the current patchset is fine. It is always possible to improve
> things but the current patch goes in the right direction. So to me it
> is ready as-is.

Not very assuring to hear that only from the original submitter, no?

Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)

[Ramsay Jones]

Junio C Hamano wrote:
> Pascal Obry <pascal@obry.net> writes:
> 
>> Junio,
>>
>>> * po/cygwin-backslash (2011-08-05) 2 commits
>>>   - On Cygwin support both UNIX and DOS style path-names
>>>   - git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
>>>
>>> I think a further refactoring (no, not my suggestion) was offered?
>> I think the current patchset is fine. It is always possible to improve
>> things but the current patch goes in the right direction. So to me it
>> is ready as-is.
> 
> Not very assuring to hear that only from the original submitter, no?

Commit 704c335 (On Cygwin support both UNIX and DOS style path-names,
05-08-2011) in pu needs an update to fix the commit message.

Also, I didn't see any response to Johannes Sixt's query concerning
backslash in pathspec. (I personally don't want to go down that
route, but ...)

ATB,
Ramsay Jones

Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)

[Junio C Hamano]

Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:

> Commit 704c335 (On Cygwin support both UNIX and DOS style path-names,
> 05-08-2011) in pu needs an update to fix the commit message.

Thanks for a reminder, Ramsay.

Here is the exchange where fixing the commit log was mentioned.

    From: Pascal Obry <pascal@obry.net>
    Subject: Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
    To: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
    Cc: git@vger.kernel.org
    Date: Sat, 13 Aug 2011 19:34:37 +0200
    Message-ID: <4E46B5AD.5050806@obry.net>

    Le 11/08/2011 22:35, Ramsay Jones a écrit :
    >   ... could you please correct your commit message. Thanks!

    Done, thanks for your review.

> Also, I didn't see any response to Johannes Sixt's query concerning
> backslash in pathspec. (I personally don't want to go down that
> route, but ...)

Here is what J6t said in the message:

  From: Johannes Sixt <j6t@kdbg.org>
  Subject: Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
  Date: Tue, 09 Aug 2011 21:47:15 +0200
  Message-ID: <4E418EC3.4070904@kdbg.org>

  > Do you also want to support this:
  >      $ git add src\file.c
  > i.e., backslash in pathspec? Then you need more than this:
  > > +#define has_dos_drive_prefix(path) (isalpha(*(path)) && (path)[1] == ':')
  > > +#define is_dir_sep(c) ((c) == '/' || (c) == '\\')
  >
  > In particular, you have to enable backslash processing in
  > setup.c:prefix_filename(), but then you lose the ability to escape
  > special characters with the backslash.

When "git add src\file.c" is given from the command line, what does our
main() see in argv[2]? Do cmd.exe and bash give us the same thing? What if
the command line is "git add 'src\*.c'"?

I vaguely recall that on Windows you only get a single parameter string
from the program loader, and arguments are split in the invoked process,
but that is so common that as far as our main() is concerned we can expect
the example command line to give us argc=3 and argv={ "git", "add", "???",
NULL }. What I do not recall is if there is some other magic such as
expanding shell globs and swapping the direction of slashes in strings
involved when this argument processing is done.

You probably _could_ do '\\' -> '/' inside prefix_filename() and
get_pathspec(), but as J6t mentioned, we _do_ handle backslash as a
quoting character, and this is _not_ going to change.

So even if we were to go that route, the user would need to make git see
"src\\file.c" or "src\\*.c" in order to make it turn into "src/file.c" and
"src/*.c" pathspec. If it means that the user needs to type:

	$ git add src\\\\file.c

I would have to say that it would be simpler for them to say

	$ git add src/file.c

even on Cygwin. After all, isn't Cygwin for people who are forced to be on
Windows and miss POSIXy environments?

By the way, Johannes, how does Git for Windows handle pathspecs?

Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)

[Johannes Sixt]

Am 23.08.2011 20:09, schrieb Junio C Hamano:
> Ramsay Jones<ramsay@ramsay1.demon.co.uk>  writes:
>
>> Commit 704c335 (On Cygwin support both UNIX and DOS style path-names,
>> 05-08-2011) in pu needs an update to fix the commit message.
>
> Thanks for a reminder, Ramsay.
>
> Here is the exchange where fixing the commit log was mentioned.
>
>      From: Pascal Obry<pascal@obry.net>
>      Subject: Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
>      To: Ramsay Jones<ramsay@ramsay1.demon.co.uk>
>      Cc: git@vger.kernel.org
>      Date: Sat, 13 Aug 2011 19:34:37 +0200
>      Message-ID:<4E46B5AD.5050806@obry.net>
>
>      Le 11/08/2011 22:35, Ramsay Jones a écrit :
>      >    ... could you please correct your commit message. Thanks!
>
>      Done, thanks for your review.
>
>> Also, I didn't see any response to Johannes Sixt's query concerning
>> backslash in pathspec. (I personally don't want to go down that
>> route, but ...)
>
> Here is what J6t said in the message:
>
>    From: Johannes Sixt<j6t@kdbg.org>
>    Subject: Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
>    Date: Tue, 09 Aug 2011 21:47:15 +0200
>    Message-ID:<4E418EC3.4070904@kdbg.org>
>
>    >  Do you also want to support this:
>    >       $ git add src\file.c
>    >  i.e., backslash in pathspec? Then you need more than this:
>    >  >  +#define has_dos_drive_prefix(path) (isalpha(*(path))&&  (path)[1] == ':')
>    >  >  +#define is_dir_sep(c) ((c) == '/' || (c) == '\\')
>    >
>    >  In particular, you have to enable backslash processing in
>    >  setup.c:prefix_filename(), but then you lose the ability to escape
>    >  special characters with the backslash.
>
> When "git add src\file.c" is given from the command line, what does our
> main() see in argv[2]? Do cmd.exe and bash give us the same thing? What if
> the command line is "git add 'src\*.c'"?

Our main() sees the string as given on the command line, i.e., with the 
backslash.

> I vaguely recall that on Windows you only get a single parameter string
> from the program loader, and arguments are split in the invoked process,
> but that is so common that as far as our main() is concerned we can expect
> the example command line to give us argc=3 and argv={ "git", "add", "???",
> NULL }. What I do not recall is if there is some other magic such as
> expanding shell globs and swapping the direction of slashes in strings
> involved when this argument processing is done.

There is a linker option whether shell globs should be expanded or not 
before they are passed to main(). If the option is enabled, the expansion 
is different from the way mandated by POSIX.

There was a proposal recently (on the msysgit list?) that this option 
should be disabled, and any expansion of pathspec (globs) should be done 
entirely by git's own expansion rules, which includes automatic recursive 
matching. As a result, git would behave differently on Windows and Unix, 
but since it already does when the linker option is enabled, we argue that 
git's rules are superior (and Windows's linker option is inferior), we 
better should go the proposed new route.

> You probably _could_ do '\\' ->  '/' inside prefix_filename() and
> get_pathspec(), but as J6t mentioned, we _do_ handle backslash as a
> quoting character, and this is _not_ going to change.

... not going to change on platforms where this already works. It does not 
work on Windows.

> So even if we were to go that route, the user would need to make git see
> "src\\file.c" or "src\\*.c" in order to make it turn into "src/file.c" and
> "src/*.c" pathspec. If it means that the user needs to type:
>
> 	$ git add src\\\\file.c
>
> I would have to say that it would be simpler for them to say
>
> 	$ git add src/file.c
>
> even on Cygwin. After all, isn't Cygwin for people who are forced to be on
> Windows and miss POSIXy environments?
>
> By the way, Johannes, how does Git for Windows handle pathspecs?

On Windows, prefix_filename() and prefix_path() (the latter via 
normalize_path_copy()) transform any backslashes to forward-slashes. 
Therefore, if you have src\*.c on the command line, it is processed as 
src/*.c. That is, if \ was meant to escape the *, then this would not 
work. It does not help to duplicate backslashes, because all of them are 
transformed to forward-slashes before git's glob expansion kicks in.

-- Hannes

Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)

[Pascal Obry]

Junio,

> Not very assuring to hear that only from the original submitter, no?

Your call, I think I'm not bias on what I said though.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B