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,
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
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 your
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 -
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,
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
git
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
Matthieu Moy matthieu@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
Signed-off-by: Matthieu Moy matthieu@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
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
Matthieu Moy matthieu@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
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 sch...@linux-m68k.org
---
Documentation/git-commit.txt | 7 +++
1 file
[+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 21
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
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 jrnie...@gmail.com wrote:
Felipe Contreras wrote:
It's all fun and games to write explanations for things, but it's not
that
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
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 t...@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
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 felipe.contre...@gmail.com
---
git-remote-testgit | 11 +++
1 file changed, 11 insertions(+)
diff --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
bash
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
It seems that our fast-import is super picky with regards to author
names. I've encountered author names like
Foo Barfoo@dev.null
Foo Bar foo@dev.null
foo@dev.null
in the self-hosting repo of some other dvcs, and the question is how to
translate them faithfully into a git author
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
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
patch is
Some additional input:
[mjg@localhost git]$ git commit --author='is thiso...@or.not
whats@up' --allow-empty -m test
[detached HEAD 0734308] test
Author: is thi...@or.not whats@up
[mjg@localhost git]$ git show
commit 0734308b7bf372227bf9f5b9fd6b4b403df33b9e
Author: is thi...@or.not whats@up
Date:
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 tip I
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_basename = (
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 in
On Fri, 2 Nov 2012 18:39:26 +0400
Kirill Likhodedov kirill.likhode...@jetbrains.com 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
On Fri, 2 Nov 2012 19:03:37 +0400
Konstantin Khomoutov flatw...@users.sourceforge.net 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
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 the
On Fri, Nov 2, 2012 at 2:17 PM, Jeff King p...@peff.net 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 jrnie...@gmail.com
wrote:
Felipe Contreras wrote:
It's all fun
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 I'll
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
On Fri, Nov 2, 2012 at 2:12 PM, Jeff King p...@peff.net 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 Fri, Nov 2, 2012 at 4:19 PM, Jeff King p...@peff.net 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?
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,
On Fri, Nov 2, 2012 at 2:55 PM, Stefano Lattarini
stefano.lattar...@gmail.com 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
On Fri, Nov 2, 2012 at 2:58 PM, Stefano Lattarini
stefano.lattar...@gmail.com 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 felipe.contre...@gmail.com
---
On 11/02/2012 04:42 PM, Felipe Contreras wrote:
On Fri, Nov 2, 2012 at 2:55 PM, Stefano Lattarini
stefano.lattar...@gmail.com 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
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 needs
On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber
g...@drmicha.warpmail.net 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
On Fri, Nov 2, 2012 at 5:03 PM, Stefano Lattarini
stefano.lattar...@gmail.com 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
On Fri, Nov 2, 2012 at 5:08 PM, Stefano Lattarini
stefano.lattar...@gmail.com 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
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 we have a:
On Fri, Nov 2, 2012 at 3:48 PM, Jeff King p...@peff.net 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
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 follow up (and
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
---
On Fri, Nov 2, 2012 at 5:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Nov 2, 2012 at 3:48 PM, Jeff King p...@peff.net 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
On Fri, Nov 2, 2012 at 3:46 PM, Jeff King p...@peff.net 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 the
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, what
Am 2012-11-02 16:15, schrieb Konstantin Khomoutov:
On Fri, 2 Nov 2012 19:03:37 +0400
Konstantin Khomoutov flatw...@users.sourceforge.net 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
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 only the first
ping?
On Tue, Oct 30, 2012 at 11:11 AM, Stefan Zager sza...@google.com 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
On 2 November 2012 18:39, Felipe Contreras felipe.contre...@gmail.com 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
On Sat, Nov 3, 2012 at 12:18 AM, Thomas Adam tho...@xteddy.org wrote:
On 2 November 2012 18:39, Felipe Contreras felipe.contre...@gmail.com 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
59 matches
Mail list logo
