What's cooking in git.git (Apr 2010, #03; Wed, 07)

What's cooking in git.git (Apr 2010, #03; Wed, 07)

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

We are at a bit beyond 1.7.1-rc0 now.

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

* sg/bash-completion (2010-02-23) 4 commits
  (merged to 'next' on 2010-03-08 at bc59860)
 + bash: completion for gitk aliases
 + bash: support user-supplied completion scripts for aliases
 + bash: support user-supplied completion scripts for user's git commands
 + bash: improve aliased command recognition

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

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

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

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

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

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

* jn/mailinfo-scissors (2010-04-03) 1 commit
  (merged to 'next' on 2010-04-05 at 366435a)
 + Teach mailinfo %< as an alternative scissors mark

* mg/notes-reflog (2010-03-29) 2 commits
  (merged to 'next' on 2010-04-06 at 1b8066f)
 + refs.c: Write reflogs for notes just like for branch heads
 + t3301-notes: Test the creation of reflog entries

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

* eb/unpretty-b-format (2010-03-24) 1 commit
  (merged to 'next' on 2010-04-07 at 7f5c112)
 + Add `%B' in format strings for raw commit body in `git log' and friends

* ne/rev-cache (2010-04-05) 7 commits
 - graft awareness
 - object name support
 - integration into revision walker
 - administrative api and tools
 - support for non-commit objects
 - basic api and porcelain
 - man page and technical docs

For some reason this was extremely hard to read, partly because it had too
many distracting style violations and too many long lines.  I'll start
reading it later in the week when I find time to comment.

* jp/hold-sring-list-sanity (2010-04-06) 6 commits
 . string_list: Fix argument order for string_list_append
 . string_list: Fix argument order for string_list_lookup
 . string_list: Fix argument order for string_list_insert_at_index
 . string_list: Fix argument order for string_list_insert
 . string_list: Fix argument order for for_each_string_list
 . string_list: Fix argument order for print_string_list
 (this branch uses js/grep-open and sr/remote-helper-export.)

Building this on top of slushy codebase is not a very promising endeavor.
Good thing to do, but bad timing.

* ab/commit-empty-message (2010-04-06) 1 commit
  (merged to 'next' on 2010-04-07 at 701e863)
 + Add option to git-commit to allow empty log messages

* jc/test-sleepless (2010-04-06) 1 commit
  (merged to 'next' on 2010-04-07 at 8ccf40a)
 + war on "sleep" in tests

* jc/maint-reflog-expire-unreachable (2010-04-07) 2 commits
 - reflog --expire-unreachable: a side note
 - reflog --expire-unreachable: avoid merge-base computation

* jc/doc-submit-gmail (2010-04-07) 1 commit
 - SubmittingPatches: update GMail section

* tc/maint-curl-helper (2010-04-08) 1 commit
 - remote-curl: avoid double-slashes in HTTP requests

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

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

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

* js/grep-open (2010-03-26) 2 commits
 - grep -O: allow optional argument specifying the pager (or editor)
 - grep: Add the option '--open-files-in-pager'
 (this branch is used by jp/hold-sring-list-sanity.)

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

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

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

* np/malloc-threading (2010-04-07) 2 commits
 - Make xmalloc and xrealloc thread-safe (addendum)
 - Make xmalloc and xrealloc thread-safe

Updated with Freku's "init_recursive_mutex()".  The fix should eventually
go to 'maint' and 'master'.

* js/async-thread (2010-03-09) 7 commits
 - Enable threaded async procedures whenever pthreads is available
  (merged to 'next' on 2010-03-20 at 9939243)
 + Dying in an async procedure should only exit the thread, not the process.
 + Reimplement async procedures using pthreads
 + Windows: more pthreads functions
 + Fix signature of fcntl() compatibility dummy
 + Make report() from usage.c public as vreportf() and use it.
 + Modernize t5530-upload-pack-error.

Been waiting for resolution of locking issues in malloc-threading.

