What's cooking in git.git (Jun 2010, #04; Wed, 23)

What's cooking in git.git (Jun 2010, #04; Wed, 23)

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

I think I should start making noises about feature freeze for 1.7.2 by
now.  'next' is getting quite thin (and most of them look good ones),
while topics in 'pu' are mostly the kind nobody gets hurt if we waited for
a cycle or two.

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

* ar/decorate-color (2010-06-23) 4 commits
 - Allow customizable commit decorations colors
 - log --decorate: Colorize commit decorations
 - log-tree.c: Use struct name_decoration's type for classifying decoration
 - commit.h: add 'type' to struct name_decoration

* tc/checkout-B (2010-06-22) 3 commits
 - builtin/checkout: learn -B
 - builtin/checkout: change -b from an OPTION_STRING to a OPTION_SET_INT
 - add tests for checkout -b

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

* bc/portable (2010-06-09) 7 commits
  (merged to 'next' on 2010-06-13 at a423055)
 + Remove python 2.5'isms
 + Makefile: add PYTHON_PATH to GIT-BUILD-OPTIONS
  (merged to 'next' on 2010-06-07 at 27a57c9)
 + t/aggregate-results: accomodate systems with small max argument list length
 + t/t7006: ignore return status of shell's unset builtin
 + t/t5150: remove space from sed script
 + git-request-pull.sh: remove -e switch to shell interpreter which breaks ksh
 + t/t5800: skip if python version is older than 2.5

* bd/maint-unpack-trees-parawalk-fix (2010-06-10) 1 commit
  (merged to 'next' on 2010-06-18 at 183c13e)
 + unpack-trees: Make index lookahead less pessimal

* cc/cherry-pick-series (2010-06-02) 8 commits
  (merged to 'next' on 2010-06-18 at 26c504f)
 + Documentation/revert: describe passing more than one commit
 + Documentation/cherry-pick: describe passing more than one commit
 + revert: add tests to check cherry-picking many commits
 + revert: allow cherry-picking more than one commit
 + revert: change help_msg() to take no argument
 + revert: refactor code into a do_pick_commit() function
 + revert: use run_command_v_opt() instead of execv_git_cmd()
 + revert: cleanup code for -x option
 (this branch is used by cc/cherry-pick-stdin.)

* cc/maint-commit-reflog-msg (2010-06-12) 1 commit
  (merged to 'next' on 2010-06-17 at 863be4d)
 + commit: use value of GIT_REFLOG_ACTION env variable as reflog message

* eb/core-eol (2010-06-04) 4 commits
  (merged to 'next' on 2010-06-17 at 66b0c9f)
 + Add "core.eol" config variable
 + Rename the "crlf" attribute "text"
 + Add per-repository eol normalization
 + Add tests for per-repository eol normalization
 (this branch uses fg/autocrlf.)

* em/checkout-orphan (2010-06-10) 6 commits
  (merged to 'next' on 2010-06-12 at 2f531d5)
 + log_ref_setup: don't return stack-allocated array
  (merged to 'next' on 2010-06-07 at 23b4607)
 + bash completion: add --orphan to 'git checkout'
 + t3200: test -l with core.logAllRefUpdates options
 + checkout --orphan: respect -l option always
 + refs: split log_ref_write logic into log_ref_setup
 + Documentation: alter checkout --orphan description

* fg/autocrlf (2010-05-12) 1 commit
  (merged to 'next' on 2010-05-21 at 5f43b66)
 + autocrlf: Make it work also for un-normalized repositories
 (this branch is used by eb/core-eol.)

* gs/usage-to-stdout (2010-06-12) 2 commits
  (merged to 'next' on 2010-06-13 at e83c00f)
 + parseopt: wrap rev-parse --parseopt usage for eval consumption
  (merged to 'next' on 2010-06-03 at c81c783)
 + print the usage string on stdout instead of stderr

* gv/portable (2010-06-11) 20 commits
  (merged to 'next' on 2010-06-13 at 1add99c)
 + test-lib: use DIFF definition from GIT-BUILD-OPTIONS
  (merged to 'next' on 2010-06-07 at 1796035)
 + build: propagate $DIFF to scripts
  (merged to 'next' on 2010-06-03 at 41ae9cb)
 + Makefile: Tru64 portability fix
 + Makefile: HP-UX 10.20 portability fixes
 + Makefile: HPUX11 portability fixes
 + Makefile: SunOS 5.6 portability fix
 + inline declaration does not work on AIX
 + Allow disabling "inline"
 + Some platforms lack socklen_t type
 + Make NO_{INET_NTOP,INET_PTON} configured independently
 + Makefile: some platforms do not have hstrerror anywhere
 + git-compat-util.h: some platforms with mmap() lack MAP_FAILED definition
 + test_cmp: do not use "diff -u" on platforms that lack one
 + fixup: do not unconditionally disable "diff -u"
 + tests: use "test_cmp", not "diff", when verifying the result
 + Do not use "diff" found on PATH while building and installing
 + enums: omit trailing comma for portability
 + Makefile: -lpthread may still be necessary when libc has only pthread stubs
 + Rewrite dynamic structure initializations to runtime assignment
 + Makefile: pass CPPFLAGS through to fllow customization

