What's cooking in git.git (Apr 2010, #02; Sun, 04)

What's cooking in git.git (Apr 2010, #02; Sun, 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.

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

* mg/mailmap-update (2010-03-19) 1 commit
  (merged to 'next' on 2010-03-28 at 8ac3436)
 + .mailmap: Entries for Alex Bennée, Deskin Miller, Vitaly "_Vi" Shukela

* mg/maint-send-email-lazy-editor (2010-03-22) 1 commit
  (merged to 'next' on 2010-03-28 at 7e8e58e)
 + send-email: lazily assign editor variable

* mg/use-default-abbrev-length-in-rev-list (2010-03-22) 1 commit
  (merged to 'next' on 2010-03-28 at d3e9f04)
 + rev-list: use default abbrev length when abbrev-commit is in effect

* rb/maint-python-path (2010-03-21) 1 commit
  (merged to 'next' on 2010-03-28 at 58ba409)
 + Correct references to /usr/bin/python which does not exist on FreeBSD

* rr/imap-send-unconfuse-from-line (2010-03-22) 1 commit
  (merged to 'next' on 2010-03-28 at fbedd77)
 + imap-send: Remove limitation on message body

* sp/maint-http-backend-die-triggers-die-recursively (2010-03-22) 1 commit
  (merged to 'next' on 2010-03-28 at bf02879)
 + http-backend: Don't infinite loop during die()

* bc/t5505-fix (2010-03-19) 3 commits
  (merged to 'next' on 2010-03-28 at 1b097af)
 + t/t5505-remote.sh: escape * to prevent interpretation by shell as glob
 + t5505: add missing &&
 + t5505: remove unnecessary subshell invocations

* bw/template-tool-buildconfig (2010-03-20) 2 commits
  (merged to 'next' on 2010-03-28 at 1e6fd8d)
 + Modernize git calling conventions in hook templates
 + Make templates honour SHELL_PATH and PERL_PATH

* mb/rebase-i-no-ff (2010-03-24) 1 commit
  (merged to 'next' on 2010-03-28 at b2c54cb)
 + Teach rebase the --no-ff option.

* jn/merge-diff3-label (2010-03-20) 14 commits
  (merged to 'next' on 2010-03-20 at 26f1805)
 + merge-recursive: add a label for ancestor
 + cherry-pick, revert: add a label for ancestor
 + revert: clarify label on conflict hunks
 + compat: add mempcpy()
 + checkout -m --conflict=diff3: add a label for ancestor
 + merge_trees(): add ancestor label parameter for diff3-style output
 + merge_file(): add comment explaining behavior wrt conflict style
 + checkout --conflict=diff3: add a label for ancestor
 + ll_merge(): add ancestor label parameter for diff3-style output
 + merge-file --diff3: add a label for ancestor
 + xdl_merge(): move file1 and file2 labels to xmparam structure
 + xdl_merge(): add optional ancestor label to diff3-style output
 + tests: document cherry-pick behavior in face of conflicts
 + tests: document format of conflicts from checkout -m
 (this branch is used by cc/revert-strategy.)

* do/rebase-i-arbitrary (2010-03-14) 1 commit
  (merged to 'next' on 2010-03-28 at 5ba9970)
 + rebase--interactive: don't require what's rebased to be a branch

* ja/send-email-ehlo (2010-03-14) 3 commits
  (merged to 'next' on 2010-03-28 at 00964a8)
 + 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
  (merged to 'next' on 2010-03-28 at ae67548)
 + everyday: fsck and gc are not everyday operations

* bc/acl-test (2010-03-15) 5 commits
  (merged to 'next' on 2010-03-28 at b40fa09)
 + 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
  (merged to 'next' on 2010-03-28 at 305ad0b)
 + daemon.c: avoid accessing ss_family member of struct sockaddr_storage

* ef/cherry-abbrev (2010-03-20) 2 commits
  (merged to 'next' on 2010-03-28 at eb3825c)
 + ls: remove redundant logic
 + cherry: support --abbrev option

* gh/maint-stash-show-error-message (2010-03-16) 1 commit
  (merged to 'next' on 2010-03-28 at 61a5643)
 + Improve error messages from 'git stash show'

