* Re: wishlist: git info
From: Alex Riesen @ 2007-11-12 23:41 UTC (permalink / raw)
To: Thomas Neumann; +Cc: git
In-Reply-To: <4738D8AA.1030604@users.sourceforge.net>
Thomas Neumann, Mon, Nov 12, 2007 23:50:18 +0100:
> >> Probably not the most intelligent way to compute it, but you get the
> >> idea. git info should give a brief overview over the current working
> >> directory.
> >
> > Like what? None of the commands you suggested even touch it.
> probably "current working directory" was not the best way to phrase it.
> I mean state of the repository, which in my case is a clone of a central
> repository.
> My commands show (ignoring formatting): 1. the remote repositories with
> URL 2. the current head commit hash 3. the date of the head commit.
Don't you want to know where the remote repo is at?
> Which gives a pretty decent idea about the state of the repository.
...which in Git-lingo would be misunderstood as the output of
git-status :)
> > Would
> >
> > git remote -r -v && git log --max-count=1 --pretty=format:'%h %s'
> >
> > do what you think is what you need?
> perhaps, the first command gives me an error (git 1.5.2.5). This here is
> nearly ok
Ach, make it "git remote -v". It does exactly showing of the url.
Dunno what I wanted the "-r" for. Probably left from thinking of
"git branch -r" (which shows remote branches).
> git remote && git log --max-count=1 --pretty=format:'%H %cD'
>
> except the missing URL from git remote (but perhaps your options include
> it with a newer git version, will test).
It is there since 1.5.3-rc1
^ permalink raw reply
* Re: wishlist: git info
From: Jakub Narebski @ 2007-11-12 23:46 UTC (permalink / raw)
To: git
In-Reply-To: <4738D8AA.1030604@users.sourceforge.net>
Thomas Neumann wrote:
> My commands show (ignoring formatting): 1. the remote repositories with
> URL 2. the current head commit hash 3. the date of the head commit.
> Which gives a pretty decent idea about the state of the repository.
Perhaps also project description (if it exists?)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git diff woes
From: Andreas Ericsson @ 2007-11-13 0:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <7vhcjr2lte.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>> In the check_ntpd.c program, there is no bug. I found the git diff output
>> surprising, so I reported it.
>
> This is what I get from "GNU diff -pu" which makes me surpried
> that anybody finds "git diff" hunk header surprising. Notice
> that hunk at line 84.
>
> --- read-cache.c 2007-11-12 12:08:00.000000000 -0800
> +++ read-cache.c+ 2007-11-12 12:07:54.000000000 -0800
> @@ -60,7 +60,7 @@ static int ce_compare_data(struct cache_
> return match;
> }
>
> -static int ce_compare_link(struct cache_entry *ce, size_t expected_size)
> +static int ce_compare_lonk(struct cache_entry *ce, size_t expected_size)
> {
> int match = -1;
> char *target;
> @@ -84,7 +84,7 @@ static int ce_compare_link(struct cache_
> match = memcmp(buffer, target, size);
> free(buffer);
> free(target);
> - return match;
> + return match + 0;
> }
>
> static int ce_compare_gitlink(struct cache_entry *ce)
I notice it, and I don't like it. I guess I'm just used to git being
smarter than their GNU tool equivalents, especially since it only ever
applies patches in full.
I have a patch ready to make it configurable but it lacks doc updates
and tests, so I'll send it tomorrow morning when I've had time to
fiddle a bit with that.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] for-each-ref: fix off by one read.
From: Junio C Hamano @ 2007-11-13 0:05 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20071112053725.4f0d1940.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
> index 598d4e1..89ea37c 100644
> --- a/builtin-for-each-ref.c
> +++ b/builtin-for-each-ref.c
> @@ -306,7 +306,7 @@ static const char *find_wholine(const char *who, int wholen, const char *buf, un
> if (!eol)
> return "";
> eol++;
> - if (eol[1] == '\n')
> + if (*eol == '\n')
> return ""; /* end of header */
> buf = eol;
> }
Good eyes. This would have broken if
(1) we had a header field that consists of a single character
and then LF. We would have mistaken such a line as the end
of header; or
(2) we had a commit or a tag that consists solely of header and
no body. We would have read past the terminating NUL.
Thanks.
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Andreas Ericsson @ 2007-11-13 0:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Johannes Schindelin, Bill Lear, Jan Wielemaker, git
In-Reply-To: <7v4pfr2kmh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>
> His second point is also a real issue. If you allowed cloning
> an empty repo (either bare or non-bare), then you and Bill can
> both clone from it, come up with an initial commit each. Bill
> pushes his initial commit first. Your later attempt to push
> will hopefully fail with "non fast forward", if you know better
> than forcing such a push, but then what? You need to fetch, and
> merge (or rebase) your change on top of Bill's initial commit,
> and at that point the history you are trying to merge does not
> have any common ancestor with his history.
If we assume zero communication between these two, the alternative
is this:
Bill starts hacking in his own repo and then uploads his .git dir
to the server.
David starts hacking in his own repo and then uploads his .git
dir to the server.
The only difference between the two scenarios is (assuming they
have write access to those shared directories) that the last-in
wins in the second case, while first-in wins in the first one.
Oh, and the fact that the first to upload his .git dir to the
server will lose all his refs if he isn't careful to save his
original copy until they both have established which "first"
commit to use, which could take a while in this imaginary world
where they don't seem to be speaking to each other but are still
working together.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 1/6] builtin-commit: fix author date with --amend --author=<author>
From: Junio C Hamano @ 2007-11-13 0:37 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <1194896334.2869.7.camel@hinata.boston.redhat.com>
Kristian Høgsberg <krh@redhat.com> writes:
> I suggest we back this patch out.
Ok. My mistake. Your "Add testcase for amending and fixing
author in git commit" does contain test for this.
I need to amend the commit log message of that one, though ;-)
^ permalink raw reply
* Re: git diff woes
From: Johannes Schindelin @ 2007-11-13 0:59 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4738E9E6.2040001@op5.se>
Hi,
On Tue, 13 Nov 2007, Andreas Ericsson wrote:
> Junio C Hamano wrote:
> > Andreas Ericsson <ae@op5.se> writes:
> >
> > > In the check_ntpd.c program, there is no bug. I found the git diff
> > > output surprising, so I reported it.
> >
> > This is what I get from "GNU diff -pu" which makes me surpried
> > that anybody finds "git diff" hunk header surprising. Notice
> > that hunk at line 84.
> >
> > --- read-cache.c 2007-11-12 12:08:00.000000000 -0800
> > +++ read-cache.c+ 2007-11-12 12:07:54.000000000 -0800
> > @@ -60,7 +60,7 @@ static int ce_compare_data(struct cache_
> > return match;
> > }
> > -static int ce_compare_link(struct cache_entry *ce, size_t expected_size)
> > +static int ce_compare_lonk(struct cache_entry *ce, size_t expected_size)
> > {
> > int match = -1;
> > char *target;
> > @@ -84,7 +84,7 @@ static int ce_compare_link(struct cache_
> > match = memcmp(buffer, target, size);
> > free(buffer);
> > free(target);
> > - return match;
> > + return match + 0;
> > }
> > static int ce_compare_gitlink(struct cache_entry *ce)
>
>
> I notice it, and I don't like it. I guess I'm just used to git being
> smarter than their GNU tool equivalents, especially since it only ever
> applies patches in full.
I still think the existing behaviour is reasonable. When I read a diff
(and remember, the hunk headers are _only_ there for the reviewer's
pleasure), the function names are a hint for _me_ where to look, and which
is the context, in my existing, _original_ file.
That is, unless I have already applied the patch, and am looking for the
reverse patch. And, lo and behold, the reverse patch generated by
git-diff really shows the now-current function name!
So IMO "fixing" this behaviour would be a regression.
Ciao,
Dscho
^ permalink raw reply
* Re: Subject: [PATCH 2/3] Let git-add--interactive read colors from .gitconfig
From: Dan Zwell @ 2007-11-13 1:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <7vve89f6qy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>> + $fg_done = "true";
>> + }
>> + elsif ($word =~ /black|red|green|yellow/ ||
>> + $word =~ /blue|magenta|cyan|white/) {
>
> exists $color_name{$word}
>
> with
>
> my %color_name = map { $_ => 1 } qw(black red ... white);
>
> at the beginning?
>
I don't see the advantage of doing it that way. After all, we're pattern
matching. Does using a hash, an array, and a call to map() gain us
something? I think a regular expression is clearer. Of course, as Jeff
pointed out, I should have used a whitespace-agnostic regular expression.
+ elsif ($word =~ /black|red|green|yellow|
+ blue|magenta|cyan|white/x ) {
I agreed with the rest of your suggestions, and will implement them in
the next round of changes, later this week.
Dan
^ permalink raw reply
* Re: Subject: [PATCH 2/3] Let git-add--interactive read colors from .gitconfig
From: Junio C Hamano @ 2007-11-13 2:32 UTC (permalink / raw)
To: Dan Zwell
Cc: Jeff King, Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <47390050.1020907@zwell.net>
Dan Zwell <dzwell@gmail.com> writes:
> Junio C Hamano wrote:
>>> + $fg_done = "true";
>>> + }
>>> + elsif ($word =~ /black|red|green|yellow/ ||
>>> + $word =~ /blue|magenta|cyan|white/) {
>>
>> exists $color_name{$word}
>>
>> with
>>
>> my %color_name = map { $_ => 1 } qw(black red ... white);
>>
>> at the beginning?
>>
> I don't see the advantage of doing it that way. After all, we're
> pattern matching. Does using a hash, an array, and a call to map()
> gain us something? I think a regular expression is clearer. Of course,
> as Jeff pointed out, I should have used a whitespace-agnostic regular
> expression.
I suggested the hash approach only because (1) it is easier to
read than two regexp matches that are split only to keep the
line less than 80-chars long, and (2) a misconfiguration like
"color.foo = fred" can be caught more easily.
I do not quite understand the "after all, we're pattern
matching" part, though. Are you talking about "split(/\s+/, $str)"
your for-loop iterates over?
^ permalink raw reply
* Re: git diff woes
From: Miles Bader @ 2007-11-13 2:53 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List
In-Reply-To: <4738E9E6.2040001@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> I notice it, and I don't like it. I guess I'm just used to git being
> smarter than their GNU tool equivalents, especially since it only ever
> applies patches in full.
It's not at all obvious that this behavior is actually wrong -- it seems
perfectly reasonable to use either old or new text for the hunk headers.
It hardly matters really, since that particular output is just "useful
noise" to provide a bit of helpful context for human readers, and humans
(unlike programs) are notoriously good at not being bothered by such
things. Er, well most humans anyway.
-Miles
--
Americans are broad-minded people. They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if a
man doesn't drive, there is something wrong with him. -- Art Buchwald
^ permalink raw reply
* Re: Subject: [PATCH 2/3] Let git-add--interactive read colors from .gitconfig
From: Dan Zwell @ 2007-11-13 2:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dan Zwell, Jeff King, Shawn O. Pearce, Wincent Colaiuta,
Git Mailing List, Jonathan del Strother, Johannes Schindelin,
Frank Lichtenheld
In-Reply-To: <7v4pfq27tx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> I suggested the hash approach only because (1) it is easier to
> read than two regexp matches that are split only to keep the
> line less than 80-chars long, and (2) a misconfiguration like
> "color.foo = fred" can be caught more easily.
>
> I do not quite understand the "after all, we're pattern
> matching" part, though. Are you talking about "split(/\s+/, $str)"
> your for-loop iterates over?
>
I think we're talking about the same thing. I was referring to the split
regular expression, and the question is, "for the current element of
split(/\s+/, $str), does it match a color?"
Anyway, I preferred the regex version for readability, though I should
have used the /x modifier--it would still take two lines, but it would
not need to attempt two matches. As for misconfigured color
configurations, should we catch that? I wrote this with the intent that
it should ignore invalid color names, but it would probably be more
useful to print a warning.
Dan
^ permalink raw reply
* The 5th issue of the msysGit Herald
From: Johannes Schindelin @ 2007-11-13 3:13 UTC (permalink / raw)
To: msysgit, git
Good morning git land!
This lovely dark 4am (see http://youtube.com/watch?v=yXi6hg90LUU) is
as good an occasion as any to offer to you the 5th issue of the
msysGit Herald, the not-quite-biweekly news letter to keep you
informed about msysGit, the effort to bring one of the most powerful
Source Code Management systems to the poor souls stuck with Windows.
These are the covered topics:
git-gui and git-fetch
git-svn
cvsps
git.git, mingw.git and 4msysgit.git closing ranks
Seems like this edition is mostly about transport... which is a good
sign. It means that the installer has no more issues and we can
concentrate on getting git on Windows to work.
git-gui and git-fetch
=====================
Some time ago, git-gui could call git-fetch to update the remotes, but
it popped up a new cmd window. This was ugly, and at some stage Shawn
Pearce, the maintainer of git-gui, changed some parts to avoid that.
Unfortunately, this broke fetching from within git-gui.
Warning: technical explanation ahead!
The problem is this: apparently there are two different kinds of
processes on Windows (actually three, but let's not make things
complicated, and for the same reason, let's not play the obvious pun
on Microsoft): graphical and console processes.
Whenever you start a console process from a graphical process, you
have to provide it with a console instance, which would be inherited
from the calling process if that were a console process, too. But in
our case, a graphical process calls a console process (this works),
which in turn calls another console process (this doesn't).
So the symptom is that git-fetch, called from git-gui, does not pop up
a cmd window, but ssh, which is called from git-fetch for ssh:// urls,
does.
I suspected a bug in Tcl/Tk, which might have been fixed in version
8.5b2, so I compiled it and tested it, but the behaviour is still the
same. At least we now have a script in our repository to conveniently
compile and install Tcl/Tk, should the need ever arise again!
Steffen Prohaska (see interview in the fourth Herald) and Johannes
Sixt (see interview in the second Herald) are currently hard at work
to flesh out this issue, and maybe the solution lies in using Putty's
plink instead of MSys' ssh.
Or maybe we will find some clever way to replace the spawnvpe() call
with a CreateProcess() call which forces the console instance to be
inherited by the called process. Hannes suggested that a possible
reason is our heavy usage of dup2(), which might be helped by using
CreateProcess(), but only time, and a fix, will tell what happens
here.
git-svn
=======
It seems that quite a few people want to have a working git-svn in
msysGit. In our bug tracker, this problem comes in disguise such as
"Digest.pm is missing".
Alas, it is not as easy as that... Perl is an MSys program (remember,
MSys gives you Unix-like paths relative to the install location), and
compiling that came with its own set of surprises: you need to use a
different compiler than for MinGW programs!
As I wrote in the third Herald, Simon Sasburg was hard at work to get
it to compile, and finally succeeded. But dynamically linked modules
(otherwise known as DLLs) would not work, instead resulting in
Windows' version of a segmentation fault.
A few more days of trial and error led to the discovery of a source
package of Perl for MSys, which was successfully munged into a
quilt-like setup: we now have a script to download Perl's sources,
patch them with our set of patches, build, install and prepare
everything for commit.
The next steps are easy: git-svn's dependencies MIME-Base64, Digest
and Digest-MD5 are nice to build and install.
The bigger chunk will be to get subversion and its Perl module to
compile, especially given the dependency of the Apache Runtime (APR):
subversion's configure complains that it was not found, and the
documentation suggest to -- you guessed it -- checking it out with
subversion.
Stay tuned.
cvsps
=====
While working at git-svn, I also though about git-cvsimport. This tool
heavily depends on cvsps, a program which was inspired by the
PatchSets of the source code management system git set out to replace.
It is not all that trivial to compile cvsps on MSys, though, since it
really loves our good old friend, fork().
Alas, Peer Sommerlund already worked on compiling this on Windows, and
was friendly enough to export his Mercurial commits as plain patches,
which soon found their way into a git repository. Now cvsps compiles
fine, but cvsimport still fails to work, probably because Peer's
patches make a few assumptions about the cvs program he used: cvsnt.
It's likely not hard to work out the kinks until it works, but the
time to do so successfully avoided finding me.
git.git, mingw.git and 4msysgit.git closing ranks
=================================================
The official repository for git is git.git, maintained by Junio C
Hamano. It does not contain any support for MinGW, because the port is
not polished enough yet. Johannes "Hannes" Sixt maintains the official
port to MinGW in the mingw.git fork of Junio's repository, and since
the msysGit project started during Hannes' vacation, mingw.git was
forked yet again, as 4msysgit.git.
It is not totally superfluous to have separate repositories for these
projects, because they differ in workflow and focus. For example, one
of the big goals of the msysGit project was to provide an integrated
installer which comes with everything you will need to run git on
Windows (including MSys with its bash and perl), while the MinGW port
tries to avoid the dependency on MSys as much as possible.
But recently Hannes has succeeded in polishing a few topics from
mingw.git to the point where Junio included them in git.git. There is
no MinGW specific code yet, but the foundations are laid.
In related news, Steffen Prohaska has undertaken some tremendous
effort to merge mingw.git's 'master' branch into 4msysgit.git's
'devel' branch. Maybe we succeed at some stage to close in totally on
mingw.git, and then we'll probably move our history to some
"historical" branch, and just keep with mingw.git's master.
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Jeff King @ 2007-11-13 4:14 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910711120928r6d9d08f0l22f3c6f0b2d80313@mail.gmail.com>
On Mon, Nov 12, 2007 at 12:28:28PM -0500, Jon Smirl wrote:
> Actually, fetching from kernel.org first and then switching the origin
> isn't helping. The host is http only since I can't get access to the
> git network port. When I pushed up my local repo it ends up in one big
> pack.
>
> I do this:
> git clone kernel.org
> move the origin
> git pull
> -- it still pulls down the entire pack and takes an hour
Yep, the http fetch code doesn't understand about fetching parts of
packs (there was some discussion about using partial HTTP transfers, but
nobody seems to have cared enough to implement it).
> Will this fix it?
> at my remote host, first clone from kernel.org
> then push my local changes?
Yes, it should. The goal is to not put your changes and the upstream
commits in the same pack. You could also push _just_ the upstream
commits first, then in a different push, send your local changes. But
when they get pushed together, they all end up in the same pack.
-Peff
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Jeff King @ 2007-11-13 4:20 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910711120921q651208cby1276426ccd4b5fa4@mail.gmail.com>
On Mon, Nov 12, 2007 at 12:21:20PM -0500, Jon Smirl wrote:
> Running git update-server-info at the remote end fixed it.
>
> I am using 'git push' to send changes, I though that was supposed to
> update the server info automatically.
It is typically triggered by the post-update hook. Make sure that your
remote repo's .git/hooks/post-update has the execute bit set.
-Peff
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Jeff King @ 2007-11-13 4:23 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Linus Torvalds, Git Mailing List
In-Reply-To: <9e4733910711121254j5af5dba6k5acdce939936af66@mail.gmail.com>
On Mon, Nov 12, 2007 at 03:54:59PM -0500, Jon Smirl wrote:
> It is eaiser to put
> git config remote.origin.url
> http://git.digispeaker.com/projects/digispeaker-kernel.git
> in a cookbook web page sequence than say edit the config file by hand.
I think that falls under "scripting" (it's just that your interpreter is
a human).
> I added the cookbook sequence to my git project page.
> http://git.digispeaker.com/
> Without cloning from kernel.org first it takes an hour to clone from
> dreamhost, but what do you want for $5/mth. I'll more to a better host
> when traffic picks up.
It sounds like you are posting commits on top of Linus' kernel tree. Why
not use repo.or.cz's hosting? It's free, and it _already_ has the
linus-2.6 tree, so you can start a 'fork' and not even waste any space.
-Peff
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Jon Smirl @ 2007-11-13 4:30 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <20071113042017.GB9745@sigill.intra.peff.net>
On 11/12/07, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 12, 2007 at 12:21:20PM -0500, Jon Smirl wrote:
>
> > Running git update-server-info at the remote end fixed it.
> >
> > I am using 'git push' to send changes, I though that was supposed to
> > update the server info automatically.
>
> It is typically triggered by the post-update hook. Make sure that your
> remote repo's .git/hooks/post-update has the execute bit set.
Execute bit was not set. I just set it for all the scripts. +x is not
getting turned on with a default git init-db. I just made a new repo
to check, no +x on the scripts.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Jon Smirl @ 2007-11-13 4:33 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Linus Torvalds, Git Mailing List
In-Reply-To: <20071113042342.GC9745@sigill.intra.peff.net>
On 11/12/07, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 12, 2007 at 03:54:59PM -0500, Jon Smirl wrote:
>
> > It is eaiser to put
> > git config remote.origin.url
> > http://git.digispeaker.com/projects/digispeaker-kernel.git
> > in a cookbook web page sequence than say edit the config file by hand.
>
> I think that falls under "scripting" (it's just that your interpreter is
> a human).
>
> > I added the cookbook sequence to my git project page.
> > http://git.digispeaker.com/
> > Without cloning from kernel.org first it takes an hour to clone from
> > dreamhost, but what do you want for $5/mth. I'll more to a better host
> > when traffic picks up.
>
> It sounds like you are posting commits on top of Linus' kernel tree. Why
> not use repo.or.cz's hosting? It's free, and it _already_ has the
> linus-2.6 tree, so you can start a 'fork' and not even waste any space.
It's the kernel for a larger embedded project. After I get the kernel
going I will add the user space environment at the same web site.
The project is described at www.digispeaker.com. It is an open source
multi-room audio system. Wifi based to allow easy installation. Uses
the MPC5200B PowerPC chip.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Jeff King @ 2007-11-13 4:48 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910711122030q7bbf6057ubb6b5b27e1885500@mail.gmail.com>
On Mon, Nov 12, 2007 at 11:30:17PM -0500, Jon Smirl wrote:
> Execute bit was not set. I just set it for all the scripts. +x is not
I assume by "all the scripts" you mean "all of the post-update scripts
in my repositories" and not "all of the hook scripts in this
repository". Because I think some of the included hooks are not suitable
to run without some configuration, which is why they are disabled by
default.
> getting turned on with a default git init-db. I just made a new repo
> to check, no +x on the scripts.
Right. git-init just copies the files from the templates directory
(probably /usr/share/git-core/templates or similar), so if the hook is
not enabled there, it will not be in the new repo. And git ships with
all hooks disabled by default.
cogito used to enable the post-update hook by default for bare repos (if
you called cg-admin-setuprepo), but git never has.
It is mentioned in the "exporting a git repository via http" section of
the user manual.
-Peff
^ permalink raw reply
* [PATCH 4/2] Fix parent rewriting in --early-output
From: Linus Torvalds @ 2007-11-13 4:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Marco Costalba, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0711041124050.15101@woody.linux-foundation.org>
When we do history simplification in early-output, we end up in the
interesting situation that the early output may do simplification with a
partial tree - in particular, there may be parents that simply haven't
been handled yet, and don't have their parenthood parsed.
The history simplification would get this case totally wrong, and assume
that the parent list of a parent being NULL meant that it was a root
commit, and rewrite the whole parent as such.
This would cause unconnected commits in the gitk output.
This fixes it, by saying that if you reach a parent that hasn't been
parsed yet, history simplification will simply stop and leave it alone:
later on, when we have the full history, we will *continue* the
simplification and eventually get the right information.
However, while the parent is now correctly rewritten, it looks like gitk
is confused by this. Gitk will remember the original parent information,
even if a replay has given new parenthood information. Since the partial
early-output information is triggered by timing, this means that gitk will
show some totally random parent that quite possibly won't even be part of
the final commit set at all!
On the kernel, at least with my machine, I can trigger this with something
like
gitk fs/read_write.c
where currently the log (with --parents) reads like this:
commit a16877ca9cec211708a161057a7cbfbf2cbc3a53 d96e6e71647846e0dab097efd9b8bf3a3a556dca
Author: Pavel Emelyanov <xemul@openvz.org>
Date: Mon Oct 1 14:41:11 2007 -0700
Cleanup macros for distinguishing mandatory locks
..
commit d96e6e71647846e0dab097efd9b8bf3a3a556dca d6b29d7cee064f28ca097e906de7453541351095
Author: Jens Axboe <jens.axboe@oracle.com>
Date: Mon Jun 11 12:18:52 2007 +0200
Remove remnants of sendfile()
...
but with early-output (and this fixed patch), I get something like this:
Final output: 1 incomplete
commit a16877ca9cec211708a161057a7cbfbf2cbc3a53 31b54f40e12e4d04941762be6615edaf3c6ed811
Author: Pavel Emelyanov <xemul@openvz.org>
Date: Mon Oct 1 14:41:11 2007 -0700
Cleanup macros for distinguishing mandatory locks
...
Final output: 26 done
commit a16877ca9cec211708a161057a7cbfbf2cbc3a53 d96e6e71647846e0dab097efd9b8bf3a3a556dca
Author: Pavel Emelyanov <xemul@openvz.org>
Date: Mon Oct 1 14:41:11 2007 -0700
Cleanup macros for distinguishing mandatory locks
..
ie notice how the early-output doesn't have the right parent, since it
hasn't gotten that far back in history yet. So now the final output will
have the parenthood rewritten (correctly), but gitk will have cached the
old random incorrect parenthood, and doesn't react properly to the updated
and fixed one at replay time.
Anyway, this is a real fix, but gitk remains a bit useless as is.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
revision.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/revision.c b/revision.c
index 931f978..8872a91 100644
--- a/revision.c
+++ b/revision.c
@@ -1352,6 +1352,8 @@ static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp
if (!revs->limited)
if (add_parents_to_list(revs, p, &revs->commits) < 0)
return rewrite_one_error;
+ if (!p->object.parsed)
+ return rewrite_one_ok;
if (p->parents && p->parents->next)
return rewrite_one_ok;
if (p->object.flags & (TREECHANGE | UNINTERESTING))
^ permalink raw reply related
* Re: [PATCH] for-each-ref: fix off by one read.
From: Christian Couder @ 2007-11-13 5:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxzb1032.fsf@gitster.siamese.dyndns.org>
Le mardi 13 novembre 2007, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
> > index 598d4e1..89ea37c 100644
> > --- a/builtin-for-each-ref.c
> > +++ b/builtin-for-each-ref.c
> > @@ -306,7 +306,7 @@ static const char *find_wholine(const char *who,
> > int wholen, const char *buf, un if (!eol)
> > return "";
> > eol++;
> > - if (eol[1] == '\n')
> > + if (*eol == '\n')
> > return ""; /* end of header */
> > buf = eol;
> > }
>
> Good eyes.
Well, Valgrind found it when I did:
$ valgrind git for-each-ref --format='%(refname)' "refs/tags/*"
> This would have broken if
> (1) we had a header field that consists of a single character
> and then LF. We would have mistaken such a line as the end
> of header; or
>
> (2) we had a commit or a tag that consists solely of header and
> no body. We would have read past the terminating NUL.
I suspect that the end of the header was not properly detected, so that it
may have read one byte past a body ending with LF and the terminating NUL.
Christian.
^ permalink raw reply
* Re: [PATCH] git-clean: Fix error message if clean.requireForce is not set.
From: Junio C Hamano @ 2007-11-13 5:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List, Shawn Bohrer
In-Reply-To: <47380E77.9040205@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> It was distracting to see this error message:
>
> clean.requireForce set and -n or -f not given; refusing to clean
>
> even though clean.requireForce was not set at all. This patch distinguishes
> the cases and gives a different message depending on whether the
> configuration variable is not set or set to true.
And this will be the counterpart for 'pu'...
---
builtin-clean.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/builtin-clean.c b/builtin-clean.c
index 55658e7..01fb887 100644
--- a/builtin-clean.c
+++ b/builtin-clean.c
@@ -11,7 +11,7 @@
#include "dir.h"
#include "parse-options.h"
-static int force;
+static int force = -1; /* unset */
static const char *const builtin_clean_usage[] = {
"git-clean [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...",
@@ -29,7 +29,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
{
int j;
int show_only = 0, remove_directories = 0, quiet = 0, ignored = 0;
- int ignored_only = 0, baselen = 0;
+ int ignored_only = 0, baselen = 0, config_set = 0;
struct strbuf directory;
struct dir_struct dir;
const char *path, *base;
@@ -49,6 +49,11 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
git_config(git_clean_config);
argc = parse_options(argc, argv, options, builtin_clean_usage, 0);
+ if (force < 0)
+ force = 0;
+ else
+ config_set = 1;
+
memset(&dir, 0, sizeof(dir));
if (ignored_only) {
dir.show_ignored =1;
@@ -59,7 +64,8 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
die("-x and -X cannot be used together");
if (!show_only && !force)
- die("clean.requireForce set and -n or -f not given; refusing to clean");
+ die("clean.requireForce%s set and -n or -f not given; "
+ "refusing to clean", config_set ? "" : " not");
dir.show_other_directories = 1;
^ permalink raw reply related
* Re: [PATCH 4/2] Fix parent rewriting in --early-output
From: Junio C Hamano @ 2007-11-13 5:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, Marco Costalba, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711122046570.2786@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Anyway, this is a real fix, but gitk remains a bit useless as is.
>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> ---
> revision.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/revision.c b/revision.c
> index 931f978..8872a91 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -1352,6 +1352,8 @@ static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp
> if (!revs->limited)
> if (add_parents_to_list(revs, p, &revs->commits) < 0)
> return rewrite_one_error;
> + if (!p->object.parsed)
> + return rewrite_one_ok;
> if (p->parents && p->parents->next)
> return rewrite_one_ok;
> if (p->object.flags & (TREECHANGE | UNINTERESTING))
This is too subtle, or I am missing something.
I have to wonder what would happen if a much higher level caller
caused the objects to get parsed before coming into the revision
walking machinery, e.g. after the command line processing for
A...B walked the ancestry chain until their common ancestors are
found. So these commits between A and B are parsed, but the
revision limiting machinery hasn't done its operation to set
TREECHANGE and/or UNINTERESTING in add_parents_to_list() on
these commits yet.
I think the fix will not trigger for such parents, but the
processing just goes on.
^ permalink raw reply
* Re: [PATCH 4/2] Fix parent rewriting in --early-output
From: Linus Torvalds @ 2007-11-13 6:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, Marco Costalba, Git Mailing List
In-Reply-To: <7v1wauzomr.fsf@gitster.siamese.dyndns.org>
On Mon, 12 Nov 2007, Junio C Hamano wrote:
>
> This is too subtle, or I am missing something.
It's subtle. And you're probably right, I need to fix it up some more.
It works, but it works for all the wrong reasons. When thinking about it,
you need to keep three "generations" of commits in mind. Let's call them
"c" (commit), "p" (parent of c) and "pp" (parent of p) respectively.
What is going on is:
- we have calculated TREECHANGE for "c".
- that, in turn, means that we have parsed "p" (it's done by
add_parents_to_list() - either as part of try_to_simplify_commit(), or
if that code doesn't trigger, by the later loop over the parents)
- but we haven't parsed "pp" yet.
Now, when we decide to rewrite "c", we look at whether we can change the
parent list of c to point from "p" to "pp". But with the added check, we
now will trigger on the fact that "pp" hasn't even been parsed yet, so we
won't even try, and we leave the parent list alone.
But I agree, I don't think it's really stable. We could have gotten to
"pp" through some other chain.
I think the real problem is that "TREECHANGE" has the wrong polarity. It
should default to always being set, and then we could actively clear it
when we do the work to say "it's the same tree". Instead, we default it to
being the same (which triggers parent rewriting), and only later may we
notice that it wasn't the same.
Linus
^ permalink raw reply
* Re: [PATCH 4/2] Fix parent rewriting in --early-output
From: Linus Torvalds @ 2007-11-13 7:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, Marco Costalba, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711122238330.2786@woody.linux-foundation.org>
On Mon, 12 Nov 2007, Linus Torvalds wrote:
>
> I think the real problem is that "TREECHANGE" has the wrong polarity. It
> should default to always being set, and then we could actively clear it
> when we do the work to say "it's the same tree". Instead, we default it to
> being the same (which triggers parent rewriting), and only later may we
> notice that it wasn't the same.
So, maybe the proper solution is to say "commits are assumed to be
different to their parents, but we have an explicit bit saying TREESAME
when we find them to be the same".
This solves the problem quite naturally, because any tree that hasn't been
parsed - or even if it *has* been parsed, but just hasn't gone through
the compare function - will then always be seen as "different" and thus
interesting.
This fairly straight-forward patch seems to work. It *replaces* the
pervious "patch 4/2", and yes, Junio, I think you were very right to
complain about that one.
How does this one feel? It basically says "a commit that has TREESAME set
is kind-of-UNINTERESTING", but obviously in a different way than an
outright UNINTERESTING commit.
The diff is pretty straightforward - just change the sense of TREECHANGE,
and that sometimes removes a line, and sometimes adds one, but most of the
changes are just TREECHANGE => TREESAME, together with a negation of the
operation.
Linus
---
builtin-fmt-merge-msg.c | 2 +-
builtin-log.c | 2 +-
builtin-rev-list.c | 16 ++++++++--------
revision.c | 22 +++++++++++-----------
revision.h | 2 +-
5 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index 8a3c962..6163bd4 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -176,7 +176,7 @@ static void shortlog(const char *name, unsigned char *sha1,
struct commit *commit;
struct object *branch;
struct list subjects = { NULL, NULL, 0, 0 };
- int flags = UNINTERESTING | TREECHANGE | SEEN | SHOWN | ADDED;
+ int flags = UNINTERESTING | TREESAME | SEEN | SHOWN | ADDED;
branch = deref_tag(parse_object(sha1), sha1_to_hex(sha1), 40);
if (!branch || branch->type != OBJ_COMMIT)
diff --git a/builtin-log.c b/builtin-log.c
index d6845bc..54ddaad 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -89,7 +89,7 @@ static int estimate_commit_count(struct rev_info *rev, struct commit_list *list)
struct commit *commit = list->item;
unsigned int flags = commit->object.flags;
list = list->next;
- if ((flags & TREECHANGE) && !(flags & UNINTERESTING))
+ if (!(flags & (TREESAME | UNINTERESTING)))
n++;
}
return n;
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 2dec887..0258ec4 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -142,7 +142,7 @@ static int count_distance(struct commit_list *entry)
if (commit->object.flags & (UNINTERESTING | COUNTED))
break;
- if (commit->object.flags & TREECHANGE)
+ if (!(commit->object.flags & TREESAME))
nr++;
commit->object.flags |= COUNTED;
p = commit->parents;
@@ -198,7 +198,7 @@ static inline int halfway(struct commit_list *p, int nr)
/*
* Don't short-cut something we are not going to return!
*/
- if (!(p->item->object.flags & TREECHANGE))
+ if (p->item->object.flags & TREESAME)
return 0;
if (DEBUG_BISECT)
return 0;
@@ -234,7 +234,7 @@ static void show_list(const char *debug, int counted, int nr,
char *ep, *sp;
fprintf(stderr, "%c%c%c ",
- (flags & TREECHANGE) ? 'T' : ' ',
+ (flags & TREESAME) ? ' ' : 'T',
(flags & UNINTERESTING) ? 'U' : ' ',
(flags & COUNTED) ? 'C' : ' ');
if (commit->util)
@@ -268,7 +268,7 @@ static struct commit_list *best_bisection(struct commit_list *list, int nr)
int distance;
unsigned flags = p->item->object.flags;
- if (!(flags & TREECHANGE))
+ if (flags & TREESAME)
continue;
distance = weight(p);
if (nr - distance < distance)
@@ -308,7 +308,7 @@ static struct commit_list *best_bisection_sorted(struct commit_list *list, int n
int distance;
unsigned flags = p->item->object.flags;
- if (!(flags & TREECHANGE))
+ if (flags & TREESAME)
continue;
distance = weight(p);
if (nr - distance < distance)
@@ -362,7 +362,7 @@ static struct commit_list *do_find_bisection(struct commit_list *list,
p->item->util = &weights[n++];
switch (count_interesting_parents(commit)) {
case 0:
- if (flags & TREECHANGE) {
+ if (!(flags & TREESAME)) {
weight_set(p, 1);
counted++;
show_list("bisection 2 count one",
@@ -435,7 +435,7 @@ static struct commit_list *do_find_bisection(struct commit_list *list,
* add one for p itself if p is to be counted,
* otherwise inherit it from q directly.
*/
- if (flags & TREECHANGE) {
+ if (!(flags & TREESAME)) {
weight_set(p, weight(q)+1);
counted++;
show_list("bisection 2 count one",
@@ -482,7 +482,7 @@ static struct commit_list *find_bisection(struct commit_list *list,
continue;
p->next = last;
last = p;
- if (flags & TREECHANGE)
+ if (!(flags & TREESAME))
nr++;
on_list++;
}
diff --git a/revision.c b/revision.c
index 931f978..5796153 100644
--- a/revision.c
+++ b/revision.c
@@ -311,17 +311,15 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
/*
* If we don't do pruning, everything is interesting
*/
- if (!revs->prune) {
- commit->object.flags |= TREECHANGE;
+ if (!revs->prune)
return;
- }
if (!commit->tree)
return;
if (!commit->parents) {
- if (!rev_same_tree_as_empty(revs, commit->tree))
- commit->object.flags |= TREECHANGE;
+ if (rev_same_tree_as_empty(revs, commit->tree))
+ commit->object.flags |= TREESAME;
return;
}
@@ -329,10 +327,8 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
* Normal non-merge commit? If we don't want to make the
* history dense, we consider it always to be a change..
*/
- if (!revs->dense && !commit->parents->next) {
- commit->object.flags |= TREECHANGE;
+ if (!revs->dense && !commit->parents->next)
return;
- }
pp = &commit->parents;
while ((parent = *pp) != NULL) {
@@ -357,6 +353,7 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
}
parent->next = NULL;
commit->parents = parent;
+ commit->object.flags |= TREESAME;
return;
case REV_TREE_NEW:
@@ -385,7 +382,8 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
die("bad tree compare for commit %s", sha1_to_hex(commit->object.sha1));
}
if (tree_changed && !tree_same)
- commit->object.flags |= TREECHANGE;
+ return;
+ commit->object.flags |= TREESAME;
}
static int add_parents_to_list(struct rev_info *revs, struct commit *commit, struct commit_list **list)
@@ -1354,7 +1352,9 @@ static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp
return rewrite_one_error;
if (p->parents && p->parents->next)
return rewrite_one_ok;
- if (p->object.flags & (TREECHANGE | UNINTERESTING))
+ if (p->object.flags & UNINTERESTING)
+ return rewrite_one_ok;
+ if (!(p->object.flags & TREESAME))
return rewrite_one_ok;
if (!p->parents)
return rewrite_one_noparents;
@@ -1427,7 +1427,7 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
return commit_ignore;
if (revs->prune && revs->dense) {
/* Commit without changes? */
- if (!(commit->object.flags & TREECHANGE)) {
+ if (commit->object.flags & TREESAME) {
/* drop merges unless we want parenthood */
if (!revs->parents)
return commit_ignore;
diff --git a/revision.h b/revision.h
index a798514..992e1e9 100644
--- a/revision.h
+++ b/revision.h
@@ -3,7 +3,7 @@
#define SEEN (1u<<0)
#define UNINTERESTING (1u<<1)
-#define TREECHANGE (1u<<2)
+#define TREESAME (1u<<2)
#define SHOWN (1u<<3)
#define TMP_MARK (1u<<4) /* for isolated cases; clean after use */
#define BOUNDARY (1u<<5)
^ permalink raw reply related
* Re: Subject: [PATCH 2/3] Let git-add--interactive read colors from .gitconfig
From: Jeff King @ 2007-11-13 7:26 UTC (permalink / raw)
To: Dan Zwell
Cc: Junio C Hamano, Shawn O. Pearce, Wincent Colaiuta,
Git Mailing List, Jonathan del Strother, Johannes Schindelin,
Frank Lichtenheld
In-Reply-To: <47391211.5000606@zwell.net>
On Mon, Nov 12, 2007 at 08:55:13PM -0600, Dan Zwell wrote:
> Anyway, I preferred the regex version for readability, though I should have
> used the /x modifier--it would still take two lines, but it would not need
Your regex is wrong, because it doesn't anchor at the beginning and end
of the string (so /red/ will match "supercaliredfragilistic", which is
probably not what you want). So you probably want /^red$/, which is
equivalent to using 'eq' with 'red'. Or, as Junio noted, you are overall
trying to say "is element $word in this list"; the canonical perl way of
doing that is to make the list a hash for quick lookup.
> to attempt two matches. As for misconfigured color configurations, should we
> catch that? I wrote this with the intent that it should ignore invalid color
> names, but it would probably be more useful to print a warning.
Your patch doesn't just ignore; sometimes it accidentally matches
invalid input (the example above is obviously silly, but consider what
accidentally omitting the space in "blinkblack" would do).
-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