* ic/maint-rebase-i-abort (2010-06-08) 1 commit
  (merged to 'next' on 2010-06-17 at 7f5f430)
 + rebase -i: Abort cleanly if new base cannot be checked out

* jc/maint-simpler-common-prefix (2010-06-16) 1 commit
  (merged to 'next' on 2010-06-18 at 24fa283)
 + common_prefix: simplify and fix scanning for prefixes

* jc/rev-list-ancestry-path (2010-06-04) 5 commits
  (merged to 'next' on 2010-06-17 at b35488a)
 + revision: Turn off history simplification in --ancestry-path mode
 + revision: Fix typo in --ancestry-path error message
 + Documentation/rev-list-options.txt: Explain --ancestry-path
 + Documentation/rev-list-options.txt: Fix missing line in example history graph
 + revision: --ancestry-path

* jk/maint-advice-empty-amend (2010-06-06) 1 commit
  (merged to 'next' on 2010-06-17 at 12ff4cd)
 + commit: give advice on empty amend

* jn/checkout-doc (2010-06-01) 2 commits
  (merged to 'next' on 2010-06-13 at d01c620)
 + Documentation/checkout: clarify description
  (merged to 'next' on 2010-06-07 at 93cc6a9)
 + Documentation/checkout: clarify description

* jn/document-rebase-i-p-limitation (2010-05-31) 1 commit
  (merged to 'next' on 2010-06-17 at a653a72)
 + rebase -i -p: document shortcomings

* jn/gitweb-fastcgi (2010-06-05) 3 commits
  (merged to 'next' on 2010-06-13 at 6d1fdd6)
 + gitweb: Run in FastCGI mode if gitweb script has .fcgi extension
  (merged to 'next' on 2010-05-21 at cb1724f)
 + gitweb: Add support for FastCGI, using CGI::Fast
 + gitweb: Put all per-connection code in run() subroutine

* jn/gitweb-return-or-exit-cleanup (2010-06-13) 1 commit
  (merged to 'next' on 2010-06-18 at 44299d4)
 + gitweb: Return or exit after done serving request

* js/async-thread (2010-06-11) 8 commits
  (merged to 'next' on 2010-06-13 at bf7457c)
 + fast-import: die_nicely() back to vsnprintf (reverts part of ebaa79f)
  (merged to 'next' on 2010-05-21 at 9d31940)
 + Enable threaded async procedures whenever pthreads is available
  (merged to 'next' on 2010-05-04 at 2644e74)
 + Dying in an async procedure should only exit the thread, not the process.
 + Reimplement async procedures using pthreads
 + Windows: more pthreads functions
 + Fix signature of fcntl() compatibility dummy
 + Make report() from usage.c public as vreportf() and use it.
 + Modernize t5530-upload-pack-error.

* js/maint-receive-pack-symref-alias (2010-06-16) 1 commit
  (merged to 'next' on 2010-06-17 at ecb7fa5)
 + Merge branch 'tr/receive-pack-aliased-update-fix' into js/maint-receive-pack-symref-alias
 (this branch uses tr/receive-pack-aliased-update-fix.)

* lt/extended-sha1-match-commit-with-regexp (2010-04-23) 1 commit
  (merged to 'next' on 2010-06-17 at 9ba2ec9)
 + Make :/ accept a regex rather than a fixed pattern

* mg/pretty-magic-space (2010-06-14) 1 commit
  (merged to 'next' on 2010-06-18 at dd5a896)
 + pretty: Introduce ' ' modifier to add space if non-empty

* rr/parse-date-refactor (2010-06-03) 1 commit
  (merged to 'next' on 2010-06-17 at c55f72b)
 + Refactor parse_date for approxidate functions

* sb/format-patch-signature (2010-06-15) 2 commits
  (merged to 'next' on 2010-06-18 at 4aee846)
 + completion: Add --signature and format.signature
 + format-patch: Add a signature option (--signature)

* sm/branch-broken-ref (2010-06-04) 2 commits
  (merged to 'next' on 2010-06-17 at cb81c35)
 + branch: don't fail listing branches if one of the commits wasn't found
 + branch: exit status now reflects if branch listing finds an error

* tc/commit-abbrev-fix (2010-06-12) 3 commits
  (merged to 'next' on 2010-06-16 at b2df7f8)
 + commit::print_summary(): don't use format_commit_message()
 + t7502-commit: add summary output tests for empty and merge commits
 + t7502-commit: add tests for summary output

* tc/maint-checkout-f-b (2010-06-21) 3 commits
 - builtin/checkout: Fix -f used with -b
 - t2018-checkout-branch.sh: "checkout -f -b" broken
 - add tests for checkout -b

* tr/receive-pack-aliased-update-fix (2010-06-10) 1 commit
  (merged to 'next' on 2010-06-14 at d3a3097)
 + check_aliased_update: strcpy() instead of strcat() to copy
 (this branch is used by js/maint-receive-pack-symref-alias.)

--------------------------------------------------
[Stalled -- would discard unless there are some movements soon]

