What's cooking in git.git (Oct 2009, #04; Wed, 21)

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.

In 1.7.0, we plan to correct handful of warts in the interfaces everybody agrees that they were mistakes. The resulting system may not be strictly backward compatible. Currently planeed changes are:

* refuse push to update the checked out branch in a non-bare repo by default

Make "git push" into a repository to update the branch that is checked out fail by default. You can countermand this default by setting a configuration variable in the receiving repository.

http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007

* refuse push to delete the current branch by default

Make "git push $there :$killed" to delete the branch that is pointed at by its HEAD fail by default. You can countermand this default by setting a configuration variable in the receiving repository.

http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936

* git-send-email won't make deep threads by default

Many people said that by default when sending more than 2 patches the threading git-send-email makes by default is hard to read, and they prefer the default be one cover letter and each patch as a direct follow-up to the cover letter. You can countermand this by setting a configuration variable.

http://article.gmane.org/gmane.comp.version-control.git/109790

* git-status won't be "git-commit --dry-run" anymore

http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993

* "git-diff -w --exit-code" will exit success if only differences it found are whitespace changes that are stripped away from the output.

http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751

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

* gb/maint-gitweb-esc-param (2009-10-13) 1 commit. (merged to 'next' on 2009-10-14 at 105f997)
+ gitweb: fix esc_param
(this branch is used by sb/gitweb-link-author.)

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

* vl/git-gui (2009-10-16) 1 commit.
- git-gui: adjust the minimum height of diff pane for shorter screen height

Shawn?

* cb/doc-fetch-pull-merge (2009-10-21) 1 commit.
(merged to 'next' on 2009-10-21 at 1d9190d)
+ modernize fetch/merge/pull examples

* ja/fetch-doc (2009-10-21) 1 commit.
(merged to 'next' on 2009-10-21 at bf09f62)
+ Documentation/fetch-options.txt: order options alphabetically

Helps 'git-fetch.{1,html}' without helping 'git-pull.{1,html}'.

* jc/1.7.0-no-commit-no-ff-2 (2009-10-21) 1 commit.
- git-merge: forbid fast-forward and up-to-date when --no-commit is given

This makes "git merge --no-commit" fail when it results in fast-forward or up-to-date. I haven't described this at the beginning of this message yet, as it is not clear if this is even necessary, but since I already wrote it and many people seem to be interested in UI and behaviour warts,...

Some tests expect the traditional behaviour of silently ignoring --no-commit upon fast-forward, and tonight's 'pu' does not pass them.

* jc/1.7.0-no-commit-no-ff (2009-10-21) 1 commit. . git-merge: imply --no-ff when --no-commit is given

This is an alternative patch to the same issue.

* jc/fsck-default-full (2009-10-20) 1 commit
(merged to 'next' on 2009-10-21 at 1375192)
+ fsck: default to "git fsck --full"

Should be safe enough to be in 'master' soon.

* jc/maint-fix-unpack-zlib-check (2009-10-21) 1 commit.
- Fix incorrect error check while reading deflated pack data

This is the final round from 2009-10-21, not my earlier botched attempts.

* jc/receive-pack-auto (2009-10-20) 2 commits.
(merged to 'next' on 2009-10-21 at fef13ef)
+ receive-pack: run "gc --auto --quiet" and optionally "update-server-info"
+ gc --auto --quiet: make the notice a bit less verboase

* jp/dirty-describe (2009-10-21) 1 commit.
- Teach "git describe" --dirty option

Ack?

* tr/filter-branch (2009-10-21) 2 commits.
- filter-branch: nearest-ancestor rewriting outside subdir filter
- filter-branch: stop special-casing $filter_subdir argument

J6t already has some comments on this.

* tr/maint-roff-quote (2009-10-21) 2 commits.
- Document GNU_ROFF in Makefile
- Quote ' as \(aq in manpages

The doc may need to be clarified a bit more.

* bg/clone-doc (2009-10-20) 1 commit.
(merged to 'next' on 2009-10-21 at 3016736)
+ git-clone.txt: Fix grammar and formatting

Should be correct enough to be in 'master' soon.

* iv/tar-lzma-xz (2009-10-20) 1 commit.
(merged to 'next' on 2009-10-21 at cb0df8a)
+ import-tars: Add support for tarballs compressed with lzma, xz

