Steven Walter writes:
> If two processes are racing to create the same directory tree, they will
> both see that the directory doesn't exist, both try to mkdir(), and one
> of them will fail. This is okay, as we only care that the directory
> gets created. So, we add a check for EEXIST from mkd
Duy Nguyen writes:
> No, the literal strings are reparsed in path_exists() before being fed
> to read_tree_recursive.
Yuck. OK. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
Duy Nguyen writes:
> On Sun, Mar 17, 2013 at 12:34 PM, Junio C Hamano wrote:
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> This avoids unnecessary re-allocations and reinsertions. On webkit.git
>>> (i.e. about 182k inserts to the name hash table), this reduces about
>>> 100ms out of 3s user time.
>>>
Jeff King writes:
>> > [3/3]: upload-pack: load non-tip "want" objects from disk
>> >
>> > While investigating the bug, I found some weirdness around the
>> > stateless-rpc check_non_tip code. As far as I can tell, that code
>> > never actually gets triggered. It's not too surprisin
Ramkumar Ramachandra writes:
> How will adding remote.pushdefault have any
> impact, unless I explicitly remove this branch-specific remote
> configuration? Besides, without branch..remote configured, I
> can't even pull and expect changes to be merged.
If the triangle topology is the norm for
On Sat, Mar 16, 2013 at 03:06:22PM +0100, Michael Haggerty wrote:
> > refname = parse_ref_line(refline, sha1);
> > if (refname) {
> > - last = create_ref_entry(refname, sha1, flag, 1);
> > + /*
> > +* Older git did not
On Sat, Mar 16, 2013 at 02:50:56PM +0100, Michael Haggerty wrote:
> > @@ -39,14 +40,13 @@ static int handle_one_ref(const char *path, const
> > unsigned char *sha1,
> > return 0;
> >
> > fprintf(cb->refs_file, "%s %s\n", sha1_to_hex(sha1), path);
> > - if (is_tag_ref) {
> > -
On Sat, Mar 16, 2013 at 10:50:17PM -0700, Junio C Hamano wrote:
> I however wonder if the above implies it may make sense to add this
> on top? Perhaps it is not worth it, because it makes a difference
> only to a repository with annotated tags outside refs/tags hierarchy
> and still has the pack
Jeff King writes:
> The simplest fix would be to always unset the
> REF_KNOWS_PEELED flag for refs outside of refs/tags that do
> not have a peel line (if it has a peel line, we know it is
> valid, but we cannot assume a missing peel line means
> anything). But that loses an important optimizatio
On Sun, Mar 17, 2013 at 06:00:08AM +0530, Ramkumar Ramachandra wrote:
> >> +remote.pushdefault::
> >> + The remote to push to by default. Overrides the
> >> + branch-specific configuration `branch..remote`.
> >
> > It feels unexpected to see "I may have said while on this branch I
> > pus
On Sat, Mar 16, 2013 at 10:16:40PM -0700, Junio C Hamano wrote:
> > ... (I had several bug reports
> > within a few hours of deploying v1.8.1.5 on github.com)
>
> Nice to have a pro at the widely used site ;-) I often wish it had
> a mechanism to deploy the tip of 'master' or 'maint', or even 'n
On Sun, Mar 17, 2013 at 12:34 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> This avoids unnecessary re-allocations and reinsertions. On webkit.git
>> (i.e. about 182k inserts to the name hash table), this reduces about
>> 100ms out of 3s user time.
>>
>> Signed-off-by: Nguyễn Thái
Nguyễn Thái Ngọc Duy writes:
> This avoids unnecessary re-allocations and reinsertions. On webkit.git
> (i.e. about 182k inserts to the name hash table), this reduces about
> 100ms out of 3s user time.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
I think this is a very good idea, but I would prefer
On Sun, Mar 17, 2013 at 12:00 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Sat, Mar 16, 2013 at 12:56 AM, Junio C Hamano wrote:
>>> Nguyễn Thái Ngọc Duy writes:
>>>
@@ -232,11 +228,18 @@ static int path_exists(struct tree *tree, const char
*path)
static void parse_pa
Jeff King writes:
> This series fixes the issue I mentioned recently with upload-pack, where
> we might feed unparsed objects to the revision parser. The bug is in
> 435c833 (the tip of the jk/peel-ref topic), which is in v1.8.1 and up.
Good to see follow-up from a responsible contributor ;-)
>
Duy Nguyen writes:
> On Sat, Mar 16, 2013 at 12:56 AM, Junio C Hamano wrote:
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> @@ -232,11 +228,18 @@ static int path_exists(struct tree *tree, const char
>>> *path)
>>> static void parse_pathspec_arg(const char **pathspec,
>>> struct archive
Peter Eisentraut writes:
> git pull passed -q and -v only to git merge, but they can be useful for
> git rebase as well, so pass them there, too. In particular, using -q
> shuts up the "Already up-to-date." message. Add test cases to prove it.
>
> Signed-off-by: Peter Eisentraut
> ---
Looks q
Torsten Bögershausen writes:
>> Or we can be more explicit and say
>>
>> # It took 2.58 seconds to search for untracked files. 'status -uno'
>> # may speed it up, but you have to be careful not to forget to add
>> # new files yourself (see 'git help status').
>>
> Thanks, that looks good for m
On Sat, Mar 16, 2013 at 2:51 PM, Kacper Kornet wrote:
> git-rev-parse interprets string in string@{upstream} as a name of
> a branch not a ref. For example refs/heads/master@{upstream} looks
> for an upstream branch that is merged by git-pull to ref
> refs/heads/refs/heads/master not to refs/heads
This avoids unnecessary re-allocations and reinsertions. On webkit.git
(i.e. about 182k inserts to the name hash table), this reduces about
100ms out of 3s user time.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
nd/read-directory-recursive-optim reduces the number of input (from
182k to 11k on webki
On Sat, Mar 16, 2013 at 06:11:32PM -0700, Shawn O. Pearce wrote:
> > That seems kind of crazy to me. It's generating an HTTP 200 just to tell
> > us the credentials are wrong. Which kind of makes sense; it's the only
> > way to convince the git client to show a custom message when it aborts
> > (r
JGit has merged the bitmap work Colby and I were working on[1] and
plans to ship it in JGit 2.4. The bitmaps are now stored in a separate
".bitmap" file alongside of a pack, making the entire system
backward-compatible with git-core.
If you have Java and Maven installed you can try this out locall
On Fri, Mar 15, 2013 at 4:59 AM, Jeff King wrote:
> I tried pushing to a repository at Google Code for the first time today,
> and I encountered some weird behavior with respect to asking for
> credentials.
>
> If I use the url "https://code.google.com/r/repo/";, everything works; I
> get prompted
Sorry about the horribly late response- I just got around to
re-rolling this, and had a doubt.
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>> index 9b11597..82a4a78 100644
>> --- a/Documentation/config.txt
>> +++ b/Do
On Sat, 16 Mar 2013, Jeff King wrote:
But are we correct in assuming that curl will barf if it gets a redirect to
an ssl-enabled protocol? My testing seems to say yes:
Ah yes. If it switches over to an SSL-based protocol it will pretty much
require that it had been initialized previously.
W
On 03/16/13 09:14, Sebastian Schuberth wrote:
On 15.03.2013 21:11, Joshua Jensen wrote:
Yes, you should grab the msysGit (the Git for Windows build
environment) [2], tweak it to include the new OpenSSH binary, ensure it
builds and works OK and then send a pull request (or post your patchset
to
On Sat, Mar 16, 2013 at 9:49 PM, Patrik Gornicz
wrote:
> Any idea as to when this mingwGitDevEnv project will be mature enough to use
> as a replacement for msysgit? One of the reasons I gave up trying to tweak
Due to a lack of contributors this is taking longer than I
anticipated. But I realize
In some cases, the default branch background color (green) isn't
an optimal choice, thus it can be difficult to read.
This provides a way for the user to customize the color used to
fill the rectangle around the branch name, by choosing another
one from the "Preferences" dialog.
The default behav
If two processes are racing to create the same directory tree, they will
both see that the directory doesn't exist, both try to mkdir(), and one
of them will fail. This is okay, as we only care that the directory
gets created. So, we add a check for EEXIST from mkdir, and continue if
the director
git-rev-parse interprets string in string@{upstream} as a name of
a branch not a ref. For example refs/heads/master@{upstream} looks
for an upstream branch that is merged by git-pull to ref
refs/heads/refs/heads/master not to refs/heads/master. However the
documentation could misled a user to belie
Ah right yes, sorry the HTTPS version needs a username the HTTP
version does not. Please use:
http://svn.code.sf.net/p/exist/code
On 16 March 2013 17:13, Eric Wong wrote:
> Adam Retter wrote:
>> If your able, any idea of when you might be able to take a look at the
>> bug? Our svn repo is publi
Http:// should provide access without password ..
--
Dannes Wessels
On 16 mrt. 2013, at 18:13, Eric Wong wrote:
> Adam Retter wrote:
>> If your able, any idea of when you might be able to take a look at the
>> bug? Our svn repo is publicly available for all.
>
> svn ls https://svn.code.sf
The only caller of diagnose_invalid_sha1_path() extracts a substring from
an object name by creating a NUL-terminated copy of the interesting part.
Add a length parameter to the function and thus avoid the need for an
allocation, thereby simplifying the code.
Signed-off-by: Rene Scharfe
---
sha1
Commit 27f76a2b ('push: switch default from "matching" to "simple"',
04-01-2013) removed the last use of the 'advice_push_non_ff_default'
variable, along with the advice message which it used to suppress.
Remove the 'advice_push_non_ff_default' variable definition, along
with the now redundant ad
Adam Retter wrote:
> If your able, any idea of when you might be able to take a look at the
> bug? Our svn repo is publicly available for all.
svn ls https://svn.code.sf.net/p/exist/code/trunk
...Is asking me for username
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bo
As a follow-up to 60d24dd25 (Makefile: fold XDIFF_H and VCSSVN_H into
LIB_H), let the unconditional additions to LIB_H form a single sorted
list. Also drop the duplicate entry for xdiff/xdiff.h, which was easy
to spot after sorting.
Signed-off-by: Rene Scharfe
---
Makefile | 29 +---
Junio C Hamano writes:
> Karsten Blees writes:
>
>> However, AFAIK inotify doesn't work recursively, so the daemon
>> would at least have to track the directory structure to be able to
>> register / unregister inotify handlers as directories come and go.
>
> Yes, and you would need one inotify p
[+Cc Eric]
Adam Retter writes:
> $ git svn init -t tags -b stable -T trunk
> file:///home/ec2-user/svn-rsync/code new-git-repo
> $ cd new-git-repo
> $ git config svn-remote.svn.preserve-empty-dirs true
> $ git config svn-remote.svn.rewriteRoot https://svn.code.sf.net/p/exist/code
> $ git svn fet
ACK, with one ignorable comment.
Michael
On 03/16/2013 10:01 AM, Jeff King wrote:
> Older versions of pack-refs did not write peel lines for
> refs outside of refs/tags. This meant that on reading the
> pack-refs file, we might set the REF_KNOWS_PEELED flag for
> such a ref, even though we do not
Looks good aside from a couple of minor points mentioned below.
On 03/16/2013 10:01 AM, Jeff King wrote:
> When we pack an annotated tag ref, we write not only the
> sha1 of the tag object along with the ref, but also the sha1
> obtained by peeling the tag. This lets readers of the
> pack-refs fil
On 03/16/2013 10:34 AM, Jeff King wrote:
> On Sat, Mar 16, 2013 at 09:48:42AM +0100, Michael Haggerty wrote:
>
>> My patch series is nearly done. I will need another day or two to
>> review and make it submission-ready, but I wanted to give you an idea of
>> what I'm up to and I could also use yo
On 15.03.2013 21:11, Joshua Jensen wrote:
Yes, you should grab the msysGit (the Git for Windows build
environment) [2], tweak it to include the new OpenSSH binary, ensure it
builds and works OK and then send a pull request (or post your patchset
to the msysgit mailing list [3].
Wow, we can do
On Sat, Mar 16, 2013 at 6:41 PM, Jeff King wrote:
> On Fri, Mar 15, 2013 at 03:42:40PM -0700, Stefan Zager wrote:
>
>> We have uncovered a regression in this commit:
>>
>> b8a2486f1524947f232f657e9f2ebf44e3e7a243
What version did you test? We used to have problems with multithreaded
index-pack on
>> fatal: Not a valid object name
>> ls-tree -z ./webapp/api/: command returned error: 128
>>
>> I have no idea what this means, or how to fix this.
>> We are using Git version 1.8.1.GIT on Amazon EC2 Linux.
>>
>> Any suggestions please?
>
> You might've hit a bug in branch detection, but I'd have
On Fri, Mar 15, 2013 at 05:23:27PM +0100, Daniel Stenberg wrote:
> >Thanks, then we should stick to starting from ALL like everybody
> >else who followed the suggestion in the documentation. Do you have
> >recommendations on the conditional dropping of SSL?
>
> Not really, no.
>
> SSL initing i
On Fri, Mar 15, 2013 at 03:42:40PM -0700, Stefan Zager wrote:
> We have uncovered a regression in this commit:
>
> b8a2486f1524947f232f657e9f2ebf44e3e7a243
>
> The symptom is that 'git fetch' dies with:
>
> error: index-pack died of signal 10
> fatal: index-pack failed
>
> I have only been abl
It is a long-time security feature that upload-pack will not
serve any "want" lines that do not correspond to the tip of
one of our refs. Traditionally, this was enforced by
checking the objects in the in-memory hash; they should have
been loaded and received the OUR_REF flag during the
advertiseme
When upload-pack receives a "want" line from the client, it
adds it to an object array. We call lookup_object to find
the actual object, which will only check for objects already
in memory. This works because we are expecting to find
objects that we already loaded during the ref advertisement.
We
When we receive a "have" line from the client, we want to
load the object pointed to by the sha1. However, we are
careful to do:
o = lookup_object(sha1);
if (!o || !o->parsed)
o = parse_object(sha1);
to avoid loading the object from disk if we have already
seen it. However, since c
This series fixes the issue I mentioned recently with upload-pack, where
we might feed unparsed objects to the revision parser. The bug is in
435c833 (the tip of the jk/peel-ref topic), which is in v1.8.1 and up.
The fix should go to maint. The bug breaks shallow clones from
repositories with pac
Hello, I'm new to this list and using GIT on MacOS 10.8:
$ /usr/local/git/bin/git --version
git version 1.7.4.1
I've caught some small issues when using GIT GUI (French version):
- when GIT GUI just launched, the menu "Dépôt" (repository I guess) and Apple
are disabled
- when opening preferences
On Sat, Mar 16, 2013 at 09:48:42AM +0100, Michael Haggerty wrote:
> My patch series is nearly done. I will need another day or two to
> review and make it submission-ready, but I wanted to give you an idea of
> what I'm up to and I could also use your feedback on some points.
I was just sending
On Sat, Mar 16, 2013 at 2:24 AM, Nguyễn Thái Ngọc Duy wrote:
> %>(N,trunc) truncates the righ part after N columns and replace the
> last two letters with "..". ltrunc does the same on the left. mtrunc
> cuts the middle out.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
s/righ/right/
> Documen
Older versions of pack-refs did not write peel lines for
refs outside of refs/tags. This meant that on reading the
pack-refs file, we might set the REF_KNOWS_PEELED flag for
such a ref, even though we do not know anything about its
peeled value.
The previous commit updated the writer to always pee
When we pack an annotated tag ref, we write not only the
sha1 of the tag object along with the ref, but also the sha1
obtained by peeling the tag. This lets readers of the
pack-refs file know the peeled value without having to
actually load the object, speeding up upload-pack's ref
advertisement.
These patches fix the issue with peel-ref noticed recently by Michael
(namely that we fail to correctly peel packed refs outside of
refs/tags). The problem has been there since we added peeling support
to pack-refs, but traditionally "show-ref -d" was the only caller that
actually triggered the is
On 03/14/2013 02:40 PM, Jeff King wrote:
> Hmph. I coincidentally ran across another problem with 435c833 today.
> Try this:
> [...]
>
> But that's somewhat off-topic for this discussion. I'll look into it
> further and try to make a patch later today or tomorrow.
>
> On Thu, Mar 14, 2013 at 12:2
On 15.03.13 22:59, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> Thanks, that looks good to me:
>>
>> # It took 2.58 seconds to enumerate untracked files.
>> # Consider the -u option for a possible speed-up?
>>
>> But:
>> If I follow the advice as is given and use "git status -u", the
58 matches
Mail list logo
