* Re: [PATCH] Fix linking for not-so-clever linkers.
From: Junio C Hamano @ 2006-07-10 21:48 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0607101429460.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 10 Jul 2006, Junio C Hamano wrote:
>>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > On one of my systems, the linker is not intelligent enough to link with
>> > pager.o (in libgit.a) when only the variable pager_in_use is needed. The
>> > consequence is that the linker complains about an undefined
>> > variable.
>>
>> I do not understand this quite yet -- which executable is your
>> linker building when it does this?
>> Maybe we need ranlib?
>
> Shouldn't be needed, since we use "$(AR) rcs",...
> ... After all, that was the
> whole reason environment.c ended up existing in the first place..
Understood and agreed to everything you said.
But I still wonder why/how it happens in Johannes's
environment...
^ permalink raw reply
* reflog doesn't note that commit was --amend-ed, and doesn't record pulls
From: Jakub Narebski @ 2006-07-10 21:49 UTC (permalink / raw)
To: git
In-Reply-To: <e8uele$o7t$2@sea.gmane.org>
Additionally, while reflog records git-reset invocations, it doesn't
distinguish between an ordinary commit, and commit --amend (which I do
a lot, most time because of forgotten update-index; yes, I know about commit
-a option ;-). Well, you can extract this information looking at current
and previous commit sha1, but it would be nice to have it noted somewhat in
message part of reflog.
Reflog doesn't seem also to record pulls (e.g. master branch): pulls has
empty reflog message part.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: can I get only the list of merges?
From: Johannes Schindelin @ 2006-07-10 22:37 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: Diego Calleja, git
In-Reply-To: <E1FzzlS-0003JE-9C@moooo.ath.cx>
Hi,
On Mon, 10 Jul 2006, Matthias Lederhofer wrote:
> git-rev-list --parents HEAD | \
> grep -E '^([a-z0-9]{40} ){2}[a-z0-9]{40}' | \
Since the output of git-rev-list is well-defined, you could say
grep '.{121}'
instead. (Instead of 121, you could take any number between 83 and 122.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Johannes Schindelin @ 2006-07-10 22:55 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Paul Serice, Junio C Hamano, git
In-Reply-To: <20060710202412.GA8189@dspnet.fr.eu.org>
Hi,
On Mon, 10 Jul 2006, Olivier Galibert wrote:
> On Mon, Jul 10, 2006 at 02:14:17PM -0500, Paul Serice wrote:
> > If you want to write portable code, you have to take into account
> > different operating systems _and_ different compilers. Writing your
> > code for just a single compiler is almost as bad as writing your code
> > for just a single operating system.
>
> Hmmm, that was not so much about gcc-specific code than which kind of
> C you want to code to, the one from 1973, the one from 1989 or the one
> from 1999? I personally don't have much sympathy for the OS vendors
> giving you an older standard C compiler and selling you the up-to-date
> one.
Judging by what you say, one could get the impression you'd have not much
sympathy for people being stuck with non-C99 compilers.
Just look at it: if the OS vendor just does not _care_, and you blame the
vendor for not providing something newer, the vendor does not _care_ about
your complaint either. But the user does.
However, there is a more important point to be made. If you are complying
with an older standard, you get more users. More users = more bug testers.
And there were quite a few occasions where I found bugs by trying to run
on a different platform, which was less forgiving than Linux. These are
bugs you have a harder time to spot on Linux, _because_ Linux is so nice.
But they will surface. And they will be a PITA to find.
Anyway, it is best practice for a reason to program portably. (Well, at
least if you are not living in Redmont.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix linking for not-so-clever linkers.
From: Johannes Schindelin @ 2006-07-10 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64i5b1am.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 10 Jul 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On one of my systems, the linker is not intelligent enough to link with
> > pager.o (in libgit.a) when only the variable pager_in_use is needed. The
> > consequence is that the linker complains about an undefined
> > variable.
>
> I do not understand this quite yet -- which executable is your
> linker building when it does this?
The problem arises for the first time with git-blame. (Have not checked
which other executables might be affected.)
> Maybe we need ranlib?
Does not help. pager.o is in libgit.a. Still, Darwin's linker does not
want to link to pager.o (probably because no function from pager.o is
called, so this is a real bug in the Darwin linker -- but being easy to
fix, I think it is worthwhile to fix it).
Ciao,
Dscho
^ permalink raw reply
* Revisiting large binary files issue.
From: Carl Baldwin @ 2006-07-10 23:01 UTC (permalink / raw)
To: git
Hi,
Some of this stuff has been discussed before but I thought I'd bring it
up again.
I am using git in a way for which, admittedly, it was not intended. I
have repositories in which I'm storing some source code mixed with some
large binary files (from 20MB up to 1GB in the worst case). The large
files easily dominate the space in the repository and the time that it
takes to perform network operations between repositories.
Just to refresh your memory a sample of these files led to work that
Nicolas did to improve the performance of packing large binary files.
Thank you Nicolas, I think your work improved the speed of git in the
face of largish files.
Attempting to delta compress these blobs is a frivolous effort. The
nature of the blobs is such that if given two blobs: 'A', and the next
revision, 'B' it is just as good --- from a pack-size standpoint --- to
compress the entire contents of 'B' than try to find a delta from A ->
B. It is also much faster than trying to find deltas. In git, I can
accomplish this by setting the pack window (I think this is right) to 0.
When I set the window to 0 I one more issue. Even though the blobs are
already compressed on disk I still seem to pay the penalty of inflating
them into memory and then deflating them into the pack. When the window
size is 0 this is just wasted cycles. With large binary files these
wasted cycles slow down the push/fetch operation considerably. Couldn't
the compressed blobs be copied into the pack without first deflating
them in this 0 window case?
My 'porcelain' on top of git works around these issues by first rsyncing
the object directories and then running the git push/fetch command
afterward. The push/fetch command sees that the remote is up-to-date
with all the necessary objects and skips packing. This works and is
fast (much faster than even packing with window of 0 because of the time
to inflate/deflate the objects) but I'd like to remove this work-around
in the long-term.
Ideally, there are two things that I would like available with git to be
able to remove my work-around.
First, I would like to be able to set the packing window to 0 for all of
the git commands. It would be nice if I could set this in a
per-repository config file so that any push/fetch operation would honor
this window. Is there currently a way to do this?
Second, I would like to not pay the penalty to inflate and then deflate
the objects into the pack when I use a window of 0. How hard would this
be? I am a capable programmer and wouldn't mind getting my hands dirty
in the code to implement this if someone could point me in the right
direction.
Thanks for your time,
Carl Baldwin
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin RADCAD (R&D CAD)
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: Revisiting large binary files issue.
From: Junio C Hamano @ 2006-07-10 23:14 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20060710230132.GA11132@hpsvcnb.fc.hp.com>
Carl Baldwin <cnb@fc.hp.com> writes:
> First, I would like to be able to set the packing window to 0 for all of
> the git commands. It would be nice if I could set this in a
> per-repository config file so that any push/fetch operation would honor
> this window. Is there currently a way to do this?
Should not be hard to add.
> Second, I would like to not pay the penalty to inflate and then deflate
> the objects into the pack when I use a window of 0. How hard would this
> be? I am a capable programmer and wouldn't mind getting my hands dirty
> in the code to implement this if someone could point me in the right
> direction.
The problem is that unpacked objects have the single line header
(type followed by its inflated size in decimal) which starts the
deflated stream, while in-pack representation of non-delta does
not.
There was an attempt to help doing this, but I haven't pursued it.
http://article.gmane.org/gmane.comp.version-control.git/17368
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Yakov Lerner @ 2006-07-10 23:25 UTC (permalink / raw)
Cc: git
In-Reply-To: <Pine.LNX.4.63.0607110049470.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 7/11/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 10 Jul 2006, Olivier Galibert wrote:
>
> > On Mon, Jul 10, 2006 at 02:14:17PM -0500, Paul Serice wrote:
> > > If you want to write portable code, you have to take into account
> > > different operating systems _and_ different compilers. Writing your
> > > code for just a single compiler is almost as bad as writing your code
> > > for just a single operating system.
> >
> > Hmmm, that was not so much about gcc-specific code than which kind of
> > C you want to code to, the one from 1973, the one from 1989 or the one
> > from 1999? I personally don't have much sympathy for the OS vendors
> > giving you an older standard C compiler and selling you the up-to-date
> > one.
>
> Judging by what you say, one could get the impression you'd have not much
> sympathy for people being stuck with non-C99 compilers.
>
> Just look at it: if the OS vendor just does not _care_, and you blame the
> vendor for not providing something newer, the vendor does not _care_ about
> your complaint either. But the user does.
>
> However, there is a more important point to be made. If you are complying
> with an older standard, you get more users. More users = more bug testers.
>
> And there were quite a few occasions where I found bugs by trying to run
> on a different platform, which was less forgiving than Linux. These are
> bugs you have a harder time to spot on Linux, _because_ Linux is so nice.
> But they will surface. And they will be a PITA to find.
>
> Anyway, it is best practice for a reason to program portably. (Well, at
> least if you are not living in Redmont.)
Back in the beginning of nineties, c89 was new and the
prototypes was not yet impemented on many compilers.
One good trick of the time was automatic
source conversion. This protoize/unprotoize tool converted
sources from non-prototyped form to
prototyped, and the other way. (There was also #ifdef-trick
which was ugly as hell for the same purpose, and the __P()
macro trick, which was less ugly).
The benefit was that you got the benefit of both worlds,
(1) the benefit of prototypes when compiler was c89-compliant, and
(2) compilability with pre-c89 compilers when needed.
I am writing in order to ask, whether there maybe
some c99-to-c89 source convertor that can be
automatically applied to the .c before compiling with
pre-c99 compiler ?
Yakov
^ permalink raw reply
* Re: Revisiting large binary files issue.
From: Linus Torvalds @ 2006-07-10 23:28 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20060710230132.GA11132@hpsvcnb.fc.hp.com>
On Mon, 10 Jul 2006, Carl Baldwin wrote:
>
> When I set the window to 0 I one more issue. Even though the blobs are
> already compressed on disk I still seem to pay the penalty of inflating
> them into memory and then deflating them into the pack. When the window
> size is 0 this is just wasted cycles. With large binary files these
> wasted cycles slow down the push/fetch operation considerably. Couldn't
> the compressed blobs be copied into the pack without first deflating
> them in this 0 window case?
The problem is that the individual object disk format isn't actually the
same as the pack-file object format for one object. The header is
different: a pack-file uses a very dense bit packing, while the individual
object format is a bit less dense.
Sad, really, but it means that right now you can only re-use data that was
already packed (when the format matches).
Linus
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Olivier Galibert @ 2006-07-10 23:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Paul Serice, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0607110049470.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Jul 11, 2006 at 12:55:59AM +0200, Johannes Schindelin wrote:
> Judging by what you say, one could get the impression you'd have not much
> sympathy for people being stuck with non-C99 compilers.
More and more these people are stuck with such a compiler because they
want to be.
> Just look at it: if the OS vendor just does not _care_, and you blame the
> vendor for not providing something newer, the vendor does not _care_ about
> your complaint either. But the user does.
Well, I'm not talking about git here, but I'm not really interested in
making my code harder to maintain just to provide more value for said
vendor.
> However, there is a more important point to be made. If you are complying
> with an older standard, you get more users. More users = more bug testers.
On such systems, what you tend to find is bugs of the system, or
simply different, and sometimes somewhat nonsensical, implementations
of some compromise-happy standards like POSIX.
> And there were quite a few occasions where I found bugs by trying to run
> on a different platform, which was less forgiving than Linux. These are
> bugs you have a harder time to spot on Linux, _because_ Linux is so nice.
> But they will surface. And they will be a PITA to find.
And how many bugs or "features" of the platform did you have to code
around before finding a genuine bug?
> Anyway, it is best practice for a reason to program portably. (Well, at
> least if you are not living in Redmont.)
If "programming portably" meant catering to the oldest standards, then
you shouldn't even use prototypes or ansi-style function declarations.
After all, some people may be stuck with the old sun (or was it hp?)
compiler that was k&r only. And limit the filenames to 14 characters.
Also, you shouldn't require gtk, python, perl, fire or the wheel.
OG.
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Olivier Galibert @ 2006-07-10 23:51 UTC (permalink / raw)
To: git
In-Reply-To: <f36b08ee0607101625y6eaec83ck22dd20b4f27a1846@mail.gmail.com>
On Tue, Jul 11, 2006 at 02:25:44AM +0300, Yakov Lerner wrote:
> I am writing in order to ask, whether there maybe
> some c99-to-c89 source convertor that can be
> automatically applied to the .c before compiling with
> pre-c99 compiler ?
Comments are easy. Moving declarations without breaking initializers
is harder. Rewriting the struct initializers is pretty much
impossible without the tool turning into a full-blown C parser.
Maybe git can be perfectly happy with c89. I don't know. I know the
linux kernel requires c99, mostly for the struct initializers. My
point was that staying at the c89 level has a maintainance cost, and a
cost/benefit analysis should be done to decide whether it is a good
idea. Answering "get a C compiler", as is being done for some years
now for people not wanting prototypes, is an option not to neglect.
OG.
^ permalink raw reply
* Re: [PATCH] fix git-repack for use with GIT_TRACE
From: Junio C Hamano @ 2006-07-11 0:11 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1FzvZG-0002C1-UN@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Ok, this patch should fix this. Instead of "echo abort" another more
> meaningful message could be used.
"git-rev-list died with exit code $?" perhaps.
> I checked the other scripts which
> redirect stderr and they should be fine. In the tests I found
> t/t1200-tutorial.sh:38
> t/t1300-repo-config.sh:276
> t/t5500-fetch-pack.sh:66
> redirecting stderr, which probably fail which GIT_TRACE.
Probably t/test-lib.sh should unset GIT_TRACE then like it does
for other environment variables.
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Shawn Pearce @ 2006-07-11 0:15 UTC (permalink / raw)
To: Olivier Galibert; +Cc: git
In-Reply-To: <20060710235122.GB26528@dspnet.fr.eu.org>
Olivier Galibert <galibert@pobox.com> wrote:
> On Tue, Jul 11, 2006 at 02:25:44AM +0300, Yakov Lerner wrote:
> > I am writing in order to ask, whether there maybe
> > some c99-to-c89 source convertor that can be
> > automatically applied to the .c before compiling with
> > pre-c99 compiler ?
>
> Comments are easy. Moving declarations without breaking initializers
> is harder. Rewriting the struct initializers is pretty much
> impossible without the tool turning into a full-blown C parser.
>
> Maybe git can be perfectly happy with c89. I don't know. I know the
> linux kernel requires c99, mostly for the struct initializers. My
> point was that staying at the c89 level has a maintainance cost, and a
> cost/benefit analysis should be done to decide whether it is a good
> idea. Answering "get a C compiler", as is being done for some years
> now for people not wanting prototypes, is an option not to neglect.
GIT 1.2.3 had a lot more struct initializers than GIT 1.4.1 has. So
apparently it was cleaner to remove a few of them in some cases then
it was to keep them in. But that's besides the point.
I can understand the core maintainers not wanting to apply my patch
and lose the benefits of c99, and if I have to I'll carry a private
branch with that patch and hand-edit future versions as necessary
to get the same result... but I'd hate to see another user have
to do the same work for the same reason.
I'm not a big contributor to GIT (I certainly don't contribute
nearly as much code as most others) and I'm also not a big user of
GIT (I don't develop for the Linux kernel) so I not expecting the
core to drop to c89 just for me and this old compiler. :-)
After reading this thread I'm thinking that this probably shouldn't
get merged in and that I should carry the tweaks locally to get
GIT to build on the only compiler I have available on that system.
Now that GIT 1.4.1 is installed on there I'm unlikely to upgrade it
for at least 6 months, as I'm using only the very low level plumbing
(git-read-tree, git-write-tree, git-update-index, git-repack).
Remerging these c99 downgrades at that time shouldn't be a huge
issue for me since its probably going to be done so infrequently.
--
Shawn.
^ permalink raw reply
* Re: Items not covered by repository-layout.txt
From: Junio C Hamano @ 2006-07-11 0:23 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <e8uhjg$5o1$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Could you then tell me what is the format of FETCH_HEAD and what other *_HEADs
> can be seen in $GIT_DIR (MERGE_HEAD?)?
Which essentially is that you are telling me to do that, but I
am a bit busy this week.
If you can use the source to figure them out, that would be
great; otherwise this can wait or others can chime in.
For FETCH_HEAD fmt-merge-msg and git-pull would be helpful.
The general format is, one entry per line:
object name <TAB> merge-marker <TAB> notes
where merge-marker is either empty (for commits to be merged by
git-pull that called git-fetch) or not-for-merge, and notes is a
human readable comment that describes where that object came
from. Note that this is read both by humans _AND_ machine;
fmt-merge-msg relies on how it is stated.
Others "git grep -e _HEAD -- '*.sh'" perhaps.
ORIG_HEAD - used to keep the value of HEAD before we do
anything we might regret
MERGE_HEAD - one or more commit object names that are
being merged into the current branch during
a merge.
MERGE_MSG - generated message for an automerge.
^ permalink raw reply
* Re: git-update-ref (reflog) uses bogus author ident information
From: Shawn Pearce @ 2006-07-11 0:27 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: git
In-Reply-To: <e8uele$o7t$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> git-log reports
>
> commit 059111c9381ce1444d17c8fc35606b0aa417ca42
> Author: Jakub Narebski <jnareb@gmail.com>
> Date: Sat Jul 8 18:52:35 2006 +0200
>
> configure.ac vertical whitespace usage cleanup
>
> git-var -l shows:
>
> GIT_COMMITTER_IDENT=Jakub Narebski <jnareb@gmail.com> 1152564452 +0200
> GIT_AUTHOR_IDENT=Jakub Narebski <jnareb@gmail.com> 1152564452 +0200
>
> BUT in git/.git/logs/refs/heads/autoconf I have (broken into lines):
> fe7b45a419ae62ed96148d98f6aba8710a6f6245
> 059111c9381ce1444d17c8fc35606b0aa417ca42
> Jakub Narebski <jnareb@roke.D-201> 1152377555 +0200
> commit: configure.ac vertical whitespace usage cleanu
>
> where "roke.D-201" are results of "hostname -f" on my computer, and are
> suitable _only_ for my small private local network.
>
> Bug or a feature?
This is definately a bug. The reflog uses the same ident code
that commit-tree uses, with the idea that GIT_COMMITTER_IDENT would
drive the entry in the reflog, as you expected it to.
Looking in refs.c at log_ref_write its invoking setup_ident()
then git_committer_info(1). git_committer_info should be using
the environment variables (GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL,
GIT_COMMITTER_DATE) with defaults back to the gecos values. Based
on that it would seem that the user data in .git/config is being
ignored... Hm.
So you must be expecting .git/config to be supplying your data but
its getting overrwritten by setup_ident() in log_ref_write.
Here's the bug fix. Sorry about that one. That bug has been in
there since the reflog code was first put into GIT. :-)
-->--
Allow user.name and user.email to drive reflog entry.
Apparently calling setup_ident() after git_config causes the
user.name and user.email values read from the config file to be
replaced with the data obtained from the host. This means that
users who have setup their email address in user.email will instead
be writing reflog entries with their hostname.
Moving setup_ident() to before git_config in update-ref resolves
this ordering problem.
---
builtin-update-ref.c | 1 +
refs.c | 1 -
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-update-ref.c b/builtin-update-ref.c
index 00333c7..83094ab 100644
--- a/builtin-update-ref.c
+++ b/builtin-update-ref.c
@@ -12,6 +12,7 @@ int cmd_update_ref(int argc, const char
unsigned char sha1[20], oldsha1[20];
int i;
+ setup_ident();
setup_git_directory();
git_config(git_default_config);
diff --git a/refs.c b/refs.c
index 2d9c1dc..56db394 100644
--- a/refs.c
+++ b/refs.c
@@ -379,7 +379,6 @@ static int log_ref_write(struct ref_lock
lock->log_file, strerror(errno));
}
- setup_ident();
committer = git_committer_info(1);
if (msg) {
maxlen = strlen(committer) + strlen(msg) + 2*40 + 5;
--
1.4.1.gc48f
^ permalink raw reply related
* Re: git-update-ref (reflog) uses bogus author ident information
From: Shawn Pearce @ 2006-07-11 0:32 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: git
In-Reply-To: <20060711002754.GB10700@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Allow user.name and user.email to drive reflog entry.
>
> Apparently calling setup_ident() after git_config causes the
> user.name and user.email values read from the config file to be
> replaced with the data obtained from the host. This means that
> users who have setup their email address in user.email will instead
> be writing reflog entries with their hostname.
>
> Moving setup_ident() to before git_config in update-ref resolves
> this ordering problem.
Whoops, I forgot this line: :-)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> builtin-update-ref.c | 1 +
> refs.c | 1 -
> 2 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-update-ref.c b/builtin-update-ref.c
> index 00333c7..83094ab 100644
> --- a/builtin-update-ref.c
> +++ b/builtin-update-ref.c
> @@ -12,6 +12,7 @@ int cmd_update_ref(int argc, const char
> unsigned char sha1[20], oldsha1[20];
> int i;
>
> + setup_ident();
> setup_git_directory();
> git_config(git_default_config);
>
> diff --git a/refs.c b/refs.c
> index 2d9c1dc..56db394 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -379,7 +379,6 @@ static int log_ref_write(struct ref_lock
> lock->log_file, strerror(errno));
> }
>
> - setup_ident();
> committer = git_committer_info(1);
> if (msg) {
> maxlen = strlen(committer) + strlen(msg) + 2*40 + 5;
> --
> 1.4.1.gc48f
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Junio C Hamano @ 2006-07-11 0:34 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060711001504.GA10700@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Olivier Galibert <galibert@pobox.com> wrote:
>>
>> Maybe git can be perfectly happy with c89. I don't know. I know the
>> linux kernel requires c99, mostly for the struct initializers. My
>> point was that staying at the c89 level has a maintainance cost, and a
>> cost/benefit analysis should be done to decide whether it is a good
>> idea.
I am generally in favor of the effect C99 struct and array
initializers have on the readability, but we also need to
balance that with the reality. The patch is only about a few
structs and one array if I recall correctly isn't it?
What Olivier says is perfectly correct, and after "cost/benefit
analysis", I would have to say avoiding some C99 is fine if that
makes people's life on some major non-Linux platforms easier.
C99 clean-up is already in the "master", so please do not waste
more bandwidth nor time on this issue, but instead spend time
elsewhere to make our system better for more people ;-).
Thanks.
^ permalink raw reply
* [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Petr Baudis @ 2006-07-11 0:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060710130046.GW29115@pasky.or.cz>
We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
(Unfortunately, Scalar::Util is not bundled with older Perl versions.)
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
perl/private-Error.pm | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/perl/private-Error.pm b/perl/private-Error.pm
index ebd0749..848e82b 100644
--- a/perl/private-Error.pm
+++ b/perl/private-Error.pm
@@ -43,8 +43,6 @@ sub throw_Error_Simple
# Exported subs are defined in Error::subs
-use Scalar::Util ();
-
sub import {
shift;
local $Exporter::ExportLevel = $Exporter::ExportLevel + 1;
@@ -290,6 +288,20 @@ use vars qw(@EXPORT_OK @ISA %EXPORT_TAGS
@ISA = qw(Exporter);
+
+# Stolen from Scalar::Util:
+
+# Hope nobody defines a sub by this name
+sub UNIVERSAL::a_sub_not_likely_to_be_here { ref($_[0]) }
+
+sub blessed ($) {
+ local($@, $SIG{__DIE__}, $SIG{__WARN__});
+ length(ref($_[0]))
+ ? eval { $_[0]->a_sub_not_likely_to_be_here }
+ : undef
+}
+
+
sub run_clauses ($$$\@) {
my($clauses,$err,$wantarray,$result) = @_;
my $code = undef;
@@ -312,7 +324,7 @@ sub run_clauses ($$$\@) {
$i -= 2;
next CATCHLOOP;
}
- elsif(Scalar::Util::blessed($err) && $err->isa($pkg)) {
+ elsif(blessed($err) && $err->isa($pkg)) {
$code = $catch->[$i+1];
while(1) {
my $more = 0;
@@ -421,7 +433,7 @@ sub try (&;$) {
if (defined($err))
{
- if (Scalar::Util::blessed($err) && $err->can('throw'))
+ if (blessed($err) && $err->can('throw'))
{
throw $err;
}
^ permalink raw reply related
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Randal L. Schwartz @ 2006-07-11 1:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060711005354.5911.62525.stgit@machine.or.cz>
>>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
Petr> We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
Petr> (Unfortunately, Scalar::Util is not bundled with older Perl versions.)
Wow. That's sure the long way around for what I would use this for:
sub blessed {
my $item = shift;
local $@; # don't kill an outer $@
ref $item and eval { $item->can('can') };
}
We call it "doing the can-can". :)
And this solution has the advantage that it doesn't pollute UNIVERSAL.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Randal L. Schwartz @ 2006-07-11 1:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <86bqrwncnq.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> sub blessed {
Randal> my $item = shift;
Randal> local $@; # don't kill an outer $@
Randal> ref $item and eval { $item->can('can') };
Randal> }
Oops, lose the local $@ line. Just found out this is a broken
thing in current Perls. The rest is good though.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Randal L. Schwartz @ 2006-07-11 1:42 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <867j2knckf.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> sub blessed {
Randal> my $item = shift;
Randal> local $@; # don't kill an outer $@
Randal> ref $item and eval { $item->can('can') };
Randal> }
Randal> Oops, lose the local $@ line. Just found out this is a broken
Randal> thing in current Perls. The rest is good though.
And thirdly, ignore what I *just* said, and concentrate on what I *previously*
said, becaused my testing was off.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Junio C Hamano @ 2006-07-11 1:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060711005354.5911.62525.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
> (Unfortunately, Scalar::Util is not bundled with older Perl versions.)
Eh, but aren't we going to rip out the try{}catch{} stuff to
avoid extra closures?
^ permalink raw reply
* Re: reflog doesn't note that commit was --amend-ed, and doesn't record pulls
From: Shawn Pearce @ 2006-07-11 2:48 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: git
In-Reply-To: <e8uhvg$5o1$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Additionally, while reflog records git-reset invocations, it doesn't
> distinguish between an ordinary commit, and commit --amend (which I do
> a lot, most time because of forgotten update-index; yes, I know about commit
> -a option ;-). Well, you can extract this information looking at current
> and previous commit sha1, but it would be nice to have it noted somewhat in
> message part of reflog.
I'm attaching a patch below which fixes this. It denotes the 4
major types of commits: initial, normal, amend, merge.
> Reflog doesn't seem also to record pulls (e.g. master branch): pulls has
> empty reflog message part.
Yea, that's a 'TODO' item. Now that someone is complaining about
it I'll see if I can't get a fix done later tonight for it.
Its probably going to be a few patches: one for git-merge and
another for receive-pack.c.
-->--
Record the type of commit operation in the reflog.
If committing a merge (.git/MERGE_HEAD exists), an initial tree
(no HEAD) or using --amend to amend the prior commit then denote
the subtype of commit in the reflog. This helps to distinguish
amended or merge commits from normal commits.
In the case of --amend the prior sha1 is probably the commit which
is being thrown away in favor of the new commit. Since it is likely
that the old commit doesn't have any ref pointing to it anymore
it can be interesting to know why that the commit was replaced
and orphaned.
In the case of a merge the prior sha1 is probably the first parent
of the new merge commit. Consequently having its prior sha1 in the
reflog is slightly less interesting but its still informative to
know the commit was the result of a merge which had to be completed
by hand.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-commit.sh | 6 +++++-
t/t1400-update-ref.sh | 19 ++++++++++++++++---
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 22c4ce8..05eccfe 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -635,9 +635,12 @@ fi
PARENTS="-p HEAD"
if test -z "$initial_commit"
then
+ rloga='commit'
if [ -f "$GIT_DIR/MERGE_HEAD" ]; then
+ rloga='commit (merge)'
PARENTS="-p HEAD "`sed -e 's/^/-p /' "$GIT_DIR/MERGE_HEAD"`
elif test -n "$amend"; then
+ rloga='commit (amend)'
PARENTS=$(git-cat-file commit HEAD |
sed -n -e '/^$/q' -e 's/^parent /-p /p')
fi
@@ -649,6 +652,7 @@ else
fi
PARENTS=""
current=
+ rloga='commit (initial)'
fi
if test -z "$no_edit"
@@ -724,7 +728,7 @@ then
fi &&
commit=$(cat "$GIT_DIR"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&
rlogm=$(sed -e 1q "$GIT_DIR"/COMMIT_MSG) &&
- git-update-ref -m "commit: $rlogm" HEAD $commit $current &&
+ git-update-ref -m "$rloga: $rlogm" HEAD $commit $current &&
rm -f -- "$GIT_DIR/MERGE_HEAD" &&
if test -f "$NEXT_INDEX"
then
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index df3e993..6a3515d 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -188,17 +188,30 @@ test_expect_success \
echo OTHER >F &&
GIT_AUTHOR_DATE="2005-05-26 23:41" \
GIT_COMMITTER_DATE="2005-05-26 23:41" git-commit -F M -a &&
- h_OTHER=$(git-rev-parse --verify HEAD)
+ h_OTHER=$(git-rev-parse --verify HEAD) &&
+ echo FIXED >F &&
+ EDITOR=true \
+ GIT_AUTHOR_DATE="2005-05-26 23:44" \
+ GIT_COMMITTER_DATE="2005-05-26 23:44" git-commit --amend &&
+ h_FIXED=$(git-rev-parse --verify HEAD) &&
+ echo TEST+FIXED >F &&
+ echo Merged initial commit and a later commit. >M &&
+ echo $h_TEST >.git/MERGE_HEAD &&
+ GIT_AUTHOR_DATE="2005-05-26 23:45" \
+ GIT_COMMITTER_DATE="2005-05-26 23:45" git-commit -F M &&
+ h_MERGED=$(git-rev-parse --verify HEAD)
rm -f M'
cat >expect <<EOF
-$Z $h_TEST $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150200 +0000 commit: add
+$Z $h_TEST $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150200 +0000 commit (initial): add
$h_TEST $h_OTHER $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150860 +0000 commit: The other day this did not work.
+$h_OTHER $h_FIXED $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117151040 +0000 commit (amend): The other day this did not work.
+$h_FIXED $h_MERGED $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117151100 +0000 commit (merge): Merged initial commit and a later commit.
EOF
test_expect_success \
'git-commit logged updates' \
'diff expect .git/logs/$m'
-unset h_TEST h_OTHER
+unset h_TEST h_OTHER h_FIXED h_MERGED
test_expect_success \
'git-cat-file blob master:F (expect OTHER)' \
--
1.4.1.gc48f
^ permalink raw reply related
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Randal L. Schwartz @ 2006-07-11 3:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7v4pxo7vk4.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> Petr Baudis <pasky@suse.cz> writes:
>> We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
>> (Unfortunately, Scalar::Util is not bundled with older Perl versions.)
Junio> Eh, but aren't we going to rip out the try{}catch{} stuff to
Junio> avoid extra closures?
Heh. Yeah, didn't notice that. I keep cutting down the trees,
but the forest remains. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: reflog doesn't note that commit was --amend-ed, and doesn't record pulls
From: Shawn Pearce @ 2006-07-11 3:38 UTC (permalink / raw)
To: Junio C Hamano, Jakub Narebski; +Cc: git
In-Reply-To: <e8uhvg$5o1$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Reflog doesn't seem also to record pulls (e.g. master branch): pulls has
> empty reflog message part.
Fixed with the patch below. git-merge doesn't record the merges yet,
so some changes made by git-pull still aren't logged as nicely as
one would like. But don't fear, that will be coming soon. :-)
-->--
Log ref changes made by git-fetch and git-pull.
When git-fetch updates a reference record in the associated reflog
what type of update took place and who caused it (git-fetch or
git-pull, by invoking git-fetch).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-fetch.sh | 20 +++++++++++++++-----
git-pull.sh | 2 +-
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index 48818f8..5e4c4d6 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -11,6 +11,7 @@ LF='
'
IFS="$LF"
+rloga=fetch
no_tags=
tags=
append=
@@ -51,6 +52,9 @@ do
-k|--k|--ke|--kee|--keep)
keep=--keep
;;
+ --reflog-action=*)
+ rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`
+ ;;
-*)
usage
;;
@@ -75,6 +79,9 @@ refs=
rref=
rsync_slurped_objects=
+rloga="$rloga $remote_nick"
+test "$remote_nick" == "$remote" || rloga="$rloga $remote"
+
if test "" = "$append"
then
: >"$GIT_DIR/FETCH_HEAD"
@@ -149,11 +156,12 @@ fast_forward_local () {
[ "$verbose" ] && echo >&2 "* $1: same as $3"
else
echo >&2 "* $1: updating with $3"
+ git-update-ref -m "$rloga: updating tag" "$1" "$2"
fi
else
echo >&2 "* $1: storing $3"
+ git-update-ref -m "$rloga: storing tag" "$1" "$2"
fi
- git-update-ref "$1" "$2"
;;
refs/heads/* | refs/remotes/*)
@@ -174,7 +182,7 @@ fast_forward_local () {
*,$local)
echo >&2 "* $1: fast forward to $3"
echo >&2 " from $local to $2"
- git-update-ref "$1" "$2" "$local"
+ git-update-ref -m "$rloga: fast-forward" "$1" "$2" "$local"
;;
*)
false
@@ -184,7 +192,7 @@ fast_forward_local () {
case ",$force,$single_force," in
*,t,*)
echo >&2 " forcing update."
- git-update-ref "$1" "$2" "$local"
+ git-update-ref -m "$rloga: forced-update" "$1" "$2" "$local"
;;
*)
echo >&2 " not updating."
@@ -194,7 +202,7 @@ fast_forward_local () {
}
else
echo >&2 "* $1: storing $3"
- git-update-ref "$1" "$2"
+ git-update-ref -m "$rloga: storing head" "$1" "$2"
fi
;;
esac
@@ -422,7 +430,9 @@ case ",$update_head_ok,$orig_head," in
curr_head=$(git-rev-parse --verify HEAD 2>/dev/null)
if test "$curr_head" != "$orig_head"
then
- git-update-ref HEAD "$orig_head"
+ git-update-ref \
+ -m "$rloga: Undoing incorrectly fetched HEAD." \
+ HEAD "$orig_head"
die "Cannot fetch into the current branch."
fi
;;
diff --git a/git-pull.sh b/git-pull.sh
index 076785c..d337bf4 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -45,7 +45,7 @@ do
done
orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
-git-fetch --update-head-ok "$@" || exit 1
+git-fetch --update-head-ok --reflog-action=pull "$@" || exit 1
curr_head=$(git-rev-parse --verify HEAD)
if test "$curr_head" != "$orig_head"
--
1.4.1.gc48f
^ permalink raw reply related
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