What's cooking in git.git (Jan 2010, #01; Mon, 04)

What's cooking in git.git (Jan 2010, #01; Mon, 04)

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

The tip of 'next' has been rebuilt on top of the current 'master'.

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

* da/difftool (2009-12-22) 2 commits
 - git-difftool: Add '--gui' for selecting a GUI tool
 - t7800-difftool: Set a bogus tool for use by tests

* jh/gitweb-cached (2010-01-03) 4 commits
 - gitweb: Makefile improvements
 - gitweb: Optionally add "git" links in project list page
 - gitweb: Add option to force version match
 - gitweb: Load checking

* tc/test-locate-httpd (2010-01-02) 1 commit
 - t/lib-http.sh: Restructure finding of default httpd location

* jc/fix-tree-walk (2009-09-14) 7 commits
 - read-tree --debug-unpack
 - unpack-trees.c: look ahead in the index
 - unpack-trees.c: prepare for looking ahead in the index
 - Aggressive three-way merge: fix D/F case
 - traverse_trees(): handle D/F conflict case sanely
 - more D/F conflict tests
 - tests: move convenience regexp to match object names to test-lib.sh

Resurrected from "Ejected" category.

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

* cc/reset-more (2010-01-04) 6 commits
  (merged to 'next' on 2010-01-04 at 8802c2c)
 + Fix bit assignment for CE_CONFLICTED
  (merged to 'next' on 2010-01-03 at f83d4c6)
 + "reset --merge": fix unmerged case
 + reset: use "unpack_trees()" directly instead of "git read-tree"
 + reset: add a few tests for "git reset --merge"
 + Documentation: reset: add some tables to describe the different options
 + reset: improve mixed reset error message when in a bare repo

* bg/maint-remote-update-default (2009-12-31) 1 commit
  (merged to 'next' on 2010-01-03 at 113009e)
 + Fix "git remote update" with remotes.defalt set

* jc/branch-d (2009-12-29) 1 commit
 - branch -d: base the "already-merged" safety on the branch it merges with

* jc/rerere (2009-12-04) 1 commit
 - Teach --[no-]rerere-autoupdate option to merge, revert and friends

* jk/maint-1.6.5-reset-hard (2009-12-30) 1 commit
  (merged to 'next' on 2010-01-02 at 190d63b)
 + reset: unbreak hard resets with GIT_WORK_TREE

* jk/push-to-delete (2009-12-30) 1 commit
  (merged to 'next' on 2010-01-03 at 9ee293b)
 + builtin-push: add --delete as syntactic sugar for :foo

* jk/run-command-use-shell (2010-01-01) 8 commits
 - t4030, t4031: work around bogus MSYS bash path conversion
 - t0021: use $SHELL_PATH for the filter script
 - diff: run external diff helper with shell
 - textconv: use shell to run helper
 - editor: use run_command's shell feature
 - run-command: optimize out useless shell calls
 - run-command: convert simple callsites to use_shell
 - run-command: add "use shell" option

* mm/config-path (2009-12-30) 1 commit
  (merged to 'next' on 2010-01-03 at 9c0e81a)
 + builtin-config: add --path option doing ~ and ~user expansion.

* pm/cvs-environ (2009-12-30) 1 commit
  (merged to 'next' on 2010-01-03 at 4c22932)
 + CVS Server: Support reading base and roots from environment

* rs/maint-archive-match-pathspec (2009-12-12) 1 commit
  (merged to 'next' on 2010-01-03 at 92d7d15)
 + archive: complain about path specs that don't match anything

* so/cvsserver-update (2009-12-07) 1 commit
  (merged to 'next' on 2010-01-03 at 99959b6)
 + cvsserver: make the output of 'update' more compatible with cvs.

* tc/clone-v-progress (2009-12-26) 4 commits
 - clone: use --progress to force progress reporting
 - clone: set transport->verbose when -v/--verbose is used
 - git-clone.txt: reword description of progress behaviour
 - check stderr with isatty() instead of stdout when deciding to show progress

* tc/smart-http-restrict (2010-01-02) 4 commits
 - Smart-http tests: Test http-backend without curl or a webserver
 - Smart-http tests: Break test t5560-http-backend into pieces
 - Smart-http tests: Improve coverage in test t5560
 - Smart-http: check if repository is OK to export before serving it

* tr/maint-1.6.5-bash-prompt-show-submodule-changes (2009-12-31) 1 commit
  (merged to 'next' on 2010-01-03 at b785974)
 + bash completion: factor submodules into dirty state

* jc/cache-unmerge (2009-12-25) 9 commits
 - rerere forget path: forget recorded resolution
 - rerere: refactor rerere logic to make it independent from I/O
 - rerere: remove silly 1024-byte line limit
 - resolve-undo: teach "update-index --unresolve" to use resolve-undo info
 - resolve-undo: "checkout -m path" uses resolve-undo information
 - resolve-undo: allow plumbing to clear the information
 - resolve-undo: basic tests
 - resolve-undo: record resolved conflicts in a new index extension section
 - builtin-merge.c: use standard active_cache macros

* js/filter-branch-prime (2009-12-15) 1 commit
  (merged to 'next' on 2010-01-03 at 7c90319)
 + filter-branch: remove an unnecessary use of 'git read-tree'

* mg/tag-d-show (2009-12-10) 1 commit
  (merged to 'next' on 2010-01-03 at 87657d2)
 + tag -d: print sha1 of deleted tag

* sb/maint-octopus (2009-12-11) 3 commits
  (merged to 'next' on 2010-01-03 at ffe77d6)
 + octopus: remove dead code
 + octopus: reenable fast-forward merges
 + octopus: make merge process simpler to follow

* jh/commit-status (2009-12-07) 1 commit
 - [test?] Add commit.status, --status, and --no-status

* jc/checkout-merge-base (2009-11-20) 2 commits
  (merged to 'next' on 2010-01-02 at 6a8f6fc)
 + "rebase --onto A...B" replays history on the merge base between A and B
 + "checkout A...B" switches to the merge base between A and B

* tr/http-push-ref-status (2009-12-24) 6 commits
 - transport-helper.c::push_refs(): emit "no refs" error message
 - transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
 - transport.c::transport_push(): make ref status affect return value
 - refactor ref status logic for pushing
 - t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
 - t5541-http-push.sh: add tests for non-fast-forward pushes

* bg/maint-add-all-doc (2009-12-07) 4 commits
  (merged to 'next' on 2010-01-03 at b19a323)
 + squash! rm documentation--also mention add-u where we mention commit-a
 + git-rm doc: Describe how to sync index & work tree
 + git-add/rm doc: Consistently back-quote
 + Documentation: 'git add -A' can remove files

* il/vcs-helper (2009-12-09) 8 commits
 - Remove special casing of http, https and ftp
 - Support remote archive from all smart transports
 - Support remote helpers implementing smart transports
 - Support taking over transports
 - Refactor git transport options parsing
 - Pass unknown protocols to external protocol handlers
 - Support mandatory capabilities
 - Add remote helper debug mode

* mm/diag-path-in-treeish (2009-12-07) 1 commit
 - Detailed diagnosis when parsing an object name fails.

* mh/rebase-fixup (2009-12-07) 2 commits
 - Add a command "fixup" to rebase --interactive
 - t3404: Use test_commit to set up test repository
 (this branch is used by ns/rebase-auto-squash.)

Initial round of "fixup" action that is similar to "squash" action in
"rebase -i" that excludes the commit log message from follow-up commits
when composing the log message for the updated one.  Expected is a further
improvement to skip opening the editor if a pick is followed only by
"fixup" and no "squash".

* ns/rebase-auto-squash (2009-12-08) 2 commits
 - fixup! rebase -i --autosquash
 - rebase -i --autosquash: auto-squash commits
 (this branch uses mh/rebase-fixup.)

