* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Stephen Boyd @ 2010-01-21 18:51 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20100106073822.6117@nanako3.lavabit.com>
On Tue, Jan 5, 2010 at 2:38 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Junio, could you tell us what happened to this thread?
>
> After a lengthy discussion, nothing happened.
>
Sorry. I lost interest during the holidays and then went on a vacation
after. I've returned and will try and get back to it this weekend.
^ permalink raw reply
* Re: [PATCHv11 12/20] Builtin-ify git-notes
From: Stephen Boyd @ 2010-01-21 18:28 UTC (permalink / raw)
To: Johan Herland; +Cc: gitster, git
In-Reply-To: <1263762277-31419-13-git-send-email-johan@herland.net>
On Sun, Jan 17, 2010 at 1:04 PM, Johan Herland <johan@herland.net> wrote:
> +
> + if (launch_editor(path, buf, NULL)) {
> + fprintf(stderr, "Please supply the note contents using"
> + " either -m or -F option.\n");
> + exit(1);
die()?
^ permalink raw reply
* Re: [PATCH] post-receive-email: allow customizing of subject/intro/footer
From: Marc Branchaud @ 2010-01-21 18:18 UTC (permalink / raw)
To: Mike Frysinger; +Cc: git
In-Reply-To: <201001211259.30704.vapier@gentoo.org>
Mike Frysinger wrote:
> On Thursday 21 January 2010 12:02:58 Marc Branchaud wrote:
>>
>> So, overall, why not make generate_email_header() be simply:
>>
>> generate_email_header()
>> {
>> # --- Email (all stdout will be the email)
>> # Generate header
>> subst_vars <<-EOF
>> To: $recipients
>> Subject: ${emailprefix}${emailsubject}
>> X-Git-Refname: @refname@
>> X-Git-Reftype: @refname_type@
>> X-Git-Oldrev: @oldrev@
>> X-Git-Newrev: @newrev@
>>
>> ${emailbodyintro}
>>
>> EOF
>> }
>>
>> This would also let you simply subst_vars() so that it needn't support
>> piped invocations, no? (Not a very drastic simplification, but still...)
>
> if emailbodyintro is empty, this adds two useless newlines. otherwise, this
> would be fine i think.
Personally, I can live with that limitation. I think it's unlikely that
anyone will want to get rid of the intro entirely, though maybe that's just me.
One alternative is to remove the newline after ${emailbodyintro}, but I think
most users will want the newline after the intro and that it's too easy to
forget to put it there when editing the setting.
Anyway, I don't have a strong opinion on the newline question. The main
change I'd like to see is including that last intro line in emailbodyintro
instead of hardwiring it into the code.
M.
^ permalink raw reply
* Re: git-merge segfault in 1.6.6 and master
From: Junio C Hamano @ 2010-01-21 18:12 UTC (permalink / raw)
To: Tim Olsen; +Cc: git, Miklos Vajna, Johannes Schindelin
In-Reply-To: <4B5882BD.3090908@brooklynpenguin.com>
Tim Olsen <tim@brooklynpenguin.com> writes:
>> In the recursive case (i.e. o->call_depth is non-zero), process_renames()
>> and process_entry() are supposed to be forcing the conflicts resolved,
>> recording the contents with conflict markers if necessary, before the
>> control gets to that point, so it clearly is a bug very specific to the
>> recursive merge implementation.
>
> Setting breakpoints on process_renames() and process_entry() shows that
> they are being executed. Is there anything I can gather from their
> execution that would help you?
When they are called with non-zero o->call_depth, they are supposed to
drop all the index entries that they handle down to stage #0 (even if the
path had contents level conflict). For example, you see this bit in
process_entry():
} else if (a_sha && b_sha) {
/* Case C: Added in both (check for same permissions) and */
/* case D: Modified in both, but differently. */
const char *reason = "content";
...
mfi = merge_file(o, &one, &a, &b,
o->branch1, o->branch2);
clean_merge = mfi.clean;
if (!mfi.clean) {
if (S_ISGITLINK(mfi.mode))
reason = "submodule";
output(o, 1, "CONFLICT (%s): Merge conflict in %s",
reason, path);
}
update_file(o, mfi.clean, mfi.sha, mfi.mode, path);
} ...
and update_file() eventually calls update_file_flags() to make sure that
the content in mfi.sha is at the stage #0 of path when o->call_depth is
non-zero (or mfi.clean is true). process_renames() and process_entry()
are humongous functions that handle full of different cases, but all
codepaths must follow the rule not to leave non-stage #0 entries in the
index before merge_trees() function calls write_tree_from_memory().
We've fixed a similar bug in c94736a (merge-recursive: don't segfault
while handling rename clashes, 2009-07-30) and I think there were similar
breakages we fixed over time in the same area, but the two functions being
as huge as they are, I suspect you are hitting a codepath that hasn't been
fixed.
^ permalink raw reply
* Re: [PATCH] post-receive-email: allow customizing of subject/intro/footer
From: Mike Frysinger @ 2010-01-21 17:59 UTC (permalink / raw)
To: Marc Branchaud; +Cc: git
In-Reply-To: <4B5888C2.60508@xiplink.com>
[-- Attachment #1: Type: Text/Plain, Size: 1497 bytes --]
On Thursday 21 January 2010 12:02:58 Marc Branchaud wrote:
> > + if [ -n "${emailbodyintro}" ] ; then
> > + printf '\n%s\n' "${emailbodyintro}"
> > + fi
>
> Since the script ensures there's always a value set for emailbodyintro, why
> check for it here? None of the other uses of the new config items
> (emailsubject and emailfooter) have this kind of check.
the other values dont have newlines added to them implicitly. if it's empty,
i dont want to useless newlines at the start of the e-mail.
> > - The $refname_type, $short_refname has been ${change_type}d
> > - EOF
> > + printf '\n%s\n' "The @refname_type@, @short_refname@ has been
> > @change_type@d" + ) | subst_vars
>
> Any reason why that last printf'd line shouldn't be made part of the
> emailbodyintro?
that could work
> So, overall, why not make generate_email_header() be simply:
>
> generate_email_header()
> {
> # --- Email (all stdout will be the email)
> # Generate header
> subst_vars <<-EOF
> To: $recipients
> Subject: ${emailprefix}${emailsubject}
> X-Git-Refname: @refname@
> X-Git-Reftype: @refname_type@
> X-Git-Oldrev: @oldrev@
> X-Git-Newrev: @newrev@
>
> ${emailbodyintro}
>
> EOF
> }
>
> This would also let you simply subst_vars() so that it needn't support
> piped invocations, no? (Not a very drastic simplification, but still...)
if emailbodyintro is empty, this adds two useless newlines. otherwise, this
would be fine i think.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] rev-parse --branches/--tags/--remotes=pattern
From: Junio C Hamano @ 2010-01-21 17:58 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Ilari Liusvaara, git
In-Reply-To: <4B584DDD.7060701@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Works for me, thank you very much!
>
> Junio, kindly squash in these speeling fixes in both patches:
>
> sed -i 's/impiled/implied/g' `git diff HEAD^ --name-only Documentation/`
Thanks; I've already pushed out what I was preparing before going to bed,
so these fixes need to happen in-tree as incremental changes.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #06; Wed, 20)
From: Junio C Hamano @ 2010-01-21 17:52 UTC (permalink / raw)
To: Johan Herland; +Cc: Sverre Rabbelier, git
In-Reply-To: <201001211018.10085.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> In any case, I totally understand if you'd rather want to hold the entire
> notes series in 'pu', and instead focus on fixing the bugs in what's already
> been released.
That is a different issue than what to do with the first three that people
have been using from 'next'. As I want to close the -rc0 by the end of
this week, I've merged these early ones to 'master'.
Tentatively I had to drop the remainder of 'jh/notes' from 'pu', but that
is not because I didn't like what was in the series. From the discussion
of last night, a patch to squelch "Notes: " output in "format-patch" was
queued and it is meant for 1.6.6.X series, but the precondition a new test
in that fix relies on in t3301 (i.e. fourth commit having a certain notes)
is changed in jh/notes series and merging it makes the tests break. I
haven't gotten around looking into its details, but the fix patch needs to
be in 'master' soon, and the first patches from 'jh/notes' are already in
'master', so probably we would want to rebase the remainder on top of
updated 'master' when 1.7.0-rc0 is tagged.
^ permalink raw reply
* Re: git fetch -v not at all verbose?
From: Thomas Rast @ 2010-01-21 17:47 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Shawn O. Pearce, git, Junio C Hamano
In-Reply-To: <20100121173010.GB16707@redhat.com>
On Thursday 21 January 2010 18:30:10 Michael S. Tsirkin wrote:
> On Thu, Jan 21, 2010 at 08:57:37AM -0800, Shawn O. Pearce wrote:
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > Hmm, no, but what is true is that I fetched several remotes
> > > that diverged significantly into the same local repository.
> > > Would that have same effect?
[...]
> > Hmm. I wonder if we should try to shortcut the commit walking in
> > a case like this and just feed the tracking branches we already have.
>
> Or for the case of 1,000s of commits ahead, git could try to implement a
> heuristic to reduce the number of commits sent. Currently all commits
> are sent in order, correct? How about binary search like what git
> bisect does?
I had a patch for this ages ago (that combines exponential-stride
backwards search and later bisection), but it was shot down on grounds
of not working at times and code convolution and I forgot about it...
I can give this another shot, but it seems most of the code has moved
due to the transport handlers changes, so I'll first have to read into
it again.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git fetch -v not at all verbose?
From: Junio C Hamano @ 2010-01-21 17:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Michael S. Tsirkin, git
In-Reply-To: <20100121165737.GG19078@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
>> > Are you fetching from a configured remote that has tracking branches,
>> > or are you fetching through a one-shot URL pasted onto the command
>> > line?
>>
>> Configured remote.
>
> Hmm. I wonder if we should try to shortcut the commit walking in
> a case like this and just feed the tracking branches we already have.
You mean that the main culprit is the presense of thousdands of commits
that fetcher has obtained through the other remotes (and his own) that the
uploader makes fetcher walk all the way, in the false hope that there
might be a commit among them that is closer to the commits being fetched
than the ones at the tip of tracking branch the fetcher has for this
uploader currently?
And the solution might be to tell only about the tips of remote tracking
branches fetcher has obtained from this particular uploader, not about
other remote tracking bracnesh it got from others or his own local
branches (which may have merged from other remotes)?
It is a clever idea but I suspect it may not work well in practice. For
example, suppose a project is two-tier, say, with top-level and subsystem
repositories, the former of which regularly merge from the latter, and you
are a participant primarily working on the subsystem. You fetch daily
from the subsystem repository, but weekly from the top-level.
Now, when you fetch from the top-level, the remote tracking refs you have
for it are much more stale than your other refs. The top-level would have
acquired a lot more commits from the same subsystem repository since you
fetched from there the last time, and you already have many of them
through your daily fetch from the subsystem repository. To minimize the
transfer in such a case, the fetcher does want to tell the uploader that
it has those commits from the same subsystem repository, so that the
commit walker can stop at a recent merge into the top-level from the
subsystem repository.
There was a discussion about updating the commit walk exchange to bisect
the history (skip and try a much older one to see if it is reachable, but
to avoid overshooting, step back and see if a newer one is still common).
It would be a lot more work and needs to be implemented as a new protocol
capability, but I think it is the right way to go in the longer term.
^ permalink raw reply
* Re: git fetch -v not at all verbose?
From: Michael S. Tsirkin @ 2010-01-21 17:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <20100121165737.GG19078@spearce.org>
On Thu, Jan 21, 2010 at 08:57:37AM -0800, Shawn O. Pearce wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Thu, Jan 21, 2010 at 08:18:58AM -0800, Shawn O. Pearce wrote:
> > > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > On many of my trees (with linux kernel), git fetch is slower than git clone.
> > > > Even more annoyingly, it would hang sometimes for tens of minutes without any
> > > > output, even if -v is supplied.
> ...
> > > Given the symptom, it sounds to me like your local repository
> > > is some 1,000s of commits ahead of the remote repository you are
> > > fetching from. Is that true?
> >
> > Hmm, no, but what is true is that I fetched several remotes
> > that diverged significantly into the same local repository.
> > Would that have same effect?
>
> Yes.
>
> > > Are you fetching from a configured remote that has tracking branches,
> > > or are you fetching through a one-shot URL pasted onto the command
> > > line?
> >
> > Configured remote.
>
> Hmm. I wonder if we should try to shortcut the commit walking in
> a case like this and just feed the tracking branches we already have.
Or for the case of 1,000s of commits ahead, git could try to implement a
heuristic to reduce the number of commits sent. Currently all commits
are sent in order, correct? How about binary search like what git
bisect does?
> --
> Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] rev-parse --branches/--tags/--remotes=pattern
From: Thomas Rast @ 2010-01-21 17:27 UTC (permalink / raw)
To: Michael J Gruber, Ilari Liusvaara; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <4B585BED.700@drmicha.warpmail.net>
Thanks Ilari for implementing my wishes :-)
On Thursday 21 January 2010 14:51:41 Michael J Gruber wrote:
> Johannes Sixt venit, vidit, dixit 21.01.2010 13:51:
> > Works for me, thank you very much!
> >
> > Junio, kindly squash in these speeling fixes in both patches:
> >
> > sed -i 's/impiled/implied/g' `git diff HEAD^ --name-only Documentation/`
> >
>
> Also, the option descriptions are kind of staccato English right now,
> lacking a few "the" here and there. Should we fix this or simply leave
> it at that?
Maybe the --branches, --tags and --remotes could be consolidated a
bit, as in the draft patch below. If --all took a pattern, it could
be included there too, but that would probably look too weird.
diff --git i/Documentation/git-rev-parse.txt w/Documentation/git-rev-parse.txt
index 2bbb566..6fce919 100644
--- i/Documentation/git-rev-parse.txt
+++ w/Documentation/git-rev-parse.txt
@@ -104,29 +104,26 @@ OPTIONS
Show all refs found in `$GIT_DIR/refs`.
--branches[=pattern]::
- Show branch refs found in `$GIT_DIR/refs/heads`. If `pattern`
- is given, only branches matching given shell glob are shown.
- If pattern lacks '?', '*', or '[', '/*' at the end is impiled.
-
--tags[=pattern]::
- Show tag refs found in `$GIT_DIR/refs/tags`. If `pattern`
- is given, only tags matching given shell glob are shown.
- If pattern lacks '?', '*', or '[', '/*' at the end is impiled.
-
--remotes[=pattern]::
- Show tag refs found in `$GIT_DIR/refs/remotes`. If `pattern`
- is given, only remote tracking branches matching given shell glob
- are shown. If pattern lacks '?', '*', or '[', '/*' at the end is
- impiled.
+ Show all branches, tags, or remote-tracking branches,
+ respectively (i.e., refs found in `$GIT_DIR/refs/heads`,
+ `$GIT_DIR/refs/tags`, or `$GIT_DIR/refs/remotes`,
+ respectively).
++
+If a `pattern` is given, only refs matching the given shell glob are
+shown. If the pattern does not contain a globbing character (`?`,
+`\*`, or `[`), it is anchored by appending `/\*`.
+
+--glob=pattern::
+ Show all refs matching the shell glob pattern `pattern`. If
+ the pattern does not start with `refs/`, this is automatically
+ prepended. If the pattern does not contain a globbing
+ character (`?`, `\*`, or `[`), it is anchored by appending `/\*`.
--show-toplevel::
Show the absolute path of the top-level directory.
---glob=glob-pattern::
- Show refs matching shell glob pattern `glob-pattern`. If pattern
- specified lacks leading 'refs/', it is automatically prepended.
- If pattern lacks '?', '*', or '[', '/*' at the end is impiled.
-
--show-prefix::
When the command is invoked from a subdirectory, show the
path of the current directory relative to the top-level
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply related
* Re: [PATCH] post-receive-email: allow customizing of subject/intro/footer
From: Marc Branchaud @ 2010-01-21 17:02 UTC (permalink / raw)
To: Mike Frysinger; +Cc: git
In-Reply-To: <1263877931-26047-1-git-send-email-vapier@gentoo.org>
Thanks for this! I've been meaning to do something similar myself. :)
A couple of thoughts struck me while looking through your patch...
Mike Frysinger wrote:
> The format of the subject/intro/footer are noise imo, but rather than
> debate the issue, let the user customize the output using the existing
> git config hooks section. The default output is retained for each part.
>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> ---
> contrib/hooks/post-receive-email | 76 +++++++++++++++++++++++++++++---------
> 1 files changed, 58 insertions(+), 18 deletions(-)
>
> diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
> index 58a35c8..79ab6b1 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -38,6 +38,15 @@
> # hooks.emailprefix
> # All emails have their subjects prefixed with this prefix, or "[SCM]"
> # if emailprefix is unset, to aid filtering
> +# hooks.emailsubject
> +# Allow customizing of the subject. Default is a description of what
> +# ref changed and how/why.
> +# hooks.emailbodyintro
> +# Allow customizing of the body intro. Default is friendly paragraph that
> +# explains why the user is receiving this e-mail and what has changed.
> +# hooks.emailfooter
> +# Allow customizing of the footer. Default is name of the script and the
> +# repo description.
> # hooks.showrev
> # The shell command used to format each revision in the email, with
> # "%s" replaced with the commit id. Defaults to "git rev-list -1
> @@ -55,6 +64,10 @@
> # "X-Git-Newrev", and "X-Git-Reftype" to enable fine tuned filtering and
> # give information for debugging.
> #
> +# All variables that start with 'email' have substitution performed on them.
> +# Patterns like @foo@ are replaced with the contents of the variable foo.
> +# See subst_vars() for the specific keywords available for substitution.
> +#
>
> # ---------------------------- Functions
>
> @@ -190,36 +203,47 @@ generate_email()
> generate_email_footer
> }
>
> +subst_vars()
> +{
> + sep=$(printf '\001')
> + # let this be used in a pipeline or by itself
> + ( [ "$#" -ne 0 ] && echo "$@" || cat ) | sed \
> + -e "s${sep}@change_type@${sep}${change_type}${sep}g" \
> + -e "s${sep}@describe@${sep}${describe}${sep}g" \
> + -e "s${sep}@newrev@${sep}${newrev}${sep}g" \
> + -e "s${sep}@oldrev@${sep}${oldrev}${sep}g" \
> + -e "s${sep}@projectdesc@${sep}${projectdesc}${sep}g" \
> + -e "s${sep}@refname@${sep}${refname}${sep}g" \
> + -e "s${sep}@refname_type@${sep}${refname_type}${sep}g" \
> + -e "s${sep}@oldrev@${sep}${oldrev}${sep}g" \
> + -e "s${sep}@short_refname@${sep}${short_refname}${sep}g"
> +}
> +
> generate_email_header()
> {
> # --- Email (all stdout will be the email)
> # Generate header
> + (
> cat <<-EOF
> To: $recipients
> - Subject: ${emailprefix}$projectdesc $refname_type, $short_refname, ${change_type}d. $describe
> - X-Git-Refname: $refname
> - X-Git-Reftype: $refname_type
> - X-Git-Oldrev: $oldrev
> - X-Git-Newrev: $newrev
> + Subject: ${emailprefix}${emailsubject}
> + X-Git-Refname: @refname@
> + X-Git-Reftype: @refname_type@
> + X-Git-Oldrev: @oldrev@
> + X-Git-Newrev: @newrev@
> + EOF
>
> - This is an automated email from the git hooks/post-receive script. It was
> - generated because a ref change was pushed to the repository containing
> - the project "$projectdesc".
> + if [ -n "${emailbodyintro}" ] ; then
Since the script ensures there's always a value set for emailbodyintro, why
check for it here? None of the other uses of the new config items
(emailsubject and emailfooter) have this kind of check.
> + printf '\n%s\n' "${emailbodyintro}"
> + fi
>
> - The $refname_type, $short_refname has been ${change_type}d
> - EOF
> + printf '\n%s\n' "The @refname_type@, @short_refname@ has been @change_type@d"
> + ) | subst_vars
Any reason why that last printf'd line shouldn't be made part of the
emailbodyintro?
So, overall, why not make generate_email_header() be simply:
generate_email_header()
{
# --- Email (all stdout will be the email)
# Generate header
subst_vars <<-EOF
To: $recipients
Subject: ${emailprefix}${emailsubject}
X-Git-Refname: @refname@
X-Git-Reftype: @refname_type@
X-Git-Oldrev: @oldrev@
X-Git-Newrev: @newrev@
${emailbodyintro}
EOF
}
This would also let you simply subst_vars() so that it needn't support piped
invocations, no? (Not a very drastic simplification, but still...)
M.
> }
>
> generate_email_footer()
> {
> - SPACE=" "
> - cat <<-EOF
> -
> -
> - hooks/post-receive
> - --${SPACE}
> - $projectdesc
> - EOF
> + subst_vars "${emailfooter}"
> }
>
> # --------------- Branches
> @@ -671,6 +695,22 @@ recipients=$(git config hooks.mailinglist)
> announcerecipients=$(git config hooks.announcelist)
> envelopesender=$(git config hooks.envelopesender)
> emailprefix=$(git config hooks.emailprefix || echo '[SCM] ')
> +emailsubject=$(git config hooks.emailsubject || \
> + echo '@projectdesc@ @refname_type@, @short_refname@, @change_type@d. @describe@')
> +emailbodyintro=$(git config hooks.emailbodyintro || cat <<-EOF
> + This is an automated email from the git hooks/post-receive script. It was
> + generated because a ref change was pushed to the repository containing
> + the project "@projectdesc@".
> + EOF
> +)
> +emailfooter=$(git config hooks.emailfooter || SPACE=" " cat <<-EOF
> +
> +
> + hooks/post-receive
> + --${SPACE}
> + @projectdesc@
> + EOF
> +)
> custom_showrev=$(git config hooks.showrev)
>
> # --- Main loop
^ permalink raw reply
* Re: git fetch -v not at all verbose?
From: Shawn O. Pearce @ 2010-01-21 16:57 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git, Junio C Hamano
In-Reply-To: <20100121163518.GA16466@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Jan 21, 2010 at 08:18:58AM -0800, Shawn O. Pearce wrote:
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > On many of my trees (with linux kernel), git fetch is slower than git clone.
> > > Even more annoyingly, it would hang sometimes for tens of minutes without any
> > > output, even if -v is supplied.
...
> > Given the symptom, it sounds to me like your local repository
> > is some 1,000s of commits ahead of the remote repository you are
> > fetching from. Is that true?
>
> Hmm, no, but what is true is that I fetched several remotes
> that diverged significantly into the same local repository.
> Would that have same effect?
Yes.
> > Are you fetching from a configured remote that has tracking branches,
> > or are you fetching through a one-shot URL pasted onto the command
> > line?
>
> Configured remote.
Hmm. I wonder if we should try to shortcut the commit walking in
a case like this and just feed the tracking branches we already have.
--
Shawn.
^ permalink raw reply
* Re: git fetch -v not at all verbose?
From: Michael S. Tsirkin @ 2010-01-21 16:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <20100121161858.GC19078@spearce.org>
On Thu, Jan 21, 2010 at 08:18:58AM -0800, Shawn O. Pearce wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On many of my trees (with linux kernel), git fetch is slower than git clone.
> > Even more annoyingly, it would hang sometimes for tens of minutes without any
> > output, even if -v is supplied.
>
> Ouch. I think -v -v boosts the output to be ever more verbose,
> and might actually show you something.
>
> > stracing it shows a ton of lines like the following:
> > 16324 read(10, "ACK 4bbdfe65d23014f539fec4227260"..., 51) = 51
> > 16324 read(10, "0037", 4) = 4
> > 16324 read(10, "ACK 322c06560fa314b04a6302ea03c0"..., 51) = 51
> > 16324 read(10, "0037", 4) = 4
> > 16324 read(10, "ACK 848ea2043b128b5947851866a114"..., 51) = 51
> > 16324 read(10, "0037", 4) = 4
>
> That's the peers trying to determine a common base.
>
> > Is there some way to make got fetch show progress at this stage,
> > or even better, can it be made faster somehow?
>
> We shouldn't need to show progress here, we should just be faster.
>
> Given the symptom, it sounds to me like your local repository
> is some 1,000s of commits ahead of the remote repository you are
> fetching from. Is that true?
Hmm, no, but what is true is that I fetched several remotes
that diverged significantly into the same local repository.
Would that have same effect?
> Are you fetching from a configured remote that has tracking branches,
> or are you fetching through a one-shot URL pasted onto the command
> line?
Configured remote.
> --
> Shawn.
^ permalink raw reply
* Re: git-merge segfault in 1.6.6 and master
From: Tim Olsen @ 2010-01-21 16:37 UTC (permalink / raw)
To: git; +Cc: git, Miklos Vajna, Johannes Schindelin
In-Reply-To: <7vtyugzabq.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Tim Olsen <tim@brooklynpenguin.com> writes:
>> Breakpoint 8, write_tree_from_memory (o=0x7fffffffd560) at
>> merge-recursive.c:210
>> (gdb) list
>> 205 struct cache_entry *ce = active_cache[i];
>> 206 if (ce_stage(ce))
>> 207 output(o, 0, "%d %.*s", ce_stage(ce),
>> 208 (int)ce_namelen(ce), ce->name);
>> 209 }
>> 210 return NULL;
>> 211 }
>> 212
>> 213 if (!active_cache_tree)
>> 214 active_cache_tree = cache_tree();
>> (gdb)
>
> Are you saying write_tree_from_memory() is returning NULL? That probably
> means that in the recursive (i.e. the step that first merges multiple
> common ancestors into one) case the merge is getting conflicts. Do you
> see these "There are unmerged index entries" output?
write_tree_from_memory() is returning NULL. Stepping through the
execution in gdb shows it returning NULL at line 210.
I do not see any output, however:
$ git merge origin/deployed
Segmentation fault
$
> In the recursive case (i.e. o->call_depth is non-zero), process_renames()
> and process_entry() are supposed to be forcing the conflicts resolved,
> recording the contents with conflict markers if necessary, before the
> control gets to that point, so it clearly is a bug very specific to the
> recursive merge implementation.
Setting breakpoints on process_renames() and process_entry() shows that
they are being executed. Is there anything I can gather from their
execution that would help you?
Tim
^ permalink raw reply
* Re: [PATCH] http/remote-curl: coddle picky servers
From: Mike Hommey @ 2010-01-21 16:34 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: John 'Warthog9' Hawley, Shawn O. Pearce, git,
Junio C Hamano, Yaroslav Halchenko, Ilari Liusvaara
In-Reply-To: <be6fef0d1001210820u638f5262jaa062a20fdfbc18b@mail.gmail.com>
On Fri, Jan 22, 2010 at 12:20:26AM +0800, Tay Ray Chuan wrote:
> Hi,
>
> On Fri, Jan 22, 2010 at 12:07 AM, Mike Hommey <mh@glandium.org> wrote:
> > Look closely at the start of the requested URL: /gitweb.cgi...
> > It comes from this rule:
> >
> > RewriteCond %{QUERY_STRING} ^(.+)$
> > RewriteRule ^/(.*)$ /gitweb.cgi$1 [L,PT]
> >
> > which is global to the virtual host.
> >
> > Anyways, while git.debian.org can certainly be fixed for that, other
> > servers may want to do some different things with urls with parameters.
>
> heh, I was suspecting some URL rewriting was going on.
>
> Is this an issue that should be fixed in gitweb?
Nah, that's just an issue with the config at git.debian.org.
It's fixed already.
Mike
^ permalink raw reply
* Re: [PATCH] http/remote-curl: coddle picky servers
From: Mike Hommey @ 2010-01-21 16:34 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Tay Ray Chuan, John 'Warthog9' Hawley, git,
Junio C Hamano, Yaroslav Halchenko, Ilari Liusvaara
In-Reply-To: <20100121162402.GD19078@spearce.org>
On Thu, Jan 21, 2010 at 08:24:02AM -0800, Shawn O. Pearce wrote:
> Tay Ray Chuan <rctay89@gmail.com> wrote:
> > On Fri, Jan 22, 2010 at 12:07 AM, Mike Hommey <mh@glandium.org> wrote:
> > > Look closely at the start of the requested URL: /gitweb.cgi...
> > > It comes from this rule:
> > >
> > > RewriteCond %{QUERY_STRING} ^(.+)$
> > > RewriteRule ^/(.*)$ /gitweb.cgi$1 [L,PT]
> > >
> > > which is global to the virtual host.
> > >
> > > Anyways, while git.debian.org can certainly be fixed for that, other
> > > servers may want to do some different things with urls with parameters.
> >
> > heh, I was suspecting some URL rewriting was going on.
> >
> > Is this an issue that should be fixed in gitweb?
>
> I don't see why it should be. gitweb isn't a service CGI. I find
> it odd that someone would configure their website to route anything
> with a query string into gitweb. WTF?
There was a good reason for it, but the implementation was too broad:
The main gitweb list (http://git.debian.org/) is made statically,
because it is too long for gitweb to create it in a timely fashion.
So while the main page is made to be a static file, when the request has
a query string, which means it's not the main gitweb list, the cgi is
used.
Except this rule was also used for unrelated urls.
But as I said in my reply to Tay Ray Chuan, it's fixed.
Mike
^ permalink raw reply
* cherry picking several patches at once
From: Felipe Balbi @ 2010-01-21 16:11 UTC (permalink / raw)
To: git
Hi,
I wonder if it's possible to cherry several patches at once ?
Can't find anything on any docs, but something like:
$ git cherry-pick <commit_id_start>..<commit_id_end> -- \
/path/to/directory
I want to do that because I keep patches to the musb driver (on linux
kernel) based on top of linus' mainline tree and on top of internal
tree.
The internal tree is outdated (not following mainline), but the musb
driver is basically in sync, so cherry picking works, but it's a bit
painful when I have to pick patches from community and manually
cherry-pick to the other branch based on my internal tree.
If there's a way (besides git rebase --onto) to do that I would very
much like to know.
Another thing that would be nice to have, is to pass the HEAD to which
we want to cherry-pick, so we can cherry-pick to not-checked-out
branches. Something like:
$ git cherry-pick <commit_id> <my_branch_name>
and combining both, of course:
$ git cherry-pick <commit_id_start>..<commit_id_end> \
<my_branch_name> -- /path/to/directory
--
balbi
^ permalink raw reply
* Re: [PATCH] http/remote-curl: coddle picky servers
From: Shawn O. Pearce @ 2010-01-21 16:24 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: Mike Hommey, John 'Warthog9' Hawley, git, Junio C Hamano,
Yaroslav Halchenko, Ilari Liusvaara
In-Reply-To: <be6fef0d1001210820u638f5262jaa062a20fdfbc18b@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Fri, Jan 22, 2010 at 12:07 AM, Mike Hommey <mh@glandium.org> wrote:
> > Look closely at the start of the requested URL: /gitweb.cgi...
> > It comes from this rule:
> >
> > RewriteCond %{QUERY_STRING} ^(.+)$
> > RewriteRule ^/(.*)$ /gitweb.cgi$1 [L,PT]
> >
> > which is global to the virtual host.
> >
> > Anyways, while git.debian.org can certainly be fixed for that, other
> > servers may want to do some different things with urls with parameters.
>
> heh, I was suspecting some URL rewriting was going on.
>
> Is this an issue that should be fixed in gitweb?
I don't see why it should be. gitweb isn't a service CGI. I find
it odd that someone would configure their website to route anything
with a query string into gitweb. WTF?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] http/remote-curl: coddle picky servers
From: Tay Ray Chuan @ 2010-01-21 16:20 UTC (permalink / raw)
To: Mike Hommey
Cc: John 'Warthog9' Hawley, Shawn O. Pearce, git,
Junio C Hamano, Yaroslav Halchenko, Ilari Liusvaara
In-Reply-To: <20100121160707.GA31276@glandium.org>
Hi,
On Fri, Jan 22, 2010 at 12:07 AM, Mike Hommey <mh@glandium.org> wrote:
> Look closely at the start of the requested URL: /gitweb.cgi...
> It comes from this rule:
>
> RewriteCond %{QUERY_STRING} ^(.+)$
> RewriteRule ^/(.*)$ /gitweb.cgi$1 [L,PT]
>
> which is global to the virtual host.
>
> Anyways, while git.debian.org can certainly be fixed for that, other
> servers may want to do some different things with urls with parameters.
heh, I was suspecting some URL rewriting was going on.
Is this an issue that should be fixed in gitweb?
(added John 'Warthog9' Hawley to the Cc list, perhaps he might know.)
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: git fetch -v not at all verbose?
From: Shawn O. Pearce @ 2010-01-21 16:18 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git, Junio C Hamano
In-Reply-To: <20100121161016.GA16300@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On many of my trees (with linux kernel), git fetch is slower than git clone.
> Even more annoyingly, it would hang sometimes for tens of minutes without any
> output, even if -v is supplied.
Ouch. I think -v -v boosts the output to be ever more verbose,
and might actually show you something.
> stracing it shows a ton of lines like the following:
> 16324 read(10, "ACK 4bbdfe65d23014f539fec4227260"..., 51) = 51
> 16324 read(10, "0037", 4) = 4
> 16324 read(10, "ACK 322c06560fa314b04a6302ea03c0"..., 51) = 51
> 16324 read(10, "0037", 4) = 4
> 16324 read(10, "ACK 848ea2043b128b5947851866a114"..., 51) = 51
> 16324 read(10, "0037", 4) = 4
That's the peers trying to determine a common base.
> Is there some way to make got fetch show progress at this stage,
> or even better, can it be made faster somehow?
We shouldn't need to show progress here, we should just be faster.
Given the symptom, it sounds to me like your local repository
is some 1,000s of commits ahead of the remote repository you are
fetching from. Is that true?
Are you fetching from a configured remote that has tracking branches,
or are you fetching through a one-shot URL pasted onto the command
line?
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2] Test t5560: Fix test when run with dash
From: Michael Haggerty @ 2010-01-21 16:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Tarmigan Casebolt, git, Shawn O. Pearce
In-Reply-To: <7v4ommoo4p.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
>>> Yesterday, I saw rebase--interactive has a few codepaths where "output"
>>> shell function was used with the single-shot export; perhaps they need to
>>> also be fixed.
>> I knew these spots, and they were discussed when that code was introduced.
>> Before I sent out the mail you were responding to, I tried various ways to
>> show the failure in rebase--interactive, but it didn't fail...
>
> It may be the case that the single-shot-ness of these GIT_AUTHOR_NAME
> exports do not matter at all in that program, even though the original
> versions may have been written carefully not to leak the value suitable
> for the current commit to later rounds.
>
> I think the recent updates from Michael actually depends on the
> distinction not to matter. For example, do_with_author() in 7756ecf
> (rebase -i: Extract function do_with_author, 2010-01-14) invokes "$@"
> that could be a shell function.
I have to say that I am a little bit over my head here. I didn't try to
follow the complete data path of the GIT_AUTHOR_* shell variables, nor
do I know exactly what git commands they affect. I just tried to
locally refactor the code based on my mistaken assumption that shell
functions are treated much like external commands WRT export of shell
variables.
The use of the GIT_AUTHOR_* variables in git-rebase--interactive.sh were
and are a bit peculiar anyway, since the variables are already set
before do_with_author() is invoked, and the values are left to hang
around afterwards. The do_with_author() function only tries to export
these already-set variables.
So I suppose that the simplest solution is to export these variables
explicitly in do_with_author(), something like this (similar to the
third code block that was replaced by the do_with_author() function):
do_with_author() {
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
"$@"
}
But to ensure that this is a correct solution would require verification
that these now-exported variables don't cause unwanted side-effects
during any other external command invocations. Alternatively, I suppose
that the variables could be exported within a subshell that also invokes
the "$@" command; this subshell could even source the $AUTHOR_SCRIPT
file if it were thought advantageous not to set the GIT_AUTHOR_*
variables in the git-rebase--interactive.sh script at all.
Help would be most appreciated; I probably won't have time to work on
this myself for a week or two.
Michael
^ permalink raw reply
* git fetch -v not at all verbose?
From: Michael S. Tsirkin @ 2010-01-21 16:10 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <20100121160707.GA31276@glandium.org>
Hi!
On many of my trees (with linux kernel), git fetch is slower than git clone.
Even more annoyingly, it would hang sometimes for tens of minutes without any
output, even if -v is supplied.
stracing it shows a ton of lines like the following:
16324 read(10, "ACK 4bbdfe65d23014f539fec4227260"..., 51) = 51
16324 read(10, "0037", 4) = 4
16324 read(10, "ACK 322c06560fa314b04a6302ea03c0"..., 51) = 51
16324 read(10, "0037", 4) = 4
16324 read(10, "ACK 848ea2043b128b5947851866a114"..., 51) = 51
16324 read(10, "0037", 4) = 4
Is there some way to make got fetch show progress at this stage,
or even better, can it be made faster somehow?
Thanks!
--
MST
^ permalink raw reply
* Re: [PATCH] http/remote-curl: coddle picky servers
From: Mike Hommey @ 2010-01-21 16:07 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Tay Ray Chuan, git, Junio C Hamano, Yaroslav Halchenko,
Ilari Liusvaara
In-Reply-To: <20100121155637.GA19078@spearce.org>
On Thu, Jan 21, 2010 at 07:56:37AM -0800, Shawn O. Pearce wrote:
> Tay Ray Chuan <rctay89@gmail.com> wrote:
> > When "info/refs" is a static file and not behind a CGI handler, some
> > servers may not handle a GET request for it with a query string
> > appended (eg. "?foo=bar") properly.
> >
> > If such a request fails, retry it sans the query string. In addition,
> > ensure that the "smart" http protocol is not used (a service has to be
> > specified with "?service=<service name>" to be conformant).
> >
> > Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
> > Reported-and-tested-by: Yaroslav Halchenko <debian@onerussian.com>
>
> *grumble* stupid Apache *grumble*
stupid Apache... configuration.
Check the error message you get on
http://git.debian.org/git/pkg-exppsy/pymvpa.git/info/refs?service=git-upload-pack:
The requested URL /gitweb.cgigit/pkg-exppsy/pymvpa.git/info/refs was not
found on this server.
Look closely at the start of the requested URL: /gitweb.cgi...
It comes from this rule:
RewriteCond %{QUERY_STRING} ^(.+)$
RewriteRule ^/(.*)$ /gitweb.cgi$1 [L,PT]
which is global to the virtual host.
Anyways, while git.debian.org can certainly be fixed for that, other
servers may want to do some different things with urls with parameters.
Mike
^ permalink raw reply
* Re: Error when cloning gc'ed repository
From: Andre Loker @ 2010-01-21 16:02 UTC (permalink / raw)
To: git
In-Reply-To: <hj6ms0$vcg$1@ger.gmane.org>
Andre Loker wrote:
> Hi,
>
> $ git clone git@theserver:the/repository.git
> Initialized empty Git repository in /e/Temp/dr/.git/
> remote: Counting objects: 1396, done.
> remote: Compressing objects: 100% (654/654), done.
> fatal: The remote end hung up unexpectedly
> fatal: early EOFs: 47% (657/1396)
> fatal: index-pack failed
To answer the question myself: it seems that it is a problem with
openssh under cygwin 1.7.1. I found a similar problem here:
http://www.mail-archive.com/cygwin@cygwin.com/msg103749.html
The proposed workaround is to use plink instead of openssh. I tried it
and so far it seems to work. It's not as nice as openssh, but at least
it's a workaround until the issue is solved.
Kind Regards,
Andre
^ 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