* Re: [PATCHv5 00/14] git notes
From: Johan Herland @ 2009-09-08 22:46 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Junio C Hamano, trast, tavestbo, git, chriscool, spearce
In-Reply-To: <alpine.DEB.1.00.0909081741590.4330@intel-tinevez-2-302>
On Tuesday 08 September 2009, Johannes Schindelin wrote:
> On Tue, 8 Sep 2009, Johan Herland wrote:
> > On Tuesday 08 September 2009, Johannes Schindelin wrote:
> > > 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,
> >
> > I don't agree. Although we will certainly see many more use cases for
> > notes, I believe that the vast majority of them can be placed in one of
> > two categories:
>
> My experience with Git is that having beliefs how my work is used was a
> constant source of surprise.
And you believe that a system that only allows SHA1-based fanout schemes is
better equipped to tackle such surprises than a system that provides both
date-based and SHA1-based fanout schemes?
> > > - I find the restriction to commits rather limiting.
> >
> > I see your point, but I don't agree until I see a compelling case for
> > annotating a non-commit.
>
> My point is that it is too late by then, if you don't allow for a
> flexible and still efficient scheme.
As I replied to Junio, we could use the epoch as a "commit date" for tree
and blob objects, thus making them representable in a date-based fanout
scheme (although if there are a signficant number of non-commit notes, the
code should be smart enough to find a better (SHA1-based probably) fanout
scheme for those notes).
> > > - 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.
> >
> > Not sure what you're trying to say here. The top-level notes tree is
> > read (as in fill_tree_descriptor()) exactly _once_. After that, it is
> > cached by the internal data structure (until free_commit_notes() or
> > end-of-process).
>
> By that reasoning, we do not need any fan-out scheme.
>
> Keep in mind: reading a large tree object takes a long time. That's why
> we started fan-out. Reading a large number of tree objects also takes a
> long time. That's why I propagated flexible fan-out that is only read-in
> on demand.
Not sure where you're going with this. Of course we want to strike an
optimal balance between the size of tree objects and the number of tree
objects. Nobody is arguing about that. Both SHA1-based and (in the most
common cases) date-based schemes can be used to achieve this balance. But
using date-based fanout has the added advantage of providing better
performance (both runtime- and memory-wise) when looking up notes in a
chronological order.
> > > 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?)
> >
> > Well, the "flexible" code does add the new requirement that all entries
> > in a notes (sub)tree object must follow the same scheme, i.e. you
> > cannot have:
> >
> > /12/34567890123456789012345678901234567890
> > /2345/678901234567890123456789012345678901
> >
> > but you can have
> >
> > /12/34567890123456789012345678901234567890
> > /23/45/678901234567890123456789012345678901
>
> Umm, why? Is there any good technical reason?
In the date-based parts of notes tree, there are very good reasons for doing
so: The code peeks at the first tree entry in order to determine what kind
of date-based fanout is used in the current tree object. Subsequent entries
(in that tree object) that do not follow the same format are
skipped/ignored.
The SHA1-based fanout code has not changed since the last iteration, so this
extra requirement is not absolutely necessary for the SHA1-based parts of
the notes tree. However, the extra requirement does guarantee that commit
notes have exactly one unique location in the notes tree, and thus relieves
us of having to keep searching for alternative notes locations, and
concatenate the notes found.
> > > 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).
> >
> > s/39/19/ (each fanout must use at least 2 chars of the 40-char SHA1)
>
> That is another unnecessary restriction that could cost you dearly. Just
> think what happens if it turns out that the optimal number of tree items
> is closer to 16 than to 255...
The code can easily be rewritten to allow for "odd" fanouts (1/39, 1/1/38,
etc.). Feel free to submit a patch.
I was, however, naive enough to assume that when git.git decided on using
2/38 fanout for its loose objects, then some performance-related thoughts
went into that decision. If there are indications that multiple-of-2-type
fanouts are not optimal, we should probably reconsider.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH 5/6 (v4)] full integration of rev-cache into git, completed test suite
From: Nick Edelen @ 2009-09-08 22:24 UTC (permalink / raw)
To: Sam Vilain
Cc: Junio C Hamano, Nicolas Pitre, Johannes Schindelin,
Michael J Gruber, Jeff King, Shawn O. Pearce, Andreas Ericsson,
Christian Couder, git@vger.kernel.org
In-Reply-To: <1252357564.5969.4.camel@maia.lan>
> ^^ You don't need to write comments like "This patch"; in the history
> such words are meaningless.
I had meant to delete that...
> "tweak" ?
Yeah I had modified the messages and didn't replace the additional
info I deleted. It's not really important, as it's modified again
(for the last time) in the name-related patch, but here it's revised
to take advantage of the size storage.
>> - more fluid handling of damaged cache slices
>
> What does this mean?
That it remembers/is aware of bad slices, instead of dumbly attempting
to load them upon each commit.
> This is quite a long commit message. Is the above detail all useful?
> Can it be split into one patch for each of the above integrations?
Erm, I suppose they could be split, but the changes to revision and
list-objects aren't very big, so I figured it'd be easier/cleaner to
just put everything required for smooth integration into a single
patch. I dunno, it dosn't seem hugely necessary; the bits modifying
git code are relatively small and already obviously seperate in the
patch.
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Sverre Rabbelier @ 2009-09-08 21:57 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Johannes Schindelin, Johan Herland, git, trast,
tavestbo, git, chriscool
In-Reply-To: <20090908213944.GX1033@spearce.org>
Heya,
On Tue, Sep 8, 2009 at 23:39, Shawn O. Pearce<spearce@spearce.org> wrote:
> Uh, but the natural way to index those is by commit, and each
> different revision of a change is a different commit. Why delete
> the prior revision information and move it to the final commit note?
Ah, I didn't realize you would push the notes before the final revision is made.
> Someone who has the prior revisions in their reflog and is doing
> `git log -g --notes` might want to see that annotation.
It would make more sense to have multiple notes then, but wouldn't you
want them to annotate the original commit, rather than the final one?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] post-receive-email: do not call sendmail if no mail was generated
From: Junio C Hamano @ 2009-09-08 21:49 UTC (permalink / raw)
To: Lars Noschinski; +Cc: Junio C Hamano, git, andyparkins, pape
In-Reply-To: <20090908205935.GB3858@lars.home.noschinski.de>
Lars Noschinski <lars-2008-2@usenet.noschinski.de> writes:
> Actually, there are a two cases in the case statement before, where
> generate_email would return:
>
> refs/remotes/*,commit)
> # tracking branch
> refname_type="tracking branch"
> short_refname=${refname##refs/remotes/}
> echo >&2 "*** Push-update of tracking branch, $refname"
> echo >&2 "*** - no email generated."
> exit 0
> ;;
> *)
> # Anything else (is there anything else?)
> echo >&2 "*** Unknown type of update to $refname ($rev_type)"
> echo >&2 "*** - no email generated"
> exit 1
> ;;
Ok, that justifies the existence of the patch.
^ permalink raw reply
* [StGit PATCH] Add import -p option
From: Catalin Marinas @ 2009-09-08 21:43 UTC (permalink / raw)
To: Gustav Hållberg, Karl Hasselström, Git Mailing List
This patch renames some of the existing import options and adds the -p
(--strip) option which allows stripping the leading slashes of the diff
paths.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
stgit/commands/imprt.py | 13 ++++++++-----
stgit/git.py | 4 +++-
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/stgit/commands/imprt.py b/stgit/commands/imprt.py
index 8067beb..0bbacbc 100644
--- a/stgit/commands/imprt.py
+++ b/stgit/commands/imprt.py
@@ -57,7 +57,9 @@ options = [
short = 'Import a patch from a URL'),
opt('-n', '--name',
short = 'Use NAME as the patch name'),
- opt('-t', '--strip', action = 'store_true',
+ opt('-p', '--strip', type = 'int', metavar = 'N',
+ short = 'Remove N leading slashes from diff paths (default 1)'),
+ opt('-t', '--stripname', action = 'store_true',
short = 'Strip numbering and extension from patch name'),
opt('-i', '--ignore', action = 'store_true',
short = 'Ignore the applied patches in the series'),
@@ -69,7 +71,7 @@ options = [
short = 'leave the rejected hunks in corresponding *.rej files'),
opt('-e', '--edit', action = 'store_true',
short = 'Invoke an editor for the patch description'),
- opt('-p', '--showpatch', action = 'store_true',
+ opt('-d', '--showdiff', action = 'store_true',
short = 'Show the patch content in the editor buffer'),
opt('-a', '--author', metavar = '"NAME <EMAIL>"',
short = 'Use "NAME <EMAIL>" as the author details'),
@@ -104,7 +106,7 @@ def __create_patch(filename, message, author_name,
author_email,
patch = os.path.basename(filename)
else:
patch = ''
- if options.strip:
+ if options.stripname:
patch = __strip_patch_name(patch)
if not patch:
@@ -152,9 +154,10 @@ def __create_patch(filename, message,
author_name, author_email,
base = git_id(crt_series, options.base)
else:
base = None
- git.apply_patch(diff = diff, base = base, reject = options.reject)
+ git.apply_patch(diff = diff, base = base, reject = options.reject,
+ strip = options.strip)
crt_series.refresh_patch(edit = options.edit,
- show_patch = options.showpatch,
+ show_patch = options.showdiff,
sign_str = options.sign_str,
backup = False)
out.done()
diff --git a/stgit/git.py b/stgit/git.py
index 268c44b..0886207 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -818,7 +818,7 @@ def repack():
GRun('repack', '-a', '-d', '-f').run()
def apply_patch(filename = None, diff = None, base = None,
- fail_dump = True, reject = False):
+ fail_dump = True, reject = False, strip = None):
"""Apply a patch onto the current or given index. There must not
be any local changes in the tree, otherwise the command fails
"""
@@ -840,6 +840,8 @@ def apply_patch(filename = None, diff = None, base = None,
cmd = ['apply', '--index']
if reject:
cmd += ['--reject']
+ if strip:
+ cmd += ['-p', strip]
try:
GRun(*cmd).raw_input(diff).no_output()
except GitRunException:
^ permalink raw reply related
* Re: [PATCHv5 00/14] git notes
From: Johan Herland @ 2009-09-08 21:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, trast, tavestbo, git, chriscool,
spearce
In-Reply-To: <7vocplxjov.fsf@alter.siamese.dyndns.org>
On Tuesday 08 September 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 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
> >
> > I can see that some people may think that date-based fan-out is the
> > cat's ass,
>
> Actually, my knee-jerk reaction was that 4.77 (next) vs 5.57 (16tree with
> 2_38) is already a good enough performance/simplicity tradeoff, and 5.57
> vs 5.08 (16tree with ym_2_38) probably does not justify the risk of worst
> case behaviour that can come from possible mismatch between the access
> pattern and the date-optimized tree layout.
Yes, 16tree / 2_38 looks like a reasonable tradeoff when you look at the
absolute numbers, but it's also interesting to highlight the actual cost of
doing the notes lookup. In that case, we see that 16tree / 2_38 costs 0.80s,
whereas flexible / ym_2_38 only costs 0.31s, i.e. less than half the cost of
the former...
> But that only argues against supporting _only_ date-optimized layout.
>
> Support of "flexible layout" is not that flexible as its name suggests;
> one single note tree needs to have a uniform fanout strategy.
Actually, the uniform strategy is only required at each separate level. You
are free to vary the strategy within independent subtrees. I.e. in the case
where you have 1 note from 2007, and 1000 notes from 2008, you are free to
use a mix of date-based and SHA1-based structures, like this:
y2007/1234567...
y2008/m01/d01/2345678...
y2008/m01/d01/3456789...
y2008/m01/d02/45/67890...
y2008/m01/d02/56/78901...
y2008/m01/d02/67/89012...
...
> > - I find the restriction to commits rather limiting.
>
> Yeah, we would not want to be surprised to find many people want to
> annotate non-commits with this mechanism.
We could arbitrarily set the "commit date" for non-commit objects to the
epoch, so that they can still be represented in a date-based fanout. (Of
course, the notes code should be smart enough to choose a more optimal
fanout if the number of non-commit notes is significant).
> > - 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.
>
> A comparison between 'next' and another algorithm that opens the
> top-level notes tree object and returns "I did not find any note"
> without doing anything else would reveal that cost. But when you are
> doing "log -n10" (or "log --all"), you would read the notes top-level
> tree once, and it is likely to be cached in the obj_hash[] (or in
> delta_base cache) already for the remaining invocations, even if notes
> mechanism does not do its own cache, which I think it does, no?
Yes it does, since Dscho's original hash_map based implementation, in fact.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Shawn O. Pearce @ 2009-09-08 21:39 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Johannes Schindelin, Johan Herland, git, trast,
tavestbo, git, chriscool
In-Reply-To: <fabb9a1e0909081436x72c71b0bv51d8f198cd82f289@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Tue, Sep 8, 2009 at 23:10, Shawn O. Pearce<spearce@spearce.org> wrote:
> > So most commits (66%) would have only 1 version (and 1 note)
> > related to them in the note tree, but if I use the same note tree
> > for final commits as individual revisions considered, at least 18%
> > of the commits in the final history of the project would actually
> > have two notes, and 7.5% would have 3 notes.
>
> You could however store all that information in one note, yes? Since
> the 'latest version' is the one committed, you can include the notes
> for all the previous ones at commit time?
Uh, but the natural way to index those is by commit, and each
different revision of a change is a different commit. Why delete
the prior revision information and move it to the final commit note?
Someone who has the prior revisions in their reflog and is doing
`git log -g --notes` might want to see that annotation.
--
Shawn.
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Sverre Rabbelier @ 2009-09-08 21:36 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Johannes Schindelin, Johan Herland, git, trast,
tavestbo, git, chriscool
In-Reply-To: <20090908211046.GV1033@spearce.org>
Heya,
On Tue, Sep 8, 2009 at 23:10, Shawn O. Pearce<spearce@spearce.org> wrote:
> So most commits (66%) would have only 1 version (and 1 note)
> related to them in the note tree, but if I use the same note tree
> for final commits as individual revisions considered, at least 18%
> of the commits in the final history of the project would actually
> have two notes, and 7.5% would have 3 notes.
You could however store all that information in one note, yes? Since
the 'latest version' is the one committed, you can include the notes
for all the previous ones at commit time?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] post-receive-email: do not call sendmail if no mail was generated
From: Andy Parkins @ 2009-09-08 21:12 UTC (permalink / raw)
To: git
In-Reply-To: <7v4ord19da.fsf@alter.siamese.dyndns.org>
Thanks for CCing me in - I don't monitor the list closely enough these days
:-)
Junio C Hamano wrote:
> If generate_email results in an empty output in this codepath:
>
> # Check if we've got anyone to send to
> if [ -z "$recipients" ]; then
> ...
> echo >&2 "*** $config_name is not set so no email will be sent"
> echo >&2 "*** for $refname update $oldrev->$newrev"
> exit 0
> fi
>
> shouldn't we rather receive an error e-mail than let the
> misconfiguration go undetected?
I don't know if it's still the case, but when I wrote it, anything that went
to standard error appeared on the client terminal, however, it could
probably do with being a better description of who is generating the
message, otherwise it'll be some anonymous error during a push, giving the
user no clue as to how to fix it.
> Before this check, I do not see anywhere generate_email would return nor
> exit, and after this check, there is a call to generate_email_header and
> that guarantees that the output from the generate_email function is not
> empty, so it looks to me that triggering this check is the only case your
> patch would change the behaviour of the script.
There is also a check for the validity of the update type above the
recipients check.
I'm wondering actually if all of these should be "return"s rather than
"exit"s. Better still would be if there were some sort of exception
throwing mechanism in shell script - anyone know if there is?
Andy
P.S. Hope you're all keeping well.
--
Dr Andy Parkins
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Shawn O. Pearce @ 2009-09-08 21:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Johan Herland, git, trast, tavestbo, git,
chriscool
In-Reply-To: <7vocplxjov.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Also Gitney talked about annotating commits in the code-review thing.
> What's the expected notes density and distribution in that application?
Uh, try one note per commit in a project. A few merges won't need
a note, but nearly every single non-merge commit would.
Consider a project with a velocity of about 200 non-merge
commits/day; the object count goes up fast.
One idea we are starting to kick around might double or quadruple
that number. If we store metadata about every version of every
commit ever proposed to a project, we need a lot more notes than
commits. Right now we have this sort of distribution from one of
our servers:
versions | commits
---------+---------
1 | 9262
2 | 2626
3 | 1053
4 | 424
5 | 224
6 | 124
7 | 57
8 | 38
9 | 28
10 | 14
11 | 12
12 | 10
13 | 5
14 | 6
15 | 2
16 | 3
17 | 2
21 | 1
32 | 1
So most commits (66%) would have only 1 version (and 1 note)
related to them in the note tree, but if I use the same note tree
for final commits as individual revisions considered, at least 18%
of the commits in the final history of the project would actually
have two notes, and 7.5% would have 3 notes.
--
Shawn.
^ permalink raw reply
* Re: [SCuMD]
From: Michael Gaffney @ 2009-09-08 21:09 UTC (permalink / raw)
To: Christian Senkowski; +Cc: git
In-Reply-To: <4A965799.6050204@gmx.de>
Christian Senkowski wrote:
> Hi,
>
> I cloned SCuMD directly via git and started it but got following error:
>
> ~/scumd$ ./run.sh
> Exception in thread "main" java.lang.NoClassDefFoundError:
> com.asolutions.scmsshd.SCuMD
> at gnu.java.lang.MainThread.run(libgcj.so.90)
> Caused by: java.lang.ClassNotFoundException:
> com.asolutions.scmsshd.SCuMD not found in
> gnu.gcj.runtime.SystemClassLoader{urls=[file:depend/lib/jgit.jar,file:depend/lib/minasshd.jar,file:lib/aopalliance-1.0.jar,file:lib/bcprov-jdk15-140.jar,file:lib/commons-io-1.4.jar,file:lib/commons-logging-1.0.4.jar,file:./,file:lib/jline-0.9.1.jar,file:lib/jline-0.9.94.jar,file:lib/jpam-1.1.jar,file:lib/jsch-0.1.40.jar,file:lib/jzlib-1.0.7.jar,file:lib/log4j-1.2.13.jar,file:lib/slf4j-api-1.5.2.jar,file:lib/slf4j-log4j12-1.4.3.jar,file:lib/spring-beans-2.5.5.jar,file:lib/spring-context-2.5.5.jar,file:lib/spring-core-2.5.5.jar],
> parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
> at java.net.URLClassLoader.findClass(libgcj.so.90)
> at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.90)
> at java.lang.ClassLoader.loadClass(libgcj.so.90)
> at java.lang.ClassLoader.loadClass(libgcj.so.90)
> at gnu.java.lang.MainThread.run(libgcj.so.90)
>
>
> Please help me out :)
>
>
> Kind regards,
> C. Senkowski
>
>
Christian,
Sorry for the late reply, yes, you need java 6 for this as it depends
on Mina2 and JGit in the bowles. You should be able to get ahold of the
openJDK these days on most distros.
-Mike
^ permalink raw reply
* Re: [PATCH] post-receive-email: do not call sendmail if no mail was generated
From: Lars Noschinski @ 2009-09-08 20:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, andyparkins, pape
In-Reply-To: <7v4ord19da.fsf@alter.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [09-09-08 22:15]:
> Lars Noschinski <lars@public.noschinski.de> writes:
>
> > contrib/hooks/post-receive-email used to call the send_mail function
> > (and thus, /usr/sbin/sendmail), even if generate_mail generated no
> > output. This is problematic, as the sendmail binary provided by exim4
> > generates an error mail if provided with an empty input.
>
> I actually have a bigger question, not about the implementation but about
> the cause.
>
> If generate_email results in an empty output in this codepath:
>
> # Check if we've got anyone to send to
> if [ -z "$recipients" ]; then
> ...
> echo >&2 "*** $config_name is not set so no email will be sent"
> echo >&2 "*** for $refname update $oldrev->$newrev"
> exit 0
> fi
>
> shouldn't we rather receive an error e-mail than let the
> misconfiguration go undetected?
Probably not. The error message is displayed to the user who did the
push. Normally (if no explicit From: address is configured), this is the
same user, which would receive the error mail.
> Before this check, I do not see anywhere generate_email would return nor
> exit, and after this check, there is a call to generate_email_header and
> that guarantees that the output from the generate_email function is not
> empty, so it looks to me that triggering this check is the only case your
> patch would change the behaviour of the script.
Actually, there are a two cases in the case statement before, where
generate_email would return:
refs/remotes/*,commit)
# tracking branch
refname_type="tracking branch"
short_refname=${refname##refs/remotes/}
echo >&2 "*** Push-update of tracking branch, $refname"
echo >&2 "*** - no email generated."
exit 0
;;
*)
# Anything else (is there anything else?)
echo >&2 "*** Unknown type of update to $refname ($rev_type)"
echo >&2 "*** - no email generated"
exit 1
;;
i.e. if we are pushing to a branch neither in refs/tags nor refs/heads.
In our setting, the build process pushes to refs/builds, so we can track
code changes between different builds, without displaying a whole lot of
mostly useless branches or tags to the user.
> > diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
> > index 2a66063..c855c31 100755
> > --- a/contrib/hooks/post-receive-email
> > +++ b/contrib/hooks/post-receive-email
> > @@ -637,6 +637,16 @@ show_new_revisions()
> >
> > send_mail()
> > {
> > + OIFS=$IFS
> > + IFS='
> > +'
> > + read FIRSTLINE || exit 1
>
> Shouldn't this be merely a "return"? The caller looks like this:
Yes.
I'll fix it in the next patch (when there are further comments); but you
may fold it in (and add the SOB if forgot), if you prefer.
^ permalink raw reply
* Re: git-diff: must --exit-code work with --ignore* options?
From: Thell Fowler @ 2009-09-08 20:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jim Meyering, git list
In-Reply-To: <7vljl1dpud.fsf@alter.siamese.dyndns.org>
On Sun, 30 Aug 2009, Junio C Hamano wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>> Junio C Hamano wrote:
>> ...
>>> Subject: [PATCH] diff --quiet: special case "ignore whitespace" options
>>> ...
>>> Change the semantics of --ignore-whitespace* options to mean more than
>>> "omit showing the difference in text". When these options are used, the
>>> internal "quick" optimization is turned off, and the status reported with
>>> the --exit-code option will now match if any the textual diff output is
>>> actually produced.
>>>
>>> Also rename the internal option "QUIET" to "QUICK" to better reflect what
>>> its true purpose is.
>>
>> Thanks again.
>> If there's anything I can to do help (add a test?), let me know.
>
> The change has been cooking in 'next' and hopefully be in 1.7.0. I think
> the updated series adds its own test script, too.
>
> Using it in every day scenario, and reporting any breakage you notice
> before 1.7.0 happens, would be greatly appreciated.
>
> Thanks.
Perhaps I'm expected something different than what I _should_ be
expecting, but shouldn't --quiet always return the same as --exit-code?
# Cut/Paste example
mkdir test_ws_quiet && cd test_ws_quiet && git init
printf "foo bar \n\n" >f1.txt
git add .
git commit -m 'f text'
printf "foo bar\n\n" >f1.txt
git commit -a -m 'f with diff white-space in middle & end'
git diff -w --exit-code HEAD^ >/dev/null
echo $?
# returns '0' which it should
git diff -w --quiet HEAD^
echo $?
# returns '0' which it should
git diff -b --exit-code HEAD^ >/dev/null
echo $?
# returns '0' which it should
git diff -b --quiet HEAD^ >/dev/null
echo $?
# returns '0' which it should
git diff --ignore-space-at-eol --exit-code HEAD^ >/dev/null
echo $?
# returns '1' which it should
git diff --ignore-space-at-eol --quiet HEAD^
echo $?
#returns '0' <=== Unexpected.
#
# Next phase
#
printf "foobar\n\n">f1.txt
git commit -a -m 'f without any spaces'
git diff -w --exit-code HEAD^ >/dev/null
echo $?
# returns '0' which it should
git diff -w --quiet HEAD^
echo $?
# returns '0' which it should
git diff -b --exit-code HEAD^ >/dev/null
echo $?
# returns '1' which it should
git diff -b --quiet HEAD^ >/dev/null
echo $?
# returns '0' <=== Unexpected
git diff --ignore-space-at-eol --exit-code HEAD^ >/dev/null
echo $?
# returns '1' which it should
git diff --ignore-space-at-eol --quiet HEAD^
echo $?
#returns '0' <=== Unexpected.
--
Thell
^ permalink raw reply
* Re: [PATCH] git.el: Use git-add-file for unmerged files, remove git-resolve-file
From: Junio C Hamano @ 2009-09-08 20:43 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: Martin Nordholts, git
In-Reply-To: <873a6x9t0l.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> Martin Nordholts <enselic@gmail.com> writes:
>
>> Use `git-add-file' to mark unmerged files as resolved in the
>> *git-status* buffer to be consistent with git's CLI instructions. Also
>> remove `git-resolve-file' to make it clear that that "R" is a now a
>> free keybinding.
>>
>> Signed-off-by: Martin Nordholts <martinn@src.gnome.org>
>
> Looks good, thanks.
>
> Acked-by: Alexandre Julliard <julliard@winehq.org>
Thanks, both.
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Junio C Hamano @ 2009-09-08 20:31 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johan Herland, git, trast, tavestbo, git, chriscool, spearce
In-Reply-To: <alpine.DEB.1.00.0909081100020.4330@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 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,
Actually, my knee-jerk reaction was that 4.77 (next) vs 5.57 (16tree with
2_38) is already a good enough performance/simplicity tradeoff, and 5.57
vs 5.08 (16tree with ym_2_38) probably does not justify the risk of worst
case behaviour that can come from possible mismatch between the access
pattern and the date-optimized tree layout.
But that only argues against supporting _only_ date-optimized layout.
Support of "flexible layout" is not that flexible as its name suggests;
one single note tree needs to have a uniform fanout strategy. But it is
not unusably rigid either; you only need to be extra careful when merging
two notes trees. We can leave the heuristics to choose what the optimum
layout to later rounds.
> - I find the restriction to commits rather limiting.
Yeah, we would not want to be surprised to find many people want to
annotate non-commits with this mechanism.
> - 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.
A comparison between 'next' and another algorithm that opens the top-level
notes tree object and returns "I did not find any note" without doing
anything else would reveal that cost. But when you are doing "log -n10"
(or "log --all"), you would read the notes top-level tree once, and it is
likely to be cached in the obj_hash[] (or in delta_base cache) already for
the remaining invocations, even if notes mechanism does not do its own
cache, which I think it does, no?
> - 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).
Hmph, is that a typical use case? How does it relate to CC's object
replacement mechanism?
Also Gitney talked about annotating commits in the code-review thing.
What's the expected notes density and distribution in that application?
^ permalink raw reply
* Re: [RFC PATCH 2/2] INSTALL: Describe a few knobs from the Makefile
From: Junio C Hamano @ 2009-09-08 20:26 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <1252425313-69793-2-git-send-email-brian@gernhardtsoftware.com>
Brian Gernhardt <brian@gernhardtsoftware.com> writes:
> We said that some of our dependencies were optional, but didn't say
> how to turn them off. Add information for that and mention where to
> save the options close to the top of the file.
>
> Also, reorder the list so the absolutely required ones are at the top.
>
> Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
> ---
>
> I don't know if anyone wants this level of detail in the INSTALL file, or
> if we'd prefer people actually RTFMakefile. It didn't take long to write
> though, so I thought I'd throw it out and see if people liked it.
Thanks.
Sprinkling these Makefile variable names in this document does not add too
much detail. If anything, they serve as good keyphrases to jump to when
you have Makefile in your pager and editing your own config.mak.
I like your patch especially because it makes it clear what the reader
will be missing if s/he chooses to omit some dependencies.
> + - "ssh" is used to push and pull over the net
> +
Please add a full-stop at the end (original was missing one, too).
> + - A POSIX-compliant shell is needed to use most of the bare-bones
> + Porcelainish scripts.
Let's stop talking about Porcelain/plumbing in this document.
It is very likely that the reader of this file has not read the main
documentation that talks about the two-tier structure.
The self pejorative reference "bare-bones" dates back to the days when git
Porcelains were supposed to be merely simpler reference implementations,
as opposed to something more end-user friendly like what Cogito aimed to
be. But that is an old history, and there is nothing "bare-bones" about
them anymore.
So please reword it along this line:
- A POSIX-compilant shell is needed to use many of the features
(e.g. "bisect", "pull") in everyday use.
> + - "openssl". Unless you specify otherwise (with NO_OPENSSL),
> + you'll get the SHA1 library from here.
It is not very clear what will be affected by disabling this.
- SHA-1 is not used from OpenSSL, as stated;
- imap-send won't be able to talk over SSL;
Do we still able to walk https:// URLs? If your cURL library is linked
with gnutls I think we can, but I never tried the combination.
> @@ -62,18 +73,20 @@ Issues of note:
> - libcurl library; git-http-fetch and git-fetch use them. You
> might also want the "curl" executable for debugging purposes.
> If you do not use http transfer, you are probably OK if you
> + do not have them (use NO_CURL).
Probably reads more easily if it were:
If you do not interact with http:// repositories, you do not have
to have them (say NO_CURL).
> + - "perl" is used for several scripts that are useful, but not
> + required for git (e.g. "git add -i" and "git difftool"). If you
> + don't need the *.perl scripts or the library contained in perl/,
> + then use NO_PERL.
I do not think moving "Perl" this low in the requirement level is such a
good idea, at least for now. I'd suggest movign it back immediately after
POSIX-compliant shell, and would say something like this:
- "Perl" is needed to use some of the features (e.g. preparing a
partial commit using "git add -i/-p", interacting with svn
repositories with "git svn"). If you can live without these,
say NO_PERL.
Maybe they are Ruby, github, and general acceptance by many open source
projects these days, but it used to be that the initial entry points to
git were "git cvsimport" and "git svn" for a surprisingly large number of
people.
^ permalink raw reply
* Re: [PATCH 1/2] INSTALL: Update description of our SHA-1 code
From: Junio C Hamano @ 2009-09-08 20:21 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <1252425313-69793-1-git-send-email-brian@gernhardtsoftware.com>
Brian Gernhardt <brian@gernhardtsoftware.com> writes:
> We haven't had Mozilla's code or an ARM optimized algorithm since
> 30ae47b. Reword the paragraph to give credit but not authorship to
> Mozilla.
Thanks.
> Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
> ---
>
> Minor nit I noticed while in the INSTALL file.
>
> INSTALL | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/INSTALL b/INSTALL
> index ae7f750..4a57e47 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -56,8 +56,8 @@ Issues of note:
> library from here.
>
> If you don't have openssl, you can use one of the SHA1 libraries
> - that come with git (git includes the one from Mozilla, and has
> - its own PowerPC and ARM optimized ones too - see the Makefile).
> + that come with git (git includes one based on Mozilla's as well
> + as a PowerPC optimized one - see the Makefile).
The leading comment in block/sha1.c says "initially based on ... although
none of the original remains." "one loosely based on" or "one inspired
by" might be a more fair statement, although I do not feel too strongly
about it.
>
> - libcurl library; git-http-fetch and git-fetch use them. You
> might also want the "curl" executable for debugging purposes.
> --
> 1.6.4.2.420.g30ecf
^ permalink raw reply
* Re: [PATCH] Makefile: Add NEEDS_CRYPTO_WITH_SSL
From: Junio C Hamano @ 2009-09-08 20:19 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <1252418078-68650-1-git-send-email-brian@gernhardtsoftware.com>
Brian Gernhardt <brian@gernhardtsoftware.com> writes:
> The Makefile comment for NEEDS_SSL_WITH_CRYPTO says to define it "if
> you need -lcrypto with -lssl (Darwin)." However, what it actually
> does is add -lssl when you use -lcrypto and not the other way around.
Correct. That is worth fixing.
> However, libcrypto contains a majority of the ERR_* functions from
> OpenSSL (at least on OS X) so we need it both ways.
I see. We need to be able to see ERR_err_string(), whose caller happens
to be only imap-send.c for now, and that function is in -lcrypto together
with other ERR_* functions.
> Compilation using BLK_SHA1 on OS X 10.5 and 10.6 (at least) is still
> broken without this patch.
>
> Alex Riesen <raa.lkml@gmail.com> pointed out that just adding LIB_4_CRYPTO
> to git-imap-send is simpler, but judging from the fact that nobody else
> has complained about this issue, I'm guessing that the need for -lcrypto
> when using -lssl is not widespread. (Or BLK_SHA1 isn't getting used much
> or those who do don't compile git-imap-send with SSL.)
BLK_SHA1 is fairly new on 'master', so lack of breakage report is
expected.
The patch makes sense to me, but as the result, depending on platforms
and configuration, we would use three variations when linking imap-send
with no NO_OPENSSL defined:
* Both -lcrypto -lssl
* Only -lssl
* Only -lcrypto
I wonder if we can simplify this in some way (not a 1.6.5 topic).
I am suspecting that the reason we do not say "always both" is because
depending on the vintage of OpenSSL one or the other is missing?
^ permalink raw reply
* Re: [PATCH] post-receive-email: do not call sendmail if no mail was generated
From: Junio C Hamano @ 2009-09-08 20:15 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git, andyparkins, pape, gitster
In-Reply-To: <1252436418-7660-1-git-send-email-lars@public.noschinski.de>
Lars Noschinski <lars@public.noschinski.de> writes:
> contrib/hooks/post-receive-email used to call the send_mail function
> (and thus, /usr/sbin/sendmail), even if generate_mail generated no
> output. This is problematic, as the sendmail binary provided by exim4
> generates an error mail if provided with an empty input.
I actually have a bigger question, not about the implementation but about
the cause.
If generate_email results in an empty output in this codepath:
# Check if we've got anyone to send to
if [ -z "$recipients" ]; then
...
echo >&2 "*** $config_name is not set so no email will be sent"
echo >&2 "*** for $refname update $oldrev->$newrev"
exit 0
fi
shouldn't we rather receive an error e-mail than let the
misconfiguration go undetected?
Before this check, I do not see anywhere generate_email would return nor
exit, and after this check, there is a call to generate_email_header and
that guarantees that the output from the generate_email function is not
empty, so it looks to me that triggering this check is the only case your
patch would change the behaviour of the script.
It looks to me that your exim error mail is actually reporting a
legitimate problem you would want to fix in your configuration.
> Therefore, we now read one line ourselves and use the result to decide
> if we really want to call /usr/sbin/sendmail.
> ---
> contrib/hooks/post-receive-email | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> Two things changed:
>
> - we do not read the whole mail in a shell variable
> - the decision whether to call sendmail is based on the output generated
> by generate_mail, not its return code
>
> diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
> index 2a66063..c855c31 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -637,6 +637,16 @@ show_new_revisions()
>
> send_mail()
> {
> + OIFS=$IFS
> + IFS='
> +'
> + read FIRSTLINE || exit 1
Shouldn't this be merely a "return"? The caller looks like this:
while read oldrev newrev refname
do
generate_email $oldrev $newrev $refname | send_mail
done
and you would not want to stop after punting to report on the first ref.
> + (printf $FIRSTLINE'\n'; cat) | call_sendmail
> + IFS=$OLD_IFS
> +}
> +
> +call_sendmail()
> +{
> if [ -n "$envelopesender" ]; then
> /usr/sbin/sendmail -t -f "$envelopesender"
> else
> @@ -644,6 +654,7 @@ send_mail()
> fi
> }
>
> +
> # ---------------------------- main()
>
> # --- Constants
Why?
^ permalink raw reply
* Re: [PATCH] Add more instructions about how to install git.
From: Matthieu Moy @ 2009-09-08 19:41 UTC (permalink / raw)
To: Thiago Farina; +Cc: Johannes Sixt, Alex Riesen, git
In-Reply-To: <a4c8a6d00909080752p5b663fc8r8bf1c60023ef39b4@mail.gmail.com>
Thiago Farina <tfransosi@gmail.com> writes:
> Running only "make".
> $ make
[...]
> Running configure and then make
> $ make configure
> GIT_VERSION = 1.6.5.rc0.dirty
> GEN configure
> $ make
[...]
What about trying to do what the INSTALL file suggests, then?
| 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
You did the first line, but the three next one give you instructions
that you didn't follow. These instructions start line 16 of the
INSTALL file, that is, in the first screen when viewing the file with
a reasonable window size.
I tend to disagree with the mainainer that the configure should be the
"alternate" and plain make the recommanded way, but the configure
script is there, it works, it's documented early enough in the INSTALL
file, so what's the problem?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] gitk: restore wm state to normal before saving geometry information
From: Alexey Borzenkov @ 2009-09-08 19:22 UTC (permalink / raw)
To: git; +Cc: paulus, Alexey Borzenkov
gitk now includes patches for saving and restoring wm state, however
because it saves wm geometry when window can still be maximized the
maximize/restore button becomes useless after restarting gitk (you
will get a huge displaced window if you try to restore it). This
patch fixes this issue by storing window geometry in normal state.
Signed-off-by: Alexey Borzenkov <snaury@gmail.com>
---
My previous email didn't come out rights, I hope this one will
Don't forget to cc me if you have any comments/questions
gitk | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 8c08310..fedeb88 100755
--- a/gitk
+++ b/gitk
@@ -2555,8 +2555,11 @@ proc savestuff {w} {
puts $f [list set extdifftool $extdifftool]
puts $f [list set perfile_attrs $perfile_attrs]
- puts $f "set geometry(main) [wm geometry .]"
puts $f "set geometry(state) [wm state .]"
+ if {[wm state .] eq {zoomed}} {
+ wm state . normal
+ }
+ puts $f "set geometry(main) [wm geometry .]"
puts $f "set geometry(topwidth) [winfo width .tf]"
puts $f "set geometry(topheight) [winfo height .tf]"
puts $f "set geometry(pwsash0) \"[.tf.histframe.pwclist sash coord 0]\""
--
1.6.4.2
^ permalink raw reply related
* Re: [PATCH] post-receive-email: do not call sendmail if no mail was generated
From: Lars Noschinski @ 2009-09-08 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andy Parkins, Gerrit Pape
In-Reply-To: <7vk5098jcv.fsf@alter.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [09-09-08 19:22]:
> Lars Noschinski <lars@public.noschinski.de> writes:
> > * 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>
[...]
> - Slurping generate_email's output into a shell variable is a bad taste.
> You said that the message is always small enough but _how_ do we know
> it?
You are right; I overlooked that the revision formatting is configurable
and if set up to display the full patch, the mail could get pretty big.
I know found a solution which does neither store the full output in a
variable nor needs a temporary file. I will post it as a reply to this
mail.
> - If this is to save us from a quirk in some but not all implementations
> of /usr/lib/sendmail, then shouldn't the logic be made into a new
> conditional?
I don't know if this a quirk in exim; I could not find a formal
specification of the sendmail behaviour and treating such an "input" as
an error seems at least not insane.
In any case, I think the overhead implied by new patch is small enough,
that a switch is unnecessary.
> - I do not see a direct link between "if generate_mail returned an error"
> and "if ... an empty input". What if generate_mail started its output
> but then failed halfway? We have some output so the send_mail won't be
> fed empty, but $? would be not zero, so the patch is testing a
> different condition from what the log message claims to be checking.
Yeah, you are right. This is also fixed in the new patch.
> People who do use this script and people who have worked on it may have
> other more useful comments.
CCed some of them.
^ permalink raw reply
* [PATCH] post-receive-email: do not call sendmail if no mail was generated
From: Lars Noschinski @ 2009-09-08 19:00 UTC (permalink / raw)
To: git; +Cc: andyparkins, pape, gitster, Lars Noschinski
In-Reply-To: <20090908185555.GA3858@lars.home.noschinski.de>
contrib/hooks/post-receive-email used to call the send_mail function
(and thus, /usr/sbin/sendmail), even if generate_mail generated no
output. This is problematic, as the sendmail binary provided by exim4
generates an error mail if provided with an empty input.
Therefore, we now read one line ourselves and use the result to decide
if we really want to call /usr/sbin/sendmail.
---
contrib/hooks/post-receive-email | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
Two things changed:
- we do not read the whole mail in a shell variable
- the decision whether to call sendmail is based on the output generated
by generate_mail, not its return code
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 2a66063..c855c31 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -637,6 +637,16 @@ show_new_revisions()
send_mail()
{
+ OIFS=$IFS
+ IFS='
+'
+ read FIRSTLINE || exit 1
+ (printf $FIRSTLINE'\n'; cat) | call_sendmail
+ IFS=$OLD_IFS
+}
+
+call_sendmail()
+{
if [ -n "$envelopesender" ]; then
/usr/sbin/sendmail -t -f "$envelopesender"
else
@@ -644,6 +654,7 @@ send_mail()
fi
}
+
# ---------------------------- main()
# --- Constants
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 3/4] push: make non-fast-forward help message configurable
From: Uri Okrent @ 2009-09-08 18:51 UTC (permalink / raw)
To: Jeff King
Cc: Matthieu Moy, Nanako Shiraishi, Junio C Hamano, Teemu Likonen,
Git
In-Reply-To: <20090907085405.GA17968@coredump.intra.peff.net>
On 09/07/2009 01:54 AM, Jeff King wrote:
> At that point, why not just get rid of "message.all" and simply say
> "manually turn off the messages you don't like". Then the user can
> either go through the config manually as above, or they can wait until
> they become annoyed with a particular message and turn it off (and
> hopefully our naming is good enough that they can easily figure out
> which one it was :) ).
>
> So I think "be verbose, but let the user quiet us" is probably
> better than "be quiet, but let the user make us louder", because it is
> easier to discover verbose things. Which implies to me that
> "message.all", if it exists at all, should be limited in scope to just
> advice.
That seems like the most sane solution, given that it may not be obvious
to the user what messages he/she may be missing if "expert" mode is on,
and also from a coding perspective.
I know that by default I'd like to see new messages, and in case I'm
doing something adventurous I'd like to see a message I may not have
seen before. If I had turned off all messages because I got sick of
seeing one or two in particular, then I'd never know.
Also, this thread started due to people's dislike of one particular
message, so I think it's likely that in general someone would really
only want to turn off at most a handful of messages, which again points
to turning them off individually as being the best and simplest solution.
P.S. I never really introduced myself to the list... Uri Okrent here
from L.A. Keep up the great work everyone!
--
Uri
Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/
^ permalink raw reply
* [PATCH] gitk: restore wm state to normal before saving geometry information
From: Alexey Borzenkov @ 2009-09-08 18:44 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
gitk now includes patches for saving and restoring wm state, however
because it saves wm geometry when window can still be maximized the
maximize/restore button becomes useless after restarting gitk (you
will get a huge displaced window if you try to restore it). This
patch fixes this issue by storing window geometry in normal state.
Signed-off-by: Alexey Borzenkov <snaury@gmail.com>
---
Please don't forget to cc me if you have comments/questions
gitk | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 8c08310..fedeb88 100755
--- a/gitk
+++ b/gitk
@@ -2555,8 +2555,11 @@ proc savestuff {w} {
puts $f [list set extdifftool $extdifftool]
puts $f [list set perfile_attrs $perfile_attrs]
- puts $f "set geometry(main) [wm geometry .]"
puts $f "set geometry(state) [wm state .]"
+ if {[wm state .] eq {zoomed}} {
+ wm state . normal
+ }
+ puts $f "set geometry(main) [wm geometry .]"
puts $f "set geometry(topwidth) [winfo width .tf]"
puts $f "set geometry(topheight) [winfo height .tf]"
puts $f "set geometry(pwsash0) \"[.tf.histframe.pwclist sash
coord 0]\""
--
1.6.4.2
^ permalink raw reply related
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