What's cooking in git.git

What's cooking in git.git

[Junio C Hamano]

This is still a draft but only to show the highlights on new topics.

* bb/remote-get-url (2015-08-05) 1 commit
 - remote: add get-url subcommand

 "git remote" learned "get-url" subcommand to show the URL for a
 given remote name used for fetching and pushing.

 Expecting a reroll.


* dt/untracked-subdir (2015-08-05) 2 commits
 - DONTMERGE: Waiting for an Ack from Duy
 - untracked-cache: fix subdirectory handling
 (this branch uses dt/untracked-sparse.)

 This seems to break some tests.



* cb/open-noatime-clear-errno (2015-08-05) 1 commit
 - git_open_noatime: return with errno=0 on success

 Breaks build; need to tweak.


* jk/guess-repo-name-regression-fix (2015-08-05) 2 commits
 - clone: use computed length in guess_dir_name
 - clone: add tests for output directory
 (this branch is used by ps/guess-repo-name-at-root.)

 "git clone $URL" in recent releases of Git contains a regression in
 the code that invents a new repository name incorrectly based on
 the $URL.  This has been corrected.

 May need some tests from SQUASH??? on ps/guess-repo-name-at-root
 squashed into this, but otherwise looks good.


* ps/guess-repo-name-at-root (2015-08-05) 4 commits
 - SQUASH???
 - clone: abort if no dir name could be guessed
 - clone: do not use port number as dir name
 - clone: do not include authentication data in guessed dir
 (this branch uses jk/guess-repo-name-regression-fix.)

 "git clone $URL", when cloning from a site whose sole purpose is to
 host a single repository (hence, no path after <scheme>://<site>/),
 tried to used the site name as the new repository name, but did
 not remove username or password when <site> part was of the form
 <user>@<pass>:<host>.  The code is taught to redact these.


* jk/notes-merge-config (2015-08-05) 4 commits
 - SQUASH???
 - notes: add notes.merge option to select default strategy
 - notes: add tests for --commit/--abort/--strategy exclusivity
 - notes: document cat_sort_uniq rewriteMode

 "git notes merge" can be told with "--strategy=<how>" option how to
 automatically handle conflicts; this can now be configured by
 setting notes.merge configuration variable.

 The last step to add more specific notes.$ref.merge looked
 questionable.

 Waiting for reroll.


* mk/submodule-gitdir-path (2015-08-05) 2 commits
 - path: implement common_dir handling in git_path_submodule()
 - submodule refactor: use git_path_submodule() in add_submodule_odb()

 The submodule code has been taught to work better with separate
 work trees created via "git worktree add".


* mm/pull-upload-pack (2015-07-30) 1 commit
 - pull.sh: quote $upload_pack when passing it to git-fetch

 "git pull" in recent releases of Git has a regression in the code
 that allows custom path to the --upload-pack=<program>.  This has
 been corrected.

 Will merge to 'maint'.

 This should have already become irrelevant in 'master' with "git
 pull" getting rewritten in C.


* ps/t1509-chroot-test-fixup (2015-08-05) 2 commits
 - tests: fix cleanup after tests in t1509-root-worktree
 - tests: fix broken && chains in t1509-root-worktree

 t1509 test that requires a dedicated VM environment had some
 bitrot, which has been corrected.

 Will merge to 'next'.


* pt/am-builtin-options (2015-08-05) 4 commits
 - am: let --signoff override --no-signoff
 - am: let command-line options override saved options
 - squash! test_terminal: redirect child process' stdin to a pty
 - test_terminal: redirect child process' stdin to a pty
 (this branch uses pt/am-builtin.)

 After "git am --opt1" stops, running "git am --opt2" pays attention
 to "--opt2" only for the patch that caused the original invocation
 to stop.


* sb/remove-get-pathspec (2015-08-03) 1 commit
 - builtin/mv: remove get_pathspec()

 Expecting a reroll ($gmane/275224).


* sb/submodule-helper (2015-08-05) 1 commit
 - submodule: implement `module_list` as a builtin helper

 The beginning of "git submodule" rewritten in C.


* tb/complete-rebase-i-edit-todo (2015-08-05) 1 commit
 - completion: offer '--edit-todo' during interactive rebase

 Comments?


* jk/negative-hiderefs (2015-07-28) 2 commits
 - refs: support negative transfer.hideRefs
 - docs/config.txt: reorder hideRefs config

 Allow negative !ref entry in multi-value transfer.hideRefs
 configuration to say "don't hide this one".

 An update to test coming?

Re: What's cooking in git.git

[David Turner]

On Wed, 2015-08-05 at 15:55 -0700, Junio C Hamano wrote:
> * dt/untracked-subdir (2015-08-05) 2 commits
>  - DONTMERGE: Waiting for an Ack from Duy
>  - untracked-cache: fix subdirectory handling
>  (this branch uses dt/untracked-sparse.)
> 
>  This seems to break some tests.

All tests pass for me locally.  What's broken for you?

Re: What's cooking in git.git

[Junio C Hamano]

David Turner <dturner@twopensource.com> writes:

> On Wed, 2015-08-05 at 15:55 -0700, Junio C Hamano wrote:
>> * dt/untracked-subdir (2015-08-05) 2 commits
>>  - DONTMERGE: Waiting for an Ack from Duy
>>  - untracked-cache: fix subdirectory handling
>>  (this branch uses dt/untracked-sparse.)
>> 
>>  This seems to break some tests.
>
> All tests pass for me locally.  What's broken for you?


*** prove ***
t7063-status-untracked-cache.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 3/30 subtests

Test Summary Report
-------------------
t7063-status-untracked-cache.sh (Wstat: 256 Tests: 30 Failed: 3)
  Failed tests:  28-30
  Non-zero exit status: 1
Files=1, Tests=30, 27 wallclock secs ( 0.04 usr  0.01 sys +  0.15 cusr  0.67 csys =  0.87 CPU)
Result: FAIL

$ sh t7063-status-untracked-cache -i -v

ends like so:

...
node creation: 2
gitignore invalidation: 0
directory invalidation: 1
opendir: 3
EOF
        test_cmp ../trace.expect ../trace

strace: invalid option -- 'k'
usage: strace [-CdffhiqrtttTvVxxy] [-I n] [-e expr]...
              [-a column] [-o file] [-s strsize] [-P path]...
              -p pid... / [-D] [-E var=val]... [-u username] PROG [ARGS]
   or: strace -c[df] [-I n] [-e expr]... [-O overhead] [-S sortby]
              -p pid... / [-D] [-E var=val]... [-u username] PROG [ARGS]
-c -- count time, calls, and errors for each syscall and report summary
-C -- like -c but also print regular output
-d -- enable debug output to stderr
-D -- run tracer process as a detached grandchild, not as parent
-f -- follow forks, -ff -- with output into separate files
-i -- print instruction pointer at time of syscall
-q -- suppress messages about attaching, detaching, etc.
-r -- print relative timestamp, -t -- absolute timestamp, -tt -- with usecs
-T -- print time spent in each syscall
-v -- verbose mode: print unabbreviated argv, stat, termios, etc. args
-x -- print non-ascii strings in hex, -xx -- print all strings in hex
-y -- print paths associated with file descriptor arguments
-h -- print help message, -V -- print version
-a column -- alignment COLUMN for printing syscall results (default 40)
-b execve -- detach on this syscall
-e expr -- a qualifying expression: option=[!]all or option=[!]val1[,val2]...
   options: trace, abbrev, verbose, raw, signal, read, write
-I interruptible --
   1: no signals are blocked
   2: fatal signals are blocked while decoding syscall (default)
   3: fatal signals are always blocked (default if '-o FILE PROG')
   4: fatal signals and SIGTSTP (^Z) are always blocked
      (useful to make 'strace -o FILE PROG' not stop on ^Z)
-o file -- send trace output to FILE instead of stderr
-O overhead -- set overhead for tracing syscalls to OVERHEAD usecs
-p pid -- trace process with process id PID, may be repeated
-s strsize -- limit length of print strings to STRSIZE chars (default 32)
-S sortby -- sort syscall counts by: time, calls, name, nothing (default time)
-u username -- run command as username handling setuid and/or setgid
-E var=val -- put var=val in the environment for command
-E var -- remove var from the environment for command
-P path -- trace accesses to path
not ok 28 - test sparse status with untracked cache and subdir

Re: What's cooking in git.git

[Junio C Hamano]

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

> David Turner <dturner@twopensource.com> writes:
>
>> On Wed, 2015-08-05 at 15:55 -0700, Junio C Hamano wrote:
>>> * dt/untracked-subdir (2015-08-05) 2 commits
>>>  - DONTMERGE: Waiting for an Ack from Duy
>>>  - untracked-cache: fix subdirectory handling
>>>  (this branch uses dt/untracked-sparse.)
>>> 
>>>  This seems to break some tests.
>>
>> All tests pass for me locally.  What's broken for you?
>
> *** prove ***
> t7063-status-untracked-cache.sh .. Dubious, test returned 1 (wstat 256, 0x100)
> Failed 3/30 subtests
>
> Test Summary Report
> -------------------
> t7063-status-untracked-cache.sh (Wstat: 256 Tests: 30 Failed: 3)
>   Failed tests:  28-30
>   Non-zero exit status: 1
> Files=1, Tests=30, 27 wallclock secs ( 0.04 usr  0.01 sys +  0.15 cusr  0.67 csys =  0.87 CPU)
> Result: FAIL

So it turns out that you run "strace -k -o /tmp/tr" and never look
at /tmp/tr; I am guessing that this was a remnant of your debugging
while developing the test, sign of lack of proofreading before
sending the patch out, perhaps?

I didn't carefully read the remainder of the patch, but at the
minimum this needs to be squashed in.  They may be a reroll with
some more tweaks from you after other people comment on it, so I'll
keep this separate and squashable.

Thanks.

 t/t7063-status-untracked-cache.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t7063-status-untracked-cache.sh b/t/t7063-status-untracked-cache.sh
index bb0e2a9..ca8dc3a 100755
--- a/t/t7063-status-untracked-cache.sh
+++ b/t/t7063-status-untracked-cache.sh
@@ -486,7 +486,7 @@ test_expect_success 'test sparse status with untracked cache and subdir' '
 	avoid_racy &&
 	: >../trace &&
 	GIT_TRACE_UNTRACKED_STATS="$TRASH_DIRECTORY/trace" \
-	strace -k -o /tmp/st git status --porcelain >../status.actual &&
+	git status --porcelain >../status.actual &&
 	cat >../status.expect <<EOF &&
  M done/two
 ?? .gitignore

Re: What's cooking in git.git

[Jeff King]

On Wed, Aug 05, 2015 at 03:55:23PM -0700, Junio C Hamano wrote:

> * jk/negative-hiderefs (2015-07-28) 2 commits
>  - refs: support negative transfer.hideRefs
>  - docs/config.txt: reorder hideRefs config
> 
>  Allow negative !ref entry in multi-value transfer.hideRefs
>  configuration to say "don't hide this one".
> 
>  An update to test coming?

Thanks for reminding me. I think we just want to squash this in to the
tip commit:

diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
index afde495..7756100 100755
--- a/t/t5512-ls-remote.sh
+++ b/t/t5512-ls-remote.sh
@@ -150,7 +150,8 @@ do
 		git config --add $configsection.hiderefs "!refs/tags/magic" &&
 		git config --add $configsection.hiderefs refs/tags/magic/one &&
 		git ls-remote . >actual &&
-		verbose grep refs/tags/magic/two actual
+		verbose grep refs/tags/magic/two actual &&
+		! grep refs/tags/magic/one actual
 	'
 
 done

-Peff

PS I don't recall the outcome of our last discussion on the "verbose"
   test function. Here it makes debug output for the "grep" above more
   readable when it fails. But it also looks weird not to have the
   matching negative one for the final grep (which could be
   test_must_fail in this case, but we do not usually apply that to
   non-git commands). If you would prefer to strip out the "verbose"
   (from here and the test just below) while squashing, I am OK with
   that.

[PATCH 0/2] ./t5512-*.sh -x complaints

[Jeff King]

On Thu, Aug 06, 2015 at 12:55:35AM -0400, Jeff King wrote:

> PS I don't recall the outcome of our last discussion on the "verbose"
>    test function. Here it makes debug output for the "grep" above more
>    readable when it fails. But it also looks weird not to have the
>    matching negative one for the final grep (which could be
>    test_must_fail in this case, but we do not usually apply that to
>    non-git commands). If you would prefer to strip out the "verbose"
>    (from here and the test just below) while squashing, I am OK with
>    that.

Here's a squashable patch for that, in case it is easier (on top of the
previous squash; I am happy to just send a re-rolled patch if you'd
prefer):

diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
index 7756100..aadaac5 100755
--- a/t/t5512-ls-remote.sh
+++ b/t/t5512-ls-remote.sh
@@ -150,7 +150,7 @@ do
 		git config --add $configsection.hiderefs "!refs/tags/magic" &&
 		git config --add $configsection.hiderefs refs/tags/magic/one &&
 		git ls-remote . >actual &&
-		verbose grep refs/tags/magic/two actual &&
+		grep refs/tags/magic/two actual &&
 		! grep refs/tags/magic/one actual
 	'
 
@@ -160,7 +160,7 @@ test_expect_success 'overrides work between mixed transfer/upload-pack hideRefs'
 	test_config uploadpack.hiderefs refs/tags &&
 	test_config transfer.hiderefs "!refs/tags/magic" &&
 	git ls-remote . >actual &&
-	verbose grep refs/tags/magic actual
+	grep refs/tags/magic actual
 '
 
 test_done

I think the last discussion did end up with "eh, now that we have -x it
is simpler to just use that". Of course, then I tried to _use_ -x and
found some small niggles.  So here are fixes for those:

  [1/2]: test-lib: turn off "-x" tracing during chain-lint check
  [2/2]: test-lib: disable trace when test is not verbose

-Peff

[PATCH 1/2] test-lib: turn off "-x" tracing during chain-lint check