* sd/log-decorate (2010-04-06) 4 commits
  (merged to 'next' on 2010-04-06 at 992c9ad)
 + log --pretty/--oneline: ignore log.decorate
  (merged to 'next' on 2010-03-08 at 58a6fba)
 + log.decorate: usability fixes
 + Add `log.decorate' configuration variable.
 + git_config_maybe_bool()

I did the tip one myself.  An extra set or two of eyeballs would be
appreciated.

* mh/status-optionally-refresh (2010-04-03) 3 commits
  (merged to 'next' on 2010-04-05 at 0e64aac)
 + t7508: add a test for "git status" in a read-only repository
 + git status: refresh the index if possible
 + t7508: add test for "git status" refreshing the index

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

* rr/remote-helper-doc (2010-04-07) 3 commits
 - Documentation/remote-helpers: Add invocation section
 - Documentation/urls: Rewrite to accomodate <transport>::<address>
 - Documentation/remote-helpers: Rewrite description

* sr/remote-helper-export (2010-03-29) 7 commits
  (merged to 'next' on 2010-04-07 at 5651307)
 + remote-helpers: add tests for testgit helper
 + remote-helpers: add testgit helper
 + remote-helpers: add support for an export command
 + remote-helpers: allow requesing the path to the .git directory
 + fast-import: always create marks_file directories
 + clone: also configure url for bare clones
 + clone: pass the remote name to remote_get
 (this branch is used by jp/hold-sring-list-sanity.)

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

This is more about debugging and we are not in a great hurry.

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

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

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

* ld/discovery-limit-to-fs (2010-04-04) 6 commits
 - write-index: check and warn when worktree crosses a filesystem boundary
  (merged to 'next' on 2010-04-07 at 11ea09a)
 + Rename ONE_FILESYSTEM to DISCOVERY_ACROSS_FILESYSTEM
 + GIT_ONE_FILESYSTEM: flip the default to stop at filesystem boundaries
 + Add support for GIT_ONE_FILESYSTEM
 + truncate cwd string before printing error message
 + config.c: remove static keyword from git_env_bool()

The tip one is a bit iffy; the whole series changes behaviour in a corner
case, and is not a 1.7.1 material.

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

I cherry-picked only obviously sensible bits.

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

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

* ar/config-from-command-line (2010-03-26) 2 commits
  (merged to 'next' on 2010-04-07 at e50fd3a)
 + Use strbufs instead of open-coded string manipulation
 + Allow passing of configuration parameters in the command line

* nd/setup (2010-04-05) 43 commits
 - builtins: do not commit pager choice early
 - builtins: setup repository before print unknown command error
 - t0001: Add test cases for "git init" with aliases
 - Guard unallowed access to repository when it's not set up
 - alias: keep repository found while collecting aliases as long as possible
 - Allow to undo setup_git_directory_gently() gracefully (and fix alias code)
 - builtins: check for startup_info->help, print and exit early
 - builtins: utilize startup_info->help where possible
 - run_builtin(): save "-h" detection result for later use
 - config: do not read .git/config if there is no repository
 - apply: do not check sha1 if there is no repository
 - Do not read .git/info/attributes if there is no repository
 - Do not read .git/info/exclude if there is no repository
 - git_config(): do not read .git/config if there is no repository
 - init/clone: turn on startup->have_repository properly
 - worktree setup: restore original state when things go wrong
 - Use git_config_early() instead of git_config() during repo setup
 - Add git_config_early()
 - worktree setup: call set_git_dir explicitly
 - rev-parse --git-dir: print relative gitdir correctly
 - enter_repo(): initialize other variables as setup_git_directory_gently() does
 - Move enter_repo() to setup.c
 - index-pack: use RUN_SETUP_GENTLY
 - index-pack: trust the prefix returned by setup_git_directory_gently()
 - worktree setup: calculate prefix even if no worktree is found
 - merge-file: use RUN_SETUP_GENTLY
 - var: use RUN_SETUP_GENTLY
 - ls-remote: use RUN_SETUP_GENTLY
 - help: take note why this command is not applicable for RUN_SETUP_GENTLY
 - diff: use RUN_SETUP_GENTLY
 - bundle: use RUN_SETUP_GENTLY
 - apply: use RUN_SETUP_GENTLY
 - verify-pack: use RUN_SETUP_GENTLY
 - check-ref-format: use RUN_SETUP_GENTLY
 - mailinfo: use RUN_SETUP_GENTLY
 - archive: use RUN_SETUP_GENTLY
 - builtin: USE_PAGER should not be used without RUN_SETUP*
 - grep: use RUN_SETUP_GENTLY
 - shortlog: use RUN_SETUP_GENTLY
 - hash-object: use RUN_SETUP_GENTLY
 - config: use RUN_SETUP_GENTLY
 - builtin: Support RUN_SETUP_GENTLY to set up repository early if found
 - builtin: introduce startup_info struct

Rerolled.  I need to look at this series during the feature freeze so that
we can decide to (or not to) include it in 'next' early in post 1.7.1 cycle.

Re: What's cooking in git.git (Apr 2010, #03; Wed, 07)

[Johannes Sixt]

Am 4/8/2010 2:48, schrieb Junio C Hamano:
> * np/malloc-threading (2010-04-07) 2 commits
>  - Make xmalloc and xrealloc thread-safe (addendum)
>  - Make xmalloc and xrealloc thread-safe
> 
> Updated with Freku's "init_recursive_mutex()".  The fix should eventually
> go to 'maint' and 'master'.

The addendum does not compile on Windows. I'm working on a replacement.

BTW, are there Unices that do not have a recursive mutex?

-- Hannes

Re: What's cooking in git.git (Apr 2010, #03; Wed, 07)

[Junio C Hamano]

Johannes Sixt <j.sixt@viscovery.net> writes:

> Am 4/8/2010 2:48, schrieb Junio C Hamano:
>> * np/malloc-threading (2010-04-07) 2 commits
>>  - Make xmalloc and xrealloc thread-safe (addendum)
>>  - Make xmalloc and xrealloc thread-safe
>> 
>> Updated with Freku's "init_recursive_mutex()".  The fix should eventually
>> go to 'maint' and 'master'.
>
> The addendum does not compile on Windows. I'm working on a replacement.

Thanks.

> BTW, are there Unices that do not have a recursive mutex?

PTHREAD_MUTEX_RECURSIVE is not marked as optional in any way, so I would
imagine an implementation that lacks it would say NO_PTHREADS in the
Makefile.

Cf.

  http://www.opengroup.org/onlinepubs/9699919799/basedefs/pthread.h.html

Re: What's cooking in git.git (Apr 2010, #03; Wed, 07)

[Jeff King]

On Wed, Apr 07, 2010 at 05:48:02PM -0700, Junio C Hamano wrote:

> * jc/test-sleepless (2010-04-06) 1 commit
>   (merged to 'next' on 2010-04-07 at 8ccf40a)
>  + war on "sleep" in tests

I read this one, and it looked fine to me.

> * sd/log-decorate (2010-04-06) 4 commits
>   (merged to 'next' on 2010-04-06 at 992c9ad)
>  + log --pretty/--oneline: ignore log.decorate
>   (merged to 'next' on 2010-03-08 at 58a6fba)
>  + log.decorate: usability fixes
>  + Add `log.decorate' configuration variable.
>  + git_config_maybe_bool()
> 
> I did the tip one myself.  An extra set or two of eyeballs would be
> appreciated.