Should be safe enough to be in 'master' soon.

* rs/pretty-wrap (2009-10-17) 1 commit
- Implement wrap format %w() as if it is a mode switch
(this branch uses js/log-rewrap; is related to jc/strbuf-nested-expand.)

When it comes to design issues to keep unnecessary complexity out, I tend to trust R辿ne (and Nico) a lot more than I trust myself. Tonight's 'pu' queues this series instead of my "nested" one.

* sr/blame-incomplete (2009-10-19) 1 commit.
- blame: make sure that the last line ends in an LF

I think this is _good enough_ as-is; although it would be better if we added some hint to the output for Porcelain implementations, that can be done as a follow-up fix.

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

* mr/gitweb-snapshot (2009-09-26) 2 commits.
- gitweb: append short hash ids to snapshot files (merged to 'next' on 2009-10-11 at 22ba047)
+ gitweb: check given hash before trying to create snapshot

I lost track of the discussion around the tip commit. The bottom one may better go to 'master' regardless.

* db/vcs-helper-rest (2009-09-03) 6 commits.
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid (this branch is used by jh/cvs-helper.)

This holds the remainder of the db/vcs-helper topic that has already merged in 1.6.5. If people want to replace this with improvements it would be a good time to do so.

* jl/submodule-add-noname (2009-09-22) 1 commit.
- git submodule add: make the <path> parameter optional

Dscho started an interesting discussion regarding the larger workflow in which the "submodule add" is used. I think the patch itself makes sense but at the same time it probably makes sense to also take the <path> and infer the <repository> as Dscho suggested, probably in "git submodule add", not in "git add" proper, at least initially.

* sr/gfi-options (2009-09-06) 6 commits.
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions

* je/send-email-no-subject (2009-08-05) 1 commit.
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects

The existing tests cover the positive case (i.e. as long as the user says "yes" to the "do you really want to send this message that lacks subject", the message is sent) of this feature, but the feature itself needs its own test to verify the negative case (i.e. does it correctly stop if the user says "no"?)

* jh/cvs-helper (2009-08-18) 8 commits.
. More fixes to the git-remote-cvs installation procedure
. Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs . Add simple selftests of git-remote-cvs functionality
. git-remote-cvs: Remote helper program for CVS repositories
. 2/2: Add Python support library for CVS remote helper
. 1/2: Add Python support library for CVS remote helper
. Basic build infrastructure for Python scripts
. Allow helpers to request marks for fast-import
(this branch uses db/vcs-helper-rest.)

* jc/strbuf-nested-expand (2009-10-18) 3 commits
. Teach --wrap to only indent without wrapping
. Add %[wrap(width,in1,in2)<<any-string>>%] implementation . strbuf_nested_expand(): allow expansion to interrupt in the middle (this branch uses js/log-rewrap; is related to rs/pretty-wrap.)

Ejected from 'pu' to let rs/pretty-wrap in as described above.

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

* ne/rev-cache (2009-10-19) 7 commits.
- support for commit grafts, slight change to general mechanism
- support for path name caching in rev-cache
- full integration of rev-cache into git, completed test suite
- administrative functions for rev-cache, start of integration into git
- support for non-commit object caching in rev-cache
- basic revision cache system, no integration or features
- man page and technical discussion for rev-cache

Still unstable? Has an extra test squashed in; tonight's 'pu' does not pass tests.

* ak/bisect-reset-to-switch (2009-10-13) 1 commit.
- bisect reset: Allow resetting to any commit, not just a branch

Soon in 'next'.

* fc/doc-fast-forward (2009-10-11) 1 commit.
- user-manual: use 'fast-forward'

* jc/maint-1.6.3-graft-trailing-space (2009-10-14) 1 commit.
- info/grafts: allow trailing whitespaces at the end of line

Soon in 'next'.

* jk/maint-cvsimport-pathname (2009-10-19) 1 commit. (merged to 'next' on 2009-10-19 at 77824f2)
+ cvsimport: fix relative argument filenames

Should be safe enough to be in 'master' soon.

* jn/show-normalized-refs (2009-10-12) 3 commits.
- check-ref-format: simplify --print implementation
- git check-ref-format --print
- Add tests for git check-ref-format