* rs/threaded-grep-context (2010-03-15) 1 commit
  (merged to 'next' on 2010-03-28 at 1934af1)
 + grep: enable threading for context line printing

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

* mh/status-optionally-refresh (2010-04-03) 3 commits
 - t7508: add a test for "git status" in a read-only repository
 - git status: refresh the index if possible
 - t7508: add test for "git status" refreshing the index

* jn/mailinfo-scissors (2010-04-03) 1 commit
 - Teach mailinfo %< as an alternative scissors mark

* tr/word-diff (2010-04-04) 2 commits
 - gitk: add the equivalent of diff --color-words
 - diff: add --word-diff option that generalizes --color-words

The tip "gitk" one I'd prefer to wait until we get Ack from Paulus.

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

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

* js/grep-open (2010-03-26) 2 commits
 - grep -O: allow optional argument specifying the pager (or editor)
 - grep: Add the option '--open-files-in-pager'

Probably needs to support --no-index mode as well.

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

* np/malloc-threading (2010-03-24) 1 commit
 - Make xmalloc and xrealloc thread-safe

Still has locking issues?

* js/async-thread (2010-03-09) 7 commits
 - Enable threaded async procedures whenever pthreads is available
  (merged to 'next' on 2010-03-20 at 9939243)
 + 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.

Waiting for resolution of locking issues in malloc-threading.

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

* 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

Nobody seems to care about "_git_frotz" that may potentially crash with
whatever random things the end users is doing in their environment, and
renaming them to "_git_complete_frotz" to avoid that.  So let's not worry
about that.

* cw/ws-indent-with-tab (2010-04-03) 6 commits
 - whitespace: tests for git-apply --whitespace=fix with tab-in-indent
 - whitespace: add tab-in-indent support for --whitespace=fix
 - whitespace: replumb ws_fix_copy to take a strbuf *dst instead of char *dst
 - whitespace: tests for git-diff --check with tab-in-indent error class
 - whitespace: add tab-in-indent error class
 - whitespace: we cannot "catch all errors known to git" anymore

Looked sensible.

* ic/bash-completion-rpm (2010-03-26) 1 commit
  (merged to 'next' on 2010-04-02 at 0358304)
 + RPM spec: include bash completion support

This is needed in 'master' by -rc1 at the latest.

* mg/notes-reflog (2010-03-29) 2 commits
 - refs.c: Write reflogs for notes just like for branch heads
 - t3301-notes: Test the creation of reflog entries

Implementation is trivially correct; I am unsure if "notes" tree wants
reflog in the first place, though.  Please convince me and I'll move it
to 'next' soon, aiming for -rc0 or -rc1 at the latest.

* rr/remote-helper-doc (2010-03-28) 2 commits
 - Documentation/remote-helpers: Fix some typos
 - Documentation/remote-helpers: Rewrite description

Although I lost track of this series with too rapid succession of
updates, intermixed with some documentation updates in the related
areas, my impression is that area experts haven't Acked them yet.

* sr/remote-helper-export (2010-03-29) 7 commits
 - remote-helpers: add tests for testgit helper
 - remote-helpers: add testgit helper
 - remote-helpers: add support for an export command
 - remote-helpers: allow requesing the path to the .git directory
 - fast-import: always create marks_file directories
 - clone: also configure url for bare clones
 - clone: pass the remote name to remote_get

May merge to 'next', but I would prefer waiting til 1.7.2 to have
this with a confidence than fast-tracking it.

* cc/revert-strategy (2010-03-31) 5 commits
 - revert: add "--strategy" option to choose merge strategy
 - merge: make function try_merge_command non static
 - merge: refactor code that calls "git merge-STRATEGY"
 - revert: refactor merge recursive code into its own function
 - revert: use strbuf to refactor the code that writes the merge message

May merge to 'next' soon, but this is more about debugging and we are not
in a great hurry.

* mr/gitweb-jsmin (2010-04-02) 6 commits
 - gitweb: update INSTALL to use shorter make target
 - gitweb: add documentation to INSTALL regarding gitweb.js
 - instaweb: add minification awareness
 - Gitweb: add autoconfigure support for minifiers
 - Gitweb: add support for minifying gitweb.css
 - Gitweb: add ignore and clean rules for minified files

