* Locked dev repository
From: Valon @ 2011-10-02 9:06 UTC (permalink / raw)
To: git
I used a tutorial to add a new user to gitosis, and at the same time I
removed the user who initially set up the whole thing (as he left the
project team).
Now I can only checkout the gitosis-admin repo, but not the development
repository anymore. Can anybody help me with what has happened and how to
fix this?
I tried already to commit an elder version of the gitosis.conf but sadly
this did not help me.
thanks, Valon
--
View this message in context: http://git.661346.n2.nabble.com/Locked-dev-repository-tp6852249p6852249.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: Frans Klaver @ 2011-10-02 6:43 UTC (permalink / raw)
To: git
In-Reply-To: <CAN0CFw3ZDcXtD7WChjkT1Vg0cU_u==4KCHo8ff-ccbyxZ8xWjg@mail.gmail.com>
On Sun, 02 Oct 2011 05:34:43 +0200, Grant <emailgrant@gmail.com> wrote:
> That's true. I hope to be able to give different developers access to
> different parts of the code. I really don't know if this will work.
> I just don't want my code to be stolen and I'm trying to find some way
> to prevent that from happening.
To me it seems like you don't trust your developers? If you run a
business and you hire external developers, have them sign an NDA.
Should be legally binding.
I as a developer would be severely insulted if my boss tried to keep
me away from some code, just because he was afraid it might get stolen.
If you don't trust them, fix your trust and relationship, not some tool.
Just my two cents.
Have a good one,
Frans
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: Andreas Krey @ 2011-10-02 6:38 UTC (permalink / raw)
To: Grant; +Cc: git
In-Reply-To: <CAN0CFw3ZDcXtD7WChjkT1Vg0cU_u==4KCHo8ff-ccbyxZ8xWjg@mail.gmail.com>
On Sat, 01 Oct 2011 20:34:43 +0000, Grant wrote:
...
> That's true. I hope to be able to give different developers access to
> different parts of the code. I really don't know if this will work.
Depending on the implementation it may drive away the good devs...
Anyway, what I think you need (for the reasons detailed in the svn list)
is a setup where the whole project is checked out in the staging area
where it can be tested in whatever way. That under a user id different
from the dev's. Then you change permissions so that he can only see
and edit the files you want him to. This at least eases the problem
of having to commit for each test, and gives you a meaningful history.
Additionally have sudo permissions to do commits etc. in the staging area.
(But still the dev's life will be, erm, suboptimal.)
> I just don't want my code to be stolen and I'm trying to find some way
> to prevent that from happening.
I'm just getting creative. When the one file that you allow access to
is server-side code (as opposed to, say, css or client js) then the
malevolent dev can use that to read the rest of the staging area anyway.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
^ permalink raw reply
* Re: [PATCH v3] refs: Use binary search to lookup refs faster
From: Junio C Hamano @ 2011-10-02 5:45 UTC (permalink / raw)
To: Michael Haggerty
Cc: Julian Phillips, Martin Fick, Christian Couder, git,
Christian Couder, Thomas Rast
In-Reply-To: <4E87F383.1050403@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Um, well, my patch series includes the same changes that Julian's wants
> to introduce, but following lots of other changes, cleanups,
> documentation improvements, etc. Moreover, my patch series builds on
> mh/iterate-refs, with which Julian's patch conflicts. In other words,
> it would be a real mess to reroll my series on top of Julian's patch.
Conflicts during re-rolling was not something I was worried too much
about---that is just the fact of life. We cannot easily resolve two topics
that want to go in totally different direction, but we should be able to
converge two topics that want to take the same approach in the end,
especially one is a subset of the other.
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Michael Haggerty @ 2011-10-02 5:19 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin Fick, git, Christian Couder, Thomas Rast,
René Scharfe, Julian Phillips
In-Reply-To: <7vwrcola0m.fsf@alter.siamese.dyndns.org>
On 10/01/2011 10:41 PM, Junio C Hamano wrote:
> Martin Fick <mfick@codeaurora.org> writes:
>> I guess this makes sense, we invalidate the cache and have
>> to rebuild it after every new ref is added? Perhaps a
>> simple fix would be to move the invalidation right after all
>> the refs are updated? Maybe write_ref_sha1 could take in a
>> flag to tell it to not invalidate the cache so that during
>> iterative updates it could be disabled and then run manually
>> after the update?
>
> It might make sense, on top of Julian's patch, to add a bit that says "the
> contents of this ref-array is current but the array is not sorted", and
> whenever somebody runs add_ref(), append it also to the ref-array (so that
> the contents do not have to be re-read from the filesystem) but flip the
> "unsorted" bit on. Then update look-up and iteration to sort the array
> when "unsorted" bit is on without re-reading the contents from the
> filesystem.
My WIP patch series does one better than this; it keeps track of what
part of the array is already sorted so that a reference can be found in
the sorted part of the array using binary search, and if it is not found
there a linear search is done through the unsorted part of the array. I
also have some code (not pushed) that adds some intelligence to make the
use case
repeat many times:
check if reference exists
add reference
efficient by picking optimal intervals to re-sort the array. (This sort
can also be faster if most of the array is already sorted: sort the new
entries using qsort then merge sort them into the already-sorted part of
the list.)
But there is another reason that we cannot currently update the
reference cache on the fly rather than invalidating it after each
change: symbolic references are stored *resolved* in the reference
cache, and no record is kept of the reference that they refer to.
Therefore it is possible that the addition or modification of an
arbitrary reference can affect how a symbolic reference is resolved, but
there is not enough information in the cache to track this.
IMO the correct solution is to store symbolic references un-resolved.
Given that lookup is going to become much faster, the slowdown in
reference resolution should not be a big performance penalty, whereas
reference updating could become *much* faster.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH v3] refs: Use binary search to lookup refs faster
From: Michael Haggerty @ 2011-10-02 5:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: Julian Phillips, Martin Fick, Christian Couder, git,
Christian Couder, Thomas Rast
In-Reply-To: <7vk48qouht.fsf@alter.siamese.dyndns.org>
On 09/30/2011 06:38 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> On 09/30/2011 01:48 AM, Junio C Hamano wrote:
>>> This version looks sane, although I have a suspicion that it may have
>>> some interaction with what Michael may be working on.
>>
>> Indeed, I have almost equivalent changes in the giant patch series that
>> I am working on [1].
>
> Good; that was the primary thing I wanted to know. I want to take
> Julian's patch early but if the approach and data structures were
> drastically different from what you are cooking, that would force
> unnecessary reroll on your part, which I wanted to avoid.
Um, well, my patch series includes the same changes that Julian's wants
to introduce, but following lots of other changes, cleanups,
documentation improvements, etc. Moreover, my patch series builds on
mh/iterate-refs, with which Julian's patch conflicts. In other words,
it would be a real mess to reroll my series on top of Julian's patch.
(That is of course not to imply that I hold a mutex on refs.c.) Because
it changes a data structure that is used throughout refs.c, changes a
lot of lines of code.
I think that the switch from linked list + linear sort to array plus
binary sort is a pretty obvious win in terms of code complexity and
*potential* performance improvement, but empirically I haven't seen any
claims that it brings performance improvements beyond "René's patch".
(Though, honestly, I've lost track of which "René's patch" is being
discussed and I don't see anything relevant in Junio's tree.)
Intuitively, given that populating the reference cache involves O(N)
I/O, speeding up lookups can only help if there are very many ref
lookups within a single git invocation. I think we will get a better
improvement by avoiding the reading of unneeded loose refs by reading
them one subdirectory at a time instead of always reading them en masse.
I wanted to reach that milestone before submitting my changes.
My preference would be:
1. Merge jp/get-ref-dir-unsorted, perhaps even into maint. It is a
simple, noninvasive, and obvious improvement and helps performance a lot
in an important use case.
2. Hold off on merging jp/get-ref-dir-unsorted for a while to give me a
chance to avoid conflict hell.
3. Evaluate René's patch on its own merits; if it makes sense regardless
of the binary search speedups, then it can be accepted independently to
give most of the performance benefit already.
Are there any other patches in this area that I've forgotten?
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH] diff: resurrect XDF_NEED_MINIMAL with --minimal
From: Junio C Hamano @ 2011-10-02 5:04 UTC (permalink / raw)
To: git; +Cc: René Scharfe
Earlier, 582aa00 (git diff too slow for a file, 2010-05-02)
unconditionally dropped XDF_NEED_MINIMAL option from the internal xdiff
invocation to help performance on pathological cases, while hinting that a
follow-up patch could reintroduce it with "--minimal" option from the
command line.
Make it so.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This together with René's c5aa906 (Revert removal of multi-match
discard heuristic in 27af01, 2011-09-25) on top of v1.7.7 seems to give
identical diff output as v1.7.1 (e.g. "git diff-tree -p v2.6.39 v3.0"
in the kernel repository, with "--minimal").
diff.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index 93ef9a2..34a88db 100644
--- a/diff.c
+++ b/diff.c
@@ -3511,6 +3511,10 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
}
else if (!strcmp(arg, "--abbrev"))
options->abbrev = DEFAULT_ABBREV;
+ else if (!strcmp(arg, "--minimal"))
+ DIFF_XDL_SET(options, NEED_MINIMAL);
+ else if (!strcmp(arg, "--no-minimal"))
+ DIFF_XDL_CLR(options, NEED_MINIMAL);
else if (!prefixcmp(arg, "--abbrev=")) {
options->abbrev = strtoul(arg + 9, NULL, 10);
if (options->abbrev < MINIMUM_ABBREV)
--
1.7.7
^ permalink raw reply related
* Re: [PATCH] Don't sort ref_list too early
From: Michael Haggerty @ 2011-10-02 4:58 UTC (permalink / raw)
To: Julian Phillips; +Cc: Junio C Hamano, Martin Fick, git
In-Reply-To: <20110927000010.79913.71464.julian@quantumfyre.co.uk>
On 09/27/2011 02:00 AM, Julian Phillips wrote:
> get_ref_dir is called recursively for subdirectories, which means that
> we were calling sort_ref_list for each directory of refs instead of
> once for all the refs. This is a massive wast of processing, so now
> just call sort_ref_list on the result of the top-level get_ref_dir, so
> that the sort is only done once.
+1
I think this patch should also be considered for maint, since it is
noninvasive and fixes a bad performance regression.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: Grant @ 2011-10-02 3:34 UTC (permalink / raw)
To: git
In-Reply-To: <CACsJy8B2rhXvGKUsu10Po8cCi7p8uqWXWE5ZHB2Z6hH-aMyR2Q@mail.gmail.com>
>> How would something like that work in a case like mine where I have a
>> series of maybe 100 files and I only want to give my developer
>> read/write access to one or a few files at a time with no read or
>> write access to any of the other files? Wouldn't setting up a
>> different repo for each set of files be difficult to manage?
>
> The write part is easy. Just setup hooks to reject updates on those
> files (however, notice the offline nature of git, people may commit
> locally and the push later, you may need to check commit time on your
> hooks).
>
> The reading part is hard, especially the way you put it ("at a time").
> The only way I can think of is to not download those objects and try
> to fetch from central repo every time the objects are read,
> essentially turn git into a central scm again. Git does not support
> this and may never do unless there's an reasonable use case.
>
> So I have to ask, why do you do it this way? Once you give read-access
> to a developer, he/she can always save the files somewhere, revoking
> read access later on would be useless.
That's true. I hope to be able to give different developers access to
different parts of the code. I really don't know if this will work.
I just don't want my code to be stolen and I'm trying to find some way
to prevent that from happening.
- Grant
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: Nguyen Thai Ngoc Duy @ 2011-10-02 3:24 UTC (permalink / raw)
To: Grant; +Cc: git
In-Reply-To: <CAN0CFw2gVH7=LdKhseE3zo+Av_=kVdz=tH3s=BKeTK9bDOprcw@mail.gmail.com>
On Sun, Oct 2, 2011 at 1:53 PM, Grant <emailgrant@gmail.com> wrote:
> How would something like that work in a case like mine where I have a
> series of maybe 100 files and I only want to give my developer
> read/write access to one or a few files at a time with no read or
> write access to any of the other files? Wouldn't setting up a
> different repo for each set of files be difficult to manage?
The write part is easy. Just setup hooks to reject updates on those
files (however, notice the offline nature of git, people may commit
locally and the push later, you may need to check commit time on your
hooks).
The reading part is hard, especially the way you put it ("at a time").
The only way I can think of is to not download those objects and try
to fetch from central repo every time the objects are read,
essentially turn git into a central scm again. Git does not support
this and may never do unless there's an reasonable use case.
So I have to ask, why do you do it this way? Once you give read-access
to a developer, he/she can always save the files somewhere, revoking
read access later on would be useless.
--
Duy
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: Grant @ 2011-10-02 2:53 UTC (permalink / raw)
To: git
In-Reply-To: <CAMK1S_icdpCyA8SBcNu8CbCk3N-h8yEYZ9+6N=JVPAeayuzSPw@mail.gmail.com>
>>>> Hello, I'm trying to decide between git and subversion. Subversion
>>>> has "Path-Based Authorization" so I can give a developer access to
>>>> only specific files instead of everything. Does git have something
>>>> similar?
>>>>
>>>> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
>>>
>>> In distributed version control systems each developers gets full copy
>>> (a clone) of a repository (separate repository instance). This means that
>>> if you want for developer to see only specified subset of repository
>>> (specific subdirectories) you would have to split repository into
>>> submodules, and control access on (sub)repository basis.
>>
>> I do want to prevent reading of all but one or a few specified files
>> at a time. I did some reading on the differences between centralized
>> and distributed version control systems, and I can see how a
>> distributed system may be better for open source projects, but a
>> business project like mine may work better with centralized control.
>> Would you guys agree in general? Easier read/write control of
>> individual files in the repository is one benefit of the centralized
>> model I will put to use.
>>
>>> However if you want only to prevent developer from making changes outside
>>> specific subdirectory or specified files, you can do that on publish time
>>> via update / pre-receive hook (like contrib/hooks/update-paranoid), or git
>>> repository management tool such as Gitolite. That would prevent a push if
>>> any of commits being published touches files that it shouldn't.
>>>
>>> P.S. Karl Fogel in "Producing Open Source Software" (http://producingoss.com)
>>> writes that social solutions wrt. restricting contributors to given area
>>> are better than technical solutions such as (overly-)strict access
>>> control.
>>
>> When I started this thread, I didn't realize the fact that my project
>> is not open-source would help decide which version control system to
>> use. Now I see that it does factor into the decision so I apologize
>> for not mentioning it previously.
>
> I'm afraid I did not follow the full thread, but I can assure you we
> have several "secret secret" type projects at work, both mine as well
> as many others.
>
> There are a few occasions when they need the kind of stuff you seem to
> want more regularly, (the only one I can really recall is one of our
> largest customers has a custom version of one of our product for
> themselves and do not want people working on the generic version to
> see those changes in case they propagate to their competitors). We
> just do that by using a different repo entirely, and making sure
> changes to common code migrate only one way.
How would something like that work in a case like mine where I have a
series of maybe 100 files and I only want to give my developer
read/write access to one or a few files at a time with no read or
write access to any of the other files? Wouldn't setting up a
different repo for each set of files be difficult to manage?
- Grant
> Git has too many advantages over legacy VCSs like SVN for people to
> throw it over for something as simple as this.
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: Sitaram Chamarty @ 2011-10-02 1:27 UTC (permalink / raw)
To: Grant; +Cc: git
In-Reply-To: <CAN0CFw3kzAgaVBKNHE5ttJgYnc_csjeHjOLq=EBjLizW=RPUkA@mail.gmail.com>
On Sun, Oct 2, 2011 at 5:30 AM, Grant <emailgrant@gmail.com> wrote:
>>> Hello, I'm trying to decide between git and subversion. Subversion
>>> has "Path-Based Authorization" so I can give a developer access to
>>> only specific files instead of everything. Does git have something
>>> similar?
>>>
>>> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
>>
>> In distributed version control systems each developers gets full copy
>> (a clone) of a repository (separate repository instance). This means that
>> if you want for developer to see only specified subset of repository
>> (specific subdirectories) you would have to split repository into
>> submodules, and control access on (sub)repository basis.
>
> I do want to prevent reading of all but one or a few specified files
> at a time. I did some reading on the differences between centralized
> and distributed version control systems, and I can see how a
> distributed system may be better for open source projects, but a
> business project like mine may work better with centralized control.
> Would you guys agree in general? Easier read/write control of
> individual files in the repository is one benefit of the centralized
> model I will put to use.
>
>> However if you want only to prevent developer from making changes outside
>> specific subdirectory or specified files, you can do that on publish time
>> via update / pre-receive hook (like contrib/hooks/update-paranoid), or git
>> repository management tool such as Gitolite. That would prevent a push if
>> any of commits being published touches files that it shouldn't.
>>
>> P.S. Karl Fogel in "Producing Open Source Software" (http://producingoss.com)
>> writes that social solutions wrt. restricting contributors to given area
>> are better than technical solutions such as (overly-)strict access
>> control.
>
> When I started this thread, I didn't realize the fact that my project
> is not open-source would help decide which version control system to
> use. Now I see that it does factor into the decision so I apologize
> for not mentioning it previously.
I'm afraid I did not follow the full thread, but I can assure you we
have several "secret secret" type projects at work, both mine as well
as many others.
There are a few occasions when they need the kind of stuff you seem to
want more regularly, (the only one I can really recall is one of our
largest customers has a custom version of one of our product for
themselves and do not want people working on the generic version to
see those changes in case they propagate to their competitors). We
just do that by using a different repo entirely, and making sure
changes to common code migrate only one way.
Git has too many advantages over legacy VCSs like SVN for people to
throw it over for something as simple as this.
^ permalink raw reply
* [PATCHv3] git-web--browse: avoid the use of eval
From: Chris Packham @ 2011-10-02 0:44 UTC (permalink / raw)
To: git; +Cc: gitster, peff, chriscool, Chris Packham
Using eval causes problems when the URL contains an appropriately
escaped ampersand (\&). Dropping eval from the built-in browser
invocation avoids the problem.
Helped-by: Jeff King <peff@peff.net> (test case)
Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
The consensus from the last round of discussion [1] seemed to be to
remove the eval from the built in browsers but quote custom browser
commands appropriately.
I've expanded the tests a little. A semi-colon had the same error as
the ampersand. A hash was another common character that had meaning in
a shell and in URL.
[1] http://article.gmane.org/gmane.comp.version-control.git/181671
git-web--browse.sh | 10 +++++-----
t/t9901-git-web--browse.sh | 37 +++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 5 deletions(-)
create mode 100755 t/t9901-git-web--browse.sh
diff --git a/git-web--browse.sh b/git-web--browse.sh
index e9de241..1e82726 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -156,7 +156,7 @@ firefox|iceweasel|seamonkey|iceape)
;;
google-chrome|chrome|chromium|chromium-browser)
# No need to specify newTab. It's default in chromium
- eval "$browser_path" "$@" &
+ "$browser_path" "$@" &
;;
konqueror)
case "$(basename "$browser_path")" in
@@ -164,10 +164,10 @@ konqueror)
# It's simpler to use kfmclient to open a new tab in konqueror.
browser_path="$(echo "$browser_path" | sed -e 's/konqueror$/kfmclient/')"
type "$browser_path" > /dev/null 2>&1 || die "No '$browser_path' found."
- eval "$browser_path" newTab "$@"
+ "$browser_path" newTab "$@" &
;;
kfmclient)
- eval "$browser_path" newTab "$@"
+ "$browser_path" newTab "$@" &
;;
*)
"$browser_path" "$@" &
@@ -175,7 +175,7 @@ konqueror)
esac
;;
w3m|elinks|links|lynx|open)
- eval "$browser_path" "$@"
+ "$browser_path" "$@"
;;
start)
exec "$browser_path" '"web-browse"' "$@"
@@ -185,7 +185,7 @@ opera|dillo)
;;
*)
if test -n "$browser_cmd"; then
- ( eval $browser_cmd "$@" )
+ ( eval "$browser_cmd \"\$@\"" )
fi
;;
esac
diff --git a/t/t9901-git-web--browse.sh b/t/t9901-git-web--browse.sh
new file mode 100755
index 0000000..c6f48a9
--- /dev/null
+++ b/t/t9901-git-web--browse.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+#
+
+test_description='git web--browse basic tests
+
+This test checks that git web--browse can handle various valid URLs.'
+
+. ./test-lib.sh
+
+test_expect_success \
+ 'URL with an ampersand in it' '
+ echo http://example.com/foo\&bar >expect &&
+ git config browser.custom.cmd echo &&
+ git web--browse --browser=custom \
+ http://example.com/foo\&bar >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success \
+ 'URL with a semi-colon in it' '
+ echo http://example.com/foo\;bar >expect &&
+ git config browser.custom.cmd echo &&
+ git web--browse --browser=custom \
+ http://example.com/foo\;bar >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success \
+ 'URL with a hash in it' '
+ echo http://example.com/foo#bar >expect &&
+ git config browser.custom.cmd echo &&
+ git web--browse --browser=custom \
+ http://example.com/foo#bar >actual &&
+ test_cmp expect actual
+'
+
+test_done
--
1.7.7
^ permalink raw reply related
* Re: Does git have "Path-Based Authorization"?
From: Grant @ 2011-10-02 0:00 UTC (permalink / raw)
To: git
In-Reply-To: <m3lit4oo9q.fsf@localhost.localdomain>
>> Hello, I'm trying to decide between git and subversion. Subversion
>> has "Path-Based Authorization" so I can give a developer access to
>> only specific files instead of everything. Does git have something
>> similar?
>>
>> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
>
> In distributed version control systems each developers gets full copy
> (a clone) of a repository (separate repository instance). This means that
> if you want for developer to see only specified subset of repository
> (specific subdirectories) you would have to split repository into
> submodules, and control access on (sub)repository basis.
I do want to prevent reading of all but one or a few specified files
at a time. I did some reading on the differences between centralized
and distributed version control systems, and I can see how a
distributed system may be better for open source projects, but a
business project like mine may work better with centralized control.
Would you guys agree in general? Easier read/write control of
individual files in the repository is one benefit of the centralized
model I will put to use.
> However if you want only to prevent developer from making changes outside
> specific subdirectory or specified files, you can do that on publish time
> via update / pre-receive hook (like contrib/hooks/update-paranoid), or git
> repository management tool such as Gitolite. That would prevent a push if
> any of commits being published touches files that it shouldn't.
>
> P.S. Karl Fogel in "Producing Open Source Software" (http://producingoss.com)
> writes that social solutions wrt. restricting contributors to given area
> are better than technical solutions such as (overly-)strict access
> control.
When I started this thread, I didn't realize the fact that my project
is not open-source would help decide which version control system to
use. Now I see that it does factor into the decision so I apologize
for not mentioning it previously.
- Grant
^ permalink raw reply
* Re: Git, Mac OS X and German special characters
From: Albert Zeyer @ 2011-10-01 23:48 UTC (permalink / raw)
To: Michael Witten; +Cc: Andreas Krey, Andreas Ericsson, Git Mailing List
In-Reply-To: <CAMOZ1BuXiQkZG_7mvay-ybm7Q7niwXVhbmbCmkfy=wD1AKsasQ@mail.gmail.com>
On Sun, Oct 2, 2011 at 12:02 AM, Michael Witten <mfwitten@gmail.com> wrote:
> On Sat, Oct 1, 2011 at 19:47, Andreas Krey <a.krey@gmx.de> wrote:
>
>> The question is, should git forbid two filenames that consist
>> of the *same* characters, only differently uni-encoded? I don't
>> think anyone would make two files named 'Büro', with different
>> unicode encodings. But as far as I know that is a shady area.
>
> So, let's leave git's current behavior as the default and provide
> a config variable that when set, tells git to handle file names
> in terms of characters rather than bytes.
I just read the very lengthy discussion here:
http://thread.gmane.org/gmane.comp.version-control.git/70688
Basically all the arguments have already been discussed.
There are varios options. Most of them are not mutual exclusive, so it
would also be an option to implement most of them and let the user
pick what (s)he prefers.
* TreatFilenamesAsText or however you would call it. I.e. handle
filenames the same when they equal in Unicode.
Linus is very much against this because in rare situations, it could
destroy your data, like in this example:
echo "foo" > Hütte # "Hütte" in NFC
echo "bar" > Hütte # "Hütte" in NFD
The second write would overwrite silently the file generated by the
first write if those filenames would be handled the same. This (and
such) behavior is to be avoided, claims Linus, because it would more
often lead to not wanted behavior in third party applications.
* On MacOSX, wrap all filesystem functions (like readdir()) to convert
all filenames to NFC.
MacOSX normalizes the UTF8 representation of the filenames to NFD but
in most common situations (on most other systems), you end up with the
filename being in NFC.
As the filename is anyway normalized on OSX, it doesn't matter wether
it is handled as NFC or NFD and NFC will likely generate less trouble.
And this patch doesn't even really need an option.
This was one suggestion by Linus itself:
http://news.gmane.org/find-root.php?message_id=%3calpine.LFD.1.00.0801211323120.2957%40woody.linux%2dfoundation.org%3e
* Disallow any files with filenames which are not in NFC at all. This
makes some things a bit more safe (like on MacOSX; along with the
previous suggestion) and more clear (you always know that your
filename is in NFC).
* Some more clever readdir() which, when it gets a filename which is
not in the Git index but Unicode-equally to one filename in the Git
index, automatically replaces it by the filename in the index.
This is some sort of half way to a TreatFilenamesAsText option but
should produce less trouble.
This probably also doesn't need an extra option as it should very
likely generate less trouble (on OSX at least; and for other systems
which don't mangle the filename, they don't need to use this code at
all).
---
I will probably go and try to implement the clever-readdir(). And/or
maybe also the NFC conversation in such a readdir() wrapper.
^ permalink raw reply
* Re: Git, Mac OS X and German special characters
From: Michael Witten @ 2011-10-01 23:26 UTC (permalink / raw)
To: Jakub Narebski
Cc: Andreas Krey, Andreas Ericsson, Albert Zeyer, Git Mailing List
In-Reply-To: <m3hb3snw4b.fsf@localhost.localdomain>
2011/10/1 Jakub Narebski <jnareb@gmail.com>:
> Michael Witten <mfwitten@gmail.com> writes:
>> On Sat, Oct 1, 2011 at 19:47, Andreas Krey <a.krey@gmx.de> wrote:
>>
>> > The question is, should git forbid two filenames that consist
>> > of the *same* characters, only differently uni-encoded? I don't
>> > think anyone would make two files named 'Büro', with different
>> > unicode encodings. But as far as I know that is a shady area.
>>
>> So, let's leave git's current behavior as the default and provide
>> a config variable that when set, tells git to handle file names
>> in terms of characters rather than bytes.
>
> You meant here _graphemes_, not Unicode codepoint when talking about
> characters, didn't you?
Yes.
^ permalink raw reply
* NOTIFICATION 2011
From: E-MAIL.BALLOT.rosilawati @ 2011-10-01 23:12 UTC (permalink / raw)
To: Recipients
NOTIFICATION
This is to inform you of the release of the WINNERS of the E-MAIL LOTTERY
BALLOT / WORLD GAMING BOARD held 2011.Your name attached to ticket number
219028657434 with serial number 918735625 You have therefore been approved
for a payment (€1,500,000.00 Euros only. Your Email ID has won
Email : einfobak@yahoo.com.hk
Tel: +31-64-536-0288
Fax: +31-84-7312-763
Full names,Address,Age,Occupation,Phone/ numbers.
Yours Sincerely,
NAME: MRS LOECKX MARGARETA MARIA CAROLINA
(Web-Email Information Manager)
^ permalink raw reply
* Re: Git, Mac OS X and German special characters
From: Jakub Narebski @ 2011-10-01 23:14 UTC (permalink / raw)
To: Michael Witten
Cc: Andreas Krey, Andreas Ericsson, Albert Zeyer, Git Mailing List
In-Reply-To: <CAMOZ1BuXiQkZG_7mvay-ybm7Q7niwXVhbmbCmkfy=wD1AKsasQ@mail.gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> On Sat, Oct 1, 2011 at 19:47, Andreas Krey <a.krey@gmx.de> wrote:
>
> > The question is, should git forbid two filenames that consist
> > of the *same* characters, only differently uni-encoded? I don't
> > think anyone would make two files named 'Büro', with different
> > unicode encodings. But as far as I know that is a shady area.
>
> So, let's leave git's current behavior as the default and provide
> a config variable that when set, tells git to handle file names
> in terms of characters rather than bytes.
You meant here _graphemes_, not Unicode codepoint when talking about
characters, didn't you?
IIRC the problem with MacOS X is that it accepts different composition
when creating a file from what it returns when asking for contents of
directory (NFD if I remember correctly, which is less used).
There are some beginnings of sanely handling filesystem encoding in
Git (the framework), but it is currently underutilized only to handle
case-sensitivity and case-preserving.
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Peter Shenkin @ 2011-10-01 22:06 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20111001T232414-84@post.gmane.org>
Peter Shenkin <shenkin <at> gmail.com> writes:
> But it leaves unexplained and undocumented the fact
> that the user's specification of an *additional* refspec is
> observed if the additional refspec is given on the
> command line but ignored if the additional refspec is
> given in the config file.
I have to take this back. It makes sense that a refspec on
the cmdline overrides one in the config file.
I understand the behavior now, and Michael's suggestion of a
--default to add the refspec in the config file to the cmdline
is IMO a good one.
'Nuff said. (By me, anyway....)
Thanks for your help and patience, everyone.
-P.
^ permalink raw reply
* Re: Git, Mac OS X and German special characters
From: Michael Witten @ 2011-10-01 22:02 UTC (permalink / raw)
To: Andreas Krey; +Cc: Andreas Ericsson, Albert Zeyer, Git Mailing List
In-Reply-To: <20111001194746.GA16826@inner.h.iocl.org>
On Sat, Oct 1, 2011 at 19:47, Andreas Krey <a.krey@gmx.de> wrote:
> The question is, should git forbid two filenames that consist
> of the *same* characters, only differently uni-encoded? I don't
> think anyone would make two files named 'Büro', with different
> unicode encodings. But as far as I know that is a shady area.
So, let's leave git's current behavior as the default and provide
a config variable that when set, tells git to handle file names
in terms of characters rather than bytes.
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Peter Shenkin @ 2011-10-01 21:41 UTC (permalink / raw)
To: git
In-Reply-To: <CAMOZ1BsYYmH6hqcB4vfCq2LAu+fxJ4MzPQ1+-erUSqU1ptx2mQ@mail.gmail.com>
Michael Witten <mfwitten <at> gmail.com> writes:
> On Sat, Oct 1, 2011 at 20:22, Peter Shenkin <shenkin <at> gmail.com> wrote:
> [--tags] is merely a shorthand for writing the refspec
> `refs/tags/\*:refs/tags/\*'; that is,
Yes, I understand that fully and it makes perfect sense.
But it leaves unexplained and undocumented the fact
that the user's specification of an *additional* refspec is
observed if the additional refspec is given on the
command line but ignored if the additional refspec is
given in the config file.
-P.
^ permalink raw reply
* Re: [PATCH v2] gitk: Show patch for initial commit
From: Zbigniew Jędrzejewski-Szmek @ 2011-10-01 21:03 UTC (permalink / raw)
To: Marcus Karlsson; +Cc: git, gitster, Paul Mackerras
In-Reply-To: <20111001190554.GA5854@kennedy.acc.umu.se>
[cc: Paul Mackerras]
Hi,
I think that the historical explanation that Junio gave could
be used as a basis for a commit message:
In early days, all projects managed by git (except for git itself) had the
product of a fairly mature development history in their first commit, and
it was deemed unnecessary clutter to show additions of these thousands of
paths as a patch.
"git log" learned to show the patch for the initial commit without requiring
--root command line option at 0f03ca9 (config option log.showroot to show
the diff of root commits, 2006-11-23).
Teach gitk to respect log.showroot.
Also the gitk should be mentioned in the man-page for git-config log.showroot.
The current description of this option seems suboptimal because it explains
how it used to be, which is not really relevant:
log.showroot
If true, the initial commit will be shown as a big creation event. This is
equivalent to a diff against an empty tree. Tools like git-log(1) or git-
whatchanged(1), which normally hide the root commit will now show it. True by
default.
This could be changed to:
If true (the default), the root commit will be shown as a big creation
event --- a diff against an empty tree. This diff can be very large for
a project which was imported into git after some development history.
If log.showroot is false tools like git-log(1), git-whatchanged(1), or
gitk(1) will not display the added files.
Zbyszek
On 10/01/2011 09:05 PM, Marcus Karlsson wrote:
> Make gitk show the patch for the initial commit by default.
> Override with log.showroot.
>
> Signed-off-by: Marcus Karlsson<mk@acc.umu.se>
> ---
> gitk-git/gitk | 13 +++++++++++--
> 1 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index 4cde0c4..40ea73f 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -7402,7 +7402,7 @@ proc addtocflist {ids} {
> }
>
> proc diffcmd {ids flags} {
> - global nullid nullid2
> + global log_showroot nullid nullid2
>
> set i [lsearch -exact $ids $nullid]
> set j [lsearch -exact $ids $nullid2]
> @@ -7436,7 +7436,11 @@ proc diffcmd {ids flags} {
> lappend cmd HEAD
> }
> } else {
> - set cmd [concat | git diff-tree -r $flags $ids]
> + set cmd [concat | git diff-tree -r]
> + if {$log_showroot eq true} {
> + set cmd [concat $cmd --root]
> + }
> + set cmd [concat $cmd $flags $ids]
> }
> return $cmd
> }
> @@ -11403,6 +11407,11 @@ catch {
> }
> }
>
> +set log_showroot true
> +catch {
> + set log_showroot [exec git config --get log.showroot]
> +}
> +
> if {[tk windowingsystem] eq "aqua"} {
> set mainfont {{Lucida Grande} 9}
> set textfont {Monaco 9}
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Michael Witten @ 2011-10-01 20:56 UTC (permalink / raw)
To: Peter Shenkin; +Cc: git
In-Reply-To: <loom.20111001T214551-834@post.gmane.org>
On Sat, Oct 1, 2011 at 20:22, Peter Shenkin <shenkin@gmail.com> wrote:
>
> The question is not how the --tags option should be
> documented, but rather why "--tags" should behave
> differently when the refspec is given on the commandline
> than when the refspec is given in the .git/config file.
Again, see here:
[PATCH v3] Docs: Clarify the --tags option of `git fetch'
Message-ID: <686c38876d5a4ad6bfac67ca77fe9bb3-mfwitten@gmail.com>
http://article.gmane.org/gmane.comp.version-control.git/181887
namely:
This option is merely a shorthand for writing the refspec
`refs/tags/\*:refs/tags/\*'; that is,
git fetch origin --tags
git fetch origin --tags frotz
are equivalent to:
git fetch origin 'refs/tags/*:refs/tags/*'
git fetch origin frotz 'refs/tags/*:refs/tags/*'
In other words, by writing "--tags", you are actually writing
"refs/tags/\*:refs/tags/\*"; because you are stating an *explicit*
refspec, "git fetch" doesn't bother with any *implicit* default
in your config, which is consistent with how "git fetch" works.
It would probably be a good idea if there were a "--defaults", too.
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Junio C Hamano @ 2011-10-01 20:41 UTC (permalink / raw)
To: Martin Fick
Cc: git, Christian Couder, Thomas Rast, René Scharfe,
Julian Phillips, Michael Haggerty
In-Reply-To: <201109301606.31748.mfick@codeaurora.org>
Martin Fick <mfick@codeaurora.org> writes:
> I guess this makes sense, we invalidate the cache and have
> to rebuild it after every new ref is added? Perhaps a
> simple fix would be to move the invalidation right after all
> the refs are updated? Maybe write_ref_sha1 could take in a
> flag to tell it to not invalidate the cache so that during
> iterative updates it could be disabled and then run manually
> after the update?
It might make sense, on top of Julian's patch, to add a bit that says "the
contents of this ref-array is current but the array is not sorted", and
whenever somebody runs add_ref(), append it also to the ref-array (so that
the contents do not have to be re-read from the filesystem) but flip the
"unsorted" bit on. Then update look-up and iteration to sort the array
when "unsorted" bit is on without re-reading the contents from the
filesystem.
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Peter Shenkin @ 2011-10-01 20:22 UTC (permalink / raw)
To: git
In-Reply-To: <CAMOZ1Bsc2idQnKxeggruPi1rrY3+vsa=DoMydHY4+BM+qoW69w@mail.gmail.com>
Michael Witten <mfwitten <at> gmail.com> writes:
> git fetch --tags origin '+refs/heads/*:refs/remotes/origin/*'
Well, Junio had just about convinced me that there was
nothing wrong with the documentation -- just with the
way I was reading it -- until I read the above.
I tried it and yes, it does do what I want. Which was not
at all my expectation, having read Junio's comment about
how the documentation is to be read.
Junio argued that the man-page mod I suggested --
namely, "This flag causes all tags and their associated
objects (only) to be downloaded." -- was unneeded
because the meaning, though correct, is clear already and
therefore redundant.
But the real problem is that the reading he gives is just
wrong.
I have the following in my .git/config file:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
tagopt = --tags
url = <whatever>
Given this, I do not see how anyone could infer from
anything in the documentation that
git fetch
would do anything different from:
git fetch --tags origin +refs/heads/*:refs/remotes/origin/*
If I am wrong about this, please cite chapter and verse.
The question is not how the --tags option should be
documented, but rather why "--tags" should behave
differently when the refspec is given on the commandline
than when the refspec is given in the .git/config file.
In fact, I no longer think it is a documentation error. It
is a just a really terrible implementation decision. If it
was desired to allow "git fetch --tags" to work without
using the user's specified refspec, then a "--no-heads"
option should have been provided to override the user's
refspec -- no matter where it was given.
Though a retrofit would likely break too many workflows,
the best one might hope for now would likely be the
addition of a "--heads" option, which would have the
effect of bringing down the branch heads even though
this would not normally be done."
But then it would still be necessary to say that "--tags"
does not normally obey the user's refspec if given in the
config file, but does if given on the command line.
I might still be missing something. If anyone thinks the
current behavior is clear from a careful reading of the
documentation, I would like to hear how that inference
could be drawn. For no matter how one reads the --tags
description, it seems it is wrong in one of the two cases.
It is either wrong for a refspec on the command-line (if
you think it says it downloads tags only) or else it is wrong
for refspec in the config file (if you think it says it downloads
tags and heads).
^ 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