* Re: [PATCH] Support working directory located at root
From: Nguyen Thai Ngoc Duy @ 2010-02-09 2:18 UTC (permalink / raw)
To: Junio C Hamano, Johannes Sixt; +Cc: git, João Carlos Mendes Luís
In-Reply-To: <7v8wb3pqqw.fsf@alter.siamese.dyndns.org>
2010/2/9 Junio C Hamano <gitster@pobox.com>:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> Git should work regardless where the working directory is located,
>> even at root. This patch fixes two places where it assumes working
>> directory always have parent directory.
>>
>> In setup_git_directory_gently(), when Git goes up to root and finds
>> .git there, it happily sets worktree to "".
>
> If you mean "instead set it to "/" and things will work much better."
> I agree with the reasoning (not suggesting to reword---just trying to
> make sure I understood what you meant).
Yes.
>
>> In prefix_path(), loosen the outside repo check a little bit. Usually
>> when a path XXX is inside worktree /foo, it must be either "/foo", or
>> "/foo/...". When worktree is simply "/", we can safely ignore the
>> check: we have a slash at the beginning already.
>
> The logic for the "are we inside?" check above sounds correct. When
> work_tree is at root, have "/" in it, and len inside the "if orig is
> absolute" block is 1, so memmove() strips out the leading '/' and makes
> the result relative to the root level. Am I reading the code right?
You are. But I suspect my change in this code is not enough and caused
the problem (on msys?) for Hannes. If the worktree somehow is '//' and
sanitized is '/etc/resolv.conf', then we could end up eating two
chars, leading to "'tc/resolv.conf' not match" error.
Hannes, can you put a "printf("%s\n", work_tree);" in prefix_path() to
see if it's the case?
--
Duy
^ permalink raw reply
* Re: [PATCH] Support working directory located at root
From: Nguyen Thai Ngoc Duy @ 2010-02-09 2:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, João Carlos Mendes Luís, Junio C Hamano
In-Reply-To: <fcaeb9bf1002081818s53f8646ev80afbaa37f039e50@mail.gmail.com>
2010/2/9 Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
> But I suspect my change in this code is not enough and caused
> the problem (on msys?) for Hannes. If the worktree somehow is '//' and
> sanitized is '/etc/resolv.conf', then we could end up eating two
> chars, leading to "'tc/resolv.conf' not match" error.
>
> Hannes, can you put a "printf("%s\n", work_tree);" in prefix_path() to
> see if it's the case?
Silly me. You used relative path, so that code path was untouched.
--
Duy
^ permalink raw reply
* Re: [PATCH] Generate a warning message if we find an unrecognized option.
From: Jeff King @ 2010-02-09 3:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeremy White, git
In-Reply-To: <7vvde7z0kf.fsf@alter.siamese.dyndns.org>
On Mon, Feb 08, 2010 at 04:59:12PM -0800, Junio C Hamano wrote:
> > And obviously that is weighed against the ability to notice things like
> > typos. But if we are going to start complaining about unknown config, we
> > would probably do better to complain about _all_ unknown config, and not
> > just this one subsection.
>
> We would probably want something like:
>
> static int do_warn_unknown_config;
>
> void warn_unknown_config(const char *key)
> {
> if (do_warn_unknown_config)
> warn("Unknown configuration variable %s", key);
> }
>
> and sprinkle that everywhere.
Your "sprinkle that everywhere" is a little harder than one might hope.
There is no code path that reads and claims to recognize _all_ of the
git config. In many cases, the git_*_config for individual subsystems
can reasonably lay claim to the whole of a "[heading]" section. But
there are exceptions even to that.
Diff config is split across git_diff_basic_config and
git_diff_ui_config. You would certainly not want to warn about
diff.color.* just because you are running a plumbing command which
happens not to recognize those entries.
And some headings have entries for several subsystems. remote.*.fetch is
used many places for calculating upstream branches. But only git-remote
looks at remote.*.skipDefaultUpdate.
So in practice I think you will get quite spotty coverage. Which isn't
to say it isn't necessarily worth doing, but I am personally not very
excited about working on it. I do like the suggestion of making it
optional, so that people who don't care about having a portable config
can have the benefit of sanity-checking their config.
> An interesting issue is where to flip do_warn_unknown_config. A naïve
> and obvious implementation would do:
>
> static int git_default_core_config(const char *var, const char *value)
> {
> ...
> if (!strcmp(var, "core.warnunknownconfig")) {
> do_warn_unknown_config = git_config_bool(var, value);
> return 0;
> }
> ...
> }
>
> but that means the definition of this variable has to come very early in
> the configuration file to be effective.
I would rather have a "git config --lint" command, but that is even
harder, since we are not even loading most of the subsystems which know
about the valid config options. And it presupposes that people will
bother to actually run such a lint command.
You could always just hoist into an environment variable which neatly
gets rid of the ordering problem.
-Peff
^ permalink raw reply
* blame -L questions
From: Jay Soffian @ 2010-02-09 3:03 UTC (permalink / raw)
To: git, Junio C Hamano
Junio,
I'd like git blame to be able to emit multiple blocks when using it
with -L /start/,/end/.
My use case is emitting blocks that are wrapped in
#if defined(WHATEVER)
....
#endif
I was going to use the syntax -L /start/../end/ for this.
I naively thought I might just be able to setup multiple blame_entry's
linked through the next/prev pointers at the start, but that clearly
does not work.
So I was wondering if you could give me any tips about how the
scoreboard, blame_entry, and origin all fit together before I injure
myself. :-)
Thanks,
j.
^ permalink raw reply
* Re: blame -L questions
From: Junio C Hamano @ 2010-02-09 3:32 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718491002081903s2e37875bs85eeb55779167ce7@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> My use case is emitting blocks that are wrapped in
>
> #if defined(WHATEVER)
> ....
> #endif
>
> I was going to use the syntax -L /start/../end/ for this.
>
> I naively thought I might just be able to setup multiple blame_entry's
> linked through the next/prev pointers at the start, but that clearly
> does not work.
The current -L parser is prepared to take only one range, but the
underlying data structure should be able to support what you want to do.
The scoreboard holds one final image (final_buf, final_buf_size) that is
the whole blob in the revision being annotated. Without -L, we start with
one blame entry in ent that covers the whole lines in this image. With a
single -L (i.e. the current implementation), this single ent covers a bit
narrower range of lines than the whole file.
A blame_entry records a range of lines (lno, num_lines) and which path
from what commit is the current suspect. We iteratively compare this
with parents of the suspect to see if we can pass blame for some lines
in the given range to some parents. When we can pass blame for the
whole range, we just update the "suspect" to parent; when we can pass
blame for some but not for other lines in the range, we break the
blame_entry into pieces, pass blame to parents for lines that came
from those parents and declare the current suspect for lines that did
not appear in any of the parents.
But this part does not concern you very much. The only thing you need
to know for what you want to do is how an ent must be initialized.
You should be able to start with more than one blame entry queued in ent
member of the scoreboard, each representing one range given by an -L
option, and as long as you prime these blame entries correctly, everything
should work just fine. sb->ent is supposed to be sorted by line number
and not have overlap, but I don't think they have to be contiguous.
^ permalink raw reply
* OS X Unicode Normalization Hits Again
From: Brian Gernhardt @ 2010-02-09 3:38 UTC (permalink / raw)
To: Git List
git fails test t3902-quoted for me starting with 8424981: Fix invalid read in quote_c_style_counted
The problem isn't with the code, or the test. It's that OS X is "normalizing" the file paths again.
diff --git a/t/t3902-quoted.sh b/t/t3902-quoted.sh
index 5868052..14da45f 100755
--- a/t/t3902-quoted.sh
+++ b/t/t3902-quoted.sh
@@ -33,6 +33,7 @@ for_each_name () {
test_expect_success setup '
+ mkdir "caractère spécial" &&
for_each_name "echo initial >\"\$name\""
git add . &&
git commit -q -m Initial &&
Git makes the directory "caract\303\250re sp\303\251cial" but OS X stores "caracte\314\200re spe\314\201cial".
Should I just alter the test to use the same form as OS X, or is there a better method?
~~ Brian
^ permalink raw reply related
* Re: OS X Unicode Normalization Hits Again
From: Junio C Hamano @ 2010-02-09 3:44 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <C417EBAD-9254-448C-9FD1-2D2FABB8CF32@gernhardtsoftware.com>
How about using $FN as the directory name instead?
^ permalink raw reply
* [PATCH] blame: prevent a segv when -L given start > EOF
From: Jay Soffian @ 2010-02-09 3:48 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Jay Soffian
blame would segv if given -L <lineno> with <lineno> past the end of the file.
While we're fixing the bug, add test cases for an invalid <start> when called
as -L <start>,<end> or -L<start>.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
bottom is start and top is end, which seems backwards to me, but alas, it is
what it is. :-)
builtin-blame.c | 2 +-
t/t8003-blame.sh | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index 6408ec8..10f7eac 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -2433,7 +2433,7 @@ parse_done:
if (top < 1)
top = lno;
bottom--;
- if (lno < top)
+ if (lno < top || lno < bottom)
die("file %s has only %lu lines", path, lno);
ent = xcalloc(1, sizeof(*ent));
diff --git a/t/t8003-blame.sh b/t/t8003-blame.sh
index ad834f2..4a8db74 100755
--- a/t/t8003-blame.sh
+++ b/t/t8003-blame.sh
@@ -157,4 +157,12 @@ EOF
git --no-pager blame $COMMIT -- uno >/dev/null
'
+test_expect_success 'blame -L with invalid start' '
+ test_must_fail git blame -L5 tres 2>&1 | grep "has only 2 lines"
+'
+
+test_expect_success 'blame -L with invalid end' '
+ git blame -L1,5 tres 2>&1 | grep "has only 2 lines"
+'
+
test_done
--
1.7.0.rc1.200.g9c1f9
^ permalink raw reply related
* Re: [PATCH] blame: prevent a segv when -L given start > EOF
From: Jay Soffian @ 2010-02-09 3:50 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <1265687293-11168-1-git-send-email-jaysoffian@gmail.com>
On Mon, Feb 8, 2010 at 10:48 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> +test_expect_success 'blame -L with invalid start' '
> + test_must_fail git blame -L5 tres 2>&1 | grep "has only 2 lines"
> +'
Sorry, please remove test_must_fail after applying. Otherwise correct.
j.
^ permalink raw reply
* Re: [PATCH] blame: prevent a segv when -L given start > EOF
From: Junio C Hamano @ 2010-02-09 3:55 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <1265687293-11168-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> - if (lno < top)
> + if (lno < top || lno < bottom)
> die("file %s has only %lu lines", path, lno);
Thanks; I think we make sure that "bottom < top" always hold true before
we reach this point, so checking with bottom alone should suffice, no?
^ permalink raw reply
* Re: [PATCH] blame: prevent a segv when -L given start > EOF
From: Jay Soffian @ 2010-02-09 4:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtytrrrju.fsf@alter.siamese.dyndns.org>
On Mon, Feb 8, 2010 at 10:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> - if (lno < top)
>> + if (lno < top || lno < bottom)
>> die("file %s has only %lu lines", path, lno);
>
> Thanks; I think we make sure that "bottom < top" always hold true before
> we reach this point,
We swap them if they're reversed.
> so checking with bottom alone should suffice, no?
Ah true. You can squash that in? :-)
j.
^ permalink raw reply
* Re: [PATCH] blame: prevent a segv when -L given start > EOF
From: Jay Soffian @ 2010-02-09 4:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <76718491002082000s7be5b32dob5b3dfe764b12da0@mail.gmail.com>
On Mon, Feb 8, 2010 at 11:00 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
>> so checking with bottom alone should suffice, no?
>
> Ah true. You can squash that in? :-)
Actually, no, that doesn't work, but my head can't keep bottom=start,
top=end straight so I'm not even sure why not.
j.
^ permalink raw reply
* [PATCH] t9302: Protect against OS X normalization
From: Brian Gernhardt @ 2010-02-09 4:07 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
In-Reply-To: <7vfx5bt6nn.fsf@alter.siamese.dyndns.org>
8424981: "Fix invalid read in quote_c_style_counted" introduced a test
that used "caractère spécial" as a directory name.
Git creates it as "caract\303\250re sp\303\251cial"
OS X stores it as "caracte\314\200re spe\314\201cial"
To work around this problem, use the already introduced $FN as the
directory name.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
---
Junio C Hamano wrote:
> How about using $FN as the directory name instead?
I knew there was a clever answer I was missing.
t/t3902-quoted.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t3902-quoted.sh b/t/t3902-quoted.sh
index 14da45f..29103f6 100755
--- a/t/t3902-quoted.sh
+++ b/t/t3902-quoted.sh
@@ -25,7 +25,7 @@ for_each_name () {
for name in \
Name "Name and a${LF}LF" "Name and an${HT}HT" "Name${DQ}" \
"$FN$HT$GN" "$FN$LF$GN" "$FN $GN" "$FN$GN" "$FN$DQ$GN" \
- "With SP in it" "caractère spécial/file"
+ "With SP in it" "$FN/file"
do
eval "$1"
done
@@ -33,7 +33,7 @@ for_each_name () {
test_expect_success setup '
- mkdir "caractère spécial" &&
+ mkdir "$FN" &&
for_each_name "echo initial >\"\$name\""
git add . &&
git commit -q -m Initial &&
@@ -51,11 +51,11 @@ Name
"Name and an\tHT"
"Name\""
With SP in it
-"caract\303\250re sp\303\251cial/file"
"\346\277\261\351\207\216\t\347\264\224"
"\346\277\261\351\207\216\n\347\264\224"
"\346\277\261\351\207\216 \347\264\224"
"\346\277\261\351\207\216\"\347\264\224"
+"\346\277\261\351\207\216/file"
"\346\277\261\351\207\216\347\264\224"
EOF
@@ -65,11 +65,11 @@ Name
"Name and an\tHT"
"Name\""
With SP in it
-caractère spécial/file
"濱野\t純"
"濱野\n純"
濱野 純
"濱野\"純"
+濱野/file
濱野純
EOF
--
1.7.0.rc1.49.gd2d66
^ permalink raw reply related
* Re: [PATCH] blame: prevent a segv when -L given start > EOF
From: Jay Soffian @ 2010-02-09 4:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtytrrrju.fsf@alter.siamese.dyndns.org>
On Mon, Feb 8, 2010 at 10:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> - if (lno < top)
>> + if (lno < top || lno < bottom)
>> die("file %s has only %lu lines", path, lno);
>
> Thanks; I think we make sure that "bottom < top" always hold true before
> we reach this point, so checking with bottom alone should suffice, no?
Right, so given "-L 10" at the point of that check:
bottom = 0
top = 10
Whereas given "-L 10,100" at the point of that check:
bottom = 9
top = 100
So the code needs to check both. Previously it made sure neither was
< 1, and swapped bottom/top if they were reversed.
Sorry for the confusion.
j.
^ permalink raw reply
* Re: [PATCH v3 2/3] git-push: clean up some of the output from git push --porcelain
From: Larry D'Anna @ 2010-02-09 4:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vpr4f9wey.fsf@alter.siamese.dyndns.org>
* Junio C Hamano (gitster@pobox.com) [100208 17:48]:
> *1* As I hinted repeatedly, I think many of them are mere churn, except
> for "don't advice porcelain scripts" (good) and perhaps "exit with failure
> status upon only this kind of failure" (I am undecided).
What about the "To" lines? It seems that they really should go to stdout (if
--porcelain is selected). Otherwise, how does the reader of stdout know which
refs got pushed to which remote?
^ permalink raw reply
* Re: [PATCH] Generate a warning message if we find an unrecognized option.
From: David Aguilar @ 2010-02-09 5:17 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Jeremy White, git
In-Reply-To: <20100209030151.GA5370@coredump.intra.peff.net>
On Mon, Feb 08, 2010 at 10:01:51PM -0500, Jeff King wrote:
> On Mon, Feb 08, 2010 at 04:59:12PM -0800, Junio C Hamano wrote:
>
> > > And obviously that is weighed against the ability to notice things like
> > > typos. But if we are going to start complaining about unknown config, we
> > > would probably do better to complain about _all_ unknown config, and not
> > > just this one subsection.
No, please, please no.
> So in practice I think you will get quite spotty coverage. Which isn't
> to say it isn't necessarily worth doing, but I am personally not very
> excited about working on it. I do like the suggestion of making it
> optional, so that people who don't care about having a portable config
> can have the benefit of sanity-checking their config.
>
> I would rather have a "git config --lint" command, but that is even
> harder, since we are not even loading most of the subsystems which know
> about the valid config options. And it presupposes that people will
> bother to actually run such a lint command.
This runs up against the same issue you pointed out
earlier--that older versions of git cannot adequately lint
configs from newer versions.
There are also config variables from unknown git scripts outside
of git.git that happen to use the git-config mechanism because
it is convenient. It would be unfortunate to punish those who
chose to make up their own config variables by warning them
that git doesn't know about them.
I have to wonder if this is a non-existent problem.
Config variables are one-shot things. You set them and forget
about them. When you set it you are usually pretty well aware
of whether it's typoed because it simply does't work.
color.ui is a perfect example. If it's typoed, you don't need
'git config --lint' to tell you, you already know by virtue of
using the thing.
Maintaining 'git config --lint' would also be a PITA since we'd
then have to remember to update yet another place in addition to
code and documentation. And who's to say what gets to be "in"
and what doesn't? git-gui, for example, has its own [gui]
namespace. git-p4 has its own [git-p4] namespace, but it
lives in contrib/, etc. etc.
This seems like a bad idea to me.
--
David
^ permalink raw reply
* Re: [PATCH v3 2/3] git-push: clean up some of the output from git push --porcelain
From: Larry D'Anna @ 2010-02-09 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vpr4f9wey.fsf@alter.siamese.dyndns.org>
* Junio C Hamano (gitster@pobox.com) [100208 17:48]:
> *1* As I hinted repeatedly, I think many of them are mere churn, except
> for "don't advice porcelain scripts" (good) and perhaps "exit with failure
> status upon only this kind of failure" (I am undecided). Especially I
> want to see the "send advice to the standard error stream" one as a
> separate patch, if you insist including that change in the series.
For some reason I thought you wanted the series squashed into one patch. Here
it is again (to follow) with each discrete change as a single patch, and without
messing with "Everything up-to-date"
--larry
^ permalink raw reply
* [PATCH 2/4] git-push: squelch advice message if in --porcelain mode
From: Larry D'Anna @ 2010-02-09 5:54 UTC (permalink / raw)
To: git; +Cc: Larry D'Anna
In-Reply-To: <20100209054820.GA30907@cthulhu>
By default, git-push may give the user a verbose advice message if a ref is
rejected for not being a fast-forward. This patch squelches that message for
--porcelain mode.
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
---
builtin-push.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 0a27072..aacba45 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -226,6 +226,11 @@ int cmd_push(int argc, const char **argv, const char *prefix)
git_config(git_default_config, NULL);
argc = parse_options(argc, argv, prefix, options, push_usage, 0);
+ if (flags & TRANSPORT_PUSH_PORCELAIN) {
+ /* Do not give advice messages to Porcelain scripts */
+ advice_push_nonfastforward = 0;
+ }
+
if (deleterefs && (tags || (flags & (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR))))
die("--delete is incompatible with --all, --mirror and --tags");
if (deleterefs && argc < 2)
--
1.7.0.rc1.33.g07cf0f.dirty
^ permalink raw reply related
* [PATCH 1/4] git-push: fix an error message so it goes to stderr
From: Larry D'Anna @ 2010-02-09 5:53 UTC (permalink / raw)
To: git; +Cc: Larry D'Anna
In-Reply-To: <20100209054820.GA30907@cthulhu>
These sort of messages typically go to the standard error.
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
---
builtin-push.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 5633f0a..0a27072 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -124,9 +124,9 @@ static int push_with_options(struct transport *transport, int flags)
return 0;
if (nonfastforward && advice_push_nonfastforward) {
- printf("To prevent you from losing history, non-fast-forward updates were rejected\n"
- "Merge the remote changes before pushing again. See the 'Note about\n"
- "fast-forwards' section of 'git push --help' for details.\n");
+ fprintf(stderr, "To prevent you from losing history, non-fast-forward updates were rejected\n"
+ "Merge the remote changes before pushing again. See the 'Note about\n"
+ "fast-forwards' section of 'git push --help' for details.\n");
}
return 1;
--
1.7.0.rc1.33.g07cf0f.dirty
^ permalink raw reply related
* [PATCH 3/4] git-push: send "To <remoteurl>" messages to the standard output in --porcelain mode
From: Larry D'Anna @ 2010-02-09 5:54 UTC (permalink / raw)
To: git; +Cc: Larry D'Anna
In-Reply-To: <20100209054820.GA30907@cthulhu>
git-push prints the line "To <remoteurl>" before above each of the ref status
lines. In --porcelain mode, these "To <remoteurl>" lines go to the standard
error, but the ref status lines go to the standard output. This makes it
difficult for the process reading standard output to know which ref status lines
correspond to which remote. This patch sends the "To <remoteurl>" lines to the
the standard output instead.
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
---
transport.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/transport.c b/transport.c
index 3846aac..fb653c6 100644
--- a/transport.c
+++ b/transport.c
@@ -675,7 +675,7 @@ static void print_ok_ref_status(struct ref *ref, int porcelain)
static int print_one_push_status(struct ref *ref, const char *dest, int count, int porcelain)
{
if (!count)
- fprintf(stderr, "To %s\n", dest);
+ fprintf(porcelain ? stdout : stderr, "To %s\n", dest);
switch(ref->status) {
case REF_STATUS_NONE:
--
1.7.0.rc1.33.g07cf0f.dirty
^ permalink raw reply related
* [PATCH 4/4] git-push: make git push --dry-run --porcelain exit with status 0 even if updates will be rejected
From: Larry D'Anna @ 2010-02-09 5:54 UTC (permalink / raw)
To: git; +Cc: Larry D'Anna
In-Reply-To: <20100209054820.GA30907@cthulhu>
The script calling git push --dry-run --porcelain can see clearly from the
output that the updates will be rejected. However, it will probably need to
distinguish this condition from the push failing for other reasons, such as the
remote not being reachable.
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
---
builtin-send-pack.c | 4 ++++
send-pack.h | 1 +
transport.c | 3 ++-
3 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 76c7206..358f5e1 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -476,6 +476,10 @@ int send_pack(struct send_pack_args *args,
if (ret < 0)
return ret;
+
+ if (args->porcelain && args->dry_run)
+ return 0;
+
for (ref = remote_refs; ref; ref = ref->next) {
switch (ref->status) {
case REF_STATUS_NONE:
diff --git a/send-pack.h b/send-pack.h
index 28141ac..60b4ba6 100644
--- a/send-pack.h
+++ b/send-pack.h
@@ -4,6 +4,7 @@
struct send_pack_args {
unsigned verbose:1,
quiet:1,
+ porcelain:1,
send_mirror:1,
force_update:1,
use_thin_pack:1,
diff --git a/transport.c b/transport.c
index fb653c6..0edcc16 100644
--- a/transport.c
+++ b/transport.c
@@ -791,6 +791,7 @@ static int git_transport_push(struct transport *transport, struct ref *remote_re
args.verbose = !!(flags & TRANSPORT_PUSH_VERBOSE);
args.quiet = !!(flags & TRANSPORT_PUSH_QUIET);
args.dry_run = !!(flags & TRANSPORT_PUSH_DRY_RUN);
+ args.porcelain = !!(flags & TRANSPORT_PUSH_PORCELAIN);
ret = send_pack(&args, data->fd, data->conn, remote_refs,
&data->extra_have);
@@ -1052,7 +1053,7 @@ int transport_push(struct transport *transport,
flags & TRANSPORT_PUSH_FORCE);
ret = transport->push_refs(transport, remote_refs, flags);
- err = push_had_errors(remote_refs);
+ err = (pretend && porcelain) ? 0 : push_had_errors(remote_refs);
ret |= err;
--
1.7.0.rc1.33.g07cf0f.dirty
^ permalink raw reply related
* Re: [PATCH] blame: prevent a segv when -L given start > EOF
From: Junio C Hamano @ 2010-02-09 5:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, git
In-Reply-To: <7vtytrrrju.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> - if (lno < top)
>> + if (lno < top || lno < bottom)
>> die("file %s has only %lu lines", path, lno);
>
> Thanks; I think we make sure that "bottom < top" always hold true before
> we reach this point, so checking with bottom alone should suffice, no?
I am ... stupid. If lno < bottom, then lno < top, but we need to check
both anyway.
^ permalink raw reply
* [ANNOUNCE] TortoiseGit 1.3.6.0 Release
From: Frank Li @ 2010-02-09 5:58 UTC (permalink / raw)
To: tortoisegit-dev, tortoisegit-announce, tortoisegit-users, git
Download:
http://tortoisegit.googlecode.com/files/TortoiseGit-1.3.6.0-32bit.msi
http://tortoisegit.googlecode.com/files/TortoiseGit-1.3.6.0-64bit.msi
= Release 1.3.6.0 =
== Bug Fix ==
* Fixed log crash when no body message at commit
* Fixed issue #298: State of "View Patch/Hide Patch" link (commit
window) is wrong in some ways
* Fixed issue #301: Show Log crashes with empty repo
= Release 1.3.5.0 =
== Features ==
* Support Annotated tags
Implemented issue #274: Enhancement: Annotated tags
* shallow clones support --depth at clone dialog
Fixed issue #290: Shallow clones support --depth at clone dialog
* Improve Diff Dialog
Change commit at diff dialog
Diff commit context menu show in git repository
* Log Dialog
Direct Launch external diff when open dialog at file
Log can refresh when Click Rev button.
* Context menu
Use setting dialog to control which menuitem is external menu.
* Sync Dialog
Add remote update at sync dialog
== Bug Fix ==
* Fixed issue #294: commit template not supported and support msysgit unix path
* Fixed issue #282: Fom/To/Messages/Authors/Paths filters are
eventually disabled
* Fixed issue #292: Very large dialog when merging
* Fixed issue #291: Blame makes empty "UserImages.bmp" file
* Fix crash when copy several log message to clipboards
* Fixed issue #284: Show Log crashes when switching branches wait for
log thread exit
* Fixed issue #285: Cherry picking no longer works
* Fix fetch command can't sync remote branch at sync dialog
^ permalink raw reply
* Re: [PATCH] Generate a warning message if we find an unrecognized option.
From: Jeff King @ 2010-02-09 5:59 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Jeremy White, git
In-Reply-To: <20100209051730.GA28599@gmail.com>
On Mon, Feb 08, 2010 at 09:17:31PM -0800, David Aguilar wrote:
> > > > And obviously that is weighed against the ability to notice things like
> > > > typos. But if we are going to start complaining about unknown config, we
> > > > would probably do better to complain about _all_ unknown config, and not
> > > > just this one subsection.
>
> No, please, please no.
I would only be OK with it if it were optional.
> > I would rather have a "git config --lint" command, but that is even
> > harder, since we are not even loading most of the subsystems which know
> > about the valid config options. And it presupposes that people will
> > bother to actually run such a lint command.
>
> This runs up against the same issue you pointed out
> earlier--that older versions of git cannot adequately lint
> configs from newer versions.
Yeah, but that isn't a big deal. You just don't run "config --lint" with
the older version. But if, for example, "git diff" breaks because your
config is too new, then that is a real pain (and that was what happened
with color.diff.func recently).
> There are also config variables from unknown git scripts outside
> of git.git that happen to use the git-config mechanism because
> it is convenient. It would be unfortunate to punish those who
> chose to make up their own config variables by warning them
> that git doesn't know about them.
Yes, I don't think anyone is proposing to lint _all_ variables. But it
does not seem unreasonable for certain subsystems to claim portions of
the namespace. I would expect git-core to own "core.*". And I would
expect git-gui to own "git-gui", etc.
> I have to wonder if this is a non-existent problem.
>
> Config variables are one-shot things. You set them and forget
> about them. When you set it you are usually pretty well aware
> of whether it's typoed because it simply does't work.
> color.ui is a perfect example. If it's typoed, you don't need
> 'git config --lint' to tell you, you already know by virtue of
> using the thing.
I think I agree with you on this. It is _much_ more annoying to me not
to have version portability than it is not to have strict config
checking. I was mainly trying to put myself in the shoes of "regular"
users, who are less likely to be running the same config file on many
different versions, and are more likely to be clueless about config. But
I may have overcompensated.
-Peff
^ permalink raw reply
* Re: [PATCH] t9302: Protect against OS X normalization
From: Jeff King @ 2010-02-09 6:08 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Junio C Hamano
In-Reply-To: <1265688445-46137-1-git-send-email-brian@gernhardtsoftware.com>
On Mon, Feb 08, 2010 at 11:07:25PM -0500, Brian Gernhardt wrote:
> 8424981: "Fix invalid read in quote_c_style_counted" introduced a test
> that used "caractère spécial" as a directory name.
>
> Git creates it as "caract\303\250re sp\303\251cial"
> OS X stores it as "caracte\314\200re spe\314\201cial"
>
> To work around this problem, use the already introduced $FN as the
> directory name.
>
> Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
> ---
>
> Junio C Hamano wrote:
> > How about using $FN as the directory name instead?
>
> I knew there was a clever answer I was missing.
I am not 100% sure this will still trigger the failure that 8424981 was
meant to fix. From my recollection of the bug, it not only needed an
unterminated string (which we get by having a directory) but the string
length and presence of multiple spread-out characters may have been
relevant.
Of course, that specific bug is fixed, so maybe it is not worth worrying
about too much.
-Peff
^ 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