* Re: [PATCH] fetch: refuse to fetch into the current branch in a non-bare repository
From: Shawn O. Pearce @ 2008-10-12 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vprm6iz6z.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Some confusing tutorials suggest that it would be a good idea to call
> > something like this:
> >
> > git pull origin master:master
> >
> > While it might make sense to store what you want to merge, it typically
> > is plain wrong.
>
> I am somewhat confused.
The description is confusing, yes. It should be about git fetch,
not git pull.
> This "confusion" has been there for very long time and (at least the
> scripted version of) git-pull/git-fetch pair has supported a workaround in
> the form of --update-head-ok option.
I think "git fetch url side:master" when master is the current branch
and we have omitted --update-head-ok is broken. Specifically Dscho's
last hunk which adds this test. The test fails on current master.
Looking at the code in builtin-fetch.c, the only usage of
update_head_ok is for output about the current branch. I think
it should have been used in at least one other spot, to decide if
the RHS of a refspec is valid for storage. Dscho's patch tries to
address that.
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 9aae496..cd8b550 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -323,4 +323,10 @@ test_expect_success 'auto tag following fetches minimum' '
)
'
+test_expect_success 'refuse to fetch into the current branch' '
+
+ test_must_fail git fetch . side:master
+
+'
+
test_done
--
Shawn.
^ permalink raw reply related
* [PATCH] compat/cygwin.c - Use cygwin's stat if core.filemode == true
From: Mark Levedahl @ 2008-10-12 18:44 UTC (permalink / raw)
To: gitster; +Cc: spearce, dpotapov, git, Mark Levedahl
In-Reply-To: <20081012133934.GB21650@dpotapov.dyndns.org>
Cygwin's POSIX emulation allows use of core.filemode true, unlike native
Window's implementation of stat / lstat, and Cygwin/git users who have
configured core.filemode true in various repositories will be very
unpleasantly surprised to find that git is no longer honoring that option.
So, this patch forces use of Cygwin's stat functions if core.filemode is
set true, regardless of any other considerations.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
Updated to use trust_executable_bit as suggested on the list.
Documentation/config.txt | 4 +++-
compat/cygwin.c | 16 +++++++++++++---
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7161597..a3a9495 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -124,7 +124,9 @@ core.ignoreCygwinFSTricks::
one hierarchy using Cygwin mount. If true, Git uses native Win32 API
whenever it is possible and falls back to Cygwin functions only to
handle symbol links. The native mode is more than twice faster than
- normal Cygwin l/stat() functions. True by default.
+ normal Cygwin l/stat() functions. True by default, unless core.filemode
+ is true, in which case ignoreCygwinFSTricks is ignored as Cygwin's
+ POSIX emulation is required to support core.filemode.
core.trustctime::
If false, the ctime differences between the index and the
diff --git a/compat/cygwin.c b/compat/cygwin.c
index 423ff20..221d2f5 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -91,12 +91,17 @@ static int cygwin_stat(const char *path, struct stat *buf)
* functions should be used. The choice is determined by core.ignorecygwinfstricks.
* Reading this option is not always possible immediately as git_dir may be
* not be set yet. So until it is set, use cygwin lstat/stat functions.
+ * However, if core.filemode is true, we *must* use the Cygwin posix stat as
+ * the Windows stat fuctions do not determine posix filemode.
*/
static int native_stat = 1;
+extern int trust_executable_bit;
static int git_cygwin_config(const char *var, const char *value, void *cb)
{
- if (!strcmp(var, "core.ignorecygwinfstricks"))
+ if (!strcmp(var, "core.filemode"))
+ trust_executable_bit = git_config_bool(var, value);
+ else if (!strcmp(var, "core.ignorecygwinfstricks"))
native_stat = git_config_bool(var, value);
return 0;
}
@@ -105,8 +110,13 @@ static int init_stat(void)
{
if (have_git_dir()) {
git_config(git_cygwin_config, NULL);
- cygwin_stat_fn = native_stat ? cygwin_stat : stat;
- cygwin_lstat_fn = native_stat ? cygwin_lstat : lstat;
+ if (!trust_executable_bit && native_stat) {
+ cygwin_stat_fn = cygwin_stat;
+ cygwin_lstat_fn = cygwin_lstat;
+ } else {
+ cygwin_stat_fn = stat;
+ cygwin_lstat_fn = lstat;
+ }
return 0;
}
return 1;
--
1.6.0.2.535.g81f8.dirty
^ permalink raw reply related
* Re: [PATCH] Introduce core.keepHardLinks
From: Shawn O. Pearce @ 2008-10-12 18:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0810111344241.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> When a tracked file was hard linked, we used to break the hard link
> whenever Git writes to that file. Make that optional.
Why would anyone want to do this?
I cannot fathom why a user wants this much rope to hang themselves
with...
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 173386e..7bfe431 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -207,6 +207,10 @@ core.symlinks::
> file. Useful on filesystems like FAT that do not support
> symbolic links. True by default.
>
> +core.keepHardLinks::
> + If true, do not break hard links by deleting and recreating the
> + files. Off by default.
> +
> core.gitProxy::
> A "proxy command" to execute (as 'command host port') instead
> of establishing direct connection to the remote server when
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH] describe: Make --tags and --all match lightweight tags more often
From: Uwe Kleine-König @ 2008-10-12 18:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano, Pierre Habouzit, Erez Zilber
In-Reply-To: <20081010165952.GI8203@spearce.org>
On Fri, Oct 10, 2008 at 09:59:52AM -0700, Shawn O. Pearce wrote:
> If the caller supplies --tags they want the lightweight, unannotated
> tags to be searched for a match. If a lightweight tag is closer
> in the history, it should be matched, even if an annotated tag is
> reachable further back in the commit chain.
>
> The same applies with --all when matching any other type of ref.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
>
> This come out of the discussions earlier last week, where folks
> were confused about the meaning of --tags and wanted to see it
> behave as they expected, which was to match the nearest tag,
> no matter its "type".
>
> The code is unchanged from what I sent out before, but now it has
> updated test vectors and a commit message.
>
> Thoughts?
As I already told earlier, this is exactly how I would expect it.
> static int debug; /* Display lots of verbose info */
> -static int all; /* Default to annotated tags only */
> -static int tags; /* But allow any tags if --tags is specified */
> +static int all; /* Any valid ref can be used */
> +static int tags; /* Either lightweight or annotated tags */
Maybe the last comment should better read:
/* allow lightweight tags */
? Apart from this one nitpick:
Acked-By: Uwe Kleine-König <ukleinek@strlen.de>
Thanks
Uwe
^ permalink raw reply
* Re: [PATCH v2] correct verify_path for Windows
From: Alex Riesen @ 2008-10-12 18:18 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Johannes Sixt, Joshua Juran, Giovanni Funchal, git,
Shawn O. Pearce
In-Reply-To: <20081012135048.GC21650@dpotapov.dyndns.org>
Dmitry Potapov, Sun, Oct 12, 2008 15:50:48 +0200:
> On Sun, Oct 12, 2008 at 12:58:52AM +0200, Alex Riesen wrote:
> > 2008/10/11 Dmitry Potapov <dpotapov@gmail.com>:
> > >> > + /* On Windows, file names are case-insensitive */
> > >> > + case 'G':
> > >> > + if ((rest[1]|0x20) != 'i')
> > >> > + break;
> > >> > + if ((rest[2]|0x20) != 't')
> > >> > + break;
> > >>
> > >> We have tolower().
> > >
> > > I am aware of that, but I am not sure what we gain by using it. It seems
> > > it makes only code bigger and slow.
> >
> > It does? Care to look into git-compat-util.h?
>
> As a matter of fact, I did, and I see the following:
>
> #define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
> #define tolower(x) sane_case((unsigned char)(x), 0x20)
>
> static inline int sane_case(int x, int high)
> {
> if (sane_istest(x, GIT_ALPHA))
> x = (x & ~0x20) | high;
> return x;
> }
>
> So, it looks like an extra look up and an extra comparison here.
Does not look like much more code. But:
> > BTW, is it such a critical path?
>
> I am not sure whether it is critical or not. It is called for each
> name in path. So, if you have a long path, it may be called quite a
> few times per a single path. Also, some operation such 'git add' can
> call verify_path() more than once (IIRC, it was called thrice per each
> added file). But I have no numbers to tell whether it is noticeable or
> not.
I looked at the callers (briefly). Performance could be a problem: add
and checkout can work with real big file lists and long pathnames.
So ok, than. It is critical.
^ permalink raw reply
* Re: [RFC PATCH] describe: Make --tags and --all match lightweight tags more often
From: Andreas Ericsson @ 2008-10-12 18:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano, Pierre Habouzit, Erez Zilber
In-Reply-To: <20081012180040.GC4856@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Shawn O. Pearce wrote:
>>> If the caller supplies --tags they want the lightweight, unannotated
>>> tags to be searched for a match. If a lightweight tag is closer
>>> in the history, it should be matched, even if an annotated tag is
>>> reachable further back in the commit chain.
>>>
>>> The same applies with --all when matching any other type of ref.
>>>
>> In 99% of the cases, "--all" will then give back the currently
>> checked out branch unless a revision is specified, right?
>
> Yup.
>
> `git describe --all` or `git describe --all HEAD`
>
> would kick back the current branch you have checked out, assuming
> you have a real branch under refs/heads and not some detached HEAD.
>
> IMHO, that's what the user asked for.
>
True. I think this will raise questions of its usability though,
in particular if it considers remote branches too.
Otoh, I've never seen the use for "git describe --all" earlier
either, so I guess I think differently from those who want this
feature.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Shawn O. Pearce @ 2008-10-12 18:05 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Michael J Gruber, Johannes Schindelin,
Caleb Cushing, git
In-Reply-To: <20081012064512.GA32597@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Sat, Oct 11, 2008 at 11:41:18PM -0700, Junio C Hamano wrote:
>
> > And just make it mimic whatever folks accustomed to "svn st" would expect,
> > modulo we would need two status letters to signal difference between
> > (HEAD, index), and (index, worktree). Perhaps three if you want to show
> > difference between (HEAD, worktree) while at it.
>
> I remember a long time ago you started on a parallel diff walker that
> could diff the working tree, the index, and a tree at once. Do you
> remember the issues with it?
>
> I think that would be the right tool here to show each file only once,
> but with multiple status flags. Something like:
>
> A M foo
I have a tool that I'll be open-sourcing later this year, but it does
something like that:
project foo/ branch master
Am foo
M- bar
R- orig => dest ( 95%)
Line coloring is red on lines with unstaged stuff in the working
directory (3rd column, lower case letters) and green on lines that
are fully staged (3rd column is a '-').
The tool is in Python, but I'm just scraping the output of
`diff-index -M --cached HEAD` and diff-files to get that
display. The status letters are exactly those given out by
diff-index/diff-files, but the diff-files output is lowercased.
Scott Chacon has seen the tool output and likes it; there's a tech
talk that will be posted on YouTube soon where he and I are sort
of talking about it.
Sorry I can't say too much more about it yet. But I'm trying to
say that both Scott and I like a denser display like this.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH] describe: Make --tags and --all match lightweight tags more often
From: Shawn O. Pearce @ 2008-10-12 18:00 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Junio C Hamano, Pierre Habouzit, Erez Zilber
In-Reply-To: <48F12CF8.505@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Shawn O. Pearce wrote:
>> If the caller supplies --tags they want the lightweight, unannotated
>> tags to be searched for a match. If a lightweight tag is closer
>> in the history, it should be matched, even if an annotated tag is
>> reachable further back in the commit chain.
>>
>> The same applies with --all when matching any other type of ref.
>>
>
> In 99% of the cases, "--all" will then give back the currently
> checked out branch unless a revision is specified, right?
Yup.
`git describe --all` or `git describe --all HEAD`
would kick back the current branch you have checked out, assuming
you have a real branch under refs/heads and not some detached HEAD.
IMHO, that's what the user asked for.
--
Shawn.
^ permalink raw reply
* Re: tip tree clone fail
From: Shawn O. Pearce @ 2008-10-12 17:59 UTC (permalink / raw)
To: Jakub Narebski
Cc: Ingo Molnar, Petr Baudis, H. Peter Anvin, Wang Chen,
Thomas Gleixner, FNST-Lai Jiangshan, FJ-KOSAKI Motohiro, git,
Junio C Hamano
In-Reply-To: <m3tzbhk94k.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> Ingo Molnar <mingo@elte.hu> writes:
>
> > Soapbox: in fact it would be outright stupid to limit the kernel
> > source's availability artificially by not making HTTP a tier-one access
> > method.
>
> Hopefully there should soon be here "smart" HTTP server [...]
>
> It is WIP, but I'm not sure how far it is from completion.
Its still not even prototyped. I'm supposed to be spending my 20%
time at Google on the Git-in-HTTP documentation and implementation,
so I can feed patches to the list for review.
Sadly, my current 80% project has been demanding >120% of my time
these past 5 weeks, so I have not been able to touch the Git-in-HTTP
concept in that time period.
Most of my 80% project has to be wrapped up by this time next
week. Afterwards I'm going to try and dedicate at least a week
to Git-in-HTTP and get caught up. I sort of have to; its part of
my goals for my performance evaluation. Even if the list winds
up rejecting my implementation, I still have to put it out there
for discussion.
--
Shawn.
^ permalink raw reply
* Re: tip tree clone fail
From: Jakub Narebski @ 2008-10-12 17:37 UTC (permalink / raw)
To: Ingo Molnar
Cc: Petr Baudis, H. Peter Anvin, Wang Chen, Thomas Gleixner,
FNST-Lai Jiangshan, FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012165954.GA2317@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> Soapbox: in fact it would be outright stupid to limit the kernel
> source's availability artificially by not making HTTP a tier-one access
> method.
>
> Fighting against HTTP-only firewalls is like constantly pointing it out
> to the popular press that they should say 'cracker' instead of 'hacker'.
> It is pointless and only hurts the availability our own project.
Hopefully there should soon be here "smart" HTTP server (as for
example CGI script), which encapsulates git protocol, modified for the
fact that HTTP is stateless protocol, in HTTP. It would unfortunately
require git installed on server.
It is WIP, but I'm not sure how far it is from completion.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: tip tree clone fail
From: Ingo Molnar @ 2008-10-12 16:59 UTC (permalink / raw)
To: Petr Baudis
Cc: H. Peter Anvin, Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012153952.GV10544@machine.or.cz>
* Petr Baudis <pasky@suse.cz> wrote:
> On Sun, Oct 12, 2008 at 05:24:27PM +0200, Ingo Molnar wrote:
> > hm, -tip's .git/hooks/post-update already contained this, for the last 2
> > months:
> >
> > exec git update-server-info
> >
> > so ... _despite_ us having this in the git repo, the HTTP protocol still
> > does not work. Why?
>
> I think your problem is that HTTP does not know where to look for
> objects coming from alternates; IIRC this would work if you used
> relative paths in objects/info/alternates, or you can create
> objects/info/http-alternates like
>
> /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
> /pub/scm/linux/kernel/git/sfr/linux-next.git/objects
ok, i've now set it up like this:
$ pwd
/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
$ cat objects/info/alternates
/home/ftp/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
/home/ftp/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
$ cat objects/info/http-alternates
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
and i've added "git update-server-info" to hooks/post-receive and made
it chmod +x.
that should be golden, right? I'm wondering why this isnt in the default
setup - i've been behind a limited corporate firewall in a former life
and having HTTP access is indeed very handy and pragmatic. Often hotel
WLANs are HTTP only as well.
Soapbox: in fact it would be outright stupid to limit the kernel
source's availability artificially by not making HTTP a tier-one access
method.
Fighting against HTTP-only firewalls is like constantly pointing it out
to the popular press that they should say 'cracker' instead of 'hacker'.
It is pointless and only hurts the availability our own project.
Ingo
^ permalink raw reply
* [PATCH] Teach/Fix git-pull/git-merge --quiet and --verbose
From: Tuncer Ayaz @ 2008-10-12 16:54 UTC (permalink / raw)
To: git
After fixing clone -q I noticed that pull -q is does not do what
it's supposed to do and implemented --quiet/--verbose by
adding it to builtin-merge and fixing two places in builtin-fetch.
I have not touched/adjusted contrib/completion/git-completion.bash
but can take a look if wanted. I think it needs one or two adjustions
anyway caused by recent --OPTIONS changes in master.
I've tested the following invocations with the below changes applied:
$ git pull
$ git pull -q
$ git pull -v
Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
---
Documentation/merge-options.txt | 8 ++++++
builtin-fetch.c | 5 ++-
builtin-merge.c | 52 +++++++++++++++++++++++---------------
git-pull.sh | 10 +++++--
4 files changed, 49 insertions(+), 26 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 007909a..427cdef 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -1,3 +1,11 @@
+-q::
+--quiet::
+ Operate quietly.
+
+-v::
+--verbose::
+ Be verbose.
+
--stat::
Show a diffstat at the end of the merge. The diffstat is also
controlled by the configuration option merge.stat.
diff --git a/builtin-fetch.c b/builtin-fetch.c
index ee93d3a..b5c2885 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -372,12 +372,13 @@ static int store_updated_refs(const char *url,
const char *remote_name,
SUMMARY_WIDTH, *kind ? kind : "branch",
REFCOL_WIDTH, *what ? what : "HEAD");
if (*note) {
- if (!shown_url) {
+ if ((verbose || !quiet) && !shown_url) {
fprintf(stderr, "From %.*s\n",
url_len, url);
shown_url = 1;
}
- fprintf(stderr, " %s\n", note);
+ if(verbose || !quiet)
+ fprintf(stderr, " %s\n", note);
}
}
fclose(fp);
diff --git a/builtin-merge.c b/builtin-merge.c
index 38266ba..1f601d4 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -44,6 +44,7 @@ static const char * const builtin_merge_usage[] = {
static int show_diffstat = 1, option_log, squash;
static int option_commit = 1, allow_fast_forward = 1;
static int allow_trivial = 1, have_message;
+static int quiet, verbose;
static struct strbuf merge_msg;
static struct commit_list *remoteheads;
static unsigned char head[20], stash[20];
@@ -101,7 +102,7 @@ static struct strategy *get_strategy(const char *name)
struct cmdname *ent = main_cmds.names[i];
for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
if (!strncmp(ent->name, all_strategy[j].name, ent->len)
- && !all_strategy[j].name[ent->len])
+ && !all_strategy[j].name[ent->len])
found = 1;
if (!found)
add_cmdname(¬_strategies, ent->name, ent->len);
@@ -152,6 +153,8 @@ static int option_parse_n(const struct option *opt,
}
static struct option builtin_merge_options[] = {
+ OPT__QUIET(&quiet),
+ OPT__VERBOSE(&verbose),
{ OPTION_CALLBACK, 'n', NULL, NULL, NULL,
"do not show a diffstat at the end of the merge",
PARSE_OPT_NOARG, option_parse_n },
@@ -250,7 +253,8 @@ static void restore_state(void)
/* This is called when no merge was necessary. */
static void finish_up_to_date(const char *msg)
{
- printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
+ if(verbose || !quiet)
+ printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
drop_save();
}
@@ -262,7 +266,8 @@ static void squash_message(void)
struct commit_list *j;
int fd;
- printf("Squash commit -- not updating HEAD\n");
+ if(verbose || !quiet)
+ printf("Squash commit -- not updating HEAD\n");
fd = open(git_path("SQUASH_MSG"), O_WRONLY | O_CREAT, 0666);
if (fd < 0)
die("Could not write to %s", git_path("SQUASH_MSG"));
@@ -282,18 +287,20 @@ static void squash_message(void)
if (prepare_revision_walk(&rev))
die("revision walk setup failed");
- strbuf_init(&out, 0);
- strbuf_addstr(&out, "Squashed commit of the following:\n");
- while ((commit = get_revision(&rev)) != NULL) {
- strbuf_addch(&out, '\n');
- strbuf_addf(&out, "commit %s\n",
- sha1_to_hex(commit->object.sha1));
- pretty_print_commit(rev.commit_format, commit, &out, rev.abbrev,
- NULL, NULL, rev.date_mode, 0);
+ if(verbose || !quiet) {
+ strbuf_init(&out, 0);
+ strbuf_addstr(&out, "Squashed commit of the following:\n");
+ while ((commit = get_revision(&rev)) != NULL) {
+ strbuf_addch(&out, '\n');
+ strbuf_addf(&out, "commit %s\n",
+ sha1_to_hex(commit->object.sha1));
+ pretty_print_commit(rev.commit_format, commit, &out, rev.abbrev,
+ NULL, NULL, rev.date_mode, 0);
+ }
+ write(fd, out.buf, out.len);
+ close(fd);
+ strbuf_release(&out);
}
- write(fd, out.buf, out.len);
- close(fd);
- strbuf_release(&out);
}
static int run_hook(const char *name)
@@ -333,14 +340,15 @@ static void finish(const unsigned char
*new_head, const char *msg)
if (!msg)
strbuf_addstr(&reflog_message, getenv("GIT_REFLOG_ACTION"));
else {
- printf("%s\n", msg);
+ if(verbose || !quiet)
+ printf("%s\n", msg);
strbuf_addf(&reflog_message, "%s: %s",
getenv("GIT_REFLOG_ACTION"), msg);
}
if (squash) {
squash_message();
} else {
- if (!merge_msg.len)
+ if ((verbose || !quiet) && !merge_msg.len)
printf("No merge message -- not updating HEAD\n");
else {
const char *argv_gc_auto[] = { "gc", "--auto", NULL };
@@ -877,6 +885,8 @@ int cmd_merge(int argc, const char **argv, const
char *prefix)
argc = parse_options(argc, argv, builtin_merge_options,
builtin_merge_usage, 0);
+ if(!verbose && quiet)
+ show_diffstat = 0;
if (squash) {
if (!allow_fast_forward)
@@ -1019,11 +1029,11 @@ int cmd_merge(int argc, const char **argv,
const char *prefix)
char hex[41];
strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));
-
- printf("Updating %s..%s\n",
- hex,
- find_unique_abbrev(remoteheads->item->object.sha1,
- DEFAULT_ABBREV));
+ if(verbose || !quiet)
+ printf("Updating %s..%s\n",
+ hex,
+ find_unique_abbrev(remoteheads->item->object.sha1,
+ DEFAULT_ABBREV));
strbuf_init(&msg, 0);
strbuf_addstr(&msg, "Fast forward");
if (have_message)
diff --git a/git-pull.sh b/git-pull.sh
index 75c3610..d84ceb5 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -16,13 +16,17 @@ cd_to_toplevel
test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
-strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
+quiet= verbose= strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
rebase=$(git config --bool branch.$curr_branch_short.rebase)
while :
do
case "$1" in
+ -q|--quiet)
+ quiet=-q ;;
+ -v|--verbose)
+ verbose=-v ;;
-n|--no-stat|--no-summary)
no_stat=-n ;;
--stat|--summary)
@@ -121,7 +125,7 @@ test true = "$rebase" && {
"refs/remotes/$origin/$reflist" 2>/dev/null)"
}
orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
-git fetch --update-head-ok "$@" || exit 1
+git fetch $verbose $quiet --update-head-ok "$@" || exit 1
curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
if test "$curr_head" != "$orig_head"
@@ -181,5 +185,5 @@ merge_name=$(git fmt-merge-msg $log_arg
<"$GIT_DIR/FETCH_HEAD") || exit
test true = "$rebase" &&
exec git-rebase $strategy_args --onto $merge_head \
${oldremoteref:-$merge_head}
-exec git-merge $no_stat $no_commit $squash $no_ff $log_arg $strategy_args \
+exec git-merge $quiet $verbose $no_stat $no_commit $squash $no_ff
$log_arg $strategy_args \
"$merge_name" HEAD $merge_head
--
1.6.0.2.GIT
^ permalink raw reply related
* Re: [PATCH 2/2 v2] check-attr: Add --stdin-paths option
From: Dmitry Potapov @ 2008-10-12 16:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Shawn O. Pearce
In-Reply-To: <gct3lk$s16$1@ger.gmane.org>
On Sun, Oct 12, 2008 at 05:04:21PM +0200, Jakub Narebski wrote:
> Dmitry Potapov wrote:
>
> >> And since its being
> >> used mostly by automated tools (gitk/git-gui) I wonder if a -z should
> >> also be supported for input termination with NUL instead of LF.
> >
> > I have added it, but after I did, I start to wonder whether it is the
> > right thing to do to unquote NUL terminated input line?
>
> I think that -z should be not quoted (like git-diff-tree or git-ls-tree
> _output_); if it is, then IMHO it is a bug.
I am sorry. I was obviously wrong about 'git checkout-index', as it does
not try to unquote if '-z' is specified. So, my previous patch was wrong.
The corrected patch is below.
It still uses the same output format whether '-z' is specified or not.
Maybe I should change that too to use '\0' as the separator if '-z' is
specified?
Dmitry
PS Please, add me to 'To:' or 'Cc:' when you reply to my email.
-- >8 --
From: Dmitry Potapov <dpotapov@gmail.com>
Date: Sun, 12 Oct 2008 18:08:43 +0400
Subject: [PATCH] check-attr: Add --stdin option
---
This patch is meant to be squash on top of dp/checkattr in pu.
Documentation/git-check-attr.txt | 8 ++++++--
builtin-check-attr.c | 15 ++++++++++-----
t/t0003-attributes.sh | 2 +-
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
index 0839a57..14e4374 100644
--- a/Documentation/git-check-attr.txt
+++ b/Documentation/git-check-attr.txt
@@ -9,7 +9,7 @@ git-check-attr - Display gitattributes information.
SYNOPSIS
--------
'git check-attr' attr... [--] pathname...
-'git check-attr' --stdin-paths attr... < <list-of-paths
+'git check-attr' --stdin [-z] attr... < <list-of-paths
DESCRIPTION
-----------
@@ -18,9 +18,13 @@ For every pathname, this command will list if each attr is 'unspecified',
OPTIONS
-------
---stdin-paths::
+--stdin::
Read file names from stdin instead of from the command-line.
+-z::
+ Only meaningful with `--stdin`; paths are separated with
+ NUL character instead of LF.
+
\--::
Interpret all preceding arguments as attributes, and all following
arguments as path names. If not supplied, only the first argument will
diff --git a/builtin-check-attr.c b/builtin-check-attr.c
index fa1e4d5..4921341 100644
--- a/builtin-check-attr.c
+++ b/builtin-check-attr.c
@@ -7,12 +7,16 @@
static int stdin_paths;
static const char * const check_attr_usage[] = {
"git check-attr attr... [--] pathname...",
-"git check-attr --stdin-paths attr... < <list-of-paths>",
+"git check-attr --stdin attr... < <list-of-paths>",
NULL
};
+static int null_term_line;
+
static const struct option check_attr_options[] = {
- OPT_BOOLEAN(0 , "stdin-paths", &stdin_paths, "read file names from stdin"),
+ OPT_BOOLEAN(0 , "stdin", &stdin_paths, "read file names from stdin"),
+ OPT_BOOLEAN('z', NULL, &null_term_line,
+ "input paths are terminated by a null character"),
OPT_END()
};
@@ -41,11 +45,12 @@ static void check_attr_stdin_paths(int cnt, struct git_attr_check *check,
const char** name)
{
struct strbuf buf, nbuf;
+ int line_termination = null_term_line ? 0 : '\n';
strbuf_init(&buf, 0);
strbuf_init(&nbuf, 0);
- while (strbuf_getline(&buf, stdin, '\n') != EOF) {
- if (buf.buf[0] == '"') {
+ while (strbuf_getline(&buf, stdin, line_termination) != EOF) {
+ if (line_termination && buf.buf[0] == '"') {
strbuf_reset(&nbuf);
if (unquote_c_style(&nbuf, buf.buf, NULL))
die("line is badly quoted");
@@ -90,7 +95,7 @@ int cmd_check_attr(int argc, const char **argv, const char *prefix)
if (cnt <= 0)
errstr = "No attribute specified";
else if (stdin_paths && doubledash < argc)
- errstr = "Can't specify files with --stdin-paths";
+ errstr = "Can't specify files with --stdin";
if (errstr) {
error (errstr);
usage_with_options(check_attr_usage, check_attr_options);
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index f6901b4..1c77192 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -60,7 +60,7 @@ a/b/h: test: a/b/h
a/b/d/g: test: a/b/d/*
EOF
- sed -e "s/:.*//" < expect | git check-attr --stdin-paths test > actual &&
+ sed -e "s/:.*//" < expect | git check-attr --stdin test > actual &&
test_cmp expect actual
'
--
1.6.0.2.521.g739d3
-- >8 --
^ permalink raw reply related
* Re: tip tree clone fail
From: Petr Baudis @ 2008-10-12 15:39 UTC (permalink / raw)
To: Ingo Molnar
Cc: H. Peter Anvin, Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012152427.GA4607@elte.hu>
On Sun, Oct 12, 2008 at 05:24:27PM +0200, Ingo Molnar wrote:
> hm, -tip's .git/hooks/post-update already contained this, for the last 2
> months:
>
> exec git update-server-info
>
> so ... _despite_ us having this in the git repo, the HTTP protocol still
> does not work. Why?
I think your problem is that HTTP does not know where to look for
objects coming from alternates; IIRC this would work if you used
relative paths in objects/info/alternates, or you can create
objects/info/http-alternates like
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: tip tree clone fail
From: Teemu Likonen @ 2008-10-12 15:36 UTC (permalink / raw)
To: Ingo Molnar
Cc: H. Peter Anvin, Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012152427.GA4607@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> * H. Peter Anvin <hpa@zytor.com> wrote:
>> post-update, rather than post-receive.
>>
>> The standard post-update.sample contains it, it just needs a rename.
>
> hm, -tip's .git/hooks/post-update already contained this, for the last 2
> months:
>
> exec git update-server-info
>
> so ... _despite_ us having this in the git repo, the HTTP protocol
> still does not work. Why?
I don't know why but I have experienced the same: post-update hook just
doesn't work. I described it here:
http://thread.gmane.org/gmane.comp.version-control.git/82351
Fortunately post-receive hooks works, so you could to try it instead.
^ permalink raw reply
* Re: tip tree clone fail
From: Ingo Molnar @ 2008-10-12 15:24 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48F20663.2040407@zytor.com>
* H. Peter Anvin <hpa@zytor.com> wrote:
> Ingo Molnar wrote:
>> * H. Peter Anvin <hpa@zytor.com> wrote:
>>
>>> Wang Chen wrote:
>>>>> So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
>>>>> 1.5.3.x)
>>>> My git version is 1.5.5.1, although it doesn't matter ;)
>>>>
>>> http transport requires that "git update-server-info" is done after
>>> each push. Otherwise, it ends up in a trainwreck.
>>
>> can i simply put "git update-server-info" into .git/hooks/post-receive
>> to solve this problem?
>>
>
> post-update, rather than post-receive.
>
> The standard post-update.sample contains it, it just needs a rename.
hm, -tip's .git/hooks/post-update already contained this, for the last 2
months:
exec git update-server-info
so ... _despite_ us having this in the git repo, the HTTP protocol still
does not work. Why?
Ingo
^ permalink raw reply
* [StGit PATCH 4/4] Tutorial: Write about rebasing
From: Karl Hasselström @ 2008-10-12 15:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081012150825.17648.3315.stgit@yoghurt>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/tutorial.txt | 84 +++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 83 insertions(+), 1 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 46c78cf..2808462 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -533,7 +533,89 @@ index e324179..6398958 100644
Rebasing a patch series
-----------------------
-TODO:: rebase, ...
+While you are busy writing, submitting, and revising your patch
+series, other people will be doing the same thing. As a result, even
+though you started writing your patches on top of what was the latest
+history at the time, your stack base will grow ever more out of date.
+
+When you clone a repository,
+
+ $ stg clone http://homepage.ntlworld.com/cmarinas/stgit.git stgit
+
+you initially get one local branch, +master+. You also get a number of
+'remote' branches, one for each branch in the repository you cloned.
+In the case of the StGit repository, these are
++remotes/origin/stable+, +remotes/origin/master+, and
++remotes/origin/proposed+. +remotes+ means that it's not a local
+branch, just a snapshot of a branch in another repository; and
++origin+ is the default name for the first remote repository (you can
+set up more; see the man page for +git remote+).
+
+Right after cloning, +master+ and +remotes/origin/master+ point at the
+same commit. When you start writing patches, +master+ will advance,
+and always point at the current topmost patch, but
++remotes/origin/master+ will stay the same because it represents the
+master branch in the repository you cloned from -- your 'upstream'
+repository.
+
+Unless you are the only one working on the project, however, the
+upstream repository will not stay the same forever. New commits will
+be added to its branches; to update your clone, run
+
+ $ git remote update
+
+This will update all your remote branches, but won't touch your local
+branches. To get the latest changes into your local +master+ branch,
+use stglink:rebase[]:
+
+ $ stg rebase remotes/origin/master
+
+This command will do three things:
+
+ 1. Pop all patches, so that your local branch (+master+, in this
+ example) points at the stack base. This is the same commit that
+ +remotes/origin/master+ pointed at at the time you started
+ writing your patches.
+
+ 2. Set the stack base to the given commit (the current, updated
+ value of +remotes/origin/master+).
+
+ 3. Push the patches that were popped in the first step.
+
+The end result is that your patches are now applied on top of the
+latest version of +remotes/origin/master+.
+
+The primary reason for rebasing is to reduce the amount of conflicts
+between your work and others'. If one of your patches changes the same
+part of the same file as a patch someone else has written, you will
+get a conflict when you run stglink:rebase[] the next time after the
+other person's patch has been accepted upstream. It is almost always
+less work to rebase often and resolve these one at a time, rather than
+a whole lot at once. After all, you have to rebase eventually; if you
+mail out patches that are based on an outdated branch, everyone who
+tries to apply them has to resolve the conflicts instead. There are
+more effective ways to get popular.
+
+
+When your patches are accepted
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If and when some or all of your patches are accepted upstream, you
+update and rebase just like usual -- but be sure to use the
++$$--merged$$+ flag to stglink:rebase[]:
+
+ $ git remote update
+ $ stg rebase --merged remotes/origin/master
+
+This flag makes the rebase operation better at detecting that your
+patches have been merged, at some cost in performance.
+
+The patches that had been merged will still be present in your patch
+stack after the rebase, but they will be empty, since the change they
+added is now already present in the stack base. Run stglink:clean[] to
+get rid of such empty patches if you don't want them hanging around:
+
+ $ stg clean
Importing patches
^ permalink raw reply related
* [StGit PATCH 3/4] Tutorial: Cover "stg mail"
From: Karl Hasselström @ 2008-10-12 15:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081012150825.17648.3315.stgit@yoghurt>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/tutorial.txt | 100 ++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 96 insertions(+), 4 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index e9d8b22..46c78cf 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -431,17 +431,109 @@ patches as patches.
Workflow: Tracking branch
=========================
+In the 'Development branch' workflow described above, we didn't have
+to worry about other people; we're working on our branch, they are
+presumably working on theirs, and when the time comes and we're ready
+to publish our branch, we'll probably end up merging our branch with
+those other peoples'. That's how Git is designed to work.
-Rebasing a patch series
------------------------
+Or rather, one of the ways Git is designed to work. An alternative,
+popular in e.g. the Linux kernel community (for which Git was
+originally created), is that contributors send their patches by e-mail
+to a mailing list. Others read the patches, try them out, and provide
+feedback; often, the patch author is asked to send a new and improved
+version of the patches. Once the project maintainer is satisfied that
+the patches are good, she'll 'apply' them to a branch and publish it.
-TODO:: rebase, ...
+StGit is ideally suited for the process of creating patches, mailing
+them out for review, revising them, mailing them off again, and
+eventually getting them accepted.
Getting patches upstream
------------------------
-TODO:: export, mail, ...
+We've already covered how to clone a Git repository and start writing
+patches. As for the next step, there are two commands you might use to
+get patches out of StGit: stglink:mail[] and stglink:export[].
+stglink:export[] will export your patches to a filesystem directory as
+one text file per patch, which can be useful if you are going to send
+the patches by something other than e-mail. Most of the time, though,
+stglink:mail[] is what you want.
+
+NOTE: Git comes with tools for sending commits via e-mail. Since StGit
+patches are Git commits, you can use the Git tools if you like them
+better for some reason.
+
+NOTE: For exporting single patches -- as opposed to a whole bunch of
+them -- you could also use stglink:show[] or stglink:diff[].
+
+Mailing a patch is as easy as this:
+
+ $ stg mail --to recipient@example.com <patches>
+
+You can list one or more patches, or ranges of patches. Each patch
+will be sent as a separate mail, with the first line of the commit
+message as subject line. Try mailing patches to yourself to see what
+the result looks like.
+
+NOTE: stglink:mail[] uses +sendmail+ on your computer to send the
+mails. If you don't have +sendmail+ properly set up, you can instruct
+it to use any SMTP server with the +$$--smtp-server$$+ flag.
+
+There are many command-line options to control exactly how mails are
+sent, as well as a message template you can modify if you want. The
+man page has all the details; I'll just mention two more here.
+
++$$--edit-cover$$+ will open an editor and let you write an
+introductory message; all the patch mails will then be sent as replies
+to this 'cover message'. This is usually a good idea if you send more
+than one patch, so that reviewers can get a quick overview of the
+patches you sent.
+
++$$--edit-patches$$+ will let you edit each patch before it is sent.
+You can change anything, but note that you are only editing the
+outgoing mail, not the patch itself; if you want to make changes to
+the patch, you probably want to use the regular StGit commands to do
+so. What this 'is' useful for, though, is to add notes for the patch
+recipients:
+
+----------------------------------------------------------------------
+From: Audrey U. Thor <author@example.com>
+Subject: [PATCH] First line of the commit message
+
+The rest of the commit message
+
+---
+
+Everything after the line with the three dashes and before the diff is
+just a comment, and not part of the commit message. If there's
+anything you want the patch recipients to see, but that shouldn't be
+recorded in the history if the patch is accepted, write it here.
+
+ stgit/main.py | 1 +
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+
+
+diff --git a/stgit/main.py b/stgit/main.py
+index e324179..6398958 100644
+--- a/stgit/main.py
++++ b/stgit/main.py
+@@ -171,6 +171,7 @@ def _main():
+ sys.exit(ret or utils.STGIT_SUCCESS)
+
+ def main():
++ print 'My first patch!'
+ try:
+ _main()
+ finally:
+----------------------------------------------------------------------
+
+
+Rebasing a patch series
+-----------------------
+
+TODO:: rebase, ...
Importing patches
^ permalink raw reply related
* [StGit PATCH 2/4] Tutorial: Explain diffs a little bit better
From: Karl Hasselström @ 2008-10-12 15:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081012150825.17648.3315.stgit@yoghurt>
Say that we use unified diffs, and point to the Wikipedia article
about them. We should probably explain this in more detail ourselves
when we get a proper user guide; but for the tutorial, this is
probably enough.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/tutorial.txt | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 103f3e4..e9d8b22 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -103,10 +103,11 @@ And voilà -- the patch is no longer empty:
_main()
finally:
-(I'm assuming you're already familiar with patches like this from Git,
-but it's really quite simple; in this example, I've added the +$$print
-'My first patch!'$$+ line to the file +stgit/main.py+, at around line
-171.)
+(I'm assuming you're already familiar with
+htmllink:http://en.wikipedia.org/wiki/Diff#Unified_format[unified
+diff] patches like this from Git, but it's really quite simple; in
+this example, I've added the +$$print 'My first patch!'$$+ line to the
+file +stgit/main.py+, at around line 171.)
Since the patch is also a regular Git commit, you can also look at it
with regular Git tools such as manlink:gitk[].
^ permalink raw reply related
* [StGit PATCH 1/4] Tutorial: Talk about conflicts when introducing StGit
From: Karl Hasselström @ 2008-10-12 15:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081012150825.17648.3315.stgit@yoghurt>
Conflicts and conflict resolving are essential features of StGit, so
we'd better tell the user about them.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/stg.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/stg.txt b/Documentation/stg.txt
index 5973a6b..fc8fd7c 100644
--- a/Documentation/stg.txt
+++ b/Documentation/stg.txt
@@ -38,6 +38,14 @@ to maintain a 'patch stack' on top of a Git branch:
an updated branch, you can take all your patches and apply them on
top of the updated branch.
+ * As you would expect, changing what is below a patch can cause that
+ patch to no longer apply cleanly -- this can occur when you
+ reorder patches, rebase patches, or refresh a non-topmost patch.
+ StGit uses Git's rename-aware three-way merge capability to
+ automatically fix up what it can; if it still fails, it lets you
+ manually resolve the conflict just like you would resolve a merge
+ conflict in Git.
+
* The patch stack is just some extra metadata attached to regular
Git commits, so you can continue to use most Git tools along with
StGit.
^ permalink raw reply related
* [StGit PATCH 0/4] More tutorial updates
From: Karl Hasselström @ 2008-10-12 15:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
More updates to the tutorial. I'd really appreciate if people would
sanity check these; a bad tutorial tends to reflect negatively on a
project.
---
Karl Hasselström (4):
Tutorial: Write about rebasing
Tutorial: Cover "stg mail"
Tutorial: Explain diffs a little bit better
Tutorial: Talk about conflicts when introducing StGit
Documentation/stg.txt | 8 ++
Documentation/tutorial.txt | 191 ++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 191 insertions(+), 8 deletions(-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 2/2 v2] check-attr: Add --stdin-paths option
From: Jakub Narebski @ 2008-10-12 15:04 UTC (permalink / raw)
To: git
In-Reply-To: <20081012141952.GD21650@dpotapov.dyndns.org>
Dmitry Potapov wrote:
>> And since its being
>> used mostly by automated tools (gitk/git-gui) I wonder if a -z should
>> also be supported for input termination with NUL instead of LF.
>
> I have added it, but after I did, I start to wonder whether it is the
> right thing to do to unquote NUL terminated input line?
I think that -z should be not quoted (like git-diff-tree or git-ls-tree
_output_); if it is, then IMHO it is a bug.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2 v2] check-attr: Add --stdin-paths option
From: Dmitry Potapov @ 2008-10-12 14:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Johannes Sixt, Alexander Gavrilov, git, Shawn O. Pearce
In-Reply-To: <18671.55733.970601.454074@cargo.ozlabs.ibm.com>
On Sat, Oct 11, 2008 at 09:39:49AM +1100, Paul Mackerras wrote:
>
> Actually, what was done with git diff-tree --stdin was to have it do
> fflush(stdout) when it sees a blank line in the input. That gives the
> calling program a way to get the output up to that point without
> having to do a flush for every line of output.
It is an interesting idea, but I have not seen any other git command
doing so, and my measurement in git repo on Linux have not offered
any noticeable speed-up. So, I am not sure if it is worth it.
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2 v2] check-attr: Add --stdin-paths option
From: Dmitry Potapov @ 2008-10-12 14:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Sixt, Alexander Gavrilov, git, Paul Mackerras
In-Reply-To: <20081008152443.GA4795@spearce.org>
On Wed, Oct 08, 2008 at 08:24:43AM -0700, Shawn O. Pearce wrote:
> Dmitry Potapov <dpotapov@gmail.com> wrote:
> > This allows multiple paths to be specified on stdin.
>
> > diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
> > index 2b821f2..0839a57 100644
> > --- a/Documentation/git-check-attr.txt
> > +++ b/Documentation/git-check-attr.txt
> > @@ -9,6 +9,7 @@ git-check-attr - Display gitattributes information.
> > SYNOPSIS
> > --------
> > 'git check-attr' attr... [--] pathname...
> > +'git check-attr' --stdin-paths attr... < <list-of-paths
>
> I wonder if the option should just be "--stdin".
I used "--stdin-paths" because git hash-object uses it, while "--stdin"
means to read the object from standard input. OTOH, we are never going
to read the object from standard input in check-attr and some other git
commands use "--stdin" to mean: read the list of paths from the standard
input. So, I fully agree here.
> And since its being
> used mostly by automated tools (gitk/git-gui) I wonder if a -z should
> also be supported for input termination with NUL instead of LF.
I have added it, but after I did, I start to wonder whether it is the
right thing to do to unquote NUL terminated input line?
NUL terminated makes sense when you feed raw-bytes, and if the first
byte happen to be a quote character, I suppose it should be treated
just as any other byte, not as a sign that the string is quited. But
then I looked at git checkout-index, and it unquotes string even if it
is NUL terminated. I don't think it is the right thing to do, but just
to be consistent, I have decided to leave as-is, i.e. to unquote a NUL
terminated string.
> > +test_expect_success 'attribute test: read paths from stdin' '
>
> A test case for the quoting might also be good.
As far as I can tell, there is no test case for special characters in
filenames when these filenames are given as arguments. And there are a
few problems with them. First, it is using colon as a separator in
output, which breaks parsing of a filename containing colons. Second,
I still have not figured out how to specify filenames with special
characters in gitattributes. The documentation does not say anything
and was lazy to study the code. Does gitattributes understand quote
strings in filenames?
Anyway, here is interdiff to my previous patch, which addresses two
first points as I described above. (I can resend the full patch if
necessary).
-- >8 --
From: Dmitry Potapov <dpotapov@gmail.com>
Date: Sun, 12 Oct 2008 18:08:43 +0400
Subject: [PATCH] check-attr: Add --stdin option
---
Documentation/git-check-attr.txt | 8 ++++++--
builtin-check-attr.c | 13 +++++++++----
t/t0003-attributes.sh | 2 +-
3 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
index 0839a57..14e4374 100644
--- a/Documentation/git-check-attr.txt
+++ b/Documentation/git-check-attr.txt
@@ -9,7 +9,7 @@ git-check-attr - Display gitattributes information.
SYNOPSIS
--------
'git check-attr' attr... [--] pathname...
-'git check-attr' --stdin-paths attr... < <list-of-paths
+'git check-attr' --stdin [-z] attr... < <list-of-paths
DESCRIPTION
-----------
@@ -18,9 +18,13 @@ For every pathname, this command will list if each attr is 'unspecified',
OPTIONS
-------
---stdin-paths::
+--stdin::
Read file names from stdin instead of from the command-line.
+-z::
+ Only meaningful with `--stdin`; paths are separated with
+ NUL character instead of LF.
+
\--::
Interpret all preceding arguments as attributes, and all following
arguments as path names. If not supplied, only the first argument will
diff --git a/builtin-check-attr.c b/builtin-check-attr.c
index fa1e4d5..02a8292 100644
--- a/builtin-check-attr.c
+++ b/builtin-check-attr.c
@@ -7,12 +7,16 @@
static int stdin_paths;
static const char * const check_attr_usage[] = {
"git check-attr attr... [--] pathname...",
-"git check-attr --stdin-paths attr... < <list-of-paths>",
+"git check-attr --stdin attr... < <list-of-paths>",
NULL
};
+static int null_term_line;
+
static const struct option check_attr_options[] = {
- OPT_BOOLEAN(0 , "stdin-paths", &stdin_paths, "read file names from stdin"),
+ OPT_BOOLEAN(0 , "stdin", &stdin_paths, "read file names from stdin"),
+ OPT_BOOLEAN('z', NULL, &null_term_line,
+ "input paths are terminated by a null character"),
OPT_END()
};
@@ -41,10 +45,11 @@ static void check_attr_stdin_paths(int cnt, struct git_attr_check *check,
const char** name)
{
struct strbuf buf, nbuf;
+ int line_termination = null_term_line ? 0 : '\n';
strbuf_init(&buf, 0);
strbuf_init(&nbuf, 0);
- while (strbuf_getline(&buf, stdin, '\n') != EOF) {
+ while (strbuf_getline(&buf, stdin, line_termination) != EOF) {
if (buf.buf[0] == '"') {
strbuf_reset(&nbuf);
if (unquote_c_style(&nbuf, buf.buf, NULL))
@@ -90,7 +95,7 @@ int cmd_check_attr(int argc, const char **argv, const char *prefix)
if (cnt <= 0)
errstr = "No attribute specified";
else if (stdin_paths && doubledash < argc)
- errstr = "Can't specify files with --stdin-paths";
+ errstr = "Can't specify files with --stdin";
if (errstr) {
error (errstr);
usage_with_options(check_attr_usage, check_attr_options);
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index f6901b4..1c77192 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -60,7 +60,7 @@ a/b/h: test: a/b/h
a/b/d/g: test: a/b/d/*
EOF
- sed -e "s/:.*//" < expect | git check-attr --stdin-paths test > actual &&
+ sed -e "s/:.*//" < expect | git check-attr --stdin test > actual &&
test_cmp expect actual
'
--
1.6.0.2.521.g49aa8.dirty
-- >8 --
^ permalink raw reply related
* Re: tip tree clone fail
From: H. Peter Anvin @ 2008-10-12 14:15 UTC (permalink / raw)
To: Wang Chen
Cc: Thomas Gleixner, Ingo Molnar, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48F1DF6A.4000900@cn.fujitsu.com>
Wang Chen wrote:
>
> So, the current solutions are:
> 1. Waiting for Shawn fixing it.
> 2. Asking Ingo to "git update-server-info" after each push.
> 3. Murdering our IT people.
>
> I'd rather to do the second solution than the third one :)
>
Actually, the third solution is the proper one given the circumstances
you find yourself in. None of this would be a problem if there wasn't a
bunch of companies with incompetent network management.
-hpa
^ 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