* Re: [PATCH 2/2] [TopGit] Portability: Don't use alternation ("|") in sed regular expressions
From: Uwe Kleine-König @ 2009-03-12 17:04 UTC (permalink / raw)
To: Brian Campbell; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <F3665462-16BC-42D6-BE28-F66CF48CEB9B@dartmouth.edu>
Hello Brian,
On Thu, Mar 12, 2009 at 12:41:45PM -0400, Brian Campbell wrote:
>> IMHO we should reuse as much as possible from git.git. For me even
>> requiring a git.git checkout to use its files would be OK. I consider
>> that even better then duplicating the relevant files.
>
> Hmm. How would the tests find your git working tree? I'd be willing to
> start the process off at least by writing test cases for the
> functionality I'm changing here if I had a good idea of how to start.
> Would it be sufficient to make something like "GIT_CHECKOUT=~/src/git
> make check" work?
Yes, this would be a good start. I would call it GIT_SRC, but that's up
to you.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Todd Zullinger @ 2009-03-12 17:09 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Alejandro Riveira, git, Jay Soffian, Tom Holaday
In-Reply-To: <49B8EF3E.2070208@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]
Michael J Gruber wrote:
> Following up on this:
> On Fedora 10, I have asciidoc 8.2.5 and docbook 1.7.4 xsl's. For
> proper man and html doc, I have to set DOCBOOK_XSL_172=Yes but leave
> ASCIIDOC8 unset! I always forget, though (just like the packagers).
Check the fedora git packages in rawhide, we don't set ASCIIDOC8. :)
I experimented with that and found it did not improve things. We are
only setting DOCBOOK_XSL_172. Without that, we get the '.ft C'
droppings. With it, we get non-ascii characters in various places
(where bold should be used to make the (1) notations stand out, for
example). This was filed as:
https://bugzilla.redhat.com/show_bug.cgi?id=485161
I didn't add DOCBOOK_XSL_172 to the F-10 packages yet, because I know
that it fixes one problem and causes another. Either way, we'd be
shipping packages with known brokeness. I chose to stick with keeping
the currently broken '.ft C' behavior. Pick your poison. ;)
One of the fedora/red hat folks that works on the xmlto and docbook
packages was going to take a look, as I very much don't understand the
documentation stack. :/
Anyone who does is very welcome to help find the culprit(s) and help
get fixes to the proper places.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The worth of a state, in the long run, is the worth of the individuals
composing it.
-- John Stuart Mill
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: git checkout -b origin/mybranch origin/mybranch
From: Jeff King @ 2009-03-12 17:14 UTC (permalink / raw)
To: John Tapsell
Cc: Pieter de Bie, Sverre Rabbelier, Johannes Schindelin, Git List
In-Reply-To: <43d8ce650903120958n18baf6c0w9d083976b52d6e40@mail.gmail.com>
On Thu, Mar 12, 2009 at 04:58:22PM +0000, John Tapsell wrote:
> > - if (resolve_ref(ref.buf, sha1, 1, NULL)) {
> > + if (dwim_ref(name, strlen(name), sha1, &junk)) {
> > + free(junk);
>
> Presumably 'junk' is the resolved name? I wonder if it's worth
> putting this info in the error message?
Hey, I said it was sloppy, right? ;)
Here's your suggestion, plus specifying which situation (existing branch
or ambiguous ref) would occur. It would still need tests. But I'm
curious to hear more opinions on this direction before cleaning it up
much more (at the very least, it needs some tests).
--- a/branch.c
+++ b/branch.c
@@ -133,6 +133,7 @@ void create_branch(const char *head,
unsigned char sha1[20];
char *real_ref, msg[PATH_MAX + 20];
struct strbuf ref = STRBUF_INIT;
+ char *existing;
int forcing = 0;
int len;
@@ -146,12 +147,18 @@ void create_branch(const char *head,
if (check_ref_format(ref.buf))
die("'%s' is not a valid branch name.", name);
- if (resolve_ref(ref.buf, sha1, 1, NULL)) {
- if (!force)
- die("A branch named '%s' already exists.", name);
+ if (dwim_ref(name, strlen(name), sha1, &existing)) {
+ if (!force) {
+ if (!prefixcmp(existing, "refs/heads/"))
+ die("A branch named '%s' already exists.",
+ name);
+ die("Creating '%s' would be ambiguous with"
+ " the existing %s", name, existing);
+ }
else if (!is_bare_repository() && !strcmp(head, name))
die("Cannot force update the current branch.");
forcing = 1;
+ free(existing);
}
real_ref = NULL;
^ permalink raw reply
* Deleting a submodule
From: Pedro Melo @ 2009-03-12 17:31 UTC (permalink / raw)
To: Git Mailinglist
Hi,
I couldn't find a git-submodule command to delete a submodule. What is
the correct procedure?
I did:
* removed the entry from .gitmodules;
* run git submodule sync
But its still recorded somewhere.
Thanks,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* Re: git checkout -b origin/mybranch origin/mybranch
From: John Tapsell @ 2009-03-12 17:45 UTC (permalink / raw)
To: Jeff King; +Cc: Pieter de Bie, Sverre Rabbelier, Johannes Schindelin, Git List
In-Reply-To: <20090312171420.GA2192@coredump.intra.peff.net>
2009/3/12 Jeff King <peff@peff.net>:
> On Thu, Mar 12, 2009 at 04:58:22PM +0000, John Tapsell wrote:
>
>> > - if (resolve_ref(ref.buf, sha1, 1, NULL)) {
>> > + if (dwim_ref(name, strlen(name), sha1, &junk)) {
>> > + free(junk);
>>
>> Presumably 'junk' is the resolved name? I wonder if it's worth
>> putting this info in the error message?
>
> Hey, I said it was sloppy, right? ;)
>
> Here's your suggestion, plus specifying which situation (existing branch
> or ambiguous ref) would occur. It would still need tests. But I'm
> curious to hear more opinions on this direction before cleaning it up
> much more (at the very least, it needs some tests).
I like :-) Just minor comments:
> --- a/branch.c
> +++ b/branch.c
> @@ -133,6 +133,7 @@ void create_branch(const char *head,
> unsigned char sha1[20];
> char *real_ref, msg[PATH_MAX + 20];
> struct strbuf ref = STRBUF_INIT;
> + char *existing;
Don't suppose you could set this NULL. Just in case dwim_ref doesn't
set &existing for whatever reason.
> int forcing = 0;
> int len;
>
> @@ -146,12 +147,18 @@ void create_branch(const char *head,
> if (check_ref_format(ref.buf))
> die("'%s' is not a valid branch name.", name);
>
> - if (resolve_ref(ref.buf, sha1, 1, NULL)) {
> - if (!force)
> - die("A branch named '%s' already exists.", name);
> + if (dwim_ref(name, strlen(name), sha1, &existing)) {
> + if (!force) {
> + if (!prefixcmp(existing, "refs/heads/"))
> + die("A branch named '%s' already exists.",
> + name);
> + die("Creating '%s' would be ambiguous with"
> + " the existing %s", name, existing);
Maybe put single quotes around the second %s, for consistency with the first?
> + }
> else if (!is_bare_repository() && !strcmp(head, name))
> die("Cannot force update the current branch.");
> forcing = 1;
> + free(existing);
> }
>
> real_ref = NULL;
>
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: david @ 2009-03-12 18:00 UTC (permalink / raw)
To: saurabh gupta; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <ab9fa62a0903120545o7e5bc359g7df233b00858869c@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3377 bytes --]
On Thu, 12 Mar 2009, saurabh gupta wrote:
> On Thu, Mar 12, 2009 at 3:17 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> You can cut it both ways. For an OO document, you do not necessarily need
>> any file-level merger at the driver level, but just let the "binary"
>> driver declare conflicts and punt. A merge helper can do all the work
>> starting from the "original, ours and theirs" that are not smudged with
>> conflict markers.
>>
>> Between these two extremes, the discussion from other people in the thread
>> seemed to all focus too heavily on the "driver punts" approach, forgetting
>> that mergetool is useful only because most of the time we do not have to
>> even use it, thanks to the fact that "xdl" driver works reasonably well
>> for most trivial cases where branches being merged stayed away from each
>> other, which is the majority case. It is a huge win from the productivity
>> point of view, and many people might be unaware of it because it is so
>> invisible.
>
> If I am not wrong, then for merging two xml files, if we use a simple
> xdl merge driver then it will mark the conflicts in the normal way as
> it does for simple text files. As far as I can understand, the
> following things are supposed to be aimed here taking an example of
> xml file:
>
>
> =>Merging of two xml files
>
> => existing merge driver (like xdl) is called which marks the
> conflicts points just like a normal text file.
>
> => the conflicted file can be read through a text terminal and
> conflicted lines can be seen.
>
> => suppose the xml file is from the domain of OO document. Then, a
> merge helper for OO xml type file is called which takes input as the
> conflicted file produced by xdl driver.
>
> => The merge helper creates a new file or changes the input file to
> make it a valid xml file so that it can be opened in OpenOffice and
> user can see the markers like "====" or "<<<<<" in an appropriate
> manner and can resolve the file manually.
with XML files it's possible to be symanticly identical, but not identical
as far as a text merge driver is concerned.
for example, the following two tags are identical in meaning, but would
show up as different (and therefor in conflict) in a text merge
<tag attr1='foo' attr2='bar' />
<tag attr2='bar' attr1='foo' />
in many instances (such as config files), the order of items doesn't
change the meaning. so the following two items would be identical
<tag1>
stuff
</tag1>
<tag2>
more stuff
</tag2>
vs
<tag2>
more stuff
</tag2>
<tag1>
stuff>
</tag1>
in addition whitespace may or may not be relavent (depending on how the
XML is used) so the following may also be identical
<tag>stuff<tag>
vs
<tag>
stuff
</tag>
a good XML merge driver would have options that you could set for a
particular file type to know about these sorts of things.
>> When it cannot autoresolve,
>> but there is no way to "mark" a tentative result with conflict markers, it
>> can do the same thing as the "binary" driver and let the mergetool backend
>> handle the "driver punted" case.
>
> I think you mean to say that in case, there is a conflict and the
> changes don't overlap, then merge driver leaves the file as it is and
> the merge helper will handle the file.
if there is a conflict it should be because the changes do overlap. if
they don't overlap why is it a conflict?
David Lang
^ permalink raw reply
* Re: Generalised bisection
From: Steven Tweed @ 2009-03-12 18:02 UTC (permalink / raw)
To: Johannes Schindelin
Cc: John Tapsell, Ealdwulf Wuffinga, Christian Couder, Git List,
Ingo Molnar
In-Reply-To: <alpine.DEB.1.00.0903121154560.10279@pacific.mpi-cbg.de>
On Thu, Mar 12, 2009 at 10:55 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Thu, 12 Mar 2009, John Tapsell wrote:
> > 2009/3/11 Ealdwulf Wuffinga <ealdwulf@googlemail.com>:
> > > What I use is the multiprecision floating point number class. doubles
> > > don't seem to be long enough.
> >
> > Hmm, really really? Sometimes this sort of thing can be fixed by just
> > readjusting the formulas. What formulas are you using that require more
> > precision than doubles?
>
> Maybe you could post the formulae instead of forcing people to deduct them
> from the source code?
I haven't even looked at the source code so a description of the
mathematical algorithm would help, but I'll just point out that
underflow (in the case of working with probabilities) and overflow
(when working with their negated logarithms) is inherent in most
multi-step Bayesian algorithms. The only solution is to rescale things
as you go so that things stay in a "computable" range. (You're almost
never interested in absolute probabilities anyway but rather relative
probabilities or, in extreme cases, just the biggest probability, so
rescaling isn't losing any useful information.)
cheers,
dave tweed
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: david @ 2009-03-12 18:03 UTC (permalink / raw)
To: saurabh gupta; +Cc: Johannes Schindelin, git
In-Reply-To: <ab9fa62a0903120542s45b1ceebwddab932891c47cf0@mail.gmail.com>
On Thu, 12 Mar 2009, saurabh gupta wrote:
> hello,
>
> On Thu, Mar 12, 2009 at 1:51 AM, <david@lang.hm> wrote:
>>
>>> Yes, but the thing is that the underlying codes and method will be
>>> different for GUI part and terminal part to make it readable and
>>> understandable. Like for OO Documents, if we aim to show the *diff*
>>> output in the Office tool, then we have to change the xml file
>>> accordingly. But the same xml file when used with terminal only, the
>>> *diff* output is not clear.
>>>
>>> As Johannes said in above post that for OO documents, while showing
>>> the *diff* result, no xml data should be shown.
>>
>> in part we are talking about different aspects of things, and we were all
>> wrong.
>>
>> see the e-mail a little bit ago by Junio
>>
>> there are two types of helpers that can be written
>>
>> 1. a low-level part that does the simple merges automaticaly and leaves
>> behind appropriate conflict markers when it can't
>>
>> there is no GUI involved with this.
>>
>> what 'appropriate conflict markers' are can vary from XML file to XML file
>>
>>
>> 2. after a conflict has taken place, a helper to work with the user to
>> resolve the conflict
>>
>> this can have a GUI and/or a text UI and is tied to the 'appropriate
>> conflict markers' as defined in #1, and can be _very_ tightly coupled to the
>> specific use of the XML file.
>>
>> I think it's very important to have a text UI tool that can be used for the
>> conflict resolution step as well as supporting GUI tools.
>
> All right. What I can understand from the current situation is that
> for merging and marking conflicts in xml (for example) files has
> following things to do.
>
> One, if the markers are put in the xml files like that of a text file,
> one can see the difference using a text editor or a terminal. But if
> the same xml file is to be opened in another editor which expects a
> valid xml (as clearly mentioned on the wiki ideas for GIT), then a
> merge helper is needed.
>
> But if the conflict markers are put in a way to make the xml file
> still valid which can be then opened in the appropriate editor, then
> the marking will be different. The merge driver has to produce the
> conflicted merged file in a manner which is still a valid xml file and
> user has the choice to open it in his own editor to resolve the
> conflicts.
exactly. and how you mark the conflict to have it be valid XML is going to
depend on details of the type of file. there are probably a few basic
methods that will work the vast majority of the time, but with some
details needing to be configurable.
for example, if the XML document is a ODF document, it may be possible to
add 'revision' tags around the conflict that are already understood by the
editor.
David Lang
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-12 18:23 UTC (permalink / raw)
To: david; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.DEB.1.10.0903121100360.16753@asgard.lang.hm>
On Thu, Mar 12, 2009 at 11:33 PM, <david@lang.hm> wrote:
>
> On Thu, 12 Mar 2009, saurabh gupta wrote:
>
>> hello,
>>
>> On Thu, Mar 12, 2009 at 1:51 AM, <david@lang.hm> wrote:
>>>
>>>> Yes, but the thing is that the underlying codes and method will be
>>>> different for GUI part and terminal part to make it readable and
>>>> understandable. Like for OO Documents, if we aim to show the *diff*
>>>> output in the Office tool, then we have to change the xml file
>>>> accordingly. But the same xml file when used with terminal only, the
>>>> *diff* output is not clear.
>>>>
>>>> As Johannes said in above post that for OO documents, while showing
>>>> the *diff* result, no xml data should be shown.
>>>
>>> in part we are talking about different aspects of things, and we were all
>>> wrong.
>>>
>>> see the e-mail a little bit ago by Junio
>>>
>>> there are two types of helpers that can be written
>>>
>>> 1. a low-level part that does the simple merges automaticaly and leaves
>>> behind appropriate conflict markers when it can't
>>>
>>> there is no GUI involved with this.
>>>
>>> what 'appropriate conflict markers' are can vary from XML file to XML file
>>>
>>>
>>> 2. after a conflict has taken place, a helper to work with the user to
>>> resolve the conflict
>>>
>>> this can have a GUI and/or a text UI and is tied to the 'appropriate
>>> conflict markers' as defined in #1, and can be _very_ tightly coupled to the
>>> specific use of the XML file.
>>>
>>> I think it's very important to have a text UI tool that can be used for the
>>> conflict resolution step as well as supporting GUI tools.
>>
>> All right. What I can understand from the current situation is that
>> for merging and marking conflicts in xml (for example) files has
>> following things to do.
>>
>> One, if the markers are put in the xml files like that of a text file,
>> one can see the difference using a text editor or a terminal. But if
>> the same xml file is to be opened in another editor which expects a
>> valid xml (as clearly mentioned on the wiki ideas for GIT), then a
>> merge helper is needed.
>>
>> But if the conflict markers are put in a way to make the xml file
>> still valid which can be then opened in the appropriate editor, then
>> the marking will be different. The merge driver has to produce the
>> conflicted merged file in a manner which is still a valid xml file and
>> user has the choice to open it in his own editor to resolve the
>> conflicts.
>
> exactly. and how you mark the conflict to have it be valid XML is going to depend on details of the type of file. there are probably a few basic methods that will work the vast majority of the time, but with some details needing to be configurable.
>
> for example, if the XML document is a ODF document, it may be possible to add 'revision' tags around the conflict that are already understood by the editor.
Exactly. This includes the work to modify the xml tags and add
contents to represent marker in the best way.
--
Saurabh Gupta
Senior,
NSIT,New Delhi, India
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: david @ 2009-03-12 18:25 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Johannes Schindelin, Daniel Barkalow, saurabh gupta, git
In-Reply-To: <49B90AE4.9030904@drmicha.warpmail.net>
On Thu, 12 Mar 2009, Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 12.03.2009 14:07:
>> Hi,
>>
>> On Thu, 12 Mar 2009, Michael J Gruber wrote:
>>
>>> Johannes Schindelin venit, vidit, dixit 11.03.2009 17:44:
>>>
>>>> On Wed, 11 Mar 2009, Daniel Barkalow wrote:
>>>>
>>>>> One thing that I think would be good whenever possible is to have the
>>>>> merge program generate a file in the same format which is easily
>>>>> recognizable as having conflict markers. For example, I think it
>>>>> should be possible to show conflicts in the text of office documents
>>>>> by having styles for each side of the merge, and show each side's
>>>>> content in the appropriate style. Then the user opens the document
>>>>> with their choice of office software, finds the things in the
>>>>> conflict styles, and decides what the result should be.
>>>> That's a very good idea! (Except for LaTeX, maybe...)
>>> latexdiff (in perl) may give you a head start (or ache, I dunno).
>> No. latexdiff is about diffing. It does nothing to help me resolve a
>> conflict.
>
> Sure. If you want to merge you have to diff first (and display it). That
> would be the "head start". Then you have to think about the merge.
> That's where the "head ache" kicks in...
the idea is that the merge driver should do the diff and merge the simple
things, only needing to display it if there is a conflict that it cannot
resolve.
David Lang
^ permalink raw reply
* Re: git checkout -b origin/mybranch origin/mybranch
From: Junio C Hamano @ 2009-03-12 18:31 UTC (permalink / raw)
To: John Tapsell; +Cc: Johannes Schindelin, Git List
In-Reply-To: <43d8ce650903120618h79686207vaa478c54f34e26f8@mail.gmail.com>
John Tapsell <johnflux@gmail.com> writes:
> I'm saying that:
>
> git checkout -b origin/mybranch origin/mybranch
>
> Is probably a mistake by the user. We should warn the user and point
> them in the right direction.
Given Finn Arne Gangstad's use case in a nearby thread, I do not think you
can so easily declare that it is a mistake by the user.
We have traditionally encouraged people to track remote origin/<name> with
matching local <name>, but in a workflow that interact with multiple
remotes, one obvious way to map would be to track remote origin/<name>
with local origin/<name> branch. You can say remotes/origin/<name> when
you mean the remote tracking one, and say heads/origin/<name> when you
mean the local one, in order to disambiguate in such a setting.
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Junio C Hamano @ 2009-03-12 18:43 UTC (permalink / raw)
To: david; +Cc: saurabh gupta, Johannes Schindelin, git
In-Reply-To: <alpine.DEB.1.10.0903121052310.16753@asgard.lang.hm>
david@lang.hm writes:
> On Thu, 12 Mar 2009, saurabh gupta wrote:
>
>> On Thu, Mar 12, 2009 at 3:17 AM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
> with XML files it's possible to be symanticly identical, but not
> identical as far as a text merge driver is concerned.
> ...
> a good XML merge driver would have options that you could set for a
> particular file type to know about these sorts of things.
Correct.
>>> When it cannot autoresolve,
>>> but there is no way to "mark" a tentative result with conflict markers, it
>>> can do the same thing as the "binary" driver and let the mergetool backend
>>> handle the "driver punted" case.
>>
>> I think you mean to say that in case, there is a conflict and the
>> changes don't overlap, then merge driver leaves the file as it is and
>> the merge helper will handle the file.
>
> if there is a conflict it should be because the changes do overlap. if
> they don't overlap why is it a conflict?
Correct. In such a case when the "driver" can be sure that the result is
reasonable, "helper" should not even kick in. That was the main point of
my suggestion, which you seem to have got right.
Thanks.
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: david @ 2009-03-12 18:53 UTC (permalink / raw)
To: saurabh gupta; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <ab9fa62a0903121119j6c2a1d43kd9cda99db47b5e7c@mail.gmail.com>
On Thu, 12 Mar 2009, saurabh gupta wrote:
> On Thu, Mar 12, 2009 at 11:30 PM, <david@lang.hm> wrote:
>
>> On Thu, 12 Mar 2009, saurabh gupta wrote:
>>
>>>
>>> =>Merging of two xml files
>>>
>>> => existing merge driver (like xdl) is called which marks the
>>> conflicts points just like a normal text file.
>>>
>>> => the conflicted file can be read through a text terminal and
>>> conflicted lines can be seen.
>>>
>>> => suppose the xml file is from the domain of OO document. Then, a
>>> merge helper for OO xml type file is called which takes input as the
>>> conflicted file produced by xdl driver.
>>>
>>> => The merge helper creates a new file or changes the input file to
>>> make it a valid xml file so that it can be opened in OpenOffice and
>>> user can see the markers like "====" or "<<<<<" in an appropriate
>>> manner and can resolve the file manually.
>>>
>>
>> with XML files it's possible to be symanticly identical, but not identical
>> as far as a text merge driver is concerned.
>>
<SNIPB>
> you are right. For xml merging, what I am thinking is to create the
> algorithm based on the document object model. Inside, any tag, all tags are
> compared only in terms of content and not in order. But again, this ordering
> option can be given to the user. If the user wants order to matter, then a
> conflict will be resulted if order mismatches.
right.
> But other issue is regarding the display of conflict markers. Either
> conflict markers should be put in xml format or like text merger. This is
> the main project idea for GSoC 2009.
this may need to be a configurable option, but I suspect that we could get
away with always using something in XML format. exactly what the markers
are needs to be configurable (the markers for OO will not be the same as
for SVG for example)
building a library of 'this works especially well for this app' markers is
something that needs to be started as part of the GSOC project, but
possibly only far enough to show a couple of examples and have confidence
that the tool is configurable enough.
David Lang
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-12 19:00 UTC (permalink / raw)
To: david; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <alpine.DEB.1.10.0903121148540.16753@asgard.lang.hm>
On Fri, Mar 13, 2009 at 12:23 AM, <david@lang.hm> wrote:
> On Thu, 12 Mar 2009, saurabh gupta wrote:
>
>> On Thu, Mar 12, 2009 at 11:30 PM, <david@lang.hm> wrote:
>>
>>> On Thu, 12 Mar 2009, saurabh gupta wrote:
>>>
>>>>
>>>> =>Merging of two xml files
>>>>
>>>> => existing merge driver (like xdl) is called which marks the
>>>> conflicts points just like a normal text file.
>>>>
>>>> => the conflicted file can be read through a text terminal and
>>>> conflicted lines can be seen.
>>>>
>>>> => suppose the xml file is from the domain of OO document. Then, a
>>>> merge helper for OO xml type file is called which takes input as the
>>>> conflicted file produced by xdl driver.
>>>>
>>>> => The merge helper creates a new file or changes the input file to
>>>> make it a valid xml file so that it can be opened in OpenOffice and
>>>> user can see the markers like "====" or "<<<<<" in an appropriate
>>>> manner and can resolve the file manually.
>>>>
>>>
>>> with XML files it's possible to be symanticly identical, but not
>>> identical
>>> as far as a text merge driver is concerned.
>>>
> <SNIPB>
>>
>> you are right. For xml merging, what I am thinking is to create the
>> algorithm based on the document object model. Inside, any tag, all tags
>> are
>> compared only in terms of content and not in order. But again, this
>> ordering
>> option can be given to the user. If the user wants order to matter, then a
>> conflict will be resulted if order mismatches.
>
> right.
>
>> But other issue is regarding the display of conflict markers. Either
>> conflict markers should be put in xml format or like text merger. This is
>> the main project idea for GSoC 2009.
>
> this may need to be a configurable option, but I suspect that we could get
> away with always using something in XML format. exactly what the markers are
> needs to be configurable (the markers for OO will not be the same as for SVG
> for example)
yeah.
> building a library of 'this works especially well for this app' markers is
> something that needs to be started as part of the GSOC project, but possibly
> only far enough to show a couple of examples and have confidence that the
> tool is configurable enough.
>
I think picking up some formats and then building libraries above that
is needed. In some sense, I talked about the plug-in architecture
also. Can;t it be possible that for different applications (like OO or
SVG), different merge helper plugins are created which can be
integrated with it. Or speaking in other words, instead of plug-ins
now, libraries for merge helpers for different applications are
created.
--
Saurabh Gupta
Senior,
NSIT,New Delhi, India
^ permalink raw reply
* Re: [PATCH] Introduce a filter-path argument to git-daemon, for doing custom path transformations
From: Johan Sørensen @ 2009-03-12 19:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903121218000.10279@pacific.mpi-cbg.de>
On Thu, Mar 12, 2009 at 12:29 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
(all my comments below refer to my latest patch)
> More importantly, you might want to point out the security concerns of
> running a script with the full permissions of git-daemon. (AFAICT from
> your patch you are not dropping any privileges at any point.)
Do you really think this is needed? It doesn't seem like running the
hook scripts does anything more than trusting the script author and
permissions of the hook scripts (?). I see the path-filter script
exactly the same way, with the exception of having to double-check the
user supplied path the script receives.
> Which brings me to another idea: we have quite a few places in Git where
> we use regular expressions. Would they not be enough for your use case?
Hmm, please do elaborate on your idea. If you mean being able to
supply a bunch of regexp mappings when starting the daemon then it
wouldn't cut it for me; I'm in need of something more dynamic.
>> diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
>> index 36f00ae..efd1687 100644
>> --- a/Documentation/git-daemon.txt
>> +++ b/Documentation/git-daemon.txt
>> @@ -71,6 +72,18 @@ OPTIONS
[snip]
> Please keep the lines shorter than 81 characters.
I believe the longest line I've added in the docs is 77.
> But there is more: what about concurrent accesses?
The external path-filter script is run from the execute(), which is
forked+exec'ed for each incoming connection to the daemon, so that
would mean a concurrency of one in that child-process, unless I've
missed something in the code path?
>> + read(filter_cmd.out, result, sizeof(result) - 1);
>
> No error checking?
>
> BTW we do have strbuf_read(), which would solve your "static char *"
> problem nicely.
I'm using strbuf_read() now, but this being my very first git patch, I
may have misunderstood the api slightly?
> And your code would be even easier to read if your
> run_path_filter_script() would never return NULL, but the unchanged path
> instead.
Done.
Thanks for giving my patch the run-through. I'm still curious to hear
what people think about the idea in general though!
>
> Ciao,
> Dscho
>
Cheers,
JS
^ permalink raw reply
* autoconf changes
From: Ben Walton @ 2009-03-12 19:20 UTC (permalink / raw)
To: git
Hi All,
I discovered recently (when building 1.6.2 on solaris 8 sparc) that
the autoconf detection for POSIX Threads wasn't quite adequate for my
needs. This is partly due to gcc only warning on invalid flags in
some cases (-pthread on solaris 8 sparc) but still exiting cleanly.
When I got looking at things, I found several items that I don't think
are quite right. For example, any of the --with- options that take a
path argument didn't actually use the value supplied when testing for
features in a library. If the user didn't also set a good
CPPFLAGS/LDFLAGS (which they should, but that's beside the point),
things like the deflateUnbound zlib function might be ignored even
when present.
I decided to dig in and modify the configure.ac file fairly heavily.
What I've put together in the forthcoming patch set does the
following:
1. Handles user arguments early in the configure script and makes the
values that get set in config.mak.autogen available in the rest of
the script (I find those names nicer that $with_...). These
settings now make it into config.log too.
2. Use the values supplied to wrap tests with a modified CPP/LD FLAGS
pair when applicable.
3. Fixed the asciidoc test to better handle python 2.6 (I haven't
tested with 2.4, but the change is quite simple and shouldn't be a
problem [as someone else mentioned recently: famous last words]).
4. Allows the user to pass in compiler flags to enable POSIX Threads
which will override the default pair of tests.
5. Tries to maintain the original actions and intents where possible.
I've tested this on solaris 8 and Linux (Ubuntu 9.04) and it seems to
do all the things I'd expect.
I hope you'll find these to be useful changes.
Thanks
-Ben
^ permalink raw reply
* [PATCH] configure: reorganize flow of argument checks
From: Ben Walton @ 2009-03-12 19:20 UTC (permalink / raw)
To: git; +Cc: Ben Walton
In-Reply-To: <1236885612-22575-2-git-send-email-bwalton@artsci.utoronto.ca>
Move the argument tests from the 'site overrides' so that they are
ahead of any library tests. This allows for library tests to take
user specified paths into account. The intent here is to avoid things
like NO_DEFLATE_BOUND being set due to finding old zlib when the user
has specified an alternate location for zlib. (Ignore the fact that
properly set *FLAGS can avoid solve this issue.)
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
configure.ac | 174 +++++++++++++++++++++++++++++-----------------------------
1 files changed, 87 insertions(+), 87 deletions(-)
diff --git a/configure.ac b/configure.ac
index 0b314d7..0bff480 100644
--- a/configure.ac
+++ b/configure.ac
@@ -100,6 +100,93 @@ if test -z "$lib"; then
AC_MSG_NOTICE([Setting lib to 'lib' (the default)])
lib=lib
fi
+
+## Site configuration (override autodetection)
+## --with-PACKAGE[=ARG] and --without-PACKAGE
+AC_MSG_NOTICE([CHECKS for site configuration])
+#
+# Define NO_SVN_TESTS if you want to skip time-consuming SVN interoperability
+# tests. These tests take up a significant amount of the total test time
+# but are not needed unless you plan to talk to SVN repos.
+#
+# Define MOZILLA_SHA1 environment variable when running make to make use of
+# a bundled SHA1 routine coming from Mozilla. It is GPL'd and should be fast
+# on non-x86 architectures (e.g. PowerPC), while the OpenSSL version (default
+# choice) has very fast version optimized for i586.
+#
+# Define PPC_SHA1 environment variable when running make to make use of
+# a bundled SHA1 routine optimized for PowerPC.
+#
+# Define ARM_SHA1 environment variable when running make to make use of
+# a bundled SHA1 routine optimized for ARM.
+#
+# Define NO_OPENSSL environment variable if you do not have OpenSSL.
+# This also implies MOZILLA_SHA1.
+#
+# Define OPENSSLDIR=/foo/bar if your openssl header and library files are in
+# /foo/bar/include and /foo/bar/lib directories.
+AC_ARG_WITH(openssl,
+AS_HELP_STRING([--with-openssl],[use OpenSSL library (default is YES)])
+AS_HELP_STRING([], [ARG can be prefix for openssl library and headers]),\
+GIT_PARSE_WITH(openssl))
+#
+# Define NO_CURL if you do not have curl installed. git-http-pull and
+# git-http-push are not built, and you cannot use http:// and https://
+# transports.
+#
+# Define CURLDIR=/foo/bar if your curl header and library files are in
+# /foo/bar/include and /foo/bar/lib directories.
+AC_ARG_WITH(curl,
+AS_HELP_STRING([--with-curl],[support http(s):// transports (default is YES)])
+AS_HELP_STRING([], [ARG can be also prefix for curl library and headers]),
+GIT_PARSE_WITH(curl))
+#
+# Define NO_EXPAT if you do not have expat installed. git-http-push is
+# not built, and you cannot push using http:// and https:// transports.
+#
+# Define EXPATDIR=/foo/bar if your expat header and library files are in
+# /foo/bar/include and /foo/bar/lib directories.
+AC_ARG_WITH(expat,
+AS_HELP_STRING([--with-expat],
+[support git-push using http:// and https:// transports via WebDAV (default is YES)])
+AS_HELP_STRING([], [ARG can be also prefix for expat library and headers]),
+GIT_PARSE_WITH(expat))
+#
+# Define NO_FINK if you are building on Darwin/Mac OS X, have Fink
+# installed in /sw, but don't want GIT to link against any libraries
+# installed there. If defined you may specify your own (or Fink's)
+# include directories and library directories by defining CFLAGS
+# and LDFLAGS appropriately.
+#
+# Define NO_DARWIN_PORTS if you are building on Darwin/Mac OS X,
+# have DarwinPorts installed in /opt/local, but don't want GIT to
+# link against any libraries installed there. If defined you may
+# specify your own (or DarwinPort's) include directories and
+# library directories by defining CFLAGS and LDFLAGS appropriately.
+#
+# Define NO_MMAP if you want to avoid mmap.
+#
+# Define NO_ICONV if your libc does not properly support iconv.
+AC_ARG_WITH(iconv,
+AS_HELP_STRING([--without-iconv],
+[if your architecture doesn't properly support iconv])
+AS_HELP_STRING([--with-iconv=PATH],
+[PATH is prefix for libiconv library and headers])
+AS_HELP_STRING([],
+[used only if you need linking with libiconv]),
+GIT_PARSE_WITH(iconv))
+
+## --enable-FEATURE[=ARG] and --disable-FEATURE
+#
+# Define USE_NSEC below if you want git to care about sub-second file mtimes
+# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
+# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely
+# randomly break unless your underlying filesystem supports those sub-second
+# times (my ext3 doesn't).
+#
+# Define USE_STDEV below if you want git to care about the underlying device
+# change being considered an inode change from the update-index perspective.
+
#
# Define SHELL_PATH to provide path to shell.
GIT_ARG_SET_PATH(shell)
@@ -526,93 +613,6 @@ AC_SUBST(PTHREAD_LIBS)
AC_SUBST(NO_PTHREADS)
AC_SUBST(THREADED_DELTA_SEARCH)
-## Site configuration (override autodetection)
-## --with-PACKAGE[=ARG] and --without-PACKAGE
-AC_MSG_NOTICE([CHECKS for site configuration])
-#
-# Define NO_SVN_TESTS if you want to skip time-consuming SVN interoperability
-# tests. These tests take up a significant amount of the total test time
-# but are not needed unless you plan to talk to SVN repos.
-#
-# Define MOZILLA_SHA1 environment variable when running make to make use of
-# a bundled SHA1 routine coming from Mozilla. It is GPL'd and should be fast
-# on non-x86 architectures (e.g. PowerPC), while the OpenSSL version (default
-# choice) has very fast version optimized for i586.
-#
-# Define PPC_SHA1 environment variable when running make to make use of
-# a bundled SHA1 routine optimized for PowerPC.
-#
-# Define ARM_SHA1 environment variable when running make to make use of
-# a bundled SHA1 routine optimized for ARM.
-#
-# Define NO_OPENSSL environment variable if you do not have OpenSSL.
-# This also implies MOZILLA_SHA1.
-#
-# Define OPENSSLDIR=/foo/bar if your openssl header and library files are in
-# /foo/bar/include and /foo/bar/lib directories.
-AC_ARG_WITH(openssl,
-AS_HELP_STRING([--with-openssl],[use OpenSSL library (default is YES)])
-AS_HELP_STRING([], [ARG can be prefix for openssl library and headers]),\
-GIT_PARSE_WITH(openssl))
-#
-# Define NO_CURL if you do not have curl installed. git-http-pull and
-# git-http-push are not built, and you cannot use http:// and https://
-# transports.
-#
-# Define CURLDIR=/foo/bar if your curl header and library files are in
-# /foo/bar/include and /foo/bar/lib directories.
-AC_ARG_WITH(curl,
-AS_HELP_STRING([--with-curl],[support http(s):// transports (default is YES)])
-AS_HELP_STRING([], [ARG can be also prefix for curl library and headers]),
-GIT_PARSE_WITH(curl))
-#
-# Define NO_EXPAT if you do not have expat installed. git-http-push is
-# not built, and you cannot push using http:// and https:// transports.
-#
-# Define EXPATDIR=/foo/bar if your expat header and library files are in
-# /foo/bar/include and /foo/bar/lib directories.
-AC_ARG_WITH(expat,
-AS_HELP_STRING([--with-expat],
-[support git-push using http:// and https:// transports via WebDAV (default is YES)])
-AS_HELP_STRING([], [ARG can be also prefix for expat library and headers]),
-GIT_PARSE_WITH(expat))
-#
-# Define NO_FINK if you are building on Darwin/Mac OS X, have Fink
-# installed in /sw, but don't want GIT to link against any libraries
-# installed there. If defined you may specify your own (or Fink's)
-# include directories and library directories by defining CFLAGS
-# and LDFLAGS appropriately.
-#
-# Define NO_DARWIN_PORTS if you are building on Darwin/Mac OS X,
-# have DarwinPorts installed in /opt/local, but don't want GIT to
-# link against any libraries installed there. If defined you may
-# specify your own (or DarwinPort's) include directories and
-# library directories by defining CFLAGS and LDFLAGS appropriately.
-#
-# Define NO_MMAP if you want to avoid mmap.
-#
-# Define NO_ICONV if your libc does not properly support iconv.
-AC_ARG_WITH(iconv,
-AS_HELP_STRING([--without-iconv],
-[if your architecture doesn't properly support iconv])
-AS_HELP_STRING([--with-iconv=PATH],
-[PATH is prefix for libiconv library and headers])
-AS_HELP_STRING([],
-[used only if you need linking with libiconv]),
-GIT_PARSE_WITH(iconv))
-
-## --enable-FEATURE[=ARG] and --disable-FEATURE
-#
-# Define USE_NSEC below if you want git to care about sub-second file mtimes
-# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
-# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely
-# randomly break unless your underlying filesystem supports those sub-second
-# times (my ext3 doesn't).
-#
-# Define USE_STDEV below if you want git to care about the underlying device
-# change being considered an inode change from the update-index perspective.
-
-
## Output files
AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"])
AC_OUTPUT
--
1.6.0.5
^ permalink raw reply related
* [PATCH] configure: wrap some library tests with GIT_STASH_FLAGS
From: Ben Walton @ 2009-03-12 19:20 UTC (permalink / raw)
To: git; +Cc: Ben Walton
In-Reply-To: <1236885612-22575-4-git-send-email-bwalton@artsci.utoronto.ca>
Libraries that can have user specificed base paths are wrapped with
GIT_STASH_FLAGS/GIT_UNSTASH_FLAGS to ensure that the proper versions
on the system are tested. This ensures, for example, that the zlib
tests for deflateUnbound are done with the version of zlib requested
by the user. This is most useful in the absence of good settings for
CPPFLAGS and/or LDFLAGS.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
configure.ac | 36 +++++++++++++++++++++++++++++++++++-
1 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 469c9a9..fe9d7eb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -315,33 +315,57 @@ AC_MSG_NOTICE([CHECKS for libraries])
#
# Define NO_OPENSSL environment variable if you do not have OpenSSL.
# Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).
+
+GIT_STASH_FLAGS($OPENSSLDIR)
+
AC_CHECK_LIB([crypto], [SHA1_Init],
[NEEDS_SSL_WITH_CRYPTO=],
[AC_CHECK_LIB([ssl], [SHA1_Init],
[NEEDS_SSL_WITH_CRYPTO=YesPlease
NEEDS_SSL_WITH_CRYPTO=],
[NO_OPENSSL=YesPlease])])
+
+GIT_UNSTASH_FLAGS($OPENSSLDIR)
+
AC_SUBST(NEEDS_SSL_WITH_CRYPTO)
AC_SUBST(NO_OPENSSL)
+
#
# Define NO_CURL if you do not have libcurl installed. git-http-pull and
# git-http-push are not built, and you cannot use http:// and https://
# transports.
+
+GIT_STASH_FLAGS($CURLDIR)
+
AC_CHECK_LIB([curl], [curl_global_init],
[NO_CURL=],
[NO_CURL=YesPlease])
+
+GIT_UNSTASH_FLAGS($CURLDIR)
+
AC_SUBST(NO_CURL)
+
#
# Define NO_EXPAT if you do not have expat installed. git-http-push is
# not built, and you cannot push using http:// and https:// transports.
+
+GIT_STASH_FLAGS($EXPATDIR)
+
AC_CHECK_LIB([expat], [XML_ParserCreate],
[NO_EXPAT=],
[NO_EXPAT=YesPlease])
+
+GIT_UNSTASH_FLAGS($EXPATDIR)
+
AC_SUBST(NO_EXPAT)
+
#
# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin and
# some Solaris installations).
# Define NO_ICONV if neither libc nor libiconv support iconv.
+
+GIT_STASH_FLAGS($ICONVDIR)
+
AC_DEFUN([ICONVTEST_SRC], [
#include <iconv.h>
@@ -365,11 +389,17 @@ AC_LINK_IFELSE(ICONVTEST_SRC,
[AC_MSG_RESULT([no])
NO_ICONV=YesPlease])
LIBS="$old_LIBS"])
+
+GIT_UNSTASH_FLAGS($ICONVDIR)
+
AC_SUBST(NEEDS_LIBICONV)
AC_SUBST(NO_ICONV)
-test -n "$NEEDS_LIBICONV" && LIBS="$LIBS -liconv"
+
#
# Define NO_DEFLATE_BOUND if deflateBound is missing from zlib.
+
+GIT_STASH_FLAGS($ZLIB_PATH)
+
AC_DEFUN([ZLIBTEST_SRC], [
#include <zlib.h>
@@ -387,7 +417,11 @@ AC_LINK_IFELSE(ZLIBTEST_SRC,
[AC_MSG_RESULT([no])
NO_DEFLATE_BOUND=yes])
LIBS="$old_LIBS"
+
+GIT_UNSTASH_FLAGS($ZLIB_PATH)
+
AC_SUBST(NO_DEFLATE_BOUND)
+
#
# Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
# Patrick Mauritz).
--
1.6.0.5
^ permalink raw reply related
* [PATCH] configure: asciidoc version test cleanup
From: Ben Walton @ 2009-03-12 19:20 UTC (permalink / raw)
To: git; +Cc: Ben Walton
In-Reply-To: <1236885612-22575-5-git-send-email-bwalton@artsci.utoronto.ca>
Redirect stderr to /dev/null instead of stdout. This discards warnings
generated by python 2.6 related to the reorganization of functions within
modules. The warnings were causing the version detection to break.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
configure.ac | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index fe9d7eb..f4b8e49 100644
--- a/configure.ac
+++ b/configure.ac
@@ -291,7 +291,7 @@ fi
AC_CHECK_PROGS(ASCIIDOC, [asciidoc])
if test -n "$ASCIIDOC"; then
AC_MSG_CHECKING([for asciidoc version])
- asciidoc_version=`$ASCIIDOC --version 2>&1`
+ asciidoc_version=`$ASCIIDOC --version 2>/dev/null`
case "${asciidoc_version}" in
asciidoc' '8*)
ASCIIDOC8=YesPlease
--
1.6.0.5
^ permalink raw reply related
* [PATCH] configure: add macros to stash FLAG variables
From: Ben Walton @ 2009-03-12 19:20 UTC (permalink / raw)
To: git; +Cc: Ben Walton
In-Reply-To: <1236885612-22575-3-git-send-email-bwalton@artsci.utoronto.ca>
Allow for quick stash/unstash of CPPFLAGS and LDFLAGS. Library tests
can now be easily bracketted with these macros to allow for values
set in user/site arguments.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
configure.ac | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 0bff480..469c9a9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -80,6 +80,32 @@ AC_DEFUN([GIT_CHECK_FUNC],[AC_CHECK_FUNC([$1],[
AC_SEARCH_LIBS([$1],,
[$2],[$3])
],[$3])])
+
+dnl
+dnl GIT_STASH_FLAGS(BASEPATH_VAR)
+dnl -----------------------------
+dnl Allow for easy stashing of LDFLAGS and CPPFLAGS before running
+dnl tests that may want to take user settings into account.
+AC_DEFUN([GIT_STASH_FLAGS],[
+if test -n "$1"; then
+ old_CPPFLAGS="$CPPFLAGS"
+ old_LDFLAGS="$LDFLAGS"
+ CPPFLAGS="-I$1/include $CPPFLAGS"
+ LDFLAGS="-L$1/$lib $LDFLAGS"
+fi
+])
+
+dnl
+dnl GIT_UNSTASH_FLAGS(BASEPATH_VAR)
+dnl -----------------------------
+dnl Restore the stashed *FLAGS values.
+AC_DEFUN([GIT_UNSTASH_FLAGS],[
+if test -n "$1"; then
+ CPPFLAGS="$old_CPPFLAGS"
+ LDFLAGS="$old_LDFLAGS"
+fi
+])
+
## Site configuration related to programs (before tests)
## --with-PACKAGE[=ARG] and --without-PACKAGE
#
--
1.6.0.5
^ permalink raw reply related
* [PATCH] configure: make iconv tests aware of user arguments
From: Ben Walton @ 2009-03-12 19:20 UTC (permalink / raw)
To: git; +Cc: Ben Walton
In-Reply-To: <1236885612-22575-6-git-send-email-bwalton@artsci.utoronto.ca>
--with-iconv is now taken into account when doing the tests for iconv.
If the user requests alternate handling for libiconv, the -liconv test
is run before the -lc test.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
configure.ac | 48 ++++++++++++++++++++++++++++++++++--------------
1 files changed, 34 insertions(+), 14 deletions(-)
diff --git a/configure.ac b/configure.ac
index f4b8e49..6fe4bfe 100644
--- a/configure.ac
+++ b/configure.ac
@@ -375,20 +375,35 @@ int main(void)
return 0;
}
])
-AC_MSG_CHECKING([for iconv in -lc])
-AC_LINK_IFELSE(ICONVTEST_SRC,
+
+if test -n "$ICONVDIR"; then
+ lib_order="-liconv -lc"
+else
+ lib_order="-lc -liconv"
+fi
+
+NO_ICONV=YesPlease
+
+for l in $lib_order; do
+ if test "$l" = "-liconv"; then
+ NEEDS_LIBICONV=YesPlease
+ else
+ NEEDS_LIBICONV=
+ fi
+
+ old_LIBS="$LIBS"
+ LIBS="$LIBS $l"
+ AC_MSG_CHECKING([for iconv in $l])
+ AC_LINK_IFELSE(ICONVTEST_SRC,
[AC_MSG_RESULT([yes])
- NEEDS_LIBICONV=],
- [AC_MSG_RESULT([no])
- old_LIBS="$LIBS"
- LIBS="$LIBS -liconv"
- AC_MSG_CHECKING([for iconv in -liconv])
- AC_LINK_IFELSE(ICONVTEST_SRC,
- [AC_MSG_RESULT([yes])
- NEEDS_LIBICONV=YesPlease],
- [AC_MSG_RESULT([no])
- NO_ICONV=YesPlease])
- LIBS="$old_LIBS"])
+ NO_ICONV=
+ break],
+ [AC_MSG_RESULT([no])])
+ LIBS="$old_LIBS"
+done
+
+#in case of break
+LIBS="$old_LIBS"
GIT_UNSTASH_FLAGS($ICONVDIR)
@@ -455,13 +470,18 @@ int main(void)
return 0;
}
]])
+
+GIT_STASH_FLAGS($ICONVDIR)
+
AC_MSG_CHECKING([for old iconv()])
AC_COMPILE_IFELSE(OLDICONVTEST_SRC,
[AC_MSG_RESULT([no])],
[AC_MSG_RESULT([yes])
OLD_ICONV=UnfortunatelyYes])
-AC_SUBST(OLD_ICONV)
+GIT_UNSTASH_FLAGS($ICONVDIR)
+
+AC_SUBST(OLD_ICONV)
## Checks for typedefs, structures, and compiler characteristics.
AC_MSG_NOTICE([CHECKS for typedefs, structures, and compiler characteristics])
--
1.6.0.5
^ permalink raw reply related
* [PATCH] configure: rework pthread handling to allow for user defined flags
From: Ben Walton @ 2009-03-12 19:20 UTC (permalink / raw)
To: git; +Cc: Ben Walton
In-Reply-To: <1236885612-22575-7-git-send-email-bwalton@artsci.utoronto.ca>
The tests for POSIX threads can now be controlled by the user with the
--enable-pthreads=FLAGS option. If this is set (to some value other
than yes or no), the value is passed to the compiler. Thread support
is based solely on the outcome of this test. The user may specify not
to use threading at all or to use the default tests (first -pthread
then -lpthread) by not specifying FLAGS when passing --enable-pthreads.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
configure.ac | 89 ++++++++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 74 insertions(+), 15 deletions(-)
diff --git a/configure.ac b/configure.ac
index 6fe4bfe..4e728bc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -127,6 +127,27 @@ if test -z "$lib"; then
lib=lib
fi
+AC_ARG_ENABLE([pthreads],
+ [AS_HELP_STRING([--enable-pthreads=FLAGS],
+ [FLAGS is the value to pass to the compiler to enable POSIX Threads.]
+ [The default if FLAGS is not specified is to try first -pthread]
+ [and then -lpthread.]
+ [--without-pthreads will disable threading.])],
+[
+if test "x$enableval" = "xyes"; then
+ AC_MSG_NOTICE([Will try -pthread then -lpthread to enable POSIX Threads])
+elif test "x$enableval" != "xno"; then
+ PTHREAD_CFLAGS=$enableval
+ AC_MSG_NOTICE([Setting '$PTHREAD_CFLAGS' as the FLAGS to enable POSIX Threads])
+else
+ AC_MSG_NOTICE([POSIX Threads will be disabled.])
+ NO_PTHREADS=YesPlease
+ USER_NOPTHREAD=1
+fi],
+[
+ AC_MSG_NOTICE([Will try -pthread then -lpthread to enable POSIX Threads.])
+])
+
## Site configuration (override autodetection)
## --with-PACKAGE[=ARG] and --without-PACKAGE
AC_MSG_NOTICE([CHECKS for site configuration])
@@ -672,23 +693,61 @@ AC_SUBST(NO_MKDTEMP)
#
# Define PTHREAD_LIBS to the linker flag used for Pthread support and define
# THREADED_DELTA_SEARCH if Pthreads are available.
-AC_LANG_CONFTEST([AC_LANG_PROGRAM(
- [[#include <pthread.h>]],
- [[pthread_mutex_t test_mutex;]]
-)])
-${CC} -pthread conftest.c -o conftest.o > /dev/null 2>&1
-if test $? -eq 0;then
- PTHREAD_LIBS="-pthread"
- THREADED_DELTA_SEARCH=YesPlease
+AC_DEFUN([PTHREADTEST_SRC], [
+#include <pthread.h>
+
+int main(void)
+{
+ pthread_mutex_t test_mutex;
+ return (0);
+}
+])
+
+dnl AC_LANG_CONFTEST([AC_LANG_PROGRAM(
+dnl [[#include <pthread.h>]],
+dnl [[pthread_mutex_t test_mutex;]]
+dnl )])
+
+NO_PTHREADS=UnfortunatelyYes
+THREADED_DELTA_SEARCH=
+PTHREAD_LIBS=
+
+if test -n "$USER_NOPTHREAD"; then
+ AC_MSG_NOTICE([Skipping POSIX Threads at user request.])
+# handle these separately since PTHREAD_CFLAGS could be '-lpthreads
+# -D_REENTRANT' or some such.
+elif test -z "$PTHREAD_CFLAGS"; then
+ for opt in -pthread -lpthread; do
+ old_CFLAGS="$CFLAGS"
+ CFLAGS="$opt $CFLAGS"
+ AC_MSG_CHECKING([Checking for POSIX Threads with '$opt'])
+ AC_LINK_IFELSE(PTHREADTEST_SRC,
+ [AC_MSG_RESULT([yes])
+ NO_PTHREADS=
+ PTHREAD_LIBS="$opt"
+ THREADED_DELTA_SEARCH=YesPlease
+ break
+ ],
+ [AC_MSG_RESULT([no])])
+ CFLAGS="$old_CFLAGS"
+ done
else
- ${CC} -lpthread conftest.c -o conftest.o > /dev/null 2>&1
- if test $? -eq 0;then
- PTHREAD_LIBS="-lpthread"
- THREADED_DELTA_SEARCH=YesPlease
- else
- NO_PTHREADS=UnfortunatelyYes
- fi
+ old_CFLAGS="$CFLAGS"
+ CFLAGS="$PTHREAD_CFLAGS $CFLAGS"
+ AC_MSG_CHECKING([Checking for POSIX Threads with '$PTHREAD_CFLAGS'])
+ AC_LINK_IFELSE(PTHREADTEST_SRC,
+ [AC_MSG_RESULT([yes])
+ NO_PTHREADS=
+ PTHREAD_LIBS="$PTHREAD_CFLAGS"
+ THREADED_DELTA_SEARCH=YesPlease
+ ],
+ [AC_MSG_RESULT([no])])
+
+ CFLAGS="$old_CFLAGS"
fi
+
+CFLAGS="$old_CFLAGS"
+
AC_SUBST(PTHREAD_LIBS)
AC_SUBST(NO_PTHREADS)
AC_SUBST(THREADED_DELTA_SEARCH)
--
1.6.0.5
^ permalink raw reply related
* [PATCH] configure: ensure settings from user are also usable in the script
From: Ben Walton @ 2009-03-12 19:20 UTC (permalink / raw)
To: git; +Cc: Ben Walton
In-Reply-To: <1236885612-22575-1-git-send-email-bwalton@artsci.utoronto.ca>
Allow things set by the user (--with-lib, --with-iconv, etc) to set
variables for use by other parts of the script. Display values as
they're set.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
configure.ac | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 082a03d..0b314d7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -42,6 +42,8 @@ else \
if test "$withval" = "yes"; then \
AC_MSG_WARN([You should provide path for --with-$1=PATH]); \
else \
+ m4_toupper($1)_PATH=$withval; \
+ AC_MSG_NOTICE([Setting m4_toupper($1)_PATH to $withval]); \
GIT_CONF_APPEND_LINE(${PROGRAM}_PATH=$withval); \
fi; \
fi; \
@@ -61,6 +63,8 @@ elif test "$withval" = "yes"; then \
m4_toupper(NO_$1)=; \
else \
m4_toupper(NO_$1)=; \
+ m4_toupper($1)DIR=$withval; \
+ AC_MSG_NOTICE([Setting m4_toupper($1)DIR to $withval]); \
GIT_CONF_APPEND_LINE(${PACKAGE}DIR=$withval); \
fi \
])# GIT_PARSE_WITH
@@ -86,9 +90,16 @@ AC_ARG_WITH([lib],
[if test "$withval" = "no" || test "$withval" = "yes"; then \
AC_MSG_WARN([You should provide name for --with-lib=ARG]); \
else \
+ lib=$withval; \
+ AC_MSG_NOTICE([Setting lib to '$lib']); \
GIT_CONF_APPEND_LINE(lib=$withval); \
fi; \
],[])
+
+if test -z "$lib"; then
+ AC_MSG_NOTICE([Setting lib to 'lib' (the default)])
+ lib=lib
+fi
#
# Define SHELL_PATH to provide path to shell.
GIT_ARG_SET_PATH(shell)
--
1.6.0.5
^ permalink raw reply related
* Re: Google Summer of Code 2009: GIT
From: david @ 2009-03-12 19:29 UTC (permalink / raw)
To: saurabh gupta; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <ab9fa62a0903121200v73ec3522gcdebcd34122efc72@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4820 bytes --]
On Fri, 13 Mar 2009, saurabh gupta wrote:
> On Fri, Mar 13, 2009 at 12:23 AM, <david@lang.hm> wrote:
>> On Thu, 12 Mar 2009, saurabh gupta wrote:
>>
>>> On Thu, Mar 12, 2009 at 11:30 PM, <david@lang.hm> wrote:
>>>
>>>> On Thu, 12 Mar 2009, saurabh gupta wrote:
>>>>
>>>>>
>>>>> =>Merging of two xml files
>>>>>
>>>>> => existing merge driver (like xdl) is called which marks the
>>>>> conflicts points just like a normal text file.
>>>>>
>>>>> => the conflicted file can be read through a text terminal and
>>>>> conflicted lines can be seen.
>>>>>
>>>>> => suppose the xml file is from the domain of OO document. Then, a
>>>>> merge helper for OO xml type file is called which takes input as the
>>>>> conflicted file produced by xdl driver.
>>>>>
>>>>> => The merge helper creates a new file or changes the input file to
>>>>> make it a valid xml file so that it can be opened in OpenOffice and
>>>>> user can see the markers like "====" or "<<<<<" in an appropriate
>>>>> manner and can resolve the file manually.
>>>>>
>>>>
>>>> with XML files it's possible to be symanticly identical, but not
>>>> identical
>>>> as far as a text merge driver is concerned.
>>>>
>> <SNIPB>
>>>
>>> you are right. For xml merging, what I am thinking is to create the
>>> algorithm based on the document object model. Inside, any tag, all tags
>>> are
>>> compared only in terms of content and not in order. But again, this
>>> ordering
>>> option can be given to the user. If the user wants order to matter, then a
>>> conflict will be resulted if order mismatches.
>>
>> right.
>>
>>> But other issue is regarding the display of conflict markers. Either
>>> conflict markers should be put in xml format or like text merger. This is
>>> the main project idea for GSoC 2009.
>>
>> this may need to be a configurable option, but I suspect that we could get
>> away with always using something in XML format. exactly what the markers are
>> needs to be configurable (the markers for OO will not be the same as for SVG
>> for example)
>
> yeah.
>
>> building a library of 'this works especially well for this app' markers is
>> something that needs to be started as part of the GSOC project, but possibly
>> only far enough to show a couple of examples and have confidence that the
>> tool is configurable enough.
>>
>
> I think picking up some formats and then building libraries above that
> is needed. In some sense, I talked about the plug-in architecture
> also. Can;t it be possible that for different applications (like OO or
> SVG), different merge helper plugins are created which can be
> integrated with it. Or speaking in other words, instead of plug-ins
> now, libraries for merge helpers for different applications are
> created.
defining terminology that was mentioned before
merge drivers are run by git to do the merges and create the conflict
markers. git already has a 'plug-in architecture' for these drivers (you
can define file types and tell git to use a particular merge driver for
this file type)
merge helpers are run by the users if there is a conflict and make use of
the markers. depending on what you end up using for conflict markers, you
may not need to write a merge helper (for OO, if your conflict markers are
good enough you can use OO to resolve conflicts easily, no need for a new
tool)
with this terminology, you can't do merge helpers without doing the merge
drivers first (what does the helper look for as an indicator of a
conflict?)
I believe that there is a lot of potential for a configurable merge driver
to support many similar formats.
using the example of XML-based files, configurable options could include
1. is the file stored compressed or not
2. does the order of the tags matter
3. does whitespace matter
note: #2 and #3 may boil down to 'is this a document with XML markup, or
are the XML tags the primary content'
4. how is the conflict marked
4a. wrap the conflicting tags in a set of tags that look like _
4b. if the conflict is in the content, not the tags, modify it similar to
what we do with text today.
note: this still requires the new driver to decide if there is a
conflict or not
4c. other (potentially including calling out to other code for more
drastic restructuring)
with a merge driver along these lines you can handle many different types
of XML documents.
with SVG you may be able to put the offending tags in different layers
with OO you may be able to put in tags that indicate a merge conflict in a
way that OO will directly handle
etc.
in many cases you may not even need to create a merge helper or library
for other software you use. you just need to figure out what sort of
manipulation would need to be done to to file to mark the conflict in a
way that existing applications can understand.
David Lang
^ permalink raw reply
* RE: newb: Given a commit id, find which branches have it as an ancestor
From: Kelly F. Hickel @ 2009-03-12 19:38 UTC (permalink / raw)
To: j.sixt; +Cc: git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302E0F9B2@emailmn.mqsoftware.com>
> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
> Behalf Of Johannes Sixt
> Sent: Thursday, March 12, 2009 10:38 AM
> To: Kelly F. Hickel
> $ git branch -a --contains the-sha1
>
> -- Hannes
>
Thanks, that looks like a really useful command.
Unfortunately, in this case it didn't print anything out (neither did
"git branch -r -a sha1").
What I'm beginning to suspect is that all the commits that should have
gone to master went to some unnamed branch.
Is that reasonable/possible/likely? This commit has a full ancestry,
but doesn't appear to be on any branch.
In the above question there's an assumption that if a branch exists
without a name, then git branch -a --contains wouldn't print anything
out, is that correct?
Thanks,
Kelly
^ 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