I just responded in that thread.

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

You mentioned pushing this off to 1.7.2. I don't have a problem with
that, but you may want to cherry-pick or merge up to the "fix textconv
leak", as it is an unrelated fix.

I think it makes sense to target 1.7.2 with the feature, and then flip
the default for diff.*.cachetextconv to 'true' in 1.7.3. That will give
it some wider exposure before we start running it by default.

> * nd/setup (2010-04-05) 43 commits
> [...]
> Rerolled.  I need to look at this series during the feature freeze so that
> we can decide to (or not to) include it in 'next' early in post 1.7.1 cycle.

I really should review this, but it's just so dauntingly large and
boring looking that I haven't gotten around to it. Probably one or both
of us should look at it before applying it to next, but assuming it
passes a basic sanity check, I think the best thing will be to get it in
'next' early so we can shake out any bugs during the next cycle.

-Peff

Re: What's cooking in git.git (Apr 2010, #03; Wed, 07)

[Fredrik Kuivinen]

On Thu, Apr 8, 2010 at 08:33, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>> BTW, are there Unices that do not have a recursive mutex?
>
> PTHREAD_MUTEX_RECURSIVE is not marked as optional in any way, so I would
> imagine an implementation that lacks it would say NO_PTHREADS in the
> Makefile.
>
> Cf.
>
>  http://www.opengroup.org/onlinepubs/9699919799/basedefs/pthread.h.html

For some reason I looked at Issue 6 of the standard (a previous
version, released in 2004). In that version pthread_mutexattr_settype
and PTHREAD_MUTEX_RECURSIVE are optional. See
http://www.opengroup.org/onlinepubs/009695399/basedefs/pthread.h.html