* jh/notes (2009-12-07) 11 commits
 - Refactor notes concatenation into a flexible interface for combining notes
 - Notes API: Allow multiple concurrent notes trees with new struct notes_tree
 - 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: add_note(): Add note objects to the internal notes tree structure
 - Notes API: init_notes(): Initialize the notes tree from the given notes ref
 - Notes API: get_commit_notes() -> format_note() + remove the commit restriction
 - Minor style fixes to notes.c
  (merged to 'next' on 2010-01-02 at ae42130)
 + Add more testcases to test fast-import of notes
 + Rename t9301 to t9350, to make room for more fast-import tests
 + fast-import: Proper notes tree manipulation

* fc/opt-quiet-gc-reset (2009-12-02) 1 commit
 - General --quiet improvements

* mv/commit-date (2009-12-03) 2 commits
  (merged to 'next' on 2010-01-03 at 1c45fdf)
 + Document date formats accepted by parse_date()
 + builtin-commit: add --date option

* sr/gfi-options (2009-12-04) 7 commits
 - fast-import: add (non-)relative-marks feature
 - fast-import: allow for multiple --import-marks= arguments
 - fast-import: test the new option command
 - fast-import: add option command
 - fast-import: add feature command
 - fast-import: put marks reading in its own function
 - fast-import: put option parsing code in separate functions

* ap/merge-backend-opts (2008-07-18) 6 commits
 - Document that merge strategies can now take their own options
 - Extend merge-subtree tests to test -Xsubtree=dir.
 - Make "subtree" part more orthogonal to the rest of merge-recursive.
 - Teach git-pull to pass -X<option> to git-merge
 - git merge -X<option>
 - git-merge-file --ours, --theirs

"git pull" patch needs sq-then-eval fix to protect it from $IFS
but otherwise seemed good.

* mo/bin-wrappers (2009-12-02) 3 commits
  (merged to 'next' on 2010-01-03 at 8c5fa27)
 + INSTALL: document a simpler way to run uninstalled builds
 + run test suite without dashed git-commands in PATH
 + build dashless "bin-wrappers" directory similar to installed bindir

* tr/http-updates (2009-12-28) 4 commits
  (merged to 'next' on 2010-01-02 at cf25698)
 + Remove http.authAny
 + Allow curl to rewind the RPC read buffer
 + Add an option for using any HTTP authentication scheme, not only basic
 + http: maintain curl sessions

* nd/sparse (2009-12-30) 23 commits
  (merged to 'next' on 2010-01-02 at 5499bbe)
 + grep: do not do external grep on skip-worktree entries
 + commit: correctly respect skip-worktree bit
 + ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID
 + tests: rename duplicate t1009
 + 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

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Matthieu Moy]

Hi,

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

> * mm/diag-path-in-treeish (2009-12-07) 1 commit
>  - Detailed diagnosis when parsing an object name fails.

This one has been there for quite some time and shouldn't be
controversial. Do I need anything to push it into next?

Thanks,

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Johannes Sixt]

Junio C Hamano schrieb:
> * jk/run-command-use-shell (2010-01-01) 8 commits
>  - t4030, t4031: work around bogus MSYS bash path conversion
>  - t0021: use $SHELL_PATH for the filter script
>  - diff: run external diff helper with shell
>  - textconv: use shell to run helper
>  - editor: use run_command's shell feature
>  - run-command: optimize out useless shell calls
>  - run-command: convert simple callsites to use_shell
>  - run-command: add "use shell" option

Two notes about this:

1. My patch "t0021:..." contains an unrelated change to t4030 (it changes 
a /bin/sh to $SHELL_PATH) that is not necessary. I included it in my first 
version of the patch, but later noticed that we already have many similar 
uses of /bin/sh instead of $SHELL_PATH in test scriptlets and decided to 
remove the change, but I only changed the commit message and forgot to 
unstage t4030.

2. If you intend to merge the early part of the topic to master early and 
hold "diff:..." and "textconv:..." in next a bit longer (as proposed by 
Jeff), then you should move "t0021:..." after "run-command: optimize out 
useless shell calls".

Thanks,
-- Hannes

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> * mm/diag-path-in-treeish (2009-12-07) 1 commit
>>  - Detailed diagnosis when parsing an object name fails.
>
> This one has been there for quite some time and shouldn't be
> controversial. Do I need anything to push it into next?

Prodding like this ;-) 

I wanted to stagger and spread the merge into 'next' over a few rounds.

Thanks.

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> writes:

> Junio C Hamano schrieb:
>> * jk/run-command-use-shell (2010-01-01) 8 commits
>>  - t4030, t4031: work around bogus MSYS bash path conversion
>>  - t0021: use $SHELL_PATH for the filter script
>>  - diff: run external diff helper with shell
>>  - textconv: use shell to run helper
>>  - editor: use run_command's shell feature
>>  - run-command: optimize out useless shell calls
>>  - run-command: convert simple callsites to use_shell
>>  - run-command: add "use shell" option
>
> Two notes about this:
>
> 1. My patch "t0021:..." contains an unrelated change to t4030 (it
> changes a /bin/sh to $SHELL_PATH) that is not necessary. I included it
> in my first version of the patch, but later noticed that we already
> have many similar uses of /bin/sh instead of $SHELL_PATH in test
> scriptlets and decided to remove the change, but I only changed the
> commit message and forgot to unstage t4030.

While you are technically correct that the change you made in t4030 is not
justified by the commit log message in the sense that the "hexdump" script
will go through run_command() interface and is not subject to the special
rules filter writers need to keep in mind, the patch text itself is a good
change, isn't it?  Do you want me to split the commit into two (one with
the current message with a patch only to t0021, and another to t4030 with
a justification like "SHELL_PATH is what the user told us to use")?

> 2. If you intend to merge the early part of the topic to master early
> and hold "diff:..." and "textconv:..." in next a bit longer (as
> proposed by Jeff), then you should move "t0021:..." after
> "run-command: optimize out useless shell calls".

As "run-command: convert simple callsites to use_shell" is the one that
changes the filter_buffer(), do you want to have t0021 patch before that
one, to prepare the test for the coming change?

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Jeff King]

On Mon, Jan 04, 2010 at 05:35:07PM -0800, Junio C Hamano wrote:

> > 1. My patch "t0021:..." contains an unrelated change to t4030 (it
> > changes a /bin/sh to $SHELL_PATH) that is not necessary. I included it
> > in my first version of the patch, but later noticed that we already
> > have many similar uses of /bin/sh instead of $SHELL_PATH in test
> > scriptlets and decided to remove the change, but I only changed the
> > commit message and forgot to unstage t4030.
> 
> While you are technically correct that the change you made in t4030 is not
> justified by the commit log message in the sense that the "hexdump" script
> will go through run_command() interface and is not subject to the special
> rules filter writers need to keep in mind, the patch text itself is a good
> change, isn't it?  Do you want me to split the commit into two (one with
> the current message with a patch only to t0021, and another to t4030 with
> a justification like "SHELL_PATH is what the user told us to use")?

If we are going to do the t4030 change, there are a ton of other spots
that use /bin/sh directly (I counted 38 with

  grep -n /bin/sh * | grep -v :1:

). Should we be changing all of them?

It is slightly just code churn, because the scripts are so simple that
even broken shells like Solaris /bin/sh run them just fine. The only
real advantage is that it slightly future-proofs them against somebody
making them more complex.

