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

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

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

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

ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))

[Stephen Boyd]

Junio C Hamano wrote:
> * 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?

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.

diff --git a/contrib/completion/git-completion.bash.generate b/contrib/completion/git-completion.bash.generate
index 33b1d1d..6487fd5 100755
--- a/contrib/completion/git-completion.bash.generate
+++ b/contrib/completion/git-completion.bash.generate
@@ -24,6 +24,7 @@ __git_all_commands ()
        do
                case $i in
                *--*)             : helper pattern;;
+               *.sh|*.perl)      : build scripts;;
                *) echo $i;;
                esac
        done

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

[Jakub Narebski]

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

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

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.

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

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

> * sb/gitweb-link-author (2009-10-15) 1 commit
>  - gitweb: linkify author/committer names with search
> 
> Soon in 'next'.

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?

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

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.


> * 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 Rene (and Nico) a lot more than I trust myself.  Tonight's 'pu'
> queues this series instead of my "nested" one.

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

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

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

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


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

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?

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


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

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.


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

Hmmm... what is happening with that series?
 
-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Nguyen Thai Ngoc Duy]

On Thu, Oct 22, 2009 at 3:46 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>> * 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
>
> Hmmm... what is happening with that series?

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

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

[skillzero]

On Thu, Oct 22, 2009 at 4:15 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Thu, Oct 22, 2009 at 3:46 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>> * 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
>>
>> Hmmm... what is happening with that series?
>
> 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.

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.

Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))

[Sverre Rabbelier]

Heya,

On Thu, Oct 22, 2009 at 03:34, Stephen Boyd <bebarino@gmail.com> wrote:
> Junio C Hamano wrote:
>> * 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?
>
> No. I now have rebase.sh, am.sh, etc. in my completion

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

Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))

[Stephen Boyd]

Sverre Rabbelier wrote:
> 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.

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

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

[Stephen Boyd]

Jakub Narebski wrote:
>> * sb/gitweb-link-author (2009-10-15) 1 commit
>>  - gitweb: linkify author/committer names with search
>>
>> Soon in 'next'.
>>     
>
> 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?
>   

Yes.

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

[Junio C Hamano]

skillzero@gmail.com writes:

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

Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))

[A Large Angry SCM]

Sverre Rabbelier wrote:
> Heya,
> 
> On Thu, Oct 22, 2009 at 03:34, Stephen Boyd <bebarino@gmail.com> wrote:
>> Junio C Hamano wrote:
>>> * 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?
>> No. I now have rebase.sh, am.sh, etc. in my completion
> 
> 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.
> 

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

Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))

[A Large Angry SCM]

Sverre Rabbelier wrote:
> How am i forcing completion on those that did not ask for it? Nothing 
> changes  compared to the old situation....
> 
>> On Oct 22, 2009 5:20 PM, "A Large Angry SCM" <gitzilla@gmail.com 
>> <mailto:gitzilla@gmail.com>> wrote:
>>
>> Sverre Rabbelier wrote: > > Heya, > > On Thu, Oct 22, 2009 at 03:34, 
>> Stephen Boyd <bebarino@gmail.co...
>>
>> Please do not for completion on those that did not ask for it.
> 

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

Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))

[Johannes Schindelin]

Hi,

On Thu, 22 Oct 2009, A Large Angry SCM wrote:

> Sverre Rabbelier wrote:
> > Heya,
> > 
> > On Thu, Oct 22, 2009 at 03:34, Stephen Boyd <bebarino@gmail.com> wrote:
> > > Junio C Hamano wrote:
> > > > * 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?
> > > No. I now have rebase.sh, am.sh, etc. in my completion
> > 
> > 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.
> > 
> 
> Please do not for completion on those that did not ask for it.

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

[PATCH] add tests for git diff --submodule

[Jens Lehmann]

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

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---

Junio C Hamano schrieb:
> * 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'.

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

diff --git a/t/t4041-diff-submodule.sh b/t/t4041-diff-submodule.sh
new file mode 100755
index 0000000..5bb4fed
--- /dev/null
+++ b/t/t4041-diff-submodule.sh
@@ -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

Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))

[Sverre Rabbelier]

Heya,

On Thu, Oct 22, 2009 at 18:05, A Large Angry SCM <gitzilla@gmail.com> wrote:
> Your original email included 'make && make install'; it's the "make install"
> part I'm concerned about.

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

Re: ks/precompute-completion

[Junio C Hamano]

Sverre Rabbelier <srabbelier@gmail.com> writes:

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

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"?

