> * jx/relative-path-regression-fix (2013-09-20) 3 commits
> - Use simpler relative_path when set_git_dir
> - relative_path should honor dos-driver-prefix
> - test: use unambigous leading path (/foo) for mingw
>
> Waiting for the review to settle.
Is this V3, which is both fixing a regression
On Thu, Sep 26, 2013 at 11:51 AM, Nicolas Pitre wrote:
>> Multi-base tree support is not part of "packv4" capability. Let's see
>> if such support comes before the series is merged to master. If so we
>> can drop that line from protocol-capabilities.txt. Otherwise a new
>> capability can be added
On Thu, 26 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
> About the "packv4" capability in git protocol. I considered a more
> generic cap "packver=ver[,ver[,ver...]]" that represents all supported
> versions, with the order of preference from the first ver (most preferred)
> to the last (least preferred
Jonathan Nieder writes:
>> @@ -684,7 +687,7 @@ svn-remote..noMetadata::
>> +
>> This option can only be used for one-shot imports as 'git svn'
>> will not be able to fetch again without metadata. Additionally,
>> -if you lose your .git/svn/**/.rev_map.* files, 'git svn' will not
>> +if you lose
An ideal repository is v4 only, no v2 packs. Show pack v4 statistics
so people know if the repository is mixed with v2 and repack it. Note
that "in-pack" and "size-pack" include all pack versions, not just v2.
Only display v4 info when there are v4 packs. It's still experimental
so don't polute th
This is the only plumbing command that is controlled by
core.preferredPackVersion so far.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/technical/protocol-capabilities.txt | 4
builtin/receive-pack.c| 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-repack.txt | 6 +-
git-repack.sh| 8 +++-
t/t7700-repack.sh| 35 +++
3 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-repack.txt b/Docu
Contrary to the fetch direction, whether send-pack sends packv4 is
totally controlled by the server. This is in favor of lowering load at
the server side. More logic may be added later to allow the client to
stick to v2 even if the server requests v4.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
send
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-fetch-pack.txt| 4
Documentation/gitremote-helpers.txt | 3 +++
builtin/fetch-pack.c| 7 +++
remote-curl.c | 14 +-
t/t5551-http-fetch.sh | 9 +
tran
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-clone.txt | 4
builtin/clone.c | 19 +++
t/t5601-clone.sh| 12
3 files changed, 35 insertions(+)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 450f
This adds
- clone, fetch and repack learn --pack-version (backends also learn
new options, check out the patches for details)
- core.preferredPackVersion to specify the default pack version for
fetch, clone, repack and the receiver of push.
This config is supposed to be used by por
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 5 +
cache.h | 1 +
config.c | 5 +
environment.c| 1 +
4 files changed, 12 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ec57a15..6e703
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/technical/protocol-capabilities.txt | 10 ++
upload-pack.c | 16 +---
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/Documentation/technical/protocol-capabilities.txt
b
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/fetch-options.txt | 5 +
builtin/fetch.c | 10 ++
fetch-pack.c| 3 +++
fetch-pack.h| 1 +
t/t5510-fetch.sh| 13 +
transport.c
This will come handy for verifying binary files like .pack, .idx or
$GIT_DIR/index. For now the only supported command is "ntohl". This
command looks into the given file at the given offset, do ntohl() and
return the value in decimal.
More commands may be added later to decode varint, or decompres
Jonathan Nieder writes:
> Keshav Kini wrote:
>
>> I changed the wording of your first paragraph a bit according to what I
>> thought it meant. Does it still convey what you wanted to convey, and is
>> it still correct?
>>
>> Mapping between Subversion revision numbers and Git commit
>>
Hi,
I'm sorry resend email many times...
My GMail setting default to HTML format.
So mail sent to Git ML is rejected...
Thanks for your reply.
> If changing the optimization level turns out to be the right fix, I
> would prefer to see this change made in the Makefile
Keshav Kini wrote:
> I changed the wording of your first paragraph a bit according to what I
> thought it meant. Does it still convey what you wanted to convey, and is
> it still correct?
>
> Mapping between Subversion revision numbers and Git commit
> names. In a repository where
What's cooking in git.git (Sep 2013, #08; Wed, 25)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The fifth batch of topics are in 'master'
Jonathan Nieder writes:
> Taking a step back, the reader might wonder *why* he would want
> to run "git svn fetch" to rebuilt these .rev_map.* files, and what
> they are for.
>
> Perhaps there should be a separate REVISION MAP section describing
> this in more detail. Something as simple as
>
>
On Tue, 24 Sep 2013, Jeff King wrote:
> On Sat, Sep 21, 2013 at 08:42:26AM +0200, Michael Haggerty wrote:
>
> > I think it would be preferable if "--prune" would *not* affect tags, and
> > if there were an extra option like "--prune-tags" that would have to be
> > used explicitly to cause tags to
:
--
Jacky Alciné - PGP: 201999FC
http://jalcine.me
signature.asc
Description: This is a digitally signed message part.
Hi,
Matthieu Moy wrote:
> error: pathspec 'foo' did not match any file(s) known to git.
> error: pathspec 'bar' did not match any file(s) known to git.
> error: pathspec '--' did not match any file(s) known to git.
>
> This patch fixes it by walking through the argument list to find the
> "--", a
Hi,
Matthieu Moy wrote:
> The "--" notation disambiguates files and branches, but as a side-effect
> of the previous implementation, also disabled the branch auto-creation
> when $branch does not exist.
Hm. I am not sure that was just an implementation side-effect.
Normally 'git checkout --'
Jona Christopher Sahnwaldt writes:
> Yes, I think the rules for the "short form" (the guessing when there's
> no --) should be made simpler, or maybe the guessing should be dropped
> altogether. I don't know. I don't know git well enough to be able to
> be more specific. I just find the current b
Hi,
On Wed, 25 Sep 2013, Jonathan Nieder wrote:
> Wataru Noguchi wrote:
>
> > - actually file name is decoded.]
> >
> > %E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%201-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%A
Jonathan Nieder wrote:
> Keshav Kini wrote:
> > + tracking. If necessary, rebuild the .git/svn/\*\*/.rev_map.*
> > + files, given the requisite information exists in commit
> > + messages (see the svn.noMetadata config option for more
> > + information). The name of the [svn-remote "..."
Hi,
Keshav Kini wrote:
> The man page for `git svn` describes a situation in which "'git svn'
> will not be able to rebuild" your .git/svn/**/.rev_map files, but no
> mention is made of in what circumstances `git svn` *will* be able to do
> so, or how to get `git svn` to do so.
>
> This patch add
On 25 September 2013 21:12, Matthieu Moy wrote:
> Jona Christopher Sahnwaldt writes:
>
>> Hi everyone,
>>
>> tl;dr: The short form "git checkout foo" is a mess. There's simply too
>> much "DWIM" magic going on. There are no comprehensible rules how it
>> decides if "foo" is a pathspec or a refspe
The previous code was detecting the presence of "--" by looking only at
argument 1. As a result, "git checkout foo bar --" was interpreted as an
ambiguous file/revision list, and errored out with:
error: pathspec 'foo' did not match any file(s) known to git.
error: pathspec 'bar' did not match any
The "--" notation disambiguates files and branches, but as a side-effect
of the previous implementation, also disabled the branch auto-creation
when $branch does not exist.
A possible scenario is then:
git checkout $branch
=> fails if $branch is both a ref and a file, and suggests --
git checkou
Hi,
Michael S. Tsirkin wrote:
> Linus favors one-time use signed tags, e.g. for_linus.
> Unfortunately if I push to such a tag without -f,
> I get an error ("already exists").
> Would it make sense for there to be an option that makes it behave like
> a head, and allow fast-forward?
Nah, I think
(cc-ing the Git for Windows maintainers)
Hi,
Wataru Noguchi wrote:
> Git for Windows crashes when clone Japanese multibyte repository.
> - Japanese Base Encoding is Shift-JIS.
> - It happens Japanese multibyte directory name and too-long directory path
> - Linux(ex. Ubuntu 13.04 amd64) can clone
Jona Christopher Sahnwaldt writes:
> Hi everyone,
>
> tl;dr: The short form "git checkout foo" is a mess. There's simply too
> much "DWIM" magic going on. There are no comprehensible rules how it
> decides if "foo" is a pathspec or a refspec.
There is a very simple rule:
What's on the left hand
On Wed, Sep 25, 2013 at 8:52 PM, Matthieu Moy
wrote:
> @@ -925,7 +926,15 @@ static int parse_branchname_arg(int argc, const char
> **argv,
> return 1;
>
> arg = argv[0];
> - has_dash_dash = (argc > 1) && !strcmp(argv[1], "--");
> + has_dash_dash = 0;
> +
On Thu, Sep 26, 2013 at 1:29 AM, Matthieu Moy
wrote:
> Hi,
>
> Since 64a99eb47, "git gc" creates a lock file gc.pid while running. I
> just noticed that the file is never deleted. The locking mechanism
> works, but leaving these files around creates a minor annoyance.
>
> For example, I run "git g
Stefan Näwe wrote:
> Stefan Näwe atlas-elektronik.com> writes:
>> 6035d6aad8ca11954c0d7821f6f3e7c047039c8f is the first bad commit
>
> And to answer myself once more:
>
> That's fixed in
>
>6da8bdc fetch-pack: do not remove .git/shallow file when --depth is not
> specified"
>
> Sorry for all
Hi,
Since 64a99eb47, "git gc" creates a lock file gc.pid while running. I
just noticed that the file is never deleted. The locking mechanism
works, but leaving these files around creates a minor annoyance.
For example, I run "git gc" in all my repos from time to time (in a cron
job). It normally
Stefan Näwe atlas-elektronik.com> writes:
> Am 25.09.2013 16:47, schrieb Stefan Näwe:
> This is what it gives me if I use my script (slightly modified
> to also run make) with 'git bisect run':
>
> 6035d6aad8ca11954c0d7821f6f3e7c047039c8f is the first bad commit
And to answer myself once more:
On Wed, Sep 25, 2013 at 11:05 AM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> Last time I checked nothing has changed, the default remains
>> push.default=matching.
>
> LOL.
I'd take that as an admission that you don't have any examples of
important changes in the past two years, at leas
Hi everyone,
tl;dr: The short form "git checkout foo" is a mess. There's simply too
much "DWIM" magic going on. There are no comprehensible rules how it
decides if "foo" is a pathspec or a refspec.
On 25 September 2013 15:09, Matthieu Moy wrote:
> Jona Christopher Sahnwaldt writes:
>
>> On 25
Felipe Contreras writes:
> Last time I checked nothing has changed, the default remains
> push.default=matching.
LOL.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More ma
Git for Windows crashes when clone Japanese multibyte repository.
- Japanese Base Encoding is Shift-JIS.
- It happens Japanese multibyte directory name and too-long directory path
- Linux(ex. Ubuntu 13.04 amd64) can clone normally.
- example repository is here:
git clone https://github.com/wnoguch
On 2013-09-25 10:55, Ondřej Bílka wrote:
> On Wed, Sep 25, 2013 at 09:24:15AM +0200, Thomas Koch wrote:
>> Is there any explanation available of the different merrits and drawbacks of
>> the diff algorithms that Git supports?
>>
>> I'm not satisfied with the default diff but have enough processing
Am 25.09.2013 16:47, schrieb Stefan Näwe:
> Just a quick report since I don't have time to bisect now (will do later
> if no other gitster is faster...)
I'd marry 'git bisect' if I wasn't already... ;-)
This is what it gives me if I use my script (slightly modified to also run make)
with 'git bis
Am 25.09.2013 16:47, schrieb Stefan Näwe:
> Just a quick report since I don't have time to bisect now (will do later
> if no other gitster is faster...)
Seems to be somewhere between v1.8.3.1 (OK) and v1.8.3.2 (not OK) !!
>
> When I execute the below script 'git show' crashes. 'git log --onelin
On Wed, Sep 25, 2013 at 10:13 AM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy
>> wrote:
>>> Felipe Contreras writes:
>>>
But let me help you; you can't mention one, because there isn't any.
>>>
>>> Or because you didn't really look. Rea
Felipe Contreras writes:
> On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy
> wrote:
>> Felipe Contreras writes:
>>
>>> But let me help you; you can't mention one, because there isn't any.
>>
>> Or because you didn't really look. Read the release notes of every Git
>> release these days, there's a
On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> But let me help you; you can't mention one, because there isn't any.
>
> Or because you didn't really look. Read the release notes of every Git
> release these days, there's a big section about ongoing backward
>
Felipe Contreras writes:
> But let me help you; you can't mention one, because there isn't any.
Or because you didn't really look. Read the release notes of every Git
release these days, there's a big section about ongoing backward
incompatible changes.
--
Matthieu Moy
http://www-verimag.imag.
Just a quick report since I don't have time to bisect now (will do later
if no other gitster is faster...)
When I execute the below script 'git show' crashes. 'git log --oneline -2' gives
for example:
3808bade5b76c4663ac4a3f751dc9f1ed0b08f2e three
error: Could not read 1e8777edeb2b7e757f74c78
n
On Wed, Sep 25, 2013 at 8:33 AM, John Szakmeister wrote:
> On Tue, Sep 24, 2013 at 10:35 AM, Felipe Contreras
> wrote:
>> On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister
>> wrote:
> [snip]
>>> There's nothing objective about "Nobody every (sic) agrees changes are
>>> good". If it were tru
Duy Nguyen writes:
> has_dash_dash is calculated as (argc > 1) && !strcmp(argv[1], "--"),
> so when argc == 1, the has_dash_dash must be zero, the "&&
> !has_dash_dash" is redundant.
Yes, but I'd rather not have to read the detailed definition of
has_dash_dash to understand the code. With my ver
The alias was from René Scharfe's Google+ post [1]. For reference when
the Internet (or Google) is down:
While grep is an indispensable tool if you're working with text
files, some aspects of it could be improved. ack (or ack-grep, as
it's called on Debian) has a few nice ideas in this
On Tue, Sep 24, 2013 at 10:35 AM, Felipe Contreras
wrote:
> On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister
> wrote:
[snip]
>> There's nothing objective about "Nobody every (sic) agrees changes are
>> good". If it were true, no changes would get in.
>
> It is true, where by "changes" I mean "
On Wed, Sep 25, 2013 at 7:49 PM, Matthieu Moy wrote:
> static int parse_branchname_arg(int argc, const char **argv,
> int dwim_new_local_branch_ok,
> struct branch_info *new,
You may want to update the big comment block about all ca
Jona Christopher Sahnwaldt writes:
> On 25 September 2013 04:51, David Aguilar wrote:
>> On Tue, Sep 24, 2013 at 2:07 PM, Jona Christopher Sahnwaldt
>> wrote:
>>> Hi,
>>>
>>> maybe this has already been reported, but I didn't find it in the mail
>>> archive.
>>>
>>> If I understand correctly,
The "--" notation disambiguates files and branches, but as a side-effect
of the previous implementation, also disabled the branch auto-creation
when $branch does not exist.
A possible scenario is then:
git checkout $branch
=> fails if $branch is both a ref and a file, and suggests --
git checkou
--
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.kernel.org/majordomo-info.html
Hi!
Linus favors one-time use signed tags, e.g. for_linus.
Unfortunately if I push to such a tag without -f,
I get an error ("already exists").
Would it make sense for there to be an option that makes it behave like
a head, and allow fast-forward?
--
MST
--
To unsubscribe from this list: send the
On Tue, Sep 24, 2013 at 9:22 PM, Jonathan Nieder wrote:
> Johan Herland wrote:
>> Signed-off-by: Johan Herland
>
> Thanks.
>
> What symptoms does this alleviate? Is this to allow configurations like
>
> [hooks]
> allowNonAscii = 1
>
> and
>
> [hooks]
>
On Fri, Sep 20, 2013 at 10:51:55AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > My original question was going to be: why bother peeling at all if we
> > are just going to push the outer objects, anyway?
> >
> > And after staring at it, I somehow convinced myself that the answer was
>
On Wed, Sep 25, 2013 at 09:24:15AM +0200, Thomas Koch wrote:
> Is there any explanation available of the different merrits and drawbacks of
> the diff algorithms that Git supports?
>
> I'm not satisfied with the default diff but have enough processing power for
> a
> slower algorithm that might
On 25 September 2013 04:51, David Aguilar wrote:
> On Tue, Sep 24, 2013 at 2:07 PM, Jona Christopher Sahnwaldt
> wrote:
>> Hi,
>>
>> maybe this has already been reported, but I didn't find it in the mail
>> archive.
>>
>> If I understand correctly, after I clone a repo, I should be able to
>> sw
On Tue, Sep 24, 2013 at 09:22:32AM -0400, Marc Branchaud wrote:
> >If we instead moved to a default fetch refspec more like:
> >
> > [remote "origin"]
> > fetch = +refs/*:refs/remotes/origin/refs/*
>
> I'm all for such a change.
>
> You no doubt recall the lengthy discussion about remote ref
On Tue, Sep 24, 2013 at 12:06:43PM -0700, Jonathan Nieder wrote:
> Part of the underlying problem is that unlike 'git init', 'git clone'
> does not accept a --shared=(true|false|group|...) option. Worse, it
> does accept a --shared option, with a completely different meaning.
> No better option n
Is there any explanation available of the different merrits and drawbacks of
the diff algorithms that Git supports?
I'm not satisfied with the default diff but have enough processing power for a
slower algorithm that might produce diffs that better show the intention of the
edit.
Thank you, Th
Benoit Person writes:
> contrib/mw-to-git/git-remote-mediawiki.perl | 14 --
> contrib/mw-to-git/t/t9365-continuing-queries.sh | 23 +++
This version sounds all right. Thanks a lot,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this
68 matches
Mail list logo