-Peff

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Mon, Jan 04, 2010 at 05:35:07PM -0800, Junio C Hamano wrote:
>
>> > 1. My patch "t0021:..." contains an unrelated change to t4030 (it
>> > changes a /bin/sh to $SHELL_PATH) that is not necessary. I included it
>> > in my first version of the patch, but later noticed that we already
>> > have many similar uses of /bin/sh instead of $SHELL_PATH in test
>> > scriptlets and decided to remove the change, but I only changed the
>> > commit message and forgot to unstage t4030.
>> 
>> While you are technically correct that the change you made in t4030 is not
>> justified by the commit log message in the sense that the "hexdump" script
>> will go through run_command() interface and is not subject to the special
>> rules filter writers need to keep in mind, the patch text itself is a good
>> change, isn't it?  Do you want me to split the commit into two (one with
>> the current message with a patch only to t0021, and another to t4030 with
>> a justification like "SHELL_PATH is what the user told us to use")?
>
> If we are going to do the t4030 change, there are a ton of other spots
> that use /bin/sh directly (I counted 38 with
>
>   grep -n /bin/sh * | grep -v :1:
>
> ). Should we be changing all of them?
>
> It is slightly just code churn, because the scripts are so simple that
> even broken shells like Solaris /bin/sh run them just fine. The only
> real advantage is that it slightly future-proofs them against somebody
> making them more complex.

Ok, it is a single liner that invokes Perl, so hardcoded /bin/sh is a much
lessor offence.

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Junio C Hamano]

I am tempted to merge the following to 'next' soonish; please complain and
stop me before I do so in a few days if there are issues.

 * da/difftool (2009-12-22) 2 commits
 * jh/gitweb-cached (2010-01-03) 4 commits
 * tc/test-locate-httpd (2010-01-02) 1 commit
 * tc/smart-http-restrict (2010-01-02) 4 commits
 * jc/branch-d (2009-12-29) 1 commit
   http://thread.gmane.org/gmane.comp.version-control.git/135837/focus=135863
 * mm/diag-path-in-treeish (2009-12-07) 1 commit
 * mh/rebase-fixup (2009-12-07) 2 commits
 * ns/rebase-auto-squash (2009-12-08) 2 commits
 * fc/opt-quiet-gc-reset (2009-12-02) 1 commit
 * tr/http-push-ref-status (2009-12-24) 6 commits
   Daniel and Jeff commented on the earlier rounds; is everybody happy with
   this v3?  If so let's move it to 'next'.  If not, please complain.
 * jh/notes (2009-12-07) 11 commits
   I didn't see any negative comments after this round; is everybody happy
   with this?  If so let's move it to 'next'.  If not, please complain.
 * sr/gfi-options (2009-12-04) 7 commits
   I didn't see any negative comments after this round; is everybody happy
   with this?  If so let's move it to 'next'.  If not, please complain.

----------------------------------------------------------------
I expect the following to be in 'master' by the end of next week.

 * bg/maint-remote-update-default (2009-12-31) 1 commit
 * jk/maint-1.6.5-reset-hard (2009-12-30) 1 commit
 * jk/push-to-delete (2009-12-30) 1 commit
 * mm/config-path (2009-12-30) 1 commit
 * pm/cvs-environ (2009-12-30) 1 commit
 * so/cvsserver-update (2009-12-07) 1 commit
 * tr/maint-1.6.5-bash-prompt-show-submodule-changes (2009-12-31) 1 commit
 * js/filter-branch-prime (2009-12-15) 1 commit
 * mg/tag-d-show (2009-12-10) 1 commit
 * sb/maint-octopus (2009-12-11) 3 commits
 * bg/maint-add-all-doc (2009-12-07) 4 commits
 * mv/commit-date (2009-12-03) 2 commits
 * mo/bin-wrappers (2009-12-02) 3 commits
 * tr/http-updates (2009-12-28) 4 commits
 * nd/sparse (2009-12-30) 23 commits

----------------------------------------------------------------

These need a bit more work to go forward.  Help and follow-up are
appreciated.

 * jc/fix-tree-walk (2009-09-14) 7 commits
   Resurrected from "Ejected" category.  This is a fix to a tricky
   codepath and testing and improving before it hits 'next' by brave souls
   is greatly appreciated.  I am not very happy about the solution myself.

 * tc/clone-v-progress (2009-12-26) 4 commits
   Perhaps needs an entry in the Release Notes, but otherwise looked Ok.

 * jh/commit-status (2009-12-07) 1 commit
   Needs tests.

 * jc/checkout-merge-base (2009-11-20) 2 commits
   Users of "rebase -i" might want to teach this to the command.
   Volunteers?

 * il/vcs-helper (2009-12-09) 8 commits
   According to http://thread.gmane.org/gmane.comp.version-control.git/134980
   this is very close to completion (or did I overlook a reroll after that?)
   but the final touch is not there yet.

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Jeff King]

On Mon, Jan 04, 2010 at 09:57:46PM -0800, Junio C Hamano wrote:

>  * tr/http-push-ref-status (2009-12-24) 6 commits
>    Daniel and Jeff commented on the earlier rounds; is everybody happy with
>    this v3?  If so let's move it to 'next'.  If not, please complain.

I just posted a few comments, but I suspect the response will just
involve Tay explaining why I'm wrong or confused. :) So no serious
objections, but let's wait for this round of discussion.

-Peff

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Tay Ray Chuan]

Hi,

On Tue, Jan 5, 2010 at 2:40 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Jan 04, 2010 at 09:57:46PM -0800, Junio C Hamano wrote:
>
>>  * tr/http-push-ref-status (2009-12-24) 6 commits
>>    Daniel and Jeff commented on the earlier rounds; is everybody happy with
>>    this v3?  If so let's move it to 'next'.  If not, please complain.
>
> I just posted a few comments, but I suspect the response will just
> involve Tay explaining why I'm wrong or confused. :) So no serious
> objections, but let's wait for this round of discussion.

thanks for taking the time to look at them; I'll be addressing your
concerns soon.

-- 
Cheers,
Ray Chuan

[PATCH] Teach --[no-]rerere-autoupdate option to merge, revert and friends

[Junio C Hamano]

Introduce a command line option to override rerere.autoupdate configuration
variable to make it more useful.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 I've had this in my private tree for quite a while and just noticed that
 I haven't sent it out.  A convenince configuration option to allow a
 potentially dangerous mode of operation must always come with an explicit
 way to disable it when necessary.

 Documentation/git-merge.txt |    7 ++++++-
 builtin-commit.c            |    2 +-
 builtin-merge.c             |    4 +++-
 builtin-rerere.c            |   23 ++++++++++++++++-------
 builtin-revert.c            |    4 +++-
 git-am.sh                   |    6 +++++-
 git-rebase.sh               |    6 +++++-
 parse-options.c             |    7 +++++++
 parse-options.h             |    3 +++
 rerere.c                    |    8 +++++---
 rerere.h                    |   10 ++++++++--
 t/t4200-rerere.sh           |   15 +++++++++++++++
 12 files changed, 77 insertions(+), 18 deletions(-)

diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index e886c2e..6747031 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -10,7 +10,7 @@ SYNOPSIS
 --------
 [verse]
 'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
-	[-m <msg>] <remote>...
+	 [--[no-]rerere-autoupdate] [-m <msg>] <remote>...
 'git merge' <msg> HEAD <remote>...
 
 DESCRIPTION
@@ -33,6 +33,11 @@ include::merge-options.txt[]
 	used to give a good default for automated 'git merge'
 	invocations.
 
+--rerere-autoupdate::
+--no-rerere-autoupdate::
+	Allow the rerere mechanism to update the index with the
+	result of auto-conflict resolution if possible.
+
 <remote>...::
 	Other branch heads to merge into our branch.  You need at
 	least one <remote>.  Specifying more than one <remote>
diff --git a/builtin-commit.c b/builtin-commit.c
index e93a647..72e0f0b 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -1150,7 +1150,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 		     "new_index file. Check that disk is not full or quota is\n"
 		     "not exceeded, and then \"git reset HEAD\" to recover.");
 
-	rerere();
+	rerere(0);
 	run_hook(get_index_file(), "post-commit", NULL);
 	if (!quiet)
 		print_summary(prefix, commit_sha1);
diff --git a/builtin-merge.c b/builtin-merge.c
index 56a1bb6..c3faa6b 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -52,6 +52,7 @@ static struct strategy **use_strategies;
 static size_t use_strategies_nr, use_strategies_alloc;
 static const char *branch;
 static int verbosity;