However, it is probably best to just ignore the issue for now until
some platform appears where pthreads is available but not recursive
mutexes.

- Fredrik

Re: ***SPAM*** Re: What's cooking in git.git (Apr 2010, #03; Wed, 07)

[Tor Arntsen]

On Thu, Apr 8, 2010 at 11:01, Fredrik Kuivinen <frekui@gmail.com> wrote:

> For some reason I looked at Issue 6 of the standard (a previous
> version, released in 2004). In that version pthread_mutexattr_settype
> and PTHREAD_MUTEX_RECURSIVE are optional. See
> http://www.opengroup.org/onlinepubs/009695399/basedefs/pthread.h.html
>
> However, it is probably best to just ignore the issue for now until
> some platform appears where pthreads is available but not recursive
> mutexes.

IRIX 6.2 has one of those early, primitive implementations. It doesn't
seem to have PTHREAD_MUTEX_RECURSIVE, even though it has pthread_mutex
functions.  Every other system I have (irix 6.5/solaris/aix) appears
to have PTHREAD_MUTEX_RECURSIVE.

-Tor

Re: ***SPAM*** Re: What's cooking in git.git (Apr 2010, #03; Wed, 07)

[Tor Arntsen]

On Thu, Apr 8, 2010 at 11:14, Tor Arntsen <tor@spacetec.no> wrote:
> Every other system I have (irix 6.5/solaris/aix) appears
> to have PTHREAD_MUTEX_RECURSIVE.

I forgot Tru64 5.1, which is also OK in this respect. So, IRIX 6.2 is
negative for now.

-Tor

nd/setup

[Jonathan Nieder]

Jeff King wrote:
> On Wed, Apr 07, 2010 at 05:48:02PM -0700, Junio C Hamano wrote:

>> * nd/setup (2010-04-05) 43 commits
[...]
> Probably one or both
> of us should look at it before applying it to next, but assuming it
> passes a basic sanity check, I think the best thing will be to get it in
> 'next' early so we can shake out any bugs during the next cycle.

I don’t think it’s anywhere near master material yet.

First, the basic problem.  The core of the series is in patch 40,
which adds a new runtime self-checker for git.  Kind of like lockdep.
Instead of proving locking correctness, this proves that whenever git
tries to access the repository, it has already been clearly and
unambiguously declared which repository to access (and in particular,
whether to try to access a repository at all).  Very neat, and it
reveals many bugs, which is nice.

When lockdep finds a locking problem, it quietly prints a message to
the kernel log and the kernel is able to keep going without worrying
about it.  Unfortunately, the repository access checker from nd/setup
is not so graceful: it makes git die even though it should be able to
carry on just fine.  Example: with nd/setup, ls-remote currently fails
when run outside any repository.  Probably the checker should be
configured by an environment variable that indicates where to print
its messages and whether to bail out when a problem is detected (for
tests).

A few of the earlier patches seem iffy, though they all start with a
correct idea.  For example, one of them changes the semantics of
rev-parse --show-prefix without documenting it.  So I have been looking
for time to document what each patch fixes.  Without some explanation
of what the patches are supposed to fix and what they are not supposed
to break, merging even them early would be a bit dangerous.

Sorry to be the bearer of bad tidings,
Jonathan

Re: nd/setup

[Jeff King]

On Thu, Apr 08, 2010 at 04:42:33PM -0500, Jonathan Nieder wrote:

> >> * nd/setup (2010-04-05) 43 commits
> [...]
> > Probably one or both
> > of us should look at it before applying it to next, but assuming it
> > passes a basic sanity check, I think the best thing will be to get it in
> > 'next' early so we can shake out any bugs during the next cycle.
> 
> I don’t think it’s anywhere near master material yet.

To clarify, I don't think that either. But sitting in pu, nobody is even
running it. This seems to me like the sort of topic where there will be
a lot of unintended fallouts. Besides review, the best way to find
them is to get people running it, and 'next' is the most bleeding-edge
we have.

> when run outside any repository.  Probably the checker should be
> configured by an environment variable that indicates where to print
> its messages and whether to bail out when a problem is detected (for
> tests).

Yeah, that sounds reasonable, especially if merging this to 'next' would
make git unusable. We want to shake out bugs, not punish people running
next. :) But I haven't even really looked at the topic in detail yet.

> Sorry to be the bearer of bad tidings,