This was for helping Porcelains like git-gui to sanely cope with user input that has redundant // in refnames. Are potential users happy with the series? I think this is ready for 'next'.

* sb/gitweb-link-author (2009-10-15) 1 commit
- gitweb: linkify author/committer names with search

Soon in 'next'.

* jc/checkout-auto-track (2009-10-18) 3 commits
- git checkout --no-guess
- DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"
- check_filename(): make verify_filename() callable without dying

The final shape of this series ended up to be more or less exactly what Dscho hinted he wanted to have in one of the discussion. Is everybody happy with this kind of new user-friendliness? I think it is safe enough to be queued to 'next'.

* tr/stash-format (2009-10-19) 5 commits
- stash list: drop the default limit of 10 stashes
- stash list: use new %g formats instead of sed
- Introduce new pretty formats %g[sdD] for reflog information
- reflog-walk: refactor the branch@{num} formatting
- Refactor pretty_print_commit arguments into a struct

Soon in 'next'.

* ks/precompute-completion (2009-10-05) 1 commit.
(merged to 'next' on 2009-10-14 at adf722a)
+ Speedup bash completion loading

Are people happy with this?

* sp/smart-http (2009-10-14) 17 commits
- Smart HTTP fetch: gzip requests
- Smart fetch over HTTP: client side
- Smart push over HTTP: client side
- Discover refs via smart HTTP server when available
- Smart fetch and push over HTTP: server side
- Add stateless RPC options to upload-pack, receive-pack
- Git-aware CGI to provide dumb HTTP transport
- Move WebDAV HTTP push under remote-curl
- remote-helpers: Support custom transport options
- remote-helpers: Fetch more than one ref in a batch
- fetch: Allow transport -v -v -v to set verbosity to 3
- remote-curl: Refactor walker initialization
- Add multi_ack_detailed capability to fetch-pack/upload-pack
- Move "get_ack()" back to fetch-pack
- fetch-pack: Use a strbuf to compose the want list
- pkt-line: Make packet_read_line easier to debug
- pkt-line: Add strbuf based functions

What's the doneness of this series?

* ef/msys-imap (2009-10-21) 8 commits.
- MSVC: Enable OpenSSL, and translate -lcrypto
- mingw: enable OpenSSL
- mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
- imap-send: build imap-send on Windows
- imap-send: fix compilation-error on Windows
- imap-send: use run-command API for tunneling
- imap-send: use separate read and write fds
- imap-send: remove useless uid code

Another re-roll. Waiting for an Ack from MSVC folks but otherwise it is ready for 'next', I think.

* jc/pretty-lf (2009-10-04) 1 commit.
- Pretty-format: %[+-]x to tweak inter-item newlines

* js/log-rewrap (2008-11-10) 2 commits
- Add strbuf_add_wrapped_text() to utf8.[ch]
- print_wrapped_text(): allow hard newlines
(this branch is used by jc/strbuf-nested-expand and rs/pretty-wrap.)

Soon in 'next'; regardless of how wrapping is exposed to --pretty=format, this code will be used, and it seems to be leak-free and reasonably done.

We _might_ want to cherry-pick the tip of jc/strbuf-nested-expand to this series, though.

* js/diff-verbose-submodule (2009-10-14) 2 commits.
- add tests for git diff --submodule-summary
- Add the --submodule option to the diff option family

I should retitle and fix some comments in the tip commit (the tests have already been adjusted to use the real option name), but otherwise I think this is ready for 'next'.

* jc/fix-tree-walk (2009-09-14) 10 commits.
- read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
+ unpack_callback(): use unpack_failed() consistently
+ unpack-trees: typofix
+ diff-lib.c: fix misleading comments on oneway_diff()

This is my replacement for Linus's lt/maint-traverse-trees-fix patch. It is not so much as a counter-proposal; I originally thought it might make sense to walk the index and drive the walker to return the entries from trees to match entries from the index, but I ended up doing pretty much what Linus outlined --- walk the trees, and have the index walker follow it. It turned out that the index side also needed some hairy look-ahead,

This includes the fix to aggressive mode of three-way merge used by the resolve strategy.

