On Mon, Aug 5, 2013 at 11:02 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
Is the untold
and obvious-to-those-who-are-familiar-with-this-codepath assumption
that it is guaranteed that there is at most one */clone/.hg under
shared_path?
No, there is no
Antoine Pelisse apeli...@gmail.com writes:
On Mon, Aug 5, 2013 at 11:02 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
Is the untold
and obvious-to-those-who-are-familiar-with-this-codepath assumption
that it is guaranteed that there is at most one
Thanks. Queued this at the tip of 'pu'. There seem to be some
fallouts found in the test suite, though.
--
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
Am 8/5/2013 16:23, schrieb Duy Nguyen:
close() is added in commit_lock_file(), before rename(), by 4723ee9
(Close files opened by lock_file() before unlinking. - 2007-11-13),
which is needed by Windows. But doesn't that create a gap between
close() and rename() on other platforms where another
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
[...]
The other comments mostly make sense.
After reading what the whole function does, I think the purpose of
this function is to take gc-lock (with optionally force). Perhaps a
name along the lines of lock_gc,
In Perforce, View setting of p4 client can describe
-//depot/project/files/*.xls //client/project/files/*.xls
to exclude Excel files.
But git p4 --use-client-spec cannot support '*'.
In git-p4.py, map_in_client method analyzes View setting and return
client file path.
So I modify the method to
Junio C Hamano wrote:
After reading what the whole function does, I think the purpose of
this function is to take gc-lock (with optionally force). Perhaps a
name along the lines of lock_gc, gc_lock, lock_repo_for_gc,
would be more appropriate.
The whole point of this exercise is to _not_
On Tue, Aug 6, 2013 at 8:36 AM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
Quoting that part I was asking about again:
+# check and upgrade old organization
+hg_path = os.path.join(shared_path, '.hg')
+if
Junio C Hamano:
Indeed.
Thanks. Testcases are good, but not if they don't actually catch the
bug one has just introduced :-)
-- 8 --
Subject: [PATCH] commit: typofix for xxFFF[EF] check
We wanted to catch all codepoints that ends with FFFE and ,
not with 0FFFE and 0.
Noticed and
On Tue, Aug 6, 2013 at 1:41 PM, Johannes Sixt j.s...@viscovery.net wrote:
Am 8/5/2013 16:23, schrieb Duy Nguyen:
close() is added in commit_lock_file(), before rename(), by 4723ee9
(Close files opened by lock_file() before unlinking. - 2007-11-13),
which is needed by Windows. But doesn't that
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@inf.ethz.ch writes:
Junio C Hamano gits...@pobox.com writes:
* tr/log-full-diff-keep-true-parents (2013-08-01) 1 commit
- log: use true parents for diff even when rewriting
Output from git log --full-diff -- pathspec looked
On Mon, Aug 5, 2013 at 10:52 AM, Junio C Hamano gits...@pobox.com wrote:
Brian Gernhardt br...@gernhardtsoftware.com writes:
It used to be that APPLE_COMMON_CRYPTO did nothing when BLK_SHA1 was
set. But APPLE_COMMON_CRYPTO is now used for more than just SHA1 (see
3ef2bca) so make sure that
On Mon, Aug 5, 2013 at 11:00 AM, Junio C Hamano gits...@pobox.com wrote:
Brian Gernhardt br...@gernhardtsoftware.com writes:
compat/apple-common-crypto.h uses die() in one of its macros, but was
included in git-compat-util.h before the definition of die.
Fix by simply moving the relevant
On Mon, Aug 5, 2013 at 11:44 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Sun, Aug 4, 2013 at 12:26 AM, brian m. carlson
sand...@crustytoothpaste.net wrote:
The test file that the UTF-16 rejection test looks for is missing, but this
went
unnoticed
On Tue, Aug 6, 2013 at 9:38 AM, Ramkumar Ramachandra artag...@gmail.com wrote:
+ Garbage collect using a pseudo logarithmic packfile
maintenance
+ approach. This approach attempts to minimize packfile churn
+ by keeping several generations of varying
Now that the variables are readin by OPT_BOOL, which makes sure
to have the values being 0 or 1 after reading, we do not need
the double negation to map any other value to 1 for integer
variables.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/branch.c | 3 ++-
This is a re-roll of [1] which teaches git-blame to accept multiple -L
ranges. It is built atop [6] (es/blame-L-more in 'pu').
The series is longer than expected since it includes a few more cleanup
patches beyond those already posted separately [2], [3], [4], [5], [6];
and because it implements
Standard practice in Git documentation is for each variation of an
option (such as: -p / --porcelain) to be placed on its own line in the
OPTIONS table. The -L option does not follow suit. It cuddles -L
start,end:file and -L :regex:file, separated by a comma.
This is inconsistent and potentially
Range specification -L/RE/ for blame/log unconditionally begins
searching at line one. Mailing list discussion [1] suggests that, in the
presence of multiple -L options, -L/RE/ should search relative to the
endpoint of the previous -L range, if any.
Teach the parsing machinery underlying blame's
The -L/RE/ option of blame/log searches from the end of the previous -L
range, if any. Add new notation -L^/RE/ to override this behavior and
search from start of file.
The new ^/RE/ syntax is valid only as the start argument of
-Lstart,end. The end argument, as usual, is relative to start.
For consistency with -L/RE/, teach -L:RE to search relative to the end
of the previous -L range, if any.
The new behavior invalidates one test in t4211 which assumes that -L:RE
begins searching at start of file. This test will be resurrected in a
follow-up patch which teaches -L:RE how to
Since inception, git-blame -L has been documented as accepting 1-based
line numbers. When handed a line number less than 1, -L's behavior is
undocumented and undefined; it's also nonsensical and should be
diagnosed as an error. Do so.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
blame/log documentation describes -L option as:
-Lstart,end
-L:regex
start and end can take one of these forms:
* number
* /regex/
* +offset or -offset
* :regex
which is incorrect and confusing since :regex is not one of the valid
forms of start or end; in fact, it must
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
t/annotate-tests.sh | 32
1 file changed, 32 insertions(+)
diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh
index ce5b8ed..77083d9 100644
--- a/t/annotate-tests.sh
+++ b/t/annotate-tests.sh
@@ -271,6
git-blame is slated to accept multiple -L ranges. git-log already
accepts multiple -L's but its implementation of range-set, which
organizes and normalizes -L ranges, is private. Publish the small
subset of range-set API which is needed for git-blame multiple -L
support.
Signed-off-by: Eric
This is complicated slightly by having to remember the previous -L range
for each file specified via -Lrange:file.
The existing implementation coalesces ranges for each file as each -L is
parsed which makes it impossible to refer back to the previous -L range
for any particular file. Re-implement
The -L:RE option of blame/log searches from the end of the previous -L
range, if any. Add new notation -L^:RE to override this behavior and
search from start of file.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/line-range-format.txt | 1 +
line-range.c
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/blame-options.txt | 8 +---
Documentation/git-blame.txt | 10 +++---
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index
Option -L/RE/ of blame/log now searches relative to the previous -L
range, if any. Document this.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/line-range-format.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
git-blame accepts only a single -L option or none. Clients requiring
blame information for multiple disjoint ranges are therefore forced
either to invoke git-blame multiple times, once for each range, or only
once with no -L option to cover the entire file, both of which can be
costly. Teach
Hi,
I just got the following error message:
dak@lola:/usr/local/tmp/lilypond$ git rebase -i
Waiting for Emacs...
error: could not apply 16de9d2... Make tempo range \tempo 20~30 be input as
\tempo 20-30 instead
When you have resolved this problem, run git rebase --continue.
If you prefer to
David Kastrup wrote:
As you can see, the first message starting with error: could not apply
outputs a reasonable rendition of the commit summary line. However, the
final Could not apply message (starting with a capital C) converts
instances of \t to a tab.
To get you started:
$ git grep
David Kastrup d...@gnu.org writes:
Could not apply 16de9d2... Make tempo range empo 20~30 be input as empo
20-30 instead
Indeed. The source of the problem is that our die shell function
interprets \t (because it uses echo).
A simple fix would be this:
diff --git a/git-sh-setup.sh
Jeff King p...@peff.net writes:
@@ -170,6 +172,20 @@ static struct ref *get_ref_map(struct transport
*transport,
rm-fetch_head_status = FETCH_HEAD_MERGE;
if (tags == TAGS_SET)
get_fetch_map(remote_refs, tag_refspec, tail, 0);
+
+
Thomas Rast tr...@inf.ethz.ch writes:
So while I do understand why sometimes you wish to see full diff
git log --full-diff -- pathspec to match output from git show
without pathspec, I am not sure doing it unconditionally and by
default like your patch does is the best way to go.
I'm
Matthieu Moy matthieu@grenoble-inp.fr writes:
David Kastrup d...@gnu.org writes:
Could not apply 16de9d2... Make tempo range empo 20~30 be input as
empo 20-30 instead
Indeed. The source of the problem is that our die shell function
interprets \t (because it uses echo).
A simple fix
David Kastrup d...@gnu.org writes:
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 7a964ad..97258d5 100644
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -53,7 +53,7 @@ die () {
die_with_status () {
status=$1
shift
- echo 2 $*
+ printf 2 %s\n $*
Stefan Beller stefanbel...@googlemail.com writes:
On 08/06/2013 08:39 AM, Junio C Hamano wrote:
Thanks. Queued this at the tip of 'pu'. There seem to be some
fallouts found in the test suite, though.
Thanks. I am sorry for forgetting 'make test' before sending patches.
And the test
Duy Nguyen pclo...@gmail.com writes:
The intention was UTF-16 is not supported yet but we want to. But I
don't think we (at least I) will put any effort on that front to allow
NUL in commit message, so the patch, as in we do not support UTF-16,
is fine.
Agreed. Here is what I queued.
-- 8
David Aguilar dav...@gmail.com writes:
I tested the tip of da/darwin (pu) w/ and w/out BLK_SHA1.
Tested-by: David Aguilar dav...@gmail.com
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
Am 04.08.2013 23:29, schrieb Fredrik Gustafsson:
On Sun, Aug 04, 2013 at 07:34:48PM +0200, Jens Lehmann wrote:
But we'll have to use sm_path here (like everywhere else in the
submodule script), because we'll run into problems under Windows
otherwise (see 64394e3ae9 for details). Apart from
Duy Nguyen pclo...@gmail.com writes:
On Tue, Aug 6, 2013 at 9:38 AM, Ramkumar Ramachandra artag...@gmail.com
wrote:
+ Garbage collect using a pseudo logarithmic packfile
maintenance
+ approach. This approach attempts to minimize packfile churn
+
Ramkumar Ramachandra artag...@gmail.com writes:
So, it's the shell script. Now, read about shell escaping [1] and
submit a patch.
This is not about shell escaping at all. I think the message is fed
to echo as-is, or to printf as its first parameter.
--
To unsubscribe from this list: send the
Matthieu Moy matthieu@grenoble-inp.fr writes:
David Kastrup d...@gnu.org writes:
Could not apply 16de9d2... Make tempo range empo 20~30 be input as empo
20-30 instead
Indeed. The source of the problem is that our die shell function
interprets \t (because it uses echo).
A simple
Commit a2cb86 (git_mkstemps: correctly test return value of open(),
12 Jul 2013) fixes a bug regarding testing the return of an open()
call for success/failure. Add a testsuite test for that fix. The
test exercises a situation where that open() is known to return 0.
Signed-off-by: Dale Worley
wor...@alum.mit.edu (Dale R. Worley) writes:
Commit a2cb86 (git_mkstemps: correctly test return value of open(),
12 Jul 2013) fixes a bug regarding testing the return of an open()
call for success/failure. Add a testsuite test for that fix. The
test exercises a situation where that open()
At least GNU echo interprets backslashes in its arguments.
This triggered at least one bug: the error message of rebase -i was
turning \t in commit messages into actual tabulations. There may be
others.
Using printf '%s\n' instead avoids this bad behavior, and is the form
used by the say
Translate 5 new messages came from git.pot update in b8ecf23
(l10n: git.pot: v1.8.4 round 2 (5 new, 3 removed)).
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
po/de.po | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/po/de.po b/po/de.po
index
---
This is a first draft of a patch that clarifies a number of points
about how patches should be formatted that have tripped me up. I have
re-filled a few of the paragraphs, which makes it hard to see from the
diff what I've changed. This listing shows the changed words between
{ ... }:
On Tue, Aug 6, 2013 at 9:07 AM, Stefan Beller
stefanbel...@googlemail.com wrote:
Now that the variables are readin by OPT_BOOL, which makes sure
Do you mean s/readin/read in/ ?
Or should it be s/readin/set/ ?
to have the values being 0 or 1 after reading, we do not need
the double negation
From: Junio C Hamano gits...@pobox.com
Thanks. I thought I've already queued
Message-ID: 7vfvuokpr0@alter.siamese.dyndns.org
aka
http://article.gmane.org/gmane.comp.version-control.git/231680
which tests
git commit --allow-empty -m message -
My mistake... I've been so
git commit --allow-empty -m message -
Though as of [fb56570] Sync with maint to grab trivial doc fixes,
that test doesn't fail for me if I revert to
fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode);
if (fd 0)
return fd;
I haven't
Currently using git mv on a submodule moves the submodule's work tree in
that of the superproject. But the submodule's path setting in .gitmodules
is left untouched, which is now inconsistent with the work tree and makes
git commands that rely on the proper path - name mapping (like status and
Currently using git rm on a submodule removes the submodule's work tree
from that of the superproject and the gitlink from the index. But the
submodule's section in .gitmodules is left untouched, which is a leftover
of the now removed submodule and might irritate users (as opposed to the
setting
wor...@alum.mit.edu (Dale R. Worley) writes:
---
This is a first draft of a patch that clarifies a number of points
about how patches should be formatted that have tripped me up. I have
re-filled a few of the paragraphs, which makes it hard to see from the
diff what I've changed. This
Matthieu Moy matthieu@grenoble-inp.fr writes:
From 7962ac8d8f2cbc556f669fd97487f9d70edc4ea1 Mon Sep 17 00:00:00 2001
From: Matthieu Moy matthieu@imag.fr
Date: Tue, 6 Aug 2013 19:13:03 +0200
Subject: [PATCH] die_with_status: use printf '%s\n', not echo
At least GNU echo interprets
David Kastrup d...@gnu.org writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
From 7962ac8d8f2cbc556f669fd97487f9d70edc4ea1 Mon Sep 17 00:00:00 2001
From: Matthieu Moy matthieu@imag.fr
Date: Tue, 6 Aug 2013 19:13:03 +0200
Subject: [PATCH] die_with_status: use printf '%s\n', not
On 08/06/2013 08:46 PM, Eric Sunshine wrote:
On Tue, Aug 6, 2013 at 9:07 AM, Stefan Beller
stefanbel...@googlemail.com wrote:
Now that the variables are readin by OPT_BOOL, which makes sure
Do you mean s/readin/read in/ ?
Or should it be s/readin/set/ ?
to have the values being 0 or 1
Now that the variables are set by OPT_BOOL, which makes sure
to have the values being 0 or 1 after parsing, we do not need
the double negation to map any other value to 1 for integer
variables.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/branch.c | 3 ++-
wor...@alum.mit.edu (Dale R. Worley) writes:
git commit --allow-empty -m message -
Though as of [fb56570] Sync with maint to grab trivial doc fixes,
that test doesn't fail for me if I revert to
fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode);
if (fd 0)
Thanks, will replace the top two commits and queue. Looks like we
are getting ready for 'next'?
--
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
+ for (range_i = ranges.nr; range_i 0; --range_i) {
+ const struct range *r = ranges.ranges[range_i - 1];
+ long bottom = r-start;
+ long top = r-end;
+ struct blame_entry *next = ent;
+ ent = xcalloc(1, sizeof(*ent));
+
Eric Sunshine sunsh...@sunshineco.com writes:
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
With the previous step, what this one does is fairly obvious and
straight-forward. Looking good ;-)
builtin/blame.c | 5 -
t/annotate-tests.sh | 20
2
On Tue, Aug 06, 2013 at 09:28:28AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
@@ -170,6 +172,20 @@ static struct ref *get_ref_map(struct transport
*transport,
rm-fetch_head_status = FETCH_HEAD_MERGE;
if (tags == TAGS_SET)
Eric Sunshine sunsh...@sunshineco.com writes:
Range specification -L/RE/ for blame/log unconditionally begins
searching at line one. Mailing list discussion [1] suggests that, in the
presence of multiple -L options, -L/RE/ should search relative to the
endpoint of the previous -L range, if
Jeff King p...@peff.net writes:
Two reasons:
OK, both boils down to Junio did not consider 'master:foobar'
case.
Thanks; it makes sense now.
--
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
Eric Sunshine sunsh...@sunshineco.com writes:
Each constructed blame_entry must own a reference to the suspect.
o-refcnt should equal the number of blame_entries. At construction, a
'struct origin' has refcnt 1. In the original code, which supported
only a single initial range (blame_entry),
On Tue, Aug 06, 2013 at 12:58:20AM -0400, Kumar Appaiah wrote:
tig-1.1
---
diff --git a/tig.c b/tig.c
index 845153f..256b589 100644
--- a/tig.c
+++ b/tig.c
@@ -4475,8 +4475,15 @@ log_request(struct view *view, enum request request,
struct line *line)
The parseopt parsing for OPT__VERBOSE() is implemented in terms of
OPT_BOOLEAN() and users of it do take advantage of the counting up
behaviour to implement increasing levels of verbosity by
differentiating git cmd -v and git cmd -v -v.
Clarify this by explicitly using OPT_COUNTUP() instead.
There cannot be git cmd -n -n that behaves even less drier than
git cmd -n, and no existing users of the macro implements such
a semantics (a summary of the audit at the end).
Instead of OPT_BOOLEAN, use OPT_BOOL to clarify.
builtin/add.c:
uses show_only as a bool.
The parseopt parsing for OPT__FORCE() is implemented in terms of
OPT_BOOLEAN() and users of it can take advantage of the counting
up behaviour to implement increasing levels of forcefulness by
differentiating git cmd -f and git cmd -f -f.
Clarify this by explicitly using OPT_COUNTUP() instead.
As a follow-up to Stefan's series, we may want to think about the
following as well:
- OPT__VERBOSE() is defined in terms of OPT_BOOLEAN(). I think we
use it to represent increasing levels of verbosity, so we cannot
turn this into OPT_BOOL(). Its implementation has to become
The parseopt parsing for OPT__QUIET() is implemented in terms of
OPT_BOOLEAN aka OPT_COUNTUP, so a user _could_ theoretically have
used it to make git cmd -q -q and git cmd -q behave differently.
However, no existing user does so (a summary of the audit at the
end). Use OPT_BOOL to make sure our
On Tuesday, August 06, 2013 06:24:50 am Duy Nguyen wrote:
On Tue, Aug 6, 2013 at 9:38 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
+ Garbage collect using a pseudo
logarithmic packfile maintenance +
approach. This approach attempts to minimize packfile
On Monday, August 05, 2013 08:38:47 pm Ramkumar Ramachandra
wrote:
This is the rough explanation I wrote down after reading
it:
So, the problem is that my .git/objects/pack is polluted
with little packs everytime I fetch (or push, if you're
the server), and this is problematic from the
Hi Folks:
On Sat, Aug 03, 2013 at 12:52:15PM -0400, Daniel Convissor wrote:
Yeah. I had contemplated using the following commands:
git config remote.wp.fetch \
+refs/heads/3.6-branch:refs/remotes/wp/3.6-branch
git config branch.wp.merge refs/heads/3.6-branch
So is git
On Tue, Aug 6, 2013 at 5:30 PM, Daniel Convissor
dani...@analysisandsolutions.com wrote:
Hi Folks:
On Sat, Aug 03, 2013 at 12:52:15PM -0400, Daniel Convissor wrote:
Yeah. I had contemplated using the following commands:
git config remote.wp.fetch \
Martin Fick wrote:
So, it has me wondering if there isn't a more accurate way
to estimate the new packfile without wasting a ton of time?
I'm not sure there is. Adding the sizes of individual packs can be off
by a lot, because your deltification will be more effective if you
have more data to
Junio C Hamano wrote:
Imagine we have a cheap way to enumerate the young objects without
the usual history traversal.
Before we discuss the advantages, can you outline how we can possibly
get this data without actually walking downwards from the roots
(refs)? One way to do it is to pull data
Users replacing an object with one of a different type were not
prevented to do so, even if it was obvious, and stated in the doc,
that bad things would result from doing that.
To avoid mistakes, it is better to just forbid that though.
The doc will be updated in a later patch.
Signed-off-by:
80 matches
Mail list logo
