* Re: Compile fix for SCO OPenServer
From: Boyd Lynn Gerber @ 2008-07-31 0:00 UTC (permalink / raw)
To: Aidan Van Dyk; +Cc: Junio C Hamano, git
In-Reply-To: <20080730234455.GN10399@yugib.highrise.ca>
On Wed, 30 Jul 2008, Aidan Van Dyk wrote:
> * Boyd Lynn Gerber <gerberb@zenez.com> [080730 19:30]:
> > I have m4-1.4.3 at
> >
> > ftp://ftp.zenez.com/pub/zenez/prgms/m4-1.4.3-osr6-all.tar.gz
> >
> > I really have to be able to use configure for most of my OpenSource
> > Projects for SCO OS's.
> >
> > I made the changes so that most things work with the auto tools.
>
> I'm not a SCO guru by any means...
>
> I'm just a user on someone else's SCO machine, just trying to make sure
> that the software I write is "fairly portable"...
>
> I'm willing to carry a good and useful tool (like git) in my home
> directory in that endeavour, but I'm not carrying all of the GNU stack
> in my home directory so I can run configure git is a bit much ;-)
That make sense. All though m4 is
test5 > l /usr/local/bin/m4
-rwxr-xr-x 1 gerberb zenez 280524 Jul 23 2005 /usr/local/bin/m4
Which is not that big. I have it in my ~/.bin/ on my clients machines.
You really need a good m4 for most things. Sendmail expecially. Also for
the latest bind with the DNS security fix. I some times need bc as well.
test5 > l /usr/local/bin/bc
-rwxr-xr-x 1 bin bin 85088 May 19 17:20 /usr/local/bin/bc
> > I did a VM install of OpenServer 6 to try things out. I was able to get
> > your -Wall failure, but once I ran the CC=cc CXX=CC ./configure I was able
> > to run gmake without any errors. I did have to install the M4 from above
> > to get configure to work. So, the straight out of the box install has to
> > have gnu m4 to run configure.
>
> So configure.ac must have some magic in it that allows configure to
> notice -Wall doesn't work. You can see what it choose in
> config.mak.autogen I think. But I'm pretty glad for the kbuild style
> Makefile in git not requiring autoconf/automake/etc.
I do not see anything really obvious, but below is config.mak.autogen
test5 > cat config.mak.autogen
# git Makefile configuration, included in main Makefile
# config.mak.autogen. Generated from config.mak.in:config.mak.append by
configure.
CC = cc
CFLAGS = -Kalloca -Kthread
AR = gar
TAR = gtar
#INSTALL = @INSTALL@ # needs install-sh or install.sh in
sources
TCLTK_PATH = wish
prefix = /usr/local
exec_prefix = ${prefix}
bindir = ${exec_prefix}/bin
#gitexecdir = ${exec_prefix}/libexec/git-core/
datarootdir = @datarootdir@
template_dir = ${prefix}/share/git-core/templates/
mandir=${prefix}/man
srcdir = .
export exec_prefix mandir
export srcdir VPATH
ASCIIDOC8=
NEEDS_SSL_WITH_CRYPTO=
NO_OPENSSL=
NO_CURL=
NO_EXPAT=
NEEDS_LIBICONV=
NEEDS_SOCKET=YesPlease
NO_SYS_SELECT_H=
NO_D_INO_IN_DIRENT=
NO_D_TYPE_IN_DIRENT=YesPlease
NO_SOCKADDR_STORAGE=
NO_IPV6=
NO_C99_FORMAT=
NO_STRCASESTR=YesPlease
NO_MEMMEM=YesPlease
NO_STRLCPY=
NO_STRTOUMAX=
NO_SETENV=
NO_UNSETENV=
NO_MKDTEMP=YesPlease
NO_ICONV=
OLD_ICONV=
NO_DEFLATE_BOUND=
FREAD_READS_DIRECTORIES=UnfortunatelyYes
SNPRINTF_RETURNS_BOGUS=UnfortunatelyYes
# config.mak.append. Generated by configure.
> > -g and -O2 are mutually exclusive. You can have either one but not both.
>
> Yes, and I think the default to cc matches -g, not -O2, hence my
> failures unless setting -O2.
>
> > I do have tcl and tk
>
> I'm sure... I might even find it burried somewhere on this machine too,
> but I have no real need for it.
OK.
So what do you think we need to have. I really do not see the need for
__OPENSERVER__. Do you?
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: git help broken
From: Miklos Vajna @ 2008-07-31 0:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kevin Ballard, Git Mailing List
In-Reply-To: <alpine.LSU.1.00.0807310144040.3486@wbgn129.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
On Thu, Jul 31, 2008 at 01:44:36AM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > And from the patch, it is pretty obvious that it does not come close to
> > the "man" code path.
>
> Oh, so it was involved?
Yes. The command list is no longer loaded automatically and the default
for non-git commands on git help foo was 'gitfoo', I guess for
gittutorial and such manpages.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Aidan Van Dyk @ 2008-07-31 0:11 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.10.0807301747160.13032@xenau.zenez.com>
[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]
* Boyd Lynn Gerber <gerberb@zenez.com> [080730 20:00]:
> So what do you think we need to have. I really do not see the need for
> __OPENSERVER__. Do you?
No, I think I saw that long ago, when I said:
> Sorry, a bit premature on my end...
With SNPRINTF_RETURNS_BOGUS and NO_MKDTEMP and CFLAGS set for make, I
don't need any source code changes to compile on SCO.
And as long as I have GNU bash and diff available, the test suite passes
as well. Well, all except for t9500-gitweb-standalone-no-errors.sh:
[Thu Jul 31 00:08:46 2008] gitweb.perl: -T and -B not implemented on filehandles at /u/aidan/git/t/trash directory/../../gitweb/gitweb.perl line 2444.
Perl claims:
This is perl, v5.8.8 built for i586-pc-sysv5
But again, I don't plan on running gitweb on this SCO box either...
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Scott Chacon @ 2008-07-31 0:13 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git list
In-Reply-To: <B7697630-DF9C-4EF0-9D63-9E362CEE125B@wincent.com>
On Wed, Jul 30, 2008 at 4:48 PM, Wincent Colaiuta <win@wincent.com> wrote:
> El 30/7/2008, a las 21:32, Junio C Hamano escribió:
>
>> That's one valid approach. I or you might have taken a different avenue,
>> but after all, it's his book, not mine, not yours, nor git list's book.
>
> Funnily enough, he chose to title it the "Git Community Book". Hard to match
> Scott's enthusiasm; this is the second major initiative we've seen from him
> in the last few days (the other being git-scm.com itself) which to the
> casual onlooker might look like the "official" Git homepage and
> documentation, but in both cases development occurred behind the scenes and
> the list was only notified after the fact. Better late than never I suppose.
Not sure what else I could have done - I announced that I was starting
a documentation project like this about a week ago on this list, then
I started the book 3 days ago
(http://github.com/schacon/gitscm/commits/book) and announced it here
for initial review yesterday. I haven't told very many people about
it yet and I haven't linked to it from git-scm.com yet either. It's
been open source from the first minute on GitHub, and the link to the
source was on the website I posted here.
Same for the git-scm site - I started it on the 23rd and emailed Pasky
about it the next day, and the day after that he began submitting
patches to me for it and I announced it on this list. Am I missing
something here? Do you think I've been working on these secretly for
months, or something? If there is a better communication workflow, I
would be happy to do so.
I appreciate that you notice my enthusiasm, though. :)
Scott
>> We originally hoped (well, at least I did) that Scott's effort on his book
>> might help us in improving the User Manual as well, but the approach seems
>> to make it unlikely. But that is nothing to hold against him --- he is
>> doing his own thing in a way he feels is the best, and that's perfectly
>> fine. We lost nothing, perhaps except for a chance to cooperate a bit
>> better and to widen the community.
>
> Even though there might not be an automated way to get changes back from the
> fork, if there are clear improvements made then there is at least no legal
> obstacle to incorporating them back in, the only obstacle would be time and
> willingness to do so manually.
>
>>
> Cheers,
> Wincent
>
>
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Junio C Hamano @ 2008-07-31 0:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <7vej5b3ozz.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The idea is to compute, for each commit in the "full history" result set,
> the commit that should replace it in the simplified history. This
> replacement commit is defined as follows:
>
> * In any case, we first figure out the replacement commits of parents of
> the commit we are looking at. The commit we are looking at is
> rewritten as if its parents are replacement commits of its original
> parents.
>
> * If the commit is marked as TREESAME (i.e. it modifies the paths we are
> interested in), then the replacement commit is itself. IOW, the commit
> is not dropped from the final result.
A typo here. This comment should have said !TREESAME (the code is correct).
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Junio C Hamano @ 2008-07-31 0:30 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Schindelin, Julian Phillips, Scott Chacon, Petr Baudis,
git list
In-Reply-To: <B7697630-DF9C-4EF0-9D63-9E362CEE125B@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> Funnily enough, he chose to title it the "Git Community Book". Hard to
> match Scott's enthusiasm; this is the second major initiative we've
> seen from him in the last few days (the other being git-scm.com
> itself) which to the casual onlooker might look like the "official"
> Git homepage and documentation, but in both cases development occurred
> behind the scenes and the list was only notified after the fact.
I think your "Behind the scenes, after the fact" is being unnecessarily
harsh.
What counts is what happens now after the launch, when there are issues
identified that he could address on his side if he wanted to work with the
community. "Ignore and fork forever" may be to further fracture the
community, but for a book like his that has quite different aim than the
official manual set, it might be a sensible approach. You have to weigh
the pros and cons.
We've seen other comments raised to both the book and the git-scm.com site
on this list after they were announced. We'll see how they are addressed
in coming weeks. I think it is not too late to voice your negative
judgements only after seeing what happens.
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Boyd Lynn Gerber @ 2008-07-31 0:32 UTC (permalink / raw)
To: Aidan Van Dyk; +Cc: Junio C Hamano, git
In-Reply-To: <20080731001112.GP10399@yugib.highrise.ca>
On Wed, 30 Jul 2008, Aidan Van Dyk wrote:
> * Boyd Lynn Gerber <gerberb@zenez.com> [080730 20:00]:
> > So what do you think we need to have. I really do not see the need for
> > __OPENSERVER__. Do you?
>
> No, I think I saw that long ago, when I said:
> > Sorry, a bit premature on my end...
>
> With SNPRINTF_RETURNS_BOGUS and NO_MKDTEMP and CFLAGS set for make, I
> don't need any source code changes to compile on SCO.
>
> And as long as I have GNU bash and diff available, the test suite passes
> as well. Well, all except for t9500-gitweb-standalone-no-errors.sh:
> [Thu Jul 31 00:08:46 2008] gitweb.perl: -T and -B not implemented on filehandles at /u/aidan/git/t/trash directory/../../gitweb/gitweb.perl line 2444.
>
> Perl claims:
> This is perl, v5.8.8 built for i586-pc-sysv5
>
> But again, I don't plan on running gitweb on this SCO box either...
OK, thanks, I did not want to not respond if things were needed.
Thanks,
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-31 0:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Roman Zippel, Martin Langhoff, Tim Harper, Git Mailing List,
Johannes Sixt
In-Reply-To: <7vej5b3ozz.fsf@gitster.siamese.dyndns.org>
On Wed, 30 Jul 2008, Junio C Hamano wrote:
>
> I am not Roman, but so I do not know if I did what Roman wanted to, but
> here is a quick hack. "gitk --post-simplify -- kernel/printk.c" is
> slightly more readable than --full-history with this patch.
.. and if by "slightly", you mean "a lot", then yes.
Patch looks fine to me. I didn't look at the code logic very closely, but
I suspect that it's actually hard to get the right answer with broken
code, and the logic doesn't look broken. So Ack.
The filter-branch thing should probably be taught about this at least as
an option. I think it was Johannes Sixt that worried about that one. Added
to cc.
Linus
^ permalink raw reply
* [PATCH] documentation: user-manual: update "using-bisect" section
From: Christian Couder @ 2008-07-31 3:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Since version 1.5.6 "git bisect" doesn't use a "bisect" branch any
more, but the user manual had not been updated to reflect this.
So this patch does that and while at it also adds a few words about
"git bisect skip" and points user to the "git bisect" man page for
more information.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/user-manual.txt | 27 +++++++++++++++++++++------
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c5641af..50bf85f 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -479,10 +479,10 @@ Bisecting: 3537 revisions left to test after this
-------------------------------------------------
If you run "git branch" at this point, you'll see that git has
-temporarily moved you to a new branch named "bisect". This branch
-points to a commit (with commit id 65934...) that is reachable from
-"master" but not from v2.6.18. Compile and test it, and see whether
-it crashes. Assume it does crash. Then:
+temporarily moved you in "(no branch)". HEAD is now detached from any
+branch and points directly to a commit (with commit id 65934...) that
+is reachable from "master" but not from v2.6.18. Compile and test it,
+and see whether it crashes. Assume it does crash. Then:
-------------------------------------------------
$ git bisect bad
@@ -504,8 +504,7 @@ report with the commit id. Finally, run
$ git bisect reset
-------------------------------------------------
-to return you to the branch you were on before and delete the
-temporary "bisect" branch.
+to return you to the branch you were on before.
Note that the version which git-bisect checks out for you at each
point is just a suggestion, and you're free to try a different
@@ -528,6 +527,22 @@ $ git reset --hard fb47ddb2db...
then test, run "bisect good" or "bisect bad" as appropriate, and
continue.
+Instead of "git bisect visualize" and then "git reset --hard
+fb47ddb2db...", you might just want to tell git that you want to skip
+the current commit:
+
+-------------------------------------------------
+$ git bisect skip
+-------------------------------------------------
+
+In this case, though, git may not eventually be able to tell the first
+bad one between some first skipped commits and a latter bad commit.
+
+There are also ways to automate the bisecting process if you have a
+test script that can tell a good from a bad commit. See
+linkgit:git-bisect[1] for more information about this and other "git
+bisect" features.
+
[[naming-commits]]
Naming commits
--------------
--
1.6.0.rc0.42.g186458.dirty
^ permalink raw reply related
* Re: git citool/gui bug
From: Shawn O. Pearce @ 2008-07-31 3:23 UTC (permalink / raw)
To: Leandro Lucarella; +Cc: git
In-Reply-To: <20080730185306.GV7616@integratech.com.ar>
Leandro Lucarella <llucarella@integratech.com.ar> wrote:
> Hi! I think I've hit a really silly bug in citool/gui:
>
> git citool shows:
>
> new file mode 100644 # black
> @@ -0,0 +1,5 @@ # blue
> + # green
> =============== # orange
> +Hello World!!!! # green
> =============== # orange
> + # green
Hmph. Don't put 7 = on a line together. Or 7 < or 7 > for that
matter. It confuses some git related tools like git-rerere,
the template pre-commit hook, and git-gui.
In this case we think these are the lines between two hunks in a
merge conflict, so we are showing them specially to you. Just in
case you staged a conflicted hunk by accident during a merge you
want it to stand out to help you notice the error.
Yes, it would be nice if git-gui knew this wasn't actually a merge
conflict but was instead proper text. Sadly it isn't that smart.
--
Shawn.
^ permalink raw reply
* Re: q: git-fetch a tad slow?
From: Shawn O. Pearce @ 2008-07-31 4:45 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080730190657.GC26389@elte.hu>
Ingo Molnar <mingo@elte.hu> wrote:
> alas, fetching still seems to be slow:
>
> titan:~/tip> time git-fetch origin
>
> real 0m5.112s
> user 0m0.972s
> sys 0m3.380s
What version of git are dealing with on the client side?
I only have a MacBook Pro (2.4 GHz Intel Core 2 Duo) and I'm getting
fetch times of ~472 ms over git:// to your -tip.git tree and ~128
ms for strictly local fetch. If your SSH overhead is ~300 ms this
is only a ~700 ms real time for `git fetch origin`, not 5100 ms.
Is your git-fetch a shell script? Or a compiled binary? The port
into C made it go _much_ faster, even though it is still a naive
O(N^2) matching algorithm. Yea, we still should fix that, but
I think an upgrade to 1.5.4 or later would make the client side
improve consideribly.
--
Shawn.
^ permalink raw reply
* [PATCH] git-svn now work with crlf convertion enabled.
From: Alexander Litvinov @ 2008-07-31 5:43 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <alpine.DEB.1.00.0807231117290.2830@eeepc-johanness>
Make git-svn works with crlf (or any other) file content convertion enabled.
When we modify file content SVN cant apply its delta to it. To fix this
situation I take full file content from SVN as next revision. This is
dump and slow but it works.
---
git-svn.perl | 34 +++++++++++++++++++---------------
1 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index cf6dbbc..606a177 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -28,6 +28,7 @@ sub fatal (@) { print STDERR "@_\n"; exit 1 }
require SVN::Core; # use()-ing this causes segfaults for me... *shrug*
require SVN::Ra;
require SVN::Delta;
+require SVN::Client;
if ($SVN::Core::VERSION lt '1.1.0') {
fatal "Need SVN::Core 1.1.0 or better (got $SVN::Core::VERSION)";
}
@@ -3075,6 +3076,7 @@ sub new {
my $self = SVN::Delta::Editor->new;
bless $self, $class;
$self->{c} = $git_svn->{last_commit} if exists $git_svn->{last_commit};
+ $self->{url} = $git_svn->{url};
$self->{empty} = {};
$self->{dir_prop} = {};
$self->{file_prop} = {};
@@ -3214,30 +3216,32 @@ sub change_file_prop {
sub apply_textdelta {
my ($self, $fb, $exp) = @_;
- my $fh = IO::File->new_tmpfile;
- $fh->autoflush(1);
- # $fh gets auto-closed() by SVN::TxDelta::apply(),
- # (but $base does not,) so dup() it for reading in close_file
- open my $dup, '<&', $fh or croak $!;
+
my $base = IO::File->new_tmpfile;
$base->autoflush(1);
if ($fb->{blob}) {
print $base 'link ' if ($fb->{mode_a} == 120000);
my $size = $::_repository->cat_blob($fb->{blob}, $base);
die "Failed to read object $fb->{blob}" if ($size < 0);
-
- if (defined $exp) {
- seek $base, 0, 0 or croak $!;
- my $got = ::md5sum($base);
- die "Checksum mismatch: $fb->{path} $fb->{blob}\n",
- "expected: $exp\n",
- " got: $got\n" if ($got ne $exp);
- }
}
seek $base, 0, 0 or croak $!;
- $fb->{fh} = $dup;
+
+ my $fh = IO::File->new_tmpfile;
+ $fh->autoflush(1);
+
+ $fb->{fh} = $fh;
$fb->{base} = $base;
- [ SVN::TxDelta::apply($base, $fh, undef, $fb->{path}, $fb->{pool}) ];
+
+ my $url = $self->{url};
+ $url =~ s/\/$//;
+ $url .= '/';
+ $url .= $fb->{path};
+
+ my $rev = $self->{file_prop}->{$fb->{path}}->{'svn:entry:committed-rev'};
+ die ("Can't find $fb->{path} revision") unless defined $rev;
+
+ my $ctx = SVN::Client->new();
+ $ctx->cat($fh, $url, $rev);
}
sub close_file {
--
1.5.6.2
^ permalink raw reply related
* Re: [PATCH v3] Advertise the ability to abort a commit
From: Jeff King @ 2008-07-31 5:50 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git, gitster
In-Reply-To: <1217440391-13259-1-git-send-email-mail@cup.kalibalik.dk>
On Wed, Jul 30, 2008 at 07:53:11PM +0200, Anders Melchiorsen wrote:
> An empty commit message is now treated as a normal situation, not an error.
As others have commented, I think the right way to say this is probably
"it is not reported to the user as an error, but still exits with a
non-zero exit status".
And I think it looks better.
But:
> "# Please enter the commit message for your changes.\n"
> + "# To abort the commit, use an empty commit message.\n"
> "# (Comment lines starting with '#' will ");
I still prefer a shortened version of these three lines, as I mentioned
earlier.
-Peff
^ permalink raw reply
* Re: [PATCH] format-patch: Produce better output with --inline or --attach
From: Jeff King @ 2008-07-31 5:52 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <B805BDA1-6C22-4488-B5F5-6DA8CC729C06@sb.org>
On Wed, Jul 30, 2008 at 11:30:32AM -0700, Kevin Ballard wrote:
>>> The second change is to always write the line termination character
>>> (default: newline) even when using --inline or --attach. This is
>> 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.
No. I didn't comment on it in my earlier response because I don't really
care. But I certainly have no problem with it, and it is probably an
improvement.
-Peff
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Alexander Litvinov @ 2008-07-31 5:57 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <200807311243.35219.litvinov2004@gmail.com>
> Make git-svn works with crlf (or any other) file content convertion
> enabled.
>
> When we modify file content SVN cant apply its delta to it. To fix this
> situation I take full file content from SVN as next revision. This is
> dump and slow but it works.
Sorry for the noise.
git-svn fetch files with this patch but I have found that git-svn use
git-hash-object and provide file name to store into stdin. As far as file is
a temp file git-hash-object can't correctly apply crlf convertion for the
file.
As a conclusion: git-svn does not apply crlf convertion on files being stored
into git repo. This make my patch useless.
^ permalink raw reply
* Re: [PATCH v3] Advertise the ability to abort a commit
From: Junio C Hamano @ 2008-07-31 5:58 UTC (permalink / raw)
To: Jeff King; +Cc: Anders Melchiorsen, git
In-Reply-To: <20080731055024.GA17652@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Jul 30, 2008 at 07:53:11PM +0200, Anders Melchiorsen wrote:
>
>> An empty commit message is now treated as a normal situation, not an error.
>
> As others have commented, I think the right way to say this is probably
> "it is not reported to the user as an error, but still exits with a
> non-zero exit status".
>
> And I think it looks better.
>
> But:
>
>> "# Please enter the commit message for your changes.\n"
>> + "# To abort the commit, use an empty commit message.\n"
>> "# (Comment lines starting with '#' will ");
>
> I still prefer a shortened version of these three lines, as I mentioned
> earlier.
I tend to agree; please make it so ;-)
^ permalink raw reply
* Re: [PATCH] Replace uses of "git-var" with "git var"
From: Junio C Hamano @ 2008-07-31 5:59 UTC (permalink / raw)
To: Todd Zullinger; +Cc: git
In-Reply-To: <20080730174833.GZ5655@inocybe.teonanacatl.org>
Thanks, applied.
^ permalink raw reply
* Re: [PATCH] documentation: user-manual: update "using-bisect" section
From: Junio C Hamano @ 2008-07-31 5:59 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20080731052240.23455ddb.chriscool@tuxfamily.org>
Thanks, applied.
^ permalink raw reply
* [PATCH] Advertise the ability to abort a commit
From: Jeff King @ 2008-07-31 6:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Anders Melchiorsen
In-Reply-To: <7vwsj23896.fsf@gitster.siamese.dyndns.org>
From: Anders Melchiorsen <mail@cup.kalibalik.dk>
We explicitly let the user know that an empty commit message
will abort the commit. At the same time, we take the
opportunity to reword the template text a bit to keep it
more compact.
This patch also makes the "fatal: empty commit message?"
warning a bit less scary, since this is now a "feature"
instead of an error. However, we retain the non-zero exit
status to indicate to callers that nothing was committed.
[jk: I compacted the text and expanded the commit message
from Anders' original patch]
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-commit.c | 18 ++++++++++++------
t/t7502-commit.sh | 4 ++--
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 9a11ca0..b783e6e 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -554,13 +554,18 @@ static int prepare_to_commit(const char *index_file, const char *prefix)
fprintf(fp,
"\n"
- "# Please enter the commit message for your changes.\n"
- "# (Comment lines starting with '#' will ");
+ "# Please enter the commit message for your changes.");
if (cleanup_mode == CLEANUP_ALL)
- fprintf(fp, "not be included)\n");
+ fprintf(fp,
+ " Lines starting\n"
+ "# with '#' will be ignored, and an empty"
+ " message aborts the commit.\n");
else /* CLEANUP_SPACE, that is. */
- fprintf(fp, "be kept.\n"
- "# You can remove them yourself if you want to)\n");
+ fprintf(fp,
+ " Lines starting\n"
+ "# with '#' will be kept; you may remove them"
+ " yourself if you want to.\n"
+ "# An empty message aborts the commit.\n");
if (only_include_assumed)
fprintf(fp, "# %s\n", only_include_assumed);
@@ -1003,7 +1008,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..3eb9fae 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -141,8 +141,8 @@ test_expect_success 'cleanup commit messages (strip,-F)' '
echo "sample
-# Please enter the commit message for your changes.
-# (Comment lines starting with '#' will not be included)" >expect
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit." >expect
test_expect_success 'cleanup commit messages (strip,-F,-e)' '
--
1.6.0.rc1.168.g8c00d.dirty
^ permalink raw reply related
* Re: git blame not respecting --find-copies-harder ?
From: Jeff King @ 2008-07-31 6:48 UTC (permalink / raw)
To: sverre; +Cc: Björn Steinbrink, Stephen R. van den Berg, Git Mailinglist
In-Reply-To: <bd6139dc0807300843l1d42d6fep95f6c99fe6e0ea0@mail.gmail.com>
On Wed, Jul 30, 2008 at 05:43:52PM +0200, Sverre Rabbelier wrote:
> 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?
Unfortunately, it _does_ know --find-copies-harder, because unknown
options get sent to the revision option parser, which chains to the diff
option parser. So it recognizes --find-copies-harder, but just sets a
flag that doesn't do what we expect.
I'm not sure if there is a simple fix. Does blame actually need the diff
option parsing? If not, then we might be able to pass a flag to
parse_revision_opt that says "don't do diff options, too".
-Peff
^ permalink raw reply
* [StGit RFC] Pull request for build/install work
From: Daniel White @ 2008-07-31 6:29 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0807270121x43b0a454g1042c0cfe650f2c1@mail.gmail.com>
Changes are on my experimental branch
at git://repo.or.cz/stgit/dwhite.git.
Fixed some old cruft causing problems when building/installing the
documentation and added new targets for streamlining the process. The
end result being fairly similar to Git's install process.
Daniel White (7):
Fix Makefile to correctly pass prefix option
Remove variables regarding section 7 man pages
Fix default install location for manpages
Add install-doc target to makefile
Add install-html target to makefile
Remove installation of documentation from setup.py
Updated INSTALL with documentation of Makefile
Documentation/Makefile | 25 ++++++++++++-------------
INSTALL | 15 ++++++++++-----
Makefile | 12 +++++++++---
setup.py | 2 +-
4 files changed, 32 insertions(+), 22 deletions(-)
--
Daniel White
^ permalink raw reply
* Re: git blame not respecting --find-copies-harder ?
From: Junio C Hamano @ 2008-07-31 7:05 UTC (permalink / raw)
To: Jeff King
Cc: sverre, Björn Steinbrink, Stephen R. van den Berg,
Git Mailinglist
In-Reply-To: <20080731064814.GA32431@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Jul 30, 2008 at 05:43:52PM +0200, Sverre Rabbelier wrote:
>
>> 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?
>
> Unfortunately, it _does_ know --find-copies-harder, because unknown
> options get sent to the revision option parser, which chains to the diff
> option parser. So it recognizes --find-copies-harder, but just sets a
> flag that doesn't do what we expect.
>
> I'm not sure if there is a simple fix. Does blame actually need the diff
> option parsing? If not, then we might be able to pass a flag to
> parse_revision_opt that says "don't do diff options, too".
Sigh...
We can probably pick up the result revision parser parsed out of
revs.diffopt, and then tweak "opt" with it, perhaps like this.
builtin-blame.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index 8b6b09b..4ea3431 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -2346,6 +2346,10 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
parse_done:
argc = parse_options_end(&ctx);
+ if (DIFF_OPT_TST(&revs.diffopt, FIND_COPIES_HARDER))
+ opt |= (PICKAXE_BLAME_COPY | PICKAXE_BLAME_MOVE |
+ PICKAXE_BLAME_COPY_HARDER);
+
if (!blame_move_score)
blame_move_score = BLAME_DEFAULT_MOVE_SCORE;
if (!blame_copy_score)
^ permalink raw reply related
* Re: Merging submodules (was Re: Feature suggestion: git-hist)
From: H.Merijn Brand @ 2008-07-31 7:21 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Lars Noschinski
In-Reply-To: <20080730230336.GA6481@Hermes>
[-- Attachment #1: Type: text/plain, Size: 5759 bytes --]
On Wed, 30 Jul 2008 19:03:37 -0400, Brian Gernhardt
<benji@silverinsanity.com> wrote:
> This message got eaten by a syntax error somewhere. This is a re-send, sorry for any duplicate messages.
>
> On Jul 30, 2008, at 12:26 PM, H.Merijn Brand wrote:
>
> > On Wed, 30 Jul 2008 11:15:55 -0400, Brian Gernhardt
> > <benji@silverinsanity.com> wrote:
> >
> > > 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.
>
> Hm. I did mention this was completely untested, yes? The problem comes
> from the fact that '-s ours' wants to use HEAD, not the index. But you
> can't amend a normal commit into a merge, apparently. And I don't think
> you want a commit that adds the files and a commit that "does the merge"
> as two separate steps.
>
> Well, I don't know how to make the porcelain do this then. But the
> plumbing can definitely do it. Hopefully someone more used to doing
> strange things like this can give a simpler recipe, but this should
> work.
>
> # First reset to the commit you made with all the modules added.
> vim commit-message # Create a merge message
> commit=$(git commit-tree HEAD: -p HEAD^ -p module_a/master -p
^^^^^^^^
had to remove that part
> module_b/master -p module_c/master < commit-message)
> git update-ref HEAD $commit # Update your current ref
Some history
---
I'm aware I started at the wrong end of being a git user. I had to move
from SCCS to `something better', and at that point only git, svn, and
hq seemed to be likely candidates.
hq being python, and our company not using python, but perl, made that
an easy drop. I gave up compiling svn on HP-UX in 64bit mode after
about a week, mainly because it depended on way too many things, and
the new VCS has to run on this platform, as it is our main development
system. I got git up and running in two days (compile in less than two
hours, but then I got to chase HP-UX and 64bit oddities).
By the I knew a lot about the git source code, make files, and test
scripts, but still had no idea about the whole plumbing/porcelain
approach. The plan was to make that someone else's job.
Once it was up and running, I had to create a way to convert all our
SCCS repo's to git, so we could get started and test if it met our
needs. That part went smooth, and with a little help from Sam Villain
to get some speed into the conversions using git-fast-import, it is now
available to the public on CPAN as VCS::SCCS, with git2sccs in the
examples folder.
Using git-gui and gitk my users were enthousiastic, and they saw all
the advantages of using git over SCCS. Of course, with every change
there are a few (serious) drawbacks, but we have to live with those.
Being a perl5 porter/maintainer, I was used to p4v (perforce) and still
wonder why there are two GUI's instead of just one, and why they don't
offer the functionality I love in p4v. Not that I think perforce is
better than git, but their GUI certainly is.
---
So, back to this merging issue. Now you might understand why I have all
those `silly' questions and have (still) no good idea of what all these
commands do. (The person that were to do all that never came into the
picture). I'm learning.
I'm VERY happy and thankful for the help I get from you here, and I get
the impression that my feedback on getting git running in our somewhat
different environment to you is also appreciated.
I had to cut down my number of modules to merge, as I got an error that
the maximum number of merges was 16. I had 18.
I will now be playing with the results a bit. I have attached the
script, in case you might want to use it in documentation or examples.
For now, all the mods are hardcoded. No arguments and so on.
Again, Thanks!
$ bash git-merge-mods.sh
Re-initialize GIT repo
Initialized empty Git repository in /work/lep/4gl/.git/
Recovering original module repo's
Fetching for i00f000
remote: Counting objects: 24, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 24 (delta 9), reused 24 (delta 9)
Unpacking objects: 100% (24/24), done.
From i00f000
* [new branch] master -> i00f000/master
Fetching for i99f000
:
:
Receiving objects: 100% (356/356), 139.05 KiB, done.
Resolving deltas: 100% (180/180), done.
From rpt
* [new branch] master -> rpt/master
Removing module repo's
Adding modules
Commit
Merge
Automatic merge went well; stopped before committing as requested
Commit
=========
53229f046c5d85d11bbd500cf04b468fd3f62c08
=========
Update
$
--
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/
[-- Attachment #2: git-merge-mods.sh --]
[-- Type: application/x-shellscript, Size: 1057 bytes --]
^ permalink raw reply
* [PATCH] diff: add ruby funcname pattern
From: Giuseppe Bilotta @ 2008-07-31 7:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Giuseppe Bilotta
Provide a regexp that catches class, module and method definitions in
Ruby scripts, since the built-in default only finds classes.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
diff.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index cbf2547..c253015 100644
--- a/diff.c
+++ b/diff.c
@@ -1381,6 +1381,7 @@ static struct builtin_funcname_pattern {
"[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
"[ ]*([^;]*\\)$" },
{ "tex", "^\\(\\\\\\(sub\\)*section{.*\\)$" },
+ { "ruby", "^\\s*\\(\\(class\\|module\\|def\\)\\s.*\\)$" },
};
static const char *diff_funcname_pattern(struct diff_filespec *one)
--
1.5.6.3
^ permalink raw reply related
* Re: git blame not respecting --find-copies-harder ?
From: Jeff King @ 2008-07-31 7:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: sverre, Björn Steinbrink, Stephen R. van den Berg,
Git Mailinglist
In-Reply-To: <7vfxpq3559.fsf@gitster.siamese.dyndns.org>
On Thu, Jul 31, 2008 at 12:05:22AM -0700, Junio C Hamano wrote:
> We can probably pick up the result revision parser parsed out of
> revs.diffopt, and then tweak "opt" with it, perhaps like this.
That is a sensible solution for this option, but I have to wonder: how
many other such ineffective options are hiding? How many of them
actually have a matching meaning in git-blame? E.g., what does "git
blame --name-only" mean?
Perhaps we should simply not worry about those ones, as people are
unlikely to try using them, and it is easy to say "has no impact,
because it doesn't make sense with blame." The truly confusing ones are
ones you _expect_ to do something, but don't (like
--find-copies-harder).
I took a look at implementing a "don't parse the diff options" flag, but
it is much larger than that. The revision parser understands a lot of
options that don't really make sense for blame (or shortlog), like
"--full-diff". So perhaps it is best to just fix this one (which we have
actually had a bug report about) and not worry about the rest.
-Peff
^ 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