* Re: "git diff --stat" doesn't show added empty file
From: Johannes Schindelin @ 2009-01-13 11:27 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Ping Yin, Git Mailing List
In-Reply-To: <496B64BA.7000408@drmicha.warpmail.net>
Hi,
On Mon, 12 Jan 2009, Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 01/12/09 13:19:
>
> > On Mon, 12 Jan 2009, Ping Yin wrote:
> >
> >> $ git --version
> >> git version 1.6.1.9.g97c34
> >> $ mkdir test && cd test && git init && git commit --allow-empty -m
> >> "Initial commit"
> >> $ touch .gitignore && git add .gitignore && git commit -m "Add empty .gitignore"
> >> $ git diff --stat HEAD^..
> >> 0 files changed, 0 insertions(+), 0 deletions(-)
> >>
> >> May be the following is better?
> >>
> >> .gitignore | 0 +
> >> 1 files changed, 0 insertions(+), 0 deletions(-)
> >
> > Have fun coding that.
>
> Removing 5 lines from diff.c does the job,
I can only think that you mean these lines:
else if (!data->files[i]->is_renamed &&
(added + deleted == 0)) {
total_files--;
continue;
}
However, they are also present in the initial stat code in d75f7952:
} else if (added + deleted == 0) {
total_files--;
continue;
}
Now, the fun part is finding out why this code is there. Are there
unintended side effects? If so, are they still there? Or was it
introduced due to an explicit request back then? Was it just sloppy?
Removing the 5 lines is not all you have to do, by _far_.
Lots of fun,
Dscho
^ permalink raw reply
* Re: how to combine 2 commits?
From: Stephen R. van den Berg @ 2009-01-13 11:20 UTC (permalink / raw)
To: git
In-Reply-To: <20090113075121.GA6923@b2j>
bill lam wrote:
>BTW, what is the norm of reply in this list, should it be reply to
>list only, or reply to group (list plus all cc)?
This list prefers list plus all cc.
--
Sincerely,
Stephen R. van den Berg.
"I have a *cunning* plan!"
^ permalink raw reply
* Re: git/webdav is refusing to authenticate properly.
From: Johannes Schindelin @ 2009-01-13 11:11 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Peter Spierenburg, git
In-Reply-To: <200901121953.16183.bss@iguanasuicide.net>
Hi,
On Mon, 12 Jan 2009, Boyd Stephen Smith Jr. wrote:
> On Monday 12 January 2009, Peter Spierenburg
> <ionlyusethisaddressforlists@gmail.com> wrote
>
> >C'mon, leave my password 'in-the-clear', in a text file on a networked
> >box? That is the kind of prank a fourth-year student would try to pull
> >on a freshman.
> >
> >How do I really do it?
>
> AFAIK, that's the only way for now.
Indeed it is.
> Personally, I'd welcome a patch that allowed fetch/push to prompt the
> user for a password, but I'm not holding my breath.
I guess everybody who wants that feature does exactly the same as you.
Oh, and FWIW: trying to ridicule the way Git does it completely misses the
fact that you are using such a ridiculously weak authentication scheme
anyway that you could just as well open the window and shout your password
out loud.
Ciao,
Dscho
P.S.: real security would require you to have public/private key based
client authentication. But that would leave you vulnerable, too, as you
are apparently not on a trustable machine.
P.P.S.: I have access to such a machine, too, but I never push _from_
there. That is relatively safe, as only those can access my private keys
(and my $HOME/.netrc, BTW, as you seemed to have missed .netrc's 0600
mode) can impersonate me without hassle using sudo anyway.
^ permalink raw reply
* [TopGit PATCH] depend: don't check for tg branch
From: Thomas Rast @ 2009-01-13 11:05 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
Remove the check in 'tg depend add <branch>' that <branch> is
topgit-tracked, as it seems inconsistent with the use of 'tg create
<branch> <dependencies>', where the <dependencies> can be arbitrary.
This is useful to, e.g., promote a git.git topic branch from
master-based to next-based.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
tg-depend.sh | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/tg-depend.sh b/tg-depend.sh
index ef5f94f..16b7751 100644
--- a/tg-depend.sh
+++ b/tg-depend.sh
@@ -37,8 +37,6 @@ done
[ -n "$name" ] || die "no branch name specified"
branchrev="$(git rev-parse --verify "$name" 2>/dev/null)" ||
die "invalid branch name: $name"
-baserev="$(git rev-parse --verify "refs/top-bases/$name" 2>/dev/null)" ||
- die "not a TopGit topic branch: $name"
## Record new dependency
--
tg: (3c70506..) t/depend-no-base-check (depends on: master)
^ permalink raw reply related
* Re: git-patches list?
From: Johannes Schindelin @ 2009-01-13 11:02 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Akira Kitada, git
In-Reply-To: <496C502A.3070908@op5.se>
Hi,
On Tue, 13 Jan 2009, Andreas Ericsson wrote:
> Junio C Hamano wrote:
> > Akira Kitada <akitada@gmail.com> writes:
> >
> > > Can I propose having another mailing list for posting patches to avoid
> > > daily mail flood to this list?
> > >
> > > Yes, I can filter out the emails but still...
> >
> > This list has always been the only place where git development happens.
> > It would make the development very awkward to set up another list only for
> > patches, forbid patches to be sent to anywhere but that new list, but
> > still discuss the patches on this list.
> >
> > It does not make much sense to me.
> >
>
> I agree.
>
> If any new list is to be introduced, it would only make sense to make it
> a read-only "what's new" list, for the various people that want to know
> what might break/be fixed in new versions but really don't care about the
> discussion that lead to that decision.
If that's what you want, I suggest having a look at
http://gitrss.q42.co.uk/
I am sure that Julian can be convinced to filter "[PATCH", too.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH,v2] contrib/examples/README: give an explanation of the status of these files
From: Thomas Adam @ 2009-01-13 10:01 UTC (permalink / raw)
To: jidanni; +Cc: gitster, git
In-Reply-To: <877i50ovdd.fsf_-_@jidanni.org>
2009/1/13 <jidanni@jidanni.org>:
> @@ -0,0 +1,3 @@
> +These are original scripted implementations, kept primarily for their
> +reference value to any aspiring plumbing users who want to learn how
> +pieces can be fit together.
"... who want to learn how the pieces fit together" is the correct
phrasing. The above is incorrect.
-- Thomas Adam
^ permalink raw reply
* Re: How to pull remote branch with specified commit id?
From: Johannes Sixt @ 2009-01-13 9:43 UTC (permalink / raw)
To: Emily Ren; +Cc: Git Mailinglist
In-Reply-To: <856bfe0e0901130108q3af1345cy31751dd09e030c96@mail.gmail.com>
Emily Ren schrieb:
> Git experts,
>
> I want to pull remote branch with specified commit id, how to do it?
>
> Below command can get remote branch
> $git pull remote refs/heads/$branch_name
>
> Below command doesn't work
> $git pull remote objects/$commit_id
You can't, and that is so by design.
Consider this: You accidentally push a branch with confidential data to a
public repository. You notice it early, and quickly delete the branch
using 'git push the-repo :refs/heads/that-branch'. At this time the
objects with the confidential data are still lingering in the public
repository. But with the current behavior noone can access them even if
the SHA1 happens to be known.
-- Hannes
^ permalink raw reply
* Re: [BUG PATCH RFC] mailinfo: correctly handle multiline 'Subject:' header
From: Kirill Smelkov @ 2009-01-13 9:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Potashev, git
In-Reply-To: <7v63kkgl5b.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 12, 2009 at 03:27:44PM -0800, Junio C Hamano wrote:
> Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
>
> > diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
> > index f7c8c08..6d72c1b 100644
> > --- a/builtin-mailinfo.c
> > +++ b/builtin-mailinfo.c
> > @@ -860,6 +860,7 @@ static void handle_info(void)
> > }
> > output_header_lines(fout, "Subject", hdr);
> > } else if (!memcmp(header[i], "From", 4)) {
> > + cleanup_space(hdr);
> > handle_from(hdr);
> > fprintf(fout, "Author: %s\n", name.buf);
> > fprintf(fout, "Email: %s\n", email.buf);
> > diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
> > index 4bf7947..d465685 100644
> > --- a/t/t5100/sample.mbox
> > +++ b/t/t5100/sample.mbox
> > @@ -2,7 +2,10 @@
> >
> >
> > From nobody Mon Sep 17 00:00:00 2001
> > -From: A U Thor <a.u.thor@example.com>
> > +From: A
> > + U
> > + Thor
> > + <a.u.thor@example.com>
> > Date: Fri, 9 Jun 2006 00:44:16 -0700
> > Subject: [PATCH] a commit.
>
> I think this is a reasonable change.
Thanks.
> But doesn't this
>
> > From nobody Mon Sep 17 00:00:00 2001
> > -From: A
> > +From: A (zzz)
> > U
> > Thor
> > - <a.u.thor@example.com>
> > + <a.u.thor@example.com> (Comment)
>
> regress for people who spell their names like this?
>
> From: john.doe@email.xz (John Doe)
I think everything is ok:
There is an explicit handler for such emails before my comments removal
in builtin-mailinfo.c:
/* The remainder is name. It could be "John Doe <john.doe@xz>"
* or "john.doe@xz (John Doe)", but we have removed the
* email part, so trim from both ends, possibly removing
* the () pair at the end.
*/
strbuf_trim(&f);
if (f.buf[0] == '(' && f.len && f.buf[f.len - 1] == ')') {
strbuf_remove(&f, 0, 1);
strbuf_setlen(&f, f.len - 1);
}
http://repo.or.cz/w/git.git?a=blob;f=builtin-mailinfo.c;h=f7c8c08b320c99d8bf96443ae57aa33c1de7e8c0;hb=HEAD#l112
And only a test for this is missing
From 77316ad6db2c3b0f4be238c4ba855b2f785b50d6 Mon Sep 17 00:00:00 2001
From: Kirill Smelkov <kirr@mns.spb.ru>
Date: Tue, 13 Jan 2009 12:33:48 +0300
Subject: [PATCH] mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
---
t/t5100-mailinfo.sh | 2 +-
t/t5100/info0013 | 5 +++++
t/t5100/sample.mbox | 5 +++++
3 files changed, 11 insertions(+), 1 deletions(-)
create mode 100644 t/t5100/info0013
create mode 100644 t/t5100/msg0013
create mode 100644 t/t5100/patch0013
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index 625c204..e70ea94 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -11,7 +11,7 @@ test_expect_success 'split sample box' \
'git mailsplit -o. "$TEST_DIRECTORY"/t5100/sample.mbox >last &&
last=`cat last` &&
echo total is $last &&
- test `cat last` = 12'
+ test `cat last` = 13'
for mail in `echo 00*`
do
diff --git a/t/t5100/info0013 b/t/t5100/info0013
new file mode 100644
index 0000000..bbe049e
--- /dev/null
+++ b/t/t5100/info0013
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.thor@example.com
+Subject: a patch
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/msg0013 b/t/t5100/msg0013
new file mode 100644
index 0000000..e69de29
diff --git a/t/t5100/patch0013 b/t/t5100/patch0013
new file mode 100644
index 0000000..e69de29
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 4f80b82..c5ad206 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -556,3 +556,8 @@ index 3fd3afb..0ee807e 100644
#. п╫п╟ я│п╡п╬п╣п╧ п╪п╟я┬п╦п╫п╣: п╬я┌я─п╣п╢п╟п╨я┌п╦я─п╬п╡п╟я┌я▄ /etc/sudoers (п╨п╬п╪п╟п╫п╢п╟ ``visudo``) п©я─п╦п╪п╣я─п╫п╬ я│п╩п╣п╢я┐я▌я┴п╦п╪ п╬п╠я─п╟п╥п╬п╪::
--
1.5.6.5
+From nobody Mon Sep 17 00:00:00 2001
+From: <a.u.thor@example.com> (A U Thor)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+Subject: [PATCH] a patch
+
--
1.6.1.101.g0335
^ permalink raw reply related
* Re: [PATCH] Teach format-patch to handle output directory relative to cwd
From: Cesar Eduardo Barros @ 2009-01-13 9:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmydwf2a9.fsf@gitster.siamese.dyndns.org>
Junio C Hamano escreveu:
> Cesar Eduardo Barros <cesarb@cesarb.net> writes:
>
>> Works great, only the resulting output to the screen is a bit
>> ugly/confusing:
>>
>> drivers/net/../../../0001-sc92031-more-useful-banner-in-kernel-log.patch
>> ...
>> (after all, I am still inside the drivers/net directory)
>
> Fair enough. Here is a replacement diff.
Works fine, thanks.
--
Cesar Eduardo Barros
cesarb@cesarb.net
cesar.barros@gmail.com
^ permalink raw reply
* Re: [PATCH] Fix Documentation typos surrounding the word 'handful'.
From: Junio C Hamano @ 2009-01-13 9:24 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <1231790527-7515-1-git-send-email-jdl@freescale.com>
Thanks, applied with fix from Markus and Sam.
^ permalink raw reply
* Re: [PATCH next] notes: fix core.notesRef documentation
From: Junio C Hamano @ 2009-01-13 9:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, git
In-Reply-To: <alpine.DEB.1.00.0901121541210.3586@pacific.mpi-cbg.de>
Thanks, queued.
^ permalink raw reply
* Re: How to pull remote branch with specified commit id?
From: Andreas Ericsson @ 2009-01-13 9:16 UTC (permalink / raw)
To: Emily Ren; +Cc: Git Mailinglist
In-Reply-To: <856bfe0e0901130108q3af1345cy31751dd09e030c96@mail.gmail.com>
Emily Ren wrote:
> Git experts,
>
> I want to pull remote branch with specified commit id, how to do it?
>
> Below command can get remote branch
> $git pull remote refs/heads/$branch_name
>
> Below command doesn't work
> $git pull remote objects/$commit_id
>
You need to fetch it first, and then merge the commit you want. The
tools operating the fetching protocol only use refs, so if you want
to fetch (or pull) a specific version that has neither a tag nor a
branch head pointing to it, you'll have to write a new tool for that.
The end-result of the following command will be, barring side-effects
in the remote-tracking branches, identical to what you're trying to
do though:
git fetch remote && git merge $commit_id
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* How to pull remote branch with specified commit id?
From: Emily Ren @ 2009-01-13 9:08 UTC (permalink / raw)
To: Git Mailinglist
Git experts,
I want to pull remote branch with specified commit id, how to do it?
Below command can get remote branch
$git pull remote refs/heads/$branch_name
Below command doesn't work
$git pull remote objects/$commit_id
Thanks,
Emily
^ permalink raw reply
* Re: [PATCH/RFC] Documentation/SubmittingPatches: emacs whitespace tip
From: Junio C Hamano @ 2009-01-13 8:28 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87k58zopg5.fsf@jidanni.org>
jidanni@jidanni.org writes:
> Signed-off-by: jidanni <jidanni@jidanni.org>
> ---
> Documentation/SubmittingPatches | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index ba07c8c..7b64343 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -442,6 +442,8 @@ whitespaces (fatal in patches). Running 'C-u g' to display the
> message in raw form before using '|' to run the pipe can work
> this problem around.
>
> +Inside gnus or not, a (setq-default show-trailing-whitespace t) in
> +one's ~/.emacs file will reduce whitespace embarrassment incidents.
What bothered me a lot more is that this part (and only this part) talks
about patch acceptance tip, not patch submission tip. The Gnus/Emacs
section needs a total rewrite, I think.
Having a separate patch acceptance tip is fine, but I do not think it
belongs to SubmittingPatches document, and the current text certainly does
not mesh well with its neighbours.
^ permalink raw reply
* Re: [PATCH] gitweb: recognize six digit abbreviated SHA1
From: Junio C Hamano @ 2009-01-13 8:26 UTC (permalink / raw)
To: Sam Vilain; +Cc: Anders Melchiorsen, git, jnareb
In-Reply-To: <496BF5D7.2090003@vilain.net>
Sam Vilain <sam@vilain.net> writes:
> I think if you're going to go so short as 6 digits, it's probably worth
> making sure that the really short SHA1s check commits only. eg, if
> you've got a commit 'fa023473' and a tree 'fa023421', then 'fa0234'
> should match the commit and not the tree. But I don't think there's a
> plumbing way to do a query like that at the moment.
When people give an abbreviated object name, 99% of the time they mean
commits (and "index deadbeef..acebead" in a patch is a good place to pick
blob object names from, which would be what the 99% of the remaining 1%
would name), so making sure it is a commit or a blob would be a very
sensible thing to do.
Unfortunately, you fundamentally cannot do this without taking a
performance hit of actually opening the object.
^ permalink raw reply
* Re: git-patches list?
From: Andreas Ericsson @ 2009-01-13 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Akira Kitada, git
In-Reply-To: <7vr638f5ch.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Akira Kitada <akitada@gmail.com> writes:
>
>> Can I propose having another mailing list for posting patches to avoid
>> daily mail flood to this list?
>>
>> Yes, I can filter out the emails but still...
>
> This list has always been the only place where git development happens.
> It would make the development very awkward to set up another list only for
> patches, forbid patches to be sent to anywhere but that new list, but
> still discuss the patches on this list.
>
> It does not make much sense to me.
>
I agree.
If any new list is to be introduced, it would only make sense to make it
a read-only "what's new" list, for the various people that want to know
what might break/be fixed in new versions but really don't care about the
discussion that lead to that decision.
Is that what you were after, Akira?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Avoid spurious error messages on error mistakes.
From: Junio C Hamano @ 2009-01-13 8:20 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1231801776-20724-1-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> Prior to that, if the user chose "squash" as a first action, the stderr
> looked like:
>
> grep: /home/madcoder/dev/scm/git/.git/rebase-merge/done: No such file or directory
> Cannot 'squash' without a previous commit
>
> Now the first line is gone.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> git-rebase--interactive.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index c8b0861..8ed2244 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -349,7 +349,7 @@ do_next () {
> squash|s)
> comment_for_reflog squash
>
> - has_action "$DONE" ||
> + test -f "$DONE" && has_action "$DONE" ||
> die "Cannot 'squash' without a previous commit"
>
> mark_action_done
> --
> 1.6.1.161.g5e07b.dirty
Make sense. Will apply to maint.
^ permalink raw reply
* Re: [PATCH 2/2] grep: don't call regexec() for fixed strings
From: Junio C Hamano @ 2009-01-13 8:13 UTC (permalink / raw)
To: René Scharfe; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <496B9780.3030000@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> +#define RR GIT_REGEX_SPECIAL /* $, (, ), +, ., ^, {, | */
> +#define US GIT_UNDERSCORE
> +#define Ah (GIT_ALPHA | GIT_LOWER_XDIGIT)
>
> unsigned char sane_ctype[256] = {
> GS, 0, 0, 0, 0, 0, 0, 0, 0, SS, SS, 0, 0, SS, 0, 0, /* 0-15 */
Mental note. NUL is marked as GIT_SPECIAL.
> #define isspecial(x) sane_istest(x,GIT_SPECIAL)
> +#define isregexspecial(x) sane_istest(x,GIT_SPECIAL | GIT_REGEX_SPECIAL)
Perhaps isspecial() is misnamed if we were to enhance git-ctype in this
way. It is about a byte being shell glob pattern or a NUL (!!!), and it
should be renamed to isglobspecial() or something.
dir.c uses isspecial() in two places, and both callers rely on NUL being a
part of special to terminate the loops they are in, like this:
for (;;) {
unsigned char c = *match++;
len++;
if (isspecial(c))
return len;
}
It may be a cunning and cute logic, but I do not particularly like it. It
might be cleaner to rename it to isglobspecial(), drop NUL from it, and
have these two call existing call sites to explicitly check for (c == NUL)
for loop termination.
^ permalink raw reply
* Re: [PATCH] contrib/vim: change URL to point to the latest syntax files
From: Junio C Hamano @ 2009-01-13 8:06 UTC (permalink / raw)
To: Jeff King; +Cc: Markus Heidelberg, git
In-Reply-To: <20090113071623.GB12631@coredump.intra.peff.net>
Thanks, both.
^ permalink raw reply
* Re: [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Junio C Hamano @ 2009-01-13 8:01 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Boyd Stephen Smith Jr., Shawn O. Pearce, git
In-Reply-To: <496C1D90.1020609@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> writes:
> An alternative (to a Vim modeline) is to put
>
> #!bash
I actually like this much better than "# vim:" thing.
It talks about WHAT the file is ("It is a bash scriptlet"), as opposed to
"# vim:" that tells HOW one user wants to edit the file ("with this
settings I use vim to edit this file"). In case somebody misunderstood
me, my "Yuck" was not about Emacs vs vi holy war. [*1*].
As people noted, it may not have any meaning to the shell, but it serves
as an important documentation to humans. As the maintainer, I try to be
reasonably strict about keeping our shell scripts free of bash-ism to help
people on platforms without bash, but this file is about bash (and bash
only). We are free to use all bash-isms we usually try to stay away from
in our scripts marked with #!/bin/sh (namely, "local", "let", shell
arrays, and substitutions outside POSIX such as ${parameter:offset:length}
substring, ${#parameter} length, and ${parameter/pattern/string} regexp
replacement), as long as they are compatible across recent bash versions.
If tools like vim notice the same hint that says "this is bash" and
adjusts its behaviour accordingly, that is great.
Even though I've grown to know Shawn well enough to be able to tell that
certain kinds of changes would get his Ack and often apply patches myself
without waiting him to give his Ack, the completion script is ultimately
his code and you do not necessarily have to make me like it.
Your updated patch still had [ $# -eq 0 -o -z "$1" ] even though the
commit log message (which is not the place to describe changes between v1
and v2 submissions, by the way) claimed that you replaced them with
"${1-}". I am guessing it would need at least one more iteration to clean
up, but I think this patch is improving _provided if_ supporting "set -u"
in the user's interactive environment is a good idea to begin with.
I just hope that next person who complains about bash completion scripts
would not say that he has "set -e" in his interactive environment ;-) I
personally consider that "set -u" is equally silly, but it probably is
just me.
[Footnote]
*1* For the same reason, Local Variables section to please Emacs is
equally offending; it tends to be much bigger which is even worse.
^ permalink raw reply
* Re: [PATCH] contrib/vim: change URL to point to the latest syntax files
From: Jeff King @ 2009-01-13 7:56 UTC (permalink / raw)
To: Teemu Likonen; +Cc: Markus Heidelberg, git
In-Reply-To: <8763kjej3p.fsf@iki.fi>
On Tue, Jan 13, 2009 at 09:54:50AM +0200, Teemu Likonen wrote:
> Vim is essentially just a one-man project and the maintainer doesn't use
> version control system. He just piles "diff -c" -type patches on top of
> the previous release and sends them to vim-dev mailing list and to some
> FTP site. Then other people try to maintain VCS repositories based on
> the patches and resources that are available.
>
> Vim's bus factor: 1
Ah. He should use git. ;)
Thanks for the explanation.
-Peff
^ permalink raw reply
* Re: [PATCH] contrib/vim: change URL to point to the latest syntax files
From: Teemu Likonen @ 2009-01-13 7:54 UTC (permalink / raw)
To: Jeff King; +Cc: Markus Heidelberg, git
In-Reply-To: <20090113071623.GB12631@coredump.intra.peff.net>
Jeff King (2009-01-13 02:16 -0500) wrote:
> On Tue, Jan 13, 2009 at 03:10:26AM +0100, Markus Heidelberg wrote:
>
>> Vim's SVN repository doesn't offer the latest runtime files, since
>> normally they are only updated there on a release. Though currently
>> there is no difference between the SVN and HTTP/FTP version of the
>> git syntax files.
>
> So their version control _doesn't_ have the latest version, but it is
> available on the website? It's not that I don't believe you, but I
> don't think I want to know the version control workflow that leads to
> that.
Vim is essentially just a one-man project and the maintainer doesn't use
version control system. He just piles "diff -c" -type patches on top of
the previous release and sends them to vim-dev mailing list and to some
FTP site. Then other people try to maintain VCS repositories based on
the patches and resources that are available.
Vim's bus factor: 1
^ permalink raw reply
* Re: how to combine 2 commits?
From: bill lam @ 2009-01-13 7:51 UTC (permalink / raw)
To: git
In-Reply-To: <200901122327.21102.bss@iguanasuicide.net>
On Mon, 12 Jan 2009, Boyd Stephen Smith Jr. wrote:
> git rebase --interactive (read "git help rebase" first)
I tried rebase the last 3 commit, but it failed.
bill@b2j:jproject$ git log --pretty=oneline | head
39ed365c11391bede0e1b6578adfac6619b78c0a for yajpp to use unix LF
70c812db2439bc84a8dd7ea831067b9ebf29885c revert last crlf error
f338a768d635b868e6fddaae670ad91d46ea7c4e format scripts
bill@b2j:jproject$ git rebase -i HEAD~3
error: Entry 'trunk/jcalc/mmenu-mm.ijs' not uptodate. Cannot merge.
fatal: merging of trees a1eafe6cdbb428f851d6ca878bbc53149fb7e7eb and
a00e6dcd3ec3f4ffde0d1aad1958db724093de69 failed
Could not apply 70c812d... revert last crlf error
It looks like cannot resolve conflict of linefeed changes. It was
expected all scripts will conflict, so I have to abort the rebase.
What is the procedure to generate a patch of the HEAD from HEAD~4,
then cancel all changes from HEAD~3 up to HEAD, and then apply the
patch to the previous HEAD~4 ?
BTW, what is the norm of reply in this list, should it be reply to
list only, or reply to group (list plus all cc)?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩213 李商隱 無題二首之二
颯颯東風細雨來 芙蓉塘外有輕雷 金蟾齧璅燒香入 玉虎牽絲汲井迴
賈氏窺簾韓掾少 宓妃留枕魏王才 春心莫共花爭發 一寸想思一寸灰
^ permalink raw reply
* Re: "git diff --stat" doesn't show added empty file
From: Ping Yin @ 2009-01-13 7:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0901120805310.6528@localhost.localdomain>
On Tue, Jan 13, 2009 at 12:13 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 12 Jan 2009, Ping Yin wrote:
>> $ git diff --stat HEAD^..
>> 0 files changed, 0 insertions(+), 0 deletions(-)
>
> In the kernel, we use "git diff --stat --summary" for exactly this reason.
>
> Well, not exactly.
>
> The thing is, even if the file is _not_ empty, there's a huge difference
> between "added 100 lines to an already-existing file" and "created a new
> 100-line file". Which is exactly what "--summary" adds.
>
> And it sometimes even makes sense to show the summary without the
> diffstat. If you're _only_ interested in create/delete/rename information,
> you can do "git show --summary <cmit>". It won't give you line counts, but
> it will give you information about any changes to filenames, eg in the
> kernel archive, you could see an example of this with
>
> git show -M --summary 95b482a8d31116f3f5c2a5089569393234d06385
>
> where you have a combination of renames, creates and deletes.
>
> So I think it's already better than what you ask for.
>
> Linus
>
Thanks. --summary works.
I just want to get all changed files. I think "git diff --name-status
A..B" should be better.
Ping Yin
^ permalink raw reply
* Re: [PATCH] contrib/vim: change URL to point to the latest syntax files
From: Jeff King @ 2009-01-13 7:16 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: git
In-Reply-To: <200901130310.26727.markus.heidelberg@web.de>
On Tue, Jan 13, 2009 at 03:10:26AM +0100, Markus Heidelberg wrote:
> Vim's SVN repository doesn't offer the latest runtime files, since
> normally they are only updated there on a release. Though currently
> there is no difference between the SVN and HTTP/FTP version of the git
> syntax files.
So their version control _doesn't_ have the latest version, but it is
available on the website? It's not that I don't believe you, but I don't
think I want to know the version control workflow that leads to that.
> - http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitsendemail.vim
> + http://ftp.vim.org/pub/vim/runtime/syntax/git.vim
Certainly they are nicer looking URLs, and I had just assumed the
originals would be recent-ish version. So:
Acked-by: Jeff King <peff@peff.net>
-Peff
^ 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