* jh/notes (2009-10-09) 22 commits.
- fast-import: Proper notes tree manipulation using the notes API
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Add selftests verifying concatenation of multiple notes for the same commit
- Refactor notes code to concatenate multiple notes annotating the same object
- Add selftests verifying that we can parse notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- Teach notes code to free its internal data structures on request
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes

Rebased so that it does not pull in anything else. Presumably it is ready for next?

* jn/gitweb-blame (2009-09-01) 5 commits.
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript (merged to 'next' on 2009-10-11 at 73c4a83)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer

Ajax-y blame. Probably the first three should go to 'master' by now?

* nd/sparse (2009-08-20) 19 commits.
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options

--------------------------------------------------
[For 1.7.0]

* jk/1.7.0-status (2009-09-05) 5 commits.
- docs: note that status configuration affects only long format (merged to 'next' on 2009-10-11 at 65c8513)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function (this branch uses jc/1.7.0-status.)

Gives the --short output format to post 1.7.0 "git commit --dry-run" that is similar to that of post 1.7.0 "git status".

* jc/1.7.0-status (2009-09-05) 4 commits.
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit" (this branch is used by jk/1.7.0-status.)

With this, "git status" is no longer "git commit --dry-run".

* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit. (merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default

* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits. (merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options

This changes exit code from "git diff --ignore-whitespace" and friends when there is no actual output. It is a backward incompatible change, but we could argue that it is a bugfix.

* jc/1.7.0-push-safety (2009-02-09) 2 commits.
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push

--------------------------------------------------
[I have been too busy to purge these]

* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected

Maybe some people care about this. I dunno.

* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker

Maybe some people care about this. I dunno.

* jg/log-format-body-indent (2009-09-19) 1 commit. . git-log --format: Add %B tag with %B(x) option

I'm looking forward to this on Windows, where loading the completion script can take about 10 seconds.

Clemens

Thanks.

Are you giving this comment after you actually tried it on Windows and found it satisfactory, or is it just based on the general description of "this should make it faster"?

I need to know, to sift acks/kudos based on facts that I can use to decide when to release it to 'master', from wishful thinking that I shouldn't, especially after seeing an obvious issue like the one reported by Stephen Boyd a few days ago (http://mid.gname.com/[email protected]/).

I just tried and it went down from several seconds to about half a second. On slower machines I expect the difference to be even more noticable.

I cannot follow that link. If you're referring to the "completion of commands available only in build environment" issue, that could also be considered a feature, because it allows completion of user-defined scripts.

Why does your PATH include the build directory during make, Stephen?

Clemens

The Makefile says:

git-completion.bash: git-completion.bash.in git-completion.bash.generate
# Generate completions for binaries we have just built PATH="$(shell pwd)/../..:$$PATH" ./git-completion.bash.generate

Having user-defined scripts is a good point. Generating the completion like this removes the possibility of such scripts from appearing in the completion. Unless users are putting their own "git-*" scripts in their build directory (sounds odd to me).

Personally, I'd rather keep it dynamic but I can see how it's useful to get the 10x speedup. It would be really cool if we could have the best of both worlds, where I keep my dynamic loading, but others can build the completion and get the speedup.

Right, of course. I guess ignoring *.sh and *.perl is reasonable then.

Should not be too hard to do using a configuration variable like core.completion = dynamic.

Clemens

No. I now have rebase.sh, am.sh, etc. in my completion because of how git help -a fully lists git commands in libexec and elsewhere in my $PATH (which gets pointed to my build directory during make).

It's late and I'm tired, but I think we can just ignore files ending in *.sh, *.perl, etc.

index 33b1d1d..6487fd5 100755
@@ -24,6 +24,7 @@ __git_all_commands ()
        do
                case $i in
                *--*)             : helper pattern;;
+               *.sh|*.perl)      : build scripts;;
                *) echo $i;;
                esac
        done

Heya,

I would really like it if running 'make && make install' in git.git would also build the completion script, I don't want to have to remember to run 'cd contrib/completion && make' every time we get new completion options :P.

Cheers,

Sverre Rabbelier

Perhaps a top-level completion rule would work? I don't know if building completion for every user would be appropriate.

Please do not for completion on those that did not ask for it.

Hi,

It is about installing git-completion.bash, AFAICT, not about forcing your shell into loading them by default. IOW something I wished for already in Feb 2008, but was unable to convince anybody of.