Soon in 'next', to iron out leftover issues if any.

* sc/http-late-auth (2010-04-01) 1 commit
  (merged to 'next' on 2010-04-02 at c991acf)
 + Prompt for a username when an HTTP request 401s

I would prefer waiting til 1.7.2 to have this with a confidence than
fast-tracking it.

* jk/cached-textconv (2010-04-01) 7 commits
  (merged to 'next' on 2010-04-02 at a023e3c)
 + diff: avoid useless filespec population
 + diff: cache textconv output
 + textconv: refactor calls to run_textconv
 + introduce notes-cache interface
 + make commit_tree a library function
 + fix textconv leak in emit_rewrite_diff
 + fix const-correctness of write_sha1_file

I would prefer waiting til 1.7.2 to have this with a confidence than
fast-tracking it.

* da/maint-python-startup (2010-03-27) 1 commit
  (merged to 'next' on 2010-04-01 at ca6897a)
 + Makefile: Remove usage of deprecated Python "has_key" method

Hopefully will merge to 'master' by -rc0.

* jc/conflict-marker-size (2010-03-24) 1 commit
  (merged to 'next' on 2010-04-01 at 164b1f4)
 + diff --check: honor conflict-marker-size attribute

Hopefully will merge to 'master' by -rc0.

* ld/discovery-limit-to-fs (2010-04-04) 4 commits
 - GIT_ONE_FILESYSTEM: flip the default to stop at filesystem boundaries
 - Add support for GIT_ONE_FILESYSTEM
 - truncate cwd string before printing error message
 - config.c: remove static keyword from git_env_bool()

Linus made a good point of making this a default, and Erick Mattos
confirmed that it won't be a problem even on Windows.

The tip one is my attempt to do just that, but I have a feeling that
it is introducing a double-negation.  ONE-FILESYSTEM that defaults to
true but the user can flip it to false to trigger NOT-LIMITED-TO-ONE
semantics.  Perhaps it should be renamed to GIT_DISCOVER_REPOSITORY_XDEV
or something that defaults to false.

* sb/fmt-merge-msg (2010-03-24) 7 commits
  (merged to 'next' on 2010-04-01 at 5fcbec5)
 + fmt-merge-msg: hide summary option
 + fmt-merge-msg: remove custom string_list implementation
 + string-list: add unsorted_string_list_lookup()
 + fmt-merge-msg: use pretty.c routines
 + t6200: test fmt-merge-msg more
 + t6200: modernize with test_tick
 + fmt-merge-msg: be quiet if nothing to merge

Hopefully will merge to 'master' by -rc0.

* pc/remove-warn (2010-03-26) 4 commits
  (merged to 'next' on 2010-04-02 at 52fc00d)
 + Remove a redundant errno test in a usage of remove_path
 + Introduce remove_or_warn function
 + Implement the rmdir_or_warn function
 + Generalise the unlink_or_warn function

I cherry-picked only obviously sensible bits.

* ef/maint-empty-commit-log (2010-03-21) 1 commit
  (merged to 'next' on 2010-03-28 at aa103e5)
 + rev-list: fix --pretty=oneline with empty message

Hopefully will merge to 'master' by -rc0.

* em/checkout-orphan (2010-03-21) 1 commit
  (merged to 'next' on 2010-03-28 at 86b6a4f)
 + git checkout: create unparented branch by --orphan

Perhaps needs a bit of documentation updates, describing the "going open
source" scenario.

* ar/config-from-command-line (2010-03-26) 2 commits
 - Use strbufs instead of open-coded string manipulation
 - Allow passing of configuration parameters in the command line

May merge to 'next', but I would prefer waiting til 1.7.2 to have
this with a confidence than fast-tracking it.