* js/rebase-origin-x (2010-02-05) 1 commit
 - [RFC w/o test and incomplete] rebase: add -x option to record original commit name

I retract my objection against the idea of -x; needs polishing before
moving forward.

* ab/i18n (2010-06-15) 3 commits
 . Add initial C, Shell and Perl gettext translations
 . fixup! Add infrastructure
 . Add infrastructure for translating Git with gettext

The parts that touch other topics in flight probably need to be split into
separate patches; otherwise it is unmanageable.

* ab/tap (2010-06-15) 5 commits
 . TAP: Make sure there's a newline before "ok" under harness
 . TAP: Say "pass" rather than "ok" on an empty line
 . We use TAP so the Perl test can run without scaffolding
 . Skip tests in a way that makes sense under TAP
 . Make test-lib.sh emit valid TAP format

Updated with a newer round but it seems to break "make -j8 test" when
merged to 'pu', hence ejected.  I was not sure why TAP is worth the
trouble, and I still am not sure.

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

* as/maint-completion-set-u-fix (2010-06-17) 1 commit
 - bash-completion: Fix __git_ps1 to work with "set -u"

Will merge to 'next'; seemed sane.

* zl/mailinfo-recode-patch (2010-06-14) 2 commits
 - add --recode-patch option to git-am
 - add --recode-patch option to git-mailinfo

Perhaps another round is coming?

* rr/svn-export (2010-06-10) 7 commits
 - Add LICENSE
 - Add SVN dump parser
 - Add infrastructure to write revisions in fast-export format
 - Add stream helper library
 - Add library for string-specific memory pool
 - Add cpp macro implementation of treaps
 - Add memory pool library

I recall there was another round of re-roll planned for this one.

* tr/rev-list-count (2010-06-17) 2 commits
 - bash completion: Support "divergence from upstream" messages in __git_ps1
 - rev-list: introduce --count option

I'd like an Ack/Nack on the tip one from people involved in the completion
scripts.

* tr/send-email-8bit (2010-06-17) 1 commit
  (merged to 'next' on 2010-06-23 at be75199)
 + send-email: ask about and declare 8bit mails

* jl/maint-diff-ignore-submodules (2010-06-08) 2 commits
  (merged to 'next' on 2010-06-23 at 057acb7)
 + Add optional parameters to the diff option "--ignore-submodules"
 + git diff: rename test that had a conflicting name

* cp/textconv-cat-file (2010-06-09) 4 commits
 - [DONTMERGE] git gui: use textconv filter for diff and blame
  (merged to 'next' on 2010-06-23 at eb6f216)
 + t/t8007: test textconv support for cat-file
 + textconv: support for cat_file
 + sha1_name: add get_sha1_with_context()
 (this branch uses ab/blame-textconv.)

I'd need to prod Shawn to take a look at the tip one, as I shouldn't be
applying it to my tree myself.

* ab/blame-textconv (2010-06-07) 3 commits
  (merged to 'next' on 2010-06-23 at a7da5af)
 + t/t8006: test textconv support for blame
 + textconv: support for blame
 + textconv: make the API public
 (this branch is used by cp/textconv-cat-file.)

* jn/grep-open (2010-06-21) 7 commits
  (merged to 'next' on 2010-06-22 at 8edca58)
 + t/t7811-grep-open.sh: remove broken/redundant creation of fake "less" script
 + t/t7811-grep-open.sh: ensure fake "less" is made executable
 + t/lib-pager.sh: remove unnecessary '^' from 'expr' regular expression
  (merged to 'next' on 2010-06-18 at cf96ea8)
 + grep -O: allow optional argument specifying the pager (or editor)
 + grep: Add the option '--open-files-in-pager'
 + Unify code paths of threaded greps
 + grep: refactor grep_objects loop into its own function

* pb/maint-perl-errmsg-no-dir (2010-06-18) 1 commit
  (merged to 'next' on 2010-06-23 at 990ea67)
 + Git.pm: better error message

* eb/double-convert-before-merge (2010-06-16) 1 commit
 - ll-merge: Normalize files before merging

If running git-to-worktree and then worktree-to-git _fixes_ something, it
means that these are not roundtrip operations; there is something that is
fundamentally wrong.  The commit log message doesn't help explaining it,
either.

* js/maint-am-rebase-invalid-author (2010-06-16) 1 commit
  (merged to 'next' on 2010-06-23 at b345ad5)
 + am: use get_author_ident_from_commit instead of mailinfo when rebasing

* ps/gitweb-soc (2010-06-02) 2 commits
  (merged to 'next' on 2010-06-13 at 92245ae)
 + git-instaweb: Add option to reuse previous config file
 + Makefile: Use $(sharedir)/gitweb for target 'install-gitweb'

If we are going to have a configuration variable to control this, I
strongly suspect that --reuse-config should be renamed so that the
variable can be named more sanely and in line with whatever option
that replaces it.

* cc/cherry-pick-stdin (2010-06-14) 3 commits
 - revert: do not rebuild argv on heap
 - revert: accept arbitrary rev-list options
 - t3508 (cherry-pick): futureproof against unmerged files

What's the doneness of this one?