Ciao,
Dscho

Your original email included 'make && make install'; it's the "make install" part I'm concerned about.

Heya,

Ah, no, I meant that as part of my semi-regular git update (during which I do 'make && make install') I want to have up-to-date bash completion, preferably installed somewhere system-wide; currently I am forced to have a 'source /home/sverre/code/git/contrib/completion/git-completion.bash' in my .bashrc,..

Cheers,

Sverre Rabbelier

If you have enough privilege to run 'make && make install' regularly into a system-wide place, I presume you can have a system-wide rc that sources /home/sverre/code/git/contrib/completion/git-completion.bash, no?

I think there are two issues.

1. The series will break your rc script (either $HOME/.bashrc, or system-side) that sources $git/contrib/completion/git-completion.bash because it has to be built; having "make" generate it may alleviate the issue, but "make clean" will break it again, so it is not something you can solve in any way other than changing your setting.

2. Some people have been expecting "make install" not to install the bash completion anywhere.

So perhaps "make && make install-contrib"?

Heya,

This is my main concern, adding 'bash_completion' as a target to all:
would be ok; why would 'make clean' break it? As long as you don't add "make -C contrib/completion clean' to the main clean target there's no problem?

Cheers,

Sverre Rabbelier

"make clean" should remove it, because it is a normal build product, if you make your "make all" build completion scripts.

The word _should_ is used in the RFC2119 sense: there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Heya,

Hmm, I guess that's fair enough, if you 'make clean' you want all build products to be removed; this problem would be solved by installing the completion script in the share dir, that way it doens't matter if 'make clean' removes the one in ~/code/git, as long as the one in ~/share/git-completion remains.

Cheers,

Sverre Rabbelier

If we take similar approach to the way gitweb can be build to the bash completion script, which means building it via

make contrib/completion/git-completion.bash

(and not make this target part of "make all"), then there is, I think, no reason for "make clean" to remove it, isn't it?

Jakub Narebski
Poland
ShadeHawk on #git

Heya,

But that I can already do through 'make contrib/completion/Makefile', what I want is to not have to worry about doing that whenever I update my git install (that is, the same way as it was before it became pre-computed).

Cheers,

Sverre Rabbelier

It seems that you want the completion script promoted out of contrib. Otherwise, you're asking for it to be treated special with respect to everything else in contrib and have the top level Makefile be aware of it and add it to the main targets.

The promotion I have no problem with as long as the install location is not somewhere where any shell will find it without a config setting in the user's shell. Leaving it in contrib and and adding it to top level Makefile, I do have a problem with.

Heya,

That would seem like a sensible solution ;).

Something like this then?

http://repo.or.cz/w/git/dscho.git?a=commit;h=eb966204d17dcab7abf61621219312a813c87405

Cheers,

Sverre Rabbelier

Copied from the submodule summary test and changed to reflect the differences in the output of git diff --submodule.

---

Sorry for sending the updated test so late, i haven't had much time for git in the last few days.

Apart from your changes necessary to make the test run again my changes are:

- rename from "t4041-diff-submodule-summary.sh" to "t4041-diff-submodule.sh"
- corrected all comments still speaking of "summary"
- added tests to test the behaviour of "--submodule" and "--submodule=short"

 t/t4041-diff-submodule.sh |  260 +++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 260 insertions(+), 0 deletions(-)
 create mode 100755 t/t4041-diff-submodule.sh

