* Re: git blame not respecting --find-copies-harder ?
From: Sverre Rabbelier @ 2008-07-30 15:43 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Stephen R. van den Berg, Git Mailinglist
In-Reply-To: <20080730150123.GB9758@atjola.homenet>
On Wed, Jul 30, 2008 at 17:01, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> git blame doesn't know --find-copies-harder, it's -C -C for blame.
Shouldn't it have died with "don't know option --find-copies-harder" then?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Gitweb: Provide Git links in project list?
From: J.H. @ 2008-07-30 15:49 UTC (permalink / raw)
To: Robert Richter; +Cc: git
In-Reply-To: <20080730125743.GY15356@erda.amd.com>
Robert,
That is a kernel.org specific change - if the community at large wants
it I can dig the patch out (I likely didn't do it as it's own patch when
I did it, being young, naive and stupid at the time - I'm now slightly
older and slightly less naive now ;-)
But yeah - if people feel that's interesting I'm happy to rip it out
later today and submit it to the mailing list.
- John 'Warthog9' Hawley
On Wed, 2008-07-30 at 14:57 +0200, Robert Richter wrote:
> The Gitweb on git.kernel.org povides links to the Git repository for
> each project (git <git://...>). However, I did not find this feature
> in the current implementation of git_project_list_body(). Does
> somebody know if there is a patch available for this and if this could
> be added to gitweb?
>
> Thanks,
>
> -Robert
>
^ permalink raw reply
* Re: cvs diff -l equivalent?
From: Stephen R. van den Berg @ 2008-07-30 15:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.LSU.1.00.0807301553030.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>On Wed, 30 Jul 2008, Stephen R. van den Berg wrote:
>> Someone popped this question on me.
>I do not know cvs that well anymore. So I do not know what -l does. Care
>to explain?
Usage: cvs diff [-lR] [-k kopt] [format_options]
[[-r rev1 | -D date1] [-r rev2 | -D date2]] [files...]
-l Local directory only, not recursive
It shows the diff for all files in the current directory, nothing
deeper, nothing higher.
>> How many weeks are there in a lightyear?
>That is easy. 52 light ones.
I presume you mean "lightweeks", and yes, that would probably fit the bill :-).
--
Sincerely,
Stephen R. van den Berg.
^ permalink raw reply
* Re: Feature suggestion: git-hist
From: Avery Pennarun @ 2008-07-30 15:58 UTC (permalink / raw)
To: Santi Béjar; +Cc: H.Merijn Brand, Miklos Vajna, Lars Noschinski, git
In-Reply-To: <8aa486160807300823w3dfbdff2m4b9821d71779231d@mail.gmail.com>
On Wed, Jul 30, 2008 at 11:23 AM, Santi Béjar <sbejar@gmail.com> wrote:
> It cannot be described because there is no annotated tag before this
> commit. Add --always to show the abbreviated commit as fallback.
Or --tags to include non-annotated tags.
Avery
^ permalink raw reply
* Re: German translation of git man pages
From: Petr Baudis @ 2008-07-30 16:03 UTC (permalink / raw)
To: Fabio Scotoni; +Cc: git
In-Reply-To: <alpine.LNX.1.10.0807301604010.4094@hydra.esse.ch>
Hi!
On Wed, Jul 30, 2008 at 04:05:03PM +0200, Fabio Scotoni wrote:
> On Wed, 2008-07-30 at 13:18 +0200, David Soria Parra wrote:
>> You might want to provide a public repository, which we can pull from
>> and send you patches.
>
> Of course. Here it is: git://repo.or.cz/srv/git/gitman-de.git
(Your favorite public link-correcting service "pasky" offers
git://repo.or.cz/gitman-de.git
http://repo.or.cz/w/gitman-de.git
instead. ;-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: Gitweb: Provide Git links in project list?
From: Robert Richter @ 2008-07-30 16:11 UTC (permalink / raw)
To: J.H.; +Cc: git
In-Reply-To: <1217432970.2884.8.camel@localhost.localdomain>
On 30.07.08 08:49:30, J.H. wrote:
> That is a kernel.org specific change - if the community at large wants
> it I can dig the patch out (I likely didn't do it as it's own patch when
> I did it, being young, naive and stupid at the time - I'm now slightly
> older and slightly less naive now ;-)
>
> But yeah - if people feel that's interesting I'm happy to rip it out
> later today and submit it to the mailing list.
John, I would like the patch.
Yes, I have seen the commit as well and it is not the only change in
this commit. Also, if I got it right, the repository is not taken from
.git/cloneurl. So, with the current implementation the git url in the
summary page may be different to cloneurl. But this is not a major
issue.
It would be great if you could provide a patch with your changes for
gitweb.
Thanks,
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@amd.com
^ permalink raw reply
* Re: [PATCH] Glean libexec path from argv[0] for git-upload-pack and git-receive-pack.
From: Steve Haslam @ 2008-07-30 16:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Johannes Sixt
In-Reply-To: <alpine.LSU.1.00.0807301650060.3486@wbgn129.biozentrum.uni-wuerzburg.de>
[sorry, was intended to cc Johannes Sixt when I mailed the patch to the
list... not doing well with the recipient etiquette]
[and then Icedove decided it was going to send mail as HTML. This is so embarassing.]
Johannes Schindelin wrote:
>> diff --git a/upload-pack.c b/upload-pack.c
>> index c911e70..086eff6 100644
>> --- a/upload-pack.c
>> +++ b/upload-pack.c
>> @@ -616,6 +616,9 @@ int main(int argc, char **argv)
>> int i;
>> int strict = 0;
>>
>> + if (argv[0] && *argv[0])
>> + git_extract_argv0_path(argv[0]);
>> +
>>
>
> This is ugly. The called function should already do it itself.
>
Fair enough.
> Further, why not go the full nine yards and avoid the calculation
> altogether, until it is necessary? Then the change to add
> lookup_program_in_path() would be nice and non-intrusive.
git.c will always need to do the calculation, to determine which command
it is being invoked as, so is there much value in delaying until necessary?
If the code in git.c is left alone, then it needs to be eventually
duplicated in upload-pack.c and receive-pack.c, or in exec_cmd.c. [I
botched when sending out the patch originally and only sent it to
Johannes and not the list, so it's my fault that the history of how this
has evolved is unclear I'm afraid]
> IOW why not leave the function name as-is, and just enhance system_path()
> to have a static variable "initialized", which does the whole calculation?
> I.e. move the calculation from git.c to exec_cmd.c, but at the same time
> do it only when needed.
Hmm, system_path and setup_path both use argv0_path; git.c would need to
call an additional function in exec_cmd.c to get the "leafname" result
of the calculation, though.
> And your change to set argv0_path from receive-pack and upload-pack would
> be a second patch.
OK.
> And then the patch to add support to "glean" (did not know that word) the
> path from the PATH (lookup_program_in_path()) could come as a third patch.
I think that once git-upload-pack.c et al get the argv[0] path over to
setup_path() then there's nothing more to do; setup_path() already uses
argv0_path in its list of paths to try. I'm confused to the reference to
PATH, though: we're avoiding the PATH environment variable completely.
SRH
^ permalink raw reply
* Re: cvs diff -l equivalent?
From: Stephen R. van den Berg @ 2008-07-30 16:17 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200807301600.44205.trast@student.ethz.ch>
Thomas Rast wrote:
>Stephen R. van den Berg wrote:
>> Someone popped this question on me. The closest I got was:
>> git diff .
>> But that still recurses. Any solutions without patching?
>Maybe a scripted version? For just 'git diff .', this should work:
> git diff $(git ls-files . | grep -v /)
git diff $(git ls-files --exclude-standard . | fgrep -v /)
comes the closest, so it seems.
>That will still do the wrong thing if you diff against an older commit
>with a different list of files. In that case you need the list of
>files in the other side of the diff too:
> git diff HEAD^.. -- $(git ls-files . | grep -v /; git ls-tree HEAD^ | cut -f2)
This doesn't seem to do the right thing, it messes up with which commit we
diff.
--
Sincerely,
Stephen R. van den Berg.
How many weeks are there in a lightyear?
^ permalink raw reply
* Re: Merging submodules (was Re: Feature suggestion: git-hist)
From: H.Merijn Brand @ 2008-07-30 16:26 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Lars Noschinski, git
In-Reply-To: <FA2D570A-B2B1-4994-AA6A-9C0C55E69900@silverinsanity.com>
On Wed, 30 Jul 2008 11:15:55 -0400, Brian Gernhardt
<benji@silverinsanity.com> wrote:
>
> On Jul 30, 2008, at 9:58 AM, H.Merijn Brand wrote:
>
> > One (very) big disadvantage of SCCS is that commits are on a per-
> > file
> > basis, and only in a single directory. This drawback still haunts me
> > in
> > git, as my first attempts to convert were successful in a single
> > folder
> > and git cannot merge folders into a single project.
> >
> > Say I now have
> >
> > /work/src/project/.git
> > /work/src/project/module_a/.git
> > /work/src/project/module_b/.git
> > /work/src/project/module_c/.git
> >
> > Which are all converted repos from SCCS, I'd like to merge the three
> > module_# repos into the top level repo.
>
> Following the example of Linus, the following is completely untested.
>
> First you fetch all of the heads/tags/etc into the superproject with
> commands like
>
> git fetch module_a refs/heads/*:refs/remotes/module_a/*
> git fetch module_b refs/heads/*:refs/remotes/module_b/*
> git fetch module_c refs/heads/*:refs/remotes/module_c/*
All went well
> Then you do something like:
>
> rm -rf module_{a,b,c}/.git # Do this in a test repository, obviously...
> git add module_a module_b module_c
> git commit # Needed because '-s ours' uses current HEAD, not index
So far so good.
> git merge --no-commit -s ours module_a/master module_b/master module_c/master
$ git merge --no-commit -s ours fnc/master i00f000/master
i99f000/master include/master l00m000/master l01f000/master l02f000/master l03f000/master l06f000/master l90z000/master leerpl/master mutbev/master prtabel/master rpt/master tabellen/master zoomen/master Automatic merge went well; stopped before committing as requested
> git commit --amend
$ git commit --amend
fatal: You are in the middle of a merge -- cannot amend.
$ git status
# On branch master
nothing to commit (working directory clean)
When I start git-gui, it still shows a long commit message:
Merge commit 'fnc/master'; commit 'i00f000/master'; commit 'i99f000/master'; commit 'include/master'; commit 'l00m000/master'; commit 'l01f000/master'; commit 'l02f000/master'; commit 'l03f000/master'; commit 'l06f000/master'; commit 'l90z000/master'; commit 'leerpl/master'; commit 'mutbev/master'; commit 'prtabel/master'; commit 'rpt/master'; commit 'tabellen/master'; commit 'zoomen/master'
All other areas are clear
> From this point on, the project repository has a merged history of
> the sub-projects, and if anyone doesn't catch up and still makes a
> commit on a subproject you can use "git merge -s subtree" to merge it
> in anyway.
>
> You may need to "git rm --cached" some files after the "git add" step
> if your .gitignore files aren't perfect.
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: Feature suggestion: git-hist
From: Lars Noschinski @ 2008-07-30 16:34 UTC (permalink / raw)
To: Avery Pennarun
Cc: Santi Béjar, H.Merijn Brand, Miklos Vajna, Lars Noschinski,
git
In-Reply-To: <32541b130807300858r152d7428j404eaefc04f606@mail.gmail.com>
* Avery Pennarun <apenwarr@gmail.com> [08-07-30 18:26]:
>On Wed, Jul 30, 2008 at 11:23 AM, Santi Béjar <sbejar@gmail.com> wrote:
>> It cannot be described because there is no annotated tag before this
>> commit. Add --always to show the abbreviated commit as fallback.
>
>Or --tags to include non-annotated tags.
For the intended use case, --contains; as the OP wants to know the
oldest version, which contains this commit.
^ permalink raw reply
* Re: Gitweb: Provide Git links in project list?
From: Boyd Lynn Gerber @ 2008-07-30 16:41 UTC (permalink / raw)
To: J.H.; +Cc: Robert Richter, git
In-Reply-To: <1217432970.2884.8.camel@localhost.localdomain>
On Wed, 30 Jul 2008, J.H. wrote:
> That is a kernel.org specific change - if the community at large wants
> it I can dig the patch out (I likely didn't do it as it's own patch when
> I did it, being young, naive and stupid at the time - I'm now slightly
> older and slightly less naive now ;-)
>
> But yeah - if people feel that's interesting I'm happy to rip it out
> later today and submit it to the mailing list.
I would like to see the patch. I think it would be good to get it
included.
Thanks,
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* [PATCH] Add testcase to ensure merging an early part of a branch is done properly
From: Miklos Vajna @ 2008-07-30 17:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabfz7puk.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Wed, Jul 30, 2008 at 01:12:19AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> In addition, the message forgot to skip "refs/heads/" it prefixed from
> the
> output.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> * It is a bit surprising that after beating merge-in-C to death, we
> still find a minor breakage like this.
Uh-oh. Here is a testcase that fails with master, but passes with your
patch.
Thanks for catching this.
t/t7607-merge-early.sh | 39 +++++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
create mode 100755 t/t7607-merge-early.sh
diff --git a/t/t7607-merge-early.sh b/t/t7607-merge-early.sh
new file mode 100755
index 0000000..9dd3ac5
--- /dev/null
+++ b/t/t7607-merge-early.sh
@@ -0,0 +1,39 @@
+#!/bin/sh
+
+test_description='git-merge
+
+Testing merging an early part of a branch.'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo c0 > c0.c &&
+ git add c0.c &&
+ git commit -m c0 &&
+ git tag c0 &&
+ echo c1 > c1.c &&
+ git add c1.c &&
+ git commit -m c1 &&
+ git tag c1 &&
+ echo c2 > c2.c &&
+ git add c2.c &&
+ git commit -m c2 &&
+ git tag c2 &&
+ git reset --hard c0 &&
+ echo c3 > c3.c &&
+ git add c3.c &&
+ git commit -m c3 &&
+ git tag c3
+'
+
+cat >expected <<EOF
+Merge branch 'c2' (early part)
+EOF
+
+test_expect_success 'merge early part of c2' '
+ git merge c2~1 &&
+ git show -s --pretty=format:%s HEAD > actual &&
+ test_cmp actual expected
+'
+
+test_done
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: [PATCH 3/4] Add a new test for using a custom merge strategy
From: Miklos Vajna @ 2008-07-30 17:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabg09rye.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
On Tue, Jul 29, 2008 at 04:43:53PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> By the way, this eval shows why "theirs" cannot be a symmetric operation
> of "ours". You are taking the last remote HEAD even when you are merging
> more than one remote into the current branch at once. "ours" can be
> sensibly defined for an octopus, but "theirs" has this "which theirs"
> problem ;-)
Oh, well, sure. But _if_ it turns out there is a demand for that kind of
git-merge-theirs, then I suppose we could still give up if we are given
two or more remotes, just like merge-resolve and others do.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] Add a second testcase for handling invalid strategies in git-merge
From: Miklos Vajna @ 2008-07-30 17:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhca89s02.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 384 bytes --]
On Tue, Jul 29, 2008 at 04:42:53PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> True, but with the old code that might blindly have executed
> git-merge-index the test would also have failed, and you would want to
> tell two cases apart, wouldn't you?
Hmm, I wonder what is the right approach to test it. Should I exit with
a different error code with the strategy is invalid?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Replace uses of "git-var" with "git var"
From: Todd Zullinger @ 2008-07-30 17:48 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
I noticed while reading the git send-email documentation that it mentioned
git-var -l. I have hopefully fixed up all the places where git-var is used and
not broken anything.
Documentation/git-send-email.txt | 2 +-
contrib/examples/git-commit.sh | 6 +++---
contrib/examples/git-tag.sh | 2 +-
git-am.sh | 2 +-
ident.c | 2 +-
perl/Git.pm | 2 +-
var.c | 2 +-
7 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index afbb294..e2437f3 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -56,7 +56,7 @@ The --cc option must be repeated for each user you want on the cc list.
--from::
Specify the sender of the emails. This will default to
- the value GIT_COMMITTER_IDENT, as returned by "git-var -l".
+ the value GIT_COMMITTER_IDENT, as returned by "git var -l".
The user will still be prompted to confirm this entry.
--in-reply-to::
diff --git a/contrib/examples/git-commit.sh b/contrib/examples/git-commit.sh
index 2c4a406..5c72f65 100755
--- a/contrib/examples/git-commit.sh
+++ b/contrib/examples/git-commit.sh
@@ -443,7 +443,7 @@ fi | git stripspace >"$GIT_DIR"/COMMIT_EDITMSG
case "$signoff" in
t)
- sign=$(git-var GIT_COMMITTER_IDENT | sed -e '
+ sign=$(git var GIT_COMMITTER_IDENT | sed -e '
s/>.*/>/
s/^/Signed-off-by: /
')
@@ -535,8 +535,8 @@ esac
case "$no_edit" in
'')
- git-var GIT_AUTHOR_IDENT > /dev/null || die
- git-var GIT_COMMITTER_IDENT > /dev/null || die
+ git var GIT_AUTHOR_IDENT > /dev/null || die
+ git var GIT_COMMITTER_IDENT > /dev/null || die
git_editor "$GIT_DIR/COMMIT_EDITMSG"
;;
esac
diff --git a/contrib/examples/git-tag.sh b/contrib/examples/git-tag.sh
index e9f3a22..2c15bc9 100755
--- a/contrib/examples/git-tag.sh
+++ b/contrib/examples/git-tag.sh
@@ -164,7 +164,7 @@ git check-ref-format "tags/$name" ||
object=$(git rev-parse --verify --default HEAD "$@") || exit 1
type=$(git cat-file -t $object) || exit 1
-tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1
+tagger=$(git var GIT_COMMITTER_IDENT) || exit 1
test -n "$username" ||
username=$(git config user.signingkey) ||
diff --git a/git-am.sh b/git-am.sh
index 6aa8192..8f91a97 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -291,7 +291,7 @@ fi
ws=`cat "$dotest/whitespace"`
if test "$(cat "$dotest/sign")" = t
then
- SIGNOFF=`git-var GIT_COMMITTER_IDENT | sed -e '
+ SIGNOFF=`git var GIT_COMMITTER_IDENT | sed -e '
s/>.*/>/
s/^/Signed-off-by: /'
`
diff --git a/ident.c b/ident.c
index b35504a..09cf0c9 100644
--- a/ident.c
+++ b/ident.c
@@ -204,7 +204,7 @@ const char *fmt_ident(const char *name, const char *email,
if ((warn_on_no_name || error_on_no_name) &&
name == git_default_name && env_hint) {
fprintf(stderr, env_hint, au_env, co_env);
- env_hint = NULL; /* warn only once, for "git-var -l" */
+ env_hint = NULL; /* warn only once, for "git var -l" */
}
if (error_on_no_name)
die("empty ident %s <%s> not allowed", name, email);
diff --git a/perl/Git.pm b/perl/Git.pm
index d99e778..087d3d0 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -730,7 +730,7 @@ This suite of functions retrieves and parses ident information, as stored
in the commit and tag objects or produced by C<var GIT_type_IDENT> (thus
C<TYPE> can be either I<author> or I<committer>; case is insignificant).
-The C<ident> method retrieves the ident information from C<git-var>
+The C<ident> method retrieves the ident information from C<git var>
and either returns it as a scalar string or as an array with the fields parsed.
Alternatively, it can take a prepared ident string (e.g. from the commit
object) and just parse it.
diff --git a/var.c b/var.c
index 724ba87..f1eb314 100644
--- a/var.c
+++ b/var.c
@@ -5,7 +5,7 @@
*/
#include "cache.h"
-static const char var_usage[] = "git-var [-l | <variable>]";
+static const char var_usage[] = "git var [-l | <variable>]";
struct git_var {
const char *name;
--
1.6.0.rc1
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I am not young enough to know everything.
-- Oscar Wilde (1854-1900)
^ permalink raw reply related
* [PATCH v3] Advertise the ability to abort a commit
From: Anders Melchiorsen @ 2008-07-30 17:53 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Anders Melchiorsen
In-Reply-To: <20080730051059.GA4497@sigill.intra.peff.net>
An empty commit message is now treated as a normal situation, not an error.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
So, I decided that I find it wrong to promote functionality
that results in an error. The error is now changed into a
normal exit (with status code 1.)
builtin-commit.c | 4 +++-
t/t7502-commit.sh | 7 ++++---
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 9a11ca0..bc59718 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -555,6 +555,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix)
fprintf(fp,
"\n"
"# Please enter the commit message for your changes.\n"
+ "# To abort the commit, use an empty commit message.\n"
"# (Comment lines starting with '#' will ");
if (cleanup_mode == CLEANUP_ALL)
fprintf(fp, "not be included)\n");
@@ -1003,7 +1004,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
stripspace(&sb, cleanup_mode == CLEANUP_ALL);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
rollback_index_files();
- die("no commit message? aborting commit.");
+ fprintf(stderr, "Aborting commit due to empty commit message.\n");
+ exit(1);
}
strbuf_addch(&sb, '\0');
if (is_encoding_utf8(git_commit_encoding) && !is_utf8(sb.buf))
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 4f2682e..f111263 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -142,6 +142,7 @@ test_expect_success 'cleanup commit messages (strip,-F)' '
echo "sample
# Please enter the commit message for your changes.
+# To abort the commit, use an empty commit message.
# (Comment lines starting with '#' will not be included)" >expect
test_expect_success 'cleanup commit messages (strip,-F,-e)' '
@@ -149,7 +150,7 @@ test_expect_success 'cleanup commit messages (strip,-F,-e)' '
echo >>negative &&
{ echo;echo sample;echo; } >text &&
git commit -e -F text -a &&
- head -n 4 .git/COMMIT_EDITMSG >actual &&
+ head -n 5 .git/COMMIT_EDITMSG >actual &&
test_cmp expect actual
'
@@ -162,7 +163,7 @@ test_expect_success 'author different from committer' '
echo >>negative &&
git commit -e -m "sample"
- head -n 7 .git/COMMIT_EDITMSG >actual &&
+ head -n 8 .git/COMMIT_EDITMSG >actual &&
test_cmp expect actual
'
@@ -181,7 +182,7 @@ test_expect_success 'committer is automatic' '
# must fail because there is no change
test_must_fail git commit -e -m "sample"
) &&
- head -n 8 .git/COMMIT_EDITMSG | \
+ head -n 9 .git/COMMIT_EDITMSG | \
sed "s/^# Committer: .*/# Committer:/" >actual &&
test_cmp expect actual
'
--
1.5.6.4
^ permalink raw reply related
* Re: cvs diff -l equivalent?
From: Johannes Schindelin @ 2008-07-30 18:18 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080730155853.GA27166@cuci.nl>
Hi,
On Wed, 30 Jul 2008, Stephen R. van den Berg wrote:
> Johannes Schindelin wrote:
> >On Wed, 30 Jul 2008, Stephen R. van den Berg wrote:
> >> Someone popped this question on me.
>
> >I do not know cvs that well anymore. So I do not know what -l does. Care
> >to explain?
>
> Usage: cvs diff [-lR] [-k kopt] [format_options]
> [[-r rev1 | -D date1] [-r rev2 | -D date2]] [files...]
> -l Local directory only, not recursive
>
> It shows the diff for all files in the current directory, nothing
> deeper, nothing higher.
Okay. This is my version of a solution:
$ find . -maxdepth 1 -type f -print0 | xargs -0 git diff
And no, there is not an easier way. Probably since Git has a snapshot
based idea of the contents, i.e. it does not think that the files in a
revision are decoupled. Not even the ones in different directories.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Glean libexec path from argv[0] for git-upload-pack and git-receive-pack.
From: Johannes Schindelin @ 2008-07-30 18:21 UTC (permalink / raw)
To: Steve Haslam; +Cc: git, Johannes Sixt
In-Reply-To: <48909396.3080500@lastminute.com>
Hi,
On Wed, 30 Jul 2008, Steve Haslam wrote:
> I think that once git-upload-pack.c et al get the argv[0] path over to
> setup_path() then there's nothing more to do; setup_path() already uses
> argv0_path in its list of paths to try. I'm confused to the reference to
> PATH, though: we're avoiding the PATH environment variable completely.
There is an issue in setting up the argv0_path when Git is called as "git"
and resolved via the PATH: argv[0] then is literally "git".
And we need argv0_path for other things than just calling programs:
relative etc/gitconfig and libexecdir.
Ciao,
Dscho
^ permalink raw reply
* Re: Git Community Book
From: Junio C Hamano @ 2008-07-30 18:27 UTC (permalink / raw)
To: Bart Trojanowski; +Cc: git list
In-Reply-To: <20080730132044.GF17649@jukie.net>
Bart Trojanowski <bart@jukie.net> writes:
> Could you let me know what the biggest inaccuracies were? I would like
> to correct my mistakes and update the slides.
The one I offhand can recall was in your spoken part not on slides ("git
add -u" does not notice new files but does notice removed ones). Nothing
major, really.
^ permalink raw reply
* Re: [PATCH] format-patch: Produce better output with --inline or --attach
From: Kevin Ballard @ 2008-07-30 18:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, peff, Junio C Hamano
In-Reply-To: <alpine.LSU.1.00.0807301624410.3486@wbgn129.biozentrum.uni-wuerzburg.de>
On Jul 30, 2008, at 7:29 AM, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 29 Jul 2008, Kevin Ballard wrote:
>
>> MIME defines the encapsulation boundary as including the preceding
>> CRLF (or in
>
> This line will still be too long in git log's output, as well as in
> git
> shortlog's output. I thought we had a suggestion to use at most 76
> characters per line in SubmittingPatches, but apparently we don't.
Good point. I'll send another re-wrapped patch.
>> The second change is to always write the line termination character
>> (default: newline) even when using --inline or --attach. This is
>> simply
>> to improve the aesthetics of the resulting message. When using --
>> inline
>> an email client should render the resulting message identically to
>> the
>> non-inline version. And when using --attach this adds a blank line
>> preceding the attachment in the email, which is visually attractive.
>
> It appears that your patch has one uncontroversial and one
> controversial
> part, then.
Is this controversial? Nobody's objected so far. My goal with this
change is to make the --inline output render exactly the same as the
default output in a mail client. I can't think of any downside.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Avery Pennarun @ 2008-07-30 18:33 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Eyvind Bernhardsen, Dmitry Potapov, Johannes Schindelin,
Joshua Jensen, Junio C Hamano, git
In-Reply-To: <80518F08-A9A9-4190-9AC4-D24DD6A1188B@zib.de>
On 7/30/08, Steffen Prohaska <prohaska@zib.de> wrote:
> On Jul 29, 2008, at 11:17 PM, Eyvind Bernhardsen wrote:
> > I think the real penalty is that with autocrlf enabled, Git no longer
> > stores exactly what I committed.
>
> Git does *never* exactly store what you committed. Git compresses
> your data and creates packs containing many of your individual
> files in a single pack.
This is not really an argument; making perfectly reversible changes as
part of the storage process, then reversing them as part of the
retrieval process, doesn't count as not storing what I committed.
> What matters is that git gives you exactly back what you committed. It
> does so with core.autocrlf=true, unless you check out with a different
> setting for autocrlf.
You can tell that this statement isn't quite true because if you have
a file with mixed LF and CRLF line endings, which I do (thanks,
Windows!) then CRLF->LF conversion is not a reversible operation.
Interestingly LF->CRLF still is (because an LF->CRLF'd file will never
have a bare LF, and on such a subset of files, CRLF->LF is
reversible).
Also note that core.autocrlf=input is *definitely* not a perfectly
reversible operation.
And so here's the problem: svn hands you a file. It may or may not
have CRLFs in it, and the line endings may actually be a random mix of
LF and CRLF, as I am actually experiencing at the moment in a
particular repository at work. If core.autocrlf is anything other
than "false", git will modify the file, and git-svn won't be apply the
diff on the next revision.
It's conceivable that core.autocrlf=true will work if your svn
repository is pure and svn hands you files only with CRLF endings.
It's somewhat unlikely that most svn repositories are in that state
(remember: it has to be perfect in *every revision* for git-svn to
work).
So anyway, I can't see how git-svn can possibly work in the general
case if core.autocrlf is anything other than false *at git-svn fetch
time*. And that's what I do, and it works great, modulo a bunch of
stupid CRLFs that sneak into the repo via svn, but those can be fixed.
Someday we'll stop using svn, and git-filter-branch can fix them all
retroactively so that "blame" will work right.
Perhaps git-svn needs to actually ignore the core.autocrlf setting?
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH v2] Support copy and rename detection in fast-export.
From: Junio C Hamano @ 2008-07-30 18:35 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <bb6f213e0807300210r205846b4qffa9fc71d4aa6533@mail.gmail.com>
"Alexander Gavrilov" <angavrilov@gmail.com> writes:
>> If you see a copied or renamed entry, you emit "this old path to that old
>> path" first, and then say that same path got modified. It appears from my
>> quick glance of fast-import that touching the same path more than once in
>> a same commit like this sequence does would work fine (it will involve two
>> calls to tree_content_set() for the same path but that is not something it
>> has to forbid, and the function doesn't).
>
> I'm sorry, but I don't quite understand what are you suggesting by
> this paragraph.
Sorry for the unmarked remark --- this was not a question, suggestion nor
complaint, but just a plain observation. I should have ended the
paragraph with "--- I think it's all good." to avoid confusion.
>>> +export GIT_AUTHOR_NAME='A U Thor'
>>> +export GIT_COMMITTER_NAME='C O Mitter'
>>> +
>>> +test_expect_success 'setup copies' '
>>> +
>>> + git config --unset i18n.commitencoding &&
>>
>> These are somewhat unusual. Was there any reason for these exports and
>> config?
>>
>
> t9301-fast-export.sh earlier changes these parameters to test
> automatic conversion to utf8.
Yeah, I noticed that while looking at wider context, after I sent the
message you are responding to.
Anyway, thanks for the patch. Applied and pushed out.
^ permalink raw reply
* Re: [PATCH] format-patch: Produce better output with --inline or --attach
From: Kevin Ballard @ 2008-07-30 18:37 UTC (permalink / raw)
Cc: Johannes Schindelin, git, peff, Junio C Hamano
In-Reply-To: <B805BDA1-6C22-4488-B5F5-6DA8CC729C06@sb.org>
On Jul 30, 2008, at 11:30 AM, Kevin Ballard wrote:
>> Hi,
>>
>> On Tue, 29 Jul 2008, Kevin Ballard wrote:
>>
>>> MIME defines the encapsulation boundary as including the preceding
>>> CRLF (or in
>>
>> This line will still be too long in git log's output, as well as in
>> git
>> shortlog's output. I thought we had a suggestion to use at most 76
>> characters per line in SubmittingPatches, but apparently we don't.
>
> Good point. I'll send another re-wrapped patch.
Nevermind, looks like the previous one was already applied.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: [PATCH] format-patch: Produce better output with --inline or --attach
From: Junio C Hamano @ 2008-07-30 18:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kevin Ballard, git, peff
In-Reply-To: <alpine.LSU.1.00.0807301624410.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> The second change is to always write the line termination character
>> (default: newline) even when using --inline or --attach. This is simply
>> to improve the aesthetics of the resulting message. When using --inline
>> an email client should render the resulting message identically to the
>> non-inline version. And when using --attach this adds a blank line
>> preceding the attachment in the email, which is visually attractive.
>
> It appears that your patch has one uncontroversial and one controversial
> part, then.
Could you elaborate what's controversial about this?
^ permalink raw reply
* Re: [PATCH] Glean libexec path from argv[0] for git-upload-pack and git-receive-pack.
From: Steve Haslam @ 2008-07-30 18:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Johannes Sixt
In-Reply-To: <alpine.LSU.1.00.0807302020300.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 30 Jul 2008, Steve Haslam wrote:
>
>> I think that once git-upload-pack.c et al get the argv[0] path over to
>> setup_path() then there's nothing more to do; setup_path() already uses
>> argv0_path in its list of paths to try. I'm confused to the reference to
>> PATH, though: we're avoiding the PATH environment variable completely.
>>
>
> There is an issue in setting up the argv0_path when Git is called as "git"
> and resolved via the PATH: argv[0] then is literally "git".
>
> And we need argv0_path for other things than just calling programs:
> relative etc/gitconfig and libexecdir.
>
Ah, I see what you meant. And all setup_path() actually does is add to
the end of PATH. I should have understood before.
OK, I will split the patch up and tidy it.
SRH
^ 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