* nd/setup (2010-03-25) 43 commits
 - builtins: do not commit pager choice early
 - builtins: reset startup_info->have_run_setup_gitdir when unsetting up repository
 - builtins: setup repository before print unknown command error
 - Guard unallowed access to repository when it's not set up
 - alias: keep repository found while collecting aliases as long as possible
 - Allow to undo setup_git_directory_gently() gracefully (and fix alias code)
 - builtins: check for startup_info->help, print and exit early
 - builtins: utilize startup_info->help where possible
 - run_builtin(): save "-h" detection result for later use
 - config: do not read .git/config if there is no repository
 - apply: do not check sha1 when repository has not been found
 - Do not read .git/info/attributes if there is no repository
 - Do not read .git/info/exclude if there is no repository
 - git_config(): do not read .git/config if there is no repository
 - init/clone: turn on startup->have_repository properly
 - worktree setup: restore original state when things go wrong
 - Use git_config_early() instead of git_config() during repo setup
 - Add git_config_early()
 - worktree setup: call set_git_dir explicitly
 - rev-parse --git-dir: print relative gitdir correctly
 - enter_repo(): initialize other variables as setup_git_directory_gently() does
 - Move enter_repo() to setup.c
 - 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

--------------------------------------------------
[Dropped]

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

I am hoping Carl or Michal Sojka can take the topic to completion without
my keeping an eye on it.  Waiting for the one with full set of Acks.

* hg/convert (2010-03-29) 5 commits
 . convert: Added core.refilteronadd feature.
 . convert: Inhibit contraction of foreign $Id$ during stats.
 . convert: Use the enum constant SAFE_CRLF_FALSE.
 . convert: Keep foreign $Id$ on checkout.
 . convert: Safer handling of $Id$ contraction.

The first two looked sensible but later one looked more like showing that
it may not have been a good idea in the first place.

Re: What's cooking in git.git (Apr 2010, #02; Sun, 04)

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 05.04.2010 03:14:
> 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.
> 
> --------------------------------------------------

> * mg/notes-reflog (2010-03-29) 2 commits
>  - refs.c: Write reflogs for notes just like for branch heads
>  - t3301-notes: Test the creation of reflog entries
> 
> Implementation is trivially correct; I am unsure if "notes" tree wants
> reflog in the first place, though.  Please convince me and I'll move it
> to 'next' soon, aiming for -rc0 or -rc1 at the latest.

I think that Jeff's impressive textconv caching is only the first of
many uses of notes where the notes ref is not a branch head with
continuously added history, but where the ref is being rewritten over
and over again. Also, people may rewrite their refs/notes/commits when
experimenting with remote notes trees.

In both cases, I deem the reflog "backup" a useful safety measure (just
as for other refs), and the automatic purging of the reflog provides
just the appropriate housekeeping.

Michael

Re: What's cooking in git.git (Apr 2010, #02; Sun, 04)

[Jeff King]

On Tue, Apr 06, 2010 at 09:12:44AM +0800, Michael J Gruber wrote:

> > * mg/notes-reflog (2010-03-29) 2 commits
> >  - refs.c: Write reflogs for notes just like for branch heads
> >  - t3301-notes: Test the creation of reflog entries
> > 
> > Implementation is trivially correct; I am unsure if "notes" tree wants
> > reflog in the first place, though.  Please convince me and I'll move it
> > to 'next' soon, aiming for -rc0 or -rc1 at the latest.
> 
> I think that Jeff's impressive textconv caching is only the first of
> many uses of notes where the notes ref is not a branch head with
> continuously added history, but where the ref is being rewritten over
> and over again. Also, people may rewrite their refs/notes/commits when
> experimenting with remote notes trees.
> 
> In both cases, I deem the reflog "backup" a useful safety measure (just
> as for other refs), and the automatic purging of the reflog provides
> just the appropriate housekeeping.

I agree. I don't expect people to want to look at their notes reflogs
very often, but we have become accustomed to having the reflog safety
net. It is often not until after the "oh crap" moment that the user
comes to the list and we tell them what the reflog is and how to
recover their lost data.

In the case of textconv caches, reflogs are not quite as important
because there is no lost data, only lost time. And as of now, we write a
large number of commits and trees that end up unreachable very quickly
(but only, of course, when encountering new items to cache).  But I
think that is a flaw in the notes-cache code. It should probably flush
the internal cache to a notes ref only on exit, not for every written
entry.

