* Re: git-log to go forward instead of reverse?
From: Linus Torvalds @ 2006-07-10 19:26 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607101212410.5623@g5.osdl.org>
On Mon, 10 Jul 2006, Linus Torvalds wrote:
>
> The difference between getting the first screenful in 0.054 seconds versus
> it taking 2.218 seconds is quite noticeable, and one of the things I've
> actually spent a fair amount of time on is to make sure that the
> incremental output case is the _common_ one for all the normal operations
> like "git log -p".
Side note: the good news is that even with the reverse generation, if you
also generate _diffs_, the diffs will be generated incrementally, so:
// Full "git log" with diffs
[torvalds@g5 linux]$ time git log -p drivers/serial > /dev/null
real 0m3.409s
user 0m3.360s
sys 0m0.052s
// First screenful of reverse git log with diffs
[torvalds@g5 linux]$ time git log -p --reverse drivers/serial | head -25 > /dev/null
real 0m2.228s
user 0m2.216s
sys 0m0.012s
// First screenful of regular git log with diffs
[torvalds@g5 linux]$ time git log -p drivers/serial | head -25 > /dev/null
real 0m0.038s
user 0m0.036s
sys 0m0.004s
here you can see how the full "git log -p" is obviously more expensive
than the full "git log" was (the diff generation adds about a second to
the full time), but because the diffs are generated incrementally as they
are shown even with "--reverse", the first screenful of the "--reverse"
case didn't get any more expensive, because we didn't generate all the
diffs up-front, just the ones we needed.
And the first screenfull of the normal case obviously stays really fast,
because both history generation _and_ diff generation is all on-the-fly.
Linus
^ permalink raw reply
* [PATCH] Allow usage of git-svnimport's -d/-D options with https
From: Diego 'Flameeyes' Pettenò @ 2006-07-10 19:34 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 384 bytes --]
While importing an SVN https repository (from SourceForge), I noticed that the
svnimport script just accepts http as url scheme to use -d/-D options, while
it seems to work fine with https too. The attached patch fixes that for me.
HTH,
--
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
[-- Attachment #1.2: git-svnimport-https.patch --]
[-- Type: text/x-diff, Size: 426 bytes --]
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 26dc454..9a69369 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -209,7 +209,7 @@ if($opt_d or $opt_D) {
} else {
$svn_dir = "";
}
- if ($svn_url->scheme eq "http") {
+ if ($svn_url->scheme eq "http" or $svn_url->scheme eq "https") {
use LWP::UserAgent;
$lwp_ua = LWP::UserAgent->new(keep_alive => 1, requests_redirectable => []);
} else {
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: git-log to go forward instead of reverse?
From: Linus Torvalds @ 2006-07-10 20:09 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86mzbhntxu.fsf@blue.stonehenge.com>
On Mon, 10 Jul 2006, Randal L. Schwartz wrote:
>
> then git-log --pretty=short ORIG_HEAD..HEAD | cat
> The log is just so I can quickly eyeball the interesting changes. The "cat"
> is to keep git-log from starting a pager. (If there's a switch that does
> *that* that I've overlooked, that'd be good too.)
Just do
PAGER= git log --pretty=short ORIG_HEAD..HEAD
instead.
And if you didn't know about "git shortlog" already, I personally actually
find it easier to read
git log --no-merges ORIG_HEAD.. | git shortlog
which orders things by author instead. It also reverses the log messages
as it does so, so each author will have the one-liners sorted oldest to
newest the way you wanted to (so you do _not_ want to pass --reverse to
that git-shortlog invocation).
Linus
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Randal L. Schwartz @ 2006-07-10 20:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607101304210.5623@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
Linus> And if you didn't know about "git shortlog" already, I personally actually
Linus> find it easier to read
Linus> git log --no-merges ORIG_HEAD.. | git shortlog
Linus> which orders things by author instead. It also reverses the log
Linus> messages as it does so, so each author will have the one-liners sorted
Linus> oldest to newest the way you wanted to (so you do _not_ want to pass
Linus> --reverse to that git-shortlog invocation).
See -- I *knew* there was a shorter way.
Looks like I owe you lunch. (Again? :)
--
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] Avoid C++ comments, use C comments instead
From: Olivier Galibert @ 2006-07-10 20:24 UTC (permalink / raw)
To: Paul Serice; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <44B2A709.8020500@serice.net>
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.
OG.
^ permalink raw reply
* Re: [PATCH] git-format-patch: Make the second and subsequent mails replies to the first
From: Jakub Narebski @ 2006-07-10 20:25 UTC (permalink / raw)
To: git
In-Reply-To: <1152549787.8890.36.camel@josh-work.beaverton.ibm.com>
Josh Triplett wrote:
> On Mon, 2006-07-10 at 18:29 +0200, Erik Mouw wrote:
>> On Mon, Jul 10, 2006 at 06:01:48PM +0200, Johannes Schindelin wrote:
>> > please make that behaviour optional.
>>
>> Rather make it consistent with git-send-email. Principle of least
>> surprise.
>
> Well, git-send-email does not include an option to disable the threading
> headers, so consistency with git-send-email would imply not including
> any such option. I can, however, implement a --no-thread option to omit
> the headers, as well as git-send-email's --in-reply-to option to set an
> initial In-Reply-To/References. New patch series shortly.
git-send-email has three ways of sending files:
1. Chain Reply-To:, where every patch refers to earlier in series.
Ugly in threaded mail/news readers, harder to comment, but there is
no way to loose the order (e.g. if patches are not numbered *blush*)
2. No chain reply-to, with cover letter introducing patch series.
IMHO nicest format... provided there are no errors nor mistakes.
3. No chain reply-to, without cover letter. I presonally don't like
this format, YMMV.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Junio C Hamano @ 2006-07-10 20:26 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86mzbhntxu.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Well, this is for a "I'm connected to the net right now: please
> refresh all of my git mirrors" script:
>
> ## (code here to cd to the right dir omitted)
> git-fetch
> if git-status | grep -v 'nothing to commit'
git-status exits non-zero for "nothing to commit" case, so do
not grep its output, but check the status of the command, to see
if your tree is in a good shape to do a pull.
> then echo UPDATE SKIPPED
> else
> if git-pull . origin | egrep -v 'up-to-date'
> then git-log --pretty=short ORIG_HEAD..HEAD | cat
> fi
> fi
>
> The log is just so I can quickly eyeball the interesting changes.
Do we not leave ORIG_HEAD when we are already up-to-date? If so
that would be confusing... No, we do leave ORIG_HEAD no matter
what, so you do not have to have this inner if to grep
up-to-date (on the other hand, you might want to do intelligent
things when git-pull fails). So just drop the if and say
something like:
else
PAGER= ; export PAGER
git pull . origin &&
git log --pretty ORIG_HEAD..HEAD |
git shortlog
fi
> The "cat"
> is to keep git-log from starting a pager. (If there's a switch that does
> *that* that I've overlooked, that'd be good too.)
BTW,
PAGER=cat
export PAGER
This should work as more efficiently -- see pager.c ;-)
^ permalink raw reply
* Re: 2 questions on git-send-email usage
From: Jakub Narebski @ 2006-07-10 20:29 UTC (permalink / raw)
To: git
In-Reply-To: <20060710190010.94648.qmail@web25808.mail.ukl.yahoo.com>
moreau francis wrote:
> I'm wondering what am I supposed to answer when git-send-email
> is asking me :
>
> Message-ID to be used as In-Reply-To for the first email?
>
> I'm running this command:
>
> $ git-send-email --no-signed-off-by-cc --no-chain-reply-to --to \
> foo@bar.com --compose /tmp/patch/
>
> to write an introductory message, and all patches are sent as replies to
> this introductory email sent.
Empty string (i.e. RET) should do if you don't want to attach your series of
patches somewhere in existing thread.
> I also noticed that git-send-email removes the commit message of each
> patches I sent, I don't think this is the normal behaviour though. What
> am I missing ?
Are patches formatted using git-format-patch?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Randal L. Schwartz @ 2006-07-10 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsgdb40s.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>> ## (code here to cd to the right dir omitted)
>> git-fetch
>> if git-status | grep -v 'nothing to commit'
Junio> git-status exits non-zero for "nothing to commit" case, so do
Junio> not grep its output, but check the status of the command, to see
Junio> if your tree is in a good shape to do a pull.
No, this is deliberate. I want to see nothing if we're up to date, but if
not, I want to see *everything else* that git-status said. This nice "grep
-v" does precisely the right thing.
Junio> Do we not leave ORIG_HEAD when we are already up-to-date? If so
Junio> that would be confusing... No, we do leave ORIG_HEAD no matter
Junio> what, so you do not have to have this inner if to grep
Junio> up-to-date (on the other hand, you might want to do intelligent
Junio> things when git-pull fails). So just drop the if and say
Junio> something like:
Junio> else
Junio> PAGER= ; export PAGER
Junio> git pull . origin &&
Junio> git log --pretty ORIG_HEAD..HEAD |
Junio> git shortlog
Junio> fi
However, this is good to know.
--
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
* Items not covered by repository-layout.txt
From: Jakub Narebski @ 2006-07-10 20:46 UTC (permalink / raw)
To: git
I have noticed few files in .git/ directory which currently are not covered
(and neither is their format) by Documentation/repository-layout.txt
* COMMIT_EDITMSG (temporary file, when I decided during writing commit
message that I should change something before commit)
* FETCH_HEAD (format?)
* HEAD, ORIG_HEAD and probably some other *_HEAD
* .tmp-vtag (I'm not sure what have left that, probably git-verify-tag
broken due to lack of signing PGP keys)
* description file
I know they are fairly obvious, but having everything that one could fing in
his/her git-core managed .git repository would be nice...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* git-update-ref (reflog) uses bogus author ident information
From: Jakub Narebski @ 2006-07-10 20:52 UTC (permalink / raw)
To: git
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?
I use git 1.4.0.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Fix linking for not-so-clever linkers.
From: Junio C Hamano @ 2006-07-10 21:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607101340080.29667@wbgn013.biozentrum.uni-wuerzburg.de>
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?
^ permalink raw reply
* Re: Items not covered by repository-layout.txt
From: Junio C Hamano @ 2006-07-10 21:29 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <e8ue98$o7t$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> I have noticed few files in .git/ directory which currently are not covered
> (and neither is their format) by Documentation/repository-layout.txt
>
> * COMMIT_EDITMSG (temporary file, when I decided during writing commit
> message that I should change something before commit)
> * FETCH_HEAD (format?)
> * HEAD, ORIG_HEAD and probably some other *_HEAD
> * .tmp-vtag (I'm not sure what have left that, probably git-verify-tag
> broken due to lack of signing PGP keys)
> * description file
>
> I know they are fairly obvious, but having everything that one could fing in
> his/her git-core managed .git repository would be nice...
Yup, please make it so.
^ permalink raw reply
* Re: [PATCH] Fix linking for not-so-clever linkers.
From: Linus Torvalds @ 2006-07-10 21:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v64i5b1am.fsf@assigned-by-dhcp.cox.net>
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", where that "s" should do
the equivalent of the old-fashioned "ranlib" call.
However, that said, I think Johannes' patch is worth applying regardless,
since it's kind of sad to link in pager.o just because of a variable that
ends up never mattering (ie any program that uses "diff.c" but isn't
built-in).
Of course, once/if everything is built-in, this doesn't matter, but in the
meantime this isn't the first time we've re-organized things so that you
don't have to link in files that you don't need. After all, that was the
whole reason environment.c ended up existing in the first place..
Linus
^ permalink raw reply
* Re: Items not covered by repository-layout.txt
From: Jakub Narebski @ 2006-07-10 21:42 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wstb12x.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> I have noticed few files in .git/ directory which currently are not covered
>> (and neither is their format) by Documentation/repository-layout.txt
>>
>> * COMMIT_EDITMSG (temporary file, when I decided during writing commit
>> message that I should change something before commit)
>> * FETCH_HEAD (format?)
>> * HEAD, ORIG_HEAD and probably some other *_HEAD
>> * .tmp-vtag (I'm not sure what have left that, probably git-verify-tag
>> broken due to lack of signing PGP keys)
>> * description file
>>
>> I know they are fairly obvious, but having everything that one could fing in
>> his/her git-core managed .git repository would be nice...
I have just noticed that _config_ file (!)is not covered by repository-layout.txt
> Yup, please make it so.
Could you then tell me what is the format of FETCH_HEAD and what other *_HEADs
can be seen in $GIT_DIR (MERGE_HEAD?)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/3] git-format-patch: Make the second and subsequent mails replies to the first
From: Junio C Hamano @ 2006-07-10 21:44 UTC (permalink / raw)
To: josht; +Cc: git
In-Reply-To: <1152556878.8890.45.camel@josh-work.beaverton.ibm.com>
Josh Triplett <josht@us.ibm.com> writes:
> Add message_id and ref_message_id fields to struct rev_info, used in show_log
> with CMIT_FMT_EMAIL to set Message-Id and In-Reply-To/References respectively.
> Use these in git-format-patch to make the second and subsequent patch mails
> replies to the first patch mail.
>
> Signed-off-by: Josh Triplett <josh@freedesktop.org>
> ---
> Resend of previous patch as part of new patch series.
While I understand what you said about imap-send, I really would
feel better if this was optional. Do not change the default
output format, please.
^ permalink raw reply
* Re: git-log to go forward instead of reverse?
From: Junio C Hamano @ 2006-07-10 21:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Randal L. Schwartz
In-Reply-To: <Pine.LNX.4.64.0607101304210.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> And if you didn't know about "git shortlog" already, I personally actually
> find it easier to read
>
> git log --no-merges ORIG_HEAD.. | git shortlog
>
> which orders things by author instead.
Yes, and you can even have '-p' between git and shortlog in the
latter command if you do want the pager ;-).
BTW, when I prepare the "What's in" messages, I often find it
more useful to have a brother of short-log command that does not
group by author but group by topic branch the commits came from.
Currently I prepare the categorized list by hand, reviewing each
commit in "master..next" shortlog output. While I do not mind
it too much since that is a good way to remind myself what are
still cooking, it would be nice to have to a command that takes:
- which branch the output is relative to (defaults
to "master");
- list of branches that are "topics";
- which branch the parts of topics have been merged to
(optional -- I'd use "next" for my use).
and for each topic:
- see if the topic branches off from another topic (for
example, the merge-tree topic branches off from the
xdiff-common topic like [*1*]); if so, state that and
use that branch point instead of "master" in the next
step;
- list commits that have not made "master" yet;
optionally, when "next" is given, limit the output
only to the ones that have made "next" already.
[Footnote]
*1*
$ git show-branch --topics master lt/xdiff-common lt/merge-tree
* [master] git-rev-list: add documentation for --parents, --no-merges
! [lt/xdiff-common] xdiff: generate "anti-diffs" aka what is common...
! [lt/merge-tree] Improved three-way blob merging code
---
+ [lt/merge-tree] Improved three-way blob merging code
+ [lt/merge-tree^] Prepare "git-merge-tree" for future work
++ [lt/xdiff-common] xdiff: generate "anti-diffs" aka what is common...
*++ [master~67] checkout -m: fix read-tree invocation
^ permalink raw reply
* 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
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