* Re: [PATCH/RFC 1/4] Optimised, faster, more effective symlink/directory detection
From: Junio C Hamano @ 2009-01-06 8:56 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Linus Torvalds
In-Reply-To: <7vprj0j181.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Let me see if I understand the logic behind this caching....
> ...
>> + last_slash = match_len;
>> + cache_path[last_slash] = '\0';
>> +
>> + if (lstat(cache_path, &st)) {
>> + ret_flags = LSTAT_LSTATERR;
>> + if (errno == ENOENT || errno == ENOTDIR)
>> + ret_flags |= LSTAT_NOTDIR;
>
> If you tested "A/B" here and got ENOENT back, you know "A/B" does not
> exist; you cache this knowledge as "A/B is not a directory" (I also think
> you could use it as a cached knowledge that "A exists and is a directory".
> I am not sure if you are taking advantage of that).
>
> What I do not understand about this code is the ENOTDIR case. If you
> tested "A/B" and got ENOTDIR back, what you know is that "A" is not a
> directory (if the path tested this round were deeper like "X/Y/A/B", you
> know "X/Y/A" is not a directory, and you know "X" and "X/Y" are true
> directories; otherwise the loop would have exited before this round when
> you tested "X" or "X/Y" in the earlier rounds).
>
> So as far as I can think of, ENOENT case and ENOTDIR case would give you
> different information (ENOENT would say "A is a dir, A/B is not"; ENOTDIR
> would say "A is not a dir"). I am confused how you can cache the same
> path and same flag between these two cases here.
I take 1/4 of the above back.
If everything is working correctly, I do not think you will ever have a
situation where you check "A/B" here and get ENOTDIR back. lstat("A/B")
would yield ENOTDIR if "A" is not a directory, but:
(1) If you did test "A" in the earlier round in the loop, you would have
already found it is not a directory and would have exited the loop
with LSTAT_ERR. You cannot test "A/B" in such a case;
(2) If you did not test "A" in the loop, that has to be because you had a
cached information for it, and the caching logic would have returned
early if "A" was a non-directory without entering the loop; in other
words, you would test "A/B" here without testing "A" in the loop only
when the cache says "A" was a directory. You cannot get ENOTDIR in
such a case.
In any case, my main puzzlement still stands. I think ENOTDIR case should
behave differently from ENOENT case.
And I think it is an indication of a grave error, either this code is
racing with an external process that is actively mucking with the work
tree to make your cached information unusable, or somebody forgot to call
clear_lstat_cache().
Hmm?
^ permalink raw reply
* Re: [ANNOUNCE] Git homepage change
From: Miklos Vajna @ 2009-01-06 8:54 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Scott Chacon, David Bryson, Mike Hommey, git
In-Reply-To: <alpine.LNX.2.00.0901052119210.9096@suse104.zenez.com>
[-- Attachment #1: Type: text/plain, Size: 591 bytes --]
On Mon, Jan 05, 2009 at 09:24:16PM -0700, Boyd Lynn Gerber <gerberb@zenez.com> wrote:
> http://dir.gmane.org/gmane.comp.version-control.git
>
> On this page the following...
>
> Other mailing list archives for this list:
>
> 1. The Mail Archive
>
> http://www.mail-archive.com/git@vger.kernel.org/
>
> And this states this link
>
> http://www.mail-archive.com/git@vger.kernel.org/
>
> And the lastest is 2005 and earlier.
I don't think you should blame Scott for this, it seem to be a gmane vs
mail-archive issue, and gmane is mentioned already in MaintNotes.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git rebase --interactive needn't call editor for noop
From: Thomas Rast @ 2009-01-06 8:47 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87bpulnmw2.fsf@jidanni.org>
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]
jidanni@jidanni.org wrote:
> On occasions when git rebase --interactive will invoke the editor with
> the word "noop" in the buffer, it would be better if it just said that
> on the command line instead of bothering to call the editor.
The editor gives you a chance to wipe the entire todo file, aborting
the rebase.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation/merge-strategies.txt, diff-options: grammar
From: Thomas Rast @ 2009-01-06 8:44 UTC (permalink / raw)
To: jidanni; +Cc: git, gitster
In-Reply-To: <1231213956-14929-1-git-send-email-jidanni@jidanni.org>
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
jidanni@jidanni.org wrote:
> @@ -11,7 +11,7 @@ resolve::
> recursive::
> This can only resolve two heads using 3-way merge
> algorithm. When there are more than one common
> - ancestors that can be used for 3-way merge, it creates a
> + ancestor that can be used for 3-way merge, it creates a
> merged tree of the common ancestors and uses that as
> the reference tree for the 3-way merge. This has been
> reported to result in fewer merge conflicts without
I'm not a native speaker, but shouldn't this be worded
When there _is_ more than one common _ancestor_ that ...
instead?
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC 2/4] Use 'lstat_cache()' instead of 'has_symlink_leading_path()'
From: Junio C Hamano @ 2009-01-06 8:19 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Linus Torvalds
In-Reply-To: <1231161001-32599-3-git-send-email-barvik@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> Start using the optimised, faster and more effective symlink/directory
> cache. The previously used call:
>
> has_symlink_leading_path(len, name);
>
> should be identically with the following call to lstat_cache():
>
> lstat_cache(len, name,
> LSTAT_SYMLINK|LSTAT_DIR,
> LSTAT_SYMLINK);
> ...
Care to enlighten why some of callers use the above, but not others?
Namely, check_removed() in diff-lib.c and callers in unpack-trees.c care
about NOTDIR unlike others, even though the original code checked for
exactly the same condition.
Does this mean that some callers of has_symlink_leading_path() checked
only for leading symlinks when they should also have checked for a leading
non-directory, and this patch is also a bugfix?
^ permalink raw reply
* Re: [PATCH/RFC 1/4] Optimised, faster, more effective symlink/directory detection
From: Junio C Hamano @ 2009-01-06 8:19 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Linus Torvalds
In-Reply-To: <1231161001-32599-2-git-send-email-barvik@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> +static inline void
> +update_path_cache(unsigned int ret_flags, unsigned int track_flags,
> + int last_slash)
> +{
> + /* Max 3 different path types can be cached for the moment! */
> + unsigned int save_flags =
> + ret_flags & track_flags & (LSTAT_DIR|
> + LSTAT_NOTDIR|
> + LSTAT_SYMLINK);
> + if (save_flags && last_slash > 0 && last_slash < PATH_MAX) {
> + cache_flags = save_flags;
> + cache_len = last_slash;
> + } else {
> + cache_flags = 0;
> + cache_len = 0;
> + }
> +}
I personally found this inline function with a single call site
distracting in following the logic. It does not make the indentation
level shallower, either. Also, the else part should probably call
clear_lstat_cache() to protect it from possible future enhancements to add
more state variables.
> +
> +/*
> + * Check if name 'name' of length 'len' has a symlink leading
> + * component, or if the directory exists and is real, or not.
> + *
> + * To speed up the check, some information is allowed to be cached.
> + * This is indicated by the 'track_flags' argument.
> + */
> +unsigned int
> +check_lstat_cache(int len, const char *name, unsigned int track_flags)
> +{
> + int match_len, last_slash, max_len;
> + unsigned int match_flags, ret_flags;
> + struct stat st;
> +
> + /* Check if match from the cache for 2 "excluding" path types.
> + */
> + match_len = last_slash =
> + greatest_common_path_cache_prefix(len, name);
> + match_flags =
> + cache_flags & track_flags & (LSTAT_NOTDIR|
> + LSTAT_SYMLINK);
> + if (match_flags && match_len == cache_len)
> + return match_flags;
Let me see if I understand the logic behind this caching. When you have
checked A/B/C earlier and you already know B is a symlink, you remember
that A/B was a symlink.. You can fill a request to check A/B/$whatever
(assuming A/B does not change --- otherwise the caller should clear the
cache) from the cached data, because no matter what $whatever is, it will
result in the same "has-leading-symlink".
Similarly, if you know A/B is not a directory from an earlier test, you
know that a request to check A/B/$whatever will result in the same ENOTDIR
no matter what $whatever is, so you can return early.
The above "return match_flags" will not trigger if the cached path does
not have any leading symlink. So we know the matched part are all good
directories when we start lstat() loop.
Am I following you so far?
> + /* Okay, no match from the cache so far, so now we have to
> + * check the rest of the path components and update the cache.
> + */
> + ret_flags = LSTAT_DIR;
> + max_len = len < PATH_MAX ? len : PATH_MAX;
> + while (match_len < max_len) {
> + do {
> + cache_path[match_len] = name[match_len];
> + match_len++;
> + } while (match_len < max_len && name[match_len] != '/');
You take one component from the input, and append it to the part that is
already known to be true directory (i.e. cached part and the part earlier
iteration of the loop checked so far), to be tested by lstat()...
> + if (match_len >= max_len)
> + break;
... but you are not interested in the full input. We are only checking
the leading path (e.g. check for "A/B/C" may lstat() "A", "A/B" but not
"A/B/C").
> + last_slash = match_len;
> + cache_path[last_slash] = '\0';
> +
> + if (lstat(cache_path, &st)) {
> + ret_flags = LSTAT_LSTATERR;
> + if (errno == ENOENT || errno == ENOTDIR)
> + ret_flags |= LSTAT_NOTDIR;
If you tested "A/B" here and got ENOENT back, you know "A/B" does not
exist; you cache this knowledge as "A/B is not a directory" (I also think
you could use it as a cached knowledge that "A exists and is a directory".
I am not sure if you are taking advantage of that).
What I do not understand about this code is the ENOTDIR case. If you
tested "A/B" and got ENOTDIR back, what you know is that "A" is not a
directory (if the path tested this round were deeper like "X/Y/A/B", you
know "X/Y/A" is not a directory, and you know "X" and "X/Y" are true
directories; otherwise the loop would have exited before this round when
you tested "X" or "X/Y" in the earlier rounds).
So as far as I can think of, ENOENT case and ENOTDIR case would give you
different information (ENOENT would say "A is a dir, A/B is not"; ENOTDIR
would say "A is not a dir"). I am confused how you can cache the same
path and same flag between these two cases here.
> + } else if (S_ISDIR(st.st_mode)) {
> + continue;
> + } else if (S_ISLNK(st.st_mode)) {
> + ret_flags = LSTAT_SYMLINK;
> + } else {
> + ret_flags = LSTAT_ERR;
> + }
> + break;
> + }
> + update_path_cache(ret_flags, track_flags, last_slash);
> + return ret_flags;
> +}
> +
> +/*
> + * Before usage of the check_lstat_cache() function one should call
> + * clear_lstat_cache() (at an appropriate place) to make sure that the
> + * cache is clean before first call to check_lstat_cache().
> + */
> +void clear_lstat_cache(void)
> +{
> + cache_flags = 0;
> + cache_len = 0;
> +}
> --
> 1.6.1.rc1.49.g7f705
^ permalink raw reply
* Re: [PATCH v3.2] rebase: learn to rebase root commit
From: Junio C Hamano @ 2009-01-06 8:19 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <1231176916-14929-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Since this is still in 'pu', can you replace it again?
Thanks, done.
^ permalink raw reply
* Re: configure clobbers LDFLAGS
From: Junio C Hamano @ 2009-01-06 8:19 UTC (permalink / raw)
To: Jeff King; +Cc: prj, git
In-Reply-To: <20090105060058.GB13189@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Jan 04, 2009 at 09:27:41PM -0500, Paul Jarc wrote:
>
>> In a couple of tests, configure clobbers the LDFLAGS value set by the
>> caller. This patch fixes it.
>
> Thanks for the patch. It looks obviously correct to me, and the problem
> was just some typos introduced by 798a9450.
>
> Junio, I think this should go onto maint.
Thanks; will queue.
^ permalink raw reply
* Re: [PATCH v2 resend] git.c: make autocorrected aliases work
From: Junio C Hamano @ 2009-01-06 8:19 UTC (permalink / raw)
To: Alexander Potashev; +Cc: Adeodato Simó, git
In-Reply-To: <20090104172833.GA7139@myhost>
Alexander Potashev <aspotashev@gmail.com> writes:
>> @@ -479,31 +501,22 @@ int main(int argc, const char **argv)
>> ...
>> + was_alias = run_argv(&argc, &argv);
>> + if (errno != ENOENT)
>> break;
>> + if (was_alias) {
>> fprintf(stderr, "Expansion of alias '%s' failed; "
>> "'%s' is not a git-command\n",
>> cmd, argv[0]);
>> exit(1);
>
> Why not using 'die' here?
The code is in the context, and I do not think it is a good idea to
conflate such a change to a patch that wants to add aliases auto
correction.
While I do not think it matters too much in practice (unless existing
scripts that runs git depends on the exact error status value), there are
two differences: the message will say "fatal: " in front, and the command
exits with 128 not with 1.
^ permalink raw reply
* Re: [PATCH 3/3] unpack-trees: remove redundant path search in verify_absent
From: Junio C Hamano @ 2009-01-06 8:19 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <1230843273-11056-4-git-send-email-drizzd@aon.at>
Clemens Buchacher <drizzd@aon.at> writes:
> Since the only caller, verify_absent, relies on the fact that o->pos
> points to the next index entry anyways, there is no need to recompute
> its position.
I suspect that the original reasoning of this behaviour might have been in
anticipation of other callers, but I agree with your reasoning especially
because I do not think of a good reason to want to receive the number of
entries to skip as the return value and not have o->pos pointing at the
right place.
Thanks, queued.
^ permalink raw reply
* Re: [PATCH v2 resend] git.c: make autocorrected aliases work
From: Junio C Hamano @ 2009-01-06 8:19 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git
In-Reply-To: <1231089361-12619-1-git-send-email-dato@net.com.org.es>
Thanks, queued.
^ permalink raw reply
* Re: git-rev-parse --symbolic-abbrev-name
From: Junio C Hamano @ 2009-01-06 8:18 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Karl Chen, Miklos Vajna, David Aguilar, Git mailing list
In-Reply-To: <1a69a9d80901041223r1f3d2956ne05996793bb23e97@mail.gmail.com>
"Arnaud Lacombe" <lacombar@gmail.com> writes:
> You'll find hereafter two patches which implements this in
> git-symbolic-ref and git-rev-parse. Feel free to choose the one you
> find the best. If you choose to integrate one of these, tells me and
> I'll do a proper documentation bits and patch submission.
> diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
> index 81d5a6f..70f4a33 100644
> --- a/builtin-rev-parse.c
> +++ b/builtin-rev-parse.c
> @@ -24,6 +24,7 @@ static int show_type = NORMAL;
>
> #define SHOW_SYMBOLIC_ASIS 1
> #define SHOW_SYMBOLIC_FULL 2
> +#define SHOW_SYMBOLIC_SHORT 3
> static int symbolic;
> static int abbrev;
> static int output_sq;
I think --symbolic-short makes the most sense.
> @@ -125,13 +129,20 @@ static void show_rev(int type, const unsigned char *sha1, const char *name)
> */
> break;
> case 1: /* happy */
> + if (symbolic == SHOW_SYMBOLIC_SHORT) {
> + char *p;
> + p = strrchr(full, (int)'/');
> + if (p != NULL)
> + full = p + 1;
> + }
However, this is not a good way to do it, I suspect. This patch most
likely will be queued to the al/symbolic-short topic branch, but you are
losing information here. You'd probably want to try substings from the
tail of the full name (e.g. symbolic-short, al/symbolic-short,
heads/al/symbolic-short, and finally refs/heads/al/symbolic-short) and
feed them to dwim_ref() and pick the shortest one that yields the same ref
unambiguously, or something like that.
By the way, I do not see why you need to cast '/'.
^ permalink raw reply
* Re: [PATCH 2/2] Be consistent in switch usage for tar
From: Junio C Hamano @ 2009-01-06 8:18 UTC (permalink / raw)
To: henrik; +Cc: git
In-Reply-To: <1231169137-32653-3-git-send-email-henrik@austad.us>
Thanks; both patches applied.
^ permalink raw reply
* Re: [PATCH v2 tested-v2] git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS X
From: Junio C Hamano @ 2009-01-06 8:18 UTC (permalink / raw)
To: Marcel M. Cary; +Cc: git, jnareb, ae, j.sixt, git-dev
In-Reply-To: <1231105649-12998-1-git-send-email-marcel@oak.homeunix.org>
Thanks; queued.
^ permalink raw reply
* Re: [PATCH] Fix sourcing "test-lib.sh" using dash shell in "t3003-ls-files-narrow-match.sh"
From: Junio C Hamano @ 2009-01-06 8:18 UTC (permalink / raw)
To: Christian Couder; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20090105143002.8a369535.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> dash barfs, on my old Ubuntu box, when "test-lib.sh" is sourced
> without "./".
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> t/t3003-ls-files-narrow-match.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> This patch applies to "pu".
Thanks; I hope you don't mind squashing this in to 'Introduce "sparse
patterns"'.
^ permalink raw reply
* Re: [PATCH] cvsserver: change generation of CVS author names
From: Junio C Hamano @ 2009-01-06 8:18 UTC (permalink / raw)
To: Lars Noschinski; +Cc: Fabian Emmes, git, Frank Lichtenheld, Martin Langhoff
In-Reply-To: <20090104111245.GA7732@lars.home.noschinski.de>
Lars Noschinski <lars@public.noschinski.de> writes:
> Obviously the reported user names change. To the best of my knowledge
> (but I'm just a barely experienced CVS user) those names are not stored
> anywhere on the client and are regenerated by git-cvsserver for every
> request, so even old repositories get the new names for all commits.
Thanks for a clarification. I'll amend the commit log message and queue
the result for 'next'.
commit d500a1ee8fe4424beb7a98e4fa6159677e7569d0
Author: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Date: Fri Jan 2 16:40:14 2009 +0100
cvsserver: change generation of CVS author names
CVS username is generated from local part email address.
We take the whole local part but restrict the character set to the
Portable Filename Character Set, which is used for Unix login names
according to Single Unix Specification v3.
This will obviously report different usernames from existing repositories
for commits with the local part of the author e-mail address that contains
characters outside the PFCS. Hopefully this won't break an old CVS
checkout from an earlier version of git-cvsserver, because the names are
always shown afresh to the CVS clients and not kept on the client side.
Signed-off-by: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: [PATCH] gitweb: suggest name for OPML view
From: Junio C Hamano @ 2009-01-06 8:18 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <1230900570-25324-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> Suggest opml.xml as name for OPML view by providing the appropriate
> header, consistently with similar usage in project_index view.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
I think this makes sense; will apply unless there is any objection.
^ permalink raw reply
* Re: [PATCH] bash: add '--merge' to 'git reset'
From: Junio C Hamano @ 2009-01-06 8:18 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Shawn O. Pearce, git
In-Reply-To: <1230563146-18958-1-git-send-email-szeder@ira.uka.de>
Thanks; applied.
^ permalink raw reply
* Re: [CLEANUP PATCH] show <tag>: reuse pp_user_info() instead of duplicating code
From: Junio C Hamano @ 2009-01-06 8:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901021717350.27818@racer>
Thanks.
^ permalink raw reply
* Re: [RESEND PATCH] git add: do not add files from a submodule
From: Junio C Hamano @ 2009-01-06 8:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901021715370.27818@racer>
Makes sense, thanks; queued for maint.
^ permalink raw reply
* Re: [PATCH] bundle: allow rev-list options to exclude annotated tags
From: Junio C Hamano @ 2009-01-06 8:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901021725530.27818@racer>
Thanks; queued for maint (and possibly maint-1.6.0).
^ permalink raw reply
* Re: [PATCH] gitweb: use href() when generating URLs in OPML
From: Junio C Hamano @ 2009-01-06 8:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Giuseppe Bilotta, git, Petr Baudis
In-Reply-To: <200901021409.07695.jnareb@gmail.com>
Thanks, both; applied.
^ permalink raw reply
* Re: Error: unable to unlink ... when using "git gc"
From: Johnny Lee @ 2009-01-06 8:09 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090106080300.GA10079@coredump.intra.peff.net>
Ooops, forgot to cc to the mailing list.
Thanks for your sharing Peff, I'm going to check these stuffs out and
get back with any findings.
Regards,
Johnny
On Tue, Jan 6, 2009 at 4:03 PM, Jeff King <peff@peff.net> wrote:
> [re-adding git@vger; please keep discussion on-list so everyone can
> benefit from the result]
>
> On Tue, Jan 06, 2009 at 03:52:12PM +0800, Johnny Lee wrote:
>
>> Thanks Peff, I've checked the permission of .git/objects/16, it's
>> created by another user and thus I have no permission to remove it.
>>
>> In fact, this is coming from a previous bad practice on setting up a
>> collaboration repository on a SSH server, here is what I've done so
>> far:
>> [...]
>> 7. Then the user "git" has changed mode for all the files under .git
>> to writable.
>>
>> 8. This time, user "johnny" can push successfully.
>
> If you are going to have multiple users sharing a repository, generally
> they should be in the same group and the core.sharedrepository config
> option should be set (see "git help config", or the "shared" option to
> git-init).
>
> I've never used that personally, though. I have always just used POSIX
> ACLs, with a default ACL on each directory giving access to everyone.
> E.g. (off the top of my head):
>
> for user in user1 user2 user3; do
> setfacl -R -m u:$user:rwX -m d:u:$user:rwX /path/to/repo
> done
>
> -Peff
>
--
we all have our crosses to bear
^ permalink raw reply
* Re: Error: unable to unlink ... when using "git gc"
From: Jeff King @ 2009-01-06 8:03 UTC (permalink / raw)
To: Johnny Lee; +Cc: git
In-Reply-To: <488807870901052352w585da727r6d4a1e4ca4238cab@mail.gmail.com>
[re-adding git@vger; please keep discussion on-list so everyone can
benefit from the result]
On Tue, Jan 06, 2009 at 03:52:12PM +0800, Johnny Lee wrote:
> Thanks Peff, I've checked the permission of .git/objects/16, it's
> created by another user and thus I have no permission to remove it.
>
> In fact, this is coming from a previous bad practice on setting up a
> collaboration repository on a SSH server, here is what I've done so
> far:
> [...]
> 7. Then the user "git" has changed mode for all the files under .git
> to writable.
>
> 8. This time, user "johnny" can push successfully.
If you are going to have multiple users sharing a repository, generally
they should be in the same group and the core.sharedrepository config
option should be set (see "git help config", or the "shared" option to
git-init).
I've never used that personally, though. I have always just used POSIX
ACLs, with a default ACL on each directory giving access to everyone.
E.g. (off the top of my head):
for user in user1 user2 user3; do
setfacl -R -m u:$user:rwX -m d:u:$user:rwX /path/to/repo
done
-Peff
^ permalink raw reply
* Re: Error: unable to unlink ... when using "git gc"
From: Jeff King @ 2009-01-06 7:22 UTC (permalink / raw)
To: Johnny Lee; +Cc: git
In-Reply-To: <488807870901052300y57f59b90rdc03cc47c790b416@mail.gmail.com>
On Tue, Jan 06, 2009 at 03:00:52PM +0800, Johnny Lee wrote:
> While I'm looking at these "unable to unlink" files, it seems they are
> read only:
> git@tomato:~/golf$ ls -l .git/objects/16/
> total 4
> -r--r--r-- 1 johnny johnny 26 2009-01-05 09:25
> b14f5da9e2fcd6f3f38cc9e584cef2f3c90ebe
>
> Is there anything wrong here?
It is normal for objects to be read-only. However, permission to unlink
a file comes from its directory permission. Is .git/objects/16 writable
by you?
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox