* Re: Improving merge failure message
From: Nanako Shiraishi @ 2009-09-08 10:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiqhgb4y.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Notable points are:
>
> - End the messages with "Aborting."; they are given when the three-way
> merge stops without harming the work tree;
>
> - Do not give the extra message after unpack_trees() already errored out.
> This "merging of trees failed" message was primarily for debugging
> merge-recursive itself, and the end user cannot do much with the object
> names given in the message anyway.
>
> But do give it under higher verbosity level, or when it happens during
> the inner merge (the "recursive" one), as unpack_trees() should not
> fail for the inner merge under normal conditions.
>
> We could later add instructions on how to recover (i.e. "stash changes
> away or commit on a side branch and retry") instead of the silent
> exit(128) I have down there, and then use Peff's advice.* mechanism to
> squelch it (e.g. "advice.mergeindirtytree"), but they are separate topics.
Thank you for a quick response. The patch works fine here, so if you want
please add:
Tested-by: Nanako Shiraishi <nanako3@lavabit.com>
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] post-receive-email: do not call sendmail if no mail was generated
From: Lars Noschinski @ 2009-09-08 9:20 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1251481187-6361-1-git-send-email-lars@public.noschinski.de>
* Lars Noschinski <lars@public.noschinski.de> [09-08-28 19:39]:
> contrib/hooks/post-receive-email used to call the send_mail function
> (and thus, /usr/sbin/sendmail), even if generate_mail returned an error.
> This is problematic, as the sendmail binary provided by exim4 generates
> an error mail if provided with an empty input.
>
> Therefore, this commit changes post-receive-email to only call sendmail
> if generate_mail returned without error.
>
> Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
Is anything wrong with this patch? Or is it just queued to be committed
some time?
- Lars.
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Johannes Schindelin @ 2009-09-08 9:32 UTC (permalink / raw)
To: Johan Herland
Cc: Junio C Hamano, git, trast, tavestbo, git, chriscool, spearce
In-Reply-To: <200909081054.02523.johan@herland.net>
Hi,
On Tue, 8 Sep 2009, Johan Herland wrote:
> Algorithm / Notes tree git log -n10 (x100) git log --all
> ------------------------------------------------------------
> next / no-notes 4.77s 63.84s
>
> before / no-notes 4.78s 63.90s
> before / no-fanout 56.85s 65.69s
>
> 16tree / no-notes 4.77s 64.18s
> 16tree / no-fanout 30.35s 65.39s
> 16tree / 2_38 5.57s 65.42s
> 16tree / 2_2_36 5.19s 65.76s
>
> flexible / no-notes 4.78s 63.91s
> flexible / no-fanout 30.34s 65.57s
> flexible / 2_38 5.57s 65.46s
> flexible / 2_2_36 5.18s 65.72s
> flexible / ym 5.13s 65.66s
> flexible / ym_2_38 5.08s 65.63s
> flexible / ymd 5.30s 65.45s
> flexible / ymd_2_38 5.29s 65.90s
> flexible / y_m 5.11s 65.72s
> flexible / y_m_2_38 5.08s 65.67s
> flexible / y_m_d 5.06s 65.50s
> flexible / y_m_d_2_38 5.07s 65.79s
It's good to see that the no-notes behaves roughly like baseline.
I can see that some people may think that date-based fan-out is the cat's
ass, but I have to warn that we have no idea how notes will be used, and
the date-based fan-out is rather limiting in certain respects:
- for the typical nightly-build-generated notes, this fan-out is pretty
inefficient memory-wise.
- I find the restriction to commits rather limiting.
- most of the performance difference between the date-based and the SHA-1
based fan-out looks to me as if the issue was the top-level tree.
Basically, this tree has to be read _every_ time _anybody_ wants to read
a note.
Maybe a finer-grained fan-out (finer than 16-bits) could help. After
all, if you have 16 different notes, chances are that they have 16
different first letters, but all have the same commit year. That's
where the top-level notes with a fan-out perform incredibly bad.
But I think that having a dynamic fan-out that can even put blobs into
the top-level tree (nothing prevents us from doing that, right?) would
_outperform_ the date-based one, at least with less than 1 note/commit
(and maybe even then, because the year-based fan-out results in pretty
varying entropies per fan-out depth).
The real question for me, therefore, is: what is the optimal way to
strike the balance between size of the tree objects (which we want to
be small, so that unpacking them is fast) and depth of the fan-out
(which we want to be shallow to avoid reading worst-case 39 tree objects
to get at one single note).
- related to the previous point is my gut feeling that the date-based
fan-out has nothing to do with any theoretical optimum. I am pretty
certain that the optimal fan-out strategy depends heavily on the SHA-1s
of the annotated objects (if you have 10,000 notes in 2009, but only 1
in 2008, the year-based fan-out _must_ be suboptimal) and maybe is
something like a sibling to the Fibonacci heap.
- I'd love to see performance numbers for less than 157118 notes. Don't
get me wrong, it is good to see the worst-case scenario in terms of
notes/commits ratio. But it will hardly be the common case, and I
very much would like to optimize for the common case.
So, I'd appreciate if you could do the tests with something like 500
notes, randomly spread over the commits (rationale: my original
understanding was that the notes could amend commit messages, and that
is much more likely to be done with relatively old commits that you
cannot change anymore).
Please understand that I might not have the time to participate in this
thread as much as I would like to. The next 4 days will be especially
hard.
Ciao,
Dscho
^ permalink raw reply
* Re: Gitweb linking to bug-tracking system
From: Alex Riesen @ 2009-09-08 9:22 UTC (permalink / raw)
To: Arnaud Bailly; +Cc: git
In-Reply-To: <85ab15n8of.fsf@oqube.com>
On Tue, Sep 8, 2009 at 10:26, Arnaud Bailly<abailly@oqube.com> wrote:
> HEllo,
> I have installed gitweb using git version 1.6.3.3 on ubuntu, and
> everything is working perfectly.
> However, when a commit have a comment containing a string matching
> "DEF[0-9]+", an hyperlink is generated on the web interface which makes
> me think it is possible to link to some DTS. Yet I cannot find how to
> configure this ?
>
> Am I missing something ? Is this totally unrelated to DTS ?
It just looks like an SHA1 and is converted to a link to simplify
jumping around revisions.
^ permalink raw reply
* Re: Improving merge failure message
From: Alex Riesen @ 2009-09-08 9:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7veiqhgb4y.fsf@alter.siamese.dyndns.org>
On Tue, Sep 8, 2009 at 09:15, Junio C Hamano<gitster@pobox.com> wrote:
> @@ -170,6 +170,18 @@ static int git_merge_trees(int index_only,
> int rc;
> struct tree_desc t[3];
> struct unpack_trees_options opts;
> + static struct unpack_trees_error_msgs msgs = {
You can make these const, the struct is copied anyway:
> + opts.msgs = msgs;
Here --^
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Johan Herland @ 2009-09-08 8:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes.Schindelin, trast, tavestbo, git, chriscool,
spearce
In-Reply-To: <7vd462qdeg.fsf@alter.siamese.dyndns.org>
On Tuesday 08 September 2009, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > Furthermore, the following notes tree structures were tested:
> >
> > - "no-notes": Testing without any notes at all. This is only present as
> > a baseline, and to verify that the notes code does not negatively
> > affect performance when not in use.
>
> Minor nit.
>
> For this to be a baseline, you would need to have another algorithm
> before "before", i.e., without any of these notes implementation.
>
> Comparison with "before" alone is not meaningful. That is like starting
> with a state with unknown performance regression compared to the stock
> version, and then boast improvements made by various variations.
>
> You would need to compare overhead of various "algorithms" with the stock
> git in "no-notes" case as well. It would give us the true performance
> cost of supporting notes.
True. Here is the same table with the baseline ('next') entry on top:
Algorithm / Notes tree git log -n10 (x100) git log --all
------------------------------------------------------------
next / no-notes 4.77s 63.84s
before / no-notes 4.78s 63.90s
before / no-fanout 56.85s 65.69s
16tree / no-notes 4.77s 64.18s
16tree / no-fanout 30.35s 65.39s
16tree / 2_38 5.57s 65.42s
16tree / 2_2_36 5.19s 65.76s
flexible / no-notes 4.78s 63.91s
flexible / no-fanout 30.34s 65.57s
flexible / 2_38 5.57s 65.46s
flexible / 2_2_36 5.18s 65.72s
flexible / ym 5.13s 65.66s
flexible / ym_2_38 5.08s 65.63s
flexible / ymd 5.30s 65.45s
flexible / ymd_2_38 5.29s 65.90s
flexible / y_m 5.11s 65.72s
flexible / y_m_2_38 5.08s 65.67s
flexible / y_m_d 5.06s 65.50s
flexible / y_m_d_2_38 5.07s 65.79s
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] git-rebase-interactive: avoid breaking when GREP_OPTIONS="-H"
From: Carlo Marcelo Arenas Belon @ 2009-09-08 8:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpra1gbqc.fsf@alter.siamese.dyndns.org>
On Tue, Sep 08, 2009 at 12:02:51AM -0700, Junio C Hamano wrote:
>
> Or even this.
definitely better.
Carlo
^ permalink raw reply
* Gitweb linking to bug-tracking system
From: Arnaud Bailly @ 2009-09-08 8:26 UTC (permalink / raw)
To: git
HEllo,
I have installed gitweb using git version 1.6.3.3 on ubuntu, and
everything is working perfectly.
However, when a commit have a comment containing a string matching
"DEF[0-9]+", an hyperlink is generated on the web interface which makes
me think it is possible to link to some DTS. Yet I cannot find how to
configure this ?
Am I missing something ? Is this totally unrelated to DTS ?
Regards,
--
Arnaud Bailly -- OQube
<software engineering>
http://www.oqube.com/
^ permalink raw reply
* Re: Improving merge failure message
From: Johannes Sixt @ 2009-09-08 8:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vbplmhr0i.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> [2]% git merge feature
>> error: Entry 'cool' not uptodate. Cannot merge.
>> fatal: merging of trees 8ec1d96451ff05451720e4e8968812c46b35e5e4 and aad8d5cef3915ab78b3227abaaac99b62db9eb54 failed
>>
>> ... the messages look unnecessarily scary, with two
>> "error" and "fatal" comments, and long sha1 commit names.
>
>> It would be nice if the message in the latter case can be toned down.
>
> Yeah, it would be nice. This actually was something that bothered me as
> well while trying to explain the recovery procedure for these two cases.
> Give me half an hour or so to cook up something...
I think that this is a symptom of a much more involved issue about error
handling.
Currently, it is customary in the code to report an error at each location
where an exceptional condition is detected:
if (frotz())
ret = error("frotz messed up");
If frotz() is a "low-level" routine, like a C library function, then this
is the right thing to do. However, if frotz() is our own function
("high-level") which itself calls low-level functions with the same
pattern, then this is obviously the wrong thing to do, because it results
into two error messages.
We need a guideline how errors are reported. This guideline could be:
(1) Low-level functions do not print error messages, but set an error code
and leave the reporting to the caller.
(2) High-level functions must print an error message (through error() or
die()) when they detect a failure of a low-level function that was called
directly.
(3) High-level functions must not print an error message when they detect
a failure of another high-level function that was called directly.
There remains to classify our functions into high-level or low-level. But
I think we won't have a lot of low-level functions.
BTW, I applied this guideline when I worked on {start,finish,run}_command
recently, and IMHO it worked out quite nicely because exactly one error is
reported after a failure.
-- Hannes
^ permalink raw reply
* Re: Improving merge failure message
From: Mike Ralphson @ 2009-09-08 7:59 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: Sverre Rabbelier, Nanako Shiraishi, git
In-Reply-To: <7vk509ev20.fsf@alter.siamese.dyndns.org>
2009/9/8 Junio C Hamano <gitster@pobox.com>:
> I'll leave the exact wording up to other people. My primary focus was to
> end all of these messages with "Aborting."
>
> This turns out to be a continuation of an older discussion thread back in
> May 2008, and I do not know if anybody took up the challenge back then. I
> wouldn't be surprised if "checkout", which was the topic of the old
> thread, has some other scary plumbing message still seeping through to the
> UI layer. Perhaps there are some other commands that needs similar kind
> of love.
Just a note that Documentation/git-checkout.txt references this
message in an example and should be kept in step with the final
wording change. It would be ideal to be able to regression-test the
examples in the documentation somehow but that might involve abusing
the asciidoc markup somewhat.
2009/9/8 Jeff King <peff@peff.net>:
> While we're picking apart your wording, is "clobbered" the word we want
> to use?
If we're debating 'clobbered', then maybe the non-word 'uptodate' is
fair game too? 8-)
^ permalink raw reply
* Re: [PATCH] Add more instructions about how to install git.
From: Michael J Gruber @ 2009-09-08 7:56 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Alex Riesen, Thiago Farina, git
In-Reply-To: <vpqhbvekldk.fsf@bauges.imag.fr>
Matthieu Moy venit, vidit, dixit 08.09.2009 08:20:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> On Tue, Sep 8, 2009 at 07:11, Thiago Farina<tfransosi@gmail.com> wrote:
>>> Signed-off-by: Thiago Farina <tfransosi@gmail.com>
>>> ---
>>> INSTALL | 9 +++++++++
>>> 1 files changed, 9 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/INSTALL b/INSTALL
>>> index ae7f750..67abfc7 100644
>>> --- a/INSTALL
>>> +++ b/INSTALL
>>> @@ -1,6 +1,15 @@
>>>
>>> Git installation
>>>
>>> +To install git follow these 4 steps inside your git directory:
>>> +$ autoconf # Generates the configure file from configure.ac
>>> +$ ./configure # Configures everything needed to build git
>>> +$ make all # Compiles git based in the Makefile
>>> +$ make install # Installs git in your own ~/bin directory
>
> Your commit message doesn't say what's wrong with
>
> | Alternatively you can use autoconf generated ./configure script to
> | set up install paths (via config.mak.autogen), so you can write
> | instead
> |
> | $ make configure ;# as yourself
> | $ ./configure --prefix=/usr ;# as yourself
> | $ make all doc ;# as yourself
> | # make install install-doc install-html;# as root
>
> which is already in INSTALL a few lines after what your patch adds.
... especially since that really is a second class alternative these
days, with using the shipped Makefile being the preferred way - just as
the current documentation states.
>
>>> +If you don't have autoconf installed, you can do this by:
>>> +$ sudo apt-get install autoconf
>>
>> ... if you're on a Debian-derived system.
>
> and if you have sudo configured.
>
> BTW, apt-get is anyway somehow deprecaded, you should
> s/apt-get/aptitude/.
>
^ permalink raw reply
* Re: Improving merge failure message
From: Jeff King @ 2009-09-08 7:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, Nanako Shiraishi, git
In-Reply-To: <7vk509ev20.fsf@alter.siamese.dyndns.org>
On Tue, Sep 08, 2009 at 12:48:23AM -0700, Junio C Hamano wrote:
> Thanks, very true indeed. "It would be clobbered if we were to continue
> hence we abort." is how we want to explain our behaviour, so "would" is
> definitely better here.
While we're picking apart your wording, is "clobbered" the word we want
to use? Everywhere else that is user-facing we tend to use the term
"overwritten".
-Peff
^ permalink raw reply
* Re: Improving merge failure message
From: Junio C Hamano @ 2009-09-08 7:48 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Nanako Shiraishi, git
In-Reply-To: <fabb9a1e0909080020i3daa92aar952fc5102df62bdb@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Tue, Sep 8, 2009 at 09:15, Junio C Hamano<gitster@pobox.com> wrote:
>> + /* would_overwrite */
>> + "Your local changes to '%s' will be clobbered by merge. Aborting.",
>
> Still scary, shouldn't that be s/will be/would be/ ?
Thanks, very true indeed. "It would be clobbered if we were to continue
hence we abort." is how we want to explain our behaviour, so "would" is
definitely better here.
>> + /* not_uptodate_dir */
>> + "Updating '%s' would lose untracked files in it. Aborting.",
This is "merge would resolve to have a file X, but you have a directory X
in your work tree and it is not empty" case.
I'll leave the exact wording up to other people. My primary focus was to
end all of these messages with "Aborting."
This turns out to be a continuation of an older discussion thread back in
May 2008, and I do not know if anybody took up the challenge back then. I
wouldn't be surprised if "checkout", which was the topic of the old
thread, has some other scary plumbing message still seeping through to the
UI layer. Perhaps there are some other commands that needs similar kind
of love.
^ permalink raw reply
* [PATCH] Add test for ignoring pushInsteadOf when remote has explicit pushurl
From: Josh Triplett @ 2009-09-08 7:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20090908071513.GA3236@feather>
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
On Tue, Sep 08, 2009 at 12:15:13AM -0700, Josh Triplett wrote:
> On Tue, Sep 08, 2009 at 12:02:42AM -0700, Junio C Hamano wrote:
> > Josh Triplett <josh@joshtriplett.org> writes:
> >
> > > This configuration option allows systematically rewriting fetch-only
> > > URLs to push-capable URLs when used with push. For instance:
> > >
> > > [url "ssh://example.org/"]
> > > pushInsteadOf = "git://example.org/"
> > >
> > > This will allow clones of "git://example.org/path/to/repo" to
> > > subsequently push to "ssh://example.org/path/to/repo", without manually
> > > configuring pushurl for that remote.
> > >
> > > Includes documentation for the new option, bash completion updates, and
> > > test cases (both that pushInsteadOf applies to push and that it does
> > > *not* apply to fetch).
> >
> > Thanks.
> >
> > I will queue these patches, but I presume you would also want to add a
> > test that pushInsteadOf is ignored for remotes with an explicit pushURL?
>
> Will do.
Done. Please add this to the queue, optionally squashing it into patch
2/2 if you prefer.
t/t5516-fetch-push.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 8f455c7..6889a53 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -193,6 +193,22 @@ test_expect_success 'push with pushInsteadOf' '
)
'
+test_expect_success 'push with pushInsteadOf and explicit pushurl (pushInsteadOf should not rewrite)' '
+ mk_empty &&
+ TRASH="$(pwd)/" &&
+ git config "url.trash2/.pushInsteadOf" trash/ &&
+ git config remote.r.url trash/wrong &&
+ git config remote.r.pushurl "$TRASH/testrepo" &&
+ git push r refs/heads/master:refs/remotes/origin/master &&
+ (
+ cd testrepo &&
+ r=$(git show-ref -s --verify refs/remotes/origin/master) &&
+ test "z$r" = "z$the_commit" &&
+
+ test 1 = $(git for-each-ref refs/remotes/origin | wc -l)
+ )
+'
+
test_expect_success 'push with matching heads' '
mk_test heads/master &&
--
1.6.3.3
^ permalink raw reply related
* Re: Improving merge failure message
From: Sverre Rabbelier @ 2009-09-08 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7veiqhgb4y.fsf@alter.siamese.dyndns.org>
Heya,
On Tue, Sep 8, 2009 at 09:15, Junio C Hamano<gitster@pobox.com> wrote:
> + /* would_overwrite */
> + "Your local changes to '%s' will be clobbered by merge. Aborting.",
Still scary, shouldn't that be s/will be/would be/ ?
> + /* not_uptodate_file */
> + "Your local changes to '%s' will be clobbered by merge. Aborting.",
Ditto.
> + /* not_uptodate_dir */
> + "Updating '%s' would lose untracked files in it. Aborting.",
Not sure, but maybe s/in it//
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Improving merge failure message
From: Junio C Hamano @ 2009-09-08 7:15 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <7vbplmhr0i.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> [2]% git merge feature
>> error: Entry 'cool' not uptodate. Cannot merge.
>> fatal: merging of trees 8ec1d96451ff05451720e4e8968812c46b35e5e4 and aad8d5cef3915ab78b3227abaaac99b62db9eb54 failed
>>
>> ... the messages look unnecessarily scary, with two
>> "error" and "fatal" comments, and long sha1 commit names.
>
> Just a technical nit. I think these are tree object names.
>
>> Those of us who used git for some time can tell what it wants to say.
>> The merge checked the files in the working tree before doing anything,
>> found that the user has uncommitted change to a file that is involved in
>> the merge, and it stopped. And it didn't change anything. It may be "fatal"
>> but the user has much less reason to be scared about this failure than
>> the conflicting case.
>>
>> It would be nice if the message in the latter case can be toned down.
>
> Yeah, it would be nice. This actually was something that bothered me as
> well while trying to explain the recovery procedure for these two cases.
> Give me half an hour or so to cook up something...
It turns out to be a lot simpler than I thought, because 8ccba00
(unpack-trees: allow Porcelain to give different error messages,
2008-05-17) already laid enough groundwork for doing this kind of thing
easily.
Notable points are:
- End the messages with "Aborting."; they are given when the three-way
merge stops without harming the work tree;
- Do not give the extra message after unpack_trees() already errored out.
This "merging of trees failed" message was primarily for debugging
merge-recursive itself, and the end user cannot do much with the object
names given in the message anyway.
But do give it under higher verbosity level, or when it happens during
the inner merge (the "recursive" one), as unpack_trees() should not
fail for the inner merge under normal conditions.
We could later add instructions on how to recover (i.e. "stash changes
away or commit on a side branch and retry") instead of the silent
exit(128) I have down there, and then use Peff's advice.* mechanism to
squelch it (e.g. "advice.mergeindirtytree"), but they are separate topics.
merge-recursive.c | 25 +++++++++++++++++++++----
1 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 10d7913..a237240 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -170,6 +170,18 @@ static int git_merge_trees(int index_only,
int rc;
struct tree_desc t[3];
struct unpack_trees_options opts;
+ static struct unpack_trees_error_msgs msgs = {
+ /* would_overwrite */
+ "Your local changes to '%s' will be clobbered by merge. Aborting.",
+ /* not_uptodate_file */
+ "Your local changes to '%s' will be clobbered by merge. Aborting.",
+ /* not_uptodate_dir */
+ "Updating '%s' would lose untracked files in it. Aborting.",
+ /* would_lose_untracked */
+ "Untracked working tree file '%s' would be %s by merge. Aborting",
+ /* bind_overlap -- will not happen here */
+ NULL,
+ };
memset(&opts, 0, sizeof(opts));
if (index_only)
@@ -181,6 +193,7 @@ static int git_merge_trees(int index_only,
opts.fn = threeway_merge;
opts.src_index = &the_index;
opts.dst_index = &the_index;
+ opts.msgs = msgs;
init_tree_desc_from_tree(t+0, common);
init_tree_desc_from_tree(t+1, head);
@@ -1188,10 +1201,14 @@ int merge_trees(struct merge_options *o,
code = git_merge_trees(o->call_depth, common, head, merge);
- if (code != 0)
- die("merging of trees %s and %s failed",
- sha1_to_hex(head->object.sha1),
- sha1_to_hex(merge->object.sha1));
+ if (code != 0) {
+ if (show(o, 4) || o->call_depth)
+ die("merging of trees %s and %s failed",
+ sha1_to_hex(head->object.sha1),
+ sha1_to_hex(merge->object.sha1));
+ else
+ exit(128);
+ }
if (unmerged_cache()) {
struct string_list *entries, *re_head, *re_merge;
^ permalink raw reply related
* Re: [PATCHv2 2/2] Add url.<base>.pushInsteadOf: URL rewriting for push only
From: Josh Triplett @ 2009-09-08 7:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vws49gbql.fsf@alter.siamese.dyndns.org>
On Tue, Sep 08, 2009 at 12:02:42AM -0700, Junio C Hamano wrote:
> Josh Triplett <josh@joshtriplett.org> writes:
>
> > This configuration option allows systematically rewriting fetch-only
> > URLs to push-capable URLs when used with push. For instance:
> >
> > [url "ssh://example.org/"]
> > pushInsteadOf = "git://example.org/"
> >
> > This will allow clones of "git://example.org/path/to/repo" to
> > subsequently push to "ssh://example.org/path/to/repo", without manually
> > configuring pushurl for that remote.
> >
> > Includes documentation for the new option, bash completion updates, and
> > test cases (both that pushInsteadOf applies to push and that it does
> > *not* apply to fetch).
>
> Thanks.
>
> I will queue these patches, but I presume you would also want to add a
> test that pushInsteadOf is ignored for remotes with an explicit pushURL?
Will do.
- Josh Triplett
^ permalink raw reply
* Re: [PATCH resend] git-pull: fix fetch-options.txt to not document --quiet and --verbose twice in git-pull.txt
From: Emmanuel Trillaud @ 2009-09-08 7:07 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Git Mailing List
In-Reply-To: <vpqd462kl4p.fsf@bauges.imag.fr>
Thank you for your patience.
Because I want to be kind to our maintainer :-), I've just finish a
complete reading of SubmitingPatches. Next time I promise : no more
whistespace mess and a commit message were it is meant to be.
Best regards
Emmanuel Trillaud
^ permalink raw reply
* Re: [PATCH] git-rebase-interactive: avoid breaking when GREP_OPTIONS="-H"
From: Junio C Hamano @ 2009-09-08 7:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlo Marcelo Arenas Belon, git
In-Reply-To: <7v7hwar1fp.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe> writes:
>
>> if GREP_OPTIONS is set and includes -H, using `grep -c` will fail
>> to generate a numeric count and result in the following error :
>>
>> /usr/libexec/git-core/git-rebase--interactive: line 110: (standard
>> input):1+(standard input):0: missing `)' (error token is
>> "input):1+(standard input):0")
>>
>> instead of grep counting use `wc -l` to return the line count.
>
> Thanks.
>
> How does your patch help when the user has GREP_OPTIONS=-C3 in the
> environment?
>
> I think a saner workaround for this user environment bug (or GNU grep
> misfeature) is to unset GREP_OPTIONS at the beginning of the script, or
> even in git-sh-setup.
Or even this.
git.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c
index 0b22595..3548154 100644
--- a/git.c
+++ b/git.c
@@ -450,11 +450,24 @@ static int run_argv(int *argcp, const char ***argv)
return done_alias;
}
+static void sanitize_env(void) {
+ static const char *vars[] = {
+ "GREP_OPTIONS",
+ "GREP_COLOR",
+ "GREP_COLORS",
+ NULL,
+ };
+ const char **p;
+
+ for (p = vars; *p; p++)
+ unsetenv(*p);
+}
int main(int argc, const char **argv)
{
const char *cmd;
+ sanitize_env();
cmd = git_extract_argv0_path(argv[0]);
if (!cmd)
cmd = "git-help";
^ permalink raw reply related
* Re: [PATCHv2 2/2] Add url.<base>.pushInsteadOf: URL rewriting for push only
From: Junio C Hamano @ 2009-09-08 7:02 UTC (permalink / raw)
To: Josh Triplett; +Cc: git
In-Reply-To: <5e58748923d9b4a182499a6ba8fa4636bce4810e.1252313313.git.josh@joshtriplett.org>
Josh Triplett <josh@joshtriplett.org> writes:
> This configuration option allows systematically rewriting fetch-only
> URLs to push-capable URLs when used with push. For instance:
>
> [url "ssh://example.org/"]
> pushInsteadOf = "git://example.org/"
>
> This will allow clones of "git://example.org/path/to/repo" to
> subsequently push to "ssh://example.org/path/to/repo", without manually
> configuring pushurl for that remote.
>
> Includes documentation for the new option, bash completion updates, and
> test cases (both that pushInsteadOf applies to push and that it does
> *not* apply to fetch).
Thanks.
I will queue these patches, but I presume you would also want to add a
test that pushInsteadOf is ignored for remotes with an explicit pushURL?
^ permalink raw reply
* [PATCH] completion: complete --scissors option of git-am
From: Stephen Boyd @ 2009-09-08 6:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index bf688e1..226e3ea 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -676,7 +676,7 @@ _git_am ()
--3way --committer-date-is-author-date --ignore-date
--ignore-whitespace --ignore-space-change
--interactive --keep --no-utf8 --signoff --utf8
- --whitespace=
+ --whitespace= --scissors
"
return
esac
--
1.6.5.rc0
^ permalink raw reply related
* Re: [PATCH] git-rebase-interactive: avoid breaking when GREP_OPTIONS="-H"
From: Junio C Hamano @ 2009-09-08 6:54 UTC (permalink / raw)
To: Carlo Marcelo Arenas Belon; +Cc: git
In-Reply-To: <20090908064756.GA14155@sajinet.com.pe>
Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe> writes:
> On Mon, Sep 07, 2009 at 12:37:30PM -0700, Junio C Hamano wrote:
>>
>> How does your patch help when the user has GREP_OPTIONS=-C3 in the
>> environment?
>
> It wouldn't help but at least wouldn't break aborting with an script
> error since you will always get a number.
That's actually worse, don't you think?
It is trying to count how many actions are done and how many are
remaining, and if you miscount it in that shell function, you will get
incorrect result. The function happens to be merely for reporting, but
the point is that it is better to fail loudly than doing wrong thing.
>> I think a saner workaround for this user environment bug (or GNU grep
>> misfeature) is to unset GREP_OPTIONS at the beginning of the script, or
>> even in git-sh-setup.
>
> agree, and since grep is used almost everywhere filtering in git-sh-setup
> like CDPATH is makes sense, with the only user of grep that wouldn't
> benefit from that being git-mergetool--lib.sh AFAIK.
Not at all. "git grep" itself will be broken. See my other patch for a
possible alternative approach.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Junio C Hamano @ 2009-09-08 6:48 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090908153109.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> ... I'm also hoping to tag the real 1.6.5 before I vanish for
>> about a week and half later in the month....
>
> Are you coming to Japan to promote your book, perhaps giving autographs at bookstores?
It will come out around 19th if things go as planned, but I'll be arriving
the week after that so I'll be too late for that kind of thing.
Besides, who would want an autographed copy of a technical book?
I should start asking the usual suspect to take things over while I'm
offline...
^ permalink raw reply
* Re: [PATCH] git-rebase-interactive: avoid breaking when GREP_OPTIONS="-H"
From: Carlo Marcelo Arenas Belon @ 2009-09-08 6:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7hwar1fp.fsf@alter.siamese.dyndns.org>
On Mon, Sep 07, 2009 at 12:37:30PM -0700, Junio C Hamano wrote:
>
> How does your patch help when the user has GREP_OPTIONS=-C3 in the
> environment?
It wouldn't help but at least wouldn't break aborting with an script
error since you will always get a number.
> I think a saner workaround for this user environment bug (or GNU grep
> misfeature) is to unset GREP_OPTIONS at the beginning of the script, or
> even in git-sh-setup.
agree, and since grep is used almost everywhere filtering in git-sh-setup
like CDPATH is makes sense, with the only user of grep that wouldn't
benefit from that being git-mergetool--lib.sh AFAIK.
will test and submit a fix for that later, but still think the original
patch at least improves the status quo (will protect also when using
custom grep wrappers as reported earlier) and doesn't do any harm as wc
is already a dependency as well and was part of the original code as well.
Carlo
^ permalink raw reply
* Re: Improving merge failure message
From: Junio C Hamano @ 2009-09-08 6:47 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090908153101.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> [2]% git merge feature
> error: Entry 'cool' not uptodate. Cannot merge.
> fatal: merging of trees 8ec1d96451ff05451720e4e8968812c46b35e5e4 and aad8d5cef3915ab78b3227abaaac99b62db9eb54 failed
>
> ... the messages look unnecessarily scary, with two
> "error" and "fatal" comments, and long sha1 commit names.
Just a technical nit. I think these are tree object names.
> Those of us who used git for some time can tell what it wants to say.
> The merge checked the files in the working tree before doing anything,
> found that the user has uncommitted change to a file that is involved in
> the merge, and it stopped. And it didn't change anything. It may be "fatal"
> but the user has much less reason to be scared about this failure than
> the conflicting case.
>
> It would be nice if the message in the latter case can be toned down.
Yeah, it would be nice. This actually was something that bothered me as
well while trying to explain the recovery procedure for these two cases.
Give me half an hour or so to cook up something...
^ 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