I started writing this script in a repo I have called misc-scripts
where I just keep one off projects and the like (notes, throw away
scripts, etc). Well, my boss asked me to create a repo for one of
these scripts and I'd like to keep the commit history.
Ok, so:
% find -type f ! -iname "webban.pl"
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: Ch
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 o
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
On Tue, Aug 6, 2013 at 5:30 PM, Daniel Convissor
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 \
>> "+refs/heads/3.6-branch:refs/remotes/wp/3.6-bran
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"
>
>
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 th
On Tuesday, August 06, 2013 06:24:50 am Duy Nguyen wrote:
> On Tue, Aug 6, 2013 at 9:38 AM, Ramkumar Ramachandra
wrote:
> > + Garbage collect using a pseudo
> > logarithmic packfile maintenance +
> > approach. This approach attempts to minimize packfile
> > churn +
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
OPT_COUNTU
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
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.
builtin
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() instea
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)
> state->re
Eric Sunshine 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), we had:
>
> o = g
On Tue, Aug 6, 2013 at 5:33 PM, Junio C Hamano wrote:
>> + 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
Jeff King 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 http://vger.kernel.o
Eric Sunshine 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 any.
>
> Teach the par
On Tue, Aug 06, 2013 at 09:28:28AM -0700, Junio C Hamano wrote:
> Jeff King 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 writes:
> Signed-off-by: Eric Sunshine
> ---
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 files changed, 24 insertions(+), 1 deletion(-)
> + 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));
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
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);
>
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
---
builtin/branch.c | 3 ++-
builtin/commit.c | 2 +-
builtin/name-r
On 08/06/2013 08:46 PM, Eric Sunshine wrote:
> On Tue, Aug 6, 2013 at 9:07 AM, Stefan Beller
> 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
David Kastrup writes:
> Matthieu Moy writes:
>
>>>From 7962ac8d8f2cbc556f669fd97487f9d70edc4ea1 Mon Sep 17 00:00:00 2001
>> From: Matthieu Moy
>> 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 backslas
Matthieu Moy writes:
>>From 7962ac8d8f2cbc556f669fd97487f9d70edc4ea1 Mon Sep 17 00:00:00 2001
> From: Matthieu Moy
> 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 backslashes in its arguments.
I think th
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
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
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
d
> 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 hav
> From: Junio C Hamano
>
> 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 inten
On Tue, Aug 6, 2013 at 9:07 AM, Stefan Beller
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 to map any other value to
---
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
{ ... }:
{
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
---
po/de.po | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/po/de.po b/po/de.po
index 7599f9c..11dde11 100644
--- a/po/
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" fu
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 ope
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
Matthieu Moy writes:
> David Kastrup 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
Ramkumar Ramachandra 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 line "unsubscrib
Duy Nguyen writes:
> On Tue, Aug 6, 2013 at 9:38 AM, Ramkumar Ramachandra
> wrote:
>> + Garbage collect using a pseudo logarithmic packfile
>> maintenance
>> + approach. This approach attempts to minimize packfile churn
>> + by keeping several generat
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 fr
David Aguilar writes:
> I tested the tip of da/darwin (pu) w/ and w/out BLK_SHA1.
>
> Tested-by: David Aguilar
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.kernel.org/majordomo
Duy Nguyen 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 --
Subjec
Stefan Beller 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 suite is correct.
>
>
David Kastrup 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 "%
Matthieu Moy writes:
> David Kastrup 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 --g
Thomas Rast writes:
>> So while I do understand why sometimes you wish to see full diff
>> "git log --full-diff -- " 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 utterly unconvinc
Jeff King 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);
> +
> +
David Kastrup 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 b/git-sh-setup
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
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 s
Option -L/RE/ of blame/log now searches relative to the previous -L
range, if any. Document this.
Signed-off-by: Eric Sunshine
---
Documentation/line-range-format.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/line-range-format.txt
b/Documentation/line-
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 git-b
Signed-off-by: Eric Sunshine
---
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 489032c..0cebc4f 100644
--- a/Do
This is complicated slightly by having to remember the previous -L range
for each file specified via -L: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 to in
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
---
Documentation/line-range-format.txt | 1 +
line-range.c| 9 +++--
Signed-off-by: Eric Sunshine
---
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 +271,38 @@ test_expect_s
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 Suns
blame/log documentation describes -L option as:
-L,
-L:
and 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 or ; in fact, it must be -L's lone argument.
Clarify
Signed-off-by: Eric Sunshine
---
builtin/blame.c | 5 -
t/annotate-tests.sh | 20
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 7b084d8..1bf8056 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2280,6 +22
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
---
line-range.c| 5 +++
git-blame -L is 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 rejected but is
nevertheless accepted. Demonstrate this shortcoming.
Signed-off-by: Eric Sunshine
---
t/annotate-t
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 override
As of 25ed3412 (Refactor parse_loc; 2013-03-28),
blame.c:prepare_blame_range() became effectively a one-line function
which merely passes its arguments along to another function. This
indirection does not bring clarity to the code. Simplify by inlining
prepare_blame_range() into its lone caller.
S
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 a
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 argument of
-L,. The argument, as usual, is relative to .
Signed-off-by: Eric Sunshi
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
,:" and "-L ::", separated by a comma.
This is inconsistent and potentially confusing since the
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 r
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
---
builtin/branch.c | 3 ++-
builtin/commit.c | 2 +-
builtin/nam
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 suite is correct.
e35ea450 (branch, commit, name-rev: e
On Tue, Aug 6, 2013 at 9:38 AM, Ramkumar Ramachandra wrote:
> + Garbage collect using a pseudo logarithmic packfile
> maintenance
> + approach. This approach attempts to minimize packfile churn
> + by keeping several generations of varying sized packfile
On Mon, Aug 5, 2013 at 11:44 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Sun, Aug 4, 2013 at 12:26 AM, brian m. carlson
>> wrote:
>>> The test file that the UTF-16 rejection test looks for is missing, but this
>>> went
>>> unnoticed because the test is expected to fail anyway; as a c
On Mon, Aug 5, 2013 at 11:00 AM, Junio C Hamano wrote:
> Brian Gernhardt 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 block after the die/error/warning
>> d
On Mon, Aug 5, 2013 at 10:52 AM, Junio C Hamano wrote:
> Brian Gernhardt 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 the appropriate libraries are always s
Junio C Hamano writes:
> Thomas Rast writes:
>
>> Junio C Hamano 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 -- " looked strange,
>>> because comparison was done wi
On Tue, Aug 6, 2013 at 1:41 PM, Johannes Sixt 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 create a gap b
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
78 matches
Mail list logo
