git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Torsten Bögershausen" <tboegi@web.de>
To: Christian Couder <christian.couder@gmail.com>, git@vger.kernel.org
Cc: "Junio C Hamano" <gitster@pobox.com>, "Jeff King" <peff@peff.net>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Nguyen Thai Ngoc Duy" <pclouds@gmail.com>,
	"David Turner" <dturner@twopensource.com>,
	"Eric Sunshine" <sunshine@sunshineco.com>,
	"Torsten Bögershausen" <tboegi@web.de>,
	"Christian Couder" <chriscool@tuxfamily.org>
Subject: Re: [PATCH v4 08/10] dir: simplify untracked cache "ident" field
Date: Wed, 30 Dec 2015 12:47:47 +0100	[thread overview]
Message-ID: <5683C463.9010003@web.de> (raw)
In-Reply-To: <1451372974-16266-9-git-send-email-chriscool@tuxfamily.org>

On 2015-12-29 08.09, Christian Couder wrote:
> It is not a good idea to compare kernel versions and disable
> the untracked cache if it changes as people may upgrade and
> still want the untracked cache to work. So let's just
> compare work tree locations to decide if we should disable
> it.
OK with that.
> 
> Also it's not useful to store many locations in the ident
> field and compare to any of them. It can even be dangerous
> if GIT_WORK_TREE is used with different values. So let's
> just store one location, the location of the current work
> tree.
I don't think I fully agree in all details.
The list is there to distinguish between different clients when sharing
a Git workspace over a network to different clients:

A file system is exported from Linux to Linux via NFS,
including a Git workspace)
The same Workspace is exported via SAMBA to Windows and, in an extreme case,
AFS to Mac OS.

Other combinations could be
Linux - SAMBA - Linux
Linux - AFP - Linux

Mac OS - NFS - Linux
Mac OS - AFP - Mac OS
Mac OS - SMB - Linux, Mac OS, Windows
The list is incomplete (BSD and other Unix is missing),
there are other combinations of network protocols,
there are NAS boxes which mostly Linux under the hood, but
may have vendor specific tweaks.

Now we want to know, which of the combinations work.
The different clients need to test separately.
E.g. for a given server:

NFS - Linux
SMB - Linux
SMB Windows.

At this point I would agree that the old code from dir.c:

static const char *get_ident_string(void)
{
	static struct strbuf sb = STRBUF_INIT;
	struct utsname uts;

	if (sb.len)
		return sb.buf;
	if (uname(&uts) < 0)
		die_errno(_("failed to get kernel name and information"));
	strbuf_addf(&sb, "Location %s, system %s %s %s", get_git_work_tree(),
		    uts.sysname, uts.release, uts.version);
	return sb.buf;
}
------------------
is unneccessary picky, and the sysname should be enough:

strbuf_addf(&sb, "Location %s, system %s", get_git_work_tree(),
uts.sysname);


The old code did not find out, which network protocol that we used,
(you need to call "mount", and grep for the directory, and try to get
the FS information, which may be ext4, btrfs, smbfs, nfs....)
This is unnecessary complicated, so we endet up in using the path.

If I was a system administrator, (I sometimes am), I would set up a
bunch of Linux boxes in a similar way, so that the repo is under
/nfs/server1/projects/myproject
(and the same path is used for all Linux boxes)

The Windows machines may use something like
N:/projects/myproject
or
//server1/projects/myproject

and Mac OS may use
/Volumes/projects/myproject
(If mounted from the finder)
or
/nfs/projects/myproject
(When autofs is used)


I may have missed the discussion somewhat, could you explain why having
different uname/location combinations are not usable at your site ?

How much burden is actually put on your system, and is there a way to keep a
list of different clients ?


What I understand is that a kernel update of a Linux machine shouldn't matter,
but if a machine runs Windows or Linux should matter.

  parent reply	other threads:[~2015-12-30 11:48 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-29  7:09 [PATCH v4 00/10] Untracked cache improvements Christian Couder
2015-12-29  7:09 ` [PATCH v4 01/10] dir: free untracked cache when removing it Christian Couder
2015-12-29 22:26   ` Junio C Hamano
2015-12-29  7:09 ` [PATCH v4 02/10] update-index: use enum for untracked cache options Christian Couder
2015-12-29  7:09 ` [PATCH v4 03/10] update-index: add --test-untracked-cache Christian Couder
2015-12-29 22:28   ` Junio C Hamano
2015-12-29  7:09 ` [PATCH v4 04/10] update-index: add untracked cache notifications Christian Couder
2015-12-29  7:09 ` [PATCH v4 05/10] update-index: move 'uc' var declaration Christian Couder
2015-12-29  7:09 ` [PATCH v4 06/10] dir: add {new,add}_untracked_cache() Christian Couder
2015-12-29  7:09 ` [PATCH v4 07/10] dir: add remove_untracked_cache() Christian Couder
2015-12-29  7:09 ` [PATCH v4 08/10] dir: simplify untracked cache "ident" field Christian Couder
2015-12-29 22:32   ` Junio C Hamano
2015-12-30 22:01     ` Christian Couder
2015-12-30 11:47   ` Torsten Bögershausen [this message]
2015-12-30 17:20     ` Christian Couder
2015-12-29  7:09 ` [PATCH v4 09/10] config: add core.untrackedCache Christian Couder
2015-12-29 22:35   ` Junio C Hamano
2015-12-30 22:47     ` Christian Couder
2015-12-30 23:23       ` Junio C Hamano
2015-12-31 12:33         ` Christian Couder
2016-01-04 18:09           ` Junio C Hamano
2016-01-08 17:52             ` Christian Couder
2016-01-08 19:43               ` Junio C Hamano
2015-12-29  7:09 ` [PATCH v4 10/10] t7063: add tests for core.untrackedCache Christian Couder

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=5683C463.9010003@web.de \
    --to=tboegi@web.de \
    --cc=avarab@gmail.com \
    --cc=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=dturner@twopensource.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=sunshine@sunshineco.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).