* jn/show-num-walks (2010-06-01) 1 commit
  (merged to 'next' on 2010-06-23 at e61649c)
 + DWIM 'git show -5' to 'git show --do-walk -5'

* mg/rev-parse-lrbranches-locals (2010-05-14) 1 commit
 - revlist: Introduce --lrbranches and --locals revision specifiers
 (this branch uses mg/rev-parse-option-sifter-deprecation.)

I am reluctant to merge a patch that introduces an unpronounceable
option.

* mg/rev-parse-option-sifter-deprecation (2010-05-14) 3 commits
 - t6018: make sure all tested symbolic names are different revs
 - t6018: add tests for rev-list's --branches and --tags
 - rev-parse: deprecate use as an option sifter
 (this branch is used by mg/rev-parse-lrbranches-locals.)

I don't think these patches help anything.  Opinions?

Re: [PATCH] bash completion: Support "divergence from upstream" messages in __git_ps1

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> writes:
>
> * tr/rev-list-count (2010-06-17) 2 commits
>  - bash completion: Support "divergence from upstream" messages in __git_ps1
>  - rev-list: introduce --count option
>
> I'd like an Ack/Nack on the tip one from people involved in the completion
> scripts.

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

-- 
Shawn.

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Ævar Arnfjörð Bjarmason]

On Wed, Jun 23, 2010 at 22:09, Junio C Hamano <gitster@pobox.com> wrote:

> * ab/i18n (2010-06-15) 3 commits
>  . Add initial C, Shell and Perl gettext translations
>  . fixup! Add infrastructure
>  . Add infrastructure for translating Git with gettext
>
> The parts that touch other topics in flight probably need to be split into
> separate patches; otherwise it is unmanageable.

I've just submitted "[PATCH v5] Add infrastructure for translating Git
with gettext" (<1277332338-8486-1-git-send-email-avarab@gmail.com>)
that omits the "Add initial C, Shell and Perl gettext translations"
patch. This'll greatly ease merging it with other topics.

I can split it up further if you want, perhaps you'd like the changes
to the Makefile to be in one seperate patch? Although I don't see how
that makes it easier to merge since you'd have to solve that conflict
anyway, but perhaps your workflow is different from mine.

Tell me if I can do anything else to make it easier to merge it.

> * ab/tap (2010-06-15) 5 commits
>  . TAP: Make sure there's a newline before "ok" under harness
>  . TAP: Say "pass" rather than "ok" on an empty line
>  . We use TAP so the Perl test can run without scaffolding
>  . Skip tests in a way that makes sense under TAP
>  . Make test-lib.sh emit valid TAP format
>
> Updated with a newer round but it seems to break "make -j8 test" when
> merged to 'pu', hence ejected.

How does it break under pu? I can't see any suspicious behavior when
running it. I've run it with -j1 and -j8 in both next and pu and I get
the same test test-results/ every time.

> I was not sure why TAP is worth the trouble, and I still am not
> sure.

Covered in comments to a previous "What's cooking" post.

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Nazri Ramliy]

On Thu, Jun 24, 2010 at 6:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
> [New Topics]
>
> * ar/decorate-color (2010-06-23) 4 commits
>  - Allow customizable commit decorations colors

This commit has some style violations. I've just sent a replacement patch, with
an explanation of (and an apology for) the offences [1].

nazri

[1] http://mid.gmane.org/1277338876-21958-1-git-send-email-ayiehere@gmail.com

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Tay Ray Chuan]

Hi,

On Thu, Jun 24, 2010 at 6:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
> [snip]
> * tc/maint-checkout-f-b (2010-06-21) 3 commits
>  - builtin/checkout: Fix -f used with -b
>  - t2018-checkout-branch.sh: "checkout -f -b" broken
>  - add tests for checkout -b

In case anyone is wondering, this series has been dropped in lieu of
"tc/checkout-B".

-- 
Cheers,
Ray Chuan

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Finn Arne Gangstad]

On Wed, Jun 23, 2010 at 03:09:32PM -0700, Junio C Hamano wrote:

> * eb/double-convert-before-merge (2010-06-16) 1 commit
>  - ll-merge: Normalize files before merging
> 
> If running git-to-worktree and then worktree-to-git _fixes_ something, it
> means that these are not roundtrip operations; there is something that is
> fundamentally wrong.  The commit log message doesn't help explaining it,
> either.

If .gitattributes is different on the different sides, or if you
enable autocrlf, the current repo contents may change after
git-to-worktree and worktree-to-git again. This is most easily seen if
you add some eol attributes, but also with clean/smudge filters, ident
and so on.

Assume you start out with a repo that has a lot of text files with
CRLF checked in (A).

  C----
 /     \
A---B---D

B: Add "* text=auto" to .gitattributes and normalize all files to LF
only in repo

D: try to merge C

Without this patch you will get a ridiculous number of lf/crlf
conflicts when trying to merge C into D, since the repository contents
for C are "wrong" wrt the new .gitattributes file.

- Finn Arne

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Johannes Sixt]