Re: ks/precompute-completion

[Sverre Rabbelier]

Heya,

On Fri, Oct 23, 2009 at 13:59, Junio C Hamano <gitster@pobox.com> wrote:
>  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.

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

Re: ks/precompute-completion

[Junio C Hamano]

Sverre Rabbelier <srabbelier@gmail.com> writes:

> 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?

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

Re: ks/precompute-completion

[Sverre Rabbelier]

Heya,

On Fri, Oct 23, 2009 at 15:05, Junio C Hamano <gitster@pobox.com> wrote:
> "make clean" should remove it, because it is a normal build product,
> if you make your "make all" build completion scripts.

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

Re: ks/precompute-completion

[Jakub Narebski]

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

> Sverre Rabbelier <srabbelier@gmail.com> writes:
> 
> > 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?
> 
> "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.

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

Re: ks/precompute-completion

[Sverre Rabbelier]

Heya,

On Fri, Oct 23, 2009 at 15:20, Jakub Narebski <jnareb@gmail.com> wrote:
> (and not make this target part of "make all")

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

Re: ks/precompute-completion

[A Large Angry SCM]

Sverre Rabbelier wrote:
> Heya,
> 
> On Fri, Oct 23, 2009 at 15:20, Jakub Narebski <jnareb@gmail.com> wrote:
>> (and not make this target part of "make all")
> 
> 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).
> 

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.

Re: ks/precompute-completion

[Sverre Rabbelier]

Heya,

On Fri, Oct 23, 2009 at 15:29, A Large Angry SCM <gitzilla@gmail.com> wrote:
> 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.

That would seem like a sensible solution ;).

> 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

Something like this then?

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

-- 
Cheers,

Sverre Rabbelier

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> * 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 Rene (and Nico) a lot more than I trust myself.  Tonight's 'pu'
>> queues this series instead of my "nested" one.
>
>> * 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.
>
> 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...

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.

>> * jc/pretty-lf (2009-10-04) 1 commit.
>>  - Pretty-format: %[+-]x to tweak inter-item newlines
>
> 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?

I know you can read the commit log message.

Re: [PATCH] add tests for git diff --submodule

[Junio C Hamano]

Jens Lehmann <Jens.Lehmann@web.de> writes:

> 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"

Thanks for a nice summary.

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

[Clemens Buchacher]

On Wed, Oct 21, 2009 at 11:52:30PM -0700, Junio C Hamano wrote:

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

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

Clemens

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

[Junio C Hamano]

Clemens Buchacher <drizzd@aon.at> writes:

> On Wed, Oct 21, 2009 at 11:52:30PM -0700, Junio C Hamano wrote:
>
>> * 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?
>
> I'm looking forward to this on Windows, where loading the completion script
> can take about 10 seconds.

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/4AE0190E.8020803@gmail.com/).

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

[Clemens Buchacher]

On Mon, Oct 26, 2009 at 12:14:45AM -0700, Junio C Hamano wrote:

> 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 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 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/4AE0190E.8020803@gmail.com/).

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

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

[Stephen Boyd]

Clemens Buchacher wrote:
>> 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/4AE0190E.8020803@gmail.com/).
>
> 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?

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.

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

[Clemens Buchacher]

On Mon, Oct 26, 2009 at 02:01:06AM -0700, Stephen Boyd wrote:

> Clemens Buchacher wrote:
>
> > Why does your PATH include the build directory during make, Stephen?
> 
> 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

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

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

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

Clemens

Re: vl/git-gui topic

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> * vl/git-gui (2009-10-16) 1 commit.
>  - git-gui: adjust the minimum height of diff pane for shorter screen height
> 
> Shawn?

Applied to git-gui tree.

-- 
Shawn.

Re: jp/dirty-describe topic

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> * jp/dirty-describe (2009-10-21) 1 commit.
>  - Teach "git describe" --dirty option
> 
> Ack?

Yup,

Acked-by: Shawn O. Pearce <spearce@spearce.org>

-- 
Shawn.

Re: vl/git-gui topic

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>> * vl/git-gui (2009-10-16) 1 commit.
>>  - git-gui: adjust the minimum height of diff pane for shorter screen height
>> 
>> Shawn?
>
> Applied to git-gui tree.

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

Re: sp/smart-http topic

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> 
> * sp/smart-http (2009-10-14) 17 commits
>  - Smart fetch over HTTP: client side
...
> What's the doneness of this series?

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.