* Re: Serious bug with pretty format strings & empty bodies?
From: Johannes Schindelin @ 2007-12-20 12:34 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: René Scharfe, Alex Riesen, git
In-Reply-To: <57518fd10712200338m19c1def9n747dc9353ae41615@mail.gmail.com>
Hi,
On Thu, 20 Dec 2007, Jonathan del Strother wrote:
> I ended up trying to filter-branch my repository, see if I could come
> up with a version stripped of all our private code, suitable for
> making public. Disappointingly, filter-branch magically fixes all the
> commits, even when simply run as "git filter-branch HEAD".
>
> However, looking at the rewritten repository vs the original, they
> share a lot of commits, then diverge halfway through their history. I
> can't see anything notable about the commit where they diverge, with
> the exception that the rewritten commit has a newline after the
> subject and the original doesn't. Neither has a commit message body.
I do not see how Rene's patch could _not_ have fixed that problem.
As it is, I cannot even reproduce without that patch. This is what I was
trying:
-- snip --
diff --git a/t/t4025-pretty-format.sh b/t/t4025-pretty-format.sh
new file mode 100644
index 0000000..2826bcb
--- /dev/null
+++ b/t/t4025-pretty-format.sh
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+test_description='git pretty formats'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+
+ : > file &&
+ git add file &&
+ tree=$(git write-tree) &&
+ commit=$(echo No newlin | tr "\\012" e | git commit-tree $tree) &&
+ git update-ref HEAD $commit
+
+'
+
+test_expect_success 'format:%b' '
+
+ test -z "$(git log -1 --pretty=format:%b)"
+
+'
+
+test_done
-- snap --
Seems I cannot help any more, but at least this is a starting point to
try to reproduce.
Ciao,
Dscho
^ permalink raw reply related
* Re: Serious bug with pretty format strings & empty bodies?
From: Johannes Schindelin @ 2007-12-20 12:37 UTC (permalink / raw)
To: René Scharfe; +Cc: Jonathan del Strother, Alex Riesen, git
In-Reply-To: <476A5DFF.40803@lsrfire.ath.cx>
Hi,
On Thu, 20 Dec 2007, Ren? Scharfe wrote:
> The second chunk keeps the body offset from being incremented by the for
> loop if we've already found a terminating NUL.
Ah! I missed that one *writethisdownintothebook*
Thanks,
Dscho
^ permalink raw reply
* [PATCH] Remove old generated files from .gitignore.
From: Charles Bailey @ 2007-12-20 13:00 UTC (permalink / raw)
To: git
Some entries in .gitignore are obselete. These should be cleaned up
just for the sake of general tidiness and so that any developers who
have a working tree that was moved forward without a clean know that
they have old stuff in their work tree.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
.gitignore | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/.gitignore b/.gitignore
index dab5bc2..7f8421d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,7 +41,6 @@ git-fetch
git-fetch--tool
git-fetch-pack
git-filter-branch
-git-findtags
git-fmt-merge-msg
git-for-each-ref
git-format-patch
@@ -59,7 +58,6 @@ git-index-pack
git-init
git-init-db
git-instaweb
-git-local-fetch
git-log
git-lost-found
git-ls-files
@@ -120,10 +118,6 @@ git-show
git-show-branch
git-show-index
git-show-ref
-git-ssh-fetch
-git-ssh-pull
-git-ssh-push
-git-ssh-upload
git-stash
git-status
git-stripspace
--
1.5.4.rc0
^ permalink raw reply related
* Re: Serious bug with pretty format strings & empty bodies?
From: Jonathan del Strother @ 2007-12-20 13:08 UTC (permalink / raw)
To: René Scharfe; +Cc: Alex Riesen, git
In-Reply-To: <476A5DFF.40803@lsrfire.ath.cx>
On Dec 20, 2007 12:20 PM, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> Jonathan del Strother schrieb:
> > On Dec 19, 2007 11:23 PM, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> >> Just a shot in the dark: does this patch on top of master make a difference?
> > No luck with that, I'm afraid.
>
> And how is this one?
>
> The first chunk is the same as in the last try -- it guards against commit
> messages ending with a NUL without a prior \n _and_ being followed by a \n
> (in memory which shouldn't be accessed by us at all as it doesn't belong to
> the commit message). I guess that's quite rare.
>
> The second chunk keeps the body offset from being incremented by the for
> loop if we've already found a terminating NUL.
>
> diff --git a/pretty.c b/pretty.c
> index 9db75b4..5b1078b 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -412,7 +412,7 @@ static void parse_commit_header(struct format_commit_context *context)
> if (i == eol) {
> state++;
> /* strip empty lines */
> - while (msg[eol + 1] == '\n')
> + while (msg[eol] == '\n' && msg[eol + 1] == '\n')
> eol++;
> } else if (!prefixcmp(msg + i, "author ")) {
> context->author.off = i + 7;
> @@ -425,6 +425,8 @@ static void parse_commit_header(struct format_commit_context *context)
> context->encoding.len = eol - i - 9;
> }
> i = eol;
> + if (!msg[i])
> + break;
> }
> context->body_off = i;
> context->commit_header_parsed = 1;
>
Winnar!
Yep, that seems to have fixed things. Wonder how I managed to get the
null into the commit message...
^ permalink raw reply
* [PATCH] everyday: replace 'repack' with 'gc'
From: Miklos Vajna @ 2007-12-20 14:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <20071219225618.GA7378@genesis.frugalware.org>
Most users don't want to run git repack manually, so suggest using gc instead.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/everyday.txt | 13 ++++---------
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index a09c1d9..f1993e2 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -30,8 +30,6 @@ Everybody uses these commands to maintain git repositories.
* gitlink:git-fsck[1] to check the repository for errors.
- * gitlink:git-repack[1] to pack loose objects for efficiency.
-
* gitlink:git-gc[1] to do common housekeeping tasks such as
repack and prune.
@@ -43,23 +41,20 @@ Check health and remove cruft.::
------------
$ git fsck <1>
$ git count-objects <2>
-$ git repack <3>
-$ git gc <4>
+$ git gc <3>
------------
+
<1> running without `\--full` is usually cheap and assures the
repository health reasonably well.
<2> check how many loose objects there are and how much
disk space is wasted by not repacking.
-<3> without `-a` repacks incrementally. repacking every 4-5MB
-of loose objects accumulation may be a good rule of thumb.
-<4> it is easier to use `git gc` than individual housekeeping commands
-such as `prune` and `repack`.
+<3> repacks the local repository and performs other housekeeping tasks. Running
+without `--prune` is a safe operation even while other ones are in progress.
Repack a small project into single pack.::
+
------------
-$ git repack -a -d <1>
+$ git gc <1>
$ git gc --prune
------------
+
--
1.5.4.rc0.67.gf9c5-dirty
^ permalink raw reply related
* [PATCH] everyday: replace 'prune' with 'gc --prune'
From: Miklos Vajna @ 2007-12-20 14:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <20071219225618.GA7378@genesis.frugalware.org>
This document is for newcomers, so it's good to mention gc for housekeeping
tasks instead of running prune manually.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/everyday.txt | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index ce7c170..a09c1d9 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -30,8 +30,6 @@ Everybody uses these commands to maintain git repositories.
* gitlink:git-fsck[1] to check the repository for errors.
- * gitlink:git-prune[1] to remove unused objects in the repository.
-
* gitlink:git-repack[1] to pack loose objects for efficiency.
* gitlink:git-gc[1] to do common housekeeping tasks such as
@@ -56,13 +54,13 @@ disk space is wasted by not repacking.
<3> without `-a` repacks incrementally. repacking every 4-5MB
of loose objects accumulation may be a good rule of thumb.
<4> it is easier to use `git gc` than individual housekeeping commands
-such as `prune` and `repack`. This runs `repack -a -d`.
+such as `prune` and `repack`.
Repack a small project into single pack.::
+
------------
$ git repack -a -d <1>
-$ git prune
+$ git gc --prune
------------
+
<1> pack all the objects reachable from the refs into one pack,
@@ -189,7 +187,7 @@ $ git pull <3>
$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>
$ git reset --hard ORIG_HEAD <6>
-$ git prune <7>
+$ git gc --prune <7>
$ git fetch --tags <8>
------------
+
--
1.5.4.rc0.67.gf9c5-dirty
^ permalink raw reply related
* Re: Git-to-svn convert
From: Thomas Harning @ 2007-12-20 15:12 UTC (permalink / raw)
To: Andrew McMillan; +Cc: Martin Langhoff, Junio C Hamano, git
In-Reply-To: <1198128721.24580.78.camel@hippy.mcmillan.net.nz>
Andrew McMillan wrote:
> My code is an embarrasingly ugly, gruesome hack, but it (sort of)
> works...
>
> I use it to keep the SVN and CVS trees up to date on Sourceforge for
> DAViCal ( http://rscds.sf.net/ ) from the Git tree.
>
> Cheers,
> Andrew
Where might I find the code? I checked out git.catalyst.net.nz ... but
I couldn't find anything that seemed to be a sync tool... I figure I'd
give it a try before manually rebasing or progressively cherry-picking a
new tree...
^ permalink raw reply
* git-svn: pulling from local mirror but committing via svn+ssh
From: Mike Frysinger @ 2007-12-20 16:21 UTC (permalink / raw)
To: git
i have local (fast) mirrors of the svn trees i use, so i normally keep
everything pointing at those. when i need to commit, i use `svn
switch --relocate ...` to flip to the svn+ssh master, and then flop
back to the local mirror. it actually works out nicely.
my reading of git-svn(1) seems to indicate that git-svn cant really
handle switching of repository URLs on the fly ?
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
i tried tweaking my .git/config and changing the url to my svn+ssh,
but it seems any modification in the URL just causes errors ...
vapier@G5[ppc] git $ git-svn dcommit
Use of uninitialized value in concatenation (.) or string at
/usr/bin/git-svn line 384.
Committing to ...
Unable to determine upstream SVN information from HEAD history
guess i'll have to bite the bullet and just clone the svn+ssh repo :/
(i'm using 1.5.3.7 over here)
-mike
^ permalink raw reply
* Re: Question about git-svn import
From: Pascal Obry @ 2007-12-20 16:30 UTC (permalink / raw)
To: Jörg Sommer; +Cc: git list
In-Reply-To: <20071218153159.GA12549@alea.gnuu.de>
Jörg,
I have at least one remaining problem.
# Import old trunk into pre/master
$ git svn init svn+ssh://myserver --prefix=pre/ --trunk=importfromcvs/trunk
$ git svn fetch --revision=9458:10242
# Import new trunk into post/master
$ git config svn-remote.svn.fetch trunk/PROJ:refs/remotes/post/trunk
$ git svn fetch --revision=11058:11066
# Rewrite post/trunk on top of pre/trunk into merged-master
$ git checkout post/trunk
$ git checkout -b merged-master
$ git-filter-branch --tag-name-filter cat --parent-filter "sed -e
's/^$/-p $(git rev-parse pre/trunk)/'" merged-master
The problem is that at this point I cannot "git svn rebase". Looks like
the filter-branch command did break the link between the Subversion
repository and the git svn one:
$ git svn rebase
Unable to determine upstream SVN information from working tree history
Is there a way around that ?
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Commit a series of patches to SVN without rebase
From: Jörg Sommer @ 2007-12-20 16:40 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 387 bytes --]
Hi,
I've a number of patches in git I want to send to a SVN repository. git
svn dcommit does a rebase after each commit which makes the whole commit
takes very long. Is it possible to skip the rebase? All patches are in
one branch without merges, a simple chain. Is it save to use --no-rebase
in this case?
Bye, Jörg
--
Der Klügere gibt so lange nach bis er der Dumme ist.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Question about git-svn import
From: Jörg Sommer @ 2007-12-20 16:52 UTC (permalink / raw)
To: git list
In-Reply-To: <476A98BB.8000900@obry.net>
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
Pascal Obry schrieb am Thu 20. Dec, 17:30 (+0100):
> # Rewrite post/trunk on top of pre/trunk into merged-master
> $ git checkout post/trunk
> $ git checkout -b merged-master
> $ git-filter-branch --tag-name-filter cat --parent-filter "sed -e
> 's/^$/-p $(git rev-parse pre/trunk)/'" merged-master
>
> The problem is that at this point I cannot "git svn rebase". Looks like
> the filter-branch command did break the link between the Subversion
> repository and the git svn one:
>
> $ git svn rebase
> Unable to determine upstream SVN information from working tree history
>
> Is there a way around that ?
According to http://duncan.mac-vicar.com/blog/archives/282 it should help
to do something like:
git update-ref refs/remotes/git-svn master
find -name .rev_db* | xargs rm
I didn't had this problem, because I did a one‐time import.
Bye, Jörg.
--
Die zehn Gebote Gottes enthalten 172 Wörter, die amerikanische
Unabhängigkeitserklärung 300 Wörter, die Verordnung der europäischen
Gemeinschaft über den Import von Karamelbonbons exakt 25911 Wörter.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problem with git-svn
From: Eric Wong @ 2007-12-20 18:30 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <47690031.7090409@obry.net>
Pascal Obry <pascal.obry@gmail.com> wrote:
> Hi Eric,
>
> > Can you show me the output of `svn log -v -r9458 svn+ssh://myserver/'?
>
> $ svn log -v -r9458 svn+ssh://myserver/
> ------------------------------------------------------------------------
> r9458 | (no author) | 1998-04-22 19:07:08 +0200 (Wed, 22 Apr 1998) | 1 line
> Changed paths:
> A /importfromcvs
> A /importfromcvs/branches
> A /importfromcvs/tags
> A /importfromcvs/trunk
>
> New repository initialized by cvs2svn.
> ------------------------------------------------------------------------
>
> > So did svn+ssh://importfromcvs/trunk/file.el at r9458? If so, git-svn
> > is behaving as expected. If not, can you tell me where "file.el" was at
> > r9458?
>
> file.el was not imported at r9458 but at r9459, just after the creation
> of the /importfromcvs directories above.
>
> ------------------------------------------------------------------------
> r9459 | author | 1998-04-22 19:07:08 +0200 (Wed, 22 Apr 1998) | 2 lines
> Changed paths:
> A /importfromcvs/trunk/file.el
>
> Initial revision
>
> ------------------------------------------------------------------------
Ah, oops, I was off-by-one with the revision number. But git-svn does
look to be doing the right thing here, because it followed history into
/importfromcvs/trunk/ and file.el was part of it.
--
Eric Wong
^ permalink raw reply
* [PATCH] Make git send-email accept $EDITOR with arguments
From: Gustaf Hendeby @ 2007-12-20 20:14 UTC (permalink / raw)
To: git; +Cc: gitster, Gustaf Hendeby
Currently git send-email does not accept $EDITOR with arguments, eg,
emacs -nw, when starting an editor to produce a cover letter. This fixes
this in the simplest way possible, assume all spaces separates either
the command from the first argument, or two arguments. This should
work in most cases, but will break with quoted strings embedded spaces.
An example of a problematic case is when there is a space in the path
to the command.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
---
This is related to the problems recently observed in the built in git
commit and git tag. I guess the behavior of git send-email has been
the same from the start, but having it treat $EDITOR substantially
different from that of git commit and git tag seems like bug or at
least something that should be avoided.
I'm not completely satisfied with the problem with embedded spaces,
but my Perl skills aren't good enough to do anything about it. If
anyone have any suggestions on how to do it, it would be greatly
appreciated. None-the-less, even with this shortcoming, I think this
is a step in the right direction.
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 248d035..47ae77c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -400,7 +400,7 @@ EOT
close(C);
my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
- system($editor, $compose_filename);
+ system((split ' ', $editor), $compose_filename);
open(C2,">",$compose_filename . ".final")
or die "Failed to open $compose_filename.final : " . $!;
--
1.5.4.rc1.3.gc641f
^ permalink raw reply related
* Re: [PATCH] Make git send-email accept $EDITOR with arguments
From: Luciano Rocha @ 2007-12-20 20:32 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: git, gitster
In-Reply-To: <1198181646-28632-1-git-send-email-hendeby@isy.liu.se>
[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]
On Thu, Dec 20, 2007 at 09:14:06PM +0100, Gustaf Hendeby wrote:
<snip>
> I'm not completely satisfied with the problem with embedded spaces,
> but my Perl skills aren't good enough to do anything about it. If
> anyone have any suggestions on how to do it, it would be greatly
> appreciated. None-the-less, even with this shortcoming, I think this
> is a step in the right direction.
>
> git-send-email.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 248d035..47ae77c 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -400,7 +400,7 @@ EOT
> close(C);
>
> my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
> - system($editor, $compose_filename);
> + system((split ' ', $editor), $compose_filename);
That should be enough. Use system("$editor $compose_filename") to use
perl's implicit split or, in case of meta-characters in the string,
external sh -c.
Or always use the shell:
$shell = $ENV{SHELL} || "/bin/sh";
system($shell, "-c", "$editor $compose_filename");
BTW, maybe add a check for the return code?
system(...) == 0 or die "editor failed\n";
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problem with git-svn
From: Pascal Obry @ 2007-12-20 20:33 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20071220183007.GA26767@untitled>
Eric,
> Ah, oops, I was off-by-one with the revision number. But git-svn does
> look to be doing the right thing here, because it followed history into
> /importfromcvs/trunk/ and file.el was part of it.
Yes part of it but before the creation of the /importfromcvs/trunk/ that
was moved later as /trunk/PROJ.
In /importfromcvs/trunk/ there was many projects imported. One per one,
each time moving it into /trunk/PROJ.
If I look at history of /trunk/PROJ:
$ svn log svn+ssh://myserver/trunk/PROJ
The last revision is 45775, so I think git-svn should not look past this
revision. So I'm very surprised by the current behavior and think it is
a bug to import file.el at revision 9458. Note that the workaround for
me is to use:
$ git svn clone svn+ssh://myserver/trunk/PROJ --revision=45775:HEAD
But it would be lot cleaner to have git-svn handling this properly I think.
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: Problem with git-svn
From: Pascal Obry @ 2007-12-20 20:34 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20071220183007.GA26767@untitled>
Eric,
> Ah, oops, I was off-by-one with the revision number. But git-svn does
> look to be doing the right thing here, because it followed history into
> /importfromcvs/trunk/ and file.el was part of it.
Yes part of it but before the creation of the /importfromcvs/trunk/ that
was moved later as /trunk/PROJ.
In /importfromcvs/trunk/ there was many projects imported. One per one,
each time moving it into /trunk/PROJ.
If I look at history of /trunk/PROJ:
$ svn log svn+ssh://myserver/trunk/PROJ
The last revision is 45775, so I think git-svn should not look past this
revision. So I'm very surprised by the current behavior and think it is
a bug to import file.el at revision 9458. Note that the workaround for
me is to use:
$ git svn clone svn+ssh://myserver/trunk/PROJ --revision=45775:HEAD
But it would be lot cleaner to have git-svn handling this properly I think.
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* [PATCH] git-commit: add --verbatim to allow unstripped commit messages
From: Alex Riesen @ 2007-12-20 21:18 UTC (permalink / raw)
To: git
It also implies --allow-empty.
Sometimes the message just have to be the way user wants it.
For instance, a template can contain "#" characters, or the message
must be kept as close to its original source as possible for reimport
reasons. Or maybe the user just copied a shell script including its
comments into the commit message for future reference.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
I just happen to have a corporate template (for perforce messages, I
reuse it my git mirror repo) which contains "#" and at least one time
lost my bash comments in a commit.
Documentation/git-commit.txt | 7 ++++++-
builtin-commit.c | 10 ++++++++--
t/t7502-commit.sh | 17 +++++++++++++++++
3 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 4261384..862543f 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git-commit' [-a | --interactive] [-s] [-v] [-u]
[(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
[--allow-empty] [--no-verify] [-e] [--author <author>]
- [--] [[-i | -o ]<file>...]
+ [--verbatim] [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
@@ -95,6 +95,11 @@ OPTIONS
from making such a commit. This option bypasses the safety, and
is primarily for use by foreign scm interface scripts.
+--verbatim::
+ Inhibits stripping of leading and trailing spaces,
+ empty lines and #commentary from the commit message.
+ Implies --allow-empty.
+
-e|--edit::
The message taken from file with `-F`, command line with
`-m`, and from file with `-C` are usually used as the
diff --git a/builtin-commit.c b/builtin-commit.c
index 0a91013..cc77ba9 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -47,6 +47,7 @@ static char *logfile, *force_author, *template_file;
static char *edit_message, *use_message;
static int all, edit_flag, also, interactive, only, amend, signoff;
static int quiet, verbose, untracked_files, no_verify, allow_empty;
+static int verbatim_message;
static int no_edit, initial_commit, in_merge;
const char *only_include_assumed;
@@ -88,6 +89,7 @@ static struct option builtin_commit_options[] = {
OPT_BOOLEAN(0, "amend", &amend, "amend previous commit"),
OPT_BOOLEAN(0, "untracked-files", &untracked_files, "show all untracked files"),
OPT_BOOLEAN(0, "allow-empty", &allow_empty, "ok to record an empty change"),
+ OPT_BOOLEAN(0, "verbatim", &verbatim_message, "do not strip spaces and #comments from message"),
OPT_END()
};
@@ -346,7 +348,8 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (fp == NULL)
die("could not open %s", git_path(commit_editmsg));
- stripspace(&sb, 0);
+ if (!verbatim_message)
+ stripspace(&sb, 0);
if (signoff) {
struct strbuf sob;
@@ -512,6 +515,8 @@ static int parse_and_validate_options(int argc, const char *argv[],
no_edit = 1;
if (edit_flag)
no_edit = 0;
+ if (verbatim_message)
+ allow_empty = 1;
if (get_sha1("HEAD", head_sha1))
initial_commit = 1;
@@ -813,7 +818,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (p != NULL)
strbuf_setlen(&sb, p - sb.buf + 1);
- stripspace(&sb, 1);
+ if (!verbatim_message)
+ stripspace(&sb, 1);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
rollback_index_files();
die("no commit message? aborting commit.");
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 21ac785..42f98bc 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -89,4 +89,21 @@ test_expect_success 'verbose' '
'
+test_expect_success 'verbatim commit messages' '
+
+ echo >>negative &&
+ git add negative &&
+ { echo;echo "# text";echo; } >expect &&
+ git commit --verbatim -t expect -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d" |head -n 3 >actual &&
+ diff -u expect actual &&
+ git commit --verbatim -F expect -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual &&
+ git commit --verbatim -m "$(cat expect)" -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual
+
+'
+
test_done
--
1.5.4.rc1.33.gbd32b
^ permalink raw reply related
* Re: [PATCH] git-commit: add --verbatim to allow unstripped commit messages
From: Linus Torvalds @ 2007-12-20 21:40 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071220211835.GA3052@steel.home>
On Thu, 20 Dec 2007, Alex Riesen wrote:
>
> I just happen to have a corporate template (for perforce messages, I
> reuse it my git mirror repo) which contains "#" and at least one time
> lost my bash comments in a commit.
I think that this is a real bug, but I don't think this is something that
we should add a flag for.
Basically, I don't think we should really strip lines starting with '#'
unless *we* added them. In particular, I don't think we should strip them
at all unless we're running the editor.
So I think that instead of your thing, we should do somethign like the
appended, which allows you to do things like
git commit -m "# Message starting with a hash-mark"
which the current code makes impossible ("empty commit message").
That may be enough for your case, although it still does leave the "use
editor on a template thing", so if that is your usage scenario, I guess we
still do need a flag for it.
But even if we *do* add a flag (like "--verbatim") you should at the
*least* also then remove the
"# (Comment lines starting with '#' will not be included)\n"
printout! Which you didn't.
So I say NAK on this patch.
> It also implies --allow-empty.
I disagree with this one too.
We have had *way* too many problems with various tools generating bogus
empty commits. I get them from stgit users (and I think this is a serious
BUG in stgit, dammit!), but I have this memory of some other usage
scenario that did it too.
In other words, empty commits are almost always just bogus. And dammit, if
they aren't bogus, you should *say* so. No "implied" permissions, please.
If you really want your commits to be empty, what's the downside of just
adding an explicit "--allow-empty"?
Linus
---
builtin-commit.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 0a91013..4685938 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -434,7 +434,7 @@ static int message_is_empty(struct strbuf *sb, int start)
/* See if the template is just a prefix of the message. */
strbuf_init(&tmpl, 0);
if (template_file && strbuf_read_file(&tmpl, template_file, 0) > 0) {
- stripspace(&tmpl, 1);
+ stripspace(&tmpl, !no_edit);
if (start + tmpl.len <= sb->len &&
memcmp(tmpl.buf, sb->buf + start, tmpl.len) == 0)
start += tmpl.len;
@@ -813,7 +813,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (p != NULL)
strbuf_setlen(&sb, p - sb.buf + 1);
- stripspace(&sb, 1);
+ stripspace(&sb, !no_edit);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
rollback_index_files();
die("no commit message? aborting commit.");
^ permalink raw reply related
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: しらいしななこ @ 2007-12-20 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jörg Sommer
In-Reply-To: <7vabo7y762.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> Jörg Sommer <joerg@alea.gnuu.de> writes:
>
>> When it should go quick why don't use an alias. git stash can print the
>> list and everyone who wants a quick stash can create an alias for this.
>
> You are taking this completely backwards. The stash mechanism is all
> about creating a quickie temporary pair of commits. Anybody who wants
> otherwise can use alias or choose not to use stash at all.
You are of course right. That was the reason I made
git-stash command behave that way in the first place.
But I see that some people on the list find this behavior
dangerous and I can understand their fears. Until one
learns that one can go back to the state before running
git-stash by running "git-stash apply" soon after that,
it appears to one that the work is lost.
How about making this behavior configurable?
-- 8< --
[PATCH] Make "git stash" configurable
"git stash" without argument originally created an unnamed
stash, but some people felt this can be confusing to new
users. This introduces config variable stash.quick to
control this behavior.
The variable can take one of three values: true, false, ask.
When set to "true", the command allows to create a quick
stash without any user interaction. When set to "false",
the command shows the list of stash instead. When set to
"ask", the command asks the user.
For the first time users, when the variable is not set,
the command helps the user to set it interactively.
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
---
git-stash.sh | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index f16fd9c..4bb7134 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -192,6 +192,69 @@ apply_stash () {
fi
}
+allow_quick_stash () {
+
+ quick=$(git config stash.quick)
+ if test $? != 0
+ then
+ if ! test -t 0 || ! test -t 1
+ then
+ return 0
+ fi
+
+ echo '
+*** First time users ***
+
+"git stash" can create an unnamed stash entry without user interaction.
+This is a quick way to save away your work in progress. Some people
+find this behaviour confusing or dangerous to new users. You can
+configure the command to list the existing stash entries instead.'
+
+ while :
+ do
+ echo '
+Do you want the command without argument to always...
+
+1. Ask for confirmation
+2. Create an unnamed stash
+3. List existing stash entries
+'
+ printf 'Which one? [1/2/3] '
+ read reply
+ quick=
+ case "$reply" in
+ 1|A*) quick=ask ;;
+ 2|C*) quick=true ;;
+ 3|L*) quick=false ;;
+ *) continue ;;
+ esac
+ break
+ done
+ git config stash.quick $quick
+ echo '
+You can reconfigure this by editing your $HOME/.gitconfig file'
+
+ fi
+
+ case "$quick" in
+ true) return 0 ;;
+ false) return 1 ;;
+ ask) : do not return ;;
+ esac
+
+ if ! test -t 0 || ! test -t 1
+ then
+ return 0
+ fi
+
+ printf 'Do you want to create an unnamed stash? [Y/n] '
+ read reply
+ case "$reply" in
+ [nN]*) return 1 ;;
+ *) return 0 ;;
+ esac
+}
+
# Main command set
case "$1" in
list)
@@ -226,11 +289,16 @@ create)
create_stash "$*" && echo "$w_commit"
;;
*)
- if test $# -eq 0
+ if test $# -ne 0
+ then
+ usage
+ fi
+ if allow_quick_stash
then
save_stash && git-reset --hard
else
- usage
+ echo "*** Stash List ***"
+ list_stash
fi
;;
esac
--
1.5.3.7
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Find out how you can get spam free email.
http://www.bluebottle.com/tag/3
^ permalink raw reply related
* Re: [PATCH v2] builtin-tag.c: allow arguments in $EDITOR
From: Junio C Hamano @ 2007-12-20 22:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Luciano Rocha, git
In-Reply-To: <Pine.LNX.4.64.0712201255510.14355@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Anything wrong with that patch?
>
> http://article.gmane.org/gmane.comp.version-control.git/68444
I think Steven stopped after you poked holes in that patch.
The way scripted commands spawned editor is:
eval "${GIT_EDITOR:=vi}" '"$@"'
which meant that $IFS characters in $GIT_EDITOR separated words
and $environment_variables were substituted.
IOW, this is possible:
GIT_EDITOR='emacs -l $HOME/my-customization.el'
I think something like this patch is probably more appropriate.
It avoids potential bugs in splitting arguments by hand and lets the
shell deal with the issue.
---
builtin-tag.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index 274901a..fae2487 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -47,7 +47,19 @@ void launch_editor(const char *path, struct strbuf *buffer, const char *const *e
editor = "vi";
if (strcmp(editor, ":")) {
- const char *args[] = { editor, path, NULL };
+ size_t len = strlen(editor);
+ int i = 0;
+ const char *args[6];
+
+ if (strcspn(editor, "$ \t'") != len) {
+ /* there are specials */
+ args[i++] = "sh";
+ args[i++] = "-c";
+ args[i++] = "$0 \"$@\"";
+ }
+ args[i++] = editor;
+ args[i++] = path;
+ args[i] = NULL;
if (run_command_v_opt_cd_env(args, 0, NULL, env))
die("There was a problem with the editor %s.", editor);
^ permalink raw reply related
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Junio C Hamano @ 2007-12-20 22:31 UTC (permalink / raw)
To: しらいしななこ
Cc: git, Jörg Sommer
In-Reply-To: <200712202145.lBKLj7Fu015050@mi0.bluebottle.com>
しらいしななこ <nanako3@bluebottle.com> writes:
> How about making this behavior configurable?
First, as a general principle, I'd like to avoid having commands that
changes their behaviour drastically depending on who the user is. It
makes it harder for people experienced a bit more than totally new to
help others. If they are truly experts and are familiar about the
configuration stash.quick, then they will be fine, but others would say
"Well, it works for me -- 'git stash' itself won't stash but list. Why
isn't it working for you, I don't know" and scratch head.
Having said that, I reserve rights to change my mind later and start
liking this approach as a compromise.
There are a few suggestions and comments.
> +allow_quick_stash () {
> +
> + quick=$(git config stash.quick)
> + if test $? != 0
> + then
I think this is not a per-repository but per-person configuration (I
already said I do not want per-person configuration to affect the
fundamental behaviour of commands, but let's put that objection on hold
for now). "git config --global" would be more appropriate.
So if the user hasn't seen this behaviour before, then...
> + if ! test -t 0 || ! test -t 1
> + then
> + return 0
> + fi
If it is not interactively called, allow "git stash" sans parameters as
before. Nice attention to the details.
> + echo '
> +*** First time users ***
> ...
> + git config stash.quick $quick
> + echo '
> +You can reconfigure this by editing your $HOME/.gitconfig file'
> +
> + fi
Again, you would want --global here. Also hint about explicit "save"
and "list" in addition to "you can reconfigure" might be helpful.
> + case "$quick" in
> + true) return 0 ;;
> + false) return 1 ;;
> + ask) : do not return ;;
> + esac
> +
> + if ! test -t 0 || ! test -t 1
> + then
> + return 0
> + fi
Even if it is configured to 'ask', we allow it for non-interactive
session (aka scripts). Although I would agree with this logic, it could
be debatable.
> @@ -226,11 +289,16 @@ create)
> create_stash "$*" && echo "$w_commit"
> ;;
> *)
> - if test $# -eq 0
> + if test $# -ne 0
> + then
> + usage
> + fi
> + if allow_quick_stash
> then
> save_stash && git-reset --hard
> else
> - usage
> + echo "*** Stash List ***"
> + list_stash
> fi
I was scratching my head about this extra "echo" and tried your version
after removing it, to realize this is another nice attention to the
details. Without it, what's output from the command is not very clear
to people who do not know what "git stash" is configured to do for the
session.
^ permalink raw reply
* Re: [PATCH] git-commit: add --verbatim to allow unstripped commit messages
From: Alex Riesen @ 2007-12-20 23:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0712201324270.21557@woody.linux-foundation.org>
Linus Torvalds, Thu, Dec 20, 2007 22:40:13 +0100:
> On Thu, 20 Dec 2007, Alex Riesen wrote:
> >
> > I just happen to have a corporate template (for perforce messages, I
> > reuse it my git mirror repo) which contains "#" and at least one time
> > lost my bash comments in a commit.
>
> I think that this is a real bug, but I don't think this is something that
> we should add a flag for.
>
> Basically, I don't think we should really strip lines starting with '#'
> unless *we* added them. In particular, I don't think we should strip them
> at all unless we're running the editor.
Right
> That may be enough for your case, although it still does leave the "use
> editor on a template thing", so if that is your usage scenario, I guess we
> still do need a flag for it.
Yes, I afraid I need both. I use "git commit -t" almost (submission in
perforce takes careful planning) every day. I also would like to keep
the empty leading and trailing lines (perforce default GUI P4Win does
not show them, but our scripts which check the descriptions will test
the description text according to template which does have trailing
empty lines).
> But even if we *do* add a flag (like "--verbatim") you should at the
> *least* also then remove the
>
> "# (Comment lines starting with '#' will not be included)\n"
>
> printout! Which you didn't.
I did think about it. It wont be read, I believe (at least I ignore
the status listing git-commit generates today). But then, it can be
removed for verbatim message as no one (I think) will probably care.
Including the "Please..." so it does not look stupid in the commit
message later. Will do.
> > It also implies --allow-empty.
>
> I disagree with this one too.
>
I agree. Will remove (I am not even sure myself, why I did that. It is
not even tested)
^ permalink raw reply
* [PATCH] git-commit: add --verbatim to allow unstripped commit messages
From: Alex Riesen @ 2007-12-20 23:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <20071220233324.GB3052@steel.home>
Sometimes the message just have to be the way user wants it.
For instance, a template can contain "#" characters, or the message
must be kept as close to its original source as possible for reimport
reasons. Or maybe the user just copied a shell script including its
comments into the commit message for future reference.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Updated patch. It conflicts with yours a bit. Will update it
Documentation/git-commit.txt | 7 ++++++-
builtin-commit.c | 20 ++++++++++++++------
t/t7502-commit.sh | 18 ++++++++++++++++++
3 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 4261384..862543f 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git-commit' [-a | --interactive] [-s] [-v] [-u]
[(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
[--allow-empty] [--no-verify] [-e] [--author <author>]
- [--] [[-i | -o ]<file>...]
+ [--verbatim] [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
@@ -95,6 +95,11 @@ OPTIONS
from making such a commit. This option bypasses the safety, and
is primarily for use by foreign scm interface scripts.
+--verbatim::
+ Inhibits stripping of leading and trailing spaces,
+ empty lines and #commentary from the commit message.
+ Implies --allow-empty.
+
-e|--edit::
The message taken from file with `-F`, command line with
`-m`, and from file with `-C` are usually used as the
diff --git a/builtin-commit.c b/builtin-commit.c
index 0a91013..3127247 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -47,6 +47,7 @@ static char *logfile, *force_author, *template_file;
static char *edit_message, *use_message;
static int all, edit_flag, also, interactive, only, amend, signoff;
static int quiet, verbose, untracked_files, no_verify, allow_empty;
+static int verbatim_message;
static int no_edit, initial_commit, in_merge;
const char *only_include_assumed;
@@ -88,6 +89,7 @@ static struct option builtin_commit_options[] = {
OPT_BOOLEAN(0, "amend", &amend, "amend previous commit"),
OPT_BOOLEAN(0, "untracked-files", &untracked_files, "show all untracked files"),
OPT_BOOLEAN(0, "allow-empty", &allow_empty, "ok to record an empty change"),
+ OPT_BOOLEAN(0, "verbatim", &verbatim_message, "do not strip spaces and #comments from message"),
OPT_END()
};
@@ -346,7 +348,8 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (fp == NULL)
die("could not open %s", git_path(commit_editmsg));
- stripspace(&sb, 0);
+ if (!verbatim_message)
+ stripspace(&sb, 0);
if (signoff) {
struct strbuf sob;
@@ -404,10 +407,11 @@ static int prepare_log_message(const char *index_file, const char *prefix)
"#\n",
git_path("MERGE_HEAD"));
- fprintf(fp,
- "\n"
- "# Please enter the commit message for your changes.\n"
- "# (Comment lines starting with '#' will not be included)\n");
+ if (!verbatim_message)
+ fprintf(fp,
+ "\n"
+ "# Please enter the commit message for your changes.\n"
+ "# (Comment lines starting with '#' will not be included)\n");
if (only_include_assumed)
fprintf(fp, "# %s\n", only_include_assumed);
@@ -431,6 +435,9 @@ static int message_is_empty(struct strbuf *sb, int start)
const char *nl;
int eol, i;
+ if (verbatim_message && sb->len)
+ return 1;
+
/* See if the template is just a prefix of the message. */
strbuf_init(&tmpl, 0);
if (template_file && strbuf_read_file(&tmpl, template_file, 0) > 0) {
@@ -813,7 +820,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (p != NULL)
strbuf_setlen(&sb, p - sb.buf + 1);
- stripspace(&sb, 1);
+ if (!verbatim_message)
+ stripspace(&sb, 1);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
rollback_index_files();
die("no commit message? aborting commit.");
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 21ac785..d549728 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -89,4 +89,22 @@ test_expect_success 'verbose' '
'
+test_expect_success 'verbatim commit messages' '
+
+ echo >>negative &&
+ { echo;echo "# text";echo; } >expect &&
+ git commit --verbatim -t expect -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d" |head -n 3 >actual &&
+ diff -u expect actual &&
+ echo >>negative &&
+ git commit --verbatim -F expect -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual &&
+ echo >>negative &&
+ git commit --verbatim -m "$(cat expect)" -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual
+
+'
+
test_done
--
1.5.4.rc1.33.gbd32b
^ permalink raw reply related
* [PATCH] Only filter "#" comments from commits if the editor is used
From: Alex Riesen @ 2007-12-20 23:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <20071220233539.GC3052@steel.home>
Originally-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-commit.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 3127247..1356d20 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -441,7 +441,7 @@ static int message_is_empty(struct strbuf *sb, int start)
/* See if the template is just a prefix of the message. */
strbuf_init(&tmpl, 0);
if (template_file && strbuf_read_file(&tmpl, template_file, 0) > 0) {
- stripspace(&tmpl, 1);
+ stripspace(&tmpl, !no_edit);
if (start + tmpl.len <= sb->len &&
memcmp(tmpl.buf, sb->buf + start, tmpl.len) == 0)
start += tmpl.len;
@@ -821,7 +821,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
strbuf_setlen(&sb, p - sb.buf + 1);
if (!verbatim_message)
- stripspace(&sb, 1);
+ stripspace(&sb, !no_edit);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
rollback_index_files();
die("no commit message? aborting commit.");
--
1.5.4.rc1.33.gbd32b
^ permalink raw reply related
* Re: [PATCH] Only filter "#" comments from commits if the editor is used
From: Junio C Hamano @ 2007-12-20 23:39 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, git
In-Reply-To: <20071220233714.GD3052@steel.home>
Thanks.
^ 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