Am 6/24/2010 13:17, schrieb Finn Arne Gangstad:
> Assume you start out with a repo that has a lot of text files with
> CRLF checked in (A).
> 
>   C----
>  /     \
> A---B---D
> 
> B: Add "* text=auto" to .gitattributes and normalize all files to LF
> only in repo
> 
> D: try to merge C
> 
> Without this patch you will get a ridiculous number of lf/crlf
> conflicts when trying to merge C into D, since the repository contents
> for C are "wrong" wrt the new .gitattributes file.

What should happen when you have C checked out (i.e., you do not yet have
the updated .gitattributes in your worktree nor index) and merge B?
Currently, you get the identical conflicts, but I suspect that the patch
does not help in this situation. IOW, it breaks the merge symmetry.

-- Hannes

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Finn Arne Gangstad]

On Thu, Jun 24, 2010 at 01:42:56PM +0200, Johannes Sixt wrote:
> Am 6/24/2010 13:17, schrieb Finn Arne Gangstad:
> > Assume you start out with a repo that has a lot of text files with
> > CRLF checked in (A).
> > 
> >   C----
> >  /     \
> > A---B---D
> > 
> > B: Add "* text=auto" to .gitattributes and normalize all files to LF
> > only in repo
> > 
> > D: try to merge C
> > 
> > Without this patch you will get a ridiculous number of lf/crlf
> > conflicts when trying to merge C into D, since the repository contents
> > for C are "wrong" wrt the new .gitattributes file.
> 
> What should happen when you have C checked out (i.e., you do not yet have
> the updated .gitattributes in your worktree nor index) and merge B?
> Currently, you get the identical conflicts, but I suspect that the patch
> does not help in this situation. IOW, it breaks the merge symmetry.

git merges .gitattributes early, so it will work any way you do the
merge I think? Each file in a merge is processed separately with
whatever .gitattributes file is active.

If you get a conflict in .gitattributes you may be in a slightly
interesting spot, but you will still get all the new attributes in the
conflicted file, so in practice it should still work. git ignores the
conflict markers in .gitattributes and moves on..

- Finn Arne

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Eyvind Bernhardsen]

On 24. juni 2010, at 13.42, Johannes Sixt wrote:

> Am 6/24/2010 13:17, schrieb Finn Arne Gangstad:
>> Assume you start out with a repo that has a lot of text files with
>> CRLF checked in (A).
>> 
>>  C----
>> /     \
>> A---B---D
>> 
>> B: Add "* text=auto" to .gitattributes and normalize all files to LF
>> only in repo
>> 
>> D: try to merge C
>> 
>> Without this patch you will get a ridiculous number of lf/crlf
>> conflicts when trying to merge C into D, since the repository contents
>> for C are "wrong" wrt the new .gitattributes file.
> 
> What should happen when you have C checked out (i.e., you do not yet have
> the updated .gitattributes in your worktree nor index) and merge B?
> Currently, you get the identical conflicts, but I suspect that the patch
> does not help in this situation. IOW, it breaks the merge symmetry.

I confess that I didn't expect this to work either, but it does: the merge completes without conflict.  This is even covered in the included test script ("Check merging addition of text=auto").

I've cleaned the patch up a bit and added automatic delete/normalize conflict resolution.  Will submit a new version soon.
-- 
Eyvind Bernhardsen

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Johannes Sixt]

Am 6/24/2010 0:09, schrieb Junio C Hamano:
> * cp/textconv-cat-file (2010-06-09) 4 commits
>  - [DONTMERGE] git gui: use textconv filter for diff and blame

This git-gui patch needs a fixup.

-- Hannes

diff --git a/git-gui/lib/diff.tcl b/git-gui/lib/diff.tcl
index b02d2e5..c628750 100644
--- a/git-gui/lib/diff.tcl
+++ b/git-gui/lib/diff.tcl
@@ -280,7 +280,7 @@ proc start_show_diff {cont_info {add_opts {}}} {
 			lappend cmd diff-files
 		}
 	}
-	if {![is_config_false gui.textconv] && [git-version >ñ.6.1]} {
+	if {![is_config_false gui.textconv] && [git-version >= 1.6.1]} {
 		lappend cmd --textconv
 	}

git log --objects

[Holger Hellmuth]

Shouldn't 'git log --objects' print out a list of all objects in the
file tree of the commits it lists?

I tried git log with lots of other parameters, for example '-p' and
never saw any difference to the normal output and definitely no list of
hash ids.

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Clément Poulain]

> Am 6/24/2010 0:09, schrieb Junio C Hamano:
>> * cp/textconv-cat-file (2010-06-09) 4 commits
>>  - [DONTMERGE] git gui: use textconv filter for diff and blame
> 
> This git-gui patch needs a fixup.

I wonder where do this come from.
It's seems to be OK there:
http://mid.gmane.org/1276102929-31712-4-git-send-email-clement.poulain@ensimag.imag.fr
doesn't it ?

Regards

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Junio C Hamano]

Finn Arne Gangstad <finnag@pvv.org> writes:

