* Re: bisect: "Needed a single revision" message is confusing
From: Michael J Gruber @ 2012-11-02 14:10 UTC (permalink / raw)
To: Daniel Bonniot; +Cc: git
In-Reply-To: <CAO5QaZkZYxvSYoAQGgrrH1ULM8rnwX5=0Ln-_zfh8OwdegNNoA@mail.gmail.com>
Daniel Bonniot venit, vidit, dixit 02.11.2012 14:23:
> Hi,
>
> Suppose I'm doing a git bisect, say:
>
> $ git bisect good 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0
>
> That works fine. The sha1 could also be a substring, as long as it's
> unambiguous, e.g.:
>
> $ git bisect good 8c7a786b6c
>
> Now if it's ambiguous, I get an error message:
>
> $ git bisect good 8
> fatal: Needed a single revision
> Bad rev input: 8
>
> All fine and good. But what if I somehow input a non-existing sha1 (in
> my case see [1]), e,g:
>
> $ git bisect good 8c7a786b6c8eae8eac91083cdc9a6e337bc133b1
> fatal: Needed a single revision
> Bad rev input: 8c7a786b6c8eae8eac91083cdc9a6e337bc133b1
>
> I understand that technically both "no revision" and "multiple
> revisions" qualify as "not a single revision", but they correspond to
> quite different situations. I think it would be more helpful to get
> different error messages, something like:
>
> Bad rev input: 8 refers to multiple revisions
> Bad rev input: 8c7a786b6c8eae8eac91083cdc9a6e337bc133b1 does not refer
> to a valid revision
>
> (and avoid outputing the "fatal: Needed a single revision" message).
>
> Is this a good idea? Anybody can think of better error messages?
>
> I'm not familiar with the code base at all, but I could give a try at
> implementing it, unless it's trivial enough that someone does it
> earlier. After a quick look, it looks like either git-bisect itself or
> rev-parse would need to be touched, any pointers and hints welcome.
>
> Cheers,
>
> Daniel
>
> [1] if you want to know, I got a sha1 from one repository and used it
> in another, which probably should work, except that when using git-svn
> they don't. And the "single revision" error message lead me on a
> tangent.
>
The error comes from rev-parse, which is called by bisect. The problem
is that
git rev-parse deadbeef
git rev-parse --verify deadbeef
give two very different error messages (if there's no dead beef there),
and that "git ref-parse --verify" gives the same error message for
non-existing as for ambiguous revs.
There are 3 places in builtins/rev-parse.c which call
die_no_single_rev(), and at least some of them should probably choose
the error message more carefully.
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH v4 04/14] Add new simplified git-remote-testgit
From: Jeff King @ 2012-11-02 14:00 UTC (permalink / raw)
To: Stefano Lattarini
Cc: Felipe Contreras, git, Junio C Hamano, Johannes Schindelin,
Elijah Newren, Ilari Liusvaara, Sverre Rabbelier
In-Reply-To: <5093D0DD.3050801@gmail.com>
On Fri, Nov 02, 2012 at 02:55:41PM +0100, Stefano Lattarini wrote:
> > --- /dev/null
> > +++ b/git-remote-testgit
> > @@ -0,0 +1,62 @@
> > +#!/bin/bash
> >
> I think git can't assume the existence of bash unconditionally, neither
> in its scripts, nor in its tests (the exception being the tests on
> bash completion, of course). This script probably need to be re-written
> to be a valid POSIX shell script.
No, we can't assume bash. But this is replacing a script written in
python, which we also can't assume. So if it were optional, and skipped
gracefully when bash was not available, that would be OK. Of course if
it could be done in portable bourne shell, that would be even better (I
haven't looked closely, but your comments all seem reasonable).
-Peff
^ permalink raw reply
* Re: [PATCH v4 09/14] remote-testgit: report success after an import
From: Stefano Lattarini @ 2012-11-02 13:58 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Jeff King, Johannes Schindelin,
Elijah Newren, Ilari Liusvaara, Sverre Rabbelier
In-Reply-To: <1351821738-17526-10-git-send-email-felipe.contreras@gmail.com>
On 11/02/2012 03:02 AM, Felipe Contreras wrote:
> Doesn't make a difference for the tests, but it does for the ones
> seeking reference.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> git-remote-testgit | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/git-remote-testgit b/git-remote-testgit
> index 6c348b0..4e8b356 100755
> --- a/git-remote-testgit
> +++ b/git-remote-testgit
> @@ -59,7 +59,18 @@ while read line; do
> sed -e "s#refs/heads/#${prefix}/heads/#g"
> ;;
> export)
> + declare -A before after
> +
If you convert this script to be a valid POSIX shell script (as I've
suggested in my reply to [PATCH v4 04/14]), you'll need to get rid of
this bashism (and those below) as well.
> + eval $(git for-each-ref --format='before[%(refname)]=%(objectname)')
> +
> git fast-import --{import,export}-marks="$testgitmarks" --quiet
> +
> + eval $(git for-each-ref --format='after[%(refname)]=%(objectname)')
> +
> + for ref in "${!after[@]}"; do
> + test "${before[$ref]}" == "${after[$ref]}" && continue
> + echo "ok $ref"
> + done
> echo
> ;;
> '')
Regards,
Stefano
^ permalink raw reply
* Re: [PATCH v4 04/14] Add new simplified git-remote-testgit
From: Stefano Lattarini @ 2012-11-02 13:55 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Jeff King, Johannes Schindelin,
Elijah Newren, Ilari Liusvaara, Sverre Rabbelier
In-Reply-To: <1351821738-17526-5-git-send-email-felipe.contreras@gmail.com>
On 11/02/2012 03:02 AM, Felipe Contreras wrote:
> It's way simpler. It exerceises the same features of remote helpers.
> It's easy to read and understand. It doesn't depend on python.
>
> It does _not_ exercise the python remote helper framework; there's
> another tool and another test for that.
>
> For now let's just copy the old remote-helpers test script, although
> some of those tests don't make sense for this testgit (they still pass).
>
> In addition, this script would be able to test other features not
> currently being tested.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> Documentation/git-remote-testgit.txt | 2 +-
> git-remote-testgit | 62 ++++++++++++++++
> t/t5801-remote-helpers.sh | 134 +++++++++++++++++++++++++++++++++++
> 3 files changed, 197 insertions(+), 1 deletion(-)
> create mode 100755 git-remote-testgit
> create mode 100755 t/t5801-remote-helpers.sh
>
> diff --git a/git-remote-testgit b/git-remote-testgit
> new file mode 100755
> index 0000000..6650402
> --- /dev/null
> +++ b/git-remote-testgit
> @@ -0,0 +1,62 @@
> +#!/bin/bash
>
I think git can't assume the existence of bash unconditionally, neither
in its scripts, nor in its tests (the exception being the tests on
bash completion, of course). This script probably need to be re-written
to be a valid POSIX shell script.
It almost is, anyway, apart from the nits below ...
> +# Copyright (c) 2012 Felipe Contreras
> +
> +alias="$1"
>
Just FYI: the double quoting here (and in several variable assignments
below) is redundant. You can portably write it as:
alias=$1
and still be safe in the face of spaces and metacharacters in $1.
I'm not sure whether the Git coding guidelines suggest the use of
quoting in this situation though; if this is the case, feel free
to disregard my observation.
> +url="$2"
> +
> +# huh?
> +url="${url#file://}"
> +
> +dir="$GIT_DIR/testgit/$alias"
> +prefix="refs/testgit/$alias"
> +refspec="refs/heads/*:${prefix}/heads/*"
> +
> +gitmarks="$dir/git.marks"
> +testgitmarks="$dir/testgit.marks"
> +
> +export GIT_DIR="$url/.git"
> +
I believe this should be rewritten as:
GIT_DIR="$url/.git"; export GIT_DIR
in order to be portable to all the POSIX shells targeted by Git.
> +mkdir -p "$dir"
> +
> +test -e "$gitmarks" || echo -n > "$gitmarks"
> +test -e "$testgitmarks" || echo -n > "$testgitmarks"
> +
The '-n' option to echo is not portable. To create an empty
file, you can just use
: > file
or
true > file
> +while read line; do
> + case "$line" in
>
Useless double quoting (my previous observation about Git coding
guidelines applies here as well, of course).
> + capabilities)
> + echo 'import'
> + echo 'export'
> + echo "refspec $refspec"
> + echo "*import-marks $gitmarks"
> + echo "*export-marks $gitmarks"
> + echo
> + ;;
> + list)
> + git for-each-ref --format='? %(refname)' 'refs/heads/'
> + head=$(git symbolic-ref HEAD)
> + echo "@$head HEAD"
> + echo
> + ;;
> + import*)
> + # read all import lines
> + while true; do
> + ref="${line#* }"
> + refs="$refs $ref"
> + read line
> + test "${line%% *}" != "import" && break
> + done
> +
> + echo "feature import-marks=$gitmarks"
> + echo "feature export-marks=$gitmarks"
> + git fast-export --use-done-feature --{import,export}-marks="$testgitmarks" $refs | \
>
Better avoid the tricky {foo,bar} bashism:
git fast-export --use-done-feature \
--import-marks="$testgitmarks" \
--export-marks="$testgitmarks" \
$refs | \
> + sed -e "s#refs/heads/#${prefix}/heads/#g"
> + ;;
> + export)
> + git fast-import --{import,export}-marks="$testgitmarks" --quiet
>
Here too.
> + echo
> + ;;
> + '')
> + exit
>
I'd put an explicit exit status here, for clarity (this is a matter
of personal preference, so feel free to disregard this nit).
> + ;;
> + esac
> +done
Regards,
Stefano
^ permalink raw reply
* Re: Overlong lines with git-merge --log
From: Stephen Bash @ 2012-11-02 13:49 UTC (permalink / raw)
To: Tim Janik; +Cc: git, Jeff King
In-Reply-To: <5093C98D.90807@gnu.org>
----- Original Message -----
> From: "Tim Janik" <timj@gnu.org>
> Sent: Friday, November 2, 2012 9:24:29 AM
> Subject: Re: Overlong lines with git-merge --log
>
> On 02.11.2012 11:05, Jeff King wrote:
>
> > Taking just the first line of those often cuts off the useful part.
> > It was deemed less bad to show the whole message as a subject rather
> > than cut it off arbitrarily.
>
> Thanks a lot for the explanation, I'm using git directly here, but the
> two cases I had indeed lacked this newline.
FWIW we use merge --log quite extensively here at the office, and I've developed a habit to skim the extremely long lines and attempt to cut them intelligently (something I don't trust the computer to do for me). Sometimes that means taking the second or third sentence if it's a better summary, sometimes it's just abbreviating the first. Now that merge automatically spawns an editor, this is quite convenient (though it does take a bit longer).
Thanks,
Stephen
^ permalink raw reply
* Re: Overlong lines with git-merge --log
From: Tim Janik @ 2012-11-02 13:24 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121102100519.GC30221@sigill.intra.peff.net>
On 02.11.2012 11:05, Jeff King wrote:
> Taking just the first line of those often cuts off the useful part. It
> was deemed less bad to show the whole message as a subject rather than
> cut it off arbitrarily.
Thanks a lot for the explanation, I'm using git directly here, but the
two cases I had indeed lacked this newline.
--
Yours sincerely,
Tim Janik
---
http://timj.testbit.eu/ - Free software Author
^ permalink raw reply
* bisect: "Needed a single revision" message is confusing
From: Daniel Bonniot @ 2012-11-02 13:23 UTC (permalink / raw)
To: git
Hi,
Suppose I'm doing a git bisect, say:
$ git bisect good 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0
That works fine. The sha1 could also be a substring, as long as it's
unambiguous, e.g.:
$ git bisect good 8c7a786b6c
Now if it's ambiguous, I get an error message:
$ git bisect good 8
fatal: Needed a single revision
Bad rev input: 8
All fine and good. But what if I somehow input a non-existing sha1 (in
my case see [1]), e,g:
$ git bisect good 8c7a786b6c8eae8eac91083cdc9a6e337bc133b1
fatal: Needed a single revision
Bad rev input: 8c7a786b6c8eae8eac91083cdc9a6e337bc133b1
I understand that technically both "no revision" and "multiple
revisions" qualify as "not a single revision", but they correspond to
quite different situations. I think it would be more helpful to get
different error messages, something like:
Bad rev input: 8 refers to multiple revisions
Bad rev input: 8c7a786b6c8eae8eac91083cdc9a6e337bc133b1 does not refer
to a valid revision
(and avoid outputing the "fatal: Needed a single revision" message).
Is this a good idea? Anybody can think of better error messages?
I'm not familiar with the code base at all, but I could give a try at
implementing it, unless it's trivial enough that someone does it
earlier. After a quick look, it looks like either git-bisect itself or
rev-parse would need to be touched, any pointers and hints welcome.
Cheers,
Daniel
[1] if you want to know, I got a sha1 from one repository and used it
in another, which probably should work, except that when using git-svn
they don't. And the "single revision" error message lead me on a
tangent.
^ permalink raw reply
* Re: [PATCH] commit: fixup misplacement of --no-post-rewrite description
From: Jeff King @ 2012-11-02 13:22 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git
In-Reply-To: <m2hap88a2g.fsf@igel.home>
On Fri, Nov 02, 2012 at 01:26:47PM +0100, Andreas Schwab wrote:
> In e858af6 (commit: document a couple of options) the description of the
> --no-post-rewrite option was put inside the paragraph for the --amend
> option. Move it down after the paragraph.
>
> Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Thanks, the modified output looks much more sane.
-Peff
^ permalink raw reply
* Re: [PATCH] test-lib: avoid full path to store test results
From: Jeff King @ 2012-11-02 13:17 UTC (permalink / raw)
To: Felipe Contreras
Cc: Johannes Sixt, Jonathan Nieder, git, Junio C Hamano,
Ævar Arnfjörð
In-Reply-To: <509167C8.6090600@kdbg.org>
On Wed, Oct 31, 2012 at 07:02:48PM +0100, Johannes Sixt wrote:
> Am 31.10.2012 03:28, schrieb Felipe Contreras:
> > On Wed, Oct 31, 2012 at 3:13 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> >> Felipe Contreras wrote:
> >>
> >>> It's all fun and games to write explanations for things, but it's not
> >>> that easy when you want those explanations to be actually true, and
> >>> corrent--you have to spend time to make sure of that.
> >>
> >> That's why it's useful for the patch submitter to write them, asking
> >> for help when necessary.
> >>
> >> As a bonus, it helps reviewers understand the effect of the patch.
> >> Bugs averted!
> >
> > Yeah, that would be nice. Too bad I don't have that information, and
> > have _zero_ motivation to go and get it for you.
>
> Just to clarify: That information is not just for Jonathan, but for
> everyone on this list and those who dig the history a year down the
> road. Contributors who have _zero_ motiviation to find out that
> information are not welcome here because they cause friction and take
> away time from many others for _zero_ gain.
And me, who is trying to figure out what to do with this patch. It is
presented on its own, outside of a series, with only the description "no
reason not to do this". But AFAICT, it is _required_ for the tests in
the remote-hg series to work. Isn't that kind of an important
motivation?
Yet it is not in the commit message, nor does the remote-hg series
indicate that it should be built on top. Or am I wrong that the one is
dependent on the other?
-Peff
^ permalink raw reply
* Re: [PATCH v3 4/4] fast-export: make sure refs are updated properly
From: Jeff King @ 2012-11-02 13:12 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Felipe Contreras, git, Junio C Hamano, Sverre Rabbelier,
Johannes Schindelin, Elijah Newren
In-Reply-To: <20121031003721.GV15167@elie.Belkin>
On Tue, Oct 30, 2012 at 05:37:21PM -0700, Jonathan Nieder wrote:
> If the commit does not have the SHOWN or UNINTERESTING flag set but it
> is going to get the UNINTERESTING flag set during the walk because of
> a negative commit listed on the command line, this patch won't help.
Right, so my understanding of the situation is that doing this:
$ git branch foo master~1
$ git fast-export foo master~1..master
won't show "foo", which seems wrong to me. _But_ we currently get that
wrong already, so Felipe's patches are not making anything worse, but
are fixing some situations (namely when master~1 is not mentioned on the
command-line, but rather in a marks file).
Is that correct?
If so, then this series isn't regressing behavior; the only downside is
that it's an incomplete fix. In theory this could get in the way of the
full fix later on, but given the commit messages and the archive of this
discussion, it would be simple enough to revert it later in favor of a
more full fix. Is that accurate?
Sorry if I am belaboring the discussion. I just want to make sure I
understand the situation before deciding what to do with the topic. It
sounds like the consensus at this point is "not perfect, but good enough
to make forward progress".
-Peff
^ permalink raw reply
* Re: Wishlist: git commit --no-edit
From: Jeff King @ 2012-11-02 12:45 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <CACnwZYe-za3Q0qvkfQ=qatB1-8eLUFA6ZzfS41yeqrV=8rVzGA@mail.gmail.com>
[+cc git@vger; please keep discussion on list]
On Fri, Nov 02, 2012 at 10:37:27AM -0200, Thiago Farina wrote:
> >> > git commit --amend --no-edit
> [...]
> > Yup, should be working since 1.7.9.
> [...]
> I doesn't appear in the help either:
>
> $ git version
> git version 1.8.0.rc2
>
> $ git commit -h 2>&1 | grep edit
> -c, --reedit-message <commit>
> reuse and edit message from specified commit
> -e, --edit force edit of commit
Yeah, parse_options doesn't advertise negative forms of boolean options,
as they are implied. I don't think it's a big deal, especially now that
it is covered in more detail in the manpage.
I think changing it would probably involve adding "--no-edit" as a
separate entry in the options struct.
-Peff
^ permalink raw reply
* [PATCH] commit: fixup misplacement of --no-post-rewrite description
From: Andreas Schwab @ 2012-11-02 12:26 UTC (permalink / raw)
To: git
In e858af6 (commit: document a couple of options) the description of the
--no-post-rewrite option was put inside the paragraph for the --amend
option. Move it down after the paragraph.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
Documentation/git-commit.txt | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 9594ac8..28a5aeb 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -193,10 +193,6 @@ OPTIONS
current tip -- if it was a merge, it will have the parents of
the current tip as parents -- so the current top commit is
discarded.
-
---no-post-rewrite::
- Bypass the post-rewrite hook.
-
+
--
It is a rough equivalent for:
@@ -213,6 +209,9 @@ You should understand the implications of rewriting history if you
amend a commit that has already been published. (See the "RECOVERING
FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
+--no-post-rewrite::
+ Bypass the post-rewrite hook.
+
-i::
--include::
Before making a commit out of staged contents so far,
--
1.8.0
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: [PATCH] Document 'git commit --no-edit' explicitly
From: Jeff King @ 2012-11-02 11:53 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, nisse
In-Reply-To: <1351852770-13897-1-git-send-email-Matthieu.Moy@imag.fr>
On Fri, Nov 02, 2012 at 11:39:30AM +0100, Matthieu Moy wrote:
> I was tempted to merge the paragraph with --edit::, but I thought this
> may add confusion. The use-cases for --edit and --no-edit are really
> different so I went for a separate paragraph, right below the --edit one.
Yeah, usually I think it would be better to keep the positive and
negative forms together, but the way you have done it does seem a lot
more clear to me. I think it is because the default flips based on other
options. So you would be stuck writing something like:
-e, --edit::
Edit the commit message using `$EDITOR`. This is the default
unless the `-F`, `-m`, or `-C` options are used; in those
cases, `-e` or `--edit` can be used to invoke the editor.
Likewise, `--no-edit` can be used to suppress the editor when
using an existing commit message. For example, `git commit
--amend --no-edit` amends a commit without changing its commit
message.
Your split reads much better, IMHO.
Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH] Document 'git commit --no-edit' explicitly
From: Matthieu Moy @ 2012-11-02 11:29 UTC (permalink / raw)
To: Niels Möller; +Cc: git, peff
In-Reply-To: <nnlieki6xs.fsf@stalhein.lysator.liu.se>
nisse@lysator.liu.se (Niels Möller) writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> +--no-edit::
>> + Use the selected commit message without launching an editor.
>> + For example, `git commit --amend --no-edit` amends a commit
>> + without changing its commit message.
>
> Looks clear enough to me. Thanks for fixing.
>
> Are -c --no-edit and -C really equivalent in all cases?
I guess so, but I didn't check.
> If so, maybe you want to say that in the documentation for -C.
I don't think we should target exhaustivity in the documentation, so I'm
not in favor of *adding* it. But maybe we should replace the doc with
stg like:
-c <commit>::
--reedit-message=<commit>::
Like '-C --edit'.
(it could even make sense to deprecate one of -C/-c)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Document 'git commit --no-edit' explicitly
From: Niels Möller @ 2012-11-02 11:24 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, peff
In-Reply-To: <1351852770-13897-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> +--no-edit::
> + Use the selected commit message without launching an editor.
> + For example, `git commit --amend --no-edit` amends a commit
> + without changing its commit message.
Looks clear enough to me. Thanks for fixing.
Are -c --no-edit and -C really equivalent in all cases? If so, maybe you
want to say that in the documentation for -C. (And if not, maybe they
*ought* to be equivalent).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Michael J Gruber @ 2012-11-02 11:03 UTC (permalink / raw)
To: Andreas Ericsson
Cc: René Scharfe, Felipe Contreras, Junio C Hamano,
Johannes Schindelin, Jonathan Nieder, Jeff King, git,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <5093949D.4070509@op5.se>
Andreas Ericsson venit, vidit, dixit 02.11.2012 10:38:
> On 11/01/2012 02:46 PM, René Scharfe wrote:
>>
>> Also, and I'm sure you didn't know that, "Jedem das Seine" (to each
>> his own) was the slogan of the Buchenwald concentration camp. For
>> that reason some (including me) hear the unspoken cynical
>> half-sentence "and some people just have to be sent to the gas
>> chamber" when someone uses this proverb.
>>
>
> It goes further back than that.
>
> "Suum cuique pulchrum est" ("To each his own is a beautiful thing") is
> a latin phrase said to be used frequently in the roman senate when
> senators politely agreed to disagree and let a vote decide the outcome
> rather than debating further.
>
> Please don't let the twisted views of whatever nazi idiot thought it
> meant "you may have the wrong faith and therefore deserve to die, so you
> shall" pollute it. The original meaning is both poetic and democratic,
> and I firmly believe most people have the original meaning to the fore
> of their mind when using it. After all, very few people knowingly quote
> nazi concentration camp slogans.
>
In fact, many German terms and words are "forbidden area" since Nazi
times, but I don't think this one carries the same connotation.
But that is a side track.
Collaboration (and code review is a form of collaboration) requires
communication. The linked code of conduct pages describe quite well how
to ensure a productive environment in which "everyone" feels comfortable
communicating and collaborating. But even reading pages like these
requires a common sense (of the many undefined terms therein), a sense
which is usually present here on the list, and thus renders a page like
these unnecessary for us. Once there is a lack of commonality, there is
a lack of agreement about those undefined terms (what constitutes a
personal attack etc.).
Consequently, the only practical test for commonality and community
acceptance appears to be just that: commonality and community
acceptance. If many people in a community consider a tone or formulation
offensive, then it is offensive by the very definition of common sense
(common to that community), and there's no point at all in arguing about
it. If I don't like a community's sense I either deal with it or leave it.
It's really not that different from coding style. If we prefer
if (cond) {
over
if (cond)
{
then you either do it that way or your code gets rejected. The
difference is that coding style is easier to define, of course. The
common thing is that there's no point in arguing about it.
Michael
^ permalink raw reply
* [PATCH] Document 'git commit --no-edit' explicitly
From: Matthieu Moy @ 2012-11-02 10:39 UTC (permalink / raw)
To: git; +Cc: peff, nisse, Matthieu Moy
In-Reply-To: <nnpq3wiaha.fsf@stalhein.lysator.liu.se>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
I was tempted to merge the paragraph with --edit::, but I thought this
may add confusion. The use-cases for --edit and --no-edit are really
different so I went for a separate paragraph, right below the --edit one.
Documentation/git-commit.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 3acf2e7..44b4347 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -188,6 +188,11 @@ OPTIONS
commit log message unmodified. This option lets you
further edit the message taken from these sources.
+--no-edit::
+ Use the selected commit message without launching an editor.
+ For example, `git commit --amend --no-edit` amends a commit
+ without changing its commit message.
+
--amend::
Used to amend the tip of the current branch. Prepare the tree
object you would want to replace the latest commit as usual
--
1.8.0.319.g8abfee4
^ permalink raw reply related
* Re: Wishlist: git commit --no-edit
From: Niels Möller @ 2012-11-02 10:07 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqfw4sgx33.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Err, isn't this already working? (maybe your version of Git is too old,
> but my 1.7.9.5 does this at least)
It may be that I'm confused.
It doesn't work in the version I have (1.7.2.5, debian packaged).
And then I also had a quick look in the source code (of a fresh pull
from https://github.com/git/git.git). In builtin/commit.c, I didn't see
any no-edit flag (but I maybe it's in the OPT_BOOL magic (which is
different from OPT_BOOLEAN?)).
And it's also not mentioned in Documentation/git-commit.txt or on
http://kernel.org/pub/software/scm/git/docs/git-commit.html.
If commit --no-edit does work in recent versions, then all is fine,
except possibly the documentation of it. Thanks.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
^ permalink raw reply
* Re: Overlong lines with git-merge --log
From: Jeff King @ 2012-11-02 10:05 UTC (permalink / raw)
To: Tim Janik; +Cc: git
In-Reply-To: <50932227.3090401@gnu.org>
On Fri, Nov 02, 2012 at 02:30:15AM +0100, Tim Janik wrote:
> Using git-merge --log to merge commit messages that spawn multiple lines
> will produce overlong summary lines.
> That's because each summary line for a commit includes the entire commit
> message (all lines concatenated).
>
> According to git-fmt-merge-msg(1), --log should 'populate the log
> message with one-line descriptions' instead of using the entire commit
> messages.
> Which would make a lot of sense, it's just not working as advertised.
The "subject" or "first line" is not actually the first line; these days
it is typically the "first paragraph". The reason is that git always
expected commit messages to look like:
one line describing the change
more detailed explanation
that might go on for several lines
or even several paragraphs
However, as people imported commits from previous systems, they ended up
with a lot of commit messages where the closest thing to a subject was
split across several lines like:
here's a description of the commit that is probably overly long,
but that's how we did it back in CVS days
Taking just the first line of those often cuts off the useful part. It
was deemed less bad to show the whole message as a subject rather than
cut it off arbitrarily.
If you are developing with git and not splitting the subject out with a
blank line, there are a lot of tools that are going to look ugly (e.g.,
format-patch will generate overly long subjects, "log --oneline" will be
ugly, and browsers like "tig" and "gitk" may be overwhelmed).
-Peff
^ permalink raw reply
* Re: Wishlist: git commit --no-edit
From: Jeff King @ 2012-11-02 9:59 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Niels Möller, git
In-Reply-To: <vpqfw4sgx33.fsf@grenoble-inp.fr>
On Fri, Nov 02, 2012 at 10:42:24AM +0100, Matthieu Moy wrote:
> nisse@lysator.liu.se (Niels Möller) writes:
>
> > I'd like to have a git commit option which is the opposite of --edit, to
> > use the selected commit message as is, without invoking any editor.
> >
> > Main use case I see would be
> >
> > git commit --amend --no-edit
>
> Err, isn't this already working? (maybe your version of Git is too old,
> but my 1.7.9.5 does this at least)
Yup, should be working since 1.7.9.
$ git tag --contains ':/commit: honour --no-edit' |
sort -V |
head -1
v1.7.9
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)
From: Jeff King @ 2012-11-02 9:56 UTC (permalink / raw)
To: Chris Rorvick; +Cc: Ramsay Jones, git
In-Reply-To: <20121102094259.GA28414@sigill.intra.peff.net>
On Fri, Nov 02, 2012 at 05:43:00AM -0400, Jeff King wrote:
> Yeah, I think that is it. IIRC, Ramsay is on cygwin, and I noticed this
> in perl 5.16's POSIX.xs:
>
> [...]
> * (4) The CRT strftime() "%Z" implementation calls __tzset(). That
> * calls CRT tzset(), but only the first time it is called, and in turn
> * that uses CRT getenv("TZ") to retrieve the timezone info from the CRT
> * local copy of the environment and hence gets the original setting as
> * perl never updates the CRT copy when assigning to $ENV{TZ}.
> [...]
> I wonder if Ramsay has an older perl that does not do this special
> hackery right. I'll see if I can dig up where it first appeared.
It looks like that code went into perl 5.11.
I wonder, even with this fix, though, if we need to be calling tzset to
reliably update from the environment. It sounds like it _should_ happen
automatically, except that if the CRT is calling the internal tzset, it
would not do the perl "grab from $ENV" magic. Calling tzset would make
sure the internal TZ is up to date.
Ramsay, what happens with this patch on top?
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index ceb119d..4c44050 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -24,11 +24,12 @@ use File::Basename qw(basename dirname);
use Time::Local;
use IO::Socket;
use IO::Pipe;
-use POSIX qw(strftime dup2 ENOENT);
+use POSIX qw(strftime tzset dup2 ENOENT);
use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
+tzset();
our ($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P, $opt_s,$opt_m,@opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r, $opt_R);
my (%conv_author_name, %conv_author_email, %conv_author_tz);
@@ -855,8 +856,10 @@ sub commit {
}
$ENV{'TZ'}=$author_tz;
+ tzset();
my $commit_date = strftime("%s %z", localtime($date));
$ENV{'TZ'}="UTC";
+ tzset();
$ENV{GIT_AUTHOR_NAME} = $author_name;
$ENV{GIT_AUTHOR_EMAIL} = $author_email;
$ENV{GIT_AUTHOR_DATE} = $commit_date;
^ permalink raw reply related
* Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)
From: Jeff King @ 2012-11-02 9:43 UTC (permalink / raw)
To: Chris Rorvick; +Cc: Ramsay Jones, git
In-Reply-To: <CAEUsAPb7hUViLn7V7v65r6mOqRHr+180ynRX8K9t3nuJVyePfg@mail.gmail.com>
On Thu, Nov 01, 2012 at 08:12:20PM -0500, Chris Rorvick wrote:
> > Just FYI, t9604-cvsimport-timestamps.sh is still failing for me.
> >
> > I haven't spent too long on this yet, but I had hoped that setting
> > TZ would sidestep any DST issues. (I have downloaded new tzdata, but
> > have yet to install - actually I don't really want to!). It is not
> > clear from the tzset manpage what happens if you use the DST format
> > for TZ, but you don't provide the start/end date for DST, which is
> > what this test is doing.
> >
> > Perhaps the test should use the non-DST format? e.g. "TZ=CST6 git ..."
> > Does the test really care about DST? (*if* that is indeed the problem).
>
> It actually looks like your TZ database is fine and the problem is
> with the conversion to a struct tm. In each case, the time is
> localized to the previous TZ value while the offset for the current TZ
> value. For example, look at the first commit in the first test. It
> converted the timestamp to 18:00 (CST6) while all the rest came
> through as expected. I suspect the previous version of cvsimport
> would exhibit similar behavior with the first imported commit. What
> is your platform?
Yeah, I think that is it. IIRC, Ramsay is on cygwin, and I noticed this
in perl 5.16's POSIX.xs:
#ifdef WIN32
/*
* (1) The CRT maintains its own copy of the environment, separate from
* the Win32API copy.
*
* (2) CRT getenv() retrieves from this copy. CRT putenv() updates this
* copy, and then calls SetEnvironmentVariableA() to update the Win32API
* copy.
*
* (3) win32_getenv() and win32_putenv() call GetEnvironmentVariableA() and
* SetEnvironmentVariableA() directly, bypassing the CRT copy of the
* environment.
*
* (4) The CRT strftime() "%Z" implementation calls __tzset(). That
* calls CRT tzset(), but only the first time it is called, and in turn
* that uses CRT getenv("TZ") to retrieve the timezone info from the CRT
* local copy of the environment and hence gets the original setting as
* perl never updates the CRT copy when assigning to $ENV{TZ}.
*
* Therefore, we need to retrieve the value of $ENV{TZ} and call CRT
* putenv() to update the CRT copy of the environment (if it is different)
* whenever we're about to call tzset().
[...]
I wonder if Ramsay has an older perl that does not do this special
hackery right. I'll see if I can dig up where it first appeared.
-Peff
^ permalink raw reply
* Re: Wishlist: git commit --no-edit
From: Matthieu Moy @ 2012-11-02 9:42 UTC (permalink / raw)
To: Niels Möller; +Cc: git
In-Reply-To: <nntxt8ice9.fsf@stalhein.lysator.liu.se>
nisse@lysator.liu.se (Niels Möller) writes:
> I'd like to have a git commit option which is the opposite of --edit, to
> use the selected commit message as is, without invoking any editor.
>
> Main use case I see would be
>
> git commit --amend --no-edit
Err, isn't this already working? (maybe your version of Git is too old,
but my 1.7.9.5 does this at least)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Andreas Ericsson @ 2012-11-02 9:38 UTC (permalink / raw)
To: René Scharfe
Cc: Felipe Contreras, Junio C Hamano, Johannes Schindelin,
Jonathan Nieder, Jeff King, git, Michael J Gruber,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <50927D29.3020703@lsrfire.ath.cx>
On 11/01/2012 02:46 PM, René Scharfe wrote:
>
> Also, and I'm sure you didn't know that, "Jedem das Seine" (to each
> his own) was the slogan of the Buchenwald concentration camp. For
> that reason some (including me) hear the unspoken cynical
> half-sentence "and some people just have to be sent to the gas
> chamber" when someone uses this proverb.
>
It goes further back than that.
"Suum cuique pulchrum est" ("To each his own is a beautiful thing") is
a latin phrase said to be used frequently in the roman senate when
senators politely agreed to disagree and let a vote decide the outcome
rather than debating further.
Please don't let the twisted views of whatever nazi idiot thought it
meant "you may have the wrong faith and therefore deserve to die, so you
shall" pollute it. The original meaning is both poetic and democratic,
and I firmly believe most people have the original meaning to the fore
of their mind when using it. After all, very few people knowingly quote
nazi concentration camp slogans.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Wishlist: git commit --no-edit
From: Niels Möller @ 2012-11-02 9:26 UTC (permalink / raw)
To: git
I'd like to have a git commit option which is the opposite of --edit, to
use the selected commit message as is, without invoking any editor.
Main use case I see would be
git commit --amend --no-edit
(say you fix a typo in the previous commit which doesn't affect the
commit message). Today, one can get the same effect more clumsily as
EDITOR=touch git commit --amend
Or maybe as
git commit --amend -C HEAD
But I'd really prefer a --no-edit option over those alternatives. And it
might be useful also in combination with other options, e.g., it would
make the -C option equivalent to -c --no-edit, if I understand it
correctly.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
^ 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