What's cooking in git.git (Mar 2010, #04; Tue, 16)

What's cooking in git.git (Mar 2010, #04; Tue, 16)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.  The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.

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

* sd/format-patch-to (2010-03-07) 4 commits
  (merged to 'next' on 2010-03-08 at 739b8cd)
 + send-email: add --no-cc, --no-to, and --no-bcc
 + format-patch: add --no-cc, --no-to, and --no-add-headers
 + format-patch: use a string_list for headers
  (merged to 'next' on 2010-03-07 at ef7a18d)
 + Add 'git format-patch --to=' option and 'format.to' configuration variable.

* ld/push-porcelain (2010-03-11) 5 commits
  (merged to 'next' on 2010-03-11 at c6dea6a)
 + t5516: Use test_cmp when appropriate
  (merged to 'next' on 2010-03-02 at d15bb1e)
 + git-push: add tests for git push --porcelain
 + git-push: make git push --porcelain print "Done"
 + git-push: send "To <remoteurl>" messages to the standard output in --porcelain mode
 + git-push: fix an advice message so it goes to stderr

* tc/http-cleanup (2010-03-02) 7 commits
  (merged to 'next' on 2010-03-07 at e92db25)
 + remote-curl: init walker only when needed
 + remote-curl: use http_fetch_ref() instead of walker wrapper
 + http: init and cleanup separately from http-walker
 + http-walker: cleanup more thoroughly
 + http-push: remove "|| 1" to enable verbose check
 + t554[01]-http-push: refactor, add non-ff tests
 + t5541-http-push: check that ref is unchanged for non-ff test

* tc/transport-verbosity (2010-02-24) 10 commits
  (merged to 'next' on 2010-03-07 at 898d6dd)
 + transport: update flags to be in running order
 + fetch and pull: learn --progress
 + push: learn --progress
 + transport->progress: use flag authoritatively
 + clone: support multiple levels of verbosity
 + push: support multiple levels of verbosity
 + fetch: refactor verbosity option handling into transport.[ch]
 + Documentation/git-push: put --quiet before --verbose
 + Documentation/git-pull: put verbosity options before merge/fetch ones
 + Documentation/git-clone: mention progress in -v

* jh/notes (2010-03-04) 33 commits
  (merged to 'next' on 2010-03-04 at 3bb921f)
 + Documentation: fix a few typos in git-notes.txt
  (merged to 'next' on 2010-02-24 at c88263d)
 + notes: fix malformed tree entry
 + builtin-notes: Minor (mostly parse_options-related) fixes
  (merged to 'next' on 2010-02-21 at 75fc451)
 + builtin-notes: Add "copy" subcommand for copying notes between objects
 + builtin-notes: Misc. refactoring of argc and exit value handling
 + builtin-notes: Add -c/-C options for reusing notes
 + builtin-notes: Refactor handling of -F option to allow combining -m and -F
 + builtin-notes: Deprecate the -m/-F options for "git notes edit"
 + builtin-notes: Add "append" subcommand for appending to note objects
 + builtin-notes: Add "add" subcommand for adding notes to objects
 + builtin-notes: Add --message/--file aliases for -m/-F options
 + builtin-notes: Add "list" subcommand for listing note objects
 + Documentation: Generalize git-notes docs to 'objects' instead of 'commits'
 + builtin-notes: Add "prune" subcommand for removing notes for missing objects
 + Notes API: prune_notes(): Prune notes that belong to non-existing objects
 + t3305: Verify that removing notes triggers automatic fanout consolidation
 + builtin-notes: Add "remove" subcommand for removing existing notes
 + Teach builtin-notes to remove empty notes
 + Teach notes code to properly preserve non-notes in the notes tree
 + t3305: Verify that adding many notes with git-notes triggers increased fanout
 + t3301: Verify successful annotation of non-commits
 + Builtin-ify git-notes
 + Refactor notes concatenation into a flexible interface for combining notes
 + Notes API: Allow multiple concurrent notes trees with new struct notes_tree
 + Notes API: write_notes_tree(): Store the notes tree in the database
 + Notes API: for_each_note(): Traverse the entire notes tree with a callback
 + Notes API: get_note(): Return the note annotating the given object
 + Notes API: remove_note(): Remove note objects from the notes tree structure
 + Notes API: add_note(): Add note objects to the internal notes tree structure
 + Notes API: init_notes(): Initialize the notes tree from the given notes ref
 + Add tests for checking correct handling of $GIT_NOTES_REF and core.notesRef
 + Notes API: get_commit_notes() -> format_note() + remove the commit restriction
 + Minor cosmetic fixes to notes.c
 (this branch shares commits with sb/notes-parse-opt and tr/notes-display.)

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

