* 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
* 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: 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
* [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: 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
* 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: 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 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: [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
* [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 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
* 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: 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: 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: 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
* 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: how to produce an index with smudged entries
From: Robin Rosenberg @ 2011-10-02 13:10 UTC (permalink / raw)
To: Christian Halstrick; +Cc: git
In-Reply-To: <CAENte7h-sbv7VTBdV7A+=TtONTpgOBBfVWz2Nejm1DqJJ9tFiQ@mail.gmail.com>
Christian Halstrick skrev 2011-09-30 17.33:
> I am trying to find out how native git handles the racy git problem. I
> read https://raw.github.com/git/git/master/Documentation/technical/racy-git.txt.
> But I cannot reproduce the behaviour described in this text.
I guess that code is only likely to work if USE_NSEC is not set or the
file system has only whole second resolution. It might be very hard to
reproduce the situation since the likehood that a file AND the index has
the same timestamp at the subsecond level is very small. Nasty thing to
test :)
Is your file system one that does not have subsecond timestamp
resolution? The nanosecond part of the timestamp(s) should be 0 (byte
24-27 for mtime for the first index entry).
Touch can set the timestamp to an explicit value, so you can use that
instead of waiting for luck. Touch cannot set ctime, but you can make
git ignore ctime by setting core.trustctime to false.
For testing the issue with nanosecond resolution you have to roll your
own touch in C, perl or even Java.
-- robin
^ permalink raw reply
* Re: fatal: index-pack failed
From: Robin Rosenberg @ 2011-10-02 13:47 UTC (permalink / raw)
To: Matti Linnanvuori; +Cc: git
In-Reply-To: <50B87B00-064C-4FCC-B1E8-94A9EB027468@portalify.com>
Matti Linnanvuori skrev 2011-09-30 10.11:
> Jenkins got an error:
>
> Error performing command: git fetch -t ssh://iac-builder@sorsa.portalify.com/p/git/.git+refs/heads/*:refs/
> Command "git fetch -t ssh://iac-builder@sorsa.portalify.com/p/git/.git+refs/heads/*:refs/remotes/origin/*" returned status code 128: error: refs/remotes/origin/HEAD does not point to a valid object!
> error: refs/remotes/origin/master does not point to a valid object!
> error: refs/tags/jenkins-iac-orm-snapshot-889 does not point to a valid object!
> error: refs/remotes/origin/HEAD does not point to a valid object!
> error: refs/remotes/origin/master does not point to a valid object!
> error: refs/tags/jenkins-iac-orm-snapshot-889 does not point to a valid object!
> error: Could not read 49f273234b582edb44bbdbda29193719e5054cb7
> error: refs/remotes/origin/HEAD does not point to a valid object!
> error: refs/remotes/origin/master does not point to a valid object!
> error: missing object referenced by 'refs/tags/iac-1.4.13'
> error: refs/tags/jenkins-iac-orm-snapshot-889 does not point to a valid object!
> error: Could not read 49f273234b582edb44bbdbda29193719e5054cb7
> fatal: pack has 26 unresolved deltas
> fatal: index-pack failed
I saw this too a couple of weeks ago. I have no idea what caused it.
After removing all refs from the remote and fetching again everything
was fine. No system crash was involved.
(fresh) Hypothesis: A fetch updated the refs, but failed to get save the
actual objects. I think git tries hard to make sure that this cannot happen.
In my case JGit might have been used to perform the fetch that failed.
Since you say it's Jenkins, I'd guess not, since it uses C Git.
-- robin
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: Enrico Weigelt @ 2011-10-02 14:50 UTC (permalink / raw)
To: git
In-Reply-To: <op.v2pox0g70aolir@keputer>
* Frans Klaver <fransklaver@gmail.com> wrote:
Putting on my business consultant hat:
> If you don't trust them, fix your trust and relationship, not some tool.
ACK. We're essentially talking about a social/political problem,
bot a technical one. Take my advise, solve the problem on the
layer it comes from.
The whole ideology of keeping individual devs on their little
tiny isle is to have the whole project structured into such
little islands in the first place. Meaning: a really strong
compartimentalization. This requires an strictly modular
architecture (which essentially means having completely
separate trees for the individual modules) and, of course,
good requirements engineering, contract-driven development,
etc, with all the associated role models, etc, etc.
What kind of project are we talking about ?
Tactical control or nuclear plant systems ?
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
^ permalink raw reply
* Re: Restoring timestamps (Re: Branches & directories)
From: Enrico Weigelt @ 2011-10-02 15:06 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <CAE1pOi1J=TWUmJKZorotBsDoz3wozXsioN7fVO=7JBxdMD7Zqg@mail.gmail.com>
* Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
> Eclipse is a wonderful IDE except for how it makes sharing workspaces
> practically impossible (where "share" means "put in SCM", not "used my
> several developers at the same time").
This is one the major points which render it rather useless for me ;-o
> Is it possible to do git stash pop without losing the stash?
git cherry-pick stash{0}
Apropos IDEs:
I've been thinking about how to properly integrate IDEs with VCS'es
like git. My conclusion is that it should be directly built ontop
of it. Project metadata itself belongs into git, and the project
management tool should automatically create local working copies
on-demand. I would even delegate *all* the VCS handling to git
(even when using other VCS'es in the back)
Maybe I'll find some time to do some initial concepts.
Perhaps anybody likes to join in ?
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
^ permalink raw reply
* Re: Bug?: 'git log --find-copies' doesn't match 'git log --follow <rev> -- path/to/file'
From: Alexander Pepper @ 2011-10-02 15:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110930213841.GA9384@sigill.intra.peff.net>
Am 30.09.2011 um 23:38 schrieb Jeff King:
> On Fri, Sep 30, 2011 at 05:32:38PM +0200, Alexander Pepper wrote:
>
>> So git log with copy and rename detection on (--find-copies) tells me,
>> that the file StopClusterException.java is copied to
>> ClusterOperation.java. But If I ask git log for that specific file
>> with --follow git claims a copy from Immutable.java to
>> ClusterOperation.java!
>
> I think that --follow uses --find-copies-harder. Did you try:
>
> git log --numstat --find-copies-harder dd4e90f9
>
> ? Does it find Immutable.java as the source?
>
> -Peff
Using 'git log --numstat --find-copies-harder dd4e90f9' yields "immutable.java" as you expected:
$ git log --numstat --find-copies-harder dd4e90f9
[...]
6 10 src/java/voldemort/annotations/concurrency/Immutable.java => contrib/ec2-testing/src/java/voldemort/utils/ClusterOperation.java
So is there a way to tell --follow to only use --find-copies instead of --find-copies harder? And what is the advantage of using "--find-copies-harder" over "--find-copies"?
Greetings from Berlin
Alex
--
Alexander Pepper
pepper@inf.fu-berlin.de
^ permalink raw reply
* Re: Bug?: 'git log --find-copies' doesn't match 'git log --follow <rev> -- path/to/file'
From: Jeff King @ 2011-10-02 15:25 UTC (permalink / raw)
To: Alexander Pepper; +Cc: git
In-Reply-To: <67B22035-4B90-4A68-8960-DDB58F640CD9@inf.fu-berlin.de>
On Sun, Oct 02, 2011 at 05:10:26PM +0200, Alexander Pepper wrote:
> Using 'git log --numstat --find-copies-harder dd4e90f9' yields "immutable.java" as you expected:
>
> $ git log --numstat --find-copies-harder dd4e90f9
> [...]
> 6 10 src/java/voldemort/annotations/concurrency/Immutable.java => contrib/ec2-testing/src/java/voldemort/utils/ClusterOperation.java
OK. That at least explains what's going on.
> So is there a way to tell --follow to only use --find-copies instead
> of --find-copies harder?
No, it's hard-coded.
> And what is the advantage of using "--find-copies-harder" over "--find-copies"?
It finds more copies. The rename detection works like this:
--find-renames: for each newly-created file, consider any deleted
files as possible sources
--find-copies: like above, but also consider any modified files as
possible sources
--find-copies-harder: like above, but consider any file in the
repository as a possible source
So in theory --find-copies-harder is the most accurate, but it is also
the most expensive. We can afford to do it for --follow since we're only
considering a small subset of the possible destinations.
So git is saying that your immutable.java is actually a better match;
it's just that we don't usually find it because it wasn't modified in
the same commit. Have you looked at the contents? Is it actually a
better match, or is git wrong?
-Peff
^ permalink raw reply
* Re: Branches & directories
From: Robin Rosenberg @ 2011-10-02 16:57 UTC (permalink / raw)
To: Hilco Wijbenga
Cc: Kyle Moffett, Michael Witten, Junio C Hamano, Evan Shelhamer,
Git Mailing List
In-Reply-To: <CAE1pOi1axNmGaPVXqBH02x0N=Z6tgO9R00RTokuJm50eY-OoNg@mail.gmail.com>
Hilco Wijbenga skrev 2011-08-22 22.10:
> [...] I just wish there was at least an option to
> keep the timestamp (and possibly other such things). Even Subversion
> can do that... ;-) After all, not everybody uses C& make.
>
What tools do you use that need the benefits from retaining timestamps?
The only
one I can think of is clearmake, but then that tool goes with another
SCM. Eclipse,
for example, will be just as confused by timestamps that travel
backwards in time, as
make is.
-- robin
^ permalink raw reply
* Re: Branches & directories
From: Ronan Keryell @ 2011-10-02 17:31 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Hilco Wijbenga, Kyle Moffett, Michael Witten, Junio C Hamano,
Evan Shelhamer, Git Mailing List
In-Reply-To: <4E889813.8070205@gmail.com>
>>>>> On Sun, 02 Oct 2011 18:57:55 +0200, Robin Rosenberg <robin.rosenberg@gmail.com> said:
Robin> Hilco Wijbenga skrev 2011-08-22 22.10:
>> [...] I just wish there was at least an option to keep the
>> timestamp (and possibly other such things). Even Subversion can
>> do that... ;-) After all, not everybody uses C& make.
Robin> What tools do you use that need the benefits from retaining
Robin> timestamps? The only one I can think of is clearmake, but
Robin> then that tool goes with another SCM. Eclipse, for example,
Robin> will be just as confused by timestamps that travel backwards
Robin> in time, as make is.
I think of tools called "humans", very common indeed on Earth. :-)
The reward of git success is that it is not only used to develop the
Linux kernel. :-)
We use also git as a very smart repositories to store administrative
documents. It is very convenient to look at the real modification or
creation dates to figure out some historical aspects for example.
metastore is a nice tool providing a begin of this on top of git (or
whatever) but :
- this is not very convenient, needing to deal manually with these
aspects ;
- the metadata is binary and not textual (à la YAML ?) so we loose the
classical textual merging candies when conflict arises on metadata
(ouch).
It is one of my future project to do a more textual version of
metastore, but I'm afraid it is an unbound future... :-/
--
Ronan KERYELL |\/ Phone: +1 408 844 HPC0
HPC Project, Inc. |/) Cell: +33 613 143 766
5201 Great America Parkway #3241 K Ronan.Keryell@hpc-project.com
Santa Clara, CA 95054 |\ skype:keryell
USA | \ http://hpc-project.com
^ permalink raw reply
* Re: Branches & directories
From: Matthieu Moy @ 2011-10-02 19:09 UTC (permalink / raw)
To: Ronan Keryell
Cc: Robin Rosenberg, Hilco Wijbenga, Kyle Moffett, Michael Witten,
Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <87botznvua.fsf@an-dro.info.enstb.org>
Ronan Keryell <Ronan.Keryell@hpc-project.com> writes:
>>>>>> On Sun, 02 Oct 2011 18:57:55 +0200, Robin Rosenberg <robin.rosenberg@gmail.com> said:
>
> Robin> Hilco Wijbenga skrev 2011-08-22 22.10:
> >> [...] I just wish there was at least an option to keep the
> >> timestamp (and possibly other such things). Even Subversion can
> >> do that... ;-) After all, not everybody uses C& make.
AFAIK, Subversion doesn't version timestamps. What it can do is to set
the timestamp to the commit date at the time the file is checked-out.
> Robin> What tools do you use that need the benefits from retaining
> Robin> timestamps? The only one I can think of is clearmake, but
> Robin> then that tool goes with another SCM. Eclipse, for example,
> Robin> will be just as confused by timestamps that travel backwards
> Robin> in time, as make is.
>
> I think of tools called "humans", very common indeed on Earth. :-)
For human beings, it's not really harder to run
git log -1 file
than to look at the on-disk timestamp. And it continues working after
you start modifying the file, so it's much less fragile than the
filesystem timestamp.
But if you insist in reproducing SVN's "use-commit-times = yes" setting,
it should be doable with a post-checkout hook.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ 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