+static int allow_rerere_auto;
 
 static struct strategy all_strategy[] = {
 	{ "recursive",  DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -170,6 +171,7 @@ static struct option builtin_merge_options[] = {
 		"allow fast-forward (default)"),
 	OPT_BOOLEAN(0, "ff-only", &fast_forward_only,
 		"abort if fast-forward is not possible"),
+	OPT_RERERE_AUTOUPDATE(&allow_rerere_auto),
 	OPT_CALLBACK('s', "strategy", &use_strategies, "strategy",
 		"merge strategy to use", option_parse_strategy),
 	OPT_CALLBACK('m', "message", &merge_msg, "message",
@@ -790,7 +792,7 @@ static int suggest_conflicts(void)
 		}
 	}
 	fclose(fp);
-	rerere();
+	rerere(allow_rerere_auto);
 	printf("Automatic merge failed; "
 			"fix conflicts and then commit the result.\n");
 	return 1;
diff --git a/builtin-rerere.c b/builtin-rerere.c
index 343d6cd..7ec602c 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -101,15 +101,24 @@ static int diff_two(const char *file1, const char *label1,
 int cmd_rerere(int argc, const char **argv, const char *prefix)
 {
 	struct string_list merge_rr = { NULL, 0, 0, 1 };
-	int i, fd;
-
+	int i, fd, flags = 0;
+
+	if (2 < argc) {
+		if (!strcmp(argv[1], "-h"))
+			usage(git_rerere_usage);
+		if (!strcmp(argv[1], "--rerere-autoupdate"))
+			flags = RERERE_AUTOUPDATE;
+		else if (!strcmp(argv[1], "--no-rerere-autoupdate"))
+			flags = RERERE_NOAUTOUPDATE;
+		if (flags) {
+			argc--;
+			argv++;
+		}
+	}
 	if (argc < 2)
-		return rerere();
-
-	if (!strcmp(argv[1], "-h"))
-		usage(git_rerere_usage);
+		return rerere(flags);
 
-	fd = setup_rerere(&merge_rr);
+	fd = setup_rerere(&merge_rr, flags);
 	if (fd < 0)
 		return 0;
 
diff --git a/builtin-revert.c b/builtin-revert.c
index 151aa6a..857ca2e 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -38,6 +38,7 @@ static const char * const cherry_pick_usage[] = {
 static int edit, no_replay, no_commit, mainline, signoff;
 static enum { REVERT, CHERRY_PICK } action;
 static struct commit *commit;
+static int allow_rerere_auto;
 
 static const char *me;
 
@@ -57,6 +58,7 @@ static void parse_args(int argc, const char **argv)
 		OPT_BOOLEAN('r', NULL, &noop, "no-op (backward compatibility)"),
 		OPT_BOOLEAN('s', "signoff", &signoff, "add Signed-off-by:"),
 		OPT_INTEGER('m', "mainline", &mainline, "parent number"),
+		OPT_RERERE_AUTOUPDATE(&allow_rerere_auto),
 		OPT_END(),
 	};
 
@@ -395,7 +397,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
 			die ("Error wrapping up %s", defmsg);
 		fprintf(stderr, "Automatic %s failed.%s\n",
 			me, help_msg(commit->object.sha1));
-		rerere();
+		rerere(allow_rerere_auto);
 		exit(1);
 	}
 	if (commit_lock_file(&msg_file) < 0)
diff --git a/git-am.sh b/git-am.sh
index 4838cdb..2f46fda 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -30,6 +30,7 @@ skip            skip the current patch
 abort           restore the original branch and abort the patching operation.
 committer-date-is-author-date    lie about committer date
 ignore-date     use current timestamp for author date
+rerere-autoupdate update the index with reused conflict resolution if possible
 rebasing*       (internal use for git-rebase)"
 
 . git-sh-setup
@@ -135,7 +136,7 @@ It does not apply to blobs recorded in its index."
 	    export GIT_MERGE_VERBOSITY=0
     fi
     git-merge-recursive $orig_tree -- HEAD $his_tree || {
-	    git rerere
+	    git rerere $allow_rerere_autoupdate
 	    echo Failed to merge in the changes.
 	    exit 1
     }
@@ -293,6 +294,7 @@ resolvemsg= resume= scissors= no_inbody_headers=
 git_apply_opt=
 committer_date_is_author_date=
 ignore_date=
+allow_rerere_autoupdate=
 
 while test $# != 0
 do
@@ -340,6 +342,8 @@ do
 		committer_date_is_author_date=t ;;
 	--ignore-date)
 		ignore_date=t ;;
+	--rerere-autoupdate|--no-rerere-autoupdate)
+		allow_rerere_autoupdate="$1" ;;
 	-q|--quiet)
 		GIT_QUIET=t ;;
 	--)
diff --git a/git-rebase.sh b/git-rebase.sh
index b121f45..398ea73 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -50,6 +50,7 @@ diffstat=$(git config --bool rebase.stat)
 git_am_opt=
 rebase_root=
 force_rebase=
+allow_rerere_autoupdate=
 
 continue_merge () {
 	test -n "$prev_head" || die "prev_head must be defined"
@@ -118,7 +119,7 @@ call_merge () {
 		return
 		;;
 	1)
-		git rerere
+		git rerere $allow_rerere_autoupdate
 		die "$RESOLVEMSG"
 		;;
 	2)
@@ -349,6 +350,9 @@ do
 	-f|--f|--fo|--for|--forc|force|--force-r|--force-re|--force-reb|--force-reba|--force-rebas|--force-rebase)
 		force_rebase=t
 		;;
+	--rerere-autoupdate|--no-rerere-autoupdate)
+		allow_rerere_autoupdate="$1"
+		;;
 	-*)
 		usage
 		;;
diff --git a/parse-options.c b/parse-options.c
index f559411..10ec21f 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -633,3 +633,10 @@ int parse_opt_with_commit(const struct option *opt, const char *arg, int unset)
 	commit_list_insert(commit, opt->value);
 	return 0;
 }
+
+int parse_opt_tertiary(const struct option *opt, const char *arg, int unset)
+{
+	int *target = opt->value;
+	*target = unset ? 2 : 1;
+	return 0;
+}
diff --git a/parse-options.h b/parse-options.h
index f295a2c..91c1500 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -123,6 +123,8 @@ struct option {
 				      (h), PARSE_OPT_NOARG, NULL, (p) }
 #define OPT_INTEGER(s, l, v, h)     { OPTION_INTEGER, (s), (l), (v), "n", (h) }
 #define OPT_STRING(s, l, v, a, h)   { OPTION_STRING,  (s), (l), (v), (a), (h) }
+#define OPT_UYN(s, l, v, h)         { OPTION_CALLBACK, (s), (l), (v), NULL, \
+				      (h), PARSE_OPT_NOARG, &parse_opt_tertiary }
 #define OPT_DATE(s, l, v, h) \
 	{ OPTION_CALLBACK, (s), (l), (v), "time",(h), 0, \
 	  parse_opt_approxidate_cb }
@@ -190,6 +192,7 @@ extern int parse_opt_abbrev_cb(const struct option *, const char *, int);
 extern int parse_opt_approxidate_cb(const struct option *, const char *, int);
 extern int parse_opt_verbosity_cb(const struct option *, const char *, int);
 extern int parse_opt_with_commit(const struct option *, const char *, int);
+extern int parse_opt_tertiary(const struct option *, const char *, int);
 
 #define OPT__VERBOSE(var)  OPT_BOOLEAN('v', "verbose", (var), "be verbose")
 #define OPT__QUIET(var)    OPT_BOOLEAN('q', "quiet",   (var), "be quiet")
diff --git a/rerere.c b/rerere.c
index 29f95f6..e0ac5bc 100644
--- a/rerere.c
+++ b/rerere.c
@@ -367,7 +367,7 @@ static int is_rerere_enabled(void)
 	return 1;
 }
 