* jk/maint-add-ignored-dir (2010-02-28) 3 commits
  (merged to 'next' on 2010-03-13 at df91e32)
 + tests for "git add ignored-dir/file" without -f
 + dir: fix COLLECT_IGNORED on excluded prefixes
 + t0050: mark non-working test as such

This replaces jc/maint-add-ignored-dir.

* do/rebase-i-arbitrary (2010-03-14) 1 commit
 - rebase--interactive: don't require what's rebased to be a branch

* ja/send-email-ehlo (2010-03-14) 3 commits
 - git-send-email.perl - try to give real name of the calling host to HELO/EHLO
 - git-send-email.perl: add option --smtp-debug
 - git-send-email.perl: improve error message in send_message()

* ak/everyday-git (2009-10-21) 1 commit
 - everyday: fsck and gc are not everyday operations

* bc/acl-test (2010-03-15) 5 commits
 - t/t1304: make a second colon optional in the mask ACL check
 - t/t1304: set the ACL effective rights mask
 - t/t1304: use 'test -r' to test readability rather than looking at mode bits
 - t/t1304: set the Default ACL base entries
 - t/t1304: avoid -d option to setfacl

* bc/maint-daemon-sans-ss-family (2010-03-15) 1 commit
 - daemon.c: avoid accessing ss_family member of struct sockaddr_storage

* ef/cherry-abbrev (2010-03-15) 1 commit
 - cherry: support --abbrev option

* gh/maint-stash-show-error-message (2010-03-16) 1 commit
 - Improve error messages from 'git stash show'

* jc/maint-refs-dangling (2010-03-15) 1 commit
  (merged to 'next' on 2010-03-16 at 376027b)
 + refs: ref entry with NULL sha1 is can be a dangling symref

* rs/threaded-grep-context (2010-03-15) 1 commit
 - grep: enable threading for context line printing

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

* cw/test-lib-relicense (2010-02-22) 1 commit
 . test-lib.sh: Add explicit license detail, with change from GPLv2 to GPLv2+.

Ack-collection stopped at the last three names.  I am hoping Carl can take
it from there without my keeping an eye on it.

* js/rebase-origin-x (2010-02-05) 1 commit
 - [RFC w/o test and incomplete] rebase: add -x option to record original commit name

I retract my objection against the idea of -x; needs polishing before
moving forward.

