* Re: [PATCH v3] Advertise the ability to abort a commit
From: Avery Pennarun @ 2008-07-30 21:09 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Anders Melchiorsen, git, gitster, peff
In-Reply-To: <E2809CE9-1DEB-48DA-8E42-8BEAB376FED2@silverinsanity.com>
On 7/30/08, Brian Gernhardt <benji@silverinsanity.com> wrote:
> 'git commit' should return with an error any time it does not commit.
> Otherwise scripts could get confused, thinking everything went fine when
> nothing actually got done. Here, the user decided something was in error
> and canceled out, the same way using using ^C causes a non-zero return
> status.
The patch uses a non-zero exit code, which is an error status. But as
that's the case, I'm not sure why it's described in the changelog as
treating it "not as an error."
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH v3] Advertise the ability to abort a commit
From: Brian Gernhardt @ 2008-07-30 21:16 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Anders Melchiorsen, git, gitster, peff
In-Reply-To: <32541b130807301409t2f1f3a80n44c62447c628f03a@mail.gmail.com>
On Jul 30, 2008, at 5:09 PM, Avery Pennarun wrote:
> On 7/30/08, Brian Gernhardt <benji@silverinsanity.com> wrote:
>> 'git commit' should return with an error any time it does not commit.
>> Otherwise scripts could get confused, thinking everything went fine
>> when
>> nothing actually got done. Here, the user decided something was in
>> error
>> and canceled out, the same way using using ^C causes a non-zero
>> return
>> status.
>
> The patch uses a non-zero exit code, which is an error status. But as
> that's the case, I'm not sure why it's described in the changelog as
> treating it "not as an error."
Sorry, was reading through the list too quickly. Of course an exit
code of 1 is an error. I'll go back to hiding under my rock now.
~~ Brian
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Boyd Lynn Gerber @ 2008-07-30 21:28 UTC (permalink / raw)
To: Aidan Van Dyk; +Cc: Junio C Hamano, git
In-Reply-To: <20080730204339.GJ10399@yugib.highrise.ca>
On Wed, 30 Jul 2008, Aidan Van Dyk wrote:
> * Boyd Lynn Gerber <gerberb@zenez.com> [080730 16:09]:
> > I have just tried this on 4 OpenServer 6.0 machines fresh installed and I
> > do not need this added. I am trying to figure out what is different on
> > his. It appears he is using the exact same version of the compiler as
> > well.
> >
> > My uname -a gives me this...
> >
> > SCO_SV tech0 5 6.0.0 i386
> >
> > and the gcc -V gives me the exact same compiler. So I do not know why he
> > has to have the additional __OPENSERVER__. This does break my OpenServer
> > 5.0.7 fresh install as well. So I would not use it. What I do not
> > understand is why the !defined(__USLC__) does not catch it. It should.
>
> Sorry, a bit premature on my end...
>
> I tried a "default" gmake, and hit an error right away:
> UX:cc: ERROR: Invalid subargument: -Wall
> And immediately pulled my changes from last january into the fix it. My
> changes included a local config.mak CFLAGS override which was the real
> fix.
>
> To build with no source changes, I need:
> NO_MKDTEMP=1 SNPRINTF_RETURNS_BOGUS=1 CFLAGS=-g NO_POSIX_ONLY_PROGRAMS=1
How about doing a fresh
working directory. And just for the fun of it try...
This
tech0 > CC=cc CXX=CC CFLAGS="-Kalloca -Kthread" CPPFLAGS="-Kalloca
-Kthread" ./configure
tech0 > gmake
and
tech0 > CC=cc CXX=CC ./configure
tech0 > gmake
worked without any issues for me.
> How about something like this:
> diff --git a/Makefile b/Makefile
> index 798a2f2..c42040f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -602,6 +602,7 @@ ifeq ($(uname_S),SCO_SV)
> endif
> ifeq ($(uname_R),5)
> CC = cc
> + CFLAGS = -g
> BASIC_CFLAGS += -Kthread
> endif
> NEEDS_SOCKET = YesPlease
> @@ -615,6 +616,8 @@ ifeq ($(uname_S),SCO_SV)
> BASIC_LDFLAGS += -L/usr/local/lib
> NO_STRCASESTR = YesPlease
> NO_MEMMEM = YesPlease
> + NO_MKDTEMP = YesPlease
> + SNPRINTF_RETURNS_BOGUS = YesPlease
> INSTALL = ginstall
> TAR = gtar
> endif
The above does work on OpenServer 6, UnixWare 7.1.4 and OpenServer 5.0.7
> Unfortunately, I have access to only that one SCO box, so I have no idea
> of mkdtemp and sprintf problems are on all SCO, or just R=5 ones.
>
> That allows me to build with NO_POSIX_ONLY_PROGRAMS=1, because for some reason, the
> linker complains on linking git-shell:
> Undefined first referenced
> symbol in file
> hexval_table abspath.o
> null_sha1 abspath.o
> trust_executable_bit abspath.o
> has_symlinks abspath.o
> UX:ld: ERROR: Symbol referencing errors. No output written to git-shell
>
> These are all extern varualbes declared in cache.h, but no defined in
> any of the objects git-shell links, normally not a problem, but this is SCO.
I do not see the problem on my systems.
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: cvs diff -l equivalent?
From: Linus Torvalds @ 2008-07-30 21:25 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080730082030.GA12555@cuci.nl>
On Wed, 30 Jul 2008, 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?
Not without patching, no. When generating a patch, git diff always
recurses.
I suspect adding some kind of "-l" flag would be about five lines of code,
though, so if you really need it... Hint, hint.
Linus
^ permalink raw reply
* Re: Git Community Book
From: J. Bruce Fields @ 2008-07-30 21:39 UTC (permalink / raw)
To: Scott Chacon; +Cc: Petr Baudis, git list
In-Reply-To: <d411cc4a0807291130p228f77d5r1f390090ec29aef4@mail.gmail.com>
> > So my confusion still is - where does this stand wrt. the user manual?
> > Why didn't you just start with the manual and work on that? I thought
> > you were planning to do that, but apparently we misunderstood each other
> > in the last mails.
> >
On Tue, Jul 29, 2008 at 11:30:55AM -0700, Scott Chacon wrote:
>
> I was originally planning on doing that, but the problem is the
> graphics, diagrams and screencasts. Unless I am mistaken, there is
> not a single outside media reference in any of these guides - the
> diagrams that are there are all ascii drawings. I'm assuming there is
> a reason for that. If I wanted to add images and screencast embeds
> into the guide, how would that work?
>
Yeah, some possible obstacles:
- Size: People probably won't want large binary blobs added to
the git repository.
- Editability: We want to be able to keep the materials up to
date and accurate.
- Source readability: the current documentation can all be read
in place without doing a build.
- Build requirements: I seem to recall complaints about the
toolchain required to build the existing documentation.
At least for simple diagrams it might be possible to solve most of those
problems with an appropriate diagram-description-language that could be
compiled into image files. Screencasts are probably totally out,
though.
In cases where you do find you're working with the same material, any
improvements you could contribute back to the in-tree documentation
would of course be appreciated.
> Well, that's what the point of this is - to ask everyone to help me
> review it, and possibly help me add to it. The user manual is great,
> but even I don't reference it very often because I find it difficult
> to find content in it I need quickly.
If you had notes on any particular examples (I looked for X in place Y,
then place Z, and finally found it where I least expected it in place
Q...), they'd be appreciated.
> The specific order I choose is very different from the User Guide and
> is likely to bother a number of people, which you mentioned (and I'm
> sure Dscho will _hate_) because I introduce the object model at the
> beginning. (I'm still working on that section, trying to simplify it
> and add in some other diagrams and a short screencast I have that I
> think will be helpful) This is because I have had a lot of positive
> feedback that primary frustration from people comes from them thinking
> of Git as a super-better Subversion.
>
> I would venture to say that
> _most_ of the users coming to Git now are currently fluent in
> Subversion. Even if they are from Perforce or CVS (the other two ones
> I will occasionally run into), their mental model of what an SCM does
> is the same - delta storage. I've found that by ridding them of that
> notion off the bat, they have _far_ fewer problems and frustrations
> with Git than when I just try to show them the first 10 commands in
> sort of a cookbook style. It's not a complicated model, it doesn't
> take long to teach, and in _my personal_ experience (which is not to
> say it's necessarily correct), it helps people the most in picking it
> up and really loving the tool.
I've considered doing the same for the user manual, actually, for some
of the same reasons--my main concern would be that it be done very
quickly, so as not to make people feel like it was a big obstacle on
their way to actually doing what they need to do.
So, anyway, that's to say that suggestions for reorganization of the
in-tree documentation (as opposed to just smaller-scale fixes) would
also be welcomed....
--b.
>
> The book is built so that it is just as easy to start in the 'Basic
> Usage' section and go back later, but if you're going to sit down and
> just start reading, I think it would be better to explain why Git is
> different at a fundamental level right off the bat.
>
> Scott
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Add NO_RSYNC to allow building without rsync
From: Boyd Lynn Gerber @ 2008-07-30 21:42 UTC (permalink / raw)
To: Aidan Van Dyk; +Cc: Junio C Hamano, git
In-Reply-To: <20080730204948.GK10399@yugib.highrise.ca>
On Wed, 30 Jul 2008, Aidan Van Dyk wrote:
> * Junio C Hamano <gitster@pobox.com> [080730 16:11]:
> > > I came about this because SCO OpenServer doesnt' have mkdtemp. But I never use
> > > rsync, so making it optional was an easy fix.
> >
> > Perhaps "make NO_MKDTEMP=YesPlease" is a much better fix for your
> > particular environment?
>
> Yes, I found that out after...
>
> > The patch is seriously whitespace damaged, in any case.
>
> Ooops... copy-n-paste from git-format-patch|more on some crappy sco terminal
> through a screen session... I guess someone in there translated tabs to
> spaces...
I do have rsync. I use it all the time on OpenServer 6. I have automated
rsync backups of certain Openserver 6 machines.
tech0 > rsync --version
rsync version 3.0.2 protocol version 30
Copyright (C) 1996-2008 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, no IPv6, batchfiles, inplace,
append, ACLs, no xattrs, iconv, no symtimes
tech0.zenez.com and osr600.zenez.com are OpenServer 6 machines.
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: [PATCH v3] Advertise the ability to abort a commit
From: Anders Melchiorsen @ 2008-07-30 21:53 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Brian Gernhardt, git, gitster, peff
In-Reply-To: <32541b130807301409t2f1f3a80n44c62447c628f03a@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> The patch uses a non-zero exit code, which is an error status. But
> as that's the case, I'm not sure why it's described in the changelog
> as treating it "not as an error."
A matter of terminology, I guess. Apologies if I used the wrong word.
I figured that a non-zero return value was not necessarily an error,
but could also be an unusual exit. Like when calling "git" for help.
However, printing out "fatal:" and a lowercase note is definitely an
error situation.
Cheers,
Anders.
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-30 21:45 UTC (permalink / raw)
To: Eyvind Bernhardsen
Cc: Johannes Schindelin, Avery Pennarun, Joshua Jensen,
Junio C Hamano, git
In-Reply-To: <A8BF9951-AB9D-4391-A6CB-E9778064F4A8@orakel.ntnu.no>
On Tue, Jul 29, 2008 at 11:17:23PM +0200, Eyvind Bernhardsen wrote:
>
> My point was that autocrlf penalises Windows users just as much as it
> does Linux users, so why should it be turned on by default on
> Windows?
Because it does make sense on Windows (I mentioned some reasons for that
in my previous email), and it does NOT make any sense on Linux unless
you copy files from Windows.
> >
> >And the main argument for having that in this way is that people
> >with LF
> >text files should be unnecessary penalized for Windows being
> >different.
>
> I know, but my point is that I don't like to be unnecessarily
> penalised any more when I am using Windows than when I'm using Linux
> or OS X.
It seems you still have not realized that from the very day when you
started to use Windows, you are penalized for that day-in, day-out.
Let's take something simple. For instance, the hello-world program:
cat <<=== > hello.c
#include <stdio.h>
int main() {
printf ("Hello world!\n");
return 0;
}
===
You can compile it on Linux and Windows (using Microsoft Visual C).
Now, if you run it on Linux, it will print 13 symbols (exactly
as many as there are symbols in the printf string) while on Windows
you will get 14 bytes. It means that printf and as many other C
function on Windows does conversion and penalize you already!
> I would like the default to be "no conversion", and for
> conversion to be enabled not based on platform, but as a policy
> decision on the repositories where it actually matters.
If Microsoft C library did not do any conversion, I suspect we would
have this CRLF conversion at all!
> You can have anything you like in _your_ repository, of course, but if
> you're not publishing it anywhere, who cares what your line endings
> are? Your line endings only matter when you publish.
You can publish only what you have. So, it must decided before.
> That's why I
> want a setting that is propagated: so that when you clone a repository
> with a LF-only policy, Git knows what to do.
LF-only policy is the only sane policy for any text files. It has nothing
to do with clone.
>
> I think the real penalty is that with autocrlf enabled, Git no longer
> stores exactly what I committed.
And what is wrong with that? In any case, Git deltifies and compress
your files. Why does it not bother you? So, what matters here is
whether you are able to get back exactly what you put or not. That's
why Git has this safecrlf option! Of course, it is guarantee to get
exactly the same back only if you have the same autocrlf setting,
but if you have different autocrlf settings, it means that you want
*different* representation of text files!
> >Files that do not need conversion (such as *.bat) should be marked as
> >"-crlf" in .gitattributes.
>
> Yes, and I see you checked that "crlf=input" does actually work when
> you want LF-only, sorry about that. The syntax is _horrible_, though.
>
> >Of course, those who are very careful and have good editors can set
> >autocrlf=false even on Windows...
>
> Right, or who know that the repository they're using will only be
> shared with other Windows users.
WRONG! Using storing CRLF in text files is a completely idiotic idea.
Those who do so asked for troubles, so they should not complain!
>
> Internally, Git doesn't really care, does it?
It DOES!!! Such things like merges and diffs and many other every day
commands do care about end-of-lines and the ONLY end-of-line they
recognize is '\n'. In fact, there are more than 400 places in Git where
'\n' is used. Of course, not all of them may be qualified as internals
but many of them do.
So, as long as Git internally consider only LF as the end-of-line.
>
> Heh. Where I work, we hacked CVS for Windows to get away from that
> behaviour :)
Maybe, you used Cygwin version of CVS, which had LF, but those Windows
versions of CVS I used produced CRLF on Windows.
> >
> >The problem is how to determine when it is necessary and when it is
> >not. If I never commit with wrong EOLs, I don't think it is necessary
> >for me to have this conversion... On the other hand, I don't mind
> >having
> >this check as default. It does not really bother me much, and if I
> >can
> >turn it off, it is fine with me. But I suppose other people may feel
> >differently about this issue.
>
> Well, what I want is to be able to say "it is necessary to do eol
> conversion in this repository",
You always can do that in _your_ repository:
git config core.autocrlf ...
> allowing the default to be "don't do
> eol conversion" on Windows, too. For a setting like that to be
> useful, it has to be propagated when the repository is cloned.
Why? Other people may have other preferences.
> I want it to be versioned because you might want to change it without
> messing with the content that's already in the repository. This is
> actually my main motivation, since I have lots of CRLF-infused CVS
> history to deal with.
Well, you can try to use .gitattributes, but I believe it would be far
more reasonable to clean this mess with line-ending than finding a
way to continue insanity with different ending in different text files.
>
> It should apply on Linux as well as Windows because there is always
> the chance that a user will manage to commit a CRLF on Linux (a
> colleague of mine once complained that CVS on Linux doesn't do eol
> conversion; he edited files on Windows, but checked them in on
> Linux).
For those who need it, Git provides autocrlf=input. But the question
here is what should be default. I don't think that those who copies
files directly from Windows to Linux are majority. OTOH, I don't
mind autocrlf=input as default. If it can be turned off, it is fine
with me :)
> It would probably be okay to have a setting that turns all
> conversion off, but wouldn't that be kind of rude?
How so?
Dmitry
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-30 22:02 UTC (permalink / raw)
To: Avery Pennarun
Cc: Steffen Prohaska, Eyvind Bernhardsen, Johannes Schindelin,
Joshua Jensen, Junio C Hamano, git
In-Reply-To: <32541b130807301407m59eef936m5e07dd33a4eb5b04@mail.gmail.com>
On Wed, Jul 30, 2008 at 05:07:49PM -0400, Avery Pennarun wrote:
>
> FWIW, this problem would apply to any system that incrementally
> imports into git from another system using binary deltas.
Not necessary. It depends on how import is done. You should not apply
this binary deltas to your working tree, but to files in the repo. And
obviously those files that are imported should be stored as is without
any conversion. In the same way as if you clone some git repo, you do
not apply any commit conversion to any existing commit. This conversion
should be done for *new* commits that you create locally.
So, the problem with git-svn is mostly due to how the import is done. Of
course, the other part of that problem is that conversion setting in Git
and SVN for text files specified very differently.
Dmitry
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Avery Pennarun @ 2008-07-30 22:14 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Steffen Prohaska, Eyvind Bernhardsen, Johannes Schindelin,
Joshua Jensen, Junio C Hamano, git
In-Reply-To: <20080730220236.GD7008@dpotapov.dyndns.org>
On 7/30/08, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Wed, Jul 30, 2008 at 05:07:49PM -0400, Avery Pennarun wrote:
> > FWIW, this problem would apply to any system that incrementally
> > imports into git from another system using binary deltas.
>
> Not necessary. It depends on how import is done. You should not apply
> this binary deltas to your working tree, but to files in the repo. And
> obviously those files that are imported should be stored as is without
> any conversion. In the same way as if you clone some git repo, you do
> not apply any commit conversion to any existing commit. This conversion
> should be done for *new* commits that you create locally.
>
> So, the problem with git-svn is mostly due to how the import is done. Of
> course, the other part of that problem is that conversion setting in Git
> and SVN for text files specified very differently.
Hmm, if your first paragraphis true (do not apply any commit
conversion to any existing commit), then in fact SVN's method for
specifying text files doesn't really matter, right? It's just a bug
in git-svn.
Is it possible to have git-svn override core.autocrlf temporarily? If
someone can give me a hint how to do that, I don't mind working up a
patch for that. I can't see any situation where *not* doing so would
even work (unless core.autocrlf=false already, of course).
Have fun,
Avery
^ permalink raw reply
* [PATCH] builtin-help: always load_command_list() in cmd_help()
From: Miklos Vajna @ 2008-07-30 22:38 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <C0DB03B0-8AF5-4B6A-A9DB-16608128EB31@sb.org>
When cmd_help() is called, we always need the list of main and other
commands, not just when the list of all commands is shown. Before this
patch 'git help diff' invoked 'man gitdiff' because cmd_to_page()
thought 'diff' is not a git command.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Wed, Jul 30, 2008 at 01:52:26PM -0700, Kevin Ballard <kevin@sb.org> wrote:
> `git help diff` no longer finds the git-diff manpage (as of tip of
> next branch). I haven't tested, but I suspect
> 940208a771066229bc6a486f6a058e332b71cfe4 is responsible.
This fixed the issue for me.
Thanks!
help.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/help.c b/help.c
index 88c0d5b..968f368 100644
--- a/help.c
+++ b/help.c
@@ -690,6 +690,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
{
int nongit;
const char *alias;
+ unsigned int longest = load_command_list("git-", &main_cmds, &other_cmds);
setup_git_directory_gently(&nongit);
git_config(git_help_config, NULL);
@@ -698,7 +699,6 @@ int cmd_help(int argc, const char **argv, const char *prefix)
builtin_help_usage, 0);
if (show_all) {
- unsigned int longest = load_command_list("git-", &main_cmds, &other_cmds);
printf("usage: %s\n\n", git_usage_string);
list_commands("git commands", longest, &main_cmds, &other_cmds);
printf("%s\n", git_more_info_string);
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: q: git-fetch a tad slow?
From: Shawn O. Pearce @ 2008-07-30 22:38 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080730190657.GC26389@elte.hu>
Ingo Molnar <mingo@elte.hu> wrote:
> * Shawn O. Pearce <spearce@spearce.org> wrote:
> >
> > What does `find .git/refs -type f | wc -l` give for the repository on
> > the central server? If its more than a handful (~20) I would suggest
> > running git-gc before testing again.
>
> ah, you are right, it gave 275, then git-gc brought it down to two:
>
> earth4:~/tip> find .git/refs -type f | wc -l
> 275
> earth4:~/tip> git gc
> earth4:~/tip> find .git/refs -type f | wc -l
> 2
>
> alas, fetching still seems to be slow:
>
> titan:~/tip> time git-fetch origin
>
> real 0m5.112s
> user 0m0.972s
> sys 0m3.380s
Yea, OK, there's definately performance problems there. And it
should be fast. Its too common of a case (fetching small deltas).
> > I'll try to find some time to reproduce the issue and look at the
> > bottleneck here. I'm two days into a new job so my git time has been
> > really quite short this week. :-|
>
> fetching the -tip repo:
>
> http://people.redhat.com/mingo/tip.git/README
>
> and then running 'git remote update' will i think already show this
> problem for you too. People have been complaining about how slow the
> update is.
Thanks. I'll try to poke at it this evening and see what I find.
git-fetch should be running faster than this.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] builtin-help: always load_command_list() in cmd_help()
From: Kevin Ballard @ 2008-07-30 22:50 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <1217457487-6509-1-git-send-email-vmiklos@frugalware.org>
This patch works great for me.
Heck, after these help changes, git-help behaves even better in its
error message.
> git help merge-recursive
No manual entry for git-merge-recursive
> git help sdfkjl
No manual entry for gitsdfkjl
It used to complain No manual entry for gitmerge-recursive.
Acked-by: Kevin Ballard <kevin@sb.org>
-Kevin Ballard
On Jul 30, 2008, at 3:38 PM, Miklos Vajna wrote:
> When cmd_help() is called, we always need the list of main and other
> commands, not just when the list of all commands is shown. Before this
> patch 'git help diff' invoked 'man gitdiff' because cmd_to_page()
> thought 'diff' is not a git command.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> On Wed, Jul 30, 2008 at 01:52:26PM -0700, Kevin Ballard
> <kevin@sb.org> wrote:
>> `git help diff` no longer finds the git-diff manpage (as of tip of
>> next branch). I haven't tested, but I suspect
>> 940208a771066229bc6a486f6a058e332b71cfe4 is responsible.
>
> This fixed the issue for me.
>
> Thanks!
>
> help.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/help.c b/help.c
> index 88c0d5b..968f368 100644
> --- a/help.c
> +++ b/help.c
> @@ -690,6 +690,7 @@ int cmd_help(int argc, const char **argv, const
> char *prefix)
> {
> int nongit;
> const char *alias;
> + unsigned int longest = load_command_list("git-", &main_cmds,
> &other_cmds);
>
> setup_git_directory_gently(&nongit);
> git_config(git_help_config, NULL);
> @@ -698,7 +699,6 @@ int cmd_help(int argc, const char **argv, const
> char *prefix)
> builtin_help_usage, 0);
>
> if (show_all) {
> - unsigned int longest = load_command_list("git-", &main_cmds,
> &other_cmds);
> printf("usage: %s\n\n", git_usage_string);
> list_commands("git commands", longest, &main_cmds, &other_cmds);
> printf("%s\n", git_more_info_string);
> --
> 1.6.0.rc0.14.g95f8.dirty
>
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Aidan Van Dyk @ 2008-07-30 22:56 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.10.0807301522140.13032@xenau.zenez.com>
[-- Attachment #1: Type: text/plain, Size: 3980 bytes --]
* Boyd Lynn Gerber <gerberb@zenez.com> [080730 17:28]:
> How about doing a fresh
>
> working directory. And just for the fun of it try...
Unfortunately, I can't use configure, apparently that SCO box does'nt
have a new enough toolc change for M4/autoconf/etc...
But I've never had to use configure before, I've always just built with
make (gmake on boxes with borked make)
> tech0 > CC=cc CXX=CC CFLAGS="-Kalloca -Kthread" CPPFLAGS="-Kalloca
> -Kthread" ./configure
> tech0 > gmake
So, with gmake, that "generally" works. I still need to add:
SNPRINTF_RETURNS_BOGUS=1 NO_MKDTEMP=1
> tech0 > CC=cc CXX=CC ./configure
> tech0 > gmake
And here, until I rid CFLAGS of -Wall, it fails.
> > Unfortunately, I have access to only that one SCO box, so I have no idea
> > of mkdtemp and sprintf problems are on all SCO, or just R=5 ones.
> >
> > That allows me to build with NO_POSIX_ONLY_PROGRAMS=1, because for some reason, the
> > linker complains on linking git-shell:
> > Undefined first referenced
> > symbol in file
> > hexval_table abspath.o
> > null_sha1 abspath.o
> > trust_executable_bit abspath.o
> > has_symlinks abspath.o
> > UX:ld: ERROR: Symbol referencing errors. No output written to git-shell
> >
> > These are all extern varualbes declared in cache.h, but no defined in
> > any of the objects git-shell links, normally not a problem, but this is SCO.
>
> I do not see the problem on my systems.
aidan@jpradley:~/git$ touch abspath.c
aidan@jpradley:~/git$ gmake V=1 git-shell
cc -o abspath.o -c -Kalloca -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM abspath.c
cc -g -Kalloca -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM -o git-shell -L/usr/local/lib abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o compat/lib.a
Undefined first referenced
symbol in file
hexval_table abspath.o
null_sha1 abspath.o
trust_executable_bit abspath.o
has_symlinks abspath.o
UX:ld: ERROR: Symbol referencing errors. No output written to git-shell
gmake: *** [git-shell] Error 1
aidan@jpradley:~/git$ cat config.mak
NO_OENSSL=1
NO_MKDTEMP=1
SHELL=/bin/bash
SNPRINTF_RETURNS_BOGUS=1
CFLAGS=-Kalloca
CPPFLAGS=-Kalloca
I've found that if I set CFLAGS to -O2, it links properly:
aidan@jpradley:~/git$ touch abspath.c
aidan@jpradley:~/git$ gmake V=1 git-shell
cc -o abspath.o -c -Kalloca -O2 -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM abspath.c
cc -Kalloca -O2 -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM -o git-shell -L/usr/local/lib abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o compat/lib.a
So I think it's "not inlining" stuff like:
static inline unsigned int hexval(unsigned char c)
{
return hexval_table[c];
}
So, finally, it pretty much works on SCO out of the box - here's my
settings, which which the test suite passed (well, is passing, I'm at
t5400, but I expect it to all pass again with these settings):
aidan@jpradley:~/git$ cat config.mak
NO_TCLTK=1
NO_MKDTEMP=1
SHELL=/bin/bash
SNPRINTF_RETURNS_BOGUS=1
CFLAGS=-O2
--
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
* Merging submodules
From: Brian Gernhardt @ 2008-07-30 22:59 UTC (permalink / raw)
To: H Merjin Brand; +Cc: Git List, Lars Noschinski
This message got eaten by a syntax error somewhere. This is a re-send, sorry for any duplicate messages.
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/*
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
git merge --no-commit -s ours module_a/master module_b/master module_c/master
git commit --amend
>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.
~~ Brian
^ permalink raw reply
* [FUN PATCH] Remove "git clone" parameters if they are the first in a git clone call
From: Pieter de Bie @ 2008-07-30 23:02 UTC (permalink / raw)
To: Git Mailinglist; +Cc: Pieter de Bie
This removes accidental duplicate "git clone" parameters, for example
when typing:
git clone git clone git://repo.or.cz/git.git
---
OK, so it happens often to me that I copy a line that already starts with "git
clone", and then type it myself again, paste, and hit enter. I thought it
might happen to others too, hence this patch.
builtin-clone.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 4b1ab36..9e4c7c2 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -350,6 +350,11 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
junk_pid = getpid();
+ if (argc > 3 && !strcmp(argv[1], "git") && !strcmp(argv[2], "clone")) {
+ argv += 2;
+ argc -= 2;
+ }
+
argc = parse_options(argc, argv, builtin_clone_options,
builtin_clone_usage, 0);
--
1.6.0.rc1.163.g8ec19
^ permalink raw reply related
* Re: Merging submodules (was Re: Feature suggestion: git-hist)
From: Brian Gernhardt @ 2008-07-30 23:03 UTC (permalink / raw)
To: H Merjin Brand; +Cc: Git List, Lars Noschinski
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
module_b/master -p module_c/master < commit-message)
git update-ref HEAD $commit # Update your current ref
~~ Brian
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Boyd Lynn Gerber @ 2008-07-30 23:30 UTC (permalink / raw)
To: Aidan Van Dyk; +Cc: Junio C Hamano, git
In-Reply-To: <20080730225635.GM10399@yugib.highrise.ca>
On Wed, 30 Jul 2008, Aidan Van Dyk wrote:
> * Boyd Lynn Gerber <gerberb@zenez.com> [080730 17:28]:
> > How about doing a fresh
> >
> > working directory. And just for the fun of it try...
>
> Unfortunately, I can't use configure, apparently that SCO box does'nt
> have a new enough toolc change for M4/autoconf/etc...
>
> But I've never had to use configure before, I've always just built with
> make (gmake on boxes with borked make)
I did have to install m4 and have /usr/local/bin before /usr/bin and /bin
so it uses the gnu m4.
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.
> > tech0 > CC=cc CXX=CC CFLAGS="-Kalloca -Kthread" CPPFLAGS="-Kalloca
> > -Kthread" ./configure
> > tech0 > gmake
>
> So, with gmake, that "generally" works. I still need to add:
> SNPRINTF_RETURNS_BOGUS=1 NO_MKDTEMP=1
>
> > tech0 > CC=cc CXX=CC ./configure
> > tech0 > gmake
>
> And here, until I rid CFLAGS of -Wall, it fails.
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.
> > > Unfortunately, I have access to only that one SCO box, so I have no idea
> > > of mkdtemp and sprintf problems are on all SCO, or just R=5 ones.
> > >
> > > That allows me to build with NO_POSIX_ONLY_PROGRAMS=1, because for some reason, the
> > > linker complains on linking git-shell:
> > > Undefined first referenced
> > > symbol in file
> > > hexval_table abspath.o
> > > null_sha1 abspath.o
> > > trust_executable_bit abspath.o
> > > has_symlinks abspath.o
> > > UX:ld: ERROR: Symbol referencing errors. No output written to git-shell
> > >
> > > These are all extern varualbes declared in cache.h, but no defined in
> > > any of the objects git-shell links, normally not a problem, but this is SCO.
> >
> > I do not see the problem on my systems.
>
> aidan@jpradley:~/git$ touch abspath.c
> aidan@jpradley:~/git$ gmake V=1 git-shell
> cc -o abspath.o -c -Kalloca -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM abspath.c
> cc -g -Kalloca -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM -o git-shell -L/usr/local/lib abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o compat/lib.a
> Undefined first referenced
> symbol in file
> hexval_table abspath.o
> null_sha1 abspath.o
> trust_executable_bit abspath.o
> has_symlinks abspath.o
> UX:ld: ERROR: Symbol referencing errors. No output written to git-shell
> gmake: *** [git-shell] Error 1
> aidan@jpradley:~/git$ cat config.mak
> NO_OENSSL=1
> NO_MKDTEMP=1
> SHELL=/bin/bash
> SNPRINTF_RETURNS_BOGUS=1
> CFLAGS=-Kalloca
> CPPFLAGS=-Kalloca
>
> I've found that if I set CFLAGS to -O2, it links properly:
> aidan@jpradley:~/git$ touch abspath.c
> aidan@jpradley:~/git$ gmake V=1 git-shell
> cc -o abspath.o -c -Kalloca -O2 -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM abspath.c
> cc -Kalloca -O2 -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM -o git-shell -L/usr/local/lib abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o compat/lib.a
>
> So I think it's "not inlining" stuff like:
> static inline unsigned int hexval(unsigned char c)
> {
> return hexval_table[c];
> }
>
> So, finally, it pretty much works on SCO out of the box - here's my
> settings, which which the test suite passed (well, is passing, I'm at
> t5400, but I expect it to all pass again with these settings):
>
> aidan@jpradley:~/git$ cat config.mak
> NO_TCLTK=1
> NO_MKDTEMP=1
> SHELL=/bin/bash
> SNPRINTF_RETURNS_BOGUS=1
> CFLAGS=-O2
-g and -O2 are mutually exclusive. You can have either one but not both.
I do have tcl and tk
drwxr-xr-x 12 gerberb zenez 2048 Jun 10 17:30 tcl8.5.2
drwxr-xr-x 12 gerberb zenez 2048 Jun 10 17:30 tk8.5.2
So I am not sure what the best option should be. There is a patch for
UnixWare 7 MP4 that has to be installed to MP4 for so failures, but it
works even with ksh with it.
Also on UnixWare 7.1.4 I could not get any m4 greater than 1.4.9 to
compile and work. I finally just used
drwxr-xr-x 8 gerberb zenez 2048 May 19 03:05 m4-1.4.9
drwxrwxrwx 9 gerberb zenez 4096 Apr 3 00:11 make-3.81
drwxr-xr-x 12 gerberb zenez 2048 Jun 10 16:43 tcl8.5.2
drwxr-xr-x 12 gerberb zenez 2048 Jun 10 16:44 tk8.5.2
drwxr-xr-x 9 gerberb zenez 4096 May 19 03:18 sed-4.1.4
On UnixWare 7.1.4 MP4 with ptf9055a.
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: git help broken
From: Johannes Schindelin @ 2008-07-30 23:42 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Git Mailing List
In-Reply-To: <C0DB03B0-8AF5-4B6A-A9DB-16608128EB31@sb.org>
Hi,
On Wed, 30 Jul 2008, Kevin Ballard wrote:
> `git help diff` no longer finds the git-diff manpage (as of tip of next
> branch). I haven't tested, but I suspect
> 940208a771066229bc6a486f6a058e332b71cfe4 is responsible.
Just to save everybody else and her dog the trouble: that commit's oneline
is "builtin-help: make some internal functions available to other
builtins".
And from the patch, it is pretty obvious that it does not come close to
the "man" code path.
Ciao,
Dscho
^ permalink raw reply
* Re: git help broken
From: Johannes Schindelin @ 2008-07-30 23:44 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Git Mailing List
In-Reply-To: <alpine.LSU.1.00.0807310141060.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Hi,
On Thu, 31 Jul 2008, Johannes Schindelin wrote:
> On Wed, 30 Jul 2008, Kevin Ballard wrote:
>
> > `git help diff` no longer finds the git-diff manpage (as of tip of next
> > branch). I haven't tested, but I suspect
> > 940208a771066229bc6a486f6a058e332b71cfe4 is responsible.
>
> Just to save everybody else and her dog the trouble: that commit's oneline
> is "builtin-help: make some internal functions available to other
> builtins".
>
> And from the patch, it is pretty obvious that it does not come close to
> the "man" code path.
Oh, so it was involved?
Oh, well,
Dscho
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Aidan Van Dyk @ 2008-07-30 23:44 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.10.0807301700500.13032@xenau.zenez.com>
[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]
* 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 ;-)
> 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.
> -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.
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: git help broken
From: Kevin Ballard @ 2008-07-30 23:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.LSU.1.00.0807310141060.3486@wbgn129.biozentrum.uni-wuerzburg.de>
On Jul 30, 2008, at 4:42 PM, Johannes Schindelin wrote:
> On Wed, 30 Jul 2008, Kevin Ballard wrote:
>
>> `git help diff` no longer finds the git-diff manpage (as of tip of
>> next
>> branch). I haven't tested, but I suspect
>> 940208a771066229bc6a486f6a058e332b71cfe4 is responsible.
>
> Just to save everybody else and her dog the trouble: that commit's
> oneline
> is "builtin-help: make some internal functions available to other
> builtins".
>
> And from the patch, it is pretty obvious that it does not come close
> to
> the "man" code path.
I suspected it because it was the only non-merge commit since my last
pull that mentioned "help" in the message. Regardless, Miklos has
posted a patch that works.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Wincent Colaiuta @ 2008-07-30 23:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Julian Phillips, Scott Chacon, Petr Baudis,
git list
In-Reply-To: <7vy73j418t.fsf@gitster.siamese.dyndns.org>
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.
> 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-30 23:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807291738280.3334@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> But the reverse isn't true: the current primary formats cannot be
> generated from your preferred format without losing something important
> (performance).
>
> But I'll make you a deal: if you actually write the filter in C form, I
> can pretty much guarantee that we can easily add it as a new flag. It
> really should be pretty easy to integrate it into the revision parsing
> machinery alongside --topo-order, since it's really the same kind of
> operation.
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.
-- >8 --
Subject: [PATCH] revision traversal: teach --post-simplify
The --full-history traversal keeps all merges and non-merge commits that
touch paths in the given pathspec. This is useful to view both sides of a
merge in a topology like this:
A---M---o
/ /
---O---B
when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with a simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
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.
* Otherwise, we examine the parents of the commit.
- If they replace to the same commit, because the commit we are looking
at itself does not touch the interesting paths, we replace the commit
we are looking at with the replacement commit of its parents.
- If some of the parents replace to one commit, and some other parents
replace to another different commit, the commit we are looking at
needs to stay as a merge in the final result.
The algorithm outlined above alone does not quite work; the reason is
because "all parents are replaced by the same commit" rule is too strict.
It needs to be relaxed to remove parents that are ancestor of some other
parents, and that is why post_simplify_one() calls a rather expensive
reduce_heads().
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
revision.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++----------
revision.h | 1 +
2 files changed, 106 insertions(+), 20 deletions(-)
diff --git a/revision.c b/revision.c
index 3897fec..a843c42 100644
--- a/revision.c
+++ b/revision.c
@@ -1045,6 +1045,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
} else if (!strcmp(arg, "--topo-order")) {
revs->lifo = 1;
revs->topo_order = 1;
+ } else if (!strcmp(arg, "--post-simplify")) {
+ revs->post_simplify = 1;
+ revs->topo_order = 1;
+ revs->simplify_history = 0;
} else if (!strcmp(arg, "--date-order")) {
revs->lifo = 0;
revs->topo_order = 1;
@@ -1378,6 +1382,105 @@ static void add_child(struct rev_info *revs, struct commit *parent, struct commi
l->next = add_decoration(&revs->children, &parent->object, l);
}
+static int remove_duplicate_parents(struct commit *commit)
+{
+ struct commit_list **pp, *p;
+ int surviving_parents;
+
+ /* Examine existing parents while marking ones we have seen... */
+ pp = &commit->parents;
+ while ((p = *pp) != NULL) {
+ struct commit *parent = p->item;
+ if (parent->object.flags & TMP_MARK) {
+ *pp = p->next;
+ continue;
+ }
+ parent->object.flags |= TMP_MARK;
+ pp = &p->next;
+ }
+ /* count them while clearing the temporary mark */
+ surviving_parents = 0;
+ for (p = commit->parents; p; p = p->next) {
+ p->item->object.flags &= ~TMP_MARK;
+ surviving_parents++;
+ }
+ return surviving_parents;
+}
+
+static int post_simplify_one(struct commit *commit)
+{
+ struct commit_list *p;
+ int num_parents;
+
+ for (p = commit->parents; p; p = p->next)
+ if (!p->item->util)
+ return 0;
+
+ /* All of our parents know what they should be rewritten to */
+ for (p = commit->parents; p; p = p->next)
+ p->item = p->item->util;
+ num_parents = remove_duplicate_parents(commit);
+
+ if (1 < num_parents) {
+ struct commit_list *h = reduce_heads(commit->parents);
+ num_parents = commit_list_count(h);
+ free_commit_list(commit->parents);
+ commit->parents = h;
+ }
+
+ /*
+ * We stand for ourselves if we are root, if we change the tree,
+ * or if we are a merge and our parents simplify to different
+ * commits. Otherwise we can be replaced by the commit our
+ * sole parent is replaced by.
+ */
+ if (!num_parents ||
+ !(commit->object.flags & TREESAME) ||
+ (1 < num_parents))
+ commit->util = commit;
+ else
+ commit->util = commit->parents->item->util;
+
+ return 1;
+}
+
+static void post_simplify(struct rev_info *revs)
+{
+ struct commit_list *list;
+ struct commit_list *yet_to_do, **tail;
+
+ /* feed the list reversed */
+ yet_to_do = NULL;
+ for (list = revs->commits; list; list = list->next)
+ commit_list_insert(list->item, &yet_to_do);
+ while (yet_to_do) {
+ list = yet_to_do;
+ yet_to_do = NULL;
+ tail = &yet_to_do;
+ while (list) {
+ struct commit *commit = list->item;
+ struct commit_list *next = list->next;
+ free(list);
+ list = next;
+ if (!post_simplify_one(commit))
+ tail = &commit_list_insert(commit, tail)->next;
+ }
+ }
+
+ /* clean up the result, removing the simplified ones */
+ list = revs->commits;
+ revs->commits = NULL;
+ tail = &revs->commits;
+ while (list) {
+ struct commit *commit = list->item;
+ struct commit_list *next = list->next;
+ free(list);
+ list = next;
+ if (commit->util == commit)
+ tail = &commit_list_insert(commit, tail)->next;
+ }
+}
+
static void set_children(struct rev_info *revs)
{
struct commit_list *l;
@@ -1418,6 +1521,8 @@ int prepare_revision_walk(struct rev_info *revs)
return -1;
if (revs->topo_order)
sort_in_topological_order(&revs->commits, revs->lifo);
+ if (revs->post_simplify)
+ post_simplify(revs);
if (revs->children.name)
set_children(revs);
return 0;
@@ -1450,26 +1555,6 @@ static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp
}
}
-static void remove_duplicate_parents(struct commit *commit)
-{
- struct commit_list **pp, *p;
-
- /* Examine existing parents while marking ones we have seen... */
- pp = &commit->parents;
- while ((p = *pp) != NULL) {
- struct commit *parent = p->item;
- if (parent->object.flags & TMP_MARK) {
- *pp = p->next;
- continue;
- }
- parent->object.flags |= TMP_MARK;
- pp = &p->next;
- }
- /* ... and clear the temporary mark */
- for (p = commit->parents; p; p = p->next)
- p->item->object.flags &= ~TMP_MARK;
-}
-
static int rewrite_parents(struct rev_info *revs, struct commit *commit)
{
struct commit_list **pp = &commit->parents;
diff --git a/revision.h b/revision.h
index f64e8ce..953e69b 100644
--- a/revision.h
+++ b/revision.h
@@ -41,6 +41,7 @@ struct rev_info {
simplify_history:1,
lifo:1,
topo_order:1,
+ post_simplify:1,
tag_objects:1,
tree_objects:1,
blob_objects:1,
--
1.6.0.rc1.29.gc4aca
^ permalink raw reply related
* 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
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