We had discussed dropping the expiration time for notes reflogs. Caches
could be 0 or very low (say 1 day), as recovery would primarily be about
experimentation with textconvs and recovering a cached state that is
slow to generate (e.g., you invalidate your cache by switching your
textconv, then switch it back; instead of regenerating your cache from
scratch, you find the latest cache commit that matches the textconv you
want. We could even do that automatically instead of clearing the cache,
but it is rare enough that I wouldn't bother).

General notes refs are probably useless after a week or two, since you
probably won't have the "oh no, I was working on this topic weeks ago
and I want to recover my partial work" moment that you do with regular
work. On the other hand, since they don't tend to have unreachable
entries, keeping them doesn't bloat the object database.

So that was a bit rambling perhaps, but the point is that I would rather
err on the side of having the reflog safety net and then later realize
we don't really want it, than vice versa.

-Peff

log --pretty/--oneline: ignore log.decorate

[Junio C Hamano]

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

> [Stalled]
>
> * 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.

This is necessary if we want to let users specify log.decorate and still
use gitk.  A patch should look like this (of course untested).

-- >8 --

Many scripts, most notably gitk, rely on output from the log family of
command not to be molested by random user configuration.  This is
especially true when --pretty=raw is given.

Just like we disable notes output unless the command line explicitly
asks for --show-notes, disable the decoration code unless --decorate is
given explicitly from the command line and --pretty or --oneline is
given.

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

---
 builtin-log.c  |   11 +++++++++++
 t/t4202-log.sh |   44 ++++++++++++++++++++++++++++----------------
 2 files changed, 39 insertions(+), 16 deletions(-)

diff --git a/builtin-log.c b/builtin-log.c
index 0afba31..7f4186f 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -53,6 +53,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
 		      struct rev_info *rev)
 {
 	int i;
+	int decoration_given = 0;
 
 	rev->abbrev = DEFAULT_ABBREV;
 	rev->commit_format = CMIT_FMT_DEFAULT;
@@ -89,11 +90,13 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
 		const char *arg = argv[i];
 		if (!strcmp(arg, "--decorate")) {
 			decoration_style = DECORATE_SHORT_REFS;
+			decoration_given = 1;
 		} else if (!prefixcmp(arg, "--decorate=")) {
 			const char *v = skip_prefix(arg, "--decorate=");
 			decoration_style = parse_decoration_style(arg, v);
 			if (decoration_style < 0)
 				die("invalid --decorate option: %s", arg);
+			decoration_given = 1;
 		} else if (!strcmp(arg, "--no-decorate")) {
 			decoration_style = 0;
 		} else if (!strcmp(arg, "--source")) {
@@ -103,6 +106,14 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
 		} else
 			die("unrecognized argument: %s", arg);
 	}