> On Wed, Jun 23, 2010 at 03:09:32PM -0700, Junio C Hamano wrote:
>
>> * eb/double-convert-before-merge (2010-06-16) 1 commit
>>  - ll-merge: Normalize files before merging
>> 
>> If running git-to-worktree and then worktree-to-git _fixes_ something, it
>> means that these are not roundtrip operations; there is something that is
>> fundamentally wrong.  The commit log message doesn't help explaining it,
>> either.
>
> If .gitattributes is different on the different sides, or if you
> enable autocrlf, the current repo contents may change after
> git-to-worktree and worktree-to-git again.

IOW, g2w-then-w2g may not be an identity function.

If we were to encourage use of this codepath to wider audiences, we may
need to have a document for people who write smudge/clean filters.  In
order for the result to be stable, applying g2w-then-w2g once again on top
of the result of running g2w-then-w2g on anything should be no-op, no?

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Eyvind Bernhardsen]

On 24. juni 2010, at 22.21, Junio C Hamano wrote:

> Finn Arne Gangstad <finnag@pvv.org> writes:
> 
>> If .gitattributes is different on the different sides, or if you
>> enable autocrlf, the current repo contents may change after
>> git-to-worktree and worktree-to-git again.
> 
> IOW, g2w-then-w2g may not be an identity function.
> 
> If we were to encourage use of this codepath to wider audiences, we may
> need to have a document for people who write smudge/clean filters.  In
> order for the result to be stable, applying g2w-then-w2g once again on top
> of the result of running g2w-then-w2g on anything should be no-op, no?

Hm.  Isn't that already a requirement?  If a clean filter doesn't clean to something normalized, simply touching a file could result in spurious differences (much like pre-safe-autocrlf autocrlf).  I could well be missing something here, though.
-- 
Eyvind

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Junio C Hamano]

Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> writes:

> On 24. juni 2010, at 22.21, Junio C Hamano wrote:
>
>> Finn Arne Gangstad <finnag@pvv.org> writes:
>> 
>>> If .gitattributes is different on the different sides, or if you
>>> enable autocrlf, the current repo contents may change after
>>> git-to-worktree and worktree-to-git again.
>> 
>> IOW, g2w-then-w2g may not be an identity function.
>> 
>> If we were to encourage use of this codepath to wider audiences, we may
>> need to have a document for people who write smudge/clean filters.  In
>> order for the result to be stable, applying g2w-then-w2g once again on top
>> of the result of running g2w-then-w2g on anything should be no-op, no?
>
> Hm.  Isn't that already a requirement?  If a clean filter doesn't clean
> to something normalized, simply touching a file could result in spurious
> differences (much like pre-safe-autocrlf autocrlf).  I could well be
> missing something here, though.

A natural expectation would be that g2w-then-w2g is an identity function,
I think.  But the "feature" under discussion in this thread depends on
that g2w-then-w2g is _not_ a noop (otherwise it wouldn't do us any good).

IOW, we are suggesting authors of clean/smudge to make their g2w-then-w2g
perform more than just a round-trip but actively _clean things up_, aren't
we?  I don't think we have documented that suggestion, and I actually
think we might even have said that g2w-then-w2g should be a no-op
somewhere in the documentation.

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Christian Couder]

On Thursday 24 June 2010 00:09:32 Junio C Hamano wrote:
> 
> * cc/cherry-pick-stdin (2010-06-14) 3 commits
>  - revert: do not rebuild argv on heap
>  - revert: accept arbitrary rev-list options
>  - t3508 (cherry-pick): futureproof against unmerged files
> 
> What's the doneness of this one?

With the documentation fix I just posted, I think it is finished.

Thanks,
Christian.

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Johannes Sixt]

Am 6/24/2010 22:21, schrieb Junio C Hamano:
> Finn Arne Gangstad <finnag@pvv.org> writes:
>> If .gitattributes is different on the different sides, or if you
>> enable autocrlf, the current repo contents may change after
>> git-to-worktree and worktree-to-git again.
> 
> IOW, g2w-then-w2g may not be an identity function.
> 
> If we were to encourage use of this codepath to wider audiences, we may
> need to have a document for people who write smudge/clean filters.  In
> order for the result to be stable, applying g2w-then-w2g once again on top
> of the result of running g2w-then-w2g on anything should be no-op, no?

I think this is implicit to some degree in the documentation,
gitattributes(5):

  The content filtering is done to massage the content into a shape that
  is more convenient for the platform, filesystem, and the user to use.
  [...] the intent is that if someone unsets the filter driver
  definition, or does not have the appropriate filter program, the
  project should still be usable.

>From this I read that the content of the repository can only be in a
canonical shape; hence, the only thing that a clean filter can do is to
generate the canonical shape of the data. This is, by definition, an
idempotent operation (i.e., g2w(g2w(x)) == g2w(x)).

(I'm talking only about clean filters because any pair of smudge+clean
filters where the clean filter cannot undo the effect of the smudge filter
would be noticed immediately and be considered broken without being
mentioned explicitly in the documentation.)

-- Hannes

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Finn Arne Gangstad]

On Thu, Jun 24, 2010 at 01:21:49PM -0700, Junio C Hamano wrote:
> >
> > If .gitattributes is different on the different sides, or if you
> > enable autocrlf, the current repo contents may change after
> > git-to-worktree and worktree-to-git again.
> 
> IOW, g2w-then-w2g may not be an identity function.

