In some places we "echo" a string that comes from a commit log
message, which may have a backslash sequence that is interpreted by
the command (POSIX.1 allows this), most notably "dash"'s built-in
'echo'.

A commit message which contains the string '\n' (or ends with the
string '\c') may result in a garbage line in the todo list of an
interactive rebase which causes the rebase to fail.

To reproduce the behavior (with dash as /bin/sh):

  mkdir test && cd test && git init
  echo 1 >foo && git add foo
  git commit -m"this commit message ends with '\n'"
  echo 2 >foo && git commit -a --fixup HEAD
  git rebase -i --autosquash --root

Now the editor opens with garbage in line 3 which has to be
removed or the rebase fails.

Signed-off-by: Uwe Storbeck <uwe@ibr.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

In a shell snippet meant to be sourced by other shell scripts, an
opening #! line does more harm than good.

The harm:

 - When the shell library is sourced, the interpreter and options from
   the #! line are not used.  Specifying a particular shell can
   confuse the reader into thinking it is safe for the shell library
   to rely on idiosyncrasies of that shell.

 - Using #! instead of a plain comment drops a helpful visual clue
   that this is a shell library and not a self-contained script.

 - Tools such as lintian can use a #! line to tell when an
   installation script has failed by forgetting to set a script
   executable.  This check does not work if shell libraries also start
   with a #! line.

The good:

 - Text editors notice the #! line and use it for syntax highlighting
   if you try to edit the installed scripts (without ".sh" suffix) in
   place.

The use of the #! for file type detection is not needed because Git's
shell libraries are meant to be edited in source form (with ".sh"
suffix).  Replace the opening #! lines with comments.

This involves tweaking the test harness's valgrind support to find
shell libraries by looking for "# " in the first line instead of "#!"
(see v1.7.6-rc3~7, 2011-06-17).

Suggested by Russ Allbery through lintian.  Thanks to Jeff King and
Clemens Buchacher for further analysis.

Tested by searching for non-executable scripts with #! line:

	find . -name .git -prune -o -type f -not -executable |
	while read file
	do
		read line <"$file"
		case $line in
		'#!'*)
			echo "$file"
			;;
		esac
	done

The only remaining scripts found are templates for shell scripts
(unimplemented.sh, wrap-for-bin.sh) and sample input used in tests
(t/t4034/perl/{pre,post}).

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

collapse_todo_ids() uses `git rev-parse --short=7' to abbreviate
commit ids before showing them to the user in a text editor.  Let's
drop argument from --short to the configured value instead (still
defaulting to 7).

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

The commit object names in the insn sheet that was prepared at the
beginning of "rebase -i" session can become ambiguous as the
rebasing progresses and the repository gains more commits. Make
sure the internal record is kept with full 40-hex object names.

* es/rebase-i-no-abbrev:
  rebase -i: fix short SHA-1 collision
  t3404: rebase -i: demonstrate short SHA-1 collision
  t3404: make tests more self-contained

"git rebase -p" internally used the merge machinery, but when
rebasing, there should not be a need for merge summary.

* rt/rebase-p-no-merge-summary:
  rebase --preserve-merges: ignore "merge.log" config

"rebase -i" forgot that the comment character can be configurable
while reading its insn sheet.

* es/rebase-i-respect-core-commentchar:
  rebase -i: fix cases ignoring core.commentchar

The 'todo' sheet for interactive rebase shows abbreviated SHA-1's and
then performs its operations upon those shortened values. This can lead
to an abort if the SHA-1 of a reworded or edited commit is no longer
unique within the abbreviated SHA-1 space and a subsequent SHA-1 in the
todo list has the same abbreviated value.

For example:

  edit f00dfad first
  pick badbeef second

If, after editing, the new SHA-1 of "first" also has prefix badbeef,
then the subsequent 'pick badbeef second' will fail since badbeef is no
longer a unique SHA-1 abbreviation:

  error: short SHA1 badbeef is ambiguous.
  fatal: Needed a single revision
  Invalid commit name: badbeef

Fix this problem by expanding the SHA-1's in the todo list before
performing the operations.

[es: also collapse & expand SHA-1's for --edit-todo; respect
core.commentchar in transform_todo_ids(); compose commit message]

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

When "merge.log" config is set, "rebase --preserve-merges" will add
the log lines to the message of the rebased merge commit.  A rebase
should not modify a commit message automatically.

Teach "git-rebase" to ignore that configuration by passing
"--no-log" to the git-merge call.

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

180bad3d (rebase -i: respect core.commentchar, 2013-02-11) updated
"rebase -i" to honor core.commentchar but missed one instance of
hard-coded '#' comment character in skip_unnecessary_picks().

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

"git rebase [-i]" used to leave just "rebase" as its reflog message
for some operations. This rewords them to be more informative.

* rr/rebase-reflog-message-reword:
  rebase -i: use a better reflog message
  rebase: use a better reflog message