-int setup_rerere(struct string_list *merge_rr)
+int setup_rerere(struct string_list *merge_rr, int flags)
 {
 	int fd;
 
@@ -375,6 +375,8 @@ int setup_rerere(struct string_list *merge_rr)
 	if (!is_rerere_enabled())
 		return -1;
 
+	if (flags & (RERERE_AUTOUPDATE|RERERE_NOAUTOUPDATE))
+		rerere_autoupdate = !!(flags & RERERE_AUTOUPDATE);
 	merge_rr_path = git_pathdup("MERGE_RR");
 	fd = hold_lock_file_for_update(&write_lock, merge_rr_path,
 				       LOCK_DIE_ON_ERROR);
@@ -382,12 +384,12 @@ int setup_rerere(struct string_list *merge_rr)
 	return fd;
 }
 
-int rerere(void)
+int rerere(int flags)
 {
 	struct string_list merge_rr = { NULL, 0, 0, 1 };
 	int fd;
 
-	fd = setup_rerere(&merge_rr);
+	fd = setup_rerere(&merge_rr, flags);
 	if (fd < 0)
 		return 0;
 	return do_plain_rerere(&merge_rr, fd);
diff --git a/rerere.h b/rerere.h
index 13313f3..10a94a4 100644
--- a/rerere.h
+++ b/rerere.h
@@ -3,9 +3,15 @@
 
 #include "string-list.h"
 
-extern int setup_rerere(struct string_list *);
-extern int rerere(void);
+#define RERERE_AUTOUPDATE   01
+#define RERERE_NOAUTOUPDATE 02
+
+extern int setup_rerere(struct string_list *, int);
+extern int rerere(int);
 extern const char *rerere_path(const char *hex, const char *file);
 extern int has_rerere_resolution(const char *hex);
 
+#define OPT_RERERE_AUTOUPDATE(v) OPT_UYN(0, "rerere-autoupdate", (v), \
+	"update the index with reused conflict resolution if possible")
+
 #endif
diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index a6bc028..bb402c3 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -217,7 +217,22 @@ test_expect_success 'rerere.autoupdate' '
 	git checkout version2 &&
 	test_must_fail git merge fifth &&
 	test 0 = $(git ls-files -u | wc -l)
+'
 
+test_expect_success 'merge --rerere-autoupdate' '
+	git config --unset rerere.autoupdate
+	git reset --hard &&
+	git checkout version2 &&
+	test_must_fail git merge --rerere-autoupdate fifth &&
+	test 0 = $(git ls-files -u | wc -l)
+'
+
+test_expect_success 'merge --no-rerere-autoupdate' '
+	git config rerere.autoupdate true
+	git reset --hard &&
+	git checkout version2 &&
+	test_must_fail git merge --no-rerere-autoupdate fifth &&
+	test 2 = $(git ls-files -u | wc -l)
 '
 
 test_done
-- 
1.6.6.158.g8bda6.dirty

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Johan Herland]

On Tuesday 05 January 2010, Junio C Hamano wrote:
> I am tempted to merge the following to 'next' soonish; please
> complain and stop me before I do so in a few days if there are
> issues.
>
> * jh/notes (2009-12-07) 11 commits
>    I didn't see any negative comments after this round; is everybody
> happy with this?  If so let's move it to 'next'.  If not, please
> complain.

Please hold until I send a new iteration of the series (which will be 
based on what is currently in 'next'). The new iteration should be 
ready in a few days.


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Ilari Liusvaara]

On Mon, Jan 04, 2010 at 09:57:46PM -0800, Junio C Hamano wrote:
> 
>  * il/vcs-helper (2009-12-09) 8 commits
>    According to http://thread.gmane.org/gmane.comp.version-control.git/134980
>    this is very close to completion (or did I overlook a reroll after that?)
>    but the final touch is not there yet.

AFAICT, the only nits about that series in that thread were:

- SoB ping-pong
- Not using warning()

And AFAICT both have been fixed in current pu. Or did I overlook some nit?


-Ilari

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Johannes Sixt]

Junio C Hamano schrieb:
> While you are technically correct that the change you made in t4030 is not
> justified by the commit log message in the sense that the "hexdump" script
> will go through run_command() interface and is not subject to the special
> rules filter writers need to keep in mind, the patch text itself is a good
> change, isn't it?

The patch text is good, but since it will not make a difference (and there 
are a ton of other places that use /bin/sh successfully), the change is 
not warrented at this time, IMO.

> As "run-command: convert simple callsites to use_shell" is the one that
> changes the filter_buffer(), do you want to have t0021 patch before that
> one, to prepare the test for the coming change?

Well, the test will break on Windows only after "run-command: optimize out 
useless shell calls", and I wrote the commit message accordingly. If you 
move it before that one (and if you are picky) the commit message should 
be changed as well.

-- Hannes

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Junio C Hamano]

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:

> - Not using warning()

Ah, I forgot about locally fixing that one up.  Sorry, and thanks.

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> writes:

> Junio C Hamano schrieb:
>> While you are technically correct that the change you made in t4030 is not
>> justified by the commit log message in the sense that the "hexdump" script
>> will go through run_command() interface and is not subject to the special
>> rules filter writers need to keep in mind, the patch text itself is a good
>> change, isn't it?
>
> The patch text is good, but since it will not make a difference (and
> there are a ton of other places that use /bin/sh successfully), the
> change is not warrented at this time, IMO.

You are right (and Peff also corrected me).

>> As "run-command: convert simple callsites to use_shell" is the one that
>> changes the filter_buffer(), do you want to have t0021 patch before that
>> one, to prepare the test for the coming change?
>
> Well, the test will break on Windows only after "run-command: optimize
> out useless shell calls", and I wrote the commit message
> accordingly. If you move it before that one (and if you are picky) the
> commit message should be changed as well.

Yeah, I've reworded that one with a phrase "futureproof".

Regarding your "[PATCH 8/6] t4030, t4031", I have two questions:

    Recall that MSYS bash converts POSIX style absolute paths to Windows style
    absolute paths. Unfortunately, it converts a program argument that begins
    with a double-quote and otherwise looks like an absolute POSIX path, but
    in doing so, it strips everything past the second double-quote[*]. This
    case is triggered in the two test scripts. The work-around is to place the
    Windows style path between the quotes to avoid the path conversion.

(1) Does "Windows style path" here mean what $(pwd) returns as opposed to
    what is in $PWD?

(2) The patch reads like this:

-	git config diff.foo.textconv "\"$PWD\""/hexdump &&
+	git config diff.foo.textconv "\"$(pwd)\""/hexdump &&

    Does "strips everything past the second dq" mean "drops '/hexdump'"?
    If so, would this also work (I am not suggesting to change it, just
    asking for information)?

-	git config diff.foo.textconv "\"$PWD\""/hexdump &&
+	git config diff.foo.textconv "\"$PWD/hexdump\"" &&


Thanks.

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Johannes Sixt]

Junio C Hamano schrieb:
> Regarding your "[PATCH 8/6] t4030, t4031", I have two questions:
> 
>     Recall that MSYS bash converts POSIX style absolute paths to Windows style
>     absolute paths. Unfortunately, it converts a program argument that begins
>     with a double-quote and otherwise looks like an absolute POSIX path, but
>     in doing so, it strips everything past the second double-quote[*]. This
>     case is triggered in the two test scripts. The work-around is to place the
>     Windows style path between the quotes to avoid the path conversion.
> 
> (1) Does "Windows style path" here mean what $(pwd) returns as opposed to
>     what is in $PWD?

Yes. $PWD is of the form /c/foo/bar; pwd is a function in test-lib.sh that 
ensures it returns the form c:/foo/bar.

> (2) The patch reads like this:
> 
> -	git config diff.foo.textconv "\"$PWD\""/hexdump &&
> +	git config diff.foo.textconv "\"$(pwd)\""/hexdump &&
> 
>     Does "strips everything past the second dq" mean "drops '/hexdump'"?

