* Re: [PATCH v2] Perform cheaper connectivity check when pack is used as medium
From: Nguyen Thai Ngoc Duy @ 2012-02-29 1:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <4F4CF58A.9090502@viscovery.net>
2012/2/28 Johannes Sixt <j.sixt@viscovery.net>:
> Am 2/28/2012 14:18, schrieb Nguyễn Thái Ngọc Duy:
>> Without the patch:
>> $ time git fetch file:///home/pclouds/w/git/.git
>> remote: Counting objects: 125638, done.
>> remote: Compressing objects: 100% (33201/33201), done.
> ...
>> With the patch:
>> $ time git fetch file:///home/pclouds/w/git/.git
>> remote: Counting objects: 125647, done.
>> remote: Compressing objects: 100% (33209/33209), done.
>
> It is a bit irritating that the number are different when they should be
> identical...
~/w/git is my working directory so objects may change a little bit.
Should have fetched from a clone instead, sorry.
--
Duy
^ permalink raw reply
* Re: Tilde spec - befuzzled
From: Andrew Ardill @ 2012-02-29 1:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Andreas Ericsson, Luke Diamand, Git List
In-Reply-To: <7vaa42zrw8.fsf@alter.siamese.dyndns.org>
On 29 February 2012 06:20, Junio C Hamano <gitster@pobox.com> wrote:
> Thomas Rast <trast@inf.ethz.ch> writes:
>
>>>> '<rev>{tilde}<n>', e.g. 'master{tilde}3'::
>>>> A suffix '{tilde}<n>' to a revision parameter means the commit
>>>> object that is the <n>th generation grand-parent of the named
>>>> commit object, following only the first parents.
>>>>
>>>> Hang on, *grand*-parents?
>>>> ...
>>
>> Perhaps we should reword it as "n-th first-parent ancestor"? Barring
>> confusion about the position of the dashes, that leaves little room for
>> error.
>
> I think we could either go "easier to read but not precise"
>
> ... that is the <n>th generation (grand-)parent of ...
>
> or "may sound scary but correct"
>
> the ancestor reached by walking the first-parent chain <n> times
>
> I am not sure which bucket "n-th first-parent ancestor" falls into.
The terms might be too technical, however my understanding was that
HEAD^n takes <n> steps along a breadth-first traversal of the commit
tree rooted at HEAD, while HEAD~n uses a depth-first traversal.
A better form for the description might come from that formulation of
the process, rather than the 'generational' formulation.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: Announcing 3 git docs: Best Practices, fixing mistakes, post-production editing
From: Junio C Hamano @ 2012-02-29 1:00 UTC (permalink / raw)
To: Seth Robertson; +Cc: git
In-Reply-To: <201202281304.q1SD4U8W018223@no.baka.org>
Just a few I noticed that are dubious to be in a document that is meant to
describe "best practices".
"Do commit early and often"
---------------------------
* "Personally ... history of this repository!". That looks somewhat out
of place when you are trying to document "best practices".
"Don't panic"
-------------
* As we never "auto-stash", anything that is on stash is by definition
what the user deliberately placed, just like a commit on a branch that
the user may have forgotten. So it is strange to count it as one of the
three places that "lost" commit may be hiding. If you make it four and
add "a branch you might have forgotten" to the mix, it would make a bit
more sense, though.
* The example command line for gitk passes --all and also everything from
"log -g" output, which should be OK for toy history, but wouldn't be
such a good idea when you can expect tons of data from "log -g".
Doesn't "gitk" itself accept -g these days?
* Lost and found
Why "git ls-tree -r"? Doesn't "git show" work eqully well?
Also, the name of the hash we happen to use to produce the "object name"
is "SHA-1", so either of these two are fine, but do not say "SHA"
(throughout the document).
"On Sausage Making"
-------------------
* The desription of "downside" shows a bias against efforts to strive for
useful history, and also shows ignorance of the true motivation behind
such discipline. It is _not_ blame or ego. It is all about leaving a
history others can later use to understand _why_ the code became the way
it is now, to make it less likely for others to break it.
If I were writing this, I would either remove that one paragraph
altogether, or tone it down dramatically. There is a short-term
downside that you would be spending time on perfecting the history
instead of advancing the tip of the branch, especially when you know the
tree at the tip of the perfected history will be identical to the tip of
the messy history you currently have. If you plan to leave the project
in a month or so and will never look back, that is totally wasted effort
as maintaining the result will be other people's problem. But if you
are planning to be involved in the project for a longer haul, the time
and effort is worth spending to make less-than-useful history into
useful one.
"Do keep up to date"
--------------------
* You explained in "Do choose a workflow" section that different workflows
suite different projects. It would read better to rephrase this
paragraph in which you are admitting that not everybody agrees with your
"pull --rebase". Instead of saying "but they should agree with me", it
would be more useful to say in what workflow and the workflow elements
such as "pull --rebase" you advocate in this section are suited (you do
not have to say in what other workflow they are inappropriate).
I stopped reading at this point, but will look at the rest some other day.
Thanks for a fun reading.
^ permalink raw reply
* [PATCH v2 2/2] pickaxe: allow -i to search in patch case-insensitively
From: Junio C Hamano @ 2012-02-29 0:20 UTC (permalink / raw)
To: git
In-Reply-To: <1330474831-9030-1-git-send-email-gitster@pobox.com>
"git log -S<string>" is a useful way to find the last commit in the
codebase that touched the <string>. As it was designed to be used by a
porcelain script to dig the history starting from a block of text that
appear in the starting commit, it never had to look for anything but an
exact match.
When used by an end user who wants to look for the last commit that
removed a string (e.g. name of a variable) that he vaguely remembers,
however, it is useful to support case insensitive match.
When given the "--regexp-ignore-case" (or "-i") option, which originally
was designed to affect case sensitivity of the search done in the commit
log part, e.g. "log --grep", the matches made with -S/-G pickaxe search is
done case insensitively now.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.h | 1 +
diffcore-pickaxe.c | 9 +++-
revision.c | 1 +
t/t4209-log-pickaxe.sh | 119 ++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 128 insertions(+), 2 deletions(-)
create mode 100755 t/t4209-log-pickaxe.sh
diff --git a/diff.h b/diff.h
index 0c51724..436b574 100644
--- a/diff.h
+++ b/diff.h
@@ -80,6 +80,7 @@ typedef struct strbuf *(*diff_prefix_fn_t)(struct diff_options *opt, void *data)
#define DIFF_OPT_OVERRIDE_SUBMODULE_CONFIG (1 << 27)
#define DIFF_OPT_DIRSTAT_BY_LINE (1 << 28)
#define DIFF_OPT_FUNCCONTEXT (1 << 29)
+#define DIFF_OPT_PICKAXE_IGNORE_CASE (1 << 30)
#define DIFF_OPT_TST(opts, flag) ((opts)->flags & DIFF_OPT_##flag)
#define DIFF_OPT_SET(opts, flag) ((opts)->flags |= DIFF_OPT_##flag)
diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
index 380a837..ed23eb4 100644
--- a/diffcore-pickaxe.c
+++ b/diffcore-pickaxe.c
@@ -138,8 +138,12 @@ static void diffcore_pickaxe_grep(struct diff_options *o)
{
int err;
regex_t regex;
+ int cflags = REG_EXTENDED | REG_NEWLINE;
- err = regcomp(®ex, o->pickaxe, REG_EXTENDED | REG_NEWLINE);
+ if (DIFF_OPT_TST(o, PICKAXE_IGNORE_CASE))
+ cflags |= REG_ICASE;
+
+ err = regcomp(®ex, o->pickaxe, cflags);
if (err) {
char errbuf[1024];
regerror(err, ®ex, errbuf, 1024);
@@ -237,7 +241,8 @@ static void diffcore_pickaxe_count(struct diff_options *o)
}
regexp = ®ex;
} else {
- kws = kwsalloc(NULL);
+ kws = kwsalloc(DIFF_OPT_TST(o, PICKAXE_IGNORE_CASE)
+ ? tolower_trans_tbl : NULL);
kwsincr(kws, needle, len);
kwsprep(kws);
}
diff --git a/revision.c b/revision.c
index 8764dde..971b7dc 100644
--- a/revision.c
+++ b/revision.c
@@ -1559,6 +1559,7 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
revs->grep_filter.regflags |= REG_EXTENDED;
} else if (!strcmp(arg, "--regexp-ignore-case") || !strcmp(arg, "-i")) {
revs->grep_filter.regflags |= REG_ICASE;
+ DIFF_OPT_SET(&revs->diffopt, PICKAXE_IGNORE_CASE);
} else if (!strcmp(arg, "--fixed-strings") || !strcmp(arg, "-F")) {
revs->grep_filter.fixed = 1;
} else if (!strcmp(arg, "--all-match")) {
diff --git a/t/t4209-log-pickaxe.sh b/t/t4209-log-pickaxe.sh
new file mode 100755
index 0000000..eed7273
--- /dev/null
+++ b/t/t4209-log-pickaxe.sh
@@ -0,0 +1,119 @@
+#!/bin/sh
+
+test_description='log --grep/--author/--regexp-ignore-case/-S/-G'
+. ./test-lib.sh
+
+test_expect_success setup '
+ >file &&
+ git add file &&
+ test_tick &&
+ git commit -m initial &&
+
+ echo Picked >file &&
+ test_tick &&
+ git commit -a --author="Another Person <another@example.com>" -m second
+'
+
+test_expect_success 'log --grep' '
+ git log --grep=initial --format=%H >actual &&
+ git rev-parse --verify HEAD^ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log --grep --regexp-ignore-case' '
+ git log --regexp-ignore-case --grep=InItial --format=%H >actual &&
+ git rev-parse --verify HEAD^ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log --grep -i' '
+ git log -i --grep=InItial --format=%H >actual &&
+ git rev-parse --verify HEAD^ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log --author --regexp-ignore-case' '
+ git log --regexp-ignore-case --author=person --format=%H >actual &&
+ git rev-parse --verify HEAD >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log --author -i' '
+ git log -i --author=person --format=%H >actual &&
+ git rev-parse --verify HEAD >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log -G (nomatch)' '
+ git log -Gpicked --format=%H >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log -G (match)' '
+ git log -GPicked --format=%H >actual &&
+ git rev-parse --verify HEAD >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log -G --regexp-ignore-case (nomatch)' '
+ git log --regexp-ignore-case -Gpickle --format=%H >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log -G -i (nomatch)' '
+ git log -i -Gpickle --format=%H >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log -G --regexp-ignore-case (match)' '
+ git log --regexp-ignore-case -Gpicked --format=%H >actual &&
+ git rev-parse --verify HEAD >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log -G -i (match)' '
+ git log -i -Gpicked --format=%H >actual &&
+ git rev-parse --verify HEAD >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log -S (nomatch)' '
+ git log -Spicked --format=%H >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log -S (match)' '
+ git log -SPicked --format=%H >actual &&
+ git rev-parse --verify HEAD >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log -S --regexp-ignore-case (match)' '
+ git log --regexp-ignore-case -Spicked --format=%H >actual &&
+ git rev-parse --verify HEAD >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log -S -i (match)' '
+ git log -i -Spicked --format=%H >actual &&
+ git rev-parse --verify HEAD >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log -S --regexp-ignore-case (nomatch)' '
+ git log --regexp-ignore-case -Spickle --format=%H >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log -S -i (nomatch)' '
+ git log -i -Spickle --format=%H >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
+test_done
--
1.7.9.2.344.g3e8c86
^ permalink raw reply related
* [PATCH v2 1/2] grep: use static trans-case table
From: Junio C Hamano @ 2012-02-29 0:20 UTC (permalink / raw)
To: git
In-Reply-To: <1330474831-9030-1-git-send-email-gitster@pobox.com>
In order to prepare the kwset machinery for a case-insensitive search, we
used to use a static table of 256 elements and filled it every time before
calling kwsalloc(). Because the kwset machinery will never modify this
table, just allocate a single instance globally and fill it at the compile
time.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
cache.h | 3 +++
ctype.c | 36 ++++++++++++++++++++++++++++++++++++
grep.c | 11 +++--------
3 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/cache.h b/cache.h
index 79c612f..79dc305 100644
--- a/cache.h
+++ b/cache.h
@@ -1258,4 +1258,7 @@ extern struct startup_info *startup_info;
/* builtin/merge.c */
int checkout_fast_forward(const unsigned char *from, const unsigned char *to);
+/* in ctype.c, for kwset users */
+extern const char tolower_trans_tbl[256];
+
#endif /* CACHE_H */
diff --git a/ctype.c b/ctype.c
index b5d856f..7c14d85 100644
--- a/ctype.c
+++ b/ctype.c
@@ -25,3 +25,39 @@ unsigned char sane_ctype[256] = {
A, A, A, A, A, A, A, A, A, A, A, R, R, 0, P, 0, /* 112..127 */
/* Nothing in the 128.. range */
};
+
+/* For case-insensitive kwset */
+const char tolower_trans_tbl[256] = {
+ 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
+ 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
+ 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
+ 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
+ ' ', '!', '"', '#', '$', '%', '&', 0x27,
+ '(', ')', '*', '+', ',', '-', '.', '/',
+ '0', '1', '2', '3', '4', '5', '6', '7',
+ '8', '9', ':', ';', '<', '=', '>', '?',
+ '@', 'a', 'b', 'c', 'd', 'e', 'f', 'g',
+ 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o',
+ 'p', 'q', 'r', 's', 't', 'u', 'v', 'w',
+ 'x', 'y', 'z', '[', 0x5c, ']', '^', '_',
+ '`', 'a', 'b', 'c', 'd', 'e', 'f', 'g',
+ 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o',
+ 'p', 'q', 'r', 's', 't', 'u', 'v', 'w',
+ 'x', 'y', 'z', '{', '|', '}', '~', 0x7f,
+ 0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
+ 0x88, 0x89, 0x8a, 0x8b, 0x8c, 0x8d, 0x8e, 0x8f,
+ 0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97,
+ 0x98, 0x99, 0x9a, 0x9b, 0x9c, 0x9d, 0x9e, 0x9f,
+ 0xa0, 0xa1, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7,
+ 0xa8, 0xa9, 0xaa, 0xab, 0xac, 0xad, 0xae, 0xaf,
+ 0xb0, 0xb1, 0xb2, 0xb3, 0xb4, 0xb5, 0xb6, 0xb7,
+ 0xb8, 0xb9, 0xba, 0xbb, 0xbc, 0xbd, 0xbe, 0xbf,
+ 0xc0, 0xc1, 0xc2, 0xc3, 0xc4, 0xc5, 0xc6, 0xc7,
+ 0xc8, 0xc9, 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf,
+ 0xd0, 0xd1, 0xd2, 0xd3, 0xd4, 0xd5, 0xd6, 0xd7,
+ 0xd8, 0xd9, 0xda, 0xdb, 0xdc, 0xdd, 0xde, 0xdf,
+ 0xe0, 0xe1, 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7,
+ 0xe8, 0xe9, 0xea, 0xeb, 0xec, 0xed, 0xee, 0xef,
+ 0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7,
+ 0xf8, 0xf9, 0xfa, 0xfb, 0xfc, 0xfd, 0xfe, 0xff,
+};
diff --git a/grep.c b/grep.c
index b29d09c..1030f38 100644
--- a/grep.c
+++ b/grep.c
@@ -168,15 +168,10 @@ static void compile_regexp(struct grep_pat *p, struct grep_opt *opt)
p->fixed = 0;
if (p->fixed) {
- if (opt->regflags & REG_ICASE || p->ignore_case) {
- static char trans[256];
- int i;
- for (i = 0; i < 256; i++)
- trans[i] = tolower(i);
- p->kws = kwsalloc(trans);
- } else {
+ if (opt->regflags & REG_ICASE || p->ignore_case)
+ p->kws = kwsalloc(tolower_trans_tbl);
+ else
p->kws = kwsalloc(NULL);
- }
kwsincr(p->kws, p->pattern, p->patternlen);
kwsprep(p->kws);
return;
--
1.7.9.2.344.g3e8c86
^ permalink raw reply related
* [PATCH v2 0/2] "log --regexp-ignore-case -S/-G<string>"
From: Junio C Hamano @ 2012-02-29 0:20 UTC (permalink / raw)
To: git
This is a re-roll of the previous attempt to teach pickaxe to match
case insensitively.
Junio C Hamano (2):
grep: use static trans-case table
pickaxe: allow -i to search in patch case-insensitively
cache.h | 3 ++
ctype.c | 36 +++++++++++++++
diff.h | 1 +
diffcore-pickaxe.c | 9 +++-
grep.c | 11 ++---
revision.c | 1 +
t/t4209-log-pickaxe.sh | 119 ++++++++++++++++++++++++++++++++++++++++++++++++
7 files changed, 170 insertions(+), 10 deletions(-)
create mode 100755 t/t4209-log-pickaxe.sh
--
1.7.9.2.344.g3e8c86
^ permalink raw reply
* [PATCH] fsck: --no-dangling omits "dangling object" information
From: Junio C Hamano @ 2012-02-28 23:25 UTC (permalink / raw)
To: git; +Cc: Clemens Buchacher, Jeff King
In-Reply-To: <7vhayc55a7.fsf@alter.siamese.dyndns.org>
The default output from "fsck" is often overwhelmed by informational
message on dangling objects, especially if you do not repack often, and a
real error can easily be buried.
Add "--no-dangling" option to omit them, and update the user manual to
demonstrate its use.
Based on a patch by Clemens Buchacher, but reverted the part to change
the default to --no-dangling, which is unsuitable for the first patch.
The usual three-step procedure to break the backward compatibility over
time needs to happen on top of this, if we were to go in that direction.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I butchered Clemens's patch and added "--no-dangling", and reverted the
part that flips the default. I also took the authorship blame, as I do
not share the final goal of fliping the default (yet), but our first
steps should be in the same direction, which is this patch.
Documentation/git-fsck.txt | 7 ++++++-
Documentation/git-repack.txt | 2 +-
Documentation/user-manual.txt | 15 +++++++--------
builtin/fsck.c | 7 +++++--
t/t1450-fsck.sh | 6 +-----
5 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 6c47395..47e2f19 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
[--[no-]full] [--strict] [--verbose] [--lost-found]
- [--[no-]progress] [<object>*]
+ [--[no-]dangling] [--[no-]progress] [<object>*]
DESCRIPTION
-----------
@@ -30,6 +30,11 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
Print out objects that exist but that aren't reachable from any
of the reference nodes.
+--dangling::
+--no-dangling::
+ Print objects that exist but that are never 'directly' used (default).
+ `--no-dangling` can be used to squech this information from the output.
+
--root::
Report root nodes.
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 40af321..4c1aff6 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -34,7 +34,7 @@ OPTIONS
Especially useful when packing a repository that is used
for private development. Use
with '-d'. This will clean up the objects that `git prune`
- leaves behind, but `git fsck --full` shows as
+ leaves behind, but `git fsck --full --dangling` shows as
dangling.
+
Note that users fetching over dumb protocols will have to fetch the
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index f13a846..6c7fee7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1582,7 +1582,7 @@ Checking the repository for corruption
The linkgit:git-fsck[1] command runs a number of self-consistency checks
on the repository, and reports on any problems. This may take some
-time. The most common warning by far is about "dangling" objects:
+time.
-------------------------------------------------
$ git fsck
@@ -1597,9 +1597,11 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
...
-------------------------------------------------
-Dangling objects are not a problem. At worst they may take up a little
-extra disk space. They can sometimes provide a last-resort method for
-recovering lost work--see <<dangling-objects>> for details.
+You will see informational messages on dangling objects. They are objects
+that still exist in the repository but are no longer referenced by any of
+your branches, and can (and will) be removed after a while with "gc".
+You can run `git fsck --no-dangling` to supress these messages, and still
+view real errors.
[[recovering-lost-changes]]
Recovering lost changes
@@ -3295,15 +3297,12 @@ it is with linkgit:git-fsck[1]; this may be time-consuming.
Assume the output looks like this:
------------------------------------------------
-$ git fsck --full
+$ git fsck --full --no-dangling
broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
to blob 4b9458b3786228369c63936db65827de3cc06200
missing blob 4b9458b3786228369c63936db65827de3cc06200
------------------------------------------------
-(Typically there will be some "dangling object" messages too, but they
-aren't interesting.)
-
Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6
points to it. If you could find just one copy of that missing blob
object, possibly in some other repository, you could move it into
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 8c479a7..67eb553 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -29,6 +29,7 @@ static int errors_found;
static int write_lost_and_found;
static int verbose;
static int show_progress = -1;
+static int show_dangling = 1;
#define ERROR_OBJECT 01
#define ERROR_REACHABLE 02
#define ERROR_PACK 04
@@ -221,8 +222,9 @@ static void check_unreachable_object(struct object *obj)
* start looking at, for example.
*/
if (!obj->used) {
- printf("dangling %s %s\n", typename(obj->type),
- sha1_to_hex(obj->sha1));
+ if (show_dangling)
+ printf("dangling %s %s\n", typename(obj->type),
+ sha1_to_hex(obj->sha1));
if (write_lost_and_found) {
char *filename = git_path("lost-found/%s/%s",
obj->type == OBJ_COMMIT ? "commit" : "other",
@@ -614,6 +616,7 @@ static char const * const fsck_usage[] = {
static struct option fsck_opts[] = {
OPT__VERBOSE(&verbose, "be verbose"),
OPT_BOOLEAN(0, "unreachable", &show_unreachable, "show unreachable objects"),
+ OPT_BOOL(0, "dangling", &show_dangling, "show dangling objects"),
OPT_BOOLEAN(0, "tags", &show_tags, "report tags"),
OPT_BOOLEAN(0, "root", &show_root, "report root nodes"),
OPT_BOOLEAN(0, "cache", &keep_cache_objects, "make index objects head nodes"),
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index 5b8ebd8..5b79c51 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -27,12 +27,8 @@ test_expect_success 'loose objects borrowed from alternate are not missing' '
git init &&
echo ../../../.git/objects >.git/objects/info/alternates &&
test_commit C fileC one &&
- git fsck >../out 2>&1
+ git fsck --no-dangling >../actual 2>&1
) &&
- {
- grep -v dangling out >actual ||
- :
- } &&
test_cmp empty actual
'
--
1.7.9.2.344.g3e8c86
^ permalink raw reply related
* [PATCH 2/2] test: "am -3" can accept non-standard -p<num>
From: Junio C Hamano @ 2012-02-28 23:24 UTC (permalink / raw)
To: git
In-Reply-To: <1330471495-12013-1-git-send-email-gitster@pobox.com>
This adds a test for the previous one to make sure that "am -3 -p0" can
read patches created with the --no-prefix option.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t4150-am.sh | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index d7d9ccc..e1d381c 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -123,6 +123,7 @@ test_expect_success setup '
git commit -m "added another file" &&
git format-patch --stdout master >lorem-move.patch &&
+ git format-patch --no-prefix --stdout master >lorem-zero.patch &&
git checkout -b rename &&
git mv file renamed &&
@@ -276,6 +277,20 @@ test_expect_success 'am -3 falls back to 3-way merge' '
git diff --exit-code lorem
'
+test_expect_success 'am -3 -p0 can read --no-prefix patch' '
+ rm -fr .git/rebase-apply &&
+ git reset --hard &&
+ git checkout -b lorem3 master2 &&
+ sed -n -e "3,\$p" msg >file &&
+ head -n 9 msg >>file &&
+ git add file &&
+ test_tick &&
+ git commit -m "copied stuff" &&
+ git am -3 -p0 lorem-zero.patch &&
+ ! test -d .git/rebase-apply &&
+ git diff --exit-code lorem
+'
+
test_expect_success 'am can rename a file' '
grep "^rename from" rename.patch &&
rm -fr .git/rebase-apply &&
--
1.7.9.2.344.g3e8c86
^ permalink raw reply related
* [PATCH 0/2] "am -3" and "--no-prefix" does not work well
From: Junio C Hamano @ 2012-02-28 23:24 UTC (permalink / raw)
To: git
I wrote these a few days ago when I tried to review somebody's patch
on this list that was made with "format-patch --no-prefix". The regular
patch application without the three-way fallback was prepared to honor a
custom -p<num>, but the code to synthesize the fake ancestor tree forgot
to pay attention to -p<num>, so "am -3 -p0" was failing.
Junio C Hamano (2):
am -3: allow nonstandard -p<num> option
test: "am -3" can accept non-standard -p<num>
git-am.sh | 11 +++++++----
t/t4150-am.sh | 15 +++++++++++++++
2 files changed, 22 insertions(+), 4 deletions(-)
--
1.7.9.2.344.g3e8c86
^ permalink raw reply
* [PATCH 1/2] am -3: allow nonstandard -p<num> option
From: Junio C Hamano @ 2012-02-28 23:24 UTC (permalink / raw)
To: git
In-Reply-To: <1330471495-12013-1-git-send-email-gitster@pobox.com>
When falling back to 3-way merge, we run "git apply" to synthesize the
fake ancestor tree by parsing the incoming patch, and another "git apply"
to apply the patch to the fake ancestor tree. Both invocation need to
be aware of the custom -p<num> setting to parse patches that were prepared
with non-standard src/dst prefix.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-am.sh | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 1c13b13..d5d168f 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -127,15 +127,18 @@ fall_back_3way () {
mkdir "$dotest/patch-merge-tmp-dir"
# First see if the patch records the index info that we can use.
- git apply --build-fake-ancestor "$dotest/patch-merge-tmp-index" \
- "$dotest/patch" &&
+ cmd="git apply $git_apply_opt --build-fake-ancestor" &&
+ cmd="$cmd "'"$dotest/patch-merge-tmp-index" "$dotest/patch"' &&
+ eval "$cmd" &&
GIT_INDEX_FILE="$dotest/patch-merge-tmp-index" \
git write-tree >"$dotest/patch-merge-base+" ||
cannot_fallback "$(gettext "Repository lacks necessary blobs to fall back on 3-way merge.")"
say Using index info to reconstruct a base tree...
- if GIT_INDEX_FILE="$dotest/patch-merge-tmp-index" \
- git apply --cached <"$dotest/patch"
+
+ cmd='GIT_INDEX_FILE="$dotest/patch-merge-tmp-index"'
+ cmd="$cmd git apply --cached $git_apply_opt"' <"$dotest/patch"'
+ if eval "$cmd"
then
mv "$dotest/patch-merge-base+" "$dotest/patch-merge-base"
mv "$dotest/patch-merge-tmp-index" "$dotest/patch-merge-index"
--
1.7.9.2.344.g3e8c86
^ permalink raw reply related
* Re: [PATCH] Documentation: use {asterisk} in rev-list-options.txt when needed
From: Thomas Rast @ 2012-02-28 23:03 UTC (permalink / raw)
To: Jeff King; +Cc: Carlos Martín Nieto, git
In-Reply-To: <20120228194551.GC11725@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Anyway, that is not a problem with your patch. :) I confirmed that the
> bug happens in my version of the toolchain, and your fix works (I also
> tried using `*`, but backtick does not suppress markup.
Actually it would, if it weren't for our use of '-a no-inline-literal'.
Which we are using because the "backticks do not interpret {stuff}"
feature was introduced in a backwards-incompatible way in asciidoc
8.4.1, see 71c020c (Disable asciidoc 8.4.1+ semantics for `{plus}` and
friends, 2009-07-25).
Some googling tells me the distros are currently at
openSuSE 8.4.5 (local)
Debian (stable) 8.5.2 packages.debian.org
Fedora 8.4.5 admin.fedoraproject.org/pkgdb/
(but I can't discern whether it's actually in there...)
Arch 8.6.6 www.archlinux.org/packages/
Ubuntu 11.10 8.6.4 packages.ubuntu.com
so perhaps the time has come to remove that switch?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Announcing 3 git docs: Best Practices, fixing mistakes, post-production editing
From: Jeff King @ 2012-02-28 22:52 UTC (permalink / raw)
To: Seth Robertson; +Cc: git
In-Reply-To: <201202281304.q1SD4U8W018223@no.baka.org>
On Tue, Feb 28, 2012 at 08:04:30AM -0500, Seth Robertson wrote:
> Commit Often, Perfect Later, Publish Once: Git Best Practices
> ----------------------------------------------------------------------
> http://sethrobertson.github.com/GitBestPractices
I have only read the first of the three so far, but it looks very nice.
I did notice a few things which were worth commenting on (I'll quote
directly from the page in question below).
> [section Don't Panic, subsection Lost and Found]
>
> Dangling Commit
>
> These are the most likely candidates for finding lost data. A dangling
> commit is a commit no longer reachable by any branch or tag. This can
> happen due to resets and rebases and are normal. git show SHA will let
> you inspect them.
Resets and rebases record the commits in the reflog (at the very least
in the HEAD reflog), and should generally not be the cause of dangling
commits (the objects should usually expire in the same "git gc" that
expires the reflog entries). I suspect a more common cause is deleting
branches, which leaves no reflog (the commits may be in the HEAD reflog
if they were ever checked out, though).
It's somewhat minor; the overall advice ("do not worry about dangling
commits") holds. But it might be worth pointing out that the method for
recovering an accidentally deleted branch is usually:
1. look in the HEAD reflog
2. if you can't find it there, try dangling commits
> [section Do make useful commit messages]
This talks about formatting, but not about content. I have long wanted
to write a nice essay on what should go into a good commit message, but
when I've tried it ends up very specific to the project, the type of
commit, and the individual change. I wonder if anybody knows of
something good you could link to.
> [section On Sausage Making]
>
> Some people like to hide the sausage making, or in other words pretend to
> the outside world that their commits sprung full-formed in utter
> perfection into their git repository. Certain large public projects
> demand this, others demand smushing all work into one large commit, and
> still others do not care.
>
> A good reason to hide the sausage making is if you feel you may be
> cherry-picking commits a lot (though this too is often a sign of bad
> workflow). Having one or a small number of commits to pick is much
> easier than having to find one commit here, one there, and half of this
> other one. The latter approach makes your problem much much harder and
> typically will lead to merge conflicts when the donor branch is finally
> merged in.
>
> Another good reason is to ensure each commit compiles and/or passes
> regression tests, and represents a different easily understood concept
> (important for archeology). The former allows git-bisect to chose any
> commit and have a good chance of that commit doing something useful, and
> the latter allows for easy change review, understanding, and
> cherry-picking.
This is a nice overview of the motivation, but I think it misses one
of the main reasons we clean up patches in git.git: code review. When
you publish patches, you have several audiences. One of those audiences
is the end user who will compile release v1.5. They only care about the
end result of the patches. Another is people bisecting, who care that
everything intermediate builds and is reasonable; you can satisfy that
by checking each commit against a test suite. Another is people reading
the logs later to find out what happened; it's OK for them to see that a
bug was in the initial version, and then fixed 5 minutes later.
But yet another audience is reviewers who will read your changes and
decide they should be applied, rejected, or re-worked. For those people,
it is much harder to review a series that introduces a bug in patch 1,
but fixes it in patch 5. The reviewer may also notice the bug, take time
thinking about and writing an analysis, and then get frustrated to find
that their work was wasted when they get to patch 5.
The alternative is that they stop thinking about individual patches and
consider the whole series (e.g., when they see patch 1 has a bug, stop
reading and look through the other patches for a fix). But that makes
review much harder, because you have to think about a much larger series
of changes.
By cleaning up patches into single, logical changes that build on one
another, and which don't individually regress (i.e., they are always
moving towards some desirable common endpoint), the author is writing a
chronological story not of what happened, but what _should_ happen, with
the intent that the audience (i.e., reviewers) are convinced that the
change is the right thing to do.
I really liked your movie analogy. Patch series are really just
documentaries about a change, arranged for greatest impact on the
viewer. :)
> [Do periodic maintenance]
>
> Compact your repo (git gc --aggressive)
>
> This will removed outdated dangling objects (after the two+ week grace
> period). It will also compress any loose objects git has added since
> your last gc. git will run gc automatically after certain commands, but
> doing a manual --aggressive will save space and speed git operations.
Most people shouldn't be using "--aggressive". Unless you have an
existing pack that is poorly packed (e.g., because you did a
fast-import that did not do much delta searching), you are not going to
see much benefit, and it will take a lot longer. Basically the three
levels of "gc" are:
1. git gc --auto; if there are too many loose objects, they will all
go into a new incremental pack. If there are already too many
packs, all of the existing packs will get re-packed together.
If we are making an incremental pack, this is by far the fastest,
because the speed is independent of the existing history. If we
pack everything together, it should be more or less the same as (2)
below.
2. git gc; this packs everything into a single pack. It does not use
high window and depth parameters, but more importantly, it reuses
existing deltas. That makes the delta compression phase _much_
faster, and it often makes the writing phase faster (because for
older objects, we are primarily streaming them right out of the
existing pack). On a big repo, though, it does do a lot of I/O,
because it has to rewrite the whole pack.
3. git gc --aggressive; this is often way slower than the above
because we throw out all of the existing deltas and recompute them
from scratch. The higher window parameter means it will spend a bit
more time computing, and it may end up with a smaller pack.
In practical applications, I would expect (2) to achieve similar results to (3). If
that isn't the case, then I think we should be tuning up the default
window and depth parameters for non-aggressive "git gc" a bit.
> [section Miscellaneous "don't"s]
>
> create very large repositories (when possible)
>
> Git can be slow in the face of large repositories. There are
> git-config options that can help. pack.threads=1 pack.deltaCacheSize=1
> pack.windowMemory=512m core.packedGitWindowSize=16m
> core.packedGitLimit=128m. Other likely ones exist.
It might help to qualify "big" here. To some people, 10,000 files,
50,000 commits, and a 200M packfile is big. But that's a fraction of
linux-2.6, which most people use. I think big here is probably getting
into 100K-200K files (where the time to stat() files becomes noticeable,
commits are probably not relevant (because git is usually good at only
looking at recent bits of history for most operations), and packfiles
above 1G or so start to get cumbersome (mostly because of the I/O on a
full repack; but then you should consider marking a pack as .keep).
But those numbers are just pulled out of a hat based on the last few
years. Your OS, your hardware, and your expectations make a huge
difference in what seems reasonable.
Your config recommendations seem mostly related to relieving memory
pressure for packing (at the expense of making the pack a lot slower).
Dropping --aggressive from your gc might help a lot with that, too. It
might be worth noting that you should only start twiddling these options
if you are running out of memory during a repack. They will not affect
git performance for day-to-day commands.
I don't think you should need to adjust core.packedGitWindowSize or
core.packedGitLimit at all. Those files are mmap'd, so it is up to the
OS to be reasonable about faulting in or releasing the memory. The main
motivation of pack windows is not memory _usage_, but rather getting a
large contiguous chunk of the address space. mmap-ing a 4G packfile on a
32-bit system just doesn't work. But the defaults are set to reasonable
values for each architecture.
-Peff
^ permalink raw reply
* Re: git-subtree Ready #2
From: Avery Pennarun @ 2012-02-28 22:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jeff King, Junio C Hamano, David A. Greene, git
In-Reply-To: <m3ehtfvhkv.fsf@localhost.localdomain>
On Mon, Feb 27, 2012 at 9:04 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Jeff King <peff@peff.net> writes:
>> Yeah, I don't see much point in rewriting. If parts of the history suck,
>> then so be it. It's probably not that big to store. And while it's
>> sometimes easier to fix bad commit messages when they are recent and in
>> your memory (rather than trying to remember later what you meant to
>> say), I think it is already too late for that. Any archaeology you do
>> now to make good commit messages could probably just as easily be done
>> if and when somebody actually needs the commit message later (emphasis
>> on the "if" -- it's likely that nobody will care about most of the
>> commit messages later at all).
>
> Anyway we already have subtree merges if subsystem with bad error
> messages -- see gitweb.
So be it then! May my lame commit messages persist forever! As if I
don't have enough embarrassing stuff on the Internet.
(Personally I think the vast majority of the commit messages are
perfectly fine, and the ones that aren't generally describe boring
commits anyway, like changes to the 'todo' file.)
Have fun,
Avery
^ permalink raw reply
* Re: Stash during incomplete merge
From: Neal Kreitzinger @ 2012-02-28 22:24 UTC (permalink / raw)
Cc: Phil Hord, git@vger.kernel.org, Phil Hord
In-Reply-To: <4F4D377B.2000206@gmail.com>
On 2/28/2012 2:22 PM, Neal Kreitzinger wrote:
>
> You may also want to consider the --keep-index option on your "git
> stash save" if your "testing" workflow doesn't involve adds or
> commits before the git stash apply/pop.
>
the very limited case I had in mind (and probably incorrect assumption)
about your "testing" workflow was:
hack merge-conflicts
$ git add conflict-resolution (conflict-resolution is in worktree and
index)
hack conflict-resolution with extra stuff (original conflict-resolution
is still in index)
uh-oh, i got carried away and started doing extra stuff (evil merge) and
forgot to finish testing just the conflict-resolutions (pure merge-commit)
$ git stash --keep-index (conflict-resolution is still in index and now
back in wokrtree)
finish testing just the conflict-resolutions (merge-commit-to-be)
(conflict resolutions worked (I knew they would))
$ git stash pop (original conflict resolution is still in index, but
extra-stuff is back in worktree)
$ git commit (commit the conflict-resolutions/merge-commit)
$ git add foo
$ git commit (new foo stuff committed after merge commit)
v/r,
neal
^ permalink raw reply
* Re: [PATCH 4/3] parse-options: disallow --no-no-sth
From: Junio C Hamano @ 2012-02-28 21:15 UTC (permalink / raw)
To: René Scharfe
Cc: Thomas Rast, git, Bert Wesarg, Geoffrey Irving,
Johannes Schindelin, Pierre Habouzit, Jeff King
In-Reply-To: <4F4D3545.6060704@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Now that options whose definition starts with "no-" can be negated
> by removing said "no-", there is no need anymore to allow them to
> be negated by adding a second "no-", which just looks silly.
Thanks. But accepting them silently and do what the user would have
expected, especially if we do not advertise it, would not hurt anybody,
no?
^ permalink raw reply
* Re: [PATCH] Documentation: use {asterisk} in rev-list-options.txt when needed
From: Junio C Hamano @ 2012-02-28 21:18 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Jeff King, git
In-Reply-To: <1330460423.691.15.camel@centaur.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> On Tue, 2012-02-28 at 14:45 -0500, Jeff King wrote:
>> On Tue, Feb 28, 2012 at 04:35:48PM +0100, Carlos Martín Nieto wrote:
>>
>> > Text between to '*' is emphasized in AsciiDoc which made the
>>
>> s/to/two/
>
> Oops. Thanks. Can you squash that in, Junio?
Thanks; done.
^ permalink raw reply
* Re: [PATCH] commit: allow {--amend|-c foo} when {HEAD|foo} has empty message
From: Junio C Hamano @ 2012-02-28 21:12 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, Thomas Rast, git
In-Reply-To: <20120228195931.GE11260@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Yeah, I agree that treating it like an empty body is reasonable
> (possibly with a warning). But given that nobody has actually seen this
> in the wild, maybe it is simpler to mark it with fsck, and to just die()
> when we see it. That would hopefully alert the author of the broken tool
> early, before the tools is made public. If it turns out that such
> commits do end up in the wild, then we can relax the behavior then.
Yeah, it is not like we would want to encourage a commit with empty body,
be it preceded with "\n\n" or just a "\n", in the first place.
We would need to locate all the places that expect that strstr("\n\n")
will find something, and add die("commit made with a broken git") at these
places anyway, in addition to the change to fsck. Given that, I suspect
that the extra amount of the work needed to tweak the code to tolerate
such a commit and keep going might not be so big, and going that route
would avoid punishing the users of broken versions of git (or broken
imitations of git, for that matter), so...
^ permalink raw reply
* Re: git (commit|tag) atomicity
From: Jon Jagger @ 2012-02-28 20:43 UTC (permalink / raw)
To: git
In-Reply-To: <4F4D2391.9020701@zabbo.net>
On Tue, Feb 28, 2012 at 6:57 PM, Zach Brown <zab@zabbo.net> wrote:
>
> It's a bit of a tangent, but just to be sure people don't get the wrong
> impression..
>
>
>> But I am not sure... that probably depends on how opendir(3) and
>> readdir(3) works on given filesystem wrt. updates to opened directory.
>> I think VFS on Linux ensures that you see view of filesystem as it was
>> on opendir().
>
>
> No, readdir() does not give you a static view of the entries in a
> directory as it was on opendir(). readdir() will reflect modifications
> that are done after opendir(). The specifics for a given situation
> depend on how the file system maps the readdir position (f_pos) to
> directory entries. You can see very different results when comparing,
> say, stock ext2, indexed ext[34], and btrfs.
Ok. Thanks.
^ permalink raw reply
* Re: Stash during incomplete merge
From: Neal Kreitzinger @ 2012-02-28 20:22 UTC (permalink / raw)
To: Phil Hord; +Cc: git@vger.kernel.org, Phil Hord
In-Reply-To: <4F4A7BC7.5010702@cisco.com>
On 2/26/2012 12:36 PM, Phil Hord wrote:
> Hi list,
>
> I was cherry-picking changes from an old branch recently when I ran into
> unexpected behavior with git stash pop. When I git-stash-save after
> resolving a merge-conflict, the subsequent git-stash-pop does not
> restore my index.
>
> I think it is the same problem being asked about here:
> http://stackoverflow.com/questions/9009354/git-stash-during-a-merge-conflict
>
> Is this expected behavior or a bug?
>
> <http://stackoverflow.com/questions/9009354/git-stash-during-a-merge-conflict>Here's
> a script the demonstrates the anomaly, but my actual encounter involved
> more files, some of which I added to the index and some I did not:
>
> # Create a sample merge-conflict
> git init tmp-repo&& cd tmp-repo
> echo foo> foo.txt&& git add foo.txt&& git commit -m "foo"
> git checkout -b A master&& echo foo-A> foo.txt&& git commit -am "foo-A"
> git checkout -b B master&& echo foo-B> foo.txt&& git commit -am "foo-B"
> git merge A
> git status
> # Resolve the conflict
> echo foo-AB> foo.txt&& git add foo.txt
> git status
> git stash
> # test test test... Resume...
> git stash pop
>
>
> Here's some of the final output:
>
> $ git merge A
> Auto-merging foo.txt
> CONFLICT (content): Merge conflict in foo.txt
> Recorded preimage for 'foo.txt'
> Automatic merge failed; fix conflicts and then commit the result.
>
> $ git status
> # On branch B
> # Unmerged paths:
> # (use "git add/rm<file>..." as appropriate to mark resolution)
> #
> # both modified: foo.txt
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> $ # Resolve the conflict
> $ echo foo-AB> foo.txt&& git add foo.txt
> $ git status
> # On branch B
> # Changes to be committed:
> #
> # modified: foo.txt
> #
>
> $ # Now foo.txt is in my index. But I have to test something before I
> commit.
> $ git stash
> Saved working directory and index state WIP on B: 80f2a13 foo-B
> HEAD is now at 80f2a13 foo-B
>
> $ # test test test... Resume...
> $ git stash pop
>
> # On branch B
> # Changes not staged for commit:
> # (use "git add<file>..." to update what will be committed)
> # (use "git checkout --<file>..." to discard changes in working
> directory)
> #
> # modified: foo.txt
> #
> no changes added to commit (use "git add" and/or "git commit -a")
> Dropped refs/stash@{0} (460a6d5c67a3db613fd27f1854ecc7b89eeaa207)
>
Was the foo.txt in your worktree still the same as the one you resolved
and added to the index?
If so, at that point you can just do "git add foo.txt" to put it back in
your index.
(merge conflict)
git add conflict-resolution (file is in worktree and index)
git stash (file is in stash of worktree and stash of index)
git stash pop (file is back in worktree but not back in index)
git add conflict-resolution (file is back in the index)
If not, then you must have a more complicated case like a modified
worktree version that differs from the index version (original conflict
resolution) in which case you need to also consider whether or not it is
an [a]"evil merge". Ideally, you intend to commit the index (conflict
resolution) as the merge commit and add any worktree mods in addition to
that as a commit after the merge commit. If so, then I see your problem.
The next time, you can get both the worktree version and the index
version back with:
git stash apply --index
git stash does not apply the index by default so you have to specify the
--index option if you want the index back also. I recommend git stash
apply instead of git stash pop in case you realize you forgot the index.
Then you can rerun git stash apply --index. git stash pop can only be
run once because it throws away the stash after popping it. You can run
git stash drop after you confirm that you did the git stash apply
correctly.
I assume you know that the stash is a stack and how to specify which
stash you want by using the reflog syntax (see git-stash manpage:
http://schacon.github.com/git/git-stash.html). Stashes are really
[b]"commit objects" of the worktree and index trees (you can see them in
gitk by viewing all refs), but they are treated according to "stash
rules" instead of "commit rules".
If you still want to try and get that conflict-resolution from the
"lost" index from that stash you popped you can try this variation of
the "Recovering stashes that were cleared/dropped erroneously" procedure
at the end of manpage:
(1) Find the lost stash:
$ git fsck --unreachable | grep commit | cut -d" " -f3 | xargs git log
--no-walk --grep=WIP --grep="index on"
(2) Review the list of commits and decide which pair is for the stash
you want. Note on stash commit-object messages:
WIP = stash commit-object of the worktree
"index on" = stash commit-object of the index (this may not exist of the
index didn't differ from the worktree)
(3) Reset the conflict-resolution-file(s) from the stash of the index:
$ git reset <sha1-of-stash-commit-object-of-index> --
<conflict-resolution-file>
git reset will just put it back in your index and leave the worktree alone.
You may also want to consider the --keep-index option on your "git stash
save" if your "testing" workflow doesn't involve adds or commits before
the git stash apply/pop.
Footnotes:
a. If you resolved the conflict and then made further mods that is
called an "evil merge" because you really didn't just merge the changes
of the two parents, but also made additional changes that were not part
of the changes made by either of the parents your are merging. The
additional changes really should be their own commit after the merge.
"Evil merges" are misleading (and also probably not documented in the
merge commit message with a git commit --amend).
b. There are only 4 types of objects in git: tag, commit, tree, blob.
Hope this helps. Maybe someone else has a better way to do this. Maybe
my assumptions are incorrect and I'm missing something about what you
are trying to do.
v/r,
neal
^ permalink raw reply
* Re: [PATCH] Documentation: use {asterisk} in rev-list-options.txt when needed
From: Carlos Martín Nieto @ 2012-02-28 20:20 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120228194551.GC11725@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]
On Tue, 2012-02-28 at 14:45 -0500, Jeff King wrote:
> On Tue, Feb 28, 2012 at 04:35:48PM +0100, Carlos Martín Nieto wrote:
>
> > Text between to '*' is emphasized in AsciiDoc which made the
>
> s/to/two/
Oops. Thanks. Can you squash that in, Junio?
>
> > glob-related explanations in rev-list-options.txt very confusing, as
> > the rendered text would be missing two asterisks and the text between
> > them would be emphasized instead.
> >
> > Use '{asterisk}' where needed to make them show up as asterisks in the
> > rendered text.
> > [...]
> > - '*', or '[', '/*' at the end is implied.
> > + '{asterisk}', or '[', '/{asterisk}' at the end is implied.
>
> Ugh. I hate asciidoc more with each passing year. Readable source
> documents are such a wonderful idea, but the markup makes it less and
> less readable as we accumulate fixes like this. I wonder if this has
> always been a bug, or something that appeared in more recent versions of
> the toolchain.
The generated documentation in the 'html' branch shows the wrong
formatting as well even for 1.7.0 when the --glob feature and its
explanation was first introduced. So either nobody reads the
documentation or very few people actually care about --glob and use the
--remotes and friends, where that part of the explanation isn't that
interesting.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH 4/3] parse-options: disallow --no-no-sth
From: René Scharfe @ 2012-02-28 20:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, git, Bert Wesarg, Geoffrey Irving,
Johannes Schindelin, Pierre Habouzit, Jeff King
In-Reply-To: <7vzkc457g3.fsf@alter.siamese.dyndns.org>
Now that options whose definition starts with "no-" can be negated
by removing said "no-", there is no need anymore to allow them to
be negated by adding a second "no-", which just looks silly.
The following thirteen options are affected:
apply --no-add
bisect--helper --no-checkout
checkout-index --no-create
clone --no-checkout --no-hardlinks
commit --no-verify --no-post-rewrite
format-patch --no-binary
hash-object --no-filters
read-tree --no-sparse-checkout
revert --no-commit
show-branch --no-name
update-ref --no-deref
E.g., with this patch --no-add and --add (its reverse) are still
accepted by git apply, but --no-no-add isn't anymore.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
parse-options.c | 3 +++
t/t0040-parse-options.sh | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/parse-options.c b/parse-options.c
index 1908996..dc59bba 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -248,6 +248,9 @@ is_abbreviated:
}
continue;
}
+ /* double negation? */
+ if (!prefixcmp(long_name, "no-"))
+ continue;
flags |= OPT_UNSET;
rest = skip_prefix(arg + 3, long_name);
/* abbreviated and negated? */
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index a44bcb9..b124f3c 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -101,11 +101,11 @@ test_expect_success 'OPT_BOOL() #5' 'check boolean: 1 -B'
test_expect_success 'OPT_BOOL() is idempotent #1' 'check boolean: 1 --yes --yes'
test_expect_success 'OPT_BOOL() is idempotent #2' 'check boolean: 1 -DB'
-test_expect_success 'OPT_BOOL() negation #1' 'check boolean: 0 -D --no-yes'
-test_expect_success 'OPT_BOOL() negation #2' 'check boolean: 0 -D --no-no-doubt'
+test_expect_success 'OPT_BOOL() negation' 'check boolean: 0 -D --no-yes'
test_expect_success 'OPT_BOOL() no negation #1' 'check_unknown --fear'
test_expect_success 'OPT_BOOL() no negation #2' 'check_unknown --no-no-fear'
+test_expect_success 'OPT_BOOL() no negation #3' 'check_unknown --no-no-doubt'
test_expect_success 'OPT_BOOL() positivation' 'check boolean: 0 -D --doubt'
--
1.7.9.2
^ permalink raw reply related
* Re: [PATCH] commit: allow {--amend|-c foo} when {HEAD|foo} has empty message
From: Jeff King @ 2012-02-28 19:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Thomas Rast, git
In-Reply-To: <7vr4xe27sq.fsf@alter.siamese.dyndns.org>
On Tue, Feb 28, 2012 at 09:21:09AM -0800, Junio C Hamano wrote:
> Thomas Rast <trast@inf.ethz.ch> writes:
>
> > So either there's a lot to be fixed, or fsck needs to catch this.
>
> Your experiment with hash-object aside (that is like saying "I can write
> garbage with a disk editor, and now OS cannot read from that directory"),
Yes, but the difference between "OS cannot read from that directory" and
"OS segfaults" might be worth noticing. :)
> if somebody manages to create a commit without any body, it is clear that
> the user wanted to record no body. I think all code that tries to run
> strstr("\n\n") and increment the resulting pointer by two to find the
> beginning of the body should behave as if it found one and the result
> pointed at a NUL. Rejecting with fsck does not help anybody, as it
> happens after the fact.
Yeah, I agree that treating it like an empty body is reasonable
(possibly with a warning). But given that nobody has actually seen this
in the wild, maybe it is simpler to mark it with fsck, and to just die()
when we see it. That would hopefully alert the author of the broken tool
early, before the tools is made public. If it turns out that such
commits do end up in the wild, then we can relax the behavior then.
-Peff
^ permalink raw reply
* Re: Delivery Status Notification (Failure)
From: Jeff King @ 2012-02-28 19:48 UTC (permalink / raw)
To: Rajat Khanduja; +Cc: git
In-Reply-To: <CAAymXMrrQakreKgSjrqBGM4ea1fH8cRWPE=7PbcxPi4dz_hxtw@mail.gmail.com>
On Wed, Feb 29, 2012 at 12:32:37AM +0530, Rajat Khanduja wrote:
> I am a student interested in participating in GSOC'12 and was curious
> to know if Git is participating in the program this year.
We haven't applied yet, but I think we are planning on it. Getting our
application started is on my to-do list this week.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: use {asterisk} in rev-list-options.txt when needed
From: Jeff King @ 2012-02-28 19:45 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1330443348-5742-1-git-send-email-cmn@elego.de>
On Tue, Feb 28, 2012 at 04:35:48PM +0100, Carlos Martín Nieto wrote:
> Text between to '*' is emphasized in AsciiDoc which made the
s/to/two/
> glob-related explanations in rev-list-options.txt very confusing, as
> the rendered text would be missing two asterisks and the text between
> them would be emphasized instead.
>
> Use '{asterisk}' where needed to make them show up as asterisks in the
> rendered text.
> [...]
> - '*', or '[', '/*' at the end is implied.
> + '{asterisk}', or '[', '/{asterisk}' at the end is implied.
Ugh. I hate asciidoc more with each passing year. Readable source
documents are such a wonderful idea, but the markup makes it less and
less readable as we accumulate fixes like this. I wonder if this has
always been a bug, or something that appeared in more recent versions of
the toolchain.
Anyway, that is not a problem with your patch. :) I confirmed that the
bug happens in my version of the toolchain, and your fix works (I also
tried using `*`, but backtick does not suppress markup. It would be nice
if there was an easy marker for "this is a literal name: no markup, tt
font, etc", but I don't think that exists).
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: [PATCH (BUGFIX)] gitweb: Handle invalid regexp in regexp search
From: Junio C Hamano @ 2012-02-28 19:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Ramsay Jones
In-Reply-To: <20120228183919.26435.86795.stgit@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> When using regexp search ('sr' parameter / $search_use_regexp variable
> is true), check first that regexp is valid.
Thanks.
How old is this bug? Should it go to older maitenance tracks like 1.7.6?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox