git/git-rebase--interactive.sh, branch v2.3.4

Merge branch 'es/rebase-i-count-todo' into maint

2015-03-23T18:23:17Z

"git rebase -i" recently started to include the number of commits in the insn sheet to be processed, but on a platform that prepends leading whitespaces to "wc -l" output, the numbers are shown with extra whitespaces that aren't necessary. * es/rebase-i-count-todo: rebase-interactive: re-word "item count" comment rebase-interactive: suppress whitespace preceding item count

rebase-interactive: re-word "item count" comment

2015-03-06T20:25:33Z

97f05f43 (Show number of TODO items for interactive rebase, 2014-12-10) taught rebase-interactive to display an item count in the instruction list comments: # Rebase 46640c6..5568fd5 onto 46640c6 (4 TODO item(s)) # # Commands: # p, pick = use commit # ... However, with the exception of the --edit-todo option, "TODO" is a one-off term, never presented to the user by rebase-interactive in any other context. The item count is in fact the number of commands ("pick", "edit", etc.) remaining on the instruction sheet, and the comment immediately following it talks about "Commands". Consequently, replace "(# TODO item(s))" with the more accurate and meaningful "(# command(s))". Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

rebase-interactive: suppress whitespace preceding item count

2015-03-06T20:11:27Z

97f05f43 (Show number of TODO items for interactive rebase, 2014-12-10) taught rebase-interactive to compute an item count with 'wc -l' and display it in the instruction list comments: # Rebase 46640c6..5568fd5 onto 46640c6 (4 TODO item(s)) On Mac OS X, however, it renders as: # Rebase 46640c6..5568fd5 onto 46640c6 ( 4 TODO item(s)) since 'wc -l' indents its output with leading spaces. Fix this. Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

Merge branch 'ks/rebase-i-abbrev' into maint

2015-03-05T21:12:56Z

The insn sheet "git rebase -i" creates did not fully honor core.abbrev settings. * ks/rebase-i-abbrev: rebase -i: use full object name internally throughout the script

rebase -i: use full object name internally throughout the script

2015-01-22T20:19:47Z

In earlier days, the abbreviated commit object name shown to the end users were generated with hardcoded --abbrev=7; 56895038 (rebase -i: respect core.abbrev, 2013-09-28) tried to make it honor the user specified core.abbrev, but it missed the very initial invocation of the editor. These days, we try to use the full 40-hex object names internally to avoid ambiguity that can arise after rebase starts running. Newly created objects during the rebase may share the same prefix with existing commits listed in the insn sheet. These object names are shortened just before invoking the sequence editor to present the insn sheet to the end user, and then expanded back to full object names when the editor returns. But the code still used the shortened names when preparing the insn sheet for the very first time, resulting "7 hexdigits or more" output to the user. Change the code to use full 40-hex commit object names from the very beginning to make things more uniform. Signed-off-by: Kirill A. Shutemov Signed-off-by: Junio C Hamano

Show number of TODO items for interactive rebase

2014-12-10T21:17:38Z

During 'rebase -i', one wrong edit in a long rebase session might inadvertently drop commits/items. This change shows the total number of TODO items in the comments after the list. After performing the rebase edit, total item counts can be compared to make sure that no changes have been lost in the edit. Signed-off-by: Onno Kortmann Signed-off-by: Junio C Hamano

rebase: omit patch-identical commits with --fork-point

2014-07-16T20:07:40Z

When the `--fork-point` argument was added to `git rebase`, we changed the value of $upstream to be the fork point instead of the point from which we want to rebase. When $orig_head..$upstream is empty this does not change the behaviour, but when there are new changes in the upstream we are no longer checking if any of them are patch-identical with changes in $upstream..$orig_head. Fix this by introducing a new variable to hold the fork point and using this to restrict the range as an extra (negative) revision argument so that the set of desired revisions becomes (in fork-point mode): git rev-list --cherry-pick --right-only \ $upstream...$orig_head ^$fork_point This allows us to correctly handle the scenario where we have the following topology: C --- D --- E <- dev / B <- master@{1} / o --- B' --- C* --- D* <- master where: - B' is a fixed-up version of B that is not patch-identical with B; - C* and D* are patch-identical to C and D respectively and conflict textually if applied in the wrong order; - E depends textually on D. The correct result of `git rebase master dev` is that B is identified as the fork-point of dev and master, so that C, D, E are the commits that need to be replayed onto master; but C and D are patch-identical with C* and D* and so can be dropped, so that the end result is: o --- B' --- C* --- D* --- E <- dev If the fork-point is not identified, then picking B onto a branch containing B' results in a conflict and if the patch-identical commits are not correctly identified then picking C onto a branch containing D (or equivalently D*) results in a conflict. This change allows us to handle both of these cases, where previously we either identified the fork-point (with `--fork-point`) but not the patch-identical commits *or* (with `--no-fork-point`) identified the patch-identical commits but not the fact that master had been rewritten. Reported-by: Ted Felix Signed-off-by: John Keeping Signed-off-by: Junio C Hamano

Merge branch 'ep/avoid-test-a-o'

2014-06-25T19:23:56Z

Update tests and scripts to avoid "test ... -a ...", which is often more error-prone than "test ... && test ...". Squashed misconversion fix-up into git-submodule.sh updates. * ep/avoid-test-a-o: git-submodule.sh: avoid "echo" path-like values git-submodule.sh: avoid "test -a/-o " t/test-lib-functions.sh: avoid "test -a/-o " t/t9814-git-p4-rename.sh: avoid "test -a/-o " t/t5538-push-shallow.sh: avoid "test -a/-o " t/t5403-post-checkout-hook.sh: avoid "test -a/-o " t/t5000-tar-tree.sh: avoid "test -a/-o " t/t4102-apply-rename.sh: avoid "test -a/-o " t/t0026-eol-config.sh: avoid "test -a/-o " t/t0025-crlf-auto.sh: avoid "test -a/-o " t/lib-httpd.sh: avoid "test -a/-o " git-rebase--interactive.sh: avoid "test -a/-o " git-mergetool.sh: avoid "test -a/-o " git-bisect.sh: avoid "test -a/-o " contrib/examples/git-resolve.sh: avoid "test -a/-o " contrib/examples/git-repack.sh: avoid "test -a/-o " contrib/examples/git-merge.sh: avoid "test -a/-o " contrib/examples/git-commit.sh: avoid "test -a/-o " contrib/examples/git-clone.sh: avoid "test -a/-o " check_bindir: avoid "test -a/-o "

Merge branch 'rr/rebase-autostash-fix'

2014-06-16T17:06:57Z

* rr/rebase-autostash-fix: rebase -i: test "Nothing to do" case with autostash rebase -i: handle "Nothing to do" case with autostash

git-rebase--interactive.sh: avoid "test -a/-o "

2014-06-09T21:47:07Z

The construct is error-prone; "test" being built-in in most modern shells, the reason to avoid "test && test " spawning one extra process by using a single "test -a " no longer exists. Signed-off-by: Elia Pinto Reviewed-by: Matthieu Moy Signed-off-by: Junio C Hamano