* sd/log-decorate (2010-02-17) 3 commits
  (merged to 'next' on 2010-03-08 at 58a6fba)
 + log.decorate: usability fixes
 + Add `log.decorate' configuration variable.
 + git_config_maybe_bool()

Needs squelching the configuration setting when "--pretty=raw" is given,
at least, or possibly when any "--pretty" is explicitly given.

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

* pb/log-first-parent-p-m (2010-03-09) 5 commits
  (merged to 'next' on 2010-03-15 at 0ae494e)
 + show --first-parent/-m: do not default to --cc
 + show -c: show patch text
 + revision: introduce setup_revision_opt
 + t4013: add tests for log -p -m --first-parent
  (merged to 'next' on 2010-02-17 at 2f8e5ae)
 + git log -p -m: document -m and honor --first-parent

* jl/submodule-diff-dirtiness (2010-03-13) 5 commits
  (merged to 'next' on 2010-03-15 at 9601fd9)
 + git status: ignoring untracked files must apply to submodules too
  (merged to 'next' on 2010-03-13 at f9bfd8a)
 + git status: Fix false positive "new commits" output for dirty submodules
 + Refactor dirty submodule detection in diff-lib.c
  (merged to 'next' on 2010-03-08 at 33f7a57)
 + git status: Show detailed dirty status of submodules in long format
  (merged to 'next' on 2010-03-04 at 58b2645)
 + git diff --submodule: Show detailed dirty status of submodules

* cc/cherry-pick-ff (2010-03-06) 7 commits
  (merged to 'next' on 2010-03-07 at 5589b26)
 + rebase -i: use new --ff cherry-pick option
 + cherry-pick: add a no-op --no-ff option to future proof scripts
 + Documentation: describe new cherry-pick --ff option
 + cherry-pick: add tests for new --ff option
 + revert: add --ff option to allow fast forward when cherry-picking
 + builtin/merge: make checkout_fast_forward() non static
 + parse-options: add parse_options_concat() to concat options

I think this is ready for 'master'; comments?

* js/async-thread (2010-03-09) 7 commits
 - Enable threaded async procedures whenever pthreads is available
 - Dying in an async procedure should only exit the thread, not the process.
 - Reimplement async procedures using pthreads
 - Windows: more pthreads functions
 - Fix signature of fcntl() compatibility dummy
 - Make report() from usage.c public as vreportf() and use it.
 - Modernize t5530-upload-pack-error.

The last one is probably unsafe for 'next' until somebody goes and vets
the callees that are invoked via this interface (any possible breakages
are already inflicted on Windows people, though).

* nd/setup (2010-03-08) 21 commits
 - index-pack: use RUN_SETUP_GENTLY
 - index-pack: trust the prefix returned by setup_git_directory_gently()
 - worktree setup: calculate prefix even if no worktree is found
 - merge-file: use RUN_SETUP_GENTLY
 - var: use RUN_SETUP_GENTLY
 - ls-remote: use RUN_SETUP_GENTLY
 - help: use RUN_SETUP_GENTLY
 - diff: use RUN_SETUP_GENTLY
 - bundle: use RUN_SETUP_GENTLY
 - apply: use RUN_SETUP_GENTLY
 - verify-pack: use RUN_SETUP_GENTLY
 - check-ref-format: use RUN_SETUP_GENTLY
 - mailinfo: use RUN_SETUP_GENTLY
 - archive: use RUN_SETUP_GENTLY
 - builtin: USE_PAGER should not be used without RUN_SETUP*
 - grep: use RUN_SETUP_GENTLY
 - shortlog: use RUN_SETUP_GENTLY
 - hash-object: use RUN_SETUP_GENTLY
 - config: use RUN_SETUP_GENTLY
 - builtin: Support RUN_SETUP_GENTLY to set up repository early if found
 - builtin: introduce startup_info struct

* bg/apply-fix-blank-at-eof (2010-03-06) 5 commits
  (merged to 'next' on 2010-03-07 at daec679)
 + t3417: Add test cases for "rebase --whitespace=fix"
 + t4124: Add additional tests of --whitespace=fix
 + apply: Allow blank context lines to match beyond EOF
 + apply: Remove the quick rejection test
 + apply: Don't unnecessarily update line lengths in the preimage

Ready for 'master'.

* sg/bash-completion (2010-02-23) 4 commits
  (merged to 'next' on 2010-03-08 at bc59860)
 + bash: completion for gitk aliases
 + bash: support user-supplied completion scripts for aliases
 + bash: support user-supplied completion scripts for user's git commands
 + bash: improve aliased command recognition

Perhaps rename _git_frotz -> _git_complete_frotz?  I dunno.

* fl/askpass (2010-03-04) 2 commits
  (merged to 'next' on 2010-03-07 at 5ab370a)
 + git-core: Support retrieving passwords with GIT_ASKPASS
 + git-svn: Support retrieving passwords with GIT_ASKPASS

Perhaps ready for 'master'?  I dunno.

* jc/color-attrs (2010-02-27) 1 commit
  (merged to 'next' on 2010-03-08 at ba02883)
 + color: allow multiple attributes

Ready for 'master'.

* ml/color-grep (2010-03-07) 3 commits
  (merged to 'next' on 2010-03-08 at 24d1eb4)
 + grep: Colorize selected, context, and function lines
 + grep: Colorize filename, line number, and separator
 + Add GIT_COLOR_BOLD_* and GIT_COLOR_BG_*

Ready for 'master'.

* sb/notes-parse-opt (2010-02-27) 1 commit
 - notes: rework subcommands and parse options
 (this branch uses tr/notes-display.)

* bw/union-merge-refactor (2010-03-01) 4 commits
  (merged to 'next' on 2010-03-10 at b917078)
 + merge-file: add option to select union merge favor
 + merge-file: add option to specify the marker size
  (merged to 'next' on 2010-03-07 at 9d1eff6)
 + refactor merge flags into xmparam_t
 + make union merge an xdl merge favor

Ready for 'master'.

* jh/maint-submodule-status-in-void (2010-03-09) 2 commits
  (merged to 'next' on 2010-03-15 at 49af9de)
 + git submodule summary: Handle HEAD as argument when on an unborn branch
  (merged to 'next' on 2010-03-08 at 0697bf4)
 + submodule summary: do not fail before the first commit

* tr/notes-display (2010-03-12) 13 commits
  (merged to 'next' on 2010-03-15 at 3329361)
 + git-notes(1): add a section about the meaning of history
 + notes: track whether notes_trees were changed at all
 + notes: add shorthand --ref to override GIT_NOTES_REF
 + commit --amend: copy notes to the new commit
 + rebase: support automatic notes copying
 + notes: implement helpers needed for note copying during rewrite
 + notes: implement 'git notes copy --stdin'
 + rebase -i: invoke post-rewrite hook
 + rebase: invoke post-rewrite hook
 + commit --amend: invoke post-rewrite hook
 + Documentation: document post-rewrite hook
 + Support showing notes from more than one notes tree
 + test-lib: unset GIT_NOTES_REF to stop it from influencing tests
 (this branch is used by sb/notes-parse-opt.)

* cc/reset-keep (2010-03-09) 6 commits
  (merged to 'next' on 2010-03-08 at 015ef4b)
 + Documentation: improve description of "git reset --keep"
  (merged to 'next' on 2010-03-07 at 5237d8e)
 + reset: disallow using --keep when there are unmerged entries
 + reset: disallow "reset --keep" outside a work tree
 + Documentation: reset: describe new "--keep" option
 + reset: add test cases for "--keep" option
 + reset: add option "--keep" to "git reset"

I think this is ready for 'master'.  Comments?

--------------------------------------------------
[Ejected from 'next']

* jc/maint-add-ignored-dir (2010-02-28) 3 commits
  (merged to 'next' on 2010-03-08 at a51762e)
 + builtin-add: fix exclude handling
 + tests for "git add ignored-dir/file" without -f
 + t0050: mark non-working test as such

cc/cherry-pick-ff (Re: What's cooking in git.git (Mar 2010, #04; Tue, 16))

[Jonathan Nieder]

Junio C Hamano wrote:

> * cc/cherry-pick-ff (2010-03-06) 7 commits
>   (merged to 'next' on 2010-03-07 at 5589b26)
>  + rebase -i: use new --ff cherry-pick option
>  + cherry-pick: add a no-op --no-ff option to future proof scripts
>  + Documentation: describe new cherry-pick --ff option
>  + cherry-pick: add tests for new --ff option
>  + revert: add --ff option to allow fast forward when cherry-picking
>  + builtin/merge: make checkout_fast_forward() non static
>  + parse-options: add parse_options_concat() to concat options
> 
> I think this is ready for 'master'; comments?

For what it’s worth, I am not convinced about the --no-ff option.  I do
not think --ff ever will be the default: for an operation that amounts
to applying a patch and making a new commit, it just feels wrong.

On the other hand, I have no objection to --no-ff as an undocumented
feature, to allow scripts using the flag to be backwards compatible.  If
--ff will become the default some day, we could start advertising the
--no-ff option as soon as we know that.  Why worry script authors and
use up space in the manual before then?

Just my two cents,
Jonathan

Re: cc/cherry-pick-ff (Re: What's cooking in git.git (Mar 2010, #04; Tue, 16))

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> For what it’s worth, I am not convinced about the --no-ff option.  I do
> not think --ff ever will be the default: for an operation that amounts
> to applying a patch and making a new commit, it just feels wrong.

Same here ;-) and because of that, --no-ff as an undocumented feature
feels doubly wrong to me.  If some scripts use it, people would wonder
what that no-op option is doing there.  Perhaps we should discard the bits
about --no-ff to make it more clear that --ff is an oddball case that is
meant only for supporting what "rebase-i" (and other tools that reinvent
and enhance it) does.

For the same reasoning, you may have liked the "do not fast-forward the
early part of 'rebase -i' even if the commits are picked literally" patch,
by Marc.

Re: cc/cherry-pick-ff (Re: What's cooking in git.git (Mar 2010, #04; Tue, 16))

[Christian Couder]

On Wednesday 17 March 2010 18:01:53 Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
> > For what it’s worth, I am not convinced about the --no-ff option.  I do
> > not think --ff ever will be the default: for an operation that amounts
> > to applying a patch and making a new commit, it just feels wrong.
> 
> Same here ;-) and because of that, --no-ff as an undocumented feature
> feels doubly wrong to me.  If some scripts use it, people would wonder
> what that no-op option is doing there.  Perhaps we should discard the bits
> about --no-ff to make it more clear that --ff is an oddball case that is
> meant only for supporting what "rebase-i" (and other tools that reinvent
> and enhance it) does.

My opinion is that if we implement "git cherry-pick A..B", and if many people 
start to use it, then perhaps it will make sense for --ff to become the 
default. Because people may not want to have to remember using --ff to avoid 
many spurious commits to be created.

And having --ff and --no-ff makes "git cherry-pick" consistent with "git merge" 
which has both. And --ff is the default for "git merge", so consistency will be 
an argument to make it the default for "git cherry-pick" if "git cherry-pick 
A..B" is used a lot.

Best regards,
Christian.

Re: cc/cherry-pick-ff (Re: What's cooking in git.git (Mar 2010, #04; Tue, 16))

[Paolo Bonzini]

On Thu, Mar 18, 2010 at 01:38, Christian Couder <chriscool@tuxfamily.org> wrote:
> On Wednesday 17 March 2010 18:01:53 Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>> > For what it’s worth, I am not convinced about the --no-ff option.  I do
>> > not think --ff ever will be the default: for an operation that amounts
>> > to applying a patch and making a new commit, it just feels wrong.
>>
>> Same here ;-) and because of that, --no-ff as an undocumented feature
>> feels doubly wrong to me.
>
> My opinion is that if we implement "git cherry-pick A..B", and if many people
> start to use it, then perhaps it will make sense for --ff to become the
> default. Because people may not want to have to remember using --ff to avoid
> many spurious commits to be created.

FWIW, I had a use-case for git cherry-pick yesterday.  I had submitted
many unrelated patches to a project where I am committer (but I still
need reviews before pushing) and placed them on a single branch for
testing.

Almost always the reviews would happen in the order that I sent, but I
wasn't sure so my workflow would be necessarily cherry-pick + test +
push + rebase.  Having the possibility to do an optional fast forward
would limit the need to rebase and thus the time spent for each
cherry-pick+push+rebase.

Paolo

Re: cc/cherry-pick-ff (Re: What's cooking in git.git (Mar 2010, #04; Tue, 16))

[Junio C Hamano]

Christian Couder <chriscool@tuxfamily.org> writes:

> ... if we implement "git cherry-pick A..B", and if many people 
> start to use it, then perhaps it will make sense for --ff to become the 
> default.

That doesn't make any sense to me.

Think why you are saying A..B, with an explicit "A".

It is because you know it is different from HEAD; otherwise you would have
done "git merge B"---slurp all changes between HEAD..B, which would be
equivalent to "cherry-pick --ff HEAD..B".

As an ingredient for use of scripts that do not want to check (even if
they could) if it is dealing with a corner case in which the commit a
change is being applied to happens to be the commit the change in question
is based on, being able to say --ff would make sense (as your patch series
showed, it helped to lose several lines from the rebase-i implementation).
The end user may not bother to count commits, and being able to ff earlier
parts of "rebase -i HEAD~20" when the first "edit" appears after many
"pick" would help (and that was why "rebase -i" internally had ff logic).

But running cherry-pick as the top-level operation is a conscious act of
"I want to replay the change done by that one", and it would be utterly
confusing if it fast-forwarded by default.  I agree with Jonathan that it
will never be default.

Re: cc/cherry-pick-ff

[Jonathan Nieder]

Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:

>> ... if we implement "git cherry-pick A..B", and if many people 
>> start to use it, then perhaps it will make sense for --ff to become the 
>> default.
>
> That doesn't make any sense to me.
> 
> Think why you are saying A..B, with an explicit "A".
> 
> It is because you know it is different from HEAD; otherwise you would have
> done "git merge B"---slurp all changes between HEAD..B, which would be
> equivalent to "cherry-pick --ff HEAD..B".

In a project that is deeply dedicated to a linear history, the workflow
might be something like this:

 contributor:
	hack hack hack
	git commit
	...
	git pull --rebase upstream; # Rebase for submission upstream.
	git push +HEAD:topic

 upstream:
	git pull --cherry-pick contributor1 topic
	git pull --cherry-pick contributor2 other-topic
	...
	run tests
	git push master

Here, “git pull --cherry-pick remote branch” is shorthand for
“git fetch remote branch && git cherry-pick --ff HEAD..FETCH_HEAD”.
It is not always a fast-forward because contributors’ changes can be
based on an out-of-date upstream version.

This imposes all the conflict resolution trouble on upstream and blames
the result on the contributors, which may be what some people want
(especially if upstream and the contributors are all the same person).

> But running cherry-pick as the top-level operation is a conscious act of
> "I want to replay the change done by that one", and it would be utterly
> confusing if it fast-forwarded by default.

All that said, I still agree with this conclusion.  It is only a gut
feeling.  I could be convinced in the future, but I do not want to
impose the imagined work of adding --no-ff to scripts until it is clear
it is the right thing to do.

One way to avoid trouble: add a --no-ff option, but make it mean
“negates any previous --ff option on the same command line”.  This
way, _if_ we decide to ask in the release notes for 1.8 for people to
add --no-ff to their scripts in preparation for 1.9, then they can do
so without breaking compatibility with git 1.7.1 (and without adding a
version check).

Cheers,
Jonathan

Re: cc/cherry-pick-ff (Re: What's cooking in git.git (Mar 2010, #04; Tue, 16))

[Christian Couder]

On Saturday 20 March 2010 15:20:03 Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > ... if we implement "git cherry-pick A..B", and if many people
> > start to use it, then perhaps it will make sense for --ff to become the
> > default.
> 
> That doesn't make any sense to me.
> 
> Think why you are saying A..B, with an explicit "A".
> 
> It is because you know it is different from HEAD; otherwise you would have
> done "git merge B"---slurp all changes between HEAD..B, which would be
> equivalent to "cherry-pick --ff HEAD..B".

I think that some people might avoid "git merge" altogether just because they 
may not be confident with merges and prefer linear histories.

They may also prefer "git cherry-pick A..B" over "git rebase" or "git rebase -
i" because it may be simpler for them to understand.

> As an ingredient for use of scripts that do not want to check (even if
> they could) if it is dealing with a corner case in which the commit a
> change is being applied to happens to be the commit the change in question
> is based on, being able to say --ff would make sense (as your patch series
> showed, it helped to lose several lines from the rebase-i implementation).
> The end user may not bother to count commits, and being able to ff earlier
> parts of "rebase -i HEAD~20" when the first "edit" appears after many
> "pick" would help (and that was why "rebase -i" internally had ff logic).
> 
> But running cherry-pick as the top-level operation is a conscious act of
> "I want to replay the change done by that one", and it would be utterly
> confusing if it fast-forwarded by default.  I agree with Jonathan that it
> will never be default.

Well, I think it is difficult to predict how and how much people will use "git 
cherry-pick A..B", and if after using it they will want fast forwarding by 
default to be consistent between "git cherry-pick" and "git merge" or if they 
won't care.

Best regards,
Christian.