* Re: Transparently encrypt repository contents with GPG
From: Michael J Gruber @ 2009-03-13 10:46 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Matthias Nothhaft, git
In-Reply-To: <fabb9a1e0903121434u4a3d71bdi6277071f54557a7e@mail.gmail.com>
Sverre Rabbelier venit, vidit, dixit 12.03.2009 22:34:
> Heya,
>
> On Thu, Mar 12, 2009 at 22:19, Matthias Nothhaft
> <matthias.nothhaft@googlemail.com> > What I need is a way to
> automatically modify each file
>>
>> a) before it is written in the repository
>> b) after it is read from the repository
>
> Have a look at smudging, you might not need to touch the git source
> code at all ;).
>
And people asked me not to be cryptic... even though the OP explicitely
asked for encryption, of course ;)
"git help attributes" may help: look for filter and set attributes and
config (filter.$name.{clean,smudge}) accordingly. smudge should probably
decrypt, clean should encrypt.
BTW: Why not use an encrypted file system? That way your work tree would
be encrypted also.
Cheers,
Michael
^ permalink raw reply
* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Michael J Gruber @ 2009-03-13 10:29 UTC (permalink / raw)
To: Todd Zullinger; +Cc: Alejandro Riveira, git, Jay Soffian, Tom Holaday
In-Reply-To: <20090312170931.GB19175@inocybe.teonanacatl.org>
Todd Zullinger venit, vidit, dixit 12.03.2009 18:09:
> 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 was unclear, but I meant forgetting to set DOCB... But:
> 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 hadn't noticed that yet (neither the effect nor the report). So, you
kept it unset intentionally and for a good reason. Please accept my apology!
>
> 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.
So the easy solution is out again, quite a pitty. The problem occurs on
F10 as well as F11/rawhide, right?
On a related issue: Does anybody know which asciidoc versions need
asciidoc7compatible to be set? 8.2.5 and above certainly don't, so we
should not advise using it. asciidoc's hg repo doesn't go back much more
(the initial revision does not need it either), and I haven't dug for
their earlier history yet.
Michael J Gruber
^ permalink raw reply
* Re: [PATCH JGIT] Add "compare with Git Index" action.
From: Yann Simon @ 2009-03-13 10:28 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn O. Pearce, git
In-Reply-To: <200903110022.53854.robin.rosenberg.lists@dewire.com>
2009/3/11 Robin Rosenberg <robin.rosenberg.lists@dewire.com>:
> Saving works, but the diff regions aren't updated on save.
Sorry, I do not understand. Can you explain me more?
> When there is a diff
> this would give us the partial staging similar to git gui, if only (not your fault) the
> commit dialog would allow us to make a distinction between changes in the
> workdir and the index.
Yes, I know that this patch is not very usefull for the moment.
I was more looking for a review as an inclusion.
And you found one bug. Thank you for that!
--
yann
^ permalink raw reply
* Re: Generalised bisection
From: Ealdwulf Wuffinga @ 2009-03-13 10:00 UTC (permalink / raw)
To: Steven Tweed
Cc: Johannes Schindelin, John Tapsell, Christian Couder, Git List
In-Reply-To: <d9c1caea0903121102y5452603fua0e7a1b82e121b01@mail.gmail.com>
On Thu, Mar 12, 2009 at 6:02 PM, Steven Tweed <orthochronous@gmail.com> wrote:
> 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.)
Hmm, I'll have to think about that one.
Ealdwulf
^ permalink raw reply
* Re: [RFC/PATCH] git push usability improvements and default change
From: John Tapsell @ 2009-03-13 10:07 UTC (permalink / raw)
To: Miles Bader
Cc: Finn Arne Gangstad, ', Nanako Shiraishi, Junio C Hamano, git
In-Reply-To: <buohc1xddxa.fsf@dhlpc061.dev.necel.com>
Hi,
What's the status of these patches? Will be commited?
John
2009/3/13 Miles Bader <miles@gnu.org>:
> Finn Arne Gangstad <finnag@pvv.org> writes:
>>> Presumably the push --track option would be used with an explicit branch
>>> name given to push anyway, right? Then it can use that info to set up
>>> the tracking flexibly (and with sane defaults).
>>>
>>> E.g.,, simple case:
>>> git push --track SOME_REMOTE BRANCH_NAME
>>>
>>> complex case:
>>> git push --track SOME_REMOTE MY-BRANCH:REMOTE-BRANCH
>>
>> Yes, git push --track ... would typically do the same thing to the
>> config as git checkout -b MY-BRANCH SOME_REMOTE/REMOTE-BRANCH, which
>> is enough for push --tracking to do its thing.
>>
>> I am not sure if you mean that git push --track could do something
>> extra to make --tracking unecessary for git push, currently it cannot
>> do that since the push configuration is per remote, not per branch.
>
> Hmm, now I'm confused... I was just thinking about --track, but am not
> sure what --tracking is ... need to go grovel past posts...
>
> -Miles
>
> --
> Happiness, n. An agreeable sensation arising from contemplating the misery of
> another.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Generalised bisection
From: Ealdwulf Wuffinga @ 2009-03-13 9:58 UTC (permalink / raw)
To: John Tapsell; +Cc: Christian Couder, Git List, Ingo Molnar
In-Reply-To: <43d8ce650903112345x3d40b70ap7e4c0f8c7d0b6069@mail.gmail.com>
On Thu, Mar 12, 2009 at 6:45 AM, John Tapsell <johnflux@gmail.com> wrote:
> 2009/3/11 Ealdwulf Wuffinga <ealdwulf@googlemail.com>:
>> On Wed, Mar 11, 2009 at 9:35 AM, John Tapsell <johnflux@gmail.com> wrote:
>> 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?
I'll have to reply to this later when I have more time. However, there
is a (rather verbose)
file in the doc directory which describes them - in texmacs format,
but I've just uploaded
a pdf version as well. It is BayesianSearch_Debugging.pdf. The
description of this code starts in
section 2.2 (since I wrote that, I have generalised it to the DAG case
as in git).
> A little bit of math trickery helps here :-)
>
> y = x^b
>
> log(y) = log(x^b) = b * log(x)
> e^log(y) = e^(b log(x))
>
> y = exp(b * log(x))
>
> So as long as you have 'exp' and 'log' functions, you can raise x to
> the power of b, even if b is fractional.
Sadly gmp does not have log or exp. mpfr does, but it does not have a python
interface.
Alex
^ permalink raw reply
* Re: Not pushing all branches?
From: Peter Krefting @ 2009-03-13 9:44 UTC (permalink / raw)
To: Imran M Yousuf; +Cc: git
In-Reply-To: <7bfdc29a0903130112w17d40473s14a895d518dbf8ae@mail.gmail.com>
Imran M Yousuf:
> Just try -
> git push remote branch :)
That is what I do. Unfortunately, the times I forged to name the branch, it
pushes my master branch, which is different from the remote's, and I have to
go to the other repository and reset it manually...
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Rogan Dawes @ 2009-03-13 9:41 UTC (permalink / raw)
To: saurabh gupta; +Cc: david, Johannes Schindelin, git
In-Reply-To: <ab9fa62a0903121123v35004215hbb64f0ad65399d9f@mail.gmail.com>
saurabh gupta wrote:
>> 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.
On the XML topic, one last thing to keep in mind is the DTD/XSD which
governs the file.
Rogan
^ permalink raw reply
* Re: [RFC/PATCH] git push usability improvements and default change
From: Miles Bader @ 2009-03-13 8:28 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: ', Nanako Shiraishi, Junio C Hamano, git
In-Reply-To: <20090312122047.GA14157@pvv.org>
Finn Arne Gangstad <finnag@pvv.org> writes:
>> Presumably the push --track option would be used with an explicit branch
>> name given to push anyway, right? Then it can use that info to set up
>> the tracking flexibly (and with sane defaults).
>>
>> E.g.,, simple case:
>> git push --track SOME_REMOTE BRANCH_NAME
>>
>> complex case:
>> git push --track SOME_REMOTE MY-BRANCH:REMOTE-BRANCH
>
> Yes, git push --track ... would typically do the same thing to the
> config as git checkout -b MY-BRANCH SOME_REMOTE/REMOTE-BRANCH, which
> is enough for push --tracking to do its thing.
>
> I am not sure if you mean that git push --track could do something
> extra to make --tracking unecessary for git push, currently it cannot
> do that since the push configuration is per remote, not per branch.
Hmm, now I'm confused... I was just thinking about --track, but am not
sure what --tracking is ... need to go grovel past posts...
-Miles
--
Happiness, n. An agreeable sensation arising from contemplating the misery of
another.
^ permalink raw reply
* Re: Not pushing all branches?
From: John Tapsell @ 2009-03-13 8:25 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0903130846410.17450@perkele.intern.softwolves.pp.se>
2009/3/13 Peter Krefting <peter@softwolves.pp.se>:
> Hi!
>
> Doing "git push remote" pushes all my local branches by default. Is there a
> way to set it to *not* do that, and (for this particular remote repository)
> just push the current branch?
> Or failing that, not allow me to run "git
> push" without specifying a branch?
I've been pushing for this behaviour, and there was a patch a few days
ago to do this. I'm not sure if it is/will be committed.
John Tapsell
^ permalink raw reply
* (unknown)
From: Werner Riener @ 2009-03-13 8:21 UTC (permalink / raw)
To: git
subscribe
--
Werner Riener
Generalsekretär des
Aikikai Verband Österreichischer Aikido-Schulen
Tel: +43-0699-101 32 940
Email: riener_w@gmx.net
URI: http://www.aikikai.at
http://home.pages.at/werrie/
Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur
17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
^ permalink raw reply
* Re: Deleting a submodule
From: Alex Riesen @ 2009-03-13 8:14 UTC (permalink / raw)
To: Pedro Melo; +Cc: Git Mailinglist
In-Reply-To: <20BA928D-7133-40E7-AB01-466F509F002C@simplicidade.org>
2009/3/12 Pedro Melo <melo@simplicidade.org>:
> 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.
git rm --cached path/to/submodule
git commit -m'Submodule path/to/submodule removed'
^ permalink raw reply
* Re: Not pushing all branches?
From: Imran M Yousuf @ 2009-03-13 8:12 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0903130846410.17450@perkele.intern.softwolves.pp.se>
On Fri, Mar 13, 2009 at 1:48 PM, Peter Krefting <peter@softwolves.pp.se> wrote:
> Hi!
>
> Doing "git push remote" pushes all my local branches by default. Is there a
> way to set it to *not* do that, and (for this particular remote repository)
> just push the current branch? Or failing that, not allow me to run "git
> push" without specifying a branch?
Just try -
git push remote branch :)
>
> The git-config manual page leads me to believe that I should recofigure
> "remote.<name>.push", but it points me to the "refspec" spec on git-push,
> which is a tad cryptic.
>
> --
> \\// Peter - http://www.softwolves.pp.se/
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Blog: http://imyousuf-tech.blogs.smartitengineering.com/
Mobile: +880-1711402557
^ permalink raw reply
* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
From: Daniel Stenberg @ 2009-03-13 7:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Ralphson, Mike Gaffney, git
In-Reply-To: <7vsklihsti.fsf@gitster.siamese.dyndns.org>
On Thu, 12 Mar 2009, Junio C Hamano wrote:
> http://curl.haxx.se/libcurl/c/curl_easy_setopt.html seems to say "added in
> 7.X.Y" for some options but does say when CURLOPT_USERPWD was added, so I am
> assuming it was available even in very early versions...
Yes it was.
Driven by use cases such as this, I also recently produced the
"symbols-in-versions" document in the libcurl tree which should help apps to
know what should works when:
http://cool.haxx.se/cvs.cgi/curl/docs/libcurl/symbols-in-versions?rev=HEAD&content-type=text/vnd.viewcvs-markup
--
/ daniel.haxx.se
^ permalink raw reply
* Not pushing all branches?
From: Peter Krefting @ 2009-03-13 7:48 UTC (permalink / raw)
To: git
Hi!
Doing "git push remote" pushes all my local branches by default. Is there a
way to set it to *not* do that, and (for this particular remote repository)
just push the current branch? Or failing that, not allow me to run "git
push" without specifying a branch?
The git-config manual page leads me to believe that I should recofigure
"remote.<name>.push", but it points me to the "refspec" spec on git-push,
which is a tad cryptic.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Rebasing local patches
From: Nicolas Morey-Chaisemartin @ 2009-03-13 7:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git@vger.kernel.org
In-Reply-To: <alpine.DEB.1.00.0903071229220.10279@pacific.mpi-cbg.de>
>> I noticed that when the branch was rebased on the centralized and repo
>> and origin/our_patches is up-to-date in mine.
>>
>> If I checkout another branch and then ckecout our_branches, I got a
>> message telling my our_patches and the one from the server have diverged
>> (or you are two commits behind...).
>>
>> How can you get this info directly without leaving/rejoining your
>> branch?
>
> It is also part of "git status"' output.
Is there some option to just get the status of HEAD against tracked branch and not the index status?
I guess I could do an alias but an option would be nicer ;)
Nicolas
^ permalink raw reply
* Re: newb: Given a commit id, find which branches have it as an ancestor
From: Junio C Hamano @ 2009-03-13 7:37 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Kelly F. Hickel, git
In-Reply-To: <49BA07E5.2080701@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Your best bet is perhaps that you create a branch at the commit
>
> $ git branch tmp-branch your_sha1
>
> so that the commits are not lost, then you cherry-pick them to master.
It could be that there are more commits that are built on top of the one
you are aware of. Finding unreachable commits from "git fsck --full"
might help you find them.
^ permalink raw reply
* Re: newb: Given a commit id, find which branches have it as an ancestor
From: Johannes Sixt @ 2009-03-13 7:14 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302E0F9BA@emailmn.mqsoftware.com>
Kelly F. Hickel schrieb:
>> 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?
Correct.
Your best bet is perhaps that you create a branch at the commit
$ git branch tmp-branch your_sha1
so that the commits are not lost, then you cherry-pick them to master.
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/7] strbuf: add "include_delim" parameter to "strbuf_split"
From: Junio C Hamano @ 2009-03-13 7:06 UTC (permalink / raw)
To: Christian Couder
Cc: Nanako Shiraishi, git, Ingo Molnar, John Tapsell,
Johannes Schindelin, Pierre Habouzit
In-Reply-To: <200903130702.01039.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
>> Also comparing this with Perl/Python split() forgets that you are working
>> in C, where truncating an existing string is quite cheap (just assign
>> '\0'). There is a different trade-off to be made in these language
>> environments.
>
> Sorry but I think the goal of the strbuf API is to be quite high level, so I
> think comparing this with Perl/Python is ok.
I think you are mistaken again.
The highlevel-ness of strbuf holds true only while you live in the strbuf
world, but you should consider what happens when its end product finally
gets used in the calling function written in C. It will be a good-old NUL
terminated string or just a chunk of memory with known length.
For a user written in C, it is far easier and cheaper to trim excess at
the end, especially when the length of the string is known (strbuf_detach
gives you the length of the string exactly for this reason) than having to
extend it (in order to recover the lost delimiter because the splitter
removed it). Trimming from the front is also cheap (just move the head
pointer and start consuming from the middle).
^ permalink raw reply
* Re: [PATCH 1/7] strbuf: add "include_delim" parameter to "strbuf_split"
From: Junio C Hamano @ 2009-03-13 6:53 UTC (permalink / raw)
To: Christian Couder
Cc: Nanako Shiraishi, git, Ingo Molnar, John Tapsell,
Johannes Schindelin, Pierre Habouzit
In-Reply-To: <200903130702.01039.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Aren't gets and fgets an example that having the choice to strip out the
> delimiter or not is good?
I consider it is an example that an earlier simplistic API (gets()) later
gets corrected when it is redone right (fgets()) with other changes like a
proper bounds check.
>> A more general
>> solution should be by default not to strip it, and I do not think your
>> new caller, if it were written correctly, needs stripping behaviour
>> either. That means there is no need for the "optionally strip" flag to
>> the function in order to support the rest of the series [*2*].
I also do not agree that you have to keep list of skip both in shell and
rev-list when you go the route I suggested. I think a separate bisect.c
you did is a good first step to make not just the bisect machinery but the
whole bisect command into a built-in, and even if we do not do the full
rewrite in C in one go, moving these "shell script reads from refs/bisect
only to feed the result to rev-list --bisect" pattern to "shell script
updates refs/bisect and let rev-list --bisect read from there" pattern
would be a good initial step. Oh, and I did not mean it only for "skip",
but also doing this for "good" and "bad" as well.
For example, you read "refs/bisect/skip-*" and keep that in $skip to:
- feed it to filter_skipped() which you are making built-in with this
series;
- feed it to check_good_are_ancestors_of_bad that in turn calls
check_merge_bases;
and its use is contained in bisect_next() alone. After this series is
done, we can move the logic in check_good_are... to bisect.c and you do
not have to read refs/bisect/skip-* in the shell anymore. IOW, we can
migrate away from the "shell reads from refs/bisect/ and feeds that to
rev-list --bisect" pattern incrementally.
^ permalink raw reply
* Re: [PATCH 1/7] strbuf: add "include_delim" parameter to "strbuf_split"
From: Christian Couder @ 2009-03-13 6:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nanako Shiraishi, git, Ingo Molnar, John Tapsell,
Johannes Schindelin, Pierre Habouzit
In-Reply-To: <7v1vt2j91x.fsf@gitster.siamese.dyndns.org>
Le vendredi 13 mars 2009, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > Yes, my patch does not do that, because I think including the delimiter
> > is a special case of the more general and useful behavior of not
> > including it.
>
> You got it backwards.
>
> With the way the returned string is used by the single caller that your
> patch adds (which splits at ","), I would agree that lack of delimiter
> allows the result to get used directly in the further processing.
>
> But even in that codepath, I have to say that it is just lazy programming
> that the caller does not postprocess the returned value from the splitter
> function. If it wants not just accept input such as "a,b,c" but also
> wants to tolerate things like "a, b, c", it will have to look at the
> resulting string, and ignoring the delimiter at the end becomes just a
> small part of the general clean-up process [*1*].
I think talking about "lazy programming" in this case is a bit strong,
because first "git rev-list --bisect-skip" is plumbing and will be used
mostly by porcelain and second because there are much more common shell
utilities that don't tolerate things like "a, b, c". Try using "cut"
with -f'1, 2' (instead of -f1,2) for example.
> Once you start allowing "split at one of these characters" and/or "split
> at delimiter that matches this pattern", you cannot just discard the
> delimiter if you want to support non-simplistic callers, because they
> would want to know what the delimiter was.
But I let non simplistic callers use "1" as the last parameter if they want
the delimiter. I just give one more way to use strbuf_split. I don't remove
anything.
> Stripping out the delimiter is the special case for simplistic callers
> (think "gets()" that strips, and "fgets()" that doesn't).
Aren't gets and fgets an example that having the choice to strip out the
delimiter or not is good?
> A more general
> solution should be by default not to strip it, and I do not think your
> new caller, if it were written correctly, needs stripping behaviour
> either. That means there is no need for the "optionally strip" flag to
> the function in order to support the rest of the series [*2*].
I think my patch 8/7, that I just sent, is a good solution and it still uses
the new behavior of strbuf_split introduced in 1/7.
> Also comparing this with Perl/Python split() forgets that you are working
> in C, where truncating an existing string is quite cheap (just assign
> '\0'). There is a different trade-off to be made in these language
> environments.
Sorry but I think the goal of the strbuf API is to be quite high level, so I
think comparing this with Perl/Python is ok.
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
From: Junio C Hamano @ 2009-03-13 5:53 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Mike Gaffney, git
In-Reply-To: <e2b179460903120153u5fdb58b6tf3027eea23673df0@mail.gmail.com>
Mike Ralphson <mike.ralphson@gmail.com> writes:
> Elsewhere we seem to protect use of CURL_NETRC_OPTIONAL by checking
> for LIBCURL_VERSION_NUM >= 0x070907. I have an ancient curl here
> (curl-7.9.3-2ssl) which doesn't seem to have this option, so building
> next is broken on AIX for me from this morning (c33976cb).
Yeah, I did this as "How about doing it this way without adding a band-aid
configuration options" demonstration, and meant to clean it up (rather,
meant to wait for the original submitter to clean-up) before moving it
forward, but I forgot. Sorry about that.
How does this look?
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html seems to say "added in
7.X.Y" for some options but does say when CURLOPT_USERPWD was added, so I
am assuming it was available even in very early versions...
-- >8 --
From 750d9305009a0f3fd14c0b5c5e62ae1eb2b18fda Mon Sep 17 00:00:00 2001
From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 12 Mar 2009 22:34:43 -0700
Subject: [PATCH] http.c: CURLOPT_NETRC_OPTIONAL is not available in ancient versions of cURL
Besides, we have already called easy_setopt with the option before coming
to this function if it was available, so there is no need to repeat it
here.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
http.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/http.c b/http.c
index b8f947e..2fc55d6 100644
--- a/http.c
+++ b/http.c
@@ -138,9 +138,7 @@ static int http_options(const char *var, const char *value, void *cb)
static void init_curl_http_auth(CURL *result)
{
- if (!user_name)
- curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
- else {
+ if (user_name) {
struct strbuf up = STRBUF_INIT;
if (!user_pass)
user_pass = xstrdup(getpass("Password: "));
--
1.6.2.249.g770a0
^ permalink raw reply related
* Re: kha/{safe,experimental} updated
From: Karl Hasselström @ 2009-03-13 5:33 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, gustav, git
The following changes since commit 594aa463c1852f77b89bdce853da4e7052d7cdd2:
Karl Hasselström (1):
Rename "stg coalesce" to "stg squash"
are available in the git repository at:
git://repo.or.cz/stgit/kha.git safe
David Kågedal (1):
stgit.el: Don't steal bindings of C-p and C-n
Gustav Hållberg (7):
stgit.el: Manually draw/erase the mark in stgit-{add,remove}-mark
stgit.el: Clarify documentation of stgit-capture-output
stgit.el: Add "M" for stgit-move-patches
stgit.el: Run 'git show' with -M to detect renames when showing entire patch
stgit.el: Break out stgit-sort-patches to a separate function for future reuse
stgit.el: Sort patches correctly before merging them in stgit-squash
stgit.el: Handle errors in first phase of stgit squash
Karl Hasselström (3):
stg squash: Improve documentation
Documentation: Ignore generated .xml files
Documentation: Rename link macros
Documentation/.gitignore | 1 +
Documentation/asciidoc.conf | 19 +++---
Documentation/stg.txt | 10 ++--
Documentation/tutorial.txt | 116 +++++++++++++++++-----------------
contrib/stgit.el | 148 +++++++++++++++++++++++++++++++++----------
stgit/commands/__init__.py | 2 +-
stgit/commands/branch.py | 6 +-
stgit/commands/clone.py | 6 +-
stgit/commands/new.py | 2 +-
stgit/commands/sink.py | 2 +-
stgit/commands/squash.py | 20 +++++-
11 files changed, 211 insertions(+), 121 deletions(-)
-+-
The following changes since commit d7af287e9818dd12a8b7d9c7c217d791861435af:
David Kågedal (1):
stgit.el: Don't steal bindings of C-p and C-n
are available in the git repository at:
git://repo.or.cz/stgit/kha.git experimental
Karl Hasselström (2):
Read several objects at once with git cat-file --batch
Diff several trees at once with git diff-tree --stdin
INSTALL | 5 +++-
stgit/lib/git.py | 79 +++++++++++++++++++++++++++++++++++++++++++++++++----
stgit/run.py | 19 +++++++++++++
3 files changed, 96 insertions(+), 7 deletions(-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH 8/7] rev-list: make "--bisect-skip" read skipped revisions from stdin
From: Christian Couder @ 2009-03-13 5:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ingo Molnar, John Tapsell, Johannes Schindelin
Previously, skipped revisions should be passed like this:
$ git rev-list --bisect-skip=<rev1>,<rev2>,<rev3> ...
but there could be problems on systems where there is a tight limit
on command line lenght.
As the "--bisect-skip" option will be mostly used by porcelain
commands, and as the current "git-bisect.sh" porcelain does not use
stdin to pass good or bad revisions, it is acceptable to have
"--bisect-skip" now read skipped commits from stdin.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
bisect-skip.c | 19 +++++++++++++++++--
bisect.h | 2 +-
builtin-rev-list.c | 11 ++++++++---
git-bisect.sh | 4 ++--
4 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/bisect-skip.c b/bisect-skip.c
index 789ee09..079e787 100644
--- a/bisect-skip.c
+++ b/bisect-skip.c
@@ -7,7 +7,8 @@ static unsigned char (*skipped_sha1)[20];
static int skipped_sha1_nr;
static int skipped_sha1_alloc;
-void register_skipped(const char *skipped)
+
+static void register_skipped(const char *skipped)
{
struct strbuf sb, **list, **it, *cur;
int len = strlen(skipped);
@@ -15,7 +16,7 @@ void register_skipped(const char *skipped)
strbuf_init(&sb, len);
strbuf_add(&sb, skipped, len);
- list = strbuf_split(&sb, ',', 0);
+ list = strbuf_split(&sb, ' ', 0);
for (it = list; (cur = *it); it++) {
ALLOC_GROW(skipped_sha1, skipped_sha1_nr + 1,
@@ -28,6 +29,20 @@ void register_skipped(const char *skipped)
strbuf_release(&sb);
}
+void read_skipped_revisions_from_stdin(void)
+{
+ char line[1000];
+
+ while (fgets(line, sizeof(line), stdin) != NULL) {
+ int len = strlen(line);
+ if (len && line[len - 1] == '\n')
+ line[--len] = '\0';
+ if (!len)
+ break;
+ register_skipped(line);
+ }
+}
+
int skipped_nr(void)
{
return skipped_sha1_nr;
diff --git a/bisect.h b/bisect.h
index ff9c781..c41b568 100644
--- a/bisect.h
+++ b/bisect.h
@@ -1,7 +1,7 @@
#ifndef BISECT_H
#define BISECT_H
-void register_skipped(const char *skipped);
+void read_skipped_revisions_from_stdin(void);
int skipped_nr(void);
struct commit_list *filter_skipped(struct commit_list *list,
struct commit_list **tried,
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 4af70d7..bf16197 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -334,16 +334,21 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
bisect_show_vars = 1;
continue;
}
- if (!prefixcmp(arg, "--bisect-skip=")) {
+ if (!prefixcmp(arg, "--bisect-skip")) {
bisect_list = 1;
bisect_show_vars = 1;
- bisect_skip = 1;
- register_skipped(arg + 14);
+ if (bisect_skip++)
+ die("--bisect-skip given twice?");
+ if (read_from_stdin)
+ die("--bisect-skip cannot work with --stdin");
+ read_skipped_revisions_from_stdin();
continue;
}
if (!strcmp(arg, "--stdin")) {
if (read_from_stdin++)
die("--stdin given twice?");
+ if (bisect_skip)
+ die("--stdin cannot work with --bisect-skip");
read_revisions_from_stdin(&revs);
continue;
}
diff --git a/git-bisect.sh b/git-bisect.sh
index 31e7cff..da3c077 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -429,8 +429,8 @@ bisect_next() {
test "$?" -eq "1" && return
# Get bisection information
- skip=$(echo $skip | tr ' ' ',')
- eval="git rev-list --bisect-skip=$skip $good $bad --" &&
+ eval="echo $skip | tr ' ' '\012'" &&
+ eval="$eval | git rev-list --bisect-skip $good $bad --" &&
eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
eval=$(eval_and_string_together "$eval") &&
eval "$eval" || exit
--
1.6.2.84.gcd0b4.dirty
^ permalink raw reply related
* Re: [PATCH 7/7] bisect: use "rev-list --bisect-skip" and remove "filter_skipped" function
From: Christian Couder @ 2009-03-13 5:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ingo Molnar, John Tapsell, Johannes Schindelin
In-Reply-To: <7viqmfkuyt.fsf@gitster.siamese.dyndns.org>
Le jeudi 12 mars 2009, Junio C Hamano a écrit :
> These (except for the first one which I do not think belongs to the
> series) look more or less straightforward changes.
I added the first one to the series because I use strbuf_split with the new
behavior in the series.
> One worrysome thing that the series introduces is that you used to hold
> all the skipped ones in a shell variable $skip and fed it internally to
> the filter_skipped shell function, but now you give them from the command
> line. When you have tons of skipped commits, this can easily bust the
> command line length limit on some system, while the shell may still be Ok
> with such a large string variable.
Yeah. I will send a patch (8/7) that makes "git rev-list" read the skipped
commits from stdin when "--bisect-skip" is passed, and that changes
git-bisect.sh accordingly. If this behavior is ok, then I can reorder the
series if you want.
> Because the operations in rev-list related to bisect are very closely
> tied to the implementation of the bisect Porcelain anyway, I am wondering
> if it makes more sense to just feed the name of the toplevel refname
> hierarchy, i.e. "refs/bisect", as a rev-list parameter and let rev-list
> enumerate what is skipped, which commits are good and which ones are bad.
Yeah that could be an improvement, but then the enumeration will happen once
in git-bisect.sh and once in "git rev-list", instead of just once in
git-bisect.sh. And we also have to deal with the other command line
arguments passed to "git rev-list" on top of the enumerated commits from
the refname hierachy, so I don't think that would be very consistent.
But perhaps we could create a new "git rev-bisect" builtin plumbing command
that could do that. And later we could improve this new command so that it
checks merge bases (like what is done in bisect_next in git-bisect.sh) and
so that it also checks out the source code of the new revision to be tested
(like what is done in bisect_checkout in git-bisect.sh).
Thanks,
Christian.
^ 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