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
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
ni...@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
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 in
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
On Fri, Nov 02, 2012 at 10:42:24AM +0100, Matthieu Moy wrote:
> ni...@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
>
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
Matthieu Moy 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 pul
Signed-off-by: Matthieu Moy
---
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 ch
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 c
Matthieu Moy 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 e
ni...@lysator.liu.se (Niels Möller) writes:
> Matthieu Moy 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.
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
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
---
Documentation/git-commit.txt | 7 +++
1 file changed, 3 insertions(+), 4
[+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
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 und
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 wrote:
> >> Felipe Contreras wrote:
> >>
> >>> It's all fun and games to write explanations for things, but it's not
> >>> that easy
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
Thank
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
- Original Message -
> From: "Tim Janik"
> 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 t
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.
>
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
> ---
> git-remote-testgit | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/git-remote-testgit b/git-
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
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
>
>
It seems that our fast-import is super picky with regards to author
names. I've encountered author names like
Foo Bar
Foo Bar
if the other system's entry does not parse as a git author name, but
fast-import does not accept either of
Foo Bar
"Foo Bar"
because of the way it parses for <>. Whil
Hi,
Currently, core.ignorecase is set to true on case insensitive system like
Windows or Mac on `git init` and `git clone`, and this setting is local to the
created/cloned repository.
Here is the man entry:
core.ignorecase
If true, this option enables various workarounds to enable gi
On Wed, Oct 31, 2012 at 05:11:39PM +0100, Felipe Contreras wrote:
> > As a patch
> > submitter, you ("generic you") want the attention of others as
> > reviewers. It's in your own (again "generic you") interest not to put
> > them off, in the same way as it's up to the submitter to argue why a
> >
Some additional input:
[mjg@localhost git]$ git commit --author='"is this"
' --allow-empty -m test
[detached HEAD 0734308] test
Author: is thi...@or.not
[mjg@localhost git]$ git show
commit 0734308b7bf372227bf9f5b9fd6b4b403df33b9e
Author: is thi...@or.not
Date: Fri Nov 2 15:45:23 2012 +0100
On Thu, Nov 01, 2012 at 05:08:52AM +0100, Felipe Contreras wrote:
> > Turns out msysgit's remote-hg is not exporting the whole repository,
> > that's why it's faster =/
>
> It seems the reason is that it would only export to the point where
> the branch is checked out. After updating the to the t
On Mon, Oct 29, 2012 at 09:42:07AM -0700, rh wrote:
> I also consolidated exts where applicable.
> i.e. c and h maps to c
>
>
> --
>
> diff --git a/a/gitweb.cgi b/b/gitweb.cgi
> index 060db27..155b238 100755
> --- a/a/gitweb.cgi
> +++ b/b/gitweb.cgi
> @@ -246,19 +246,19 @@ our %highlight_basen
Jeff King wrote:
> 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
On Fri, 2 Nov 2012 18:39:26 +0400
Kirill Likhodedov wrote:
> Currently, core.ignorecase is set to true on case insensitive system
> like Windows or Mac on `git init` and `git clone`, and this setting
> is local to the created/cloned repository.
[...]
> I suggest to set this globally by default wh
On Fri, 2 Nov 2012 19:03:37 +0400
Konstantin Khomoutov wrote:
> > Currently, core.ignorecase is set to true on case insensitive system
> > like Windows or Mac on `git init` and `git clone`, and this setting
> > is local to the created/cloned repository.
> [...]
> > I suggest to set this globally
Hi Peff,
On Fri, 2 Nov 2012, Jeff King wrote:
> 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
On Fri, Nov 2, 2012 at 2:17 PM, Jeff King wrote:
> 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
>> > wrote:
>> >> Felipe Contreras wrote:
>> >>
>> >>> It's all fun and game
On Fri, Nov 02, 2012 at 04:17:14PM +0100, Johannes Schindelin wrote:
> > 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
On Fri, Nov 02, 2012 at 04:17:27PM +0100, Felipe Contreras wrote:
> > 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".
>
> Yeah, because I think it stands on its own. But
On Tue, Oct 30, 2012 at 10:50:42AM +0100, karsten.bl...@dcon.de wrote:
> 'update-index --refresh' and 'diff-index' (without --cached) don't honor
> the core.preloadindex setting yet. Porcelain commands using these (such as
> git [svn] rebase) suffer from this, especially on Windows.
>
> Use read_
On Fri, Nov 2, 2012 at 2:12 PM, Jeff King wrote:
> 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 th
On Fri, Nov 2, 2012 at 4:19 PM, Jeff King wrote:
> On Fri, Nov 02, 2012 at 04:17:14PM +0100, Johannes Schindelin wrote:
>> May I just ask to include a summary of that rationale into the commit
>> message rather than relying on people having internet access and knowing
>> where to look? Adding the
On Fri, Nov 02, 2012 at 11:26:16AM -0400, Jeff King wrote:
> Still, I don't think we need to worry about performance regressions,
> because people who don't have a setup suitable for it will not turn on
> core.preloadindex in the first place. And if they have it on, the more
> places we use it, pr
On Fri, Nov 2, 2012 at 2:55 PM, Stefano Lattarini
wrote:
>> +#!/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
> t
On Fri, Nov 2, 2012 at 2:58 PM, Stefano Lattarini
wrote:
> 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
>> ---
>> git-remote-testgit | 11 +++
>> 1 file cha
On 11/02/2012 04:42 PM, Felipe Contreras wrote:
> On Fri, Nov 2, 2012 at 2:55 PM, Stefano Lattarini
> wrote:
>
>>> +#!/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,
On 11/02/2012 04:46 PM, Felipe Contreras wrote:
>
> In the end I liked this approach much better.
>
> If you have a solution for this that works in POSIX shell, I'll be
> glad to consider it, but for the moment, I think a simple, easy to
> understand and maintain code is more important, and if it
On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber
wrote:
> 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 c
On Fri, Nov 2, 2012 at 5:03 PM, Stefano Lattarini
wrote:
> On 11/02/2012 04:42 PM, Felipe Contreras wrote:
>> What happens when you call this with:
>>
>> ./script "alias with spaces"
>>
> '$alias' will correctly expand to "alias with spaces". Try out:
>
> $ sh -c 'alias=$1; echo "$alias"' dum
On Fri, Nov 2, 2012 at 5:08 PM, Stefano Lattarini
wrote:
> On 11/02/2012 04:46 PM, Felipe Contreras wrote:
>>
>> In the end I liked this approach much better.
>>
>> If you have a solution for this that works in POSIX shell, I'll be
>> glad to consider it, but for the moment, I think a simple, easy
On 11/02/2012 05:19 PM, Felipe Contreras wrote:
>
> [SNIP]
>
> As things are the options are:
>
> 1) Remove this code and move to POSIX sh. People looking for reference
> might scratch their heads as to why 'git push' is not showing the
> update.
> 2) Keep this code and remain in bash.
>
> Until
On Fri, Nov 2, 2012 at 3:48 PM, Jeff King wrote:
> On Thu, Nov 01, 2012 at 05:08:52AM +0100, Felipe Contreras wrote:
>
>> > Turns out msysgit's remote-hg is not exporting the whole repository,
>> > that's why it's faster =/
>>
>> It seems the reason is that it would only export to the point where
On Fri, Nov 02, 2012 at 05:19:33PM +0100, Felipe Contreras wrote:
> > In any case, I agree that having a clean, understandable code as a
> > starting point is better than having a more "portable" but trickier
> > one right away. If it will need converting to POSIX, that can be
> > done as a follo
This change removes the config entries in .gitmodules and adds it.
---
git-submodule.sh | 62 +++-
1 file changed, 61 insertions(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..29d950f 100755
--- a/git-submodule
On Fri, Nov 2, 2012 at 5:41 PM, Felipe Contreras
wrote:
> On Fri, Nov 2, 2012 at 3:48 PM, Jeff King wrote:
>> On Thu, Nov 01, 2012 at 05:08:52AM +0100, Felipe Contreras wrote:
>>
>>> > Turns out msysgit's remote-hg is not exporting the whole repository,
>>> > that's why it's faster =/
>>>
>>> It
On Fri, Nov 2, 2012 at 3:46 PM, Jeff King wrote:
> On Wed, Oct 31, 2012 at 05:11:39PM +0100, Felipe Contreras wrote:
>
>> > As a patch
>> > submitter, you ("generic you") want the attention of others as
>> > reviewers. It's in your own (again "generic you") interest not to put
>> > them off, in th
On Fri, Nov 2, 2012 at 7:39 PM, Felipe Contreras
wrote:
> As a rule, I don't see much value in writing a framework that works
> only for one case, that smells more like over-engineering. If we had
> two cases (hg and bzr), then we might be able to know with a modicum
> of certainty what such a fr
Jonathan Nieder wrote:
> Kevin wrote:
>
>> As I see it, the problem is not the possibility to add new lines, but
>> colleagues being too lazy to add them.
>
> I suspect the underlying problem is that we make it too hard to tell
> git which text editor to run.
Don't we just use $EDITOR?
> Ram, wha
Am 2012-11-02 16:15, schrieb Konstantin Khomoutov:
On Fri, 2 Nov 2012 19:03:37 +0400
Konstantin Khomoutov wrote:
Currently, core.ignorecase is set to true on case insensitive system
like Windows or Mac on `git init` and `git clone`, and this setting
is local to the created/cloned repository.
Jeff King wrote:
> 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
ping?
On Tue, Oct 30, 2012 at 11:11 AM, Stefan Zager wrote:
> This is a refresh of a conversation from a couple of months ago.
>
> I didn't try to implement all the desired features (e.g., smart logic
> for passing a -j parameter to recursive submodule invocations), but I
> did address the one is
On 2 November 2012 18:39, Felipe Contreras wrote:
> I disagree. The open source process works not by making favors to each
> other, but by everyone sharing and improving the code, by
> *collaborating*. "I review your code if you review mine", or "if you
> by me a bear in the next conference" is no
On Sat, Nov 3, 2012 at 12:18 AM, Thomas Adam wrote:
> On 2 November 2012 18:39, Felipe Contreras wrote:
>> I disagree. The open source process works not by making favors to each
>> other, but by everyone sharing and improving the code, by
>> *collaborating*. "I review your code if you review mine
Ramkumar Ramachandra wrote:
> Jonathan Nieder wrote:
>> Ram, what platform do your colleagues use?
>
> Red Hat Enterprise Linux 5.
Oh, ok. In that case I blame habit.
I think the best option you have is to just complain to your
colleagues about the long lines. Then they would get a chance to
e
62 matches
Mail list logo