+
+	/*
+	 * defeat log.decorate configuration interacting with --pretty
+	 * from the command line.
+	 */
+	if (!decoration_given && rev->pretty_given)
+		decoration_style = 0;
+
 	if (decoration_style) {
 		rev->show_decorations = 1;
 		load_ref_decorations(decoration_style);
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 2230e60..166de44 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -390,50 +390,62 @@ test_expect_success 'log --graph with merge' '
 test_expect_success 'log.decorate configuration' '
 	git config --unset-all log.decorate || :
 
-	git log --oneline >expect.none &&
-	git log --oneline --decorate >expect.short &&
-	git log --oneline --decorate=full >expect.full &&
+	git log >expect.none &&
+	git log --decorate >expect.short &&
+	git log --decorate=full >expect.full &&
+	git log --oneline >expect.oneline &&
 
 	echo "[log] decorate" >>.git/config &&
-	git log --oneline >actual &&
+	git log >actual &&
 	test_cmp expect.short actual &&
+	git log --oneline >actual &&
+	test_cmp expect.oneline actual &&
 
 	git config --unset-all log.decorate &&
 	git config log.decorate true &&
-	git log --oneline >actual &&
+	git log >actual &&
 	test_cmp expect.short actual &&
-	git log --oneline --decorate=full >actual &&
+	git log --decorate=full >actual &&
 	test_cmp expect.full actual &&
-	git log --oneline --decorate=no >actual &&
+	git log --decorate=no >actual &&
 	test_cmp expect.none actual &&
+	git log --oneline >actual &&
+	test_cmp expect.oneline actual &&
 
 	git config --unset-all log.decorate &&
 	git config log.decorate no &&
-	git log --oneline >actual &&
+	git log >actual &&
 	test_cmp expect.none actual &&
-	git log --oneline --decorate >actual &&
+	git log --decorate >actual &&
 	test_cmp expect.short actual &&
-	git log --oneline --decorate=full >actual &&
+	git log --decorate=full >actual &&
 	test_cmp expect.full actual &&
+	git log --oneline >actual &&
+	test_cmp expect.oneline actual &&
 
 	git config --unset-all log.decorate &&
 	git config log.decorate short &&
-	git log --oneline >actual &&
+	git log >actual &&
 	test_cmp expect.short actual &&
-	git log --oneline --no-decorate >actual &&
+	git log --no-decorate >actual &&
 	test_cmp expect.none actual &&
-	git log --oneline --decorate=full >actual &&
+	git log --decorate=full >actual &&
 	test_cmp expect.full actual &&
+	git log --oneline >actual &&
+	test_cmp expect.oneline actual &&
 
 	git config --unset-all log.decorate &&
 	git config log.decorate full &&
-	git log --oneline >actual &&
+	git log >actual &&
 	test_cmp expect.full actual &&
-	git log --oneline --no-decorate >actual &&
+	git log --no-decorate >actual &&
 	test_cmp expect.none actual &&
-	git log --oneline --decorate >actual &&
+	git log --decorate >actual &&
 	test_cmp expect.short actual
+	git log --oneline >actual &&
+	test_cmp expect.oneline actual &&
 
+	:
 '
 
 test_done

Re: log --pretty/--oneline: ignore log.decorate

[Jeff King]

On Tue, Apr 06, 2010 at 02:48:55PM -0700, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > [Stalled]
> >
> > * 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.
> 
> This is necessary if we want to let users specify log.decorate and still
> use gitk.  A patch should look like this (of course untested).

Hmm. You took the "any --pretty" option with this patch.

And given the markups to the test suite:

> -	git log --oneline >expect.none &&
> -	git log --oneline --decorate >expect.short &&
> -	git log --oneline --decorate=full >expect.full &&
> +	git log >expect.none &&
> +	git log --decorate >expect.short &&
> +	git log --decorate=full >expect.full &&
> +	git log --oneline >expect.oneline &&

I suspect that will annoy users who have set log.decorate. Wouldn't they
expect to see it with "--oneline" if they have it configured (I would
guess that "git log" and "git log --oneline" are the most commonly
viewed forms by humans).

It seems reasonable to say "git log --pretty=raw should be consumable by
scripts", but I don't know that we need to do so for every pretty
format.

However:

  $ git grep oneline *.sh
  git-rebase--interactive.sh:             git rev-list $MERGES_OPTION --pretty=oneline --abbrev-commit \
  git-stash.sh:           head=$(git log --no-color --abbrev-commit --pretty=oneline -n 1 HEAD --)
  git-submodule.sh:                       git log --pretty=oneline --first-parent $range | wc -l

rebase--interactive properly uses rev-list. The submodule invocation
would uselessly look up the decoration, and the stash one would add it
to the stash commit message. But I am inclined to say that both of those
scripts are at fault, and should be converted to rev-list.

-Peff

Re: log --pretty/--oneline: ignore log.decorate

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

>> > * 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.
>> 
>> This is necessary if we want to let users specify log.decorate and still
>> use gitk.  A patch should look like this (of course untested).
>
> Hmm. You took the "any --pretty" option with this patch.

Yeah, I considered to further narrow it down to the --pretty=raw case;
because that is not something we do for the default --show-notes, I opted
for consistency.  But a decoration and notes are quite different, and
such a consistency perhaps is not worth it.  How about this on top?

-- >8 --
Subject: log: only "--pretty=raw" defeats log.decorate from the command line

Unlike notes that are often multi-line and disrupting to be placed in many
output formats, a decoration is designed to be a small token that can be
tacked after an existing line of the output where a commit object name sits.

Disabling log.decorate for something like "log --oneline" would defeat the
purpose of the configuration.

We _might_ want to change it further in the future to force scripts that
do not want to be broken by random end user configurations to explicitly
say "log --no-decorate", but that would be an incompatible change that
needs the usual multi-release-cycle deprecation process.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin-log.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/builtin-log.c b/builtin-log.c
index 7f4186f..017fcf8 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -108,10 +108,11 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
 	}
 
 	/*
-	 * defeat log.decorate configuration interacting with --pretty
+	 * defeat log.decorate configuration interacting with --pretty=raw
 	 * from the command line.
 	 */