Absolutely, pretty much by definition this cannot be the case (and is
not the case for any of the built-in filters like eol, autocrlf,
ident), since you have no control of what you have in the repository
before you enable the filter.

What we assume though is that g2w(g2w(x)) == g2w(x). I think it is
very hard to come up with a reasonable case for a filter where that is
not the case.

> If we were to encourage use of this codepath to wider audiences, we may
> need to have a document for people who write smudge/clean filters.  In
> order for the result to be stable, applying g2w-then-w2g once again on top
> of the result of running g2w-then-w2g on anything should be no-op, no?

This _has_ to work, otherwise you would get dirty contents after a
checkout, and that would be horrible.

So, the follolwing should be true:

g2w(x) == g2w(g2w(x))
A -> g2w() -> B -> g2w() -> B ... 

w2g(g2w(x)) == w2g(g2w(w2g(g2w(x))))
X -> g2w() -> w2g() -> Y -> g2w() -> w2g() -> Y ...

Running w2g() twice should also be the same as running it once. 
I thought nothing in git required it as such, but in the case of a
missing smudge filter git will call w2g() on something that is already
cleaned. I think the clean/smudge guidelines should be:

  "Both clean and smudge filters should be idempotent; running them
   multiple times should not alter the contents further."

- Finn Arne

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Finn Arne Gangstad]

On Thu, Jun 24, 2010 at 03:48:36PM -0700, Junio C Hamano wrote:

> A natural expectation would be that g2w-then-w2g is an identity function,
> I think.  But the "feature" under discussion in this thread depends on
> that g2w-then-w2g is _not_ a noop (otherwise it wouldn't do us any good).

This is a natural expecation for subsequent runs. The first time you
run it though, it makes more sense (and all built in filters act this
way) to change the file to its canonical form instead. If it already
is in its canonical form, you expect no further change.

> IOW, we are suggesting authors of clean/smudge to make their g2w-then-w2g
> perform more than just a round-trip but actively _clean things up_, aren't
> we?  I don't think we have documented that suggestion, and I actually
> think we might even have said that g2w-then-w2g should be a no-op
> somewhere in the documentation.

It's not that we suggest they should clean things up, it is that they
ALREADY clean things up. It's hard to make a reasonable filter that
doesn't. And git should (and can!) give you some assistance in
handling cleanup-related changes if you have such a filter.

To make a non-normalizing filter, both of these would have to be true:
1. g2w then g2w again would change the file even more
2. w2g on something that was run twice through g2w would be equivalent
   to running it through g2w once.. e.g. w2g(g2w(g2w(x))) == g2w(x),
   can't think of any resaonable scenario.

If you somehow manage to make a filter where w2g(g2w(x)) == x for all
x, the patch under discussion will not create any problems. I've never
seen such a filter though.

- Finn Arne

Re: git log --objects

[Santi Béjar]

On Thu, Jun 24, 2010 at 5:33 PM, Holger Hellmuth <hellmuth@ira.uka.de> wrote:
> Shouldn't 'git log --objects' print out a list of all objects in the
> file tree of the commits it lists?

In fact --objects prints all objects reachable from the given commits
(or between commits if $commit1..$commit2)

>
> I tried git log with lots of other parameters, for example '-p' and
> never saw any difference to the normal output and definitely no list of
> hash ids.

I think --objects, --objects-edge, --unpacked are for "git rev-list".
So they should not be listed in git-log man page.

HTH,
Santi

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Ævar Arnfjörð Bjarmason]

On Wed, Jun 23, 2010 at 22:09, Junio C Hamano <gitster@pobox.com> wrote:
> Here are the topics that have been cooking.

Here are topics that I've submitted that haven't made it into a
"What's cooking" post, but which I consider ready for inclusion.

