Benoit Person benoit.per...@gmail.com 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
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,
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
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
namespaces
On 25 September 2013 04:51, David Aguilar dav...@gmail.com wrote:
On Tue, Sep 24, 2013 at 2:07 PM, Jona Christopher Sahnwaldt
j...@sahnwaldt.de 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
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 Fri, Sep 20, 2013 at 10:51:55AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
On Tue, Sep 24, 2013 at 9:22 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Johan Herland wrote:
Signed-off-by: Johan Herland jo...@herland.net
Thanks.
What symptoms does this alleviate? Is this to allow configurations like
[hooks]
allowNonAscii = 1
and
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
--
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
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 checkout
Jona Christopher Sahnwaldt j...@sahnwaldt.de writes:
On 25 September 2013 04:51, David Aguilar dav...@gmail.com wrote:
On Tue, Sep 24, 2013 at 2:07 PM, Jona Christopher Sahnwaldt
j...@sahnwaldt.de wrote:
Hi,
maybe this has already been reported, but I didn't find it in the mail
archive.
On Wed, Sep 25, 2013 at 7:49 PM, Matthieu Moy matthieu@imag.fr 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
On Tue, Sep 24, 2013 at 10:35 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister j...@szakmeister.net
wrote:
[snip]
There's nothing objective about Nobody every (sic) agrees changes are
good. If it were true, no changes would get in.
It
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
n
On Wed, Sep 25, 2013 at 8:33 AM, John Szakmeister j...@szakmeister.net wrote:
On Tue, Sep 24, 2013 at 10:35 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister j...@szakmeister.net
wrote:
[snip]
There's nothing objective about Nobody
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
On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com 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
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
But let me help you; you can't mention one, because there isn't any.
Or because you didn't really look.
On Wed, Sep 25, 2013 at 10:13 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
But let me help you;
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 --oneline
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
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 power
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
Felipe Contreras felipe.contre...@gmail.com 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
On Wed, Sep 25, 2013 at 11:05 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com 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
Stefan Näwe stefan.naewe at 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
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 wrote:
Stefan Näwe stefan.naewe at 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
On Thu, Sep 26, 2013 at 1:29 AM, Matthieu Moy
matthieu@grenoble-inp.fr 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
On Wed, Sep 25, 2013 at 8:52 PM, Matthieu Moy
matthieu@grenoble-inp.fr 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], --);
+
Jona Christopher Sahnwaldt j...@sahnwaldt.de 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
(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
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 checkout
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
On 25 September 2013 21:12, Matthieu Moy matthieu@grenoble-inp.fr wrote:
Jona Christopher Sahnwaldt j...@sahnwaldt.de 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
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 adds some
Jonathan Nieder jrnie...@gmail.com 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
Hi,
On Wed, 25 Sep 2013, Jonathan Nieder wrote:
Wataru Noguchi wrote:
- actually file name is decoded.]
Jona Christopher Sahnwaldt j...@sahnwaldt.de 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
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 branch
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
--, and now
:
--
Jacky Alciné - PGP: 201999FC
http://jalcine.me
signature.asc
Description: This is a digitally signed message part.
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 be pruned.
Jonathan Nieder jrnie...@gmail.com 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
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
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 the
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
Jonathan Nieder jrnie...@gmail.com 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
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 decompress
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/technical/protocol-capabilities.txt | 10 ++
upload-pack.c | 16 +---
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/fetch-options.txt | 5 +
builtin/fetch.c | 10 ++
fetch-pack.c| 3 +++
fetch-pack.h| 1 +
t/t5510-fetch.sh| 13 +
transport.c
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-repack.txt | 6 +-
git-repack.sh| 8 +++-
t/t7700-repack.sh| 35 +++
3 files changed, 47 insertions(+), 2 deletions(-)
diff --git
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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 |
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
This is the only plumbing command that is controlled by
core.preferredPackVersion so far.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/technical/protocol-capabilities.txt | 4
builtin/receive-pack.c| 3 ++-
2 files changed, 6
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 the
Jonathan Nieder jrnie...@gmail.com writes:
@@ -684,7 +687,7 @@ svn-remote.name.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
On Thu, Sep 26, 2013 at 11:51 AM, Nicolas Pitre n...@fluxnic.net 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
62 matches
Mail list logo
