git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: gitster@pobox.com, git@vger.kernel.org, matled@gmx.net
Subject: Re: [PATCH 0/9] work-tree clean ups
Date: Wed, 1 Aug 2007 01:28:30 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0708010058130.14781@racer.site> (raw)
In-Reply-To: <Pine.LNX.4.64.0707300016470.14781@racer.site>

Hi,

so this is yet another revision of the work-tree clean ups (sorry to all 
those who grow tired of it; I feel with you: I am tired of it, too).

Junio rightfully pointed out that the tests do not succeed after each 
single step of the series.

Alas, after thinking about it for quite some time, I do not think there is 
any way around squashing all the earlier steps 4,6--9 into one step.

There is not really much that can be done about step 6/9: if we are in a 
work tree: that does not mean that we are _not_ in the git_dir.  (And no, 
this does not break git-clean, as a work tree is a work tree is a work 
tree.  If the user was stupid enough to specify the same directory as 
GIT_DIR and GIT_WORK_TREE, then that is _her_ problem.  Git is a powerful 
tool, and you can harm yourself with it.  Tough.)

Patch 7/9 is needed, because the old logic in git-init was wrong, and only 
hidden by the fact that the work-tree logic was implemented wrongly to 
begin with.

Patches 8 and 9/9 only updated the tests to ensure a sane logic, instead 
of an unsane one.  So they are needed, too.

Note: if you are in a bare repository (a repository which either says 
"core.bare = false" in the config, or which is a direct ancestor 
directory, i.e. ../[...]/.. of the current working directory) there will 
_not_ be an automatic working directory assignment.  You will be operating 
_without_ any work tree, unless you specify one.

I somehow feel that core.bare = true weighs more than core.worktree = 
/some/thing, and therefore I implemented it that way, but hey, if enough 
people disagree, then I'll change it.

Maybe I should add two comments?

Namely that setup_git_directory_gently() does _not_ check the config if 
the repository version is right, and where the working directory is, and 
if the repository is bare.  setup_git_directory() does...

And that setup_git_directory_gently() _does_ try to be smart about 
get_git_work_tree(), is_inside_git_dir() and is_inside_work_tree() by 
assigning their return values, and only if core.bare or core.worktree (or 
--work-tree=<something> or GIT_WORK_TREE) are set, get_git_work_tree() and 
is_inside_work_tree() are reset to recalculate what is happening...  
(actually, that is not completely true: if we _know_ that GIT_WORK_TREE is 
set, or --work-tree=<something> which is almost the same, we will defer 
the calculation until one of the functions get_git_work_tree() and 
is_inside_work_tree() is called.)

IMHO we should (probably after 1.5.3) change setup_git_directory_gently() 
to call check_repository_format() in every return path, so that we 
ascertain that the current repository is recent enough.  Because that 
function now checks also if the repo is bare, and if it has a worktree 
set, in addition to ensuring a valid repository.

In hindsight, I should have separated the "check .git/, then ./, and if no 
git_dir was found, continue with the parent directory" into a separate 
patch, but frankly, I am sick and tired of the work-tree series.  It was 
not done right in the first place, and it used hard-to-understand code to 
hide the fact.

Ciao,
Dscho

P.S.: After reading my patch to the tests, I have to disagree strongly 
with my notion that _not_ cleaning up the tests to use some sane syntax 
would make them clearer.  Nevertheless, I think I'll let them stand as an 
example how _not_ to write tests.

  parent reply	other threads:[~2007-08-01  0:28 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-29 23:23 [PATCH 0/9] work-tree clean ups Johannes Schindelin
2007-07-29 23:24 ` [PATCH 1/9] Add is_absolute_path() and make_absolute_path() Johannes Schindelin
2007-07-29 23:24 ` [PATCH 2/9] Add functions get_relative_cwd() and is_inside_dir() Johannes Schindelin
2007-07-29 23:24 ` [PATCH 3/9] white space fixes in setup.c Johannes Schindelin
2007-07-29 23:25 ` [PATCH 4/9] Clean up work-tree handling Johannes Schindelin
2007-07-29 23:25 ` [PATCH 5/9] Add set_git_dir() function Johannes Schindelin
2007-07-29 23:25 ` [PATCH 6/9] work-trees are allowed inside a git-dir Johannes Schindelin
2007-07-29 23:25 ` [PATCH 7/9] init: use get_git_work_tree() instead of rolling our own Johannes Schindelin
2007-07-29 23:26 ` [PATCH 8/9] Fix t1501 for updated work-tree logic Johannes Schindelin
2007-07-29 23:26 ` [PATCH 9/9] Fix t1500 for sane work-tree behavior Johannes Schindelin
2007-07-29 23:29 ` [UNWANTED PATCH] Die if core.bare = true and core.worktree is set Johannes Schindelin
2007-08-01  0:28 ` Johannes Schindelin [this message]
2007-08-01  0:28   ` [PATCH 1/4] Add is_absolute_path() and make_absolute_path() Johannes Schindelin
2007-08-01  0:29   ` [PATCH 2/4] Add functions get_relative_cwd() and is_inside_dir() Johannes Schindelin
2007-08-01  4:22     ` Junio C Hamano
2007-08-01  5:35       ` Junio C Hamano
2007-08-01 11:38         ` Johannes Schindelin
2007-08-01 15:26         ` [NOT-SERIOUS PATCH] Make get_relative_cwd() not accept NULL for a directory Johannes Schindelin
2007-08-01 16:58           ` Junio C Hamano
2007-08-01 18:26             ` [PATCH] get_relative_cwd(): clarify why it handles dir == NULL Johannes Schindelin
2007-08-01  0:29   ` [PATCH 3/4] Add set_git_dir() function Johannes Schindelin
2007-08-01  0:30   ` [PATCH 4/4] Clean up work-tree handling Johannes Schindelin
2007-08-01  5:17     ` Junio C Hamano
2007-08-01 11:46       ` Johannes Schindelin
2007-08-02  7:04         ` Junio C Hamano
2007-08-01  8:59     ` Junio C Hamano
2007-08-01 11:53       ` Johannes Schindelin
2007-08-01  0:55   ` [PATCH 0/9] work-tree clean ups Junio C Hamano
2007-08-01  1:13     ` Johannes Schindelin
2007-08-01 10:56       ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0708010058130.14781@racer.site \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=matled@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).