* [PATCH/RFC 0/6] commit caching
From: Jeff King @ 2013-01-29 9:14 UTC (permalink / raw)
To: git; +Cc: Duy Nguyen, Shawn O. Pearce
This is the cleaned-up version of the commit caching patches I mentioned
here:
http://article.gmane.org/gmane.comp.version-control.git/212329
The basic idea is to generate a cache file that sits alongside a
packfile and contains the timestamp, tree, and parents in a more compact
and easy-to-access format.
The timings from this one are roughly similar to what I posted earlier.
Unlike the earlier version, this one keeps the data for a single commit
together for better cache locality (though I don't think it made a big
difference in my tests, since my cold-cache timing test ends up touching
every commit anyway). The short of it is that for an extra 31M of disk
space (~4%), I get a warm-cache speedup for "git rev-list --all" of
~4.2s to ~0.66s.
The big thing it does not (yet) do is use offsets to reference sha1s, as
Shawn suggested. This would potentially drop the on-disk size from 84
bytes to 16 bytes per commit (or about 6M total for linux.git).
Coupled with using compression level 0 for trees (which do not compress
well at all, and yield only a 2% increase in size when left
uncompressed), my "git rev-list --objects --all" time drops from ~40s to
~25s. Perf reveals that we're spending most of the remaining time in
lookup_object. I've spent a fair bit of time trying to optimize that,
but with no luck; I think it's fairly close to optimal. The problem is
just that we call it a very large number of times, since it is the
mechanism by which we recognize that we have already processed each
sha1.
[1/6]: csum-file: make sha1write const-correct
[2/6]: strbuf: add string-chomping functions
[3/6]: introduce pack metadata cache files
[4/6]: introduce a commit metapack
[5/6]: add git-metapack command
[6/6]: commit: look up commit info in metapack
-Peff
^ permalink raw reply
* [PATCH] git p4: chdir resolves symlinks only for relative paths
From: Miklós Fazekas @ 2013-01-29 8:37 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons
In-Reply-To: <CAAMmcSSvrsZqEVf68Nrqy_ZG6r5ESKhtx7JdQ7vzypkZ3gOFnA@mail.gmail.com>
[resending as plain text]
If a p4 client is configured to /p/foo which is a symlink
to /vol/bar/projects/foo, then resolving symlink, which
is done by git-p4's chdir will confuse p4: "Path
/vol/bar/projects/foo/... is not under client root /p/foo"
While AltRoots in p4 client specification can be used as a
workaround on p4 side, git-p4 should not resolve symlinks
in client paths.
chdir(dir) uses os.getcwd() after os.chdir(dir) to resolve
relative paths, but as a side effect it resolves symlinks
too. Now it checks if the dir is relative before resolving.
Signed-off-by: Miklós Fazekas <mfazekas@szemafor.com>
---
git-p4.py | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index 2da5649..5d74649 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -64,7 +64,10 @@ def chdir(dir):
# not using the shell, we have to set it ourselves. This path could
# be relative, so go there first, then figure out where we ended up.
os.chdir(dir)
- os.environ['PWD'] = os.getcwd()
+ if os.path.isabs(dir):
+ os.environ['PWD'] = dir
+ else:
+ os.environ['PWD'] = os.getcwd()
def die(msg):
if verbose:
--
1.7.10.2 (Apple Git-33)
^ permalink raw reply related
* Re: [PATCH 0/2] optimizing pack access on "read only" fetch repos
From: Jeff King @ 2013-01-29 8:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vlibfxhit.fsf@alter.siamese.dyndns.org>
On Sat, Jan 26, 2013 at 10:32:42PM -0800, Junio C Hamano wrote:
> Both makes sense to me.
>
> I also wonder if we would be helped by another "repack" mode that
> coalesces small packs into a single one with minimum overhead, and
> run that often from "gc --auto", so that we do not end up having to
> have 50 packfiles.
>
> When we have 2 or more small and young packs, we could:
>
> - iterate over idx files for these packs to enumerate the objects
> to be packed, replacing read_object_list_from_stdin() step;
>
> - always choose to copy the data we have in these existing packs,
> instead of doing a full prepare_pack(); and
>
> - use the order the objects appear in the original packs, bypassing
> compute_write_order().
I'm not sure. If I understand you correctly, it would basically just be
concatenating packs without trying to do delta compression between the
objects which are ending up in the same pack. So it would save us from
having to do (up to) 50 binary searches to find an object in a pack, but
would not actually save us much space.
I would be interested to see the timing on how quick it is compared to a
real repack, as the I/O that happens during a repack is non-trivial
(although if you are leaving aside the big "main" pack, then it is
probably not bad).
But how do these somewhat mediocre concatenated packs get turned into
real packs? Pack-objects does not consider deltas between objects in the
same pack. And when would you decide to make a real pack? How do you
know you have 50 young and small packs, and not 50 mediocre coalesced
packs?
-Peff
^ permalink raw reply
* Re: Cloning remote HTTP repository: Can only see 'master' branch
From: Jeff King @ 2013-01-29 8:23 UTC (permalink / raw)
To: Michael Tyson; +Cc: git
In-Reply-To: <83605E83-1110-449B-969D-AB43158376EA@atastypixel.com>
On Tue, Jan 29, 2013 at 04:54:13PM +1100, Michael Tyson wrote:
> I've a readonly git repository that I'm hosting via HTTP (a bare git
> repository located within the appropriate directory on the server). I
> push to it via my own SSH account (local repository with a remote
> pointing to the ssh:// URL).
>
> This has all worked fine so far - I push via ssh, and others can clone
> and pull via the HTTP URL.
>
> I've recently added a branch - "beta" - which pushed just fine, but
> now cloning via the HTTP URL doesn't seem to show the new branch -
> just master:
If you are using the "dumb" http protocol (i.e., the web server knows
nothing about git, and just serves the repo files), you need to run "git
update-server-info" after each push in order to update the static file
that tells the git client about each ref. You can have git do it
automatically for you by setting receive.updateServerInfo in the server
repo's config.
If the server is yours to control, consider setting up the "smart" http
protocol, as it is much more efficient. Details are in "git help
http-backend".
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] upload-pack: avoid parsing objects during ref advertisement
From: Jeff King @ 2013-01-29 8:14 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git, git-dev
In-Reply-To: <CAJo=hJubUF2mmkzXU77kQ5uj1cbBZrnLcw2u736wMqxhs39jdQ@mail.gmail.com>
On Tue, Jan 29, 2013 at 12:10:59AM -0800, Shawn O. Pearce wrote:
> > On a repository with 120K refs, the advertisement portion of
> > upload-pack goes from ~3.4s to 3.2s (the failure to speed up
> > more is largely due to the fact that most of these refs are
> > tags, which need dereferenced to find the tag destination
> > anyway).
>
> Why aren't we using the peeled information from the packed-refs file?
> JGit does this and it saves a lot of time on advertisements from a
> well packed repository.
The patch you are replying to is a year old. Since then, I did:
435c833 (upload-pack: use peel_ref for ref advertisements, 2012-10-04)
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] upload-pack: avoid parsing objects during ref advertisement
From: Shawn Pearce @ 2013-01-29 8:10 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, git-dev
In-Reply-To: <20120106191740.GA12903@sigill.intra.peff.net>
On Fri, Jan 6, 2012 at 11:17 AM, Jeff King <peff@peff.net> wrote:
> When we advertise a ref, the first thing we do is parse the
> pointed-to object. This gives us two things:
...
> The downside is that we are no longer verifying objects that
> we advertise by fully parsing them (however, we do still
> know we actually have them, because sha1_object_info must
> find them to get the type). While we might fail to detect a
> corrupt object here, if the client actually fetches the
> object, we will parse (and verify) it then.
As you explain, its not necessary to verify during the advertisement
phase. Its fine to delay verification to when a client actually
"wants" the object.
> On a repository with 120K refs, the advertisement portion of
> upload-pack goes from ~3.4s to 3.2s (the failure to speed up
> more is largely due to the fact that most of these refs are
> tags, which need dereferenced to find the tag destination
> anyway).
Why aren't we using the peeled information from the packed-refs file?
JGit does this and it saves a lot of time on advertisements from a
well packed repository.
^ permalink raw reply
* Re: [PATCH 0/2] optimizing pack access on "read only" fetch repos
From: Shawn Pearce @ 2013-01-29 8:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vlibfxhit.fsf@alter.siamese.dyndns.org>
On Sat, Jan 26, 2013 at 10:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> This is a repost from here:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/211176
>>
>> which got no response initially. Basically the issue is that read-only
>> repos (e.g., a CI server) whose workflow is something like:
>>
>> git fetch $some_branch &&
>> git checkout -f $some_branch &&
>> make test
>>
>> will never run git-gc, and will accumulate a bunch of small packs and
>> loose objects, leading to poor performance.
...
> I also wonder if we would be helped by another "repack" mode that
> coalesces small packs into a single one with minimum overhead, and
> run that often from "gc --auto", so that we do not end up having to
> have 50 packfiles.
Yes. This does help....
> When we have 2 or more small and young packs, we could:
>
> - iterate over idx files for these packs to enumerate the objects
> to be packed, replacing read_object_list_from_stdin() step;
>
> - always choose to copy the data we have in these existing packs,
> instead of doing a full prepare_pack(); and
>
> - use the order the objects appear in the original packs, bypassing
> compute_write_order().
Hmm, sounds familiar. Seems like its what we do in JGit for Android. :-)
^ permalink raw reply
* Why Same Files show up with different Statuses in Git?
From: Matthew Johnson @ 2013-01-29 7:38 UTC (permalink / raw)
To: git
First, some background. I have one hard disk separated into two
partitions: one for the version of Windows 7 that shipped on this
rather new Thinkpad (Windows 7 Professional SP1), the other for Fedora
17 (which I installed and keep up-to-date). Of course, it is rather
easy to access the Windows partition from the F17 partition, which I
have been doing with no noticeable problems: the File Explorer
equivalent, Dolphin (the KDE equivalent) will automount the Windows
partition as a filesystem under /media, I only have to enter the
password for 'su'.
I don't think it makes a difference, but for completeness I provide
the options with which I find it mounted:
/dev/sda2 on /media/Windows7_OS type fuseblk
(rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096).
Anyway, the problem is this: the very same files, e.g.
/media/Windows7_OS/cygwin/home/Matthew
Johnson/MrEd/mr.ed/lesson1/images/home-icon.jpg show up as 'modified'
when I type "git status" (in the mr.ed/ dir) using the F17 git client,
but do not show up at all when I type "git status" under the Cygwin
client. This problem is not on all files, only a few, predominantly in
two directories.
Under Windows (cygwin) "git status" shows nothing to commit, only
untracked files, which is what I expect; only under F17 do I get
several modified files -- and these have old dates (e.g. Nov 27).
Yes, that is another important note: I am running Cygwin on the
Windows partition.
The versions of things under the F17 partition are:
Linux 3.7.3-101.fc17.x86_64 x86_64
System: Fedora release 17 (Beefy Miracle)
KDE: 4.9.5
git --version
git version 1.7.11.7
Under Cygwin, the git version is 1.7.9.
Finally, I did check the git configuration to make sure the same
user.name and user.email are set in both. And in both cases, I made
mr.ed the current directory before executing "git status". Shouldn't
that be enough? Is there anything else that must match in the git
config?
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 11 new messages
From: Ralf Thielow @ 2013-01-29 7:42 UTC (permalink / raw)
To: Philip Oakley; +Cc: Thomas Rast, jk, stimming, Git List
In-Reply-To: <AE5DE037F2E44705AC6716EEB19948B1@PhilipOakley>
2013/1/28 Philip Oakley <philipoakley@iee.org>:
> From: "Ralf Thielow" <ralf.thielow@gmail.com>
> Sent: Monday, January 28, 2013 5:55 PM
>
>> On Mon, Jan 28, 2013 at 11:33:09AM +0100, Thomas Rast wrote:
>>>
>>> Ralf Thielow <ralf.thielow@gmail.com> writes:
>>>
>>> > #: builtin/reset.c:275
>>> > -#, fuzzy, c-format
>>> > +#, c-format
>>> > msgid "Failed to resolve '%s' as a valid revision."
>>> > -msgstr "Konnte '%s' nicht als gültige Referenz auflösen."
>>> > +msgstr "Konnte '%s' nicht als gültige Revision auflösen."
>>>
>>> You don't have "revision" in the glossary[1] yet. Wouldn't it be
>>> appropriate to treat it as "commit", and translate as "Version" to
>>> avoid
>>> introducing yet another term?
>>>
>>> Or am I missing some subtle distinction between commit and revision?
>>>
>>
>> I don't think there's a distinction.
>
>
> It was a problem I had http://stackoverflow.com/a/11792712/717355
> answered as:
>
> See "SPECIFYING REVISIONS" of git rev-parse:
>
> A revision parameter <rev> typically, but not necessarily, names a commit
> object.
> It uses what is called an extended SHA1 syntax, [and includes] various ways
> to spell object names.
>
> It had me confused for a while.
>
Thanks. So it would be a mistake to translate "revision" and "commit"
with the same word. This would hide the special meaning of revision and
the user wouldn't see that there's a difference.
I'll amend the commit which unifys the translation of "revision" and "commit"
in the way that "revision" will be translated as "Revision" in the whole file.
I'll also update the glossary.
>> Since we've already translated
>> "revision" as "Revision" in a couple of other messages, I'll make a
>> new "s/Revision/Version" commit on top.
>>
>>> Since it's only a single nit, feel free to add my ack when you
>>> reroll:
>>>
>>> Acked-by: Thomas Rast <trast@inf.ethz.ch>
>>>
>>>
>>> [1] https://github.com/ralfth/git-po-de/wiki/Glossary
>>>
>>> --
>>> Thomas Rast
>>> trast@{inf,student}.ethz.ch
>>
>> --
>
> Philip Oakley
^ permalink raw reply
* Re: [RFC] The design of new pathspec features
From: Junio C Hamano @ 2013-01-29 6:31 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <CACsJy8DsKFfGoPUt5b=3MuSmZ2z2Z5vJ20D_kqEowAUc8QTryA@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
>> prefixq=$(git rev-parse --show-prefix-glob-quoted)
>> pathspec="$prefixq$1"
>>
>> but magic that applies only to a substring may have other uses.
>
> Yeah, that simplifies things. Supporting applying magic over just
> parts of the pathspec pattern sounds complex. Just a small
> modification. That rev-parse needs to look at "$1" as well.
Makes sense. More like
prefix=$(git rev-parse --show-prefix)
test -z "$prefix" || cd $(git rev-parse --show-cdup)
...
pathspec=$(git rev-parse --prefix-pathspec "$prefix" "$1")
git ls-files "$pathspec"
which may take prefix="D*cumentati*n" (from the previous example),
and the user may have given ":(icase)hell*.txt" to "$1". Ideally
the scriptors shouldn't have to worry about how to add the prefix to
the user supplied pathspec.
^ permalink raw reply
* Re: [RFC] The design of new pathspec features
From: Duy Nguyen @ 2013-01-29 6:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd2wotuxm.fsf@alter.siamese.dyndns.org>
On Tue, Jan 29, 2013 at 12:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Have you considered if it may be helpful to have a :(literal) magic
> (or any magic in general) that applies only to the first N
> characters of the pathspec pattern?
Not user-driven. But the prefix part is :(literal)-applied. :(glob) is
currently implemented this way, using nowildcard_len as you mentioned.
:(icase) is more complicated and does not follow yet.
> I personally think we do not need to support something like this:
>
> prefix=$(git rev-parse --show-prefix)
> n=${#prefix}
> pathspec=":(literal-$n)$prefix$1"
>
> but other aspiring Porcelain script writers may disagree and would
> want to have it. We can always solve it by giving them an easy and
> uniform way to get the glob-quoted version of prefix to solve this
> particular issue, i.e.
>
> prefixq=$(git rev-parse --show-prefix-glob-quoted)
> pathspec="$prefixq$1"
>
> but magic that applies only to a substring may have other uses.
Yeah, that simplifies things. Supporting applying magic over just
parts of the pathspec pattern sounds complex. Just a small
modification. That rev-parse needs to look at "$1" as well. If
:(literal) is already specified, glob quoting will backfire. The user
script can deal with that, but it's harder (e.g. parsing magic from
scripts and deal with magic combination) than letting rev-parse does
it.
I've done some form of this already, for supporting add--interactive.
git-add prefixes the pathspec but keeps all the magic in place, before
passing pathspec to add--interactive. But I missed the quoting point
you mentioned above. I probably need de-quoting the prefix as well.
Many optimizations stop short at the sign of any glob symbols,
including backslash. This could be a new task for wildmatch.
--
Duy
^ permalink raw reply
* Cloning remote HTTP repository: Can only see 'master' branch
From: Michael Tyson @ 2013-01-29 5:54 UTC (permalink / raw)
To: git
Hello!
I've a readonly git repository that I'm hosting via HTTP (a bare git repository located within the appropriate directory on the server). I push to it via my own SSH account (local repository with a remote pointing to the ssh:// URL).
This has all worked fine so far - I push via ssh, and others can clone and pull via the HTTP URL.
I've recently added a branch - "beta" - which pushed just fine, but now cloning via the HTTP URL doesn't seem to show the new branch - just master:
$ git clone http://server.tld/path/to/repository.git repository
Cloning into 'repository'...
$ cd repository
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
Cloning via the readwrite ssh URL works fine though:
$ git clone ssh://user@server.tld:www/path/to/repository.git repository
Cloning into 'repository'...
stdin: is not a tty
remote: Counting objects: 225, done.
remote: Compressing objects: 100% (196/196), done.
remote: Total 225 (delta 109), reused 77 (delta 25)
Receiving objects: 100% (225/225), 9.55 MiB | 295 KiB/s, done.
Resolving deltas: 100% (109/109), done.
$ cd repository
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/beta
remotes/origin/master
I've tried 'git clone --mirror' just in case, but this just resulted in a bare repository with only the 'master' branch, still.
Anyone have any ideas about what I'm doing wrong?
Cheers,
Michael
^ permalink raw reply
* Re: [RFC] The design of new pathspec features
From: Junio C Hamano @ 2013-01-29 5:33 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <20130129043517.GA2878@duynguyen-vnpc.dek-tpc.internal>
Duy Nguyen <pclouds@gmail.com> writes:
> :(literal) magic
> ================
>
> This magic is for people who want simple no-globbing pathspec (*). It
> can be used in combination with other magic such as case-insensitive
> matching. Incompatible with :(glob) magic below.
>
> Global option --noglob-pathspecs is added to add :(literal) to
> all. This is very similar to --literal-pathspecs. It just does not
> disable pathspec magic. :(glob) magic overrides this global option.
>
> (*) you can always disable wildcards by quoting them using backslash,
> but that's inconvenient
Have you considered if it may be helpful to have a :(literal) magic
(or any magic in general) that applies only to the first N
characters of the pathspec pattern?
When you are in subdirectory and do a pathspec limited operation,
e.g.
cd Documentation && git ls-files "*.txt"
we internaly do an equivalent of this:
(1) first find out the "prefix", e.g. "Documentation/" in this
case;
(2) prepend the prefix to user-supplied pathspecs, e.g. yielding
"Documentation/*.txt" in this case; and
(3) use the resulting pathspecs to match against full pathnames
relative to the root of the working tree.
If the prefix had globbing character in it (e.g. we started in a
directory "D*cumentati*n" instead), we still should make sure that
that part matches literally, while allowing the globbing in
user-supplied part of the pathspec (e.g. "*.txt"). In the built in
code, you can work with the struct pathspec directly and mark the
entire prefix part with nowildcard_len field to match literally, but
if the above three-step logic needs to be implemented by a Porcelain
script like old days, they would need to quote glob specials in the
prefix part before appending user-supplied part to form the full
pathspec string.
I personally think we do not need to support something like this:
prefix=$(git rev-parse --show-prefix)
n=${#prefix}
pathspec=":(literal-$n)$prefix$1"
but other aspiring Porcelain script writers may disagree and would
want to have it. We can always solve it by giving them an easy and
uniform way to get the glob-quoted version of prefix to solve this
particular issue, i.e.
prefixq=$(git rev-parse --show-prefix-glob-quoted)
pathspec="$prefixq$1"
but magic that applies only to a substring may have other uses.
If you do not immediately think of any, let's not overengineer this.
Thanks.
^ permalink raw reply
* Re: [RFC] The design of new pathspec features
From: Duy Nguyen @ 2013-01-29 5:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpq0otw7y.fsf@alter.siamese.dyndns.org>
On Tue, Jan 29, 2013 at 12:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> New way to specify long pathspec magic
>> ======================================
>>
>> While testing the pathspec magic code, I grow tired of quoting :(glob)
>> every time because '(' is the start of a new shell. Which is one of
>> the reasons I introduce --[no]glob-pathspecs. Still I'd like a way to
>> specify long pathspec magic without quoting.
>
> Is this a real issue, though? Often interesting pathspecs do have
> shell globs in them and we have to quote them anyway.
:(icase) often won't (unless you combine with :(glob)). If we turn
grep's --max-depth feature into pathspec magic (feasible, just not
sure if it's actually useful), it won't need quoting either.
Even with :(glob), because of the complexity of the pathspec, it's
less likely to match anything and be expanded by bash, so no quoting
required.
>> How about making ":q/xxx/" an equivalence of ":(xxx)"?
>
> A moderately strong no from here.
--
Duy
^ permalink raw reply
* Re: [PATCH v2 0/3] transfer.hiderefs
From: Junio C Hamano @ 2013-01-29 5:13 UTC (permalink / raw)
To: git
In-Reply-To: <1359418412-26602-1-git-send-email-gitster@pobox.com>
Please take this as just a preview of early WIP. I think I may end
up doing moderate amount of refactoring as a preparatory step before
these patches, so nitpick-reviews are likely to become waste of
reviewer's time at this point.
^ permalink raw reply
* Re: [RFC] The design of new pathspec features
From: Junio C Hamano @ 2013-01-29 5:07 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <20130129043517.GA2878@duynguyen-vnpc.dek-tpc.internal>
Duy Nguyen <pclouds@gmail.com> writes:
> For those who haven't followed closely, some coming changes allow us
> to extend current pathspec syntax. We should soon be able to do
> case-insenstive matching for example, or introduce "**" wildcard that
> is currently used by gitignore. I just want to discuss about the new
> syntax and behavior.
>
> Many of these are already implemented in [1]. But I don't want you to
> bother with buggy code yet. I'll resend it soon after 1.8.2.
I think I agree with everything up to the "fnmatch(~FNM_PATHNAME)"
part, from a quick read.
Thanks for writing this up.
^ permalink raw reply
* Re: [RFC] The design of new pathspec features
From: Junio C Hamano @ 2013-01-29 5:05 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <20130129043517.GA2878@duynguyen-vnpc.dek-tpc.internal>
Duy Nguyen <pclouds@gmail.com> writes:
> Pathspec mnemonic
> =================
>
> Are :(literal) and :(glob) used often enough to deserve a short
> mnemonic (like :/ is equivalent to :(top))? Which symbols should be
> used?
I do not think we should discuss this before letting people gain
experience with various forms of magic; otherwise we would at best
end up with a concensus guess among uninformed.
> New way to specify long pathspec magic
> ======================================
>
> While testing the pathspec magic code, I grow tired of quoting :(glob)
> every time because '(' is the start of a new shell. Which is one of
> the reasons I introduce --[no]glob-pathspecs. Still I'd like a way to
> specify long pathspec magic without quoting.
Is this a real issue, though? Often interesting pathspecs do have
shell globs in them and we have to quote them anyway.
> How about making ":q/xxx/" an equivalence of ":(xxx)"?
A moderately strong no from here.
^ permalink raw reply
* [RFC] The design of new pathspec features
From: Duy Nguyen @ 2013-01-29 4:35 UTC (permalink / raw)
To: git
For those who haven't followed closely, some coming changes allow us
to extend current pathspec syntax. We should soon be able to do
case-insenstive matching for example, or introduce "**" wildcard that
is currently used by gitignore. I just want to discuss about the new
syntax and behavior.
Many of these are already implemented in [1]. But I don't want you to
bother with buggy code yet. I'll resend it soon after 1.8.2.
--literal-pathspecs
===================
This feature is added by Jeff to disable globbing for all pathspecs. I
want to push it a bit further: disable all pathspec magic. This means
even ":/" is treated literally when --literal-pathspecs is set.
Because the intent behind this, as I understand, is for scripting, it
makes sense to keep it as literal as possible.
:(literal) magic
================
This magic is for people who want simple no-globbing pathspec (*). It
can be used in combination with other magic such as case-insensitive
matching. Incompatible with :(glob) magic below.
Global option --noglob-pathspecs is added to add :(literal) to
all. This is very similar to --literal-pathspecs. It just does not
disable pathspec magic. :(glob) magic overrides this global option.
(*) you can always disable wildcards by quoting them using backslash,
but that's inconvenient
:(glob) magic
=============
This magic is for people who want globbing. However, it does _not_ use
the same matching mechanism the non-magic pathspec does today. It uses
wildmatch(WM_PATHNAME), which basically means '*' does not match
slashes and "**" does.
Global option --glob-pathspecs is added to add :(glob) to all
pathspec. :(literal) magic overrides this global option.
fnmatch without FNM_PATHNAME is deprecated
==========================================
With the two magic above, people can switch between literal and new
globbing. There is no way to regain current matching behavior once
--[no]glob-pathspecs is used. And I think that's a good thing. New
globbing is more powerful than the current one. At some point, I'd
like to switch the matching behavior when neither literal nor magic
pathspec is specified. Either:
- make it literal by default
- make it new globbing by default
Which is more often used should be come the default. The question is
which.
Pathspec mnemonic
=================
Are :(literal) and :(glob) used often enough to deserve a short
mnemonic (like :/ is equivalent to :(top))? Which symbols should be
used? We can only use non-alphanumeric here, and '(', ')', ':' and '/'
are taken. It should be friendly to UNIX shell, no quoting is
preferred.
Another magic will come soon: case-insensitive matching. We may want
to reserve a mnemonic symbol for it as well.
We may also want to reserve option shortcuts for --noglob-pathspecs
and --glob-pathspecs. I suspect they'll be used more often.
New way to specify long pathspec magic
======================================
While testing the pathspec magic code, I grow tired of quoting :(glob)
every time because '(' is the start of a new shell. Which is one of
the reasons I introduce --[no]glob-pathspecs. Still I'd like a way to
specify long pathspec magic without quoting.
How about making ":q/xxx/" an equivalence of ":(xxx)"? Any character
(except ',') following 'q' is used as separator (similar to s/// from
sed). This violates the guidelines set in glossary-content.txt (only
use non-alphanumeric).
Another step futher is remove support for ":(xxx)" in favor of
":q(xxx)". We can do it today because I don't think anybody is using
":(top)" (the only supported magic) yet.
[1] https://github.com/pclouds/git/tree/parse-pathspec
^ permalink raw reply
* Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
From: Bryan Turner @ 2013-01-29 4:16 UTC (permalink / raw)
To: git
In-Reply-To: <20130129041206.GA15442@google.com>
Interesting. I wonder if they've changed it recently. I only pointed
it out because a software product I'm working on had a bug because it
was building the URLs with "https://www..." and the resulting images
were showing as X's instead of avatars. We had to change the
implementation to use "https://secure..." to get the avatars to load
correctly. That's been ~8 months ago now, though, so maybe it's no
longer the case. It seems like it would be much more convenient if
they just changed the scheme.
Bryan
On 29 January 2013 15:12, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Bryan,
>
> Bryan Turner wrote:
>
>> This won't work correctly as-is. The secure URL for Gravatar is
>> "https://secure.gravatar.com"[1], not "https://www.gravatar.com".
>
> Odd. "https://www.gravatar.com/" also seems to work. I've put in a
> technical support query to find out what the Gravatar admins prefer.
>
> Thanks,
> Jonathan
^ permalink raw reply
* Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
From: Jonathan Nieder @ 2013-01-29 4:12 UTC (permalink / raw)
To: Bryan Turner; +Cc: git, Andrej E Baranov, Junio C Hamano
In-Reply-To: <CAGyf7-GJkKDWdykq8iv90tU3TUR5ZKUf2bQc9sJokbq-RFYBYg@mail.gmail.com>
Hi Bryan,
Bryan Turner wrote:
> This won't work correctly as-is. The secure URL for Gravatar is
> "https://secure.gravatar.com"[1], not "https://www.gravatar.com".
Odd. "https://www.gravatar.com/" also seems to work. I've put in a
technical support query to find out what the Gravatar admins prefer.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
From: Bryan Turner @ 2013-01-29 3:28 UTC (permalink / raw)
To: git
In-Reply-To: <7vtxq0u1v3.fsf@alter.siamese.dyndns.org>
This won't work correctly as-is. The secure URL for Gravatar is
"https://secure.gravatar.com"[1], not "https://www.gravatar.com".
[1] See the "Secure Requests" section on:
https://en.gravatar.com/site/implement/images/
On 29 January 2013 14:03, Junio C Hamano <gitster@pobox.com> wrote:
>
> Thanks; will queue.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
From: Junio C Hamano @ 2013-01-29 3:03 UTC (permalink / raw)
To: Andrej E Baranov; +Cc: git, jrnieder, giuseppe.bilotta, jnareb
In-Reply-To: <1359416492-8597-1-git-send-email-admin@andrej-andb.ru>
Thanks; will queue.
^ permalink raw reply
* Re: [PATCH] fixup! mergetools: simplify how we handle "vim" and "defaults"
From: Junio C Hamano @ 2013-01-29 3:02 UTC (permalink / raw)
To: David Aguilar; +Cc: John Keeping, git
In-Reply-To: <CAJDDKr5wsYqnBk+kvKj1qzUYKJBJ5nAiwMJZ=HpzPPgJf8BBTQ@mail.gmail.com>
David Aguilar <davvid@gmail.com> writes:
> On Mon, Jan 28, 2013 at 11:28 AM, John Keeping <john@keeping.me.uk> wrote:
>> ---
>> Junio, please can you squash this into f9924e5 on jk/mergetool,
>> providing that David is OK with that?
>
> This looks good to me.
Thanks for a quick response. Will squash this in and rebuild the
two affected branches.
^ permalink raw reply
* Re: [PATCH] fixup! mergetools: simplify how we handle "vim" and "defaults"
From: David Aguilar @ 2013-01-29 1:37 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, git
In-Reply-To: <20130128192856.GA7498@serenity.lan>
On Mon, Jan 28, 2013 at 11:28 AM, John Keeping <john@keeping.me.uk> wrote:
> ---
> Junio, please can you squash this into f9924e5 on jk/mergetool,
> providing that David is OK with that?
This looks good to me.
> The original change breaks custom mergetool by making changing the logic
> around default functions so that they are now only defined when the tool
> file exists in $MERGE_TOOLS_DIR but we need the default implementations
> when a custom tool is in use, which by definition means that the file
> doesn't exist in $MERGE_TOOLS_DIR.
>
> git-mergetool--lib.sh | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index 1d0fb12..211ffe5 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -48,15 +48,6 @@ valid_tool () {
> setup_tool () {
> tool="$1"
>
> - if ! test -f "$MERGE_TOOLS_DIR/$tool"
> - then
> - # Use a special return code for this case since we want to
> - # source "defaults" even when an explicit tool path is
> - # configured since the user can use that to override the
> - # default path in the scriptlet.
> - return 2
> - fi
> -
> # Fallback definitions, to be overriden by tools.
> can_merge () {
> return 0
> @@ -80,6 +71,15 @@ setup_tool () {
> echo "$1"
> }
>
> + if ! test -f "$MERGE_TOOLS_DIR/$tool"
> + then
> + # Use a special return code for this case since we want to
> + # source "defaults" even when an explicit tool path is
> + # configured since the user can use that to override the
> + # default path in the scriptlet.
> + return 2
> + fi
> +
> # Load the redefined functions
> . "$MERGE_TOOLS_DIR/$tool"
>
> --
> 1.8.1.1
--
David
^ permalink raw reply
* [PATCH v2 3/3] receive-pack: reject an attempt to update/delete a hidden ref
From: Junio C Hamano @ 2013-01-29 0:13 UTC (permalink / raw)
To: git
In-Reply-To: <1359418412-26602-1-git-send-email-gitster@pobox.com>
An attempt to update or delete a ref that is hidden from "git push"
is rejected. With this the server side can implement refs that are
only available for its own use, e.g. refs/pull/11/head used to hold
an incoming pull request at GitHub.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 3 ++-
builtin/receive-pack.c | 16 ++++++++++++++++
t/t5516-fetch-push.sh | 24 ++++++++++++++++++++++++
3 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 8e2853e..b7b407b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2063,7 +2063,8 @@ transfer.hiderefs::
more than one transfer.hiderefs configuration variables to
specify multiple prefix strings. A ref that has one of these
strings as its prefix is excluded, and is hidden from
- `git clone --mirror` and `git push :`.
+ `git clone --mirror` and `git push :`. An attempt to update
+ or delete a hidden ref by `git push` is rejected.
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 5ed40be..a8248d9 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -696,6 +696,20 @@ static int iterate_receive_command_list(void *cb_data, unsigned char sha1[20])
return -1; /* end of list */
}
+static void reject_updates_to_hidden(struct command *commands)
+{
+ struct command *cmd;
+
+ for (cmd = commands; cmd; cmd = cmd->next) {
+ if (cmd->error_string || !ref_is_hidden(cmd->ref_name))
+ continue;
+ if (is_null_sha1(cmd->new_sha1))
+ cmd->error_string = "deny deleting a hidden ref";
+ else
+ cmd->error_string = "deny updating a hidden ref";
+ }
+}
+
static void execute_commands(struct command *commands, const char *unpacker_error)
{
struct command *cmd;
@@ -712,6 +726,8 @@ static void execute_commands(struct command *commands, const char *unpacker_erro
0, &cmd))
set_connectivity_errors(commands);
+ reject_updates_to_hidden(commands);
+
if (run_receive_hook(commands, pre_receive_hook, 0)) {
for (cmd = commands; cmd; cmd = cmd->next) {
if (!cmd->error_string)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 6009372..8e8287a 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -1037,4 +1037,28 @@ test_expect_success 'push --prune refspec' '
! check_push_result $the_first_commit tmp/foo tmp/bar
'
+test_expect_success 'push to update a hidden ref' '
+ mk_test heads/master hidden/one hidden/two hidden/three &&
+ (
+ cd testrepo &&
+ git config transfer.hiderefs refs/hidden
+ ) &&
+
+ # push to unhidden ref succeeds normally
+ git push testrepo master:refs/heads/master &&
+ check_push_result $the_commit heads/master &&
+
+ # push to update a hidden ref should fail
+ test_must_fail git push testrepo master:refs/hidden/one &&
+ check_push_result $the_first_commit hidden/one &&
+
+ # push to delete a hidden ref should fail
+ test_must_fail git push testrepo master:refs/hidden/two &&
+ check_push_result $the_first_commit hidden/two &&
+
+ # idempotent push to update a hidden ref should fail
+ test_must_fail git push testrepo $the_first_commit:refs/hidden/three &&
+ check_push_result $the_first_commit hidden/three
+'
+
test_done
--
1.8.1.2.548.g0e4986f
^ permalink raw reply related
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