Yes.

>     If so, would this also work (I am not suggesting to change it, just
>     asking for information)?
> 
> -	git config diff.foo.textconv "\"$PWD\""/hexdump &&
> +	git config diff.foo.textconv "\"$PWD/hexdump\"" &&

It would work, too, but it would depend on very bogus behavior of the MSYS 
bash.

-- Hannes

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Nanako Shiraishi]

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

> These need a bit more work to go forward.  Help and follow-up are
> appreciated.
>
>  * jc/checkout-merge-base (2009-11-20) 2 commits
>    Users of "rebase -i" might want to teach this to the command.
>    Volunteers?

Let me try. I'll let others to contribute documentation updates.

-- >8 --
Subject: [PATCH] Fix rebase --onto A...B and teach the same to interactive rebase

Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
---
 git-rebase--interactive.sh       |   21 +++++++++++-
 git-rebase.sh                    |    4 +-
 t/t3415-rebase-onto-threedots.sh |   68 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 90 insertions(+), 3 deletions(-)
 create mode 100755 t/t3415-rebase-onto-threedots.sh

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 23ded48..d42cc4f 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -482,6 +482,25 @@ get_saved_options () {
 	test -f "$DOTEST"/rebase-root && REBASE_ROOT=t
 }
 
+LF='
+'
+parse_onto () {
+	if	expr "$1" : '.*\.\.\.' >/dev/null &&
+		left=${1%...*} right=${1#*...} &&
+		: ${left:=HEAD} ${right:=HEAD} &&
+		onto=$(git merge-base "$left" "$right")
+	then
+		case "$onto" in
+		?*"$LF"?* | '')
+			exit 1 ;;
+		esac
+		echo "$onto"
+		exit 0
+	else
+		git rev-parse --verify "$1^0"
+	fi
+}
+
 while test $# != 0
 do
 	case "$1" in
@@ -589,7 +608,7 @@ first and then run 'git rebase --continue' again."
 		;;
 	--onto)
 		shift
-		ONTO=$(git rev-parse --verify "$1") ||
+		ONTO=$(parse_onto "$1") ||
 			die "Does not point to a valid commit: $1"
 		;;
 	--)
diff --git a/git-rebase.sh b/git-rebase.sh
index 6503113..43c62c0 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -419,8 +419,8 @@ fi
 
 # Make sure the branch to rebase onto is valid.
 onto_name=${newbase-"$upstream_name"}
-if	left=$(expr "$onto_name" : '\(.*\)\.\.\.') &&
-	right=$(expr "$onto_name" : '\.\.\.\(.*\)$') &&
+if	expr "$onto_name" : '.*\.\.\.' >/dev/null &&
+	left=${onto_name%...*} right=${onto_name#*...} &&
 	: ${left:=HEAD} ${right:=HEAD} &&
 	onto=$(git merge-base "$left" "$right")
 then
diff --git a/t/t3415-rebase-onto-threedots.sh b/t/t3415-rebase-onto-threedots.sh
new file mode 100755
index 0000000..c243243
--- /dev/null
+++ b/t/t3415-rebase-onto-threedots.sh
@@ -0,0 +1,68 @@
+#!/bin/sh
+
+test_description='git rebase --onto A...B'
+
+. ./test-lib.sh
+. "$TEST_DIRECTORY/lib-rebase.sh"
+
+#           F---G                     G'
+#          /          -->            /
+# A---B---C---D---E         A---B---C---D---E
+
+test_expect_success setup '
+	test_commit A &&
+	test_commit B &&
+	test_commit C &&
+	git branch topic &&
+	test_commit D &&
+	test_commit E &&
+	git checkout topic &&
+	test_commit F &&
+	test_commit G
+'
+
+test_expect_success 'rebase --onto A...B' '
+	git reset --hard &&
+	git checkout topic &&
+	git reset --hard G &&
+
+	git rebase --onto master...topic HEAD^ &&
+	git rev-parse HEAD^ >actual &&
+	git rev-parse C^0 >expect &&
+	test_cmp expect actual
+'
+
+test_expect_success 'rebase --onto A...' '
+	git reset --hard &&
+	git checkout topic &&
+	git reset --hard G &&
+
+	git rebase --onto master... HEAD^ &&
+	git rev-parse HEAD^ >actual &&
+	git rev-parse C^0 >expect &&
+	test_cmp expect actual
+'
+
+test_expect_success 'rebase -i --onto A...B' '
+	git reset --hard &&
+	git checkout topic &&
+	git reset --hard G &&
+	set_fake_editor &&
+	EXPECT_COUNT=1 git rebase -i --onto master...topic HEAD^ &&
+	git rev-parse HEAD^ >actual &&
+	git rev-parse C^0 >expect &&
+	test_cmp expect actual
+'
+
+test_expect_success 'rebase -i --onto A...' '
+	git reset --hard &&
+	git checkout topic &&
+	git reset --hard G &&
+	set_fake_editor &&
+	EXPECT_COUNT=1 git rebase -i --onto master... HEAD^ &&
+	git rev-parse HEAD^ >actual &&
+	git rev-parse C^0 >expect &&
+	test_cmp expect actual
+'
+
+test_done
-- 
1.6.6

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Johannes Schindelin]

Hi,

On Wed, 6 Jan 2010, Nanako Shiraishi wrote:

> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 23ded48..d42cc4f 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -482,6 +482,25 @@ get_saved_options () {
>  	test -f "$DOTEST"/rebase-root && REBASE_ROOT=t
>  }
>  
> +LF='
> +'
> +parse_onto () {
> +	if	expr "$1" : '.*\.\.\.' >/dev/null &&
> +		left=${1%...*} right=${1#*...} &&
> +		: ${left:=HEAD} ${right:=HEAD} &&
> +		onto=$(git merge-base "$left" "$right")
> +	then
> +		case "$onto" in
> +		?*"$LF"?* | '')
> +			exit 1 ;;
> +		esac
> +		echo "$onto"
> +		exit 0
> +	else
> +		git rev-parse --verify "$1^0"
> +	fi
> +}

It might be easier to understand like this:

	case "$1" in
	*...*)
		left=${1%...*} &&
		right=${1#*...} &&
		onto="$(git merge-base "${left:-HEAD}" "${right:-HEAD}")" &&
		test ! -z "$onto" &&
		echo "$onto"
	;;
	*)
		git rev-parse --verify "$1^0"
	;;
	esac

Besides, why do you change the "$1" to "$1^0"?
		
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 6503113..43c62c0 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh

I would separate the patches.  rebase.sh and rebase--interactive.sh are 
fundamentally different.

Thanks,
Dscho

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> writes:

> Junio C Hamano schrieb:
>> (1) Does "Windows style path" here mean what $(pwd) returns as opposed to
>>     what is in $PWD?
>
> Yes. $PWD is of the form /c/foo/bar; pwd is a function in test-lib.sh
> that ensures it returns the form c:/foo/bar.
>
>> (2) The patch reads like this:
>> ...
>>     Does "strips everything past the second dq" mean "drops '/hexdump'"?
> Yes.
>
>>     If so, would this also work (I am not suggesting to change it, just
>> ...
> It would work, too, but it would depend on very bogus behavior of the
> MSYS bash.

Thanks.

Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> It might be easier to understand like this:
>
> 	case "$1" in
> 	*...*)
> 		left=${1%...*} &&
> 		right=${1#*...} &&
> 		onto="$(git merge-base "${left:-HEAD}" "${right:-HEAD}")" &&
> 		test ! -z "$onto" &&
> 		echo "$onto"
> 	;;
> 	*)
> 		git rev-parse --verify "$1^0"
> 	;;
> 	esac

Double-semicolons should be indented one level deeper.

I think your version may be slightly better (avoids one "expr"), but it
actually was much harder to read your cascade of && that implicitly exits
with non-zero status in the first case arm than the explicit exit status
given by the original patch.

