* Re: Git BOF notes
From: Catalin Marinas @ 2006-07-24 9:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060719230155.GJ13776@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> a short summary of the Git BOF on OLS which finished just a short
> while ago. We got to hear how Len Brown is doing things and where Git
> gets in the way for him as well as interesting questions and comments
> from several other people. The main highlights as I feel them (mixed
> randomly with my personal blabbering) are that:
What I forgot to mention at the OLS - it would be useful for a more
wide-spread adoption of GIT to convince some of the source code
hosting sites (like sourceforge.net) to provide GIT support. For StGIT
I currently use an HTTP server but that's not the most efficient way.
--
Catalin
^ permalink raw reply
* Re: [PATCH] support cover letter before commit log, using "+++"
From: Jakub Narebski @ 2006-07-24 9:53 UTC (permalink / raw)
To: git
In-Reply-To: <20060724070438.GD20068@admingilde.org>
Martin Waitz wrote:
> I haven't seen the "+++" before here. People have used their own
> "cut here" markers somethimes but I don't think their is an
> established convention already.
Most common I think is the variation of "scissors" separator, i.e.
-- >8 --
> The "+++" just felt good in combination with the "---" end marker.
True.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Can't clone Linus tree
From: Rene Scharfe @ 2006-07-24 9:55 UTC (permalink / raw)
To: Tomasz Torcz; +Cc: linux-kernel, git, Junio C Hamano, Linus Torvalds
In-Reply-To: <20060724080752.GA8716@irc.pl>
Tomasz Torcz schrieb:
> Hi,
>
> yesterdat I wanted to bisect my kernel problem, but failed at first step:
> cloning Linus' tree. Today I tried it on other system and also failed.
>
> This is git-1.4.0 on Slackware, i586:
>
> % git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-git
> fatal: packfile '/home/zdzichu/linux-git/.git/objects/pack/tmp-1jI4AH' SHA1 mismatch
> error: git-fetch-pack: unable to read from git-index-pack
> error: git-index-pack died with error code 128
> fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed.
>
> And this is 1.4.0-1.fc5 on FC5, x86_64:
> % git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-git
> fatal: packfile '/home/tomek/linux-git/.git/objects/pack/tmp-BxIcIC' SHA1 mismatch
> error: git-fetch-pack: unable to read from git-index-pack
> error: git-index-pack died with error code 128
> fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed.
>
> Errors occur constantly since yesterday. They of course appear after
> downloading several megabytes of data, which is unpleasant on my 128kbps
> connection.
Same here with both the master and next branch of git. rsync as
suggested by Johannes Weiner works. You can change the protocol
back to git in .git/remotes/origin after cloning; pulling small
changes seems to work fine.
strace tells me that safe_read at pkt-line.c:111 gets only 305 of
the expected 996 bytes and then dies. I have no idea how that
might happen. :-/
Pulling the git repository works using the git protocol, btw.
René
^ permalink raw reply
* Re: Random Git Issues/Wishlist
From: Catalin Marinas @ 2006-07-24 10:19 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Petr Baudis, git
In-Reply-To: <20060723042725.GA12306@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Petr Baudis <pasky@suse.cz> wrote:
>> (viii) Patches versioning in StGit - many people I've told about StGit
>> complained that it doesn't version patches (and possibly moved to mq?).
>> We should have some scheme for doing meta-history (especially
>> interesting when/if we aim to make altering history easy).
>
> Doesn't StGit now have a single ref for every patch commit?
Yes, it does and the history is lost.
> What about turning on reflog support on those refs and reading the
> reflog for the ``history'' of that patch? Granted the reflog isn't
> prune proof but it is a history of that ref's values over time.
That's a good idea indeed (I haven't noticed this feature). Anyway, I
don't see any problem with not being prune-safe. I wouldn't want to
preserve the refresh history of a patch forever. If I have a stable
series I want to keep, I either clone it or simply tag it.
I think that people willing to keep the patch history for a number of
years (and be prune-safe) should use topic branches rather than
StGIT. Patches are meant to be more lightweight than topic branches
and might have a shorter life-time. There were some people at the OLS
BOF session even mentioning that they don't care about long-term
history.
The StGIT feature wish-list after the OLS is:
- patch history (I'll probably use reflogs as you suggested)
- configurable pull command (currently uses git-pull only)
- commit directly to a patch which is not top
- patch synchronisation between between branches (as some people,
including me have the same patches based on different branches and
they have scripts for moving the changes in one to the others)
- document the workflow on the StGIT wiki
- maybe a separate undo command rather than passing a --undo option to
push and refresh
--
Catalin
^ permalink raw reply
* Re: Can't clone Linus tree
From: Rene Scharfe @ 2006-07-24 10:36 UTC (permalink / raw)
To: Tomasz Torcz; +Cc: linux-kernel, git, Junio C Hamano, Linus Torvalds
In-Reply-To: <44C4992E.3070706@lsrfire.ath.cx>
> Tomasz Torcz schrieb:
>> % git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-git
>> fatal: packfile '/home/zdzichu/linux-git/.git/objects/pack/tmp-1jI4AH' SHA1 mismatch
>> error: git-fetch-pack: unable to read from git-index-pack
>> error: git-index-pack died with error code 128
>> fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed.
Ah, I just saw this is a known problem and there's a patch by
Matthias Lederhofer, which Junio just accepted, I think (the
mail with subject "[PATCH] upload-pack: fix timeout in
create_pack_file)" on the git mailing list.
The problem is apparently that the server expects you (wrongly)
to finish your download session within ten minutes. Until the
server is fixed you can use rsync:// for the initial clone and
git:// for smaller updates.
René
^ permalink raw reply
* Re: Git BOF notes
From: Petr Baudis @ 2006-07-24 11:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnxmzaz5q3v.fsf@arm.com>
Dear diary, on Mon, Jul 24, 2006 at 11:06:28AM CEST, I got a letter
where Catalin Marinas <catalin.marinas@arm.com> said that...
> Petr Baudis <pasky@suse.cz> wrote:
> > a short summary of the Git BOF on OLS which finished just a short
> > while ago. We got to hear how Len Brown is doing things and where Git
> > gets in the way for him as well as interesting questions and comments
> > from several other people. The main highlights as I feel them (mixed
> > randomly with my personal blabbering) are that:
>
> What I forgot to mention at the OLS - it would be useful for a more
> wide-spread adoption of GIT to convince some of the source code
> hosting sites (like sourceforge.net) to provide GIT support. For StGIT
> I currently use an HTTP server but that's not the most efficient way.
Actually, with recent (well, at least half a year ago the situation was
like that) quality of Sf.net's CVS hosting that might in fact give Git
some share of negative reputation if they provided a service of similar
quality. I think some people from Savannah were actually interested in
Git hosting, though.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Git BOF notes
From: Nguyễn Thái Ngọc Duy @ 2006-07-24 12:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: Catalin Marinas, git
In-Reply-To: <20060724114753.GT13776@pasky.or.cz>
On 7/24/06, Petr Baudis <pasky@suse.cz> wrote:
> Actually, with recent (well, at least half a year ago the situation was
> like that) quality of Sf.net's CVS hosting that might in fact give Git
> some share of negative reputation if they provided a service of similar
> quality. I think some people from Savannah were actually interested in
> Git hosting, though.
I don't think so. Quotes from [1]:
What about support for git / cogito?
No. Savannah can not support every versioning system. That's merely ludicrous.
[1] http://savannah.gnu.org/forum/forum.php?printer=1&forum_id=3944
^ permalink raw reply
* [PATCH] Allow an alias to start with "-p"
From: Johannes Schindelin @ 2006-07-24 12:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xmjh5sv.fsf@assigned-by-dhcp.cox.net>
Now, something like
[alias]
pd = -p diff
works as expected.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Sun, 23 Jul 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Now, something like
> >
> > [alias]
> > pd = -p diff
> >
> > works as expected.
>
> I like what it wants to do but I am afraid this leads to an
> unmaintainable code (a micronit that already shows what I mean
> is that you can say "git --paginate diff", but you cannot say
> "pd = --paginate diff" in the configuration file).
>
> Is there a cleaner way to do it without duplicating the argument
> loop of git.c::main()?
This patch uses a better approach: instead of duplicating the option
parsing of the git wrapper, it refactors the code into the new function
handle_options().
In related news, this function would be the perfect candidate to set
GIT_DIR without environment variables...
git.c | 37 +++++++++++++++++++++++++++++++------
1 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/git.c b/git.c
index ee5a0e8..8d7c644 100644
--- a/git.c
+++ b/git.c
@@ -35,6 +35,27 @@ static void prepend_to_path(const char *
setenv("PATH", path, 1);
}
+static int handle_options(const char*** argv, int* argc)
+{
+ int handled = 0;
+
+ while (*argc > 0) {
+ const char *cmd = (*argv)[0];
+ if (cmd[0] != '-')
+ break;
+
+ if (!strcmp(cmd, "-p") || !strcmp(cmd, "--paginate")) {
+ setup_pager();
+ } else
+ die ("Unknown option: %s", cmd);
+
+ (*argv)++;
+ (*argc)--;
+ handled++;
+ }
+ return handled;
+}
+
static const char *alias_command;
static char *alias_string = NULL;
@@ -106,7 +127,7 @@ static int handle_alias(int *argcp, cons
subdir = setup_git_directory_gently(&nongit);
if (!nongit) {
- int count;
+ int count, option_count;
const char** new_argv;
alias_command = (*argv)[0];
@@ -114,6 +135,10 @@ static int handle_alias(int *argcp, cons
if (alias_string) {
count = split_cmdline(alias_string, &new_argv);
+ option_count = handle_options(&new_argv, &count);
+ memmove(new_argv - option_count, new_argv,
+ count * sizeof(char *));
+ new_argv -= option_count;
if (count < 1)
die("empty alias for %s", alias_command);
@@ -264,6 +289,7 @@ int main(int argc, const char **argv, ch
if (!strncmp(cmd, "git-", 4)) {
cmd += 4;
argv[0] = cmd;
+ handle_alias(&argc, &argv);
handle_internal_command(argc, argv, envp);
die("cannot handle %s internally", cmd);
}
@@ -273,13 +299,12 @@ int main(int argc, const char **argv, ch
/* Look for flags.. */
while (argc > 1) {
- cmd = *++argv;
+ argv++;
argc--;
- if (!strcmp(cmd, "-p") || !strcmp(cmd, "--paginate")) {
- setup_pager();
- continue;
- }
+ handle_options(&argv, &argc);
+
+ cmd = *argv;
if (strncmp(cmd, "--", 2))
break;
^ permalink raw reply related
* [PATCH] Always reset the color _before_ printing out the newline
From: Johannes Schindelin @ 2006-07-24 12:41 UTC (permalink / raw)
To: git, junkio
This patch brings the benefits of part of v1.4.1-rc2~37
to the "commit" colorizing patch.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
log-tree.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 608f3ec..b67b8dd 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -144,9 +144,9 @@ void show_log(struct rev_info *opt, cons
printf(" (from %s)",
diff_unique_abbrev(parent->object.sha1,
abbrev_commit));
- putchar(opt->commit_format == CMIT_FMT_ONELINE ? ' ' : '\n');
printf("%s",
diff_get_color(opt->diffopt.color_diff, DIFF_RESET));
+ putchar(opt->commit_format == CMIT_FMT_ONELINE ? ' ' : '\n');
}
/*
--
1.4.2.rc1.g41e1-dirty
^ permalink raw reply related
* Re: [RFC/PATCH] Per branch properties for pull
From: Santi @ 2006-07-24 12:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzaze9xj.fsf@assigned-by-dhcp.cox.net>
2006/7/24, Junio C Hamano <junkio@cox.net>:
> Santi Béjar <sbejar@gmail.com> writes:
>
> > It extracts all the information for pull from the config file.
> >
> > If you have a config file as:
> >
> > [branch "master"]
> > remote=origin
> > merge=next #the remote name
> > octopus=octopus
> > twohead=recursive
> >
[...]
> I am in general in agreement with this line of thought and had
> an impression that many on the list wanted to have per-branch
> configuration. I am a bit too tired now so I'd just let you
> know I am interested but would not apply it tonight.
>
> Opinions? Comments? Anything missing or objectionable on
> Santi's patch from the list?
Actually my patch is a RFC to agree on the config semantics, (although
I do not mind if committed to "pu" :) :
.- are remote/merge good names?
.- the merge key is the name of the remote branch.
.- are the octopus and twohead OK?
.- for a local merge, is remote=. OK?
.- "git pull ." to mean: do not fetch anything but merge the default branch?
.- for the integrator case:
* is the "merge= rembranch from remote" OK?
* "git pull remotename" should read the branch properties if
branch.$curr_branch.remote=remotename?
* It could be usefull to have a git-merge-seq that performs a
twohead merge sequentially instead of an octopus.
The patch as is works for me and it currently depends on the remote
config being in .git/config.
It only touchs git-pull, just to have a working prototype of the
semantics and to minimize the breakage, but it could be that it should
be integrated in the git-parse-remote.
Santi
^ permalink raw reply
* Re: [PATCH] Always reset the color _before_ printing out the newline
From: Jeff King @ 2006-07-24 13:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607241440340.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, Jul 24, 2006 at 02:41:41PM +0200, Johannes Schindelin wrote:
> This patch brings the benefits of part of v1.4.1-rc2~37
> to the "commit" colorizing patch.
Oops, yes, I should have thought of that. Patch looks good to me.
-Peff
^ permalink raw reply
* Re: GIT user survey
From: Paolo Ciarrocchi @ 2006-07-24 13:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e9vsv9$iuo$1@sea.gmane.org>
On 7/23/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Paolo Ciarrocchi wrote:
>
> > If you know people using GIT please forward this message to them,
> > currently is has been sent to the following projects:
> > - u-boot
> > - wine
> > - cairo
> > - xmms2
> > - xcb
>
> Check out http://git.or.cz/gitwiki/GitProjects
Thanks. I sent out a few emails to other projects.
regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi
^ permalink raw reply
* Better Future, yard trader
From: Cathryn Purvis @ 2006-07-24 18:49 UTC (permalink / raw)
To: git-commits-head-owner
Your cre dit doesn't matter to us! If you OWN real est ate
and want IMMEDIATEG cash to spend ANY way you like, or simply wish
to LOWER your monthly paym ents by a third or more, here are the dea ls
we have TODAY (hurry, these ofers will expre TONIGHT):
$488,000.00 at a 3.67,% fixed-rateX
$372,000.00 at a 3.90,% variable-rate6
$492,000.00 at a 3.21,% interest-onlyE
$248,000.00 at a 3.36,% fixed-rate4
$198,000.00 at a 3.55,% variable-rate0
Hurry, when these deals are gone, they are gone Simply fill out this one-min ute form...
Don't worry about approval, your cre dit will not disqualify you!
http://WE8KUEJD.fortessed.com
wrong--that it would disappoint him, evoke doubts, throw him from the cloud
harder with his elbow and his knees. just get there, just a little more,
other on the rusty rails. Redrick unbuttoned a flap and took out a package
Redrick walked behind him, and as soon as he stepped out of the shade, the
car, and lay down, his elbow on the backpack.
could hear another peal of thunder. I'll shake your souls out of you for
on its axles, and he remembered that they could rest in the shade of the
the rounded bristly peaks of the hills. Here and there between the hills
"Forward! Forward!" he shouted, unable to hear himself.
"Well, I guessed! I don't remember exactly what gave me the clue. Well,
it's getting light!"
^ permalink raw reply
* Re: GIT user survey
From: Wolfgang Denk @ 2006-07-24 19:47 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30607230145i2480c20fxb06127c8b0187c98@mail.gmail.com>
In message <4d8e3fd30607230145i2480c20fxb06127c8b0187c98@mail.gmail.com> you wrote:
>
> If you know people using GIT please forward this message to them,
> currently is has been sent to the following projects:
> - u-boot
Has it? When? I haven't seen anything.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The thing is, as you progress in the Craft, you'll learn there is
another rule... When you break rules, break 'em good and hard.
- Terry Pratchett, _Wyrd Sisters_
^ permalink raw reply
* Re: GIT user survey
From: Paolo Ciarrocchi @ 2006-07-24 19:50 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Git Mailing List
In-Reply-To: <20060724194716.1B4EB352640@atlas.denx.de>
On 7/24/06, Wolfgang Denk <wd@denx.de> wrote:
> In message <4d8e3fd30607230145i2480c20fxb06127c8b0187c98@mail.gmail.com> you wrote:
> >
> > If you know people using GIT please forward this message to them,
> > currently is has been sent to the following projects:
> > - u-boot
>
>
> Has it? When? I haven't seen anything.
>
I don't follow the project but I know that NOW it's using GIT, see the
homepage http://u-boot.sourceforge.net/
regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi
^ permalink raw reply
* Re: GIT user survey
From: Wolfgang Denk @ 2006-07-24 20:11 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30607241250k3b1a7768yb27653750ae921b3@mail.gmail.com>
In message <4d8e3fd30607241250k3b1a7768yb27653750ae921b3@mail.gmail.com> you wrote:
>
> > > If you know people using GIT please forward this message to them,
> > > currently is has been sent to the following projects:
> > > - u-boot
> >
> > Has it? When? I haven't seen anything.
>
> I don't follow the project but I know that NOW it's using GIT, see the
> homepage http://u-boot.sourceforge.net/
Of course we use git; that's not the question.
I understood your posting such that you have sent a "GIT user survey"
to the U-Boot mailing list: you wrote: "is [typo for `it' ? -
referring to Subject:, i. e. `GIT user survey'?] has been sent to the
following projects..."
I wanted to make clear that nothing has been sent to the U-Boot
project. At least I haven't seen anything, nor can I find anything in
the archives.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"I've seen it. It's rubbish." - Marvin the Paranoid Android
^ permalink raw reply
* Re: GIT user survey
From: Paolo Ciarrocchi @ 2006-07-24 20:15 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Git Mailing List
In-Reply-To: <20060724201110.5B14635363E@atlas.denx.de>
On 7/24/06, Wolfgang Denk <wd@denx.de> wrote:
> In message <4d8e3fd30607241250k3b1a7768yb27653750ae921b3@mail.gmail.com> you wrote:
> >
> > > > If you know people using GIT please forward this message to them,
> > > > currently is has been sent to the following projects:
> > > > - u-boot
> > >
> > > Has it? When? I haven't seen anything.
> >
> > I don't follow the project but I know that NOW it's using GIT, see the
> > homepage http://u-boot.sourceforge.net/
>
> Of course we use git; that's not the question.
Doh :-)
> I understood your posting such that you have sent a "GIT user survey"
> to the U-Boot mailing list: you wrote: "is [typo for `it' ? -
> referring to Subject:, i. e. `GIT user survey'?] has been sent to the
> following projects..."
Yep, that was a typo.
And yes, I sent an email to u-boot-users@lists.sourceforge.net
Is that the correct email address?
> I wanted to make clear that nothing has been sent to the U-Boot
> project. At least I haven't seen anything, nor can I find anything in
> the archives.
Can you please FW my original email to the list?
Thanks.
regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi
^ permalink raw reply
* [PATCH] gitweb: escape tag comments
From: Daniel Drake @ 2006-07-24 22:07 UTC (permalink / raw)
To: junkio; +Cc: git, kay.sievers
I have a tag with a comment which includes an & character. Firefox wouldn't
display my gitweb summary page due to malformed XML. This solves the problem.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 2fd1e5f..5acd66d 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -1138,7 +1138,7 @@ sub git_summary {
"</td>\n" .
"<td>";
if (defined($comment)) {
- print $cgi->a({-class => "list", -href => "$my_uri?" . esc_param("p=$project;a=tag;h=$tag{'id'}")}, $comment);
+ print $cgi->a({-class => "list", -href => "$my_uri?" . esc_param("p=$project;a=tag;h=$tag{'id'}")}, esc_html($comment));
}
print "</td>\n" .
"<td class=\"link\">";
^ permalink raw reply related
* Re: [PATCH 1/2] add git-quote: shell and C quoting tool
From: Alex Riesen @ 2006-07-24 23:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwta3h7r2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Mon, Jul 24, 2006 07:49:53 +0200:
> > In case anyone asks why isn't it a standalone tool nor is it put into
> > git-stripspace: I don't know. Maybe it should be.
>
> This organization is fine by me.
>
> * unquote?
Not done yet. I actually never expected it to be used for unquoting,
being naturally unquoted by bash. C-quoting was done just because it
was so simple to do. I have no idea where could that be used.
> * doc?
Done. Sorry for missing that.
> > +enum {SHELL_QUOTE, C_QUOTE};
> > +static int style = SHELL_QUOTE,
> > + use_stdin = 0;
>
> Shouldn't style be of type which is that unnamed enum?
It should. Done.
> > +static const char *separator = NULL; /* default is space */
> > +static unsigned sep_len = 0;
>
> It is not clear if this is separator of input side or output
> side (after reading the code it becomes somewhat obvious that
> you are talking about output separator), and if the default is
> space wouldn't it make more sense to set that here?
Right. It is out_separator now.
> > +static const char builtin_quote_usage[] =
> > +"git-quote [--c] [--sep=<c-quoted> | -z] ( [--stdin] | [--] ... )";
> > +
> > +static void print_quoted(const char *text)
> > +{
> > + switch (style)
> > + {
> > + case SHELL_QUOTE:
> > + sq_quote_print(stdout, text);
> > + break;
> > + case C_QUOTE:
> > + quote_c_style(text, NULL, stdout, 0);
> > + break;
> > + }
>
> Not a big deal but aren't these going to write out things quoted
> when they do not need to? To help scripts, it might be worth
> adding "check if this needs quoting" interface perhaps?
Not done yet. "--no-overquote"?
> > + if (!strcmp(arg, "--c")) {
>
> Perhaps "--c-style" with "-c" as a shorthand, (and
> "--shell-style" with "-s" to complement)?
Done. --sh-style.
> > + style = C_QUOTE;
> > + continue;
> > + }
> > + if (!strcmp(arg, "-z")) {
> > + separator = "";
> > + sep_len = 1;
> > + continue;
> > + }
>
> Is it plausible that somebody might want to feed you NUL
> terminated sequence as input (iow you might want to give them
> choice of separator on the input side)?
Done. -z sets both separators to NUL, --in-separator=<c-style> defines
by its first character the input separator. I.e.:
$ find | git quote -z --in-separator='\n'
'a'\0'b'\0''
which is not all that useful...
> > + if (!strncmp(arg, "--sep=", 6)) {
>
> Perhaps "--separator" (or "--output-separator") with whatever
> shorthand is handy?
--out-separator. No idea of a shortcut, though
> > + separator = unquote_c_style(tmp, &end);
> > + sep_len = strlen(separator);
>
> If the parameter is a malformed c-quoted string, you would dump
> core here.
Oops. Fixed.
> > + if (!separator) {
> > + sep_len = 1;
> > + separator = "\x20";
>
> Any reason you needed to spell it in hex? Is this trying to
> be portable to EBCDIC (or trying to prevent the code to be
> ported there)? I dunno.
Visibility. I have dificulty seeing spaces and tabs.
I changed it anyway, maybe that's just me.
> > + while (EOF != (ch = fgetc(stdin))) {
>
> Looks similar to strbuf.c::read_line() loop...
>
Indeed. Replaced.
I attach the updated patch here, because it is obviously is not quite
finished yet and I probably wont have enough time over the week. So
maybe someone takes over. Or it'll be taken as is, that happens too.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
diff --git a/Documentation/git-quote.txt b/Documentation/git-quote.txt
new file mode 100644
index 0000000..98b2859
--- /dev/null
+++ b/Documentation/git-quote.txt
@@ -0,0 +1,70 @@
+git-quote(1)
+============
+
+NAME
+----
+git-quote - Quote given text according to Shell or C rules
+
+
+SYNOPSIS
+--------
+'git-quote' [-c] [-s] [-s] [--out-separator=<c-quoted>]
+ [--in-separator=<c-quoted>] [-z] [--] ...
+'git-quote' ... --stdin < <stream>
+
+DESCRIPTION
+-----------
+Quote the lines according to the given rules, which can be Shell backslash
+quoting (every line is enclosed in single ticks, backslash and single tick
+quoted specially) or a C quoting (use double ticks and backslash-prefixed
+symbols).
+
+The separator options are handled in the order they are given, so one
+can save some typing by giving "-z" first, and overriding input or
+output separator as needed.
+
+OPTIONS
+-------
+-c|--c-style::
+ Select C-style quoting
+
+-s|--sh-style::
+ Select Shell-style quoting. This is default.
+
+--out-separator=<c-quoted>::
+ Specify the separator between the output elements. If the separator
+ have to contain special characters, they must be quoted according
+ to C quoting rules (double ticks are not essential).
+ The ASCII space is default output separator.
+
+--in-separator=<c-quoted>::
+ Specify the separator between the input elements. Only the
+ first character of <c-quoted> is used.
+ Used only if --stdin is also given. The default is LF.
+
+-z::
+ Separate the elements on output and expect elements separated
+ on input with NUL character.
+ Used only if --stdin is also given.
+
+--stdin::
+ Specify that the elements have to be read from stdin.
+ This option ends command line parsing.
+ Also, if there were no output separator set by previous
+ --out-separator or -z, this option will set it to LF.
+
+<stream>::
+ Byte stream to act on.
+
+Author
+------
+Written by Alex Riesen <raa.lkml@gmail.com>
+
+Documentation
+--------------
+Documentation by Alex Riesen.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index 3e085df..4df2951 100644
--- a/Makefile
+++ b/Makefile
@@ -246,7 +246,8 @@ BUILTIN_OBJS = \
builtin-apply.o builtin-show-branch.o builtin-diff-files.o \
builtin-diff-index.o builtin-diff-stages.o builtin-diff-tree.o \
builtin-cat-file.o builtin-mailsplit.o builtin-stripspace.o \
- builtin-update-ref.o builtin-fmt-merge-msg.o builtin-prune.o
+ builtin-update-ref.o builtin-fmt-merge-msg.o builtin-prune.o \
+ builtin-quote.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
diff --git a/builtin-quote.c b/builtin-quote.c
new file mode 100644
index 0000000..d9d4b00
--- /dev/null
+++ b/builtin-quote.c
@@ -0,0 +1,123 @@
+/*
+ * "git quote" builtin command
+ *
+ * DOES NOT QUOTE \0 (truncates lines at it)
+ */
+#include "cache.h"
+#include "builtin.h"
+#include "strbuf.h"
+#include "quote.h"
+
+static enum {SHELL_QUOTE, C_QUOTE} style = SHELL_QUOTE;
+static int use_stdin = 0;
+static const char *out_separator = NULL; /* default is space */
+static unsigned out_separator_len = 0;
+
+static const char builtin_quote_usage[] =
+"git-quote [-c | -s] [--out-separator=<c-quoted> | -z] ( [--stdin] | [--] ... )";
+
+static void print_quoted(const char *text)
+{
+ switch (style)
+ {
+ case SHELL_QUOTE:
+ sq_quote_print(stdout, text);
+ break;
+ case C_QUOTE:
+ quote_c_style(text, NULL, stdout, 0);
+ break;
+ }
+ fwrite(out_separator, 1, out_separator_len, stdout);
+}
+
+static char *unquote_c_arg(const char *arg)
+{
+ const char *end;
+ char *tmp;
+ char *result;
+ if ('"' == *arg)
+ tmp = strdup(arg);
+ else {
+ size_t l = strlen(arg);
+ tmp = malloc(l + 3);
+ sprintf(tmp, "\"%s\"", arg);
+ }
+ result = unquote_c_style(tmp, &end);
+ free(tmp);
+ return result;
+}
+
+int cmd_quote(int argc, const char **argv, char **envp)
+{
+ int in_separator = '\n';
+ int i;
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+
+ if (arg[0] != '-')
+ break;
+ if (!strcmp(arg, "--")) {
+ i++;
+ break;
+ }
+ if (!strcmp(arg, "--stdin")) {
+ use_stdin = 1;
+ if ( !out_separator ) {
+ out_separator = "\n";
+ out_separator_len = 1;
+ }
+ break;
+ }
+ if (!strcmp(arg, "--c-style") || !strcmp(arg, "-c")) {
+ style = C_QUOTE;
+ continue;
+ }
+ if (!strcmp(arg, "--sh-style") || !strcmp(arg, "-s")) {
+ style = SHELL_QUOTE;
+ continue;
+ }
+ if (!strcmp(arg, "-z")) {
+ in_separator = 0;
+ out_separator = "";
+ out_separator_len = 1;
+ continue;
+ }
+ if (!strncmp(arg, "--out-separator=", 16)) {
+ arg += 16;
+ out_separator = unquote_c_arg(arg);
+ if (!out_separator)
+ die("malformed separator '%s'", arg);
+ out_separator_len = strlen(out_separator);
+ /* this will leak if multiple --sep= given */
+ continue;
+ }
+ if (!strncmp(arg, "--in-separator=", 15)) {
+ char *sep;
+ arg += 15;
+ sep = unquote_c_arg(arg);
+ if (!sep || !*sep)
+ die("malformed separator '%s'", arg);
+ in_separator = *sep;
+ free(sep);
+ continue;
+ }
+ die(builtin_quote_usage);
+ }
+ if (!out_separator) {
+ out_separator_len = 1;
+ out_separator = " ";
+ }
+ if (use_stdin) {
+ struct strbuf line;
+ strbuf_init(&line);
+
+ while (!line.eof) {
+ read_line(&line, stdin, in_separator);
+ if (line.len)
+ print_quoted(line.buf);
+ }
+ } else
+ for (; argv[i]; ++i)
+ print_quoted(argv[i]);
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index 5339d86..9bd522e 100644
--- a/builtin.h
+++ b/builtin.h
@@ -64,4 +64,6 @@ extern int mailinfo(FILE *in, FILE *out,
extern int cmd_stripspace(int argc, const char **argv, char **envp);
extern void stripspace(FILE *in, FILE *out);
+
+extern int cmd_quote(int argc, const char **argv, char **envp);
#endif
diff --git a/git.c b/git.c
index ee5a0e8..f94d25a 100644
--- a/git.c
+++ b/git.c
@@ -202,6 +202,7 @@ static void handle_internal_command(int
{ "update-ref", cmd_update_ref },
{ "fmt-merge-msg", cmd_fmt_merge_msg },
{ "prune", cmd_prune },
+ { "quote", cmd_quote },
};
int i;
^ permalink raw reply related
* [PATCH] Trivial path optimization test
From: Alex Riesen @ 2006-07-24 23:23 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0607140828250.5623@g5.osdl.org>
Linus:
get_pathspec() does turn '.' into an empty string (which is
correct - git internally does _not_ ever understand the notion of
"." as the current working directory), but it doesn't ever do the
optimization of noticing that a pathspec that consists solely of
an empty string is "equivalent" to an empty pathspec.
The test is to ensure that this behaviour stays.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t6004-rev-list-path-optim.sh | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/t/t6004-rev-list-path-optim.sh b/t/t6004-rev-list-path-optim.sh
new file mode 100755
index 0000000..5182dbb
--- /dev/null
+++ b/t/t6004-rev-list-path-optim.sh
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+test_description='git-rev-list trivial path optimization test'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+echo Hello > a &&
+git add a &&
+git commit -m "Initial commit" a
+'
+
+test_expect_success path-optimization '
+ commit=$(echo "Unchanged tree" | git-commit-tree "HEAD^{tree}" -p HEAD) &&
+ test $(git-rev-list $commit | wc -l) = 2 &&
+ test $(git-rev-list $commit -- . | wc -l) = 1
+'
+
+test_done
--
1.4.1.gb944
^ permalink raw reply related
* Re: [PATCH] Trivial path optimization test
From: Alex Riesen @ 2006-07-24 23:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7v4px7h5df.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Mon, Jul 24, 2006 08:41:16 +0200:
> Clean up the commit log pretty please.
No problem.
^ permalink raw reply
* Re: [PATCH] Allow an alias to start with "-p"
From: Junio C Hamano @ 2006-07-25 0:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607241408170.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Now, something like
>
> [alias]
> pd = -p diff
>
> works as expected.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
This seems to break t5400 among other things (git-clone
complains that it is not invoked in a git repository).
^ permalink raw reply
* [ANNOUNCE] GIT 1.4.1.1
From: Junio C Hamano @ 2006-07-25 3:53 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.4.1.1 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.1.1.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.1.1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.1.1.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.1.1-1.$arch.rpm (RPM)
The primary purpose of this release is to fix the breakage
people reported while cloning large quantity of data via git
protocol, and the server side incorrectly timing out. I am very
sorry for the breakage.
A big thanks goes to Matthias Lederhofer who fixed the breakage
for us. The fix was cherry-picked from the "master" branch.
The "master" branch has the same fix already and we will have an
1.4.2-rc2 sometime this week, hopefully soon.
----------------------------------------------------------------
Changes since v1.4.1 are as follows:
Junio C Hamano:
Makefile: tighten git-http-{fetch,push} dependencies
Linus Torvalds:
revision.c: fix "dense" under --remove-empty
Matthias Lederhofer:
upload-pack: fix timeout in create_pack_file
Robin Rosenberg:
Empty author may be presented by svn as an empty string or a null value.
^ permalink raw reply
* Re: [PATCH] Allow an alias to start with "-p"
From: Jeff King @ 2006-07-25 5:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0607241408170.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, Jul 24, 2006 at 02:10:45PM +0200, Johannes Schindelin wrote:
> @@ -264,6 +289,7 @@ int main(int argc, const char **argv, ch
> if (!strncmp(cmd, "git-", 4)) {
> cmd += 4;
> argv[0] = cmd;
> + handle_alias(&argc, &argv);
> handle_internal_command(argc, argv, envp);
> die("cannot handle %s internally", cmd);
> }
I believe this change is the source of the breakage in tests.
GIT_DIR=foo git-init-db no longer works because handle_alias
unconditionally calls setup_git_directory_gently(), which thinks that if
GIT_DIR is set, it must exist.
This can be fixed by giving precedence to the internal command over
alias checking. This makes sense, anyway, since later in the function,
we give precedence to internal commands in the "git init-db" form.
Patch is below (wow, that +++ is kind of ugly!).
-Peff
+++
git: choose internal commands over aliases for git-*
This is especially important because some commands (like init-db) don't
require a working GIT_DIR, and alias expansion tries to look at it. It
also matches the behavior of "git cmd".
Signed-off-by: Jeff King <peff@peff.net>
---
git.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index 8d7c644..68ce826 100644
--- a/git.c
+++ b/git.c
@@ -289,8 +289,8 @@ int main(int argc, const char **argv, ch
if (!strncmp(cmd, "git-", 4)) {
cmd += 4;
argv[0] = cmd;
- handle_alias(&argc, &argv);
handle_internal_command(argc, argv, envp);
+ handle_alias(&argc, &argv);
die("cannot handle %s internally", cmd);
}
--
1.4.2.rc1.gc470-dirty
^ permalink raw reply related
* Re: [PATCH] Allow an alias to start with "-p"
From: Johannes Schindelin @ 2006-07-25 6:18 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20060725050312.GA5618@coredump.intra.peff.net>
Hi,
On Tue, 25 Jul 2006, Jeff King wrote:
> On Mon, Jul 24, 2006 at 02:10:45PM +0200, Johannes Schindelin wrote:
>
> > @@ -264,6 +289,7 @@ int main(int argc, const char **argv, ch
> > if (!strncmp(cmd, "git-", 4)) {
> > cmd += 4;
> > argv[0] = cmd;
> > + handle_alias(&argc, &argv);
> > handle_internal_command(argc, argv, envp);
> > die("cannot handle %s internally", cmd);
> > }
My fault. This was a left-over from my original alias patch. (I did a
merge, and just used "git-diff next" instead of "git-diff --merge next".
<Clickety-click/> Nope, that would not have worked either.
> Patch is below (wow, that +++ is kind of ugly!).
Same here.
> git: choose internal commands over aliases for git-*
>
> This is especially important because some commands (like init-db) don't
> require a working GIT_DIR, and alias expansion tries to look at it. It
> also matches the behavior of "git cmd".
>
> Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> @@ -289,8 +289,8 @@ int main(int argc, const char **argv, ch
> if (!strncmp(cmd, "git-", 4)) {
> cmd += 4;
> argv[0] = cmd;
> - handle_alias(&argc, &argv);
> handle_internal_command(argc, argv, envp);
> + handle_alias(&argc, &argv);
> die("cannot handle %s internally", cmd);
> }
Alternatively, you can just delete it. IIRC we decided that aliases with
"git-" commands do not make sense.
Ciao,
Dscho
^ 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