Not at all. This is exactly the sort of in-depth review that is very
helpful. Thanks.

-Peff

Re: nd/setup

[Nguyen Thai Ngoc Duy]

2010/4/8 Jonathan Nieder <jrnieder@gmail.com>:
> When lockdep finds a locking problem, it quietly prints a message to
> the kernel log and the kernel is able to keep going without worrying
> about it.  Unfortunately, the repository access checker from nd/setup
> is not so graceful: it makes git die even though it should be able to
> carry on just fine.  Example: with nd/setup, ls-remote currently fails
> when run outside any repository.  Probably the checker should be
> configured by an environment variable that indicates where to print
> its messages and whether to bail out when a problem is detected (for
> tests).

The intention was to let that patch stay on next/pu for very long time
(or ever), while the rest of fixes can be merged up to master. That's
why it was the last patch (now close to the last).

I did use an env variable to control whether it die() when unallowed
access is found in early versions. Perhaps I should resurrect that env
variable.

> A few of the earlier patches seem iffy, though they all start with a
> correct idea.  For example, one of them changes the semantics of
> rev-parse --show-prefix without documenting it.  So I have been looking

You meant "rev-parse --git-dir"?
-- 
Duy

Re: nd/setup

[Jonathan Nieder]

Nguyen Thai Ngoc Duy wrote:
> 2010/4/8 Jonathan Nieder <jrnieder@gmail.com>:

>> A few of the earlier patches seem iffy, though they all start with a
>> correct idea.  For example, one of them changes the semantics of
>> rev-parse --show-prefix without documenting it.  So I have been looking
>
> You meant "rev-parse --git-dir"?

I meant --show-prefix.  ad36c84 (worktree setup: calculate prefix even
if no worktree is found, 2010-04-05) teaches rev-parse to produce a
nonempty prefix even when there is no workdir but didn’t update the
documentation:

    --show-prefix
         When the command is invoked from a subdirectory, show the
         path of the current directory relative to the top-level
         directory.

I suspect it’s a good change.  Git ought to correctly honor relative
paths on the command line even when there is no work tree.  But the
semantics are not clear any more --- when there is no top-level
directory, what is the prefix relative to?

Probably my other words of warning were also too extreme.  I have been
using a copy of git with nd/setup included, and aside from the
ls-remote problem I mentioned, I haven’t run into any trouble.

Cheers,
Jonathan

Re: nd/setup

[Nguyen Thai Ngoc Duy]

On Fri, Apr 9, 2010 at 7:57 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Nguyen Thai Ngoc Duy wrote:
>> 2010/4/8 Jonathan Nieder <jrnieder@gmail.com>:
>
>>> A few of the earlier patches seem iffy, though they all start with a
>>> correct idea.  For example, one of them changes the semantics of
>>> rev-parse --show-prefix without documenting it.  So I have been looking
>>
>> You meant "rev-parse --git-dir"?
>
> I meant --show-prefix.  ad36c84 (worktree setup: calculate prefix even
> if no worktree is found, 2010-04-05) teaches rev-parse to produce a
> nonempty prefix even when there is no workdir but didn’t update the
> documentation:
>
>    --show-prefix
>         When the command is invoked from a subdirectory, show the
>         path of the current directory relative to the top-level
>         directory.
>
> I suspect it’s a good change.  Git ought to correctly honor relative
> paths on the command line even when there is no work tree.  But the
> semantics are not clear any more --- when there is no top-level
> directory, what is the prefix relative to?
>
> Probably my other words of warning were also too extreme.  I have been
> using a copy of git with nd/setup included, and aside from the
> ls-remote problem I mentioned, I haven’t run into any trouble.

OK. I thought it was expectation and did not check documentation. The
assumption that $GIT_DIR stays at worktree's top directory is still
around.. I'll rethink about this.
-- 
Duy

[PATCH] Take it easy on unallowed access to non-existent repository

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 2010/4/9 Jeff King <peff@peff.net>:
 > Yeah, that sounds reasonable, especially if merging this to 'next' would
 > make git unusable. We want to shake out bugs, not punish people running
 > next. :) But I haven't even really looked at the topic in detail yet.

 This patch could be squashed into 551a5786 (Guard unallowed access to repository..)
 Still don't know what to do with "git ls-remote". I'm not familiar with it.

 config.c      |    2 +-
 environment.c |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/config.c b/config.c
