git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Chris Packham <judge.packham@gmail.com>
Cc: git@vger.kernel.org, Jens.Lehmann@web.de, pclouds@gmail.com,
	gitster@pobox.com
Subject: Re: [RFC/PATCHv2 1/5] worktree: provide better prefix to go back to original cwd
Date: Sat, 16 Oct 2010 13:42:59 -0500	[thread overview]
Message-ID: <20101016184259.GB30457@burratino> (raw)
In-Reply-To: <1287185204-843-2-git-send-email-judge.packham@gmail.com>

Hi,

Chris Packham wrote:

> From: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> 
> When both GIT_DIR and GIT_WORK_TREE are set, if cwd is outside worktree,
> prefix (the one passed to every builtin commands) will be set to NULL,
> which means "user stays at worktree topdir".
> 
> As a consequence, command line arguments are supposed to be relative
> to worktree topdir, not current working directory. Not very intuitive.

Thanks.  More detailed history for this patch:

 - v0: http://thread.gmane.org/gmane.comp.version-control.git/157599/focus=157601
 - v1: http://thread.gmane.org/gmane.comp.version-control.git/158287
 - v2: http://thread.gmane.org/gmane.comp.version-control.git/158369

Any thoughts about the previous questions?

> --- a/cache.h
> +++ b/cache.h
> @@ -1117,6 +1117,8 @@ const char *split_cmdline_strerror(int cmdline_errno);
>  /* git.c */
>  struct startup_info {
>  	int have_repository;
> +	char *cwd_to_worktree; /* chdir("this"); from cwd would return to worktree */
> +	char *worktree_to_cwd; /* chdir("this"); from worktree would return to cwd */

e.g. I still find these comments hard to understand.

> --- a/setup.c
> +++ b/setup.c
> @@ -313,10 +313,109 @@ const char *read_gitfile_gently(const char *path)
>  	return path;
>  }
>  
> +/*
> + * Given "foo/bar" and "hey/hello/world", return "../../hey/hello/world/"
> + * Either path1 or path2 can be NULL
> + */
> +static char *make_path_to_path(const char *path1, const char *path2)
> +{
> +	int nr_back = 0;
> +	int i, pathlen = path2 ? strlen(path2) : 0;
> +	char *buf, *p;
> +
> +	if (path1 && *path1) {
> +		nr_back = 1;
> +		while (*path1) {
> +			if (*path1 == '/')
> +				nr_back++;

This still assumes Unix-style path separators.  Is that okay?  (The
answer could be yes; it just seems useful to document the assumptions...)

> +/*
> + * Return a prefix if cwd inside worktree, or NULL otherwise.
> + * Also fill startup_info struct.
> + */
> +static const char *setup_prefix(const char *cwd)
> +{
> +	const char *worktree = get_git_work_tree();
> +	int len = 0, cwd_len = strlen(cwd), worktree_len = strlen(worktree);
> +
> +	while (worktree[len] && worktree[len] == cwd[len])
> +		len++;
> +
> +	if (!worktree[len] && !cwd[len]) {
> +		if (startup_info) {
> +			startup_info->cwd_to_worktree = NULL;
> +			startup_info->worktree_to_cwd = NULL;
> +		}
> +		return NULL;
> +	}
> +	/* get /foo/, not /foo/baa if /foo/baa1 and /foo/baa2 are given */
> +	else if (worktree[len] && cwd[len]) {

Style: use cuddled braces.

	} else if (worktree[len] && cwd[len]) {
		/*
		 * The result should be /foo/, not /foo/baa, when
		 * worktree is /foo/baa1 and cwd is /foo/baa2.
		 */

> +		while (len && worktree[len] != '/')
> +			len--;
> +		len++;
> +	}
> +	else {

Likewise.

> +		if (worktree[len]) {
> +			if (worktree[len] != '/') {
> +				while (len && worktree[len] != '/')
> +					len--;
> +			}
> +		}
> +		else {

Likewise.

> +			if (cwd[len] != '/') {
> +				while (len && cwd[len] != '/')
> +					len--;
> +			}

This is repetitive.  Why is the if necessary?

[...]
>  static const char *setup_explicit_git_dir(const char *gitdirenv,
>  				const char *work_tree_env, int *nongit_ok)
>  {
> -	static char buffer[1024 + 1];
> +	static char buffer[PATH_MAX];

Unexplained.

[...]
> --- /dev/null
> +++ b/t/t1510-worktree-prefix.sh
> @@ -0,0 +1,52 @@
[...]
> +test_expect_success 'at root' '
> +	(
> +	cd foo &&
> +	git rev-parse --cwd-to-worktree --worktree-to-cwd >result &&
> +	: >expected &&
> +	test_cmp expected result
> +	)
> +'

It is clearer where a subshell begins and ends if it is indented.  The
usual style in git shell scripts is to omit the ":" in

	>empty

commands.  So maybe:

	(
		cd foo &&
		git rev-parse --cwd-to-worktree --worktree-to-cwd >result
	) &&
	>expected &&
	test_cmp expected foo/result

Sorry, a bit grumpy today.  Still, hope that helps,
Jonathan

  reply	other threads:[~2010-10-16 18:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-15 23:26 [RGC/PATCHv2] grep: submodule support Chris Packham
2010-10-15 23:26 ` [RFC/PATCHv2 1/5] worktree: provide better prefix to go back to original cwd Chris Packham
2010-10-16 18:42   ` Jonathan Nieder [this message]
2010-10-17  2:48     ` Chris Packham
2010-10-17 10:01       ` Nguyen Thai Ngoc Duy
2010-10-18  2:05         ` Chris Packham
2010-10-15 23:26 ` [RFC/PATCHv2 2/5] grep: output the path from cwd to worktree Chris Packham
2010-10-15 23:26 ` [RFC/PATCHv2 3/5] grep_cache: check pathspec first Chris Packham
2010-10-15 23:26 ` [RFC/PATCHv2 4/5] add test for git grep --recursive Chris Packham
2010-10-15 23:26 ` [RFC/PATCHv2 5/5] grep: add support for grepping in submodules Chris Packham
2010-10-17 10:28   ` Nguyen Thai Ngoc Duy
2010-10-18  2:01     ` Chris Packham
2010-10-18  3:37       ` Nguyen Thai Ngoc Duy
2010-10-16 15:54 ` [RGC/PATCHv2] grep: submodule support Jens Lehmann
2010-10-17  2:13   ` Chris Packham

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=20101016184259.GB30457@burratino \
    --to=jrnieder@gmail.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=judge.packham@gmail.com \
    --cc=pclouds@gmail.com \
    /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).