new file mode 100755
index 0000000..5bb4fed
@@ -0,0 +1,260 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Jens Lehmann, based on t7401 by Ping Yin
+#
+
+test_description='Support for verbose submodule differences in git diff
+
+This test tries to verify the sanity of the --submodule option of git diff.
+'
+
+. ./test-lib.sh
+
+add_file () {
+	sm=$1
+	shift
+	owd=$(pwd)
+	cd "$sm"
+	for name; do
+		echo "$name" > "$name" &&
+		git add "$name" &&
+		test_tick &&
+		git commit -m "Add $name"
+	done >/dev/null
+	git rev-parse --verify HEAD | cut -c1-7
+	cd "$owd"
+}
+commit_file () {
+	test_tick &&
+	git commit "$@" -m "Commit $*" >/dev/null
+}
+
+test_create_repo sm1 &&
+add_file . foo >/dev/null
+
+head1=$(add_file sm1 foo1 foo2)
+
+test_expect_success 'added submodule' "
+	git add sm1 &&
+	git diff-index -p --submodule=log HEAD >actual &&
+	diff actual - <<-EOF
+Submodule sm1 0000000...$head1 (new submodule)
+EOF
+"
+
+commit_file sm1 &&
+head2=$(add_file sm1 foo3)
+
+test_expect_success 'modified submodule(forward)' "
+	git diff-index -p --submodule=log HEAD >actual &&
+	diff actual - <<-EOF
+Submodule sm1 $head1..$head2:
+  > Add foo3
+EOF
+"
+
+test_expect_success 'modified submodule(forward)' "
+	git diff --submodule=log >actual &&
+	diff actual - <<-EOF
+Submodule sm1 $head1..$head2:
+  > Add foo3
+EOF
+"
+
+test_expect_success 'modified submodule(forward) --submodule' "
+	git diff --submodule >actual &&
+	diff actual - <<-EOF
+Submodule sm1 $head1..$head2:
+  > Add foo3
+EOF
+"
+
+fullhead1=$(cd sm1; git rev-list --max-count=1 $head1)
+fullhead2=$(cd sm1; git rev-list --max-count=1 $head2)
+test_expect_success 'modified submodule(forward) --submodule=short' "
+	git diff --submodule=short >actual &&
+	diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+index $head1..$head2 160000
+--- a/sm1
++++ b/sm1
+@@ -1 +1 @@
+-Subproject commit $fullhead1
++Subproject commit $fullhead2
+EOF
+"
+
+commit_file sm1 &&
+cd sm1 &&
+git reset --hard HEAD~2 >/dev/null &&
+head3=$(git rev-parse --verify HEAD | cut -c1-7) &&
+cd ..
+
+test_expect_success 'modified submodule(backward)' "
+	git diff-index -p --submodule=log HEAD >actual &&
+	diff actual - <<-EOF
+Submodule sm1 $head2..$head3 (rewind):
+  < Add foo3
+  < Add foo2
+EOF
+"
+
+head4=$(add_file sm1 foo4 foo5) &&
+head4_full=$(GIT_DIR=sm1/.git git rev-parse --verify HEAD)
+test_expect_success 'modified submodule(backward and forward)' "
+	git diff-index -p --submodule=log HEAD >actual &&
+	diff actual - <<-EOF
+Submodule sm1 $head2...$head4:
+  > Add foo5
+  > Add foo4
+  < Add foo3
+  < Add foo2
+EOF
+"
+
+commit_file sm1 &&
+mv sm1 sm1-bak &&
+echo sm1 >sm1 &&
+head5=$(git hash-object sm1 | cut -c1-7) &&
+git add sm1 &&
+rm -f sm1 &&
+mv sm1-bak sm1
+
+test_expect_success 'typechanged submodule(submodule->blob), --cached' "
+	git diff --submodule=log --cached >actual &&
+	diff actual - <<-EOF
+Submodule sm1 41fbea9...0000000 (submodule deleted)
+diff --git a/sm1 b/sm1
+new file mode 100644
+index 0000000..9da5fb8
+--- /dev/null
++++ b/sm1
+@@ -0,0 +1 @@
++sm1
+EOF
+"
+
+test_expect_success 'typechanged submodule(submodule->blob)' "
+	git diff --submodule=log >actual &&
+	diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+deleted file mode 100644
+index 9da5fb8..0000000
+--- a/sm1
++++ /dev/null
+@@ -1 +0,0 @@
+-sm1
+Submodule sm1 0000000...$head4 (new submodule)
+EOF
+"
+
+rm -rf sm1 &&
+git checkout-index sm1
+test_expect_success 'typechanged submodule(submodule->blob)' "
+	git diff-index -p --submodule=log HEAD >actual &&
+	diff actual - <<-EOF
+Submodule sm1 $head4...0000000 (submodule deleted)
+diff --git a/sm1 b/sm1
+new file mode 100644
+index 0000000..$head5
+--- /dev/null
++++ b/sm1
+@@ -0,0 +1 @@
++sm1
+EOF
+"
+
+rm -f sm1 &&
+test_create_repo sm1 &&
+head6=$(add_file sm1 foo6 foo7)
+fullhead6=$(cd sm1; git rev-list --max-count=1 $head6)
+test_expect_success 'nonexistent commit' "
+	git diff-index -p --submodule=log HEAD >actual &&
+	diff actual - <<-EOF
+Submodule sm1 $head4...$head6 (commits not present)
+EOF
+"
+
+commit_file
+test_expect_success 'typechanged submodule(blob->submodule)' "
+	git diff-index -p --submodule=log HEAD >actual &&
+	diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+deleted file mode 100644
+index $head5..0000000
+--- a/sm1
++++ /dev/null
+@@ -1 +0,0 @@
+-sm1
+Submodule sm1 0000000...$head6 (new submodule)
+EOF
+"
+
+commit_file sm1 &&
+rm -rf sm1
+test_expect_success 'deleted submodule' "
+	git diff-index -p --submodule=log HEAD >actual &&
+	diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+EOF
+"
+
+test_create_repo sm2 &&
+head7=$(add_file sm2 foo8 foo9) &&
+git add sm2
+
+test_expect_success 'multiple submodules' "
+	git diff-index -p --submodule=log HEAD >actual &&
+	diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+test_expect_success 'path filter' "
+	git diff-index -p --submodule=log HEAD sm2 >actual &&
+	diff actual - <<-EOF
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+commit_file sm2
+test_expect_success 'given commit' "
+	git diff-index -p --submodule=log HEAD^ >actual &&
+	diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+test_expect_success 'given commit --submodule' "
+	git diff-index -p --submodule HEAD^ >actual &&
+	diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+fullhead7=$(cd sm2; git rev-list --max-count=1 $head7)
+
+test_expect_success 'given commit --submodule=short' "
+	git diff-index -p --submodule=short HEAD^ >actual &&
+	diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+deleted file mode 160000
+index $head6..0000000
+--- a/sm1
++++ /dev/null
+@@ -1 +0,0 @@
+-Subproject commit $fullhead6
+diff --git a/sm2 b/sm2
+new file mode 160000
+index 0000000..$head7
+--- /dev/null
++++ b/sm2
+@@ -0,0 +1 @@
++Subproject commit $fullhead7
+EOF
+"
+
+test_done