[Jeff King]

Now that GIT_TEST_CHAIN_LINT is on by default, running:

    ./t0000-basic.sh -x --verbose-only=1

starts with:

    expecting success:
            find .git/objects -type f -print >should-be-empty &&
            test_line_count = 0 should-be-empty

    + exit 117
    error: last command exited with $?=117
    + find .git/objects -type f -print
    + test_line_count = 0 should-be-empty
    + test 3 != 3
    + wc -l
    + test 0 = 0
    ok 1 - .git/objects should be empty after git init in an empty repo

This is confusing, as the "exit 117" line and the error line
(which is printed in red, no less!) are not part of the test
at all, but are rather in the separate chain-lint test_eval.
Let's unset the "trace" variable when eval-ing the chain
lint check, which avoids this.

Note that we cannot just do a one-shot variable like:

    trace= test_eval ...

as the behavior of one-shot variables for function calls
is not portable.

Signed-off-by: Jeff King <peff@peff.net>
---
 t/test-lib.sh | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index cea6cda..374bfcb 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -571,12 +571,17 @@ test_run_ () {
 	expecting_failure=$2
 
 	if test "${GIT_TEST_CHAIN_LINT:-1}" != 0; then
+		# turn off tracing for this test-eval, as it simply creates
+		# confusing noise in the "-x" output
+		trace_tmp=$trace
+		trace=
 		# 117 is magic because it is unlikely to match the exit
 		# code of other programs
 		test_eval_ "(exit 117) && $1"
 		if test "$?" != 117; then
 			error "bug in the test script: broken &&-chain: $1"
 		fi
+		trace=$trace_tmp
 	fi
 
 	setup_malloc_check
-- 
2.5.0.148.g63828c1

[PATCH 2/2] test-lib: disable trace when test is not verbose

[Jeff King]

The "-x" test-script option turns on the shell's "-x"
tracing, which can help show why a particular test is
failing. Unfortunately, this can create false negatives in
some tests if they invoke a shell function with its stderr
redirected. t5512.10 is such a test, as it does:

    test_must_fail git ls-remote refs*master >actual 2>&1 &&
    test_cmp exp actual

The "actual" file gets the "-x" trace for the test_must_fail
function, which prevents it from matching the expected
output.

There's no way to avoid this without managing the
trace flag inside each sub-function, which isn't really a
workable solution. But unless you specifically care about
t5512.10, we can work around it by enabling tracing only for
the specific tests we want.

You can already do:

    ./t5512-ls-remote.sh -x --verbose-only=16

to see the trace only for a specific test. But that doesn't
_disable_ the tracing in the other tests; it just sends it
to /dev/null. However, there's no point in generating a
trace that the user won't see, so we can simply disable
tracing whenever it doesn't have a matching verbose flag.

The normal case of just "./t5512-ls-remote.sh -x" stays the
same, as "-x" already implies "--verbose" (and
"--verbose-only" overrides "--verbose", which is why this
works at all). And for our test, we need only check
$verbose, as maybe_setup_verbose will have already
set that flag based on the $verbose_only list).

