* Re: q: faster way to integrate/merge lots of topic branches?
From: Linus Torvalds @ 2008-07-23 18:12 UTC (permalink / raw)
To: Ingo Molnar; +Cc: SZEDER Gábor, Git Mailing List, Lars Hjemli
In-Reply-To: <alpine.LFD.1.10.0807231100310.4754@woody.linux-foundation.org>
On Wed, 23 Jul 2008, Linus Torvalds wrote:
>
> But I'll look if there's a way to cut it down from 9s. I suspect it has to
> traverse the whole history to make 100% sure that something isn't merged,
> but even that should be faster than 9s.
Heh. It should be trivially doable _much_ faster, but the has_commit()
logic really relies on re-doing the "in_merge_base()" thing over and over
again (clearing the bits), instead of just populating the object list with
a "already seen" bit and lettign that expand over time.
So using "git branch --no-merged" does avoid re-parsing the commits over
and over again (which is a pretty big win), but the way the code is
written it does end up traversing the commit list fully for every single
branch. That's quite horrible.
Lars added to Cc list in the hope that he'll be embarrassed enough about
the performance to try to fix it ;)
Linus
^ permalink raw reply
* Re: [PATCH 0/9] Make gitexecdir relative to $(bindir) on Windows
From: Junio C Hamano @ 2008-07-23 18:28 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git
In-Reply-To: <200807222131.32828.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Dienstag, 22. Juli 2008, Johannes Schindelin wrote:
>> Hi,
>>
>> On Mon, 21 Jul 2008, Johannes Sixt wrote:
>> > The problem was that argv[0] does not have a path in certain cases.
>>
>> Note that the same holds true for Linux when calling a program that is in
>> the PATH:
>
> Oh, boy!
>
>> I imagine that the proper solution would be to rip out lookup_prog() and
>> use it for non-Windows Git, too. Unless you want to limit the usefulness
>> of your patch series to Windows, that is.
>
> This certainly goes beyond what I am prepared to do. It is not my itch. The
> series is already much longer than I wanted, when there is a much simpler
> solution that solves *my* problem: to set bindir = $(gitexecdir).
If you are living in the Windows world, perhaps you could record the
installation location in resource somewhere from the installer and look it
up at runtime? Or is it considered a bad practice?
^ permalink raw reply
* Re: [PATCH 5/9] Allow the built-in exec path to be relative to the command invocation path
From: Junio C Hamano @ 2008-07-23 18:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <1216667998-8879-6-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> If $(gitexecdir) is relative, it is interpreted relative to the command's
> invocation path, which usually is $(bindir).
>
> The Makefile rules were written with the assumption that $(gitexecdir) is
> an absolute path. We introduce a separate variable that names the
> (absolute) installation directory.
> ...
> +ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
> +gitexec_instdir = $(bindir)/$(gitexecdir)
> +else
Can we please have a brief comment in the Makefile near we define mandir,
infodir, gitexecdir and friends about this "relative to $(bindir)"
business?
Perhaps like:
Makefile | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 23f2185..8fa8f9a 100644
--- a/Makefile
+++ b/Makefile
@@ -171,6 +171,12 @@ ALL_LDFLAGS = $(LDFLAGS)
STRIP ?= strip
prefix = $(HOME)
+
+# Among these variables, gitexecdir and/or template_dir can be
+# specified as a relative path ../some/where/else; this is interpreted
+# as relative to $(bindir) and "git" at runtime figures out where they
+# are based on the path to the executable. This can help installing the
+# suite in a relocatable way.
bindir = $(prefix)/bin
mandir = $(prefix)/share/man
infodir = $(prefix)/share/info
Note that I just listed two variables out of thin air without studying;
you might be making other variables capable of relative path, in which
case they should also be listed there.
^ permalink raw reply related
* Re: [PATCH/RFC] git add: do not add files from a submodule
From: Junio C Hamano @ 2008-07-23 18:31 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johannes Schindelin, git
In-Reply-To: <20080723081333.GA15243@artemis.madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> On Wed, Jul 23, 2008 at 06:40:20AM +0000, Junio C Hamano wrote:
> ...
>> If we started the process of diagnosing and fixing these issues earlier,
>> and had plausible code to address the issue already in 'next' before the
>> current -rc cycle started, the topic would have been an obvious candidate
>> for the coming release and I'd further say it would be even worth delaying
>> the release for a few weeks if it takes more time. But I have to say it
>> is too late for 1.6.0 now if we are just noticing and starting the
>> discussion.
>
> Well given that we now use submodules at work, and that git is
> nowadays somewhere in the top 5 of my most consciously (as opposed to
> the compiler that I rarely call by hand) used software suites (among my
> editor, my MUA, my shell and my tiling WM), I'm very much interested in
> tackling some things about what is (not) done with submodules yet.
Surely the effort is appreciated.
>> This comment goes to the issue Pierre raised last night as well.
>
> You mean the git checkout issue?
Oh, no; that misuse of parse_opt() that forgot KEEP_DASHDASH one was not
what I had in mind. I meant to say that your "switch branches between an
old pre-submodule rev and a new one that has a submodule at where a blob
or directory used to be" issue with a good explanation material was a good
starting point for submodule improvements for the next cycle.
I'd like the release schedule not too heavily based on "per feature", but
more time-based.
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Junio C Hamano @ 2008-07-23 18:31 UTC (permalink / raw)
To: Olivier Marin
Cc: Theodore Tso, Nanako Shiraishi, Johannes Schindelin,
René Scharfe, Stephan Beyer, Joe Fiorini, git, Jari Aalto
In-Reply-To: <488722F5.9030602@free.fr>
Olivier Marin <dkr+ml.git@free.fr> writes:
> Junio C Hamano a écrit :
>>> diff --git a/git-am.sh b/git-am.sh
>> ...
>>> @@ -202,8 +202,15 @@ then
>> ...
>>> + case "$skip,$abort" in
>>> + t,)
>>> + git rerere clear
>>> + git read-tree --reset -u HEAD HEAD
>>> + orig_head=$(cat "$GIT_DIR/ORIG_HEAD")
>>> + git reset HEAD
>>> + git update-ref ORIG_HEAD $orig_head
>>> + ;;
>> ...
> I add reset to unstage paths with no conflict that are left behind.
Does removing the last three lines (1) change the behaviour? (2) break any test?
If the answers are "Yes and No", we would need a few more tests in the
testsuite.
If the answers are "No and naturally no", then let's remove the last three
lines in the hunk.
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Avery Pennarun @ 2008-07-23 18:33 UTC (permalink / raw)
To: Joshua Jensen; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <488772BC.80207@workspacewhiz.com>
On 7/23/08, Joshua Jensen <jjensen@workspacewhiz.com> wrote:
> There are certain file formats, such as a Visual Studio .sln file, that
> MUST be CRLF. [...]
It seems like what people really want is some additional file attributes:
1. always CRLF on all platforms (eg. for .bat files)
2. always LF on all platforms (eg. for shell scripts and perl scripts)
3. just leave it alone no matter what (eg. for binary files)
4. convert line endings to LF on checkin, native on checkout (eg. for
most source files)
Where "native" is defined by some config option, but the choice of #1
through #4 is defined by .gitattributes. Thus, the config option
affects only mode #4 (and perhaps the default mode, as it does now).
The current system works for #3. With Dscho's patch, #4 works too. I
think more kinds of per-file attributes are needed in order to get #1
and #2.
Avery
^ permalink raw reply
* Re: [PATCH] Add help.autocorrect to enable/disable autocorrecting
From: Alex Riesen @ 2008-07-23 18:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807231743030.8986@racer>
Johannes Schindelin, Wed, Jul 23, 2008 18:44:49 +0200:
> > + n = 1;
> > + while (n < main_cmds.cnt &&
> > + best_similarity == similarity(main_cmds.names[n]->name))
> > + ++n;
>
> Mini-nit: you never ask for the value of n, only if it is 1 or larger. So
> you do not need to count...
But I do, don't I? AFAICS, I use 0, 1 and >1 (this-these).
^ permalink raw reply
* Re: [PATCH] Wait help.autocorrect deciseconds before running corrected command
From: Alex Riesen @ 2008-07-23 18:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807231756380.8986@racer>
Johannes Schindelin, Wed, Jul 23, 2008 18:57:05 +0200:
> On Wed, 23 Jul 2008, Alex Riesen wrote:
>
> > + if (autocorrect > 0) {
> > + fprintf(stderr, "in %0.1f seconds automatically...\n",
> > + (float)autocorrect/10.0);
> > + poll(NULL, 0, autocorrect * 100);
> > + }
>
> What? No countdown? No fancy sounds when the time ran up?
>
Hate them fancies... :)
^ permalink raw reply
* Re: [PATCH 0/9] Make gitexecdir relative to $(bindir) on Windows
From: Johannes Sixt @ 2008-07-23 18:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vmyk8e9p9.fsf@gitster.siamese.dyndns.org>
On Mittwoch, 23. Juli 2008, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
> > On Dienstag, 22. Juli 2008, Johannes Schindelin wrote:
> >> On Mon, 21 Jul 2008, Johannes Sixt wrote:
> >> > The problem was that argv[0] does not have a path in certain cases.
> >>
> >> Note that the same holds true for Linux when calling a program that is
> >> in the PATH:
> >
> > Oh, boy!
> >
> >> I imagine that the proper solution would be to rip out lookup_prog() and
> >> use it for non-Windows Git, too. Unless you want to limit the
> >> usefulness of your patch series to Windows, that is.
> >
> > This certainly goes beyond what I am prepared to do. It is not my itch.
> > The series is already much longer than I wanted, when there is a much
> > simpler solution that solves *my* problem: to set bindir = $(gitexecdir).
>
> If you are living in the Windows world, perhaps you could record the
> installation location in resource somewhere from the installer and look it
> up at runtime? Or is it considered a bad practice?
Well, looking at value of _pgmptr *is* "look it up at runtime"; no resources
or help from the installer are needed.
My rant here is more about that I created a *long* patch series only to find
out that it does not have enough genericity to solve the same problem
(relocatability) on platforms other than Windows - and I don't want to make
it even longer. Windows is special enough that *I* could live with a much
simpler solution even though it is a bit retro.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-23 18:57 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Joshua Jensen, Junio C Hamano, git
In-Reply-To: <32541b130807231133x37083278u1badd82b5c48e57b@mail.gmail.com>
Hi,
On Wed, 23 Jul 2008, Avery Pennarun wrote:
> 1. always CRLF on all platforms (eg. for .bat files)
> 2. always LF on all platforms (eg. for shell scripts and perl scripts)
> 3. just leave it alone no matter what (eg. for binary files)
These are not different, but equal. "Do no harm to the contents of this
file".
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Add help.autocorrect to enable/disable autocorrecting
From: Johannes Schindelin @ 2008-07-23 19:00 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080723184443.GD5283@blimp.local>
Hi,
On Wed, 23 Jul 2008, Alex Riesen wrote:
> Johannes Schindelin, Wed, Jul 23, 2008 18:44:49 +0200:
> > > + n = 1;
> > > + while (n < main_cmds.cnt &&
> > > + best_similarity == similarity(main_cmds.names[n]->name))
> > > + ++n;
> >
> > Mini-nit: you never ask for the value of n, only if it is 1 or larger. So
> > you do not need to count...
>
> But I do, don't I? AFAICS, I use 0, 1 and >1 (this-these).
Yes. So check cnt > 0 && best_similarity > 5 says if it is 0, and
cnt > 1 && best_similarity < similarity(...[1]...) says if it is 1.
Ergo: no need to count,
Dscho
^ permalink raw reply
* Re: [PATCH 02/12] git-grep: support --no-external-grep
From: Petr Baudis @ 2008-07-23 19:01 UTC (permalink / raw)
To: Nguy???n Thái Ng???c Duy; +Cc: git
In-Reply-To: <20080723145549.GA29067@laptop>
Hi,
the patches 2, 3, 8 and 10 of your series introduce config options,
commandline switches and environment variables that are not documented
anywhere - can you please include documentation updates in your patch
series as well? It might be worth it to find some suitable place in the
documentation where to explain the concept itself; it took me quite
sometime before I actually realized (I think) what are your patches
about. (Which is also why is it useful to write cover letters for
patch series.)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH/RFC] git add: do not add files from a submodule
From: Pierre Habouzit @ 2008-07-23 19:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v8wvse9l7.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]
On Wed, Jul 23, 2008 at 06:31:16PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > On Wed, Jul 23, 2008 at 06:40:20AM +0000, Junio C Hamano wrote:
> > ...
> >> If we started the process of diagnosing and fixing these issues earlier,
> >> and had plausible code to address the issue already in 'next' before the
> >> current -rc cycle started, the topic would have been an obvious candidate
> >> for the coming release and I'd further say it would be even worth delaying
> >> the release for a few weeks if it takes more time. But I have to say it
> >> is too late for 1.6.0 now if we are just noticing and starting the
> >> discussion.
> >
> > Well given that we now use submodules at work, and that git is
> > nowadays somewhere in the top 5 of my most consciously (as opposed to
> > the compiler that I rarely call by hand) used software suites (among my
> > editor, my MUA, my shell and my tiling WM), I'm very much interested in
> > tackling some things about what is (not) done with submodules yet.
>
> Surely the effort is appreciated.
okay I'll try to work on this on the git wiki so that collaboration is
possible.
>
> >> This comment goes to the issue Pierre raised last night as well.
> >
> > You mean the git checkout issue?
>
> Oh, no; that misuse of parse_opt() that forgot KEEP_DASHDASH one was not
> what I had in mind. I meant to say that your "switch branches between an
> old pre-submodule rev and a new one that has a submodule at where a blob
> or directory used to be" issue with a good explanation material was a good
> starting point for submodule improvements for the next cycle.
ohh that :)
> I'd like the release schedule not too heavily based on "per feature", but
> more time-based.
Yeah, we've seen in the past how it makes a release slip. Though it'd
be great to say e.g. that we won't do a 1.7.0 release[0] until we have
an UI for submodules we are prood of. It doesn't mean that we won't have
a 1.6.21 because it's slow to get into shape ;)
IOW I'm all for time based releases, with some big milestones that
when completed bump the git version significantly. And hinting on what
are those milestones would probably be quite nice. I mean git
developpement is kind of a hit and run thing: people have an issue, come
with patches, and go back to their lives (except for a mere 20 regular
contributors with more than 50 patches). Maybe we should hint some
direction we would like to see a bit more. examples of such big
directions are:
* submodules UI ;
* sparse checkouts ;
* ...
[0] I don't really *mean* we must do it for 1.7.0, It's merely an
example.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] sort_in_topological_order(): avoid setting a commit flag
From: Junio C Hamano @ 2008-07-23 19:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: pasky, git
In-Reply-To: <alpine.DEB.1.00.0807230150480.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> @@ -494,7 +493,8 @@ void sort_in_topological_order(struct commit_list ** list, int lifo)
> * when all their children have been emitted thereby
> * guaranteeing topological order.
> */
> - if (!--parent->indegree) {
> + if (--parent->indegree == 1) {
> + parent->indegree = 0;
> if (!lifo)
> insert_by_date(parent, &work);
> else
> @@ -505,7 +505,6 @@ void sort_in_topological_order(struct commit_list ** list, int lifo)
> * work_item is a commit all of whose children
> * have already been emitted. we can emit it now.
> */
> - commit->object.flags &= ~TOPOSORT;
> *pptr = work_item;
> pptr = &work_item->next;
> }
These two hunks look suspicious.
The "tips" used to enter that while() loop with zero indegree, its parents
examined and then entered the final list pointed by pptr with the toposort
scratch variables removed and indegree set to zero. Now with the new +1
based code, they enter the while() loop with 1 indegree, and enter the
final list with indegree set to 1.
A parent that has only one child that is "tip" is discovered in the
while() loop, its indegree decremented (so it goes down to zero in the
original code and 1 in yours) and enters work queue to be processed. It
used to have the toposort scratch variable removed in the second hunk
above, but that is done in the first hunk in your version.
So after this patch, indegree will be all zero for non-tip commits but
will be one for tip commits. Is this intended?
I'd suggest dropping the "parent->indegree = 0" assignment and turn the
second hunk into "commit->indgree = 0" assignment.
^ permalink raw reply
* Re: [PATCH] Add help.autocorrect to enable/disable autocorrecting
From: Johannes Schindelin @ 2008-07-23 19:04 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807231958210.8986@racer>
Hi,
On Wed, 23 Jul 2008, Johannes Schindelin wrote:
> On Wed, 23 Jul 2008, Alex Riesen wrote:
>
> > Johannes Schindelin, Wed, Jul 23, 2008 18:44:49 +0200:
> > > > + n = 1;
> > > > + while (n < main_cmds.cnt &&
> > > > + best_similarity == similarity(main_cmds.names[n]->name))
> > > > + ++n;
> > >
> > > Mini-nit: you never ask for the value of n, only if it is 1 or larger. So
> > > you do not need to count...
> >
> > But I do, don't I? AFAICS, I use 0, 1 and >1 (this-these).
>
> Yes. So check cnt > 0 && best_similarity > 5 says if it is 0,
Oh, I just realized that my patch is bogus anyway. It only checks for
best_similarity > 5 in the case that the first two commands have equal
similarity. D'oh.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 02/12] git-grep: support --no-external-grep
From: Petr Baudis @ 2008-07-23 19:05 UTC (permalink / raw)
To: Nguy???n Thái Ng???c Duy; +Cc: git
In-Reply-To: <20080723190129.GM32184@machine.or.cz>
Hi!
On Wed, Jul 23, 2008 at 09:01:30PM +0200, Petr Baudis wrote:
> (Which is also why is it useful to write cover letters for
> patch series.)
sorry, I did not notice the cover letter, already separated from the
rest by a sprouting thread. Which is also why it is useful to thread up
all the patches. ;-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] Fix git-svnimport against libsvn_ra.
From: Junio C Hamano @ 2008-07-23 19:09 UTC (permalink / raw)
To: P. Christeas; +Cc: git, Gerrit Pape
In-Reply-To: <200807231008.39455.p_christ@hol.gr>
Thanks.
But the one line description is not descriptive enough, don't you think?
Imagine this line (and nothing else from what you wrote in the body text)
appearing among 100 other commits. Can you tell what this commit is about
3 months from now on?
Perhaps:
svnimport: newer libsvn wants us to ask for the root with "", not "/"
> In r27729, libsvn introduced an assert which explicitly
> forbids searching the tree at "/". Luckily enough, it
> still accepts an empty string "" as the starting point.
I think you implied by saying "still", asking with an empty string had the
same effect as asking for the root "/" in earlier versions of SVN, and the
patch will not break people with older libsvn. Is that correct?
> http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_ra/ra_loader.c?r1=27653&r2=27729
> ---
Sign-off, please?
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Pierre Habouzit @ 2008-07-23 19:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ingo Molnar, git
In-Reply-To: <alpine.LFD.1.10.0807231027030.4754@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]
On Wed, Jul 23, 2008 at 05:59:01PM +0000, Linus Torvalds wrote:
> In fact, the two top entries in a profile look roughly like:
>
> 102161 70.2727 libz.so.1.2.3 libz.so.1.2.3 (no symbols)
> 7685 5.2862 git git find_pack_entry_one
> ...
>
> ie 70% of the time is just purely unpacking the data, and another 5% is
> just finding it. We could perhaps improve on it, but not a whole lot.
Well there is an easy way though, that could reduce that: using
adaptative compression. I proposed a patch once upon a time, that set
the compression strengh to 0 for "small" objects with a configurable
cut-off. If you do that, most trees, commits messages and so on aren't
compressed, and it will reduce (with IIRC a 5-liner) this time quite
dramatically.
I could maybe resurect it to see if for people that do the kind of
things Ingo does it helps. By setting the cut-off at 1k, I had packs
being less than 1% bigger IIRC. I'll try to find it again and run your
tests with it to see how much it helps.
[ Of course, it doesn't invalidate the rest of your mail about being
more clever with git-merge, but still, we could reduce this 70% of
zlib time quite a lot with that ]
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] git add: do not add files from a submodule
From: Johannes Schindelin @ 2008-07-23 19:10 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20080723190227.GF20614@artemis.madism.org>
Hi,
On Wed, 23 Jul 2008, Pierre Habouzit wrote:
> Though it'd be great to say e.g. that we won't do a 1.7.0 release[0]
> until we have an UI for submodules we are prood of.
Or until we have everything ported over to parse_options?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] git add: do not add files from a submodule
From: Pierre Habouzit @ 2008-07-23 19:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807232009310.8986@racer>
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
On Wed, Jul 23, 2008 at 07:10:09PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 23 Jul 2008, Pierre Habouzit wrote:
>
> > Though it'd be great to say e.g. that we won't do a 1.7.0 release[0]
> > until we have an UI for submodules we are prood of.
>
> Or until we have everything ported over to parse_options?
hahah, okay, fair enough, I deserve this one ;)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 5/9 v2] Allow the built-in exec path to be relative to the command invocation path
From: Johannes Sixt @ 2008-07-23 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxq0e9lk.fsf@gitster.siamese.dyndns.org>
If GIT_EXEC_PATH (the macro that is defined in the Makefile) is relative,
it is interpreted relative to the command's invocation path, which usually
is $(bindir).
The Makefile rules were written with the assumption that $(gitexecdir) is
an absolute path. We introduce a separate variable that names the
(absolute) installation directory.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
On Mittwoch, 23. Juli 2008, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
> > If $(gitexecdir) is relative, it is interpreted relative to the command's
> > invocation path, which usually is $(bindir).
> >
> > The Makefile rules were written with the assumption that $(gitexecdir) is
> > an absolute path. We introduce a separate variable that names the
> > (absolute) installation directory.
> > ...
> > +ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
> > +gitexec_instdir = $(bindir)/$(gitexecdir)
> > +else
>
> Can we please have a brief comment in the Makefile near we define mandir,
> infodir, gitexecdir and friends about this "relative to $(bindir)"
> business?
Here it is.
It also fixes 'make install' of git-gui as well (sigh!) by not exporting
gitexecdir - assuming that Shawn applies the git-gui patch.
The first two hunks are new compared to v1 of this patch.
-- Hannes
Makefile | 28 +++++++++++++++++++++++-----
exec_cmd.c | 38 ++------------------------------------
2 files changed, 25 insertions(+), 41 deletions(-)
diff --git a/Makefile b/Makefile
index 23f2185..4f19b52 100644
--- a/Makefile
+++ b/Makefile
@@ -170,6 +170,16 @@ ALL_CFLAGS = $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
STRIP ?= strip
+# Among the variables below, these:
+# gitexecdir
+# template_dir
+# htmldir
+# ETC_GITCONFIG (but not sysconfdir)
+# can be specified as a relative path ../some/where/else (which must begin
+# with ../); this is interpreted as relative to $(bindir) and "git" at
+# runtime figures out where they are based on the path to the executable.
+# This can help installing the suite in a relocatable way.
+
prefix = $(HOME)
bindir = $(prefix)/bin
mandir = $(prefix)/share/man
@@ -205,7 +215,7 @@ GITWEB_FAVICON = git-favicon.png
GITWEB_SITE_HEADER =
GITWEB_SITE_FOOTER =
-export prefix bindir gitexecdir sharedir htmldir sysconfdir
+export prefix bindir sharedir htmldir sysconfdir
CC = gcc
AR = ar
@@ -1316,10 +1326,18 @@ template_instdir = $(template_dir)
endif
export template_instdir
+ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
+gitexec_instdir = $(bindir)/$(gitexecdir)
+else
+gitexec_instdir = $(gitexecdir)
+endif
+gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir))
+export gitexec_instdir
+
install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
- $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
+ $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) git$X git-upload-pack$X git-receive-pack$X
git-upload-archive$X '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
@@ -1328,10 +1346,10 @@ ifndef NO_TCLTK
$(MAKE) -C git-gui install
endif
ifneq (,$X)
- $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)),
$(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
+ $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)),
$(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
endif
bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
- execdir=$$(cd '$(DESTDIR_SQ)$(gitexecdir_SQ)' && pwd) && \
+ execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \
if test "z$$bindir" != "z$$execdir"; \
then \
ln -f "$$bindir/git$X" "$$execdir/git$X" || \
diff --git a/exec_cmd.c b/exec_cmd.c
index 45f92eb..c236034 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -7,40 +7,6 @@ extern char **environ;
static const char *argv_exec_path;
static const char *argv0_path;
-static const char *builtin_exec_path(void)
-{
-#ifndef __MINGW32__
- return GIT_EXEC_PATH;
-#else
- int len;
- char *p, *q, *sl;
- static char *ep;
- if (ep)
- return ep;
-
- len = strlen(_pgmptr);
- if (len < 2)
- return ep = ".";
-
- p = ep = xmalloc(len+1);
- q = _pgmptr;
- sl = NULL;
- /* copy program name, turn '\\' into '/', skip last part */
- while ((*p = *q)) {
- if (*q == '\\' || *q == '/') {
- *p = '/';
- sl = p;
- }
- p++, q++;
- }
- if (sl)
- *sl = '\0';
- else
- ep[0] = '.', ep[1] = '\0';
- return ep;
-#endif
-}
-
const char *system_path(const char *path)
{
if (!is_absolute_path(path) && argv0_path) {
@@ -75,7 +41,7 @@ const char *git_exec_path(void)
return env;
}
- return builtin_exec_path();
+ return system_path(GIT_EXEC_PATH);
}
static void add_path(struct strbuf *out, const char *path)
@@ -99,7 +65,7 @@ void setup_path(void)
add_path(&new_path, argv_exec_path);
add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
- add_path(&new_path, builtin_exec_path());
+ add_path(&new_path, system_path(GIT_EXEC_PATH));
add_path(&new_path, argv0_path);
if (old_path)
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* Re: [PATCH] Build configuration to skip ctime for modification test
From: Alex Riesen @ 2008-07-23 19:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0807231757550.8986@racer>
Johannes Schindelin, Wed, Jul 23, 2008 18:59:02 +0200:
> On Wed, 23 Jul 2008, Alex Riesen wrote:
>
> > Because exactly the file mode (the executable bit) is the reason for
> > checking ctime.
>
> But ctime is broken on Windows. Because ctime is supposed to change
> whenever the _inode_ changes.
It is not that it is broken. We just don't need it, because the st_mode
is not used, and the rest of inode information is not used anyway.
> You have to admit that saying "I ignore the ctime because the executable
> bit is broken" must leave the reader puzzled.
This is conclusion. I said "file mode" and "file attributes", which
is how reason for ctime update is defined in SUSv3. man 2 stat says:
The field st_ctime is changed by writing or by setting inode
information (i.e., owner, group, link count, mode, etc.).
Not just "inode" but "inode information". Only mode is used, and even
that is ignored on Windows.
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Junio C Hamano @ 2008-07-23 19:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807231817460.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 23 Jul 2008, Junio C Hamano wrote:
> ...
>> If you are on a sane system, you do not even want to pay the price of
>> conversion. Only people on systems with CRLF line endings should pay
>> the price (because your aim is to convert on such systems). Are we
>> throwing that out of the window when the project decides to use
>> gitattributes?
>
> Well, if you do not want that, why do you set crlf in the gitattributes to
> begin with?
It is not _me_ but the project upstream that needs to interact also with
Windows people who manages gitattributes. And me personally knows my
editors are not helpful to add CR at the end of lines, so I do not need
the conversion.
That was the situation I had in mind.
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Robin Rosenberg @ 2008-07-23 19:22 UTC (permalink / raw)
To: Joshua Jensen; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <488772BC.80207@workspacewhiz.com>
onsdagen den 23 juli 2008 20.04.44 skrev Joshua Jensen:
> ----- Original Message -----
> From: Johannes Schindelin
> Date: 7/23/2008 11:22 AM
> > On msys we do that. A few users decided they know better and switched it
> > off. Me for example. But I wouldn't do something as stupid as editing a
> > file with an editor that tries to be helpful and adds CR/LFs.
> >
> There are certain file formats, such as a Visual Studio .sln file, that
> MUST be CRLF. When a .sln file is not CRLF, Visual Studio refuses to
> read it. I want to be able to set into the committed .gitattributes
> file the list of files that must be translated to the proper format
> regardless of the autocrlf setting. An example is below:
>
> *.bat crlf
> *.def crlf
> *.dsp crlf
> *.dsw crlf
> *.rc crlf
> *.sln crlf
> *.vcproj crlf
> *.vcp crlf
> *.vcw crlf
Wouldn't "*bat -crlf " etc be good for these, and thus store CRLF in the repo.
-- robin
^ permalink raw reply
* Re: [PATCH v2] git daemon: avoid waking up too often
From: Avery Pennarun @ 2008-07-23 19:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <4886D503.7030106@viscovery.net>
On 7/23/08, Johannes Sixt <j.sixt@viscovery.net> wrote:
> This makes porting this beast to Windows practically impossible because we
> cannot have a poll() implementation that waits both on a listening socket
> and a pipe. :-(
I have worked around such problems in the past by having a thread
whose job it is to read from the pipe and simply write it to a socket.
The trick works for "console" objects, too, which in win32 are even
less agreeable than pipes.
(In case your life wasn't disgusting enough already today :))
Alternatively, you could use something like socketpair() instead of a
pipe for this purpose. Naturally, Win32 helps you out here by somehow
forgetting to include socketpair() in winsock, although it's sort of
easy to emulate.
Have fun,
Avery
^ 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