Since I'm not sure whether they've been rejected, ignored or just
forgotten I'm listing them here. It'd be nice to get an update on
their status so I can act appropriately on my end.

 * git-am: Ignore whitespace before patches
   (<1273944188-9472-1-git-send-email-avarab@gmail.com>)

  Junio commented:

    Actually cut-and-paste is often a major source of whitespace breakage
    (including tabs silently being expanded), and I personally think a patch
    like this to encourage the practice is going in a wrong direction.

  my reply:

    What it does is enable the GMail -> download -> git-am workflow. GMail
    (and doubtless countless other) E-Mail providers introduce whitespace
    at the beginning of raw E-Mail messages, while otherwise leaving them
    intact.

  That patch just makes git-am smarter while harming nothing. Given
  the fuzzy behavior of E-Mail programs I think it should be included,
  and generally that patch detection should try harder before failing.


 * Remove editor-specific droppings from .gitignore
   (<1274061883-18043-1-git-send-email-avarab@gmail.com>).

   Micro-cleanup that removes the (as far as I can see) only case
   where .gitignore isn't ignoring something generated by the build
   system. Context:

      On Mon, May 17, 2010 at 01:35, Jonathan Nieder <jrnieder@gmail.com> wrote:
      > Michael J Gruber wrote:
      >
      >> Does the git build process call format-patch? No! The .gitignore we
      >> distribute is meant for things the build process creates
      >
      > Ah, true. I seem to remember a thread long ago about whether to
      > include editor droppings in .gitignore, but I can’t find it in
      > the git or lkml archive.
      >
      > git’s .gitignore does not include .*.swp, \#*#, *~, indeed.

      Thanks both of you, I stand corrected. Anyway, I guess this is a bug
      then. It's the only thing ignored by Git's various .gitignore files
      that isn't created by the build system.

   The patch was acked by Michael J Gruber <git@drmicha.warpmail.net>.

 * perl libs: perl -w + use warnings is redundant
   (<1274460741-9674-1-git-send-email-avarab@gmail.com>).

   A minor cleanup of our Perl code, uses lexical warnings instead of
   global warnings in code that's known to require Perl 5.6.0 or
   later. Doesn't change behavior but uses the recommended Perl form.

 * sha1_file: Show the the type and path to corrupt objects
   (<1276174021-9544-1-git-send-email-avarab@gmail.com>).

   Make the error message for git-cat-file's (and other blog accessor
   functions) more specific. From the commit message:

      Change the error message that's displayed when we encounter corrupt
      objects to be more specific. We now print the type (loose or packed)
      of corrupted objects, along with the full path to the file in
      question.

      Before:

         $ git cat-file blob 909ef997367880aaf2133bafa1f1a71aa28e09df
         fatal: object 909ef997367880aaf2133bafa1f1a71aa28e09df is corrupted

      After:

         $ git cat-file blob 909ef997367880aaf2133bafa1f1a71aa28e09df
         fatal: loose object 909ef997367880aaf2133bafa1f1a71aa28e09df
(stored in .git/objects/90/9ef997367880aaf2133bafa1f1a71aa28e09df) is
corrupted

      Knowing the path helps to quickly analyze what's wrong:

         $ file .git/objects/90/9ef997367880aaf2133bafa1f1a71aa28e09df
         .git/objects/90/9ef997367880aaf2133bafa1f1a71aa28e09df: empty

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 24.06.2010 00:09:
> 
> * mg/rev-parse-lrbranches-locals (2010-05-14) 1 commit
>  - revlist: Introduce --lrbranches and --locals revision specifiers
>  (this branch uses mg/rev-parse-option-sifter-deprecation.)
> 
> I am reluctant to merge a patch that introduces an unpronounceable
> option.

While I could tell you how to pronounce it, I actually was about to
suggest dropping this patch! I don't like the name lrbranches, we have
two names (heads/branches) for local branch heads already, and couldn't
come up with a better name, available name meaning "all branch heads".

> 
> * mg/rev-parse-option-sifter-deprecation (2010-05-14) 3 commits
>  - t6018: make sure all tested symbolic names are different revs
>  - t6018: add tests for rev-list's --branches and --tags
>  - rev-parse: deprecate use as an option sifter
>  (this branch is used by mg/rev-parse-lrbranches-locals.)
> 
> I don't think these patches help anything.  Opinions?

They helped the patch which is going to get dropped...

Besides that: The two test patches improve the tests. t6018 gives the
impression to test something which it doesn't (because some symbolic
names point to the same rev, so it doesn't test whether rev-parse really
resolves all of them), and was lacking coverage for --branches and
--tags. So I think those two are independent improvements.

About the "deprecation/discouragement notice" for rev-parse I don't
know. rev-parse is not completely in sync with all rev-list options, and
doesn't mean to be if I understood correctly. I know that now. As long
as nobody cares, nobody cares...

Cheers,
Michael

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Eyvind Bernhardsen]

On 25. juni 2010, at 00.48, Junio C Hamano wrote:

> Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> writes:
> 
>> Hm.  Isn't that already a requirement?  If a clean filter doesn't clean
>> to something normalized, simply touching a file could result in spurious
>> differences (much like pre-safe-autocrlf autocrlf).  I could well be
>> missing something here, though.
> 
> A natural expectation would be that g2w-then-w2g is an identity function,
> I think.  But the "feature" under discussion in this thread depends on
> that g2w-then-w2g is _not_ a noop (otherwise it wouldn't do us any good).

Well, it assumes that g2w does not smudge already smudged data (or that w2g can clean up after double smudging), but when the assumption fails you end up with the same merge conflict you would get without this series.  Is it important that _all_ filters support merging?

> IOW, we are suggesting authors of clean/smudge to make their g2w-then-w2g
> perform more than just a round-trip but actively _clean things up_, aren't
> we?  I don't think we have documented that suggestion, and I actually
> think we might even have said that g2w-then-w2g should be a no-op
> somewhere in the documentation.

I think it's worth documenting that a well-written ("normalizing", as Finn Arne said) filter allows automatic merging of filtered and unfiltered data.  I'll see what I can come up with.
-- 
Eyvind

Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

[Junio C Hamano]

Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> writes:

> I think it's worth documenting that a well-written ("normalizing", as
> Finn Arne said) filter allows automatic merging of filtered and
> unfiltered data.  I'll see what I can come up with.

Thanks, both.