-	if (!decoration_given && rev->pretty_given)
+	if (!decoration_given && rev->pretty_given
+	    && rev->commit_format == CMIT_FMT_RAW)
 		decoration_style = 0;
 
 	if (decoration_style) {

Re: log --pretty/--oneline: ignore log.decorate

[Jeff King]

On Thu, Apr 08, 2010 at 10:14:24AM -0700, Junio C Hamano wrote:

> Yeah, I considered to further narrow it down to the --pretty=raw case;
> because that is not something we do for the default --show-notes, I opted
> for consistency.  But a decoration and notes are quite different, and
> such a consistency perhaps is not worth it.  How about this on top?

Since I consider normal output, --pretty=raw, and --oneline to be the
only useful output formats for git-log, I think of the right behavior
as:

  - normal: show both by default, since that is the point of the
    features

  - raw: show neither, since we are probably parsed by a script

  - oneline: don't show notes, as they are inherently multi-line. Do
    show decorations, as they inherently fit the hash+subject model

User-formats are useful, too, but outside the scope, as they should
always show exactly what was requested, and nothing more.

For the other formats, I couldn't care less. So your patch is fine, but
I would also be fine with turning it back on _just_ for --oneline, and
leaving all other pretty formats with it disabled.

The patch itself looks fine. As you know, it needs to revert some of the
test updates from your previous tip.

We should also either apply on top or squash in:

-- >8 --
Subject: [PATCH] script with rev-list instead of log

Because log.decorate now shows decorations for --pretty=oneline,
we must explicitly turn it off when scripting. Otherwise,
users with log.decorate set will get cruft like:

  $ git stash
  Saved working directory and index state WIP on master:
    2c1f7f5 (HEAD, master) commit subject

Instead of adding --no-decorate to the log command line,
let's just use the rev-list plumbing interface instead,
which does the right thing.

git-submodule has a similar call. Since it just counts the
commit lines, nothing is broken, but let's switch it, too,
for the sake of consistency and cleanliness.

Signed-off-by: Jeff King <peff@peff.net>
---
I think these changes are Obviously Correct (tm), but please confirm
that I am not missing something subtle.

 git-stash.sh     |    2 +-
 git-submodule.sh |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/git-stash.sh b/git-stash.sh
index 62beae0..abaeee7 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -57,7 +57,7 @@ create_stash () {
 	# state of the base commit
 	if b_commit=$(git rev-parse --verify HEAD)
 	then
-		head=$(git log --no-color --abbrev-commit --pretty=oneline -n 1 HEAD --)
+		head=$(git rev-list --oneline -n 1 HEAD --)
 	else
 		die "You do not have the initial commit yet"
 	fi
diff --git a/git-submodule.sh b/git-submodule.sh
index 2dd372a..187461c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -648,7 +648,7 @@ cmd_summary() {
 				range=$sha1_dst
 			fi
 			GIT_DIR="$name/.git" \
-			git log --pretty=oneline --first-parent $range | wc -l
+			git rev-list --first-parent $range -- | wc -l
 			)
 			total_commits=" ($(($total_commits + 0)))"
 			;;
-- 
1.7.1.rc0.248.g055378.dirty

Re: log --pretty/--oneline: ignore log.decorate

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Subject: [PATCH] script with rev-list instead of log
>
> Because log.decorate now shows decorations for --pretty=oneline,
> we must explicitly turn it off when scripting. Otherwise,
> users with log.decorate set will get cruft like:
>
>   $ git stash
>   Saved working directory and index state WIP on master:
>     2c1f7f5 (HEAD, master) commit subject
>
> Instead of adding --no-decorate to the log command line,
> let's just use the rev-list plumbing interface instead,
> which does the right thing.
>
> git-submodule has a similar call. Since it just counts the
> commit lines, nothing is broken, but let's switch it, too,
> for the sake of consistency and cleanliness.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I think these changes are Obviously Correct (tm)

Looks good; thanks.