Signed-off-by: Jeff King <peff@peff.net>
---
 t/test-lib.sh | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index 374bfcb..16c4d7b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -531,6 +531,10 @@ maybe_setup_valgrind () {
 	fi
 }
 
+want_trace () {
+	test "$trace" = t && test "$verbose" = t
+}
+
 # This is a separate function because some tests use
 # "return" to end a test_expect_success block early
 # (and we want to make sure we run any cleanup like
@@ -538,7 +542,7 @@ maybe_setup_valgrind () {
 test_eval_inner_ () {
 	# Do not add anything extra (including LF) after '$*'
 	eval "
-		test \"$trace\" = t && set -x
+		want_trace && set -x
 		$*"
 }
 
@@ -554,7 +558,7 @@ test_eval_ () {
 	{
 		test_eval_inner_ "$@" </dev/null >&3 2>&4
 		test_eval_ret_=$?
-		if test "$trace" = t
+		if want_trace
 		then
 			set +x
 			if test "$test_eval_ret_" != 0
-- 
2.5.0.148.g63828c1

Re: What's cooking in git.git

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> PS I don't recall the outcome of our last discussion on the "verbose"
>    test function. Here it makes debug output for the "grep" above more
>    readable when it fails. But it also looks weird not to have the
>    matching negative one for the final grep (which could be
>    test_must_fail in this case, but we do not usually apply that to
>    non-git commands). If you would prefer to strip out the "verbose"
>    (from here and the test just below) while squashing, I am OK with
>    that.

Yeah, let's do that then.

Re: What's cooking in git.git

[Johannes Schindelin]

Hi Junio,

On 2015-08-06 00:55, Junio C Hamano wrote:

> * sb/submodule-helper (2015-08-05) 1 commit
>  - submodule: implement `module_list` as a builtin helper
> 
>  The beginning of "git submodule" rewritten in C.

I am really looking forward to that, with my Windows performance hat firmly on my head.

> * tb/complete-rebase-i-edit-todo (2015-08-05) 1 commit
>  - completion: offer '--edit-todo' during interactive rebase
> 
>  Comments?

The problem fixed by this one has bugged me plenty of times. I often need to edit the TODO e.g. when I managed to get the reordering wrong and want to insert a `pick <commit>` later in the `git-rebase-todo` and then call `git rebase --skip`.

Read: I am very much in favor of fast-tracking this topic.

Thanks,
Dscho

What's cooking in git.git

[Junio C Hamano]

I think the last issue in "consolidated topic listing" format
was a success, so this is in the same format.  In the following
listing, a commit in 'next' has '+' in front, and the ones only
in 'pu' have '-' in front.  The date after each topic name is
the last time the topic was touched.

* jc/diff--cached (Wed Dec 13 01:33:43 2006 -0800) 1 commit
 + Revert "git-diff: Introduce --index and deprecate --cached."

Will merge to 'master' shortly and will be in v1.5.0.

* jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits
 - git-add --interactive: hunk splitting
 - git-add --interactive

Undecided.  Either drop it altogether or merge it to 'next'
after adding 'edit' interface to the index contents.

* jn/web (Sun Dec 10 13:25:49 2006 +0100) 5 commits
 + gitweb: SHA-1 in commit log message links to "object" view
 + gitweb: Hyperlink target of symbolic link in "tree" view (if
   possible)
 + gitweb: Add generic git_object subroutine to display object of any
   type
 + gitweb: Show target of symbolic link in "tree" view
 + gitweb: Don't use Content-Encoding: header in git_snapshot

Haven't looked at them fully, but likely to be in v1.5.0.

* jc/blame-boundary (Fri Dec 1 20:45:45 2006 -0800) 1 commit
 + git-blame: show lines attributed to boundary commits differently.

This does not break gitweb nor git-cvsserver because they have
no way to specify boundary commits.  Likely to be in v1.5.0.

Later we can update gitweb to allow specifying the range and
handle 'boundary' annotations in a special way.

* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain

We probably should come up with a unified way to allow various
commands that can leave the working tree into special states to
communicate with each other first.  Will NOT be in v1.5.0.

* jc/patch-inline-comments (Fri Dec 8 21:03:52 2006 -0800) 1 commit
 - mailinfo: hack to accept in-line annotations in patches.

Will drop.

* sv/git-svn (Tue Dec 5 16:17:38 2006 +1100) 5 commits
 - git-svn: re-map repository URLs and UUIDs on SVK mirror paths
 - git-svn: collect revision properties when fetching
 - git-svn: collect SVK source URL on mirror paths
 - git-svn: let libsvn_ls_fullurl return properties too
 - git-svn: make test for SVK mirror path import

Sam Villain's SVN fixes are queued in 'pu' but the series hasn't
seen updates after Eric commented on them.  Still on hold.

* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward

This does the magic unconditionally which I am not 100% happy
about, because the resulting mess could be too large to handle.
On the other hand, the user deserves what he gets if he starts a
merge from wildly unclean state, so it may not be too much of an
issue.  Undecided.

* jc/leftright (Sun Oct 22 17:32:47 2006 -0700) 1 commit
 - rev-list --left-right

I think this needs a better UI integration into 'git log' and
friends, not just rev-list.  Currently, I can say:

  $ git rev-list --no-merges --left-right --pretty v1.4.4.2...master

but that still misses --stat and --patch output.  If people find
this useful, maybe we would want to merge it to 'next' after
adding the option to log and friends (or turn it on
automatically when symmetric difference is used).

* js/shallow (Fri Nov 24 16:00:13 2006 +0100) 15 commits
 + fetch-pack: Do not fetch tags for shallow clones.
 + get_shallow_commits: Avoid memory leak if a commit has been
   reached already.
 + git-fetch: Reset shallow_depth before auto-following tags.
 + upload-pack: Check for NOT_SHALLOW flag before sending a shallow
   to the client.
 + fetch-pack: Properly remove the shallow file when it becomes
   empty.
 + shallow clone: unparse and reparse an unshallowed commit
 + Why didn't we mark want_obj as ~UNINTERESTING in the old code?
 + Why does it mean we do not have to register shallow if we have
   one?
 + We should make sure that the protocol is still extensible.
 + add tests for shallow stuff
 + Shallow clone: do not ignore shallowness when following tags
 + allow deepening of a shallow repository
 + allow cloning a repository "shallowly"
 + support fetching into a shallow repository
 + upload-pack: no longer call rev-list

The 'shallow clone'.  Most likely post v1.5.0.

* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org

If somebody steps up to maintain the gitweb installation at
kernel.org, merging this would make one less thing to customize
there.  Undecided.

* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.

This is developer-only; will hold.

* jc/diff (Mon Sep 25 23:03:34 2006 -0700) 1 commit
 - para-walk: walk n trees, index and working tree in parallel

Backburnered and will continue to hold.  I suspect unpack-trees
logic that is used by read-tree would turn out to be too
cumbersome to optimize and at that point this might become
useful.

* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

Will hold until February.

What's cooking in git.git

[Junio C Hamano]

I have queued the following for the maintenance branches.

For both 1.0.X and 1.1.X series:

 - update-index: work with c-quoted name
 - show-branch: handle [] globs as well.
 - name-rev: do not omit leading components of ref name.

For 1.1.X series only:

 - Add git-describe to .gitignore.
 - describe: do not silently ignore indescribable commits

I plan to do 1.0.10 [*1*] and 1.1.2 sometime this weekend, along
with some other fixes that would appear until then.

On the development front, I have these in the proposed updates
branch:

 - Exec git programs without using PATH (Michal Ostrowski).

   This has been discussed for the last couple of days on the
   list.  I think C side is ready to go in, but I'd like to
   decide what to do on the scripting side before merging it
   into the master branch.

 - Disable USE_SYMLINK_HEAD by default (Pavel Roskin).

   This has been on hold for almost two months -- forever in git
   timescale.

   One offender that could have been broken by this change was
   fixed recently (gitweb), so this can go in anytime now.  Do
   people still care about it?  The argument for the change when
   it was proposed was "then we only have to worry about one
   format of .git/HEAD, not two", and it still is a valid
   argument from Porcelain writers' point of view.  To be
   honest, since I do not do Porcelain, I am neutral about it.

 - convert-packs: futureproofing.
 - Require packfiles to follow the naming convention (preparation).

   These two I have been holding for a while.  I would
   eventually like to force people to rename the packfiles
   created by GIT older than v0.99.9 which has unverifiable
   hexadecimal string in their names and these are the first
   two baby steps toward that goal.  If people object to the
   idea of verifiable packname in general, please raise hand,
   and I may be talked into shelving the whole thing.

 - Documentation: show-branch.
 - show-branch: always include the current branch
 - show-branch: make --topo-order noop and default.
 - show-branch: make the current branch stand out.

   Here are mostly usability updates.

I'll send out some of the above patches to the list separately
for discussion and review.


[Footnote]

*1* 1.0.X series maintenance can largely be ignored by general
public, since I do not see any reason to stick to 1.0.X series.
1.1.X series does not have any backward incompatibility issues
as far as I know.  I am doing 1.0.X series primarily as a
practice for myself, and to experiment with a maintainer
workflow like this:

 - "fixo/1.0" topic branch queues fixes applicable for 1.0
   series *and* *later* maintenance series.

 - "fix" topic branch queues fixes applicable only for the
   current maintenance series.

 - "mainto/1.0" branch is used to cut releases for the 1.0.X
   maintenance series from.  This pulls from "fixo/1.0" topic
   branch.

 - "maint" branch is used to cut releases for the current
   maintenance series from.  This pulls from both "fix" topic
   branch and "mainto/*" topic branches.

With this setup, I can first merge "fixo/1.0" to "mainto/1.0",
and then merge "mainto/1.0" and "fix" branches to "maint", to
come up with something like this:

    $ git show-branch fix fixo/* maint mainto/*
    ! [fix] describe: do not silently ignore indescribable commits
     ! [fixo/1.0] name-rev: do not omit leading components of ref name.
      * [maint] GIT 1.1.2 (not really -- just a demonstration)
       ! [mainto/1.0] GIT 1.0.10 (not really -- just a demonstration)
    ----
      *  [maint] GIT 1.1.2 (not really -- just a demonstration)
    + *  [fix] describe: do not silently ignore indescribable commits
    + *  [fix^] Add git-describe to .gitignore.
      *  [maint^] Merge fixes up to GIT 1.0.10 (not really)
      *+ [mainto/1.0] GIT 1.0.10 (not really -- just a demonstration)
     +*+ [fixo/1.0] name-rev: do not omit leading components of ref name.
     +*+ [fixo/1.0^] update-index: work with c-quoted name
      *+ [mainto/1.0^] GIT 1.0.9
      *  [maint~2] GIT 1.1.1
     +*+ [fixo/1.0~2] glossary: explain "master" and "origin"
    + *  [maint~3] GIT-VERSION-GEN: detect dirty tree and mark the ver...
    + *  [maint~4] For release tarballs, include the proper version
    + *  [maint~5] GIT 1.1.0
    + *+ [mainto/1.0~2] GIT 1.0.8
    ++*+ [fixo/1.0~3] mailsplit: allow empty input from stdin

What's cooking in git.git

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

>  - Exec git programs without using PATH (Michal Ostrowski).
>
>    This has been discussed for the last couple of days on the
>    list.  I think C side is ready to go in, but I'd like to
>    decide what to do on the scripting side before merging it
>    into the master branch.

I've done a minor fix in the Makefile (things were installed in
the wrong way around --- $bindir should hold git and gitk and
$gitexecdir should hold the rest), and ran a brief test after
installing things with gitexecdir set to /usr/lib/git-core/x.
gitk needs to be taught to use git --exec-path upfront to set
its own PATH, but other than that, everything looks peachy.

About prepending to/appending to/not touching PATH, my current
thinking is that prepending is the way to go.  The best
rationale so far I have heard against mucking with PATH was
"/home/mo/bin/diff vs /usr/bin/diff" issue, but I do not find
this to be so convincing in practice.  This "use my diff not
system diff" is done most often when system diff is not GNU
enough, but on such a machine git will not be installed under
/usr/bin anyway (after all git prefers GNU diff).

And this becomes truly a non-issue when you point $gitexecdir at
a separate location that holds *only* git stuff.  Everybody will
find the matching version of git that way, and when looking for
"diff", it will be found from one of the directories in the rest
of the PATH, not from $gitexecdir.

So unless there is an objection, this will graduate into the
"master" branch over the weekend.

What happens if gitexecdir != bindir?

As long as the user invokes "git foo" from the command line, not
"git-foo", everything should work fine, and once gitk is
updated, binary distributions could ship git with only git and
gitk in /usr/bin and others in /usr/lib/git-core/tools, or
something like that.

I will _not_ change the default gitexecdir in my Makefile nor
change the spec file, so RPM binary from kernel.org will still
have everything in /usr/bin for now.

Somebody needs to audit how ready popular Porcelains are, for at
least Cogito, stgit, gitweb and qgit and feed patches to
respective authors as necessary.  I haven't looked into any of
them about this issue.  The rules are:

    (1) you can assume "git" is available on PATH;

    (2) you should be safe if you do not use "git-foo" form;

    (3) you can run

        PATH="$(git --exec-path):$PATH"; export PATH

        once at the beginning of your program and use "git-foo"
        form.

Volunteers?

Re: What's cooking in git.git

[Petr Baudis]

Dear diary, on Thu, Jan 12, 2006 at 01:04:41AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
>  - Disable USE_SYMLINK_HEAD by default (Pavel Roskin).
> 
>    This has been on hold for almost two months -- forever in git
>    timescale.
> 
>    One offender that could have been broken by this change was
>    fixed recently (gitweb), so this can go in anytime now.  Do
>    people still care about it?  The argument for the change when
>    it was proposed was "then we only have to worry about one
>    format of .git/HEAD, not two", and it still is a valid
>    argument from Porcelain writers' point of view.  To be
>    honest, since I do not do Porcelain, I am neutral about it.

Yes, I'd still be pleased to see this. Cogito should be ready for this
for long enough, as far as I'm concerned.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams