* Re: [PATCH] init-db: support --import to add all files and commit right after init
From: Miles Bader @ 2009-03-31 9:09 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20090325041934.GA15524@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I seem to recall that we were phasing out "--long-option <arg>" at some
> point, and that all long-options should use "--long-option=". But maybe
> I am mis-remembering.
Surely it should support both where possible, since both are standard
syntaxes for passing args to "--"-style long options (so users expect
both to work).
-Miles
--
Occam's razor split hairs so well, I bought the whole argument!
^ permalink raw reply
* Re: [PATCH] git-svn: fix ls-tree usage with dash-prefixed paths
From: Björn Steinbrink @ 2009-03-31 7:31 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git, Anton Gyllenberg
In-Reply-To: <20090331071100.GA3307@atjola.homenet>
On 2009.03.31 09:11:00 +0200, Björn Steinbrink wrote:
> And interestingly, the problem doesn't seem to be in
> show_tree/show_recursive, but in match_tree_entry.
>
> With "git ls-tree HEAD gitweb/git-favicon.png g" we descend into gitweb/
> and at some point we get:
>
> match = "g"
> base = "gitweb/"
>
> And we have:
> if (baselen >= matchlen) {
> if (strncmp(base, match, matchlen))
> continue;
> /* The base is a subdirectory of a path which was specified */
> return 1;
> }
>
> So we return 1 there. The code doesn't do what the comment says, so I
> guess we can be pretty sure that the behaviour is not intended.
Yup, it's in match_tree_entry, you get the same thing with git show.
With git.git, you can try with:
git show 4fa535a -- Documentation/git-merge.txt D
I'll try to get a patch done, if noone beats me to it.
Björn
^ permalink raw reply
* Re: [Q] merging from one (kernel) stable to another?
From: Brian Foster @ 2009-03-31 7:30 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git mailing list
In-Reply-To: <alpine.LNX.1.00.0903301311230.19665@iabervon.org>
On Monday 30 March 2009 19:31:18 Daniel Barkalow wrote:
> On Mon, 30 Mar 2009, Brian Foster wrote:
> > Whilst this question involves linux(-mips) kernel tree,
> > it's a git(-related?) question, not a kernel question ....
> >
> > We are currently in the process of upgrading our embedded
> > system from kernel 2.6.21(-ish) to at least 2.6.26.8; and
> > later, at some time in the future on to 2.6.3x or something.
> > Going from 2.6.21 to .22 to .23 and so on to .26, then to
> > .26.1 and so on to .26.8 is “easy” in the sense there are
> > very few conflicts with our existing baseline (e.g., just
> > 2 or 3 in 2 or 3 files).
> >
> > .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master
> > \ \ \ \ \
> > .21-stable .22-stable .23-stable \ .27-stable
> > .26.8
> > \
> > .26-stable
> >
> > But (using 2.6.21-stable and 2.6.22-stable as proxies),
> > tests indicate that going from .26.8 to .27 or anything
> > later will have numerous conflicts (100s? in more than
> > 30 files). Thinking about it, this isn't too surprising
> > since the -stable branches cherry-pick important/benign
> > fixes from later revisions.
>
> Why are you going from .26.8 to .27? Based on the -stable policy,
> there should be no reason not to skip .26.x between .26 and .27.
Daniel,
That's a good question! The policy to-date has been to
ignore the -stable branches entirely, and go from release
to release; i.e., .21 to .22 to ... to .26 to .27 et al.
We (deliberately!) stay several releases behind (being
bang-up-to-date isn't too important to our market/product,
but having a robust secure system is extremely important).
The current feeling is we should probably be moving from
-stable to -stable, i.e., .21-stable to .22-stable to ...
to .26-stable and later to .27-stable and so on. This is
based, in part, on observing the changes that are in -stable
and realizing some of them are highly desirable. This new
idea/plan of going from -stable to -stable can change if
there's a good reason. It's currently in a state of flux.
So I somewhat incorrectly described the thinking, mixing
up our historical practice with the proposed new policy.
In my defense, my I point out that we are particularly
interested in some MIPS changes on .26-stable, and, at the
the moment, have decided to not go to .27 for this cycle.
(Admittedly, with the release of .29, the decision not to
go to .27 has been challenged, but the issue hasn't been
looked into in any detail (yet? as far as I know).)
Anyways, good catch! I take your point. Many thanks.
> In fact, it's
> not unlikely that merging both .26.8 and .27 will introduce bugs when the
> same issue was fixed in different places in the two branches: a narrow
> patch to paper over the identified problem in -stable and an intrusive
> patch to change some API to make simpler code correct in the mainline.
>
> That is, the correct way of merging changes from -stable with the latest
> mainline series is always to take the mainline version, even if the
> -stable changes don't conflict at all.
Yep! We don't want to merge changes from -stable
into master (mainline). That was a mistake in my
description. Again, thanks for pointing it out.
> It should actually be ideal to just merge your local changes directly with
> the mainline kernel you want to end up using. But you might want to merge
> first with earlier mainline kernels in order to get fewer or easier
> conflicts per step.
Indeed. We are progressing one release at a time.
(I've been insisting on this!) However, given we're
not targeting .27 or later at this cycle, and that
we know there are changes on .26-stable we want/need,
it's (almost) a dead cert our next release will be
based on some point in .26-stable (I'm using .26.8
as a proxy as it's the latest (when I checked) tag
on .26-stable).
Things are in flux, and suggestions are certainly
welcome. Thanks for your very helpful observations.
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Re: [StGit PATCH] Add the --merged option to goto
From: Karl Hasselström @ 2009-03-31 7:27 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0903300901i469bd899v3518b43c331bd9df@mail.gmail.com>
On 2009-03-30 17:01:12 +0100, Catalin Marinas wrote:
> 2009/3/26 Karl Hasselström <kha@treskal.com>:
>
> > On 2009-03-25 10:24:13 +0000, Catalin Marinas wrote:
> >
> > > BTW, why don't we keep the tree information directly in the
> > > Index object? Since this object is modified only via its own
> > > interface, it can do all the checks and avoid the managing of
> > > temp_index_tree in the Transaction object.
> >
> > I guess that might be a good idea -- it should be doable without
> > any extra overhead for users that don't want it.
>
> I tried but gave up quickly. The IndexAndWorktree class also dirties
> the Index with the merge operations, so it is not worth the hassle.
OK. (Though you should be able to set the tree to None for those
cases, since the meaning of None is simply that we don't promise
anything about what tree is currently in the index.)
And since I've run out of even remotely plausible things to complain
about,
Acked-by: Karl Hasselström <kha@treskal.com>
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Segfault on merge with 1.6.2.1
From: Michael Johnson @ 2009-03-31 7:14 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20090330110335.GF22446@genesis.frugalware.org>
On Mon, 30 Mar 2009 06:03:35 -0500, Miklos Vajna <vmiklos@frugalware.org>
wrote:
> On Sun, Mar 29, 2009 at 09:39:49PM -0500, Michael Johnson
> <redbeard@mdjohnson.us> wrote:
>> Well, I've got a backtrace, but I don't have debugging symbols,
>> apparently. There is not a Debian package I can find that has them. I
>> checked debug.debian.net, as well as the standard sid repository. So I
>> will have to rebuild the package with debugging turned on. I will not be
>> able to do that tonight, unfortunately. I will probably have a chance
>> tomorrow evening.
>
> Okay, no rush. In case Dscho's patch does not fix your problem, please
> rebuild git with debug symbols enabled and send a normal trace.
>
It would appear that the patch has already been applied to 1.6.2.1.
That said, here's my backtrace. I've tried tracing through to figure out
where the problem is occurring, but my gdb-foo is non-existent, I'm wating
for some GUIs to install, and I'm ready for some sleep :| So if I haven't
heard back by tomorrow evening, I'll be running one of the frontends for
gdb until I have something traced down :)
If you need any more information, please let me know.
Thanks,
Michael
(gdb) run merge origin/dojo-1.3
Starting program: /usr/bin/git merge origin/dojo-1.3
[Thread debugging using libthread_db enabled]
[New Thread 0xb7b1bb30 (LWP 2651)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7b1bb30 (LWP 2651)]
0x080fa828 in parse_tree (item=0x0) at tree.c:250
250 if (item->object.parsed)
(gdb) backtrace
#0 0x080fa828 in parse_tree (item=0x0) at tree.c:250
#1 0x080cc40b in init_tree_desc_from_tree (desc=0xbfdf53ac, tree=0x0) at
merge-recursive.c:161
#2 0x080cc4d4 in git_merge_trees (index_only=1, common=0x8fa5df8,
head=0x0, merge=0x8fa5718) at merge-recursive.c:186
#3 0x080cf28e in merge_trees (o=0xbfdf54d0, head=0x0, merge=0x8fa5718,
common=0x8fa5df8, result=0xbfdf5448)
at merge-recursive.c:1170
#4 0x080cf75f in merge_recursive (o=0xbfdf54d0, h1=0x8ffc200,
h2=0x8f992f0, ca=0x0, result=0xbfdf548c)
at merge-recursive.c:1294
#5 0x080cf6c7 in merge_recursive (o=0xbfdf54d0, h1=0x8f99050,
h2=0x8f98ff0, ca=0x8f97b98, result=0xbfdf551c)
at merge-recursive.c:1280
#6 0x08080d75 in try_merge_strategy (strategy=0x811b9b0 "recursive",
common=0x8fd40f0, head_arg=0x811be14 "HEAD")
at builtin-merge.c:566
#7 0x08082446 in cmd_merge (argc=1, argv=0xbfdf5808, prefix=0x0) at
builtin-merge.c:1111
#8 0x0804bb5f in run_builtin (p=0x8130400, argc=2, argv=0xbfdf5808) at
git.c:244
#9 0x0804bcf3 in handle_internal_command (argc=2, argv=0xbfdf5808) at
git.c:388
#10 0x0804bdf0 in run_argv (argcp=0xbfdf5780, argv=0xbfdf5784) at git.c:434
#11 0x0804bf82 in main (argc=2, argv=0xbfdf5808) at git.c:505
--
Michael D Johnson <redbeard@mdjohnson.us>
redbeardcreator.deviantart.com
"Marketing research...[has] shown that energy weapons that make sounds sell
better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111)
^ permalink raw reply
* Re: [PATCH] git-svn: fix ls-tree usage with dash-prefixed paths
From: Björn Steinbrink @ 2009-03-31 7:11 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git, Anton Gyllenberg
In-Reply-To: <20090330225834.GA24254@dcvr.yhbt.net>
On 2009.03.30 15:58:34 -0700, Eric Wong wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > Eric Wong <normalperson@yhbt.net> writes:
> > > From the ls-tree documentation, I was under the impression that "--"
> > > matching "--dashed" was intended:
> > >
> > > When paths are given, show them (note that this isn't really raw
> > > pathnames, but rather a list of patterns to match).
> > >
> > > It doesn't make sense to me match like this, either; but I do think it
> > > was intended and it will break things if people depend on the
> > > existing behavior.
I guess that paragraph was meant to explain why "git ls-tree HEAD
Documentation" and "git ls-tree HEAD Documentation/" give different
results. The first one shows the entry for the tree object, while the
second one shows the contents of the tree object. In contrast to "ls"
which would descend into the directory in both cases.
> > Ok, but then the decision to descend into --dashed should be consistent
> > with that policy, no? Right now, it appears that giving "--" alone says
> > "Anything under --dashed can never match that pattern, so I wouldn't
> > bother recursing into it".
>
> Right. Except in the case when there are multiple files inside --dashed/
> as Björn's email illustrated. So there seems to be a bug in the way
> the number of files inside --dashed/ affects what "--" does when used
> with "--dashed/1" (if --dashed/2 also exists). Very confusing :x
It's not the number of files that matters. With just one file, you just
don't notice the buggy behaviour, because showing all files is the same
as showing the specified file.
And interestingly, the problem doesn't seem to be in
show_tree/show_recursive, but in match_tree_entry.
With "git ls-tree HEAD gitweb/git-favicon.png g" we descend into gitweb/
and at some point we get:
match = "g"
base = "gitweb/"
And we have:
if (baselen >= matchlen) {
if (strncmp(base, match, matchlen))
continue;
/* The base is a subdirectory of a path which was specified */
return 1;
}
So we return 1 there. The code doesn't do what the comment says, so I
guess we can be pretty sure that the behaviour is not intended.
Björn
^ permalink raw reply
* Re: [PATCH 0/5] Header includes cleanup
From: Christian Couder @ 2009-03-31 6:59 UTC (permalink / raw)
To: Nathaniel P Dawson; +Cc: Johannes Sixt, git
In-Reply-To: <20090330173319.GC25950@eiku.org>
Le lundi 30 mars 2009, Nathaniel P Dawson a écrit :
> I'm sorry, I must have misunderstood the task on the janitor
> list. Could you explain it a bit better so I would be able to do it
> properly?
Actually I added this task to the Janitor page on the wiki because I was
tired of having to find which other includes are needed each time I
include "revision.h". And I think there are other worthwile include cleanup
that could be done.
I think it's a good thing that you started working on it even if in the end
we decide that we want these cleanup to be done otherwise. At least we will
hopefully have clarified our include header policy.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH] git-svn: add a double quiet option to hide git commits
From: Eric Wong @ 2009-03-31 6:52 UTC (permalink / raw)
To: Simon Arlott; +Cc: Junio C Hamano, git, mdpoole
In-Reply-To: <49D1100D.8010206@simon.arlott.org.uk>
Simon Arlott <simon@fire.lp0.eu> wrote:
> People may expect/prefer -q to still show git commits,
> so this change allows a second -q to hide them.
>
> Signed-off-by: Michael Poole <mdpoole@troilus.org>
> Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Thanks,
Acked-by: Eric Wong <normalperson@yhbt.net>
and pushed out to git://git.bogomips.org/git-svn
> ---
> On 30/03/09 07:44, Junio C Hamano wrote:
> > Eric Wong <normalperson@yhbt.net> writes:
> >> Simon Arlott <simon@fire.lp0.eu> wrote:
> >>> Ideally only errors should be output in this mode so fetch
> >>> can be run from cron and normally produce no output. Without
> >>> this change it would output a single line on each git commit,
> >>> e.g.
> >>> r1909 = 32ef87860662526d4a62f903949ed21e0341079e (u2_10_12_branch)
>
> Documentation/git-svn.txt | 3 ++-
> git-svn.perl | 9 +++++----
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index cda3389..8163a19 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -385,7 +385,8 @@ config key: svn.authorsfile
>
> -q::
> --quiet::
> - Make 'git-svn' less verbose.
> + Make 'git-svn' less verbose. Specify a second time to make it
> + even less verbose.
>
> --repack[=<n>]::
> --repack-flags=<flags>::
> diff --git a/git-svn.perl b/git-svn.perl
> index e5c3dfe..d919798 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -68,6 +68,7 @@ my ($_stdin, $_help, $_edit,
> $_prefix, $_no_checkout, $_url, $_verbose,
> $_git_format, $_commit_url, $_tag);
> $Git::SVN::_follow_parent = 1;
> +$_q ||= 0;
> my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
> 'config-dir=s' => \$Git::SVN::Ra::config_dir,
> 'no-auth-cache' => \$Git::SVN::Prompt::_no_auth_cache,
> @@ -80,7 +81,7 @@ my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
> 'useSvnsyncProps' => \$Git::SVN::_use_svnsync_props,
> 'log-window-size=i' => \$Git::SVN::Ra::_log_window_size,
> 'no-checkout' => \$_no_checkout,
> - 'quiet|q' => \$_q,
> + 'quiet|q+' => \$_q,
> 'repack-flags|repack-args|repack-opts=s' =>
> \$Git::SVN::_repack_flags,
> 'use-log-author' => \$Git::SVN::_use_log_author,
> @@ -2331,13 +2332,13 @@ sub do_git_commit {
>
> $self->{last_rev} = $log_entry->{revision};
> $self->{last_commit} = $commit;
> - print "r$log_entry->{revision}" unless $::_q;
> + print "r$log_entry->{revision}" unless $::_q > 1;
> if (defined $log_entry->{svm_revision}) {
> - print " (\@$log_entry->{svm_revision})" unless $::_q;
> + print " (\@$log_entry->{svm_revision})" unless $::_q > 1;
> $self->rev_map_set($log_entry->{svm_revision}, $commit,
> 0, $self->svm_uuid);
> }
> - print " = $commit ($self->{ref_id})\n" unless $::_q;
> + print " = $commit ($self->{ref_id})\n" unless $::_q > 1;
> if (--$_gc_nr == 0) {
> $_gc_nr = $_gc_period;
> gc();
> --
> 1.6.2
> --
> Simon Arlott
^ permalink raw reply
* Re: [PATCH 07/10] rev-list: call new "filter_skip" function
From: Christian Couder @ 2009-03-31 6:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, John Tapsell
In-Reply-To: <alpine.DEB.1.00.0903300951460.7534@intel-tinevez-2-302>
Hi,
Le lundi 30 mars 2009, Johannes Schindelin a écrit :
> Hi,
>
> On Mon, 30 Mar 2009, Christian Couder wrote:
> > Le jeudi 26 mars 2009, Junio C Hamano a écrit :
> > >
> > > I've learned to suspect without reading a qsort() callback that does
> > > not derefence its arguments. Is this doing the right thing?
> >
> > I think so.
>
> I suspect something much worse: you are trying to build a list of sha1s
> of commits that need to be skipped, later to look up every commit via
> binary search.
>
> But it has been proven a lot of times that using a hash set is superior
> to that approach, and even better: we already have the framework in place
> in the form of struct decorate.
I had a look, and "struct decorate" can be used to store objects, but I want
to store only sha1s.
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH 1/8] mergetool: use tabs consistently
From: David Aguilar @ 2009-03-31 6:36 UTC (permalink / raw)
To: Charles Bailey; +Cc: Junio C Hamano, git
In-Reply-To: <20090330213530.GA7091@hashpling.org>
On 0, Charles Bailey <charles@hashpling.org> wrote:
> On Mon, Mar 30, 2009 at 01:44:01AM -0700, Junio C Hamano wrote:
>
> I don't much like [1/8] though. I'm all in favour of consistency, but
> this patch touches most of the lines in git-mergetool and tries to go
> the opposite way to the consistency drive that we were trying to
> introduce gradually (i.e. only through lines materially affected by
> subsequent patches) in:
Sounds good. I'll re-roll and give the refactoring another go.
I think we can definitely do better, and more importantly, I
think we can decouple things by using less globals.
Junio, did you have any comments about patch v2
"difftool: add support for difftool.prompt config variable"?
This series was based on top of that patch so I'm wondering if I
should do that again.
>
> commit 0eea345111a9b9fea4dd2841b80bc7d62964e812
> Author: Charles Bailey <charles@hashpling.org>
> Date: Thu Nov 13 12:41:13 2008 +0000
>
> Fix some tab/space inconsistencies in git-mergetool.sh
>
> If you'd gone the other way the patch to consistency would only affect
> 23 lines rather than 347 lines and all bar 3 of these lines you
> subsequently remove from git-mergetool.sh in later patches anyway.
>
> [2/8] - looks good.
>
> [3/8] - no mergetool impact.
>
> [4/8] - Hmmm, OK. Even so at this point, I'm getting slightly iffy
> feelings about the whole init_merge_tool_path sets a variable needed
> by the calling script. I know it's only scripting and not programming,
> but it seemed less bad to set (global) variables in sh functions when
> they were all in the same sh script.
>
> [5/8] - no mergtool impact.
>
> [6/8] - ditto
>
> [7/8] - OK, here's where my uneasiness about global script variables
> vs. parameters really gets going. Why is merge_tool a parameter when
> it's setup once and doesn't change in the invocation of a script, yet
> base_present is a script global but can vary between sets of paths to
> be merged?
>
> I fully appreciate that this is just inheriting the way things are
> and that they weren't beautiful before, but it somehow seems even
> worse when the variables are set in one script and used from a
> function in a separate sourced script. We're definitely setting up a
> very strong coupling between the two scripts which will make it harder
> to change either in the future.
>
> [8/8] - no mergetool impact here.
>
> On the plus side, I really like the introduction and function of the
> run_mergetool function. It's exactly the split that will make
> extending mergetool resolves of file vs. symlink vs. directory easier
> in the future. I have a similar split in some slow brewing patches
> myself.
>
> I think that [1/8] is the only patch that I'd relucatant to ack, as it
> seems like unnecessary churn and change of direction. Here's a sample
> patch for consistency 'the other way'. As I mentioned before, the
> first to hunks are made redundant by your subsequent changes anyway,
> so I only counted 3 lines that are currently inconsistent in
> git-mergetool as it stands at the moment.
>
> Sample patch fixing consistent whitespace 'the other way'.
> ---
> git-mergetool.sh | 46 +++++++++++++++++++++++-----------------------
> 1 files changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index 87fa88a..1588b5f 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -344,29 +344,29 @@ valid_custom_tool()
> }
>
> valid_tool() {
> - case "$1" in
> - kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
> - ;; # happy
> - *)
> - if ! valid_custom_tool "$1"; then
> - return 1
> - fi
> - ;;
> - esac
> + case "$1" in
> + kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
> + ;; # happy
> + *)
> + if ! valid_custom_tool "$1"; then
> + return 1
> + fi
> + ;;
> + esac
> }
>
> init_merge_tool_path() {
> - merge_tool_path=`git config mergetool.$1.path`
> - if test -z "$merge_tool_path" ; then
> - case "$1" in
> - emerge)
> - merge_tool_path=emacs
> - ;;
> - *)
> - merge_tool_path=$1
> - ;;
> - esac
> - fi
> + merge_tool_path=`git config mergetool.$1.path`
> + if test -z "$merge_tool_path" ; then
> + case "$1" in
> + emerge)
> + merge_tool_path=emacs
> + ;;
> + *)
> + merge_tool_path=$1
> + ;;
> + esac
> + fi
> }
>
> prompt_after_failed_merge() {
> @@ -389,9 +389,9 @@ prompt_after_failed_merge() {
> if test -z "$merge_tool"; then
> merge_tool=`git config merge.tool`
> if test -n "$merge_tool" && ! valid_tool "$merge_tool"; then
> - echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
> - echo >&2 "Resetting to default..."
> - unset merge_tool
> + echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
> + echo >&2 "Resetting to default..."
> + unset merge_tool
> fi
> fi
>
> --
> 1.6.2.323.geaf6e
>
> --
> Charles Bailey
> http://ccgi.hashpling.plus.com/blog/
--
David
^ permalink raw reply
* Re: "git reflog expire --all" very slow
From: Junio C Hamano @ 2009-03-31 6:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brandon Casey, Johannes Schindelin, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0903302244580.4093@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, 30 Mar 2009, Linus Torvalds wrote:
>>
>> If I do
>>
>> mark_reachable(cb.ref_commit, 0);
>
> Ok, I think I got it.
>
> You had
>
> mark_reachable(cb.ref_commit, cmd->expire_unreachable);
>
> but we care about the commits that are younger than 'expire_total' (older
> than that, and they are pruned unconditionally), but older than
> 'expire_unreachable' (younger than that and the date doesn't matter).
>
> So making it do
>
> mark_reachable(cb.ref_commit, cmd->expire_total);
>
> marks the right parts reachable. Not the whole tree, but also not just the
> commits we're not going to expire regardless.
>
> With that change, it's all basically instantaneous. We don't need to
> traverse the whole kernel history, and with that change to your patch, I
> get
>
> [torvalds@nehalem linux]$ time ~/git/git reflog expire --all
>
> real 0m1.715s
> user 0m1.676s
> sys 0m0.040s
>
> which is still slower than I'd wish for, but is a whole lot faster than
> over half a minute.
Actually, the initial pruning I showed (around 23 seconds) is not helped
with the expire_total change at all, but if I mark everything and get rid
of in_merge_bases(), it goes down to 1.15 seconds.
But subsequent pruning, which is what we should be optimizing for, gets
much faster with your approach of not traversing down the history all the
way.
By the way, I suspect I might be making the same mistake of traversing
both sides of the merge twice while marking, but I am tired already, so
I'll throw out the final patch for tonight and go to bed.
builtin-reflog.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/builtin-reflog.c b/builtin-reflog.c
index d95f515..b67272a 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -52,6 +52,7 @@ struct collect_reflog_cb {
#define INCOMPLETE (1u<<10)
#define STUDYING (1u<<11)
+#define REACHABLE (1u<<12)
static int tree_is_complete(const unsigned char *sha1)
{
@@ -209,6 +210,43 @@ static int keep_entry(struct commit **it, unsigned char *sha1)
return 1;
}
+static void mark_reachable(struct commit *commit, unsigned long expire_limit)
+{
+ /*
+ * We need to compute if commit on either side of an reflog
+ * entry is reachable from the tip of the ref for all entries.
+ * Mark commits that are reachable from the tip down to the
+ * time threashold first; we know a commit marked thusly is
+ * reachable from the tip without running in_merge_bases()
+ * at all.
+ */
+ struct commit_list *pending = NULL;
+
+ commit_list_insert(commit, &pending);
+ while (pending) {
+ struct commit_list *entry = pending;
+ struct commit_list *parent;
+ pending = entry->next;
+ commit = entry->item;
+ free(entry);
+ if (commit->object.flags & REACHABLE)
+ continue;
+ commit->object.flags |= REACHABLE;
+ parent = commit->parents;
+ while (parent) {
+ commit = parent->item;
+ parent = parent->next;
+ if (commit->object.flags & REACHABLE)
+ continue;
+ if (parse_commit(commit))
+ continue;
+ if (expire_limit && commit->date < expire_limit)
+ continue;
+ commit_list_insert(commit, &pending);
+ }
+ }
+}
+
static int expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
const char *email, unsigned long timestamp, int tz,
const char *message, void *cb_data)
@@ -234,8 +272,10 @@ static int expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
old = lookup_commit_reference_gently(osha1, 1);
if (!new && !is_null_sha1(nsha1))
new = lookup_commit_reference_gently(nsha1, 1);
- if ((old && !in_merge_bases(old, &cb->ref_commit, 1)) ||
- (new && !in_merge_bases(new, &cb->ref_commit, 1)))
+ if ((old && !(old->object.flags & REACHABLE) &&
+ !in_merge_bases(old, &cb->ref_commit, 1)) ||
+ (new && !(new->object.flags & REACHABLE) &&
+ !in_merge_bases(new, &cb->ref_commit, 1)))
goto prune;
}
@@ -288,7 +328,11 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,
cb.ref_commit = lookup_commit_reference_gently(sha1, 1);
cb.ref = ref;
cb.cmd = cmd;
+ if (cb.ref_commit)
+ mark_reachable(cb.ref_commit, cmd->expire_total);
for_each_reflog_ent(ref, expire_reflog_ent, &cb);
+ if (cb.ref_commit)
+ clear_commit_marks(cb.ref_commit, REACHABLE);
finish:
if (cb.newlog) {
if (fclose(cb.newlog)) {
^ permalink raw reply related
* Re: "git reflog expire --all" very slow
From: Junio C Hamano @ 2009-03-31 5:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brandon Casey, Johannes Schindelin, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0903302239040.4093@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, 30 Mar 2009, Junio C Hamano wrote:
>>
>> I do have a lot of reflog entries kept around, as my main repository has
>> these:
>>
>> [gc]
>> reflogexpire = '2005-01-01 00:00:00 +0000'
>> reflogexpireunreachable = '2005-01-01 00:00:00 +0000'
>
> I think that actually _hides_ the problem. You'll never have anything at
> all that triggers that
>
> if (timestamp < cb->cmd->expire_unreachable) {
>
> because your "expire_unreachable" timestamp is already very old (== small
> value), so 'timestamp' will _not_ be older (smaller value) than that.
>
> I dunno. As mentioned, I don't really understand why we'd want to save
> some of those reflog entries at all in the first place, so I'm probably
> missing something.
>
> If we've asked for reflog entries past a certain age to be expired, why do
> when then look at the details of those reflog entries and only expire them
> under certain circumstances? Just expire them, and get rid of the
> 'unreachable' part.
I know. My test repository does not have them. I only quoted them to
tell you that I have a lot of entries to play with.
^ permalink raw reply
* Re: [PATCH 0/5] Header includes cleanup
From: Christian Couder @ 2009-03-31 5:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nathaniel P Dawson, git
In-Reply-To: <49D0A3DF.4000203@viscovery.net>
Le lundi 30 mars 2009, Johannes Sixt a écrit :
> Please wrap your lines at ca. 75 columns.
>
> Nathaniel P Dawson schrieb:
> > This is just the beginning for this project. I'm slowly cleaning up
> > the header includes one chunk at a time. I hope my patches aren't too
> > messy, I've learned how to better utilize git to make patches and
> > organize my commits logically so I'll submit neater chunks henceforth.
> > You can expect patches from me nightly until I've finished this
> > project.
>
> You have removed includes that are implied by other includes, i.e. if
> foo.h includes bar.h, then you removed #include "bar.h" from *.c if there
> is #include "foo.h".
>
> IMO, this is not a good guiding principle to reduce includes. A better
> principle is to keep #include "bar.h" in a source or header file iff a
> feature that is declared or defined in bar.h is *used* *directly* in that
> source or header file, regardless of whether bar.h is included in foo.h
> that is itself included in that source or header file.
In theory, it's perhaps the best way to do it. But we don't do that for
system header includes. And I think it makes it very difficult to cleanup
header includes, because you have to check what is needed for each feature
in a file. So I think we have to choose between basically no header include
cleanup or a cleanup like the one Nathaniel started.
> If this latter principle is obeyed, then the build won't break by
> removing the include of foo.h (for the reason that nothing of foo.h is
> *use* *directly* anymore).
I think it's more likely that we will add features rather than remove some.
And it's not very difficult if we remove some, to remove "foo.h" and
add "bar.h" at the same time.
For example, many files include "cache.h", does it really make sense to try
to remove these #include because we could replace them by only includes
of "git-compat-util.h" and "hash.h"? I don't think so.
Best regards,
Christian.
^ permalink raw reply
* Re: "git reflog expire --all" very slow
From: Linus Torvalds @ 2009-03-31 5:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, Johannes Schindelin, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0903302244580.4093@localhost.localdomain>
That made no sense. It should have been:
On Mon, 30 Mar 2009, Linus Torvalds wrote:
>
> but we care about the commits that are younger than 'expire_total' (older
> than that, and they are pruned unconditionally), but older than
> 'expire_unreachable' (younger than that and the date doesn't matter).
^^^^
reachability
but other than that the commentary stands.
Linus
^ permalink raw reply
* Re: "git reflog expire --all" very slow
From: Linus Torvalds @ 2009-03-31 5:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, Johannes Schindelin, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0903302231370.4093@localhost.localdomain>
On Mon, 30 Mar 2009, Linus Torvalds wrote:
>
> If I do
>
> mark_reachable(cb.ref_commit, 0);
Ok, I think I got it.
You had
mark_reachable(cb.ref_commit, cmd->expire_unreachable);
but we care about the commits that are younger than 'expire_total' (older
than that, and they are pruned unconditionally), but older than
'expire_unreachable' (younger than that and the date doesn't matter).
So making it do
mark_reachable(cb.ref_commit, cmd->expire_total);
marks the right parts reachable. Not the whole tree, but also not just the
commits we're not going to expire regardless.
With that change, it's all basically instantaneous. We don't need to
traverse the whole kernel history, and with that change to your patch, I
get
[torvalds@nehalem linux]$ time ~/git/git reflog expire --all
real 0m1.715s
user 0m1.676s
sys 0m0.040s
which is still slower than I'd wish for, but is a whole lot faster than
over half a minute.
Linus
^ permalink raw reply
* Re: "git reflog expire --all" very slow
From: Junio C Hamano @ 2009-03-31 5:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brandon Casey, Johannes Schindelin, Git Mailing List
In-Reply-To: <7vy6um6z9m.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>> ...
>> This if anything makes things just go slower.
>>
>> Not much, but some. It went from 36.566s to 38.070s. That may be in the
>> noise, I've not done any sensitivity analysis.
>
> I actually think that the cutoff for history traversal is bogus. You may
> have a 30-day old reflog entry that pulled in a 45-day old commit, and
> giving up the smudging at the expiry cutoff timestamp does not make much
> sense.
>
> I do have a lot of reflog entries kept around, as my main repository has
> these:
>
> [gc]
> reflogexpire = '2005-01-01 00:00:00 +0000'
> reflogexpireunreachable = '2005-01-01 00:00:00 +0000'
>
> so let me experiment a bit more.
To initially prune a copy of my git repository that was never pruned
before, it takes a lot of time with or without the patch to prune from the
original 73476 reflog entries.
(without patch)
23.46user 0.23system 0:23.70elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+5464outputs (0major+6045minor)pagefaults 0swaps
(with patch, but with a bit of fprintf's for counting)
21.99user 0.40system 0:22.56elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+5472outputs (0major+6040minor)pagefaults 0swaps
After the initial pruning, with 13780 reflog entries still left (and no
further pruning expected), I am seeing these:
(without patch)
2.09user 0.22system 0:02.32elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+5464outputs (0major+4956minor)pagefaults 0swaps
(with patch, but again with a bit of fprintf's for counting)
0.76user 0.25system 0:01.05elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+5464outputs (0major+4918minor)pagefaults 0swaps
I might be better off traversing down all the way and do away with
in_merge_bases(), but that might hold true only for something small like
git.git and the kernel.
^ permalink raw reply
* Re: "git reflog expire --all" very slow
From: Linus Torvalds @ 2009-03-31 5:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, Johannes Schindelin, Git Mailing List
In-Reply-To: <7vy6um6z9m.fsf@gitster.siamese.dyndns.org>
On Mon, 30 Mar 2009, Junio C Hamano wrote:
>
> I do have a lot of reflog entries kept around, as my main repository has
> these:
>
> [gc]
> reflogexpire = '2005-01-01 00:00:00 +0000'
> reflogexpireunreachable = '2005-01-01 00:00:00 +0000'
I think that actually _hides_ the problem. You'll never have anything at
all that triggers that
if (timestamp < cb->cmd->expire_unreachable) {
because your "expire_unreachable" timestamp is already very old (== small
value), so 'timestamp' will _not_ be older (smaller value) than that.
I dunno. As mentioned, I don't really understand why we'd want to save
some of those reflog entries at all in the first place, so I'm probably
missing something.
If we've asked for reflog entries past a certain age to be expired, why do
when then look at the details of those reflog entries and only expire them
under certain circumstances? Just expire them, and get rid of the
'unreachable' part.
Linus
^ permalink raw reply
* Re: "git reflog expire --all" very slow
From: Linus Torvalds @ 2009-03-31 5:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, Johannes Schindelin, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0903302154000.4093@localhost.localdomain>
On Mon, 30 Mar 2009, Linus Torvalds wrote:
>
> This if anything makes things just go slower.
>
> Not much, but some. It went from 36.566s to 38.070s. That may be in the
> noise, I've not done any sensitivity analysis.
>
> I thought you perhaps had a missing "parse_commit()" making the
> reachability thing not work (look_up_gently parses the object, but if it's
> a tag deref_tag() will dereference it until it hits a commit, but never
> parse the commit). But that wasn't it.
Ahhah.
I know why it makes things slower.
The slow case is already inside that whole:
if (timestamp < cb->cmd->expire_unreachable) {
if-statement, so the thing that slows down is if we hit a commit that is
_older_ than the expire limit.
But your whole "mark_reachable()" thing only marks things _younger_ than
that reachable. So you mark exactly the wrong things reachable - you mark
the ones that we don't even care about.
If I do
mark_reachable(cb.ref_commit, 0);
instead (to traverse the _whole_ tree, with no regards to date), the time
shrinks to 1.7s. But of course, that's also wrong.
Qutie frankly, I don't really understand why the logic isn't just
if (timestamp < cb->cmd->expire_unreachable)
goto prune;
why is that reachability so important?
Linus
^ permalink raw reply
* Re: [PATCH 3/4] bisect: fix reading more than one path in "$GIT_DIR/BISECT_NAMES"
From: Christian Couder @ 2009-03-31 5:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Tapsell, Johannes Schindelin
In-Reply-To: <7vocvjh25n.fsf@gitster.siamese.dyndns.org>
Le lundi 30 mars 2009, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > The implementation of "read_bisect_paths" worked with only one
> > path in each line of "$GIT_DIR/BISECT_NAMES", but the paths are all
> > stored on one line by "git-bisect.sh".
> >
> > So we have to process all the paths that may be on each line.
>
> This is "oops, the previous one is broken", for a series that was not yet
> 'next' worthy, so I squashed the fix and rebuilt the topic, together with
> your other patches.
No problem.
> The series now looks like this:
[...]
> I've tweaked a few patches before applying, but they all looked basically
> sane. Unless I hear from other people in a few days , I'd say we merge
> it to 'next' and start cooking it.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH] Add warning about known issues to documentation of cvsimport
From: Ferry Huberts (Pelagic) @ 2009-03-31 5:36 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Junio C Hamano, git
In-Reply-To: <20090330221729.GB68118@macbook.lan>
Heiko Voigt wrote:
> On Mon, Mar 23, 2009 at 09:33:55PM +0100, Ferry Huberts (Pelagic) wrote:
>> maybe you can also add remarks about autocrlf and safecrlf?
>> both need to be off
>
> From my experience thats not necessarily true. You can use
> autocrlf=input to repair broken revisions were crlf's have been
> mistakenly committed into the repository. And if I remember correctly
> safecrlf helps if you want to make sure that no information gets lost.
>
> So when importing from a nice correct cvs repository you would expect
> safecrlf to not stop your import. And I suspect there are actually cvs
> users that were very careful with their lineendings who would use it.
>
> cheers Heiko
If you look at this thread:
http://thread.gmane.org/gmane.comp.version-control.git/110152/focus=110358
you'll see why I said it. I did some testing to prove my statement.
Ferry
^ permalink raw reply
* Re: "git reflog expire --all" very slow
From: Junio C Hamano @ 2009-03-31 5:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brandon Casey, Johannes Schindelin, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0903302154000.4093@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, 30 Mar 2009, Junio C Hamano wrote:
>>
>> Most of your reflog entries are expected to be reachable from the tip, so
>> one optimization would be to mark all commits reachable from the tip
>> upfront, and omit the in_merge_bases() computation for the ones that are
>> already marked. Perhaps something like this...
>
> This if anything makes things just go slower.
>
> Not much, but some. It went from 36.566s to 38.070s. That may be in the
> noise, I've not done any sensitivity analysis.
I actually think that the cutoff for history traversal is bogus. You may
have a 30-day old reflog entry that pulled in a 45-day old commit, and
giving up the smudging at the expiry cutoff timestamp does not make much
sense.
I do have a lot of reflog entries kept around, as my main repository has
these:
[gc]
reflogexpire = '2005-01-01 00:00:00 +0000'
reflogexpireunreachable = '2005-01-01 00:00:00 +0000'
so let me experiment a bit more.
builtin-reflog.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/builtin-reflog.c b/builtin-reflog.c
index d95f515..ef02b5a 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -36,6 +36,7 @@ struct expire_reflog_cb {
FILE *newlog;
const char *ref;
struct commit *ref_commit;
+ int commit_marked;
struct cmd_reflog_expire_cb *cmd;
unsigned char last_kept_sha1[20];
};
@@ -52,6 +53,7 @@ struct collect_reflog_cb {
#define INCOMPLETE (1u<<10)
#define STUDYING (1u<<11)
+#define REACHABLE (1u<<12)
static int tree_is_complete(const unsigned char *sha1)
{
@@ -209,6 +211,43 @@ static int keep_entry(struct commit **it, unsigned char *sha1)
return 1;
}
+static void mark_reachable(struct commit *commit, unsigned long expire_limit)
+{
+ /*
+ * We need to compute if commit on either side of an reflog
+ * entry is reachable from the tip of the ref for all entries.
+ * Mark commits that are reachable from the tip down to the
+ * time threashold first; we know a commit marked thusly is
+ * reachable from the tip without running in_merge_bases()
+ * at all.
+ */
+ struct commit_list *pending = NULL;
+
+ commit_list_insert(commit, &pending);
+ while (pending) {
+ struct commit_list *entry = pending;
+ struct commit_list *parent;
+ pending = entry->next;
+ commit = entry->item;
+ free(entry);
+ if (commit->object.flags & REACHABLE)
+ continue;
+ commit->object.flags |= REACHABLE;
+ parent = commit->parents;
+ while (parent) {
+ commit = parent->item;
+ parent = parent->next;
+ if (commit->object.flags & REACHABLE)
+ continue;
+ if (parse_commit(commit))
+ continue;
+ if (commit->date < expire_limit)
+ continue;
+ commit_list_insert(commit, &pending);
+ }
+ }
+}
+
static int expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
const char *email, unsigned long timestamp, int tz,
const char *message, void *cb_data)
@@ -230,12 +269,28 @@ static int expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
if (timestamp < cb->cmd->expire_unreachable) {
if (!cb->ref_commit)
goto prune;
+
if (!old && !is_null_sha1(osha1))
old = lookup_commit_reference_gently(osha1, 1);
if (!new && !is_null_sha1(nsha1))
new = lookup_commit_reference_gently(nsha1, 1);
- if ((old && !in_merge_bases(old, &cb->ref_commit, 1)) ||
- (new && !in_merge_bases(new, &cb->ref_commit, 1)))
+
+ if (!cb->commit_marked) {
+ if (old) {
+ mark_reachable(cb->ref_commit, old->date);
+ cb->commit_marked = 1;
+ } else if (new) {
+ mark_reachable(cb->ref_commit, new->date);
+ cb->commit_marked = 1;
+ }
+ }
+
+ if ((old &&
+ !(old->object.flags & REACHABLE) &&
+ !in_merge_bases(old, &cb->ref_commit, 1)) ||
+ (new &&
+ !(new->object.flags & REACHABLE) &&
+ !in_merge_bases(new, &cb->ref_commit, 1)))
goto prune;
}
@@ -289,6 +344,8 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,
cb.ref = ref;
cb.cmd = cmd;
for_each_reflog_ent(ref, expire_reflog_ent, &cb);
+ if (cb.ref_commit && cb.commit_marked)
+ clear_commit_marks(cb.ref_commit, REACHABLE);
finish:
if (cb.newlog) {
if (fclose(cb.newlog)) {
^ permalink raw reply related
* [PATCHv2] Documentation: git-format-patch.txt rewordings and cleanups
From: Stephen Boyd @ 2009-03-31 5:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J. Bruce Fields
Clarify --no-binary description using some words from the original
commit 37c22a4b (add --no-binary, 2008-05-9). Cleanup --suffix and
--thread descriptions. Add --thread style option to synopsis. Clarify
renaming patches example.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
The --suffix words have been updated per the list discussion.
Documentation/git-format-patch.txt | 33 ++++++++++++++++-----------------
1 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index c2eb5fa..e2b7939 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -9,9 +9,9 @@ git-format-patch - Prepare patches for e-mail submission
SYNOPSIS
--------
[verse]
-'git format-patch' [-k] [-o <dir> | --stdout] [--thread]
+'git format-patch' [-k] [-o <dir> | --stdout] [--thread[=<style>]]
[--attach[=<boundary>] | --inline[=<boundary>] |
- [--no-attach]]
+ --no-attach]
[-s | --signoff] [<common diff options>]
[-n | --numbered | -N | --no-numbered]
[--start-number <n>] [--numbered-files]
@@ -132,9 +132,9 @@ include::diff-options.txt[]
the Message-Id header to reference.
+
The optional <style> argument can be either `shallow` or `deep`.
-'Shallow' threading makes every mail a reply to the head of the
+'shallow' threading makes every mail a reply to the head of the
series, where the head is chosen from the cover letter, the
-`\--in-reply-to`, and the first patch mail, in this order. 'Deep'
+`\--in-reply-to`, and the first patch mail, in this order. 'deep'
threading makes every mail a reply to the previous one. If not
specified, defaults to the 'format.thread' configuration, or `shallow`
if that is not set.
@@ -169,24 +169,23 @@ if that is not set.
--suffix=.<sfx>::
Instead of using `.patch` as the suffix for generated
filenames, use specified suffix. A common alternative is
- `--suffix=.txt`.
+ `--suffix=.txt`. Leaving this empty will remove the `.patch`
+ suffix.
+
-Note that you would need to include the leading dot `.` if you
-want a filename like `0001-description-of-my-change.patch`, and
-the first letter does not have to be a dot. Leaving it empty would
-not add any suffix.
+Note the leading character does not have to be a dot; for example, you
+can use --suffix=-patch to get `0001-description-of-my-change-patch`.
--no-binary::
- Don't output contents of changes in binary files, just take note
- that they differ. Note that this disable the patch to be properly
- applied. By default the contents of changes in those files are
- encoded in the patch.
+ Do not output contents of changes in binary files, instead
+ display a notice that those files changed. Patches generated
+ using this option cannot be applied properly, but they are
+ still useful for code review.
CONFIGURATION
-------------
You can specify extra mail header lines to be added to each message
-in the repository configuration, new defaults for the subject prefix
-and file suffix, control attachements, and number patches when outputting
+in the repository configuration, defaults for the subject prefix
+and file suffix, configure attachments, and number patches when outputting
more than one.
------------
@@ -234,8 +233,8 @@ $ git format-patch -M -B origin
+
Additionally, it detects and handles renames and complete rewrites
intelligently to produce a renaming patch. A renaming patch reduces
-the amount of text output, and generally makes it easier to review it.
-Note that the "patch" program does not understand renaming patches, so
+the amount of text output, and generally makes it easier to review.
+Note that non-git "patch" programs won't understand renaming patches, so
use it only when you know the recipient uses git to apply your patch.
* Extract three topmost commits from the current branch and format them
--
1.6.2
^ permalink raw reply related
* Re: "git reflog expire --all" very slow
From: Linus Torvalds @ 2009-03-31 5:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, Johannes Schindelin, Git Mailing List
In-Reply-To: <7vk5668g55.fsf@gitster.siamese.dyndns.org>
On Mon, 30 Mar 2009, Junio C Hamano wrote:
>
> Most of your reflog entries are expected to be reachable from the tip, so
> one optimization would be to mark all commits reachable from the tip
> upfront, and omit the in_merge_bases() computation for the ones that are
> already marked. Perhaps something like this...
This if anything makes things just go slower.
Not much, but some. It went from 36.566s to 38.070s. That may be in the
noise, I've not done any sensitivity analysis.
I thought you perhaps had a missing "parse_commit()" making the
reachability thing not work (look_up_gently parses the object, but if it's
a tag deref_tag() will dereference it until it hits a commit, but never
parse the commit). But that wasn't it.
Linus
^ permalink raw reply
* Re: [PATCH 2/4] quote: add "sq_dequote_to_argv" to put unwrapped args in an argv array
From: Christian Couder @ 2009-03-31 5:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Tapsell, Johannes Schindelin
In-Reply-To: <7vhc1bjyl7.fsf@gitster.siamese.dyndns.org>
Le lundi 30 mars 2009, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > This new function unwraps the space separated shell quoted elements in
> > its first argument and put a copy of them in the argv array passed as
> > its second argument.
> >
> > Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> > ---
> > quote.c | 17 +++++++++++++++++
> > quote.h | 2 ++
> > 2 files changed, 19 insertions(+), 0 deletions(-)
> >
> > diff --git a/quote.c b/quote.c
> > index 8cf0ef4..5b12a4a 100644
> > --- a/quote.c
> > +++ b/quote.c
> > @@ -120,6 +120,23 @@ char *sq_dequote(char *arg)
> > return sq_dequote_many(arg, NULL);
> > }
> >
> > +int sq_dequote_to_argv(char *arg, const char ***argv, int *nr, int
> > *alloc) +{
> > + char *next = arg;
> > +
> > + if (!*arg)
> > + return 0;
> > + do {
> > + char *dequoted = sq_dequote_many(next, &next);
> > + if (!dequoted)
> > + return 1;
>
> Usually we signal an error with a negative value, e.g. -1.
>
> > + ALLOC_GROW(*argv, *nr + 1, *alloc);
> > + (*argv)[(*nr)++] = xstrdup(dequoted);
>
> The original sq_dequote() interface takes advantage of the fact that the
> result of single-quote unquoting is always shorter than the original and
> it can rewrite the argument in-place to return the result. I would
> expect dequote_step() to retain that trait and allow the caller to use
> its return value without xstrdup().
I thought that it could be dangerous not to use xstrdup, as users of this
function might want to free the strings in argv one by one. But I don't
care much.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 1/4] quote: implement "sq_dequote_many" to unwrap many args in one string
From: Junio C Hamano @ 2009-03-31 5:09 UTC (permalink / raw)
To: Christian Couder; +Cc: git, John Tapsell, Johannes Schindelin
In-Reply-To: <200903310704.52864.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> But you might want to change the function name in the
> patch title too.
Thanks, sure I might ;-)
^ 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