index 9981b09..63702bf 100644
--- a/config.c
+++ b/config.c
@@ -738,7 +738,7 @@ int git_config(config_fn_t fn, void *data)
 	int ret;
 
 	if (startup_info && !startup_info->have_run_setup_gitdir)
-		die("internal error: access to .git/config without repo setup");
+		warning("Broken repository setup: early access to $GIT_DIR/config");
 	if (!startup_info || startup_info->have_repository)
 		repo_config = git_pathdup("config");
 	ret = git_config_early(fn, data, repo_config);
diff --git a/environment.c b/environment.c
index 28624ad..dbaed04 100644
--- a/environment.c
+++ b/environment.c
@@ -99,7 +99,7 @@ void unset_git_env(void)
 static void setup_git_env(void)
 {
 	if (startup_info && startup_info->have_run_setup_gitdir)
-		die("internal error: setup_git_env can't be called twice");
+		warning("Broken repository setup: setup_git_env() called twice");
 	git_dir = getenv(GIT_DIR_ENVIRONMENT);
 	if (!git_dir) {
 		/*
@@ -107,7 +107,7 @@ static void setup_git_env(void)
 		 * or enter_repo, not by this function
 		 */
 		if (startup_info)
-			die("internal error: $GIT_DIR is empty");
+			warning("Broken respository setup: git_dir is empty");
 		git_dir = read_gitfile_gently(DEFAULT_GIT_DIR_ENVIRONMENT);
 	}
 	if (!git_dir)
-- 
1.7.0.rc1.541.g2da82.dirty

Re: [PATCH] Take it easy on unallowed access to non-existent repository

[Sverre Rabbelier]

Heya,

2010/4/11 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>        if (startup_info && !startup_info->have_run_setup_gitdir)
> -               die("internal error: access to .git/config without repo setup");
> +               warning("Broken repository setup: early access to $GIT_DIR/config");

This makes it sound like whatever is the problem is caused by the
repository that is being operated on, rather than git's code, is that
correct?

-- 
Cheers,

Sverre Rabbelier

Re: [PATCH] Take it easy on unallowed access to non-existent repository

[Nguyen Thai Ngoc Duy]

2010/4/11 Sverre Rabbelier <srabbelier@gmail.com>:
> Heya,
>
> 2010/4/11 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>>        if (startup_info && !startup_info->have_run_setup_gitdir)
>> -               die("internal error: access to .git/config without repo setup");
>> +               warning("Broken repository setup: early access to $GIT_DIR/config");
>
> This makes it sound like whatever is the problem is caused by the
> repository that is being operated on, rather than git's code, is that
> correct?

Gaah.. from a user point of view, correct. What do you suggest?
-- 
Duy

Re: [PATCH] Take it easy on unallowed access to non-existent repository

[Sverre Rabbelier]

Heya,

On Sun, Apr 11, 2010 at 19:49, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> Gaah.. from a user point of view, correct. What do you suggest?

Simple, add a reference to the "code":

warning("broken repository setup code: early access to $GIT_DIR/config");

-- 
Cheers,

Sverre Rabbelier

Re: nd/setup

[Nguyen Thai Ngoc Duy]

2010/4/8 Jonathan Nieder <jrnieder@gmail.com>:
> Jeff King wrote:
>> On Wed, Apr 07, 2010 at 05:48:02PM -0700, Junio C Hamano wrote:
>
>>> * nd/setup (2010-04-05) 43 commits
> [...]
>> Probably one or both
>> of us should look at it before applying it to next, but assuming it
>> passes a basic sanity check, I think the best thing will be to get it in
>> 'next' early so we can shake out any bugs during the next cycle.
>
> I don’t think it’s anywhere near master material yet.

No it's not. I spent a bit of time on it this morning. A few notes:

- My logic to restore repo state in run_builtin, patch "Guard
unallowed access..", is just broken, and will lead to many die()s (or
warning()s with the squash)
 - "git -p init" will not work, pager problem again.
-- 
Duy

Re: [PATCH] Take it easy on unallowed access to non-existent repository

[Nguyen Thai Ngoc Duy]

On Sun, Apr 11, 2010 at 7:52 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Sun, Apr 11, 2010 at 19:49, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> Gaah.. from a user point of view, correct. What do you suggest?
>
> Simple, add a reference to the "code":
>
> warning("broken repository setup code: early access to $GIT_DIR/config");

Thanks.
-- 
Duy