1.6.5.rc2.19.gcbaec.dirty

Thanks for a nice summary.

Good. Beside fixing excaping of multibyte Unicode characters this also finally makes gitweb use '+' and not '%20' to encode space ' ' in CGI parameters.

This reminds me that gitweb really should do conversion / marking data as UTF-8 _on input_, to avoid situations where output is mangled because of problems with Unicode. That goes to my gitweb's TODO.

The tip commit should be fixed before accepting. There are some problems with it as it is now:

* $hash parameter is abused to hold version suffix of snapshot filename (and archive prefix), e.g. 'next-ae4ab03'; it really should be done using separate variable, and perhaps even separate subroutine which would generate snapshot name.

* I don't think it works with fully qualified refnames that gitweb itself generate, e.g. 'refs/heads/next' or 'refs/tags/v1.6.0', nor with hierarchical branch names such as 'mr/gitweb-snapshot'; snapshot name can't include '/', and prefix shouldn't include '/'

* when new test is running with --debug option, it dumps whole output of gitweb for 'snapshot' action, which includes *binary data*, and not only HTTP headers like it should (at least in first version).

Is this version that uses title attribute to show that this link is different in that it leads to search results, not an action view?

The first three makes fairly 'invisible' change, but introduce possibility of using JavaScript in gitweb. I'd like more testing with different browsers than mine, but corrections if any can be done in-tree.

The "Create links" patch is not ready yet.

I think nested expand is easier to use than a mode switch: using scoping (well, kind of) like in high-level programming languages is IMVHO easier than programming a state machine like in assembler (or e.g. OpenGL).

On the other hand this makes pretty format into a mini-language; also we already have and use mode switches in the form of color codes. Perhaps if color also used wrapping / nested expand, so one doesn't have to track where to turn off and on which toggle...

...and this was yet another alternate solution (less generic, though)

I understand that %a%+b expands to %a%n%b if %b has non-empty expansion, and to %a if %b is empty, but what %-b is used for?

