git/git-sh-setup.sh, branch v2.0.2

git-sh-setup.sh: add variable to use the stuck-long mode

2014-02-03T20:11:10Z

If the variable $OPTIONS_STUCKLONG is not empty, then rev-parse option parsing is done in --stuck-long mode. Signed-off-by: Nicolas Vigier Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'jn/pager-lv-default-env'

2014-01-13T19:33:35Z

Just like we give a reasonable default for "less" via the LESS environment variable, specify a reasonable default for "lv" via the "LV" environment variable when spawning the pager. * jn/pager-lv-default-env: pager: set LV=-c alongside LESS=FRSX

pager: set LV=-c alongside LESS=FRSX

2014-01-07T17:23:41Z

On systems with lv configured as the preferred pager (i.e., DEFAULT_PAGER=lv at build time, or PAGER=lv exported in the environment) git commands that use color show control codes instead of color in the pager: $ git diff ^[[1mdiff --git a/.mailfilter b/.mailfilter^[[m ^[[1mindex aa4f0b2..17e113e 100644^[[m ^[[1m--- a/.mailfilter^[[m ^[[1m+++ b/.mailfilter^[[m ^[[36m@@ -1,11 +1,58 @@^[[m "less" avoids this problem because git uses the LESS environment variable to pass the -R option ('output ANSI color escapes in raw form') by default. Use the LV environment variable to pass 'lv' the -c option ('allow ANSI escape sequences for text decoration / color') to fix it for lv, too. Noticed when the default value for color.ui flipped to 'auto' in v1.8.4-rc0~36^2~1 (2013-06-10). Reported-by: Olaf Meeuwissen Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

remove #!interpreter line from shell libraries

2013-11-26T22:23:56Z

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 Signed-off-by: Junio C Hamano

Merge branch 'jc/reflog-doc'

2013-10-18T20:50:12Z

Document rules to use GIT_REFLOG_ACTION variable in the scripted Porcelain. git-rebase--interactive locally violates them, but it is a leaf user that does not call out to or dot-source other scripts, so it does not urgently need to be fixed. * jc/reflog-doc: setup_reflog_action: document the rules for using GIT_REFLOG_ACTION

die_with_status: use "printf '%s\n'", not "echo"

2013-08-07T15:49:49Z

Some implementations of 'echo' (e.g. dash's built-in) interpret backslash sequences in their arguments. This triggered at least one bug: the error message of "rebase -i" was turning \t in commit messages into actual tabulations. There may be others. Using "printf '%s\n'" instead avoids this bad behavior, and is the form used by the "say" function. Noticed-by: David Kastrup Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

setup_reflog_action: document the rules for using GIT_REFLOG_ACTION

2013-06-19T17:54:00Z

The set_reflog_action helper (in git-sh-setup) is designed to be used once at the very top of a program, like this in "git am", for example: set_reflog_action am The helper function sets the given string to GIT_REFLOG_ACTION only when GIT_REFLOG_ACTION is not yet set. Thanks to this, "git am", when run as the top-level program, will use "am" in GIT_REFLOG_ACTION and the reflog entries made by whatever it does will record the updates of refs done by "am". Because of the conditional assignment, when "git am" is run as a subprogram (i.e. an implementation detail) of "git rebase" that already sets GIT_REFLOG_ACTION to its own name, the call in "git am" to the helper function at the beginning will *not* have any effect. So "git rebase" can do this: set_reflog_action rebase ... do its own preparation, like checking out "onto" commit ... decide to do "format-patch" to "am" pipeline git format-patch --stdout >mbox git am mbox and the reflog entries made inside "git am" invocation will say "rebase", not "am". Calls to "git" commands that update refs would use GIT_REFLOG_ACTION to record who did that update. Most such calls in scripted Porcelains do not define custom reflog message and rely on GIT_REFLOG_ACTION to contain its (or its caller's, when it is called as a subprogram) name. If a scripted Porcelain wants to record a custom reflog message for a single invocation of "git" command (e.g. when "git rebase" uses "git checkout" to detach HEAD at the commit a series is to be replayed on), it needs to set GIT_REFLOG_ACTION to the custom message and export it while calling the "git" command, but such an assignment must be restricted to that single "git" invocation and should not be left behind to affect later codepath. Document the rules to avoid future confusion. Signed-off-by: Junio C Hamano

sh-setup: add new peel_committish() helper

2013-06-14T16:41:03Z

The normal way to check whether a certain revision resolves to a valid commit is: $ git rev-parse --verify $REV^0 Unfortunately, this does not work when $REV is of the type :/quuxery. Write a helper to work around this limitation. Suggested-by: Junio C Hamano Signed-off-by: Ramkumar Ramachandra Signed-off-by: Junio C Hamano

Merge branch 'kb/p4merge'

2013-03-26T20:15:24Z

Adjust the order mergetools feeds the files to the p4merge backend to match the p4 convention. * kb/p4merge: merge-one-file: force content conflict for "both sides added" case git-merge-one-file: send "ERROR:" messages to stderr git-merge-one-file: style cleanup merge-one-file: remove stale comment mergetools/p4merge: create a base if none available mergetools/p4merge: swap LOCAL and REMOTE

mergetools/p4merge: create a base if none available

2013-03-13T17:46:07Z

Originally, with no base, Git gave P4Merge $LOCAL as a dummy base: p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED" Commit 0a0ec7bd changed this to: p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED" to avoid the problem of being unable to save in some circumstances with similar inputs. Unfortunately this approach produces much worse results on differing inputs. P4Merge really regards the blank file as the base, and once you have just a couple of differences between the two branches you end up with one a massive full-file conflict. The 3-way diff is not readable, and you have to invoke "difftool MERGE_HEAD HEAD" manually to get a useful view. The original approach appears to have invoked special 2-way merge behaviour in P4Merge that occurs only if the base filename is "" or equal to the left input. You get a good visual comparison, and it does not auto-resolve differences. (Normally if one branch matched the base, it would autoresolve to the other branch). But there appears to be no way of getting this 2-way behaviour and being able to reliably save. Having base==left appears to be triggering other assumptions. There are tricks the user can use to force the save icon on, but it's not intuitive. So we now follow a suggestion given in the original patch's discussion: generate a virtual base, consisting of the lines common to the two branches. This is the same as the technique used in resolve and octopus merges, so we relocate that code to a shared function. Note that if there are no differences at the same location, this technique can lead to automatic resolution without conflict, combining everything from the 2 files. As with the other merges using this technique, we assume the user will inspect the result before saving. Signed-off-by: Kevin Bracey Reviewed-by: David Aguilar Signed-off-by: Junio C Hamano