All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: "Santi Béjar" <sbejar@gmail.com>
Cc: "Junio C Hamano" <junkio@cox.net>,
	"Git Mailing List" <git@vger.kernel.org>
Subject: Re: [PATCHv3] git-fetch: Split fetch and merge logic
Date: Sat, 24 Feb 2007 01:30:19 -0800	[thread overview]
Message-ID: <7vd53zzyvo.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: 8aa486160702230242r4059811ewbc4cb5c6d33500df@mail.gmail.com

"Santi Béjar" <sbejar@gmail.com> writes:

> On 2/23/07, Junio C Hamano <junkio@cox.net> wrote:
>
>> I am wondering if FETCH_FETCHED is purely for internal use by
>> git-fetch (it appears so), and if so if it is worth trying to do
>> without the temporary file, but that is a minor detail.
>
> Yes, it's purely internal. With "without the temporary file" you mean
> to put the content in a variable or removing at the end?

If a variable suffices that would be quite nice, but it is not a
big deal.  As the script does fair amount of computation in
subprocess, I suspect it may not be worth trying to use variable,
only to get rid of the temporary file.

>> I appreciate the cleverness of the intersection.  However, is
>> "echo -e" portable?  I think we have avoided it so far (we have
>> avoided even "echo -n" which is traditionally much more
>> available).
>
> printf '%s\n%s' "$merge_branches" "$fetch_branches"
>
> is OK?

Yes.  I think printf is what people who rewrote my "echo -n"
have done elsewhere.

  reply	other threads:[~2007-02-24  9:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-23  8:49 [PATCHv3] git-fetch: Split fetch and merge logic Santi Béjar
2007-02-23  9:53 ` Junio C Hamano
2007-02-23 10:42   ` Santi Béjar
2007-02-24  9:30     ` Junio C Hamano [this message]
2007-02-24 12:32 ` Junio C Hamano
2007-02-25  5:07   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vd53zzyvo.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=sbejar@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.