BTW. I would really prefer if this series was send with cover letter explaining series and perhaps differences from previous version of series as a whole (reordering, splitting and joining patches, new patches etc.), and individual patches in series replies to this cover letter, without 'Re: ' prefix in subject, and with explanation of the difference from previous version (if any) in the commentary area.

Hmmm... what is happening with that series?

Jakub Narebski
Poland
ShadeHawk on #git

Yes.

Indeed, the "mini-language"-ness was what made Réne worried and reminded me that I should be worried, too. We need to get the design right if we do so---there may come a time that we are better off biting the bullet when we discover needs (notice, it is not "wants, because we can") for many useful string functions, but I do not think we have reached that point yet.

I know you can read the commit log message.

Junio concerned about CE_MATCH_IGNORE_VALID being used by both assume-unchanged and skip-worktree bits, which I did not resolve yet. I should really get back to the series when I have time.

Duy

Just an FYI, but I've been using this series for a while. I'm actually relying on sparse support in our internal build system (via my private build with this series) so I hope it doesn't go away :) I haven't really noticed any problems (I thought the index state got out of sync once, but I couldn't reproduce the problem later). Here's some feedback though:

1. I found it confusing to have to append '/' to directories in the sparse pattern list for directories. I always forget it requires them. It would be nice to support the same rules as .gitignore in terms of '/'.

2. It would be nice to have built-in support for a sparse modules file and switching between them. Maybe .gitmodules could support "module" or "sparsemodule" sections to list the patterns for that sparse module. I've written a simple script to do this and it's what I use. It just parses the INI-style file:

[module "MyProject"]
App1
Shared1
!FolderIDontWant

Then I have a "module" script to read that file for a specified module and switch to it:

git module switch MyProject

The script just parses git show HEAD:.gitmodules (so it works without a working directory) and switches sparse modules by enabling sparse, writing info/sparse-checkout, and doing a checkout:

sub cmd_switch

{
	# Enable sparse.
	my $currentCmd = "git config core.sparsecheckout true";
	system( $currentCmd ) == 0 or die( "error: $currentCmd\n" );
	
	# Write sparse patterns.
	my $gitDir = `git rev-parse --git-dir`;
	chop( $gitDir );
	my $sparsePath = $gitDir . "/info/sparse-checkout";
	if( $? != 0 ) { die( "error: read git directory failed $?\n" ); }
	open( FILE, ">", $sparsePath ) or die( "error: can't open '$sparsePath'\n" );
	foreach( @{$gModules->{$gModuleName}} )
	{
		print( FILE "$_\n" );
	}
	close( FILE );
	
	# Checkout using new sparse patterns.
	system( "git checkout" ) == 0 or die( "error: switch module failed\n" );
}

That said, the current level of sparse support provided by this series is good enough for me because I can build my own scripts like this on top of it to automate things.

Thanks for sharing. It is the best approach to start by adding minimum core level support and then to let people (like you) with real-world needs to experiment with custom wrapper scripts, to figure out what user-level concepts and workflows work and useful (and what don't and aren't), and what additional core level features is helpful to support them. Over time, successful custom wrappers will become the best-current-practice and can be folded back into the mainline, and everybody will benefit.

Applied to git-gui tree.

Shawn.

Thanks, pulled together with bunch of other changes that looked sensible.

Yup,

Shawn.

...

Not done yet. I want to respin once more before it hits next.

I've picked up a number of test related changes from Clemens Buchacher and Tay Ray Chuan, plus some suggestions from the latter were fixed up in the WebDAV code.

John "warthog9" Hawley and I were spending some time yesterday to try to figure out why smart HTTP serving off kernel.org was giving me only 300 KiB/sec during clone, but git-daemon was giving me 12 MiB/sec for the same server and repository.

Peff noticed the TCP windows for smart HTTP were ~16 KiB in size, but with git-daemon were ~200 KiB on size. John and I are pretty sure this is the throughput problem, but we haven't found why the window is so much smaller under smart HTTP.

We also need proper tests for smart HTTP. I haven't had time to write tests yet, and the ones that were proposed for t5540-http-push aren't suitable because you have to run the test suite twice in order to test both WebDAV and smart HTTP push for the same build.

Shawn.