As far as I can tell, both versions inherit the same bug from me when the
user gave us A...B pair that has more than one merge bases.  I think you
need to give --all to merge-base and resurrect the "did we get more than
one" test from her patch.

> Besides, why do you change the "$1" to "$1^0"?

Isn't it a bugfix?

Earlier code wouldn't have caught "--onto $blob_id" as an error, but this
will do so---I actually think it is a good change.

>> diff --git a/git-rebase.sh b/git-rebase.sh
>> index 6503113..43c62c0 100755
>> --- a/git-rebase.sh
>> +++ b/git-rebase.sh
>
> I would separate the patches.  rebase.sh and rebase--interactive.sh are 
> fundamentally different.

I too think splitting into two patches would make sense in this case.  The
patch to git-rebase.sh seems to be a bugfix in the left/right computation;
I am kind of surprised that I haven't triggered it myself so far.

Thanks.

[PATCH (v2) 1/2] rebase: fix --onto A...B parsing and add tests

[Nanako Shiraishi]

The previous patch didn't parse "rebase --onto A...B" correctly when A
isn't an empty string. It also tried to be careful to notice a case in
which there are more than one merge bases, but forgot to give --all option
to merge-base, making the test pointless.

Fix these problems and add a test script to verify. Improvements to the
script to parse A...B syntax was taken from review comments by Johannes
Schindelin.

Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
---
 git-rebase.sh                    |   33 ++++++++++-------
 t/t3415-rebase-onto-threedots.sh |   75 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 94 insertions(+), 14 deletions(-)
 create mode 100755 t/t3415-rebase-onto-threedots.sh

diff --git a/git-rebase.sh b/git-rebase.sh
index 6503113..9bd8974 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -419,22 +419,27 @@ fi
 
 # Make sure the branch to rebase onto is valid.
 onto_name=${newbase-"$upstream_name"}
-if	left=$(expr "$onto_name" : '\(.*\)\.\.\.') &&
-	right=$(expr "$onto_name" : '\.\.\.\(.*\)$') &&
-	: ${left:=HEAD} ${right:=HEAD} &&
-	onto=$(git merge-base "$left" "$right")
-then
-	case "$onto" in
-	?*"$LF"?*)
-		die "$onto_name: there are more than one merge bases"
-		;;
-	'')
+case "$onto_name" in
+*...*)
+	if	left=${onto_name%...*} right=${onto_name#*...} &&
+		onto=$(git merge-base --all ${left:-HEAD} ${right:-HEAD})
+	then
+		case "$onto" in
+		?*"$LF"?*)
+			die "$onto_name: there are more than one merge bases"
+			;;
+		'')
+			die "$onto_name: there is no merge base"
+			;;
+		esac
+	else
 		die "$onto_name: there is no merge base"
-		;;
-	esac
-else
+	fi
+	;;
+*)
 	onto=$(git rev-parse --verify "${onto_name}^0") || exit
-fi
+	;;
+esac
 
 # If a hook exists, give it a chance to interrupt
 run_pre_rebase_hook "$upstream_arg" "$@"
diff --git a/t/t3415-rebase-onto-threedots.sh b/t/t3415-rebase-onto-threedots.sh
new file mode 100755
index 0000000..da378c4
--- /dev/null
+++ b/t/t3415-rebase-onto-threedots.sh
@@ -0,0 +1,75 @@
+#!/bin/sh
+
+test_description='git rebase --onto A...B'
+
+. ./test-lib.sh
+. "$TEST_DIRECTORY/lib-rebase.sh"
+
+# Rebase only the tip commit of "topic" on merge base between "master"
+# and "topic".  Cannot do this for "side" with "master" because there
+# is no single merge base.
+#
+#
+#	    F---G topic                             G'
+#	   /                                       /
+# A---B---C---D---E master      -->       A---B---C---D---E
+#      \   \ /
+#	\   x
+#	 \ / \ 
+#	  H---I---J---K side
+
+test_expect_success setup '
+	test_commit A &&
+	test_commit B &&
+	git branch side &&
+	test_commit C &&
+	git branch topic &&
+	git checkout side &&
+	test_commit H &&
+	git checkout master &&
+	test_tick &&
+	git merge H &&
+	git tag D &&
+	test_commit E &&
+	git checkout topic &&
+	test_commit F &&
+	test_commit G &&
+	git checkout side &&
+	test_tick &&
+	git merge C &&
+	git tag I &&
+	test_commit J &&
+	test_commit K
+'
+
+test_expect_success 'rebase --onto master...topic' '
+	git reset --hard &&
+	git checkout topic &&
+	git reset --hard G &&
+
+	git rebase --onto master...topic F &&
+	git rev-parse HEAD^1 >actual &&
+	git rev-parse C^0 >expect &&
+	test_cmp expect actual
+'
+
+test_expect_success 'rebase --onto master...' '
+	git reset --hard &&
+	git checkout topic &&
+	git reset --hard G &&
+
+	git rebase --onto master... F &&
+	git rev-parse HEAD^1 >actual &&
+	git rev-parse C^0 >expect &&
+	test_cmp expect actual
+'
+
+test_expect_success 'rebase --onto master...side' '
+	git reset --hard &&
+	git checkout side &&
+	git reset --hard K &&
+
+	test_must_fail git rebase --onto master...side J
+'
+
+test_done
-- 
1.6.6.53.g75f61




-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

[PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax

[Nanako Shiraishi]

When rewriting commits on a topic branch, sometimes it is easier to
compare the version of commits before and after the rewrite if they are
based on the same commit that forked from the upstream. An earlier commit
by Junio (fixed up by the previous commit) gives "--onto A...B" syntax to
rebase command, and rebases on top of the merge base between A and B;
teach the same to the interactive version, too.

Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
---
 git-rebase--interactive.sh       |   21 ++++++++++++++++++++-
 t/t3415-rebase-onto-threedots.sh |   30 ++++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+), 1 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 23ded48..f7ae02c 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -482,6 +482,25 @@ get_saved_options () {
 	test -f "$DOTEST"/rebase-root && REBASE_ROOT=t
 }
 
+LF='
+'
+parse_onto () {
+	case "$1" in
+	*...*)
+		if	left=${1%...*} right=${1#*...} &&
+			onto=$(git merge-base --all ${left:-HEAD} ${right:-HEAD})
+		then
+			case "$onto" in
+			?*"$LF"?* | '')
+				exit 1 ;;
+			esac
+			echo "$onto"
+			exit 0
+		fi
+	esac
+	git rev-parse --verify "$1^0"
+}
+
 while test $# != 0
 do
 	case "$1" in
@@ -589,7 +608,7 @@ first and then run 'git rebase --continue' again."
 		;;
 	--onto)
 		shift
-		ONTO=$(git rev-parse --verify "$1") ||
+		ONTO=$(parse_onto "$1") ||
 			die "Does not point to a valid commit: $1"
 		;;
 	--)
diff --git a/t/t3415-rebase-onto-threedots.sh b/t/t3415-rebase-onto-threedots.sh
index da378c4..5e7eb88 100755
--- a/t/t3415-rebase-onto-threedots.sh
+++ b/t/t3415-rebase-onto-threedots.sh
@@ -72,4 +72,34 @@ test_expect_success 'rebase --onto master...side' '
 	test_must_fail git rebase --onto master...side J
 '
 
+test_expect_success 'rebase -i --onto master...topic' '
+	git reset --hard &&
+	git checkout topic &&
+	git reset --hard G &&
+	set_fake_editor &&
+	EXPECT_COUNT=1 git rebase -i --onto master...topic F &&
+	git rev-parse HEAD^1 >actual &&
+	git rev-parse C^0 >expect &&
+	test_cmp expect actual
+'
+
+test_expect_success 'rebase -i --onto master...' '
+	git reset --hard &&
+	git checkout topic &&
+	git reset --hard G &&
+	set_fake_editor &&
+	EXPECT_COUNT=1 git rebase -i --onto master... F &&
+	git rev-parse HEAD^1 >actual &&
+	git rev-parse C^0 >expect &&
+	test_cmp expect actual
+'
+
+test_expect_success 'rebase -i --onto master...side' '
+	git reset --hard &&
+	git checkout side &&
+	git reset --hard K &&
+
+	test_must_fail git rebase -i --onto master...side J
+'
+
 test_done
-- 
1.6.6.53.g75f61




-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> When rewriting commits on a topic branch, sometimes it is easier to
> compare the version of commits before and after the rewrite if they are
> based on the same commit that forked from the upstream. An earlier commit
> by Junio (fixed up by the previous commit) gives "--onto A...B" syntax to
> rebase command, and rebases on top of the merge base between A and B;
> teach the same to the interactive version, too.
>
> Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
> ---
>  git-rebase--interactive.sh       |   21 ++++++++++++++++++++-
>  t/t3415-rebase-onto-threedots.sh |   30 ++++++++++++++++++++++++++++++
>  2 files changed, 50 insertions(+), 1 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 23ded48..f7ae02c 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -482,6 +482,25 @@ get_saved_options () {
>  	test -f "$DOTEST"/rebase-root && REBASE_ROOT=t
>  }
>  
> +LF='
> +'
> +parse_onto () {
> +	case "$1" in
> +	*...*)
> +		if	left=${1%...*} right=${1#*...} &&
> +			onto=$(git merge-base --all ${left:-HEAD} ${right:-HEAD})
> +		then
> +			case "$onto" in
> +			?*"$LF"?* | '')
> +				exit 1 ;;
> +			esac
> +			echo "$onto"
> +			exit 0
> +		fi
> +	esac
> +	git rev-parse --verify "$1^0"
> +}
> +
>  while test $# != 0
>  do
>  	case "$1" in

I am a bit unhappy about the duplication.  The text of this function is
different from the one in "rebase" proper, but they implement essentially
the same logic.  I was tempted to suggest having a common helper function,
but as Dscho mentioned "rebase -i" implementation does not share much with
"rebase" (even though it shares the external command line interface from
the end user's point of view), and I don't see a readily available place
(other than in git-sh-setup) to do so.

Ideas?

Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax

[Johannes Sixt]

On Donnerstag, 7. Januar 2010, Junio C Hamano wrote:
> I was tempted to suggest having a common helper function, 
> but as Dscho mentioned "rebase -i" implementation does not share much with
> "rebase" (even though it shares the external command line interface from
> the end user's point of view), and I don't see a readily available place
> (other than in git-sh-setup) to do so.
>
> Ideas?

1. Split git-rebase--merge.sh and git-rebase--am.sh backends off of 
git-rebase.sh. Have git-rebase.sh dispatch to 
git-rebase--{am,merge,interactive}.sh as appropriate.

2. Unify command line parsing from git-rebase--*.sh in git-rebase.sh. The 
git-rebase--*.sh can now simply refer to shell variables that were set by 
command line switches (the backends must be invoked using the . (dot) 
command).

3. Place common functionality like the one above in git-rebase.sh.

-- Hannes

Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax

[Avery Pennarun]

2010/1/7 Junio C Hamano <gitster@pobox.com>:
> I am a bit unhappy about the duplication.  The text of this function is
> different from the one in "rebase" proper, but they implement essentially
> the same logic.  I was tempted to suggest having a common helper function,
> but as Dscho mentioned "rebase -i" implementation does not share much with
> "rebase" (even though it shares the external command line interface from
> the end user's point of view), and I don't see a readily available place
> (other than in git-sh-setup) to do so.

Is there a reason that non-interactive rebase can't just be
implemented as "git rebase -i" but without actually launching an
editor to edit the commit list?

This would resolve any other inconsistencies between the two as well,
notably that non-interactive rebase sometimes refuses to do the rebase
I requested because "Current branch master is up to date," while
interactive rebase is willing to do it.  (Personally I prefer the
latter behaviour, since I don't like tools that think they're smarter
than me :))

Avery

Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax

[Sverre Rabbelier]

Heya,

On Fri, Jan 8, 2010 at 15:16, Avery Pennarun <apenwarr@gmail.com> wrote:
> This would resolve any other inconsistencies between the two as well,
> notably that non-interactive rebase sometimes refuses to do the rebase
> I requested because "Current branch master is up to date," while
> interactive rebase is willing to do it.  (Personally I prefer the
> latter behaviour, since I don't like tools that think they're smarter
> than me :))

I taught rebase the -f|--force-rebase flag a little while back, you
could use that :).

-- 
Cheers,

Sverre Rabbelier

Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax

[Avery Pennarun]

On Fri, Jan 8, 2010 at 3:22 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Fri, Jan 8, 2010 at 15:16, Avery Pennarun <apenwarr@gmail.com> wrote:
>> This would resolve any other inconsistencies between the two as well,
>> notably that non-interactive rebase sometimes refuses to do the rebase
>> I requested because "Current branch master is up to date," while
>> interactive rebase is willing to do it.  (Personally I prefer the
>> latter behaviour, since I don't like tools that think they're smarter
>> than me :))
>
> I taught rebase the -f|--force-rebase flag a little while back, you
> could use that :).

Thanks, I didn't know about that one.  But my general point is still:
we seem to have two implementations when the functionality of one is
actually a superset of the other.  As far as I can see, anyway.  So
the obvious way to reduce the duplicated code is to simply eliminate
the less-featureful implementation.

Avery

Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax

[Sverre Rabbelier]

Heya,

On Fri, Jan 8, 2010 at 15:31, Avery Pennarun <apenwarr@gmail.com> wrote:
> Thanks, I didn't know about that one.  But my general point is still:
> we seem to have two implementations when the functionality of one is
> actually a superset of the other.  As far as I can see, anyway.  So
> the obvious way to reduce the duplicated code is to simply eliminate
> the less-featureful implementation.

*cough* git sequencer *cough*

-- 
Cheers,

Sverre Rabbelier

Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax

[A Large Angry SCM]

Sverre Rabbelier wrote:
> Heya,
> 
> On Fri, Jan 8, 2010 at 15:31, Avery Pennarun <apenwarr@gmail.com> wrote:
>> Thanks, I didn't know about that one.  But my general point is still:
>> we seem to have two implementations when the functionality of one is
>> actually a superset of the other.  As far as I can see, anyway.  So
>> the obvious way to reduce the duplicated code is to simply eliminate
>> the less-featureful implementation.
> 
> *cough* git sequencer *cough*
> 

*cough* not in my ${PATH} *cough*

Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax

[Johannes Schindelin]

Hi,

On Fri, 8 Jan 2010, A Large Angry SCM wrote:

> Sverre Rabbelier wrote:
> > 
> > On Fri, Jan 8, 2010 at 15:31, Avery Pennarun <apenwarr@gmail.com> 
> > wrote:
> > > Thanks, I didn't know about that one.  But my general point is 
> > > still: we seem to have two implementations when the functionality of 
> > > one is actually a superset of the other.  As far as I can see, 
> > > anyway.  So the obvious way to reduce the duplicated code is to 
> > > simply eliminate the less-featureful implementation.
> > 
> > *cough* git sequencer *cough*
> 
> *cough* not in my ${PATH} *cough*

*cough* because that GSoC project failed in all but writing? *cough*

Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax

[Avery Pennarun]

On Fri, Jan 8, 2010 at 8:36 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Fri, 8 Jan 2010, A Large Angry SCM wrote:
>> Sverre Rabbelier wrote:
>> > *cough* git sequencer *cough*
>>
>> *cough* not in my ${PATH} *cough*
>
> *cough* because that GSoC project failed in all but writing? *cough*

Is there a summary of the results somewhere?  I can find a lot of
discussions of git-sequencer, but not what went right/wrong or if it
turned out to be a good/bad idea.

Avery