* Re: [PATCH] Add a simple option parser.
From: Kristian Høgsberg @ 2007-10-04 14:57 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, gitster
In-Reply-To: <20071003231145.GF28188@artemis.corp>
On Thu, 2007-10-04 at 01:11 +0200, Pierre Habouzit wrote:
> On Wed, Oct 03, 2007 at 09:45:01PM +0000, Kristian Høgsberg wrote:
> > The option parser takes argc, argv, an array of struct option
> > and a usage string. Each of the struct option elements in the array
> > describes a valid option, its type and a pointer to the location where the
> > value is written. The entry point is parse_options(), which scans through
> > the given argv, and matches each option there against the list of valid
> > options. During the scan, argv is rewritten to only contain the
> > non-option command line arguments and the number of these is returned.
>
> if we are going in that direction (and I believe it's a good one), we
> should be sure that the model fits with other commands as well. And as I
> said on IRC, I believe the most "horrible" (as in complex) option parser
> in git is the one from git-grep.
>
> A migration of git-grep on that API should be tried first. If this
> works well enough, I believe that the rest of the git commands will be
> migrated easily enough. (with maybe small addition to parse-option.[hc]
> but the hardcore things should have been met with git-grep already I
> think).
I'm not sure - we can go with the current proposal and add new options
types and probably the callback option type I suggested as we go. I
don't want to block builtin-commit on figuring out what the perfect
option parser should look like and what I sent out earlier work for
commit. I think the way you handled the strbuf rewrites worked pretty
well; extending and rewriting the API as you put it to use in more and
more places. We can do the same thing with parse_options().
cheers,
Kristian
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary (long)
From: Jakub Narebski @ 2007-10-04 14:59 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: git
In-Reply-To: <CDD8E66B-44E0-4258-A3CC-4E48BC58FD2F@lrde.epita.fr>
On 10/4/07, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
> Hi Jakub,
> nice work you've done there. Well done!
Half done. But thanks.
By the way, I'd put final data from the survey as an attachement at
http://git.or.cz/gitwiki/GitSurvey2007
Currently there is data I used to generate this summary, in CSV format.
I have used horrible Perl script to tabularize free-form questions, removing
comments etc., and to generate tables in this summary.
> On Oct 4, 2007, at 11:12 AM, Jakub Narebski wrote:
>
> > Note that Git is GPLv2, and it will probably stay that forever, so you
> > are _free_ to start a commercial support scheme for Git, but others
> > are free not to choose it. This question is to get to know if there is
> > sufficient demand for commercial Git support for it to be viable.
>
> Once again (AFAIR this was already raised during one of the previous
> summary) what's the link between GPLv2 and commercial support? You
> seem to imply that because Git won't move to GPLv3, it's a good thing
> for potential paid support, or something. I don't quite see how
> GPLvX comes into play with commercial support. I'm not a license
> expert though.
The only link between GPL and commercial support is that GPL does not
prohibit commercial support (like noncommercial-free licenses for example),
and that having commercial support doesn't mean that license would change
to proprietary (it cannot).
--
Jakub Narebski
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: David Kastrup @ 2007-10-04 14:47 UTC (permalink / raw)
To: git
In-Reply-To: <7vhcl79c4l.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * --index means work work tree through the index. Once you get
> git, this is natural as you would not interact with files in
> the work tree that is not known to the index.
>
> * --cached means work only on the cached information in index.
That is a rather shaky relation.
> Giving them synonyms without deprecation is a viable option, if
> necessary. I do not however see the need yet. A few people who
> haven't learned the lingo of the land yet can worry about possible
> confusion, but I do not think that "worry" itself does not count as
> real need.
The "lingo of the land" as documented in the manuals no longer uses
the term "cache" or "cached" as something with an official meaning.
So the current state of affairs does not really look overly convincing
with regard to consistency.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Add a simple option parser.
From: Pierre Habouzit @ 2007-10-04 15:15 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git, gitster
In-Reply-To: <1191509878.29379.2.camel@hinata.boston.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2510 bytes --]
On Thu, Oct 04, 2007 at 02:57:58PM +0000, Kristian Høgsberg wrote:
>
> On Thu, 2007-10-04 at 01:11 +0200, Pierre Habouzit wrote:
> > On Wed, Oct 03, 2007 at 09:45:01PM +0000, Kristian Høgsberg wrote:
> > > The option parser takes argc, argv, an array of struct option
> > > and a usage string. Each of the struct option elements in the array
> > > describes a valid option, its type and a pointer to the location where the
> > > value is written. The entry point is parse_options(), which scans through
> > > the given argv, and matches each option there against the list of valid
> > > options. During the scan, argv is rewritten to only contain the
> > > non-option command line arguments and the number of these is returned.
> >
> > if we are going in that direction (and I believe it's a good one), we
> > should be sure that the model fits with other commands as well. And as I
> > said on IRC, I believe the most "horrible" (as in complex) option parser
> > in git is the one from git-grep.
> >
> > A migration of git-grep on that API should be tried first. If this
> > works well enough, I believe that the rest of the git commands will be
> > migrated easily enough. (with maybe small addition to parse-option.[hc]
> > but the hardcore things should have been met with git-grep already I
> > think).
>
> I'm not sure - we can go with the current proposal and add new options
> types and probably the callback option type I suggested as we go. I
> don't want to block builtin-commit on figuring out what the perfect
> option parser should look like and what I sent out earlier work for
> commit. I think the way you handled the strbuf rewrites worked pretty
> well; extending and rewriting the API as you put it to use in more and
> more places. We can do the same thing with parse_options().
Of course we can do that, or junio said that some people talked about
popt some time ago. I understand that you don't want to block the
git-commit work, but doing things right from the beginning is often a
big win on the long term.
I don't know popt, and I don't know if it has sufficient expressivity.
For sure I don't like getopt_long APIs at all, so if popt is as
cumbersome, rolling our own based on the current parse_options you
propose is probably a good choice.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH/RFT] cvsserver: only allow checkout of branches
From: Johannes Schindelin @ 2007-10-04 15:29 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: Frank Lichtenheld, Martin Langhoff, git
In-Reply-To: <200710041506.13154.wielemak@science.uva.nl>
It does not make sense to check out tags or "HEAD".
Noticed by Jan Wielemaker.
---
On Thu, 4 Oct 2007, Jan Wielemaker wrote:
> On Thursday 04 October 2007 14:56, Johannes Schindelin wrote:
>
> > Ah! Did you do "CVSROOT=:ext:blablub cvs co HEAD"?
>
> Yip ...
>
> > You should "co master". The branches in git are the modules
> > in cvs.
> >
> > HEAD is too volatile, you cannot make a proper module from it
> > (imagine for example "git checkout next" where "next" is a
> > branch, followed by "git checkout html", where "html" is
> > another branch).
>
> Ok. Pretty sure I got literal HEAD from one of the examples
> somewhere ... Or, I've been blind all along. Anyway, the
> maintainer may consider giving an error when trying to access
> HEAD as a module. Would have saved about 2 days work and its
> unlikely I'm the last victim :-(
This patch is completely untested. Could you try it, please?
If it works:
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc'ed Frank, who is de-facto maintainer (according to shortlog)
and Martin, who started it all IIRC.
git-cvsserver.perl | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 13dbd27..869690c 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -770,6 +770,14 @@ sub req_co
$log->debug("req_co : " . ( defined($data) ? $data : "[NULL]" ) );
+ if( system("git", "rev-parse", "--verify", "refs/heads/$module" ) != 0 )
+ {
+ $log->warn("Checkout failed: $module is not a branch");
+ print "error 1 Checkout failed: $module is not a branch\n";
+ chdir "/";
+ exit;
+ }
+
$log->info("Checking out module '$module' ($state->{CVSROOT}) to '$checkout_path'");
$ENV{GIT_DIR} = $state->{CVSROOT} . "/";
^ permalink raw reply related
* Question about "git commit -a"
From: Paolo Ciarrocchi @ 2007-10-04 15:38 UTC (permalink / raw)
To: Git Mailing List
Hi all,
I was just wondering why git commit doesn't default to "-a" (yes, it's
another question that came up during a chat with a mercurial user) and
I didn't find an answer to that.
It's not a big deal but I strongly suspect that the large majority of
the git users never user git commit without the option "-a".
Am I wrong?
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://ubuntista.blogspot.com
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Karl Hasselström @ 2007-10-04 15:38 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910710040606j75caa6bcn1e97e59c1285eb4b@mail.gmail.com>
On 2007-10-04 09:06:22 -0400, Jon Smirl wrote:
> On 10/4/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > Mmmph. This is not the only StGit command that's apparently not
> > safe to run from a subdirectory. See e.g.
> > https://gna.org/bugs/?9986.
> >
> > I plan to do some StGit hacking this weekend. I guess subdirectory
> > safeness ought to be at the top of my list ...
>
> Isn't a rollback log fairly easy to implement? Is there a single SHA
> after each operation? If so just record the commands and the sha to
> rollback.
Yeah, conceptually it's simple. The only major complication there is
if you want to allow undo both at the whole-stack level and on single
patches.
> I have also messed things up more than once using 'git merge linus'
> instead of 'stg rebase linus'. Should 'git merge' have a check to
> see if stg is active and refuse to run?
I've always felt that git shouldn't have to know about third-party
tools.
stg will detect that you've made git commits on top of the stack.
There's a command to turn them into patches -- but not if they are
merges, of course. In a sufficiently bleeding-edge StGit, assimilate
will tell you something like,
14 patches are hidden below the merge commit 4711abcd,
and will be considered unapplied.
at which point you can easily git-reset to below the merge and run
assimilate again.
This is of course less user-friendly than having git refuse to commit
a merge in the first place. Hmmm, a commit hook could probably do
magic here ... it could even turn regular commits into patches on the
fly. I'll have to look up how commit hooks work.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Question about "git commit -a"
From: Matthieu Moy @ 2007-10-04 15:43 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30710040838t48bb590erbd90a8c4a1c6e932@mail.gmail.com>
"Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
> Hi all,
> I was just wondering why git commit doesn't default to "-a" (yes, it's
> another question that came up during a chat with a mercurial user) and
> I didn't find an answer to that.
http://git.or.cz/gitwiki/GitFaq#head-3aa45c7d75d40068e07231a5bf8a1a0db9a8b717
--
Matthieu
^ permalink raw reply
* Re: stgit: lost all my patches again
From: David Brown @ 2007-10-04 15:45 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20071004083304.GB17778@diana.vm.bytemark.co.uk>
On Thu, Oct 04, 2007 at 10:33:04AM +0200, Karl Hasselström wrote:
>> I did the 'stg refresh' from a directory that was not being tracked
>> by git. It is in the .gitignore list. This appears to be the root of
>> the problem.
>
>Mmmph. This is not the only StGit command that's apparently not safe
>to run from a subdirectory. See e.g. https://gna.org/bugs/?9986.
I get an "Error: This item is private" from that page, so I'm not sure what
that is.
Just yesterday, I had 'stg push' empty out my patches when I ran it from a
subdirectory. Fortunately, in this case, the old versions were in the log,
but I can imagine someone less familiar with what git and stgit are doing
not knowing how to recover this.
David
^ permalink raw reply
* Re: Question about "git commit -a"
From: Paolo Ciarrocchi @ 2007-10-04 15:48 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Git Mailing List
In-Reply-To: <vpqk5q2x4ud.fsf@bauges.imag.fr>
On 10/4/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
>
> > Hi all,
> > I was just wondering why git commit doesn't default to "-a" (yes, it's
> > another question that came up during a chat with a mercurial user) and
> > I didn't find an answer to that.
>
> http://git.or.cz/gitwiki/GitFaq#head-3aa45c7d75d40068e07231a5bf8a1a0db9a8b717
Ooops... I'm really that bad in googling for an information ;-(
Thanks and sorry for the noise.
Regads,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://ubuntista.blogspot.com
^ permalink raw reply
* Re: stgit: editing description of patch
From: Karl Hasselström @ 2007-10-04 15:48 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910710040616l5358099dj1b65b47cf94cf031@mail.gmail.com>
On 2007-10-04 09:16:46 -0400, Jon Smirl wrote:
> Why is mailing a patch series so slow?
Because the default per-patch delay is 5 seconds. You can change it by
setting stgit.smtpdelay in your config, or passing --sleep on the
command line.
> There also seems to be a disconnect when mailing patches. Locally
> the patches have a name, when you email them it uses the short
> description for the name by default instead of the local name. This
> may cause confusion because the emailed name does not default to the
> local name. A parallel issue happens on import.
>
> Now that I am aware of the naming scheme I can deal with it, but
> this may be a problem for new users. It might be better to force the
> short description and local name to always match.
I've never thought of the patch names as anything that would make
sense to export from a repository (like reflogs), so using the first
line of the commit message for mail subject (like git does) always
seemed like a no-brainer. But then I don't have any experience using
quilt or any related tool.
The default when creating a new patch is to make up a name from its
commit message (the user is free to give a name explicitly, however);
the same goes when you import a patch mbox. But when importing a patch
series (with "stg import --series"), I see the names are taken from
the series file you import. Maybe that should change, at least
optionally.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: J. Bruce Fields @ 2007-10-04 15:51 UTC (permalink / raw)
To: Matthieu Moy
Cc: Johannes Schindelin, Junio C Hamano, Miklos Vajna,
Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <vpqtzp7ndn3.fsf@bauges.imag.fr>
On Thu, Oct 04, 2007 at 04:44:00PM +0200, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Hi,
> >
> > On Thu, 4 Oct 2007, Junio C Hamano wrote:
> >
> >> * --cached means work only on index and ignore work tree.
> >
> > I guess I could live with "--staged" as a synonym for "--cached" (and
> > maybe deprecating "--cached").
>
> It makes more sense to me.
>
> For me, a "cache" is a fast-access copy of something, that I can
> rebuild at any time. Cache should be only a matter of performance, if
> the "cache" for an application changes its functionality, it means the
> cache has been too optimistic. Git's index is not that, "git add"
> means "add this to the index", which itself means "put that in the
> list of things to commit", and not "get a copy of that to work faster
> with it".
Yes, the index differs from the work tree or HEAD temporarily, but most
of it's life it's just a fast-access copy of something that you can
rebuild at any time.
So it's partly a "cache", partly a "staging area", and "index" is as
good a term for it as any.
--b.
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Wincent Colaiuta @ 2007-10-04 15:54 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Git Mailing List, Johannes Schindelin, Pierre Habouzit,
Miles Bader, Junio C Hamano, Karl Hasselström
In-Reply-To: <717D7260-CE23-4397-8B13-264309094423@zib.de>
El 4/10/2007, a las 16:47, Steffen Prohaska escribió:
> On Oct 3, 2007, at 7:02 PM, Karl Hasselström wrote:
>
>> On 2007-10-03 17:44:39 +0100, Johannes Schindelin wrote:
>>
>>> I wonder how hard it would be to teach _everybody_ to specify
>>> _exactly_ what they want.
>>>
>>> Of course, we'd need an "--existing" option to git-push to trigger
>>> the behaviour that we have right now.
>>
>> I could _definitely_ live with that. If the branch config doesn't say
>> what to do when no arguments are given, then demand a
>> specification on
>> the command line.
>>
>> I'll shut up on this topic now, though, since I'm not exactly helping
>> with the patch/opinion ratio.
>
> Here is an interesting related pitfall where my expectations about
> the behaviour of git push in relation with tracking branches were
> wrong. I should have know better, but I somehow forgot the details.
> I expected that the following would establish a two-way link, not
> only a one way link:
>
> git checkout --track -b mynext origin/next
>
> sets up a tracking branch and "git pull" fetches and merges changes
> from origin/next as expected.
>
> I somehow expected that "git push" would push changes from mynext to
> origin/next. But it doesn't. It would only do so if I had chosen
> the same name for the local branch, that is
>
> git checkout --track -b next origin/next
>
> would have set up a two-way link -- but maybe only as long as I don't
> have other push lines in my config file. I'm not sure about the last
> point.
>
> I do not find it very intuitive to mangle the push behaviour into the
> naming of the local branch. I think it would be a good idea if the
> two commands above would either both setup a pull/push relation
> or both would setup a pull-only relation. If pull-only would be the
> default another switch could be provided to establish a pull/push
> relation, like
>
> git checkout --track --push -b mynext origin/next
>
> Comments?
Interesting. To me that doesn't seem to be intuitive at all. I
actually think it makes a lot of sense for the relationship to be
"one way" in the absence of matching ref names.
Basically, the distributed model works because you know that if you
have the same commit hash in two repositories you're talking about
the same thing. Same thing goes for branches; if you expect to be
able to push back upstream then it's natural to expect that that
should only work if you have the same ref name to identify the "what"
that you're actually pushing to.
Cheers,
Wincent
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Wincent Colaiuta @ 2007-10-04 15:49 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Miklos Vajna, Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710041534000.4174@racer.site>
El 4/10/2007, a las 16:34, Johannes Schindelin escribió:
> On Thu, 4 Oct 2007, Junio C Hamano wrote:
>
>> * --cached means work only on index and ignore work tree.
>
> I guess I could live with "--staged" as a synonym for "--cached" (and
> maybe deprecating "--cached").
Good idea. I think that would partly address the consistency
problems, be more accessible to new users, and easier to explain in
the documentation.
Not that it makes much difference to me personally. One of the first
things I did when I started using Git was set up two shell aliases
(not Git aliases) seeing as looking at my staged and unstaged changes
is for me such an extremely frequent operation:
alias staged='git diff --cached'
alias unstaged='git diff'
Cheers,
Wincent
^ permalink raw reply
* Re: Question about "git commit -a"
From: Wincent Colaiuta @ 2007-10-04 15:58 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30710040838t48bb590erbd90a8c4a1c6e932@mail.gmail.com>
El 4/10/2007, a las 17:38, Paolo Ciarrocchi escribió:
> Hi all,
> I was just wondering why git commit doesn't default to "-a" (yes, it's
> another question that came up during a chat with a mercurial user) and
> I didn't find an answer to that.
>
> It's not a big deal but I strongly suspect that the large majority of
> the git users never user git commit without the option "-a".
<http://git.or.cz/gitwiki/GitFaq>
Specifically:
<http://git.or.cz/gitwiki/
GitFaq#head-3aa45c7d75d40068e07231a5bf8a1a0db9a8b717>
> Am I wrong?
About it being a majority, yes, I suspect so.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Be nice with compilers that do not support runtime paths at all.
From: Benoit SIGOURE @ 2007-10-04 15:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejgbdbyn.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]
On Oct 4, 2007, at 1:18 AM, Junio C Hamano wrote:
> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>
>> diff --git a/Makefile b/Makefile
>> index a1fe443..7c6c453 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -100,6 +100,9 @@ all::
>> # that tells runtime paths to dynamic libraries;
>> # "-Wl,-rpath=/path/lib" is used instead.
>> #
>> +# Define NO_RPATH if your dynamic loader doesn't support runtime
>> paths at
>> +# all.
>> +#
>> # 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
>
> Thanks for this part;
>
>> @@ -507,6 +510,7 @@ ifeq ($(uname_S),Darwin)
>> BASIC_LDFLAGS += -L/opt/local/lib
>> endif
>> endif
>> + NO_RPATH = YesPlease
>> endif
>
> I'll let Darwin users to fight the defaults for this part out.
No more replies on this thread, and the Apple documentation confirms
that there is no rpath support in the dynamic loader of OSX 10.4 and
before. I don't know about the soon-to-be-released 10.5 aka Leopard.
>> @@ -521,7 +525,10 @@ ifndef NO_CURL
>> ifdef CURLDIR
>> # Try "-Wl,-rpath=$(CURLDIR)/$(lib)" in such a case.
>> BASIC_CFLAGS += -I$(CURLDIR)/include
>> - CURL_LIBCURL = -L$(CURLDIR)/$(lib) $(CC_LD_DYNPATH)$(CURLDIR)/$
>> (lib) -lcurl
>> + CURL_LIBCURL = -L$(CURLDIR)/$(lib) -lcurl
>> +ifndef NO_RPATH
>> + CURL_LIBCURL += $(CC_LD_DYNPATH)$(CURLDIR)/$(lib)
>> +endif
>> else
>> CURL_LIBCURL = -lcurl
>> endif
>
>> @@ -539,7 +546,10 @@ endif
>>
>> ifdef ZLIB_PATH
>> BASIC_CFLAGS += -I$(ZLIB_PATH)/include
>> - EXTLIBS += -L$(ZLIB_PATH)/$(lib) $(CC_LD_DYNPATH)$(ZLIB_PATH)/$
>> (lib)
>> + EXTLIBS += -L$(ZLIB_PATH)/$(lib)
>> +ifndef NO_RPATH
>> + EXTLIBS += $(CC_LD_DYNPATH)$(ZLIB_PATH)/$(lib)
>> +endif
>> endif
>> EXTLIBS += -lz
>>
>
> While these parts are ugly but correct, I think...
>
>> @@ -547,7 +557,10 @@ ifndef NO_OPENSSL
>> OPENSSL_LIBSSL = -lssl
>> ifdef OPENSSLDIR
>> BASIC_CFLAGS += -I$(OPENSSLDIR)/include
>> - OPENSSL_LINK = -L$(OPENSSLDIR)/$(lib) $(CC_LD_DYNPATH)$
>> (OPENSSLDIR)/$(lib)
>> + OPENSSL_LINK = -L$(OPENSSLDIR)/$(lib)
>> +ifndef NO_RPATH
>> + OPENSSL_LINK = $(CC_LD_DYNPATH)$(OPENSSLDIR)/$(lib)
>> +endif
>> else
>> OPENSSL_LINK =
>> endif
>
> this and the ICONV one are missing s/=/+=/.
You're right, sorry.
>
> If we do not care about supporting too old GNU make, we can do
> this by first adding this near the top:
>
> ifndef NO_RPATH
> LINKER_PATH = -L$(1) $(CC_LD_DYNPATH)$(1)
> else
> LINKER_PATH = -L$(1)
> endif
>
> and then doing something like:
>
> CURL_LIBCURL = $(call LINKER_PATH,$(CURLDIR)/$(lib))
> OPENSSL_LINK = $(call LINKER_PATH,$(OPENSSLDIR)/$(lib))
>
> to make it easier to read and less error prone.
>
Yes. I can rework the patch, but the question is: do you care about
old GNU make? Can I rewrite the patch with this feature?
Thanks.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Matthieu Moy @ 2007-10-04 16:02 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Johannes Schindelin, Junio C Hamano, Miklos Vajna,
Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <20071004155147.GA17487@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> Yes, the index differs from the work tree or HEAD temporarily,
Temporarily, yes, but the _point_ of having it is to have it differ
from HEAD (otherwise, you can't create a new revision), and from the
tree (otherwise, index-related commands are useless).
The stat-information, and sha1sum are actually a cache, but they don't
have to be user-visible, except for speed. "diff --cached" has nothing
to do with the stat information for the user.
--
Matthieu
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary (long)
From: Johannes Schindelin @ 2007-10-04 16:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <8fe92b430710040212u332bb4e5yfa6c10b8236c6301@mail.gmail.com>
Hi,
On Thu, 4 Oct 2007, Jakub Narebski wrote:
> This is partial summary of Git User's Survey 2007,
> ending at state from 28 September 2007.
Thanks.
> 26. Which porcelains do you use?
>
> Multiple answers (one can use more than one porcelain).
>
> Answer (multiple choice) | Count
> ------------------------------------------
> core-git | 558
> cogito (deprecated) | 56
>
> Patch management interface: : 57
> ...........................................
> StGIT | 41
> Guilt (formerly gq) | 13
> pg (deprecated) | 3
>
> own scripts | 95
> other | 14
> ------------------------------------------
> Base | 593 / 683
> Total (sum) | 780
>
> Those 14 "other" answers make me wish to have provided "if other,
> what it was?" (sub)question; actually not only for this question.
git-gui, of course. I consider it porcelain, because it uses core-git as
backend.
In the same vein, I should consider gitk porcelain now, since it has
rebase capabilities. I will not, and I am not very happy that this viewer
got a non-view-only capability, instead of git-gui, where that feature
should have belonged (as suggested by at least one answer to a later
question in the survey -- not by me).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFT] cvsserver: only allow checkout of branches
From: Frank Lichtenheld @ 2007-10-04 16:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jan Wielemaker, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0710041622070.4174@racer.site>
On Thu, Oct 04, 2007 at 04:29:04PM +0100, Johannes Schindelin wrote:
> Cc'ed Frank, who is de-facto maintainer (according to shortlog)
> and Martin, who started it all IIRC.
>
> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
> index 13dbd27..869690c 100755
> --- a/git-cvsserver.perl
> +++ b/git-cvsserver.perl
> @@ -770,6 +770,14 @@ sub req_co
>
> $log->debug("req_co : " . ( defined($data) ? $data : "[NULL]" ) );
>
> + if( system("git", "rev-parse", "--verify", "refs/heads/$module" ) != 0 )
> + {
> + $log->warn("Checkout failed: $module is not a branch");
> + print "error 1 Checkout failed: $module is not a branch\n";
> + chdir "/";
> + exit;
> + }
> +
> $log->info("Checking out module '$module' ($state->{CVSROOT}) to '$checkout_path'");
>
> $ENV{GIT_DIR} = $state->{CVSROOT} . "/";
Looks good, haven't tested it yet, though. Care to add a testcase
or should I take care of that?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: J. Bruce Fields @ 2007-10-04 16:19 UTC (permalink / raw)
To: Matthieu Moy
Cc: Johannes Schindelin, Junio C Hamano, Miklos Vajna,
Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <vpq8x6ix3zm.fsf@bauges.imag.fr>
On Thu, Oct 04, 2007 at 06:02:21PM +0200, Matthieu Moy wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > Yes, the index differs from the work tree or HEAD temporarily,
>
> Temporarily, yes, but the _point_ of having it is to have it differ
> from HEAD (otherwise, you can't create a new revision), and from the
> tree (otherwise, index-related commands are useless).
Getting a nearly-instantaneous "git diff" would be sufficiently
important to justify its existance on its own, so I think you're
overstating the case.
> The stat-information, and sha1sum are actually a cache, but they don't
> have to be user-visible, except for speed.
That's a big exception.--b.
> "diff --cached" has nothing to do with the stat information for the
> user.
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Steffen Prohaska @ 2007-10-04 16:24 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Git Mailing List, Johannes Schindelin, Pierre Habouzit,
Miles Bader, Junio C Hamano, Karl Hasselström
In-Reply-To: <204B0DD6-54B0-4436-AFC6-ABDA4510E5D5@wincent.com>
On Oct 4, 2007, at 5:54 PM, Wincent Colaiuta wrote:
>> I do not find it very intuitive to mangle the push behaviour into the
>> naming of the local branch. I think it would be a good idea if the
>> two commands above would either both setup a pull/push relation
>> or both would setup a pull-only relation. If pull-only would be the
>> default another switch could be provided to establish a pull/push
>> relation, like
>>
>> git checkout --track --push -b mynext origin/next
>>
>> Comments?
>
> Interesting. To me that doesn't seem to be intuitive at all. I
> actually think it makes a lot of sense for the relationship to be
> "one way" in the absence of matching ref names.
>
> Basically, the distributed model works because you know that if you
> have the same commit hash in two repositories you're talking about
> the same thing. Same thing goes for branches; if you expect to be
> able to push back upstream then it's natural to expect that that
> should only work if you have the same ref name to identify the
> "what" that you're actually pushing to.
But how do multiple remotes fit into your model? Maybe my example
above was a bit to simple. How about this one:
git checkout --track --push -b masterA remoteA/master
git checkout --track --push -b masterB remoteB/master
I understand what it means because I devised my local naming model.
The model could look totally wrong to you, but it's in my repository.
You'd never see it. But if it fits my mental model, why should git
enforce its master-means-always-master-and-must-not-be-named-differently
model?
Steffen
^ permalink raw reply
* Re: [PATCH] Add a simple option parser.
From: Pierre Habouzit @ 2007-10-04 16:31 UTC (permalink / raw)
To: Kristian Høgsberg, git, gitster
In-Reply-To: <20071004151532.GB5083@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]
On jeu, oct 04, 2007 at 03:15:32 +0000, Pierre Habouzit wrote:
> On Thu, Oct 04, 2007 at 02:57:58PM +0000, Kristian Høgsberg wrote:
> > I'm not sure - we can go with the current proposal and add new options
> > types and probably the callback option type I suggested as we go. I
> > don't want to block builtin-commit on figuring out what the perfect
> > option parser should look like and what I sent out earlier work for
> > commit. I think the way you handled the strbuf rewrites worked pretty
> > well; extending and rewriting the API as you put it to use in more and
> > more places. We can do the same thing with parse_options().
>
> Of course we can do that, or junio said that some people talked about
> popt some time ago. I understand that you don't want to block the
> git-commit work, but doing things right from the beginning is often a
> big win on the long term.
>
> I don't know popt, and I don't know if it has sufficient expressivity.
> For sure I don't like getopt_long APIs at all, so if popt is as
> cumbersome, rolling our own based on the current parse_options you
> propose is probably a good choice.
Okay, popt seems to be quite complicated, and depends upon gettext
(which we may require as per survey results, but right now it seems a
useless dependency). Don't get me wrong, I'm sure it's very powerful,
but again, I believe we can have a 200 line ad-hoc module that fits what
git really needs, the less cumbersome way.
So well, I'd be (I'm not in position to decide anything btw ;p) in
favor of pursuing the work into git-commit like you did, and ASAP it
gets merged into next, I'm definitely willing to pursue a refactoring to
use it (now that strbufs seems to have been used where needed).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH/RFT] cvsserver: only allow checkout of branches
From: Johannes Schindelin @ 2007-10-04 16:32 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Jan Wielemaker, Martin Langhoff, git
In-Reply-To: <20071004161812.GA31659@planck.djpig.de>
Hi,
On Thu, 4 Oct 2007, Frank Lichtenheld wrote:
> On Thu, Oct 04, 2007 at 04:29:04PM +0100, Johannes Schindelin wrote:
> > Cc'ed Frank, who is de-facto maintainer (according to shortlog)
> > and Martin, who started it all IIRC.
> >
> > diff --git a/git-cvsserver.perl b/git-cvsserver.perl
> > index 13dbd27..869690c 100755
> > --- a/git-cvsserver.perl
> > +++ b/git-cvsserver.perl
> > @@ -770,6 +770,14 @@ sub req_co
> >
> > $log->debug("req_co : " . ( defined($data) ? $data : "[NULL]" ) );
> >
> > + if( system("git", "rev-parse", "--verify", "refs/heads/$module" ) != 0 )
> > + {
> > + $log->warn("Checkout failed: $module is not a branch");
> > + print "error 1 Checkout failed: $module is not a branch\n";
> > + chdir "/";
> > + exit;
> > + }
> > +
> > $log->info("Checking out module '$module' ($state->{CVSROOT}) to '$checkout_path'");
> >
> > $ENV{GIT_DIR} = $state->{CVSROOT} . "/";
>
> Looks good, haven't tested it yet, though. Care to add a testcase
> or should I take care of that?
I would be eternally thankful if you could add the test case, since I am
really short on time.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a simple option parser.
From: Johannes Schindelin @ 2007-10-04 16:39 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Kristian Høgsberg, git, gitster
In-Reply-To: <20071004163156.GD5083@artemis.corp>
Hi,
On Thu, 4 Oct 2007, Pierre Habouzit wrote:
> Okay, popt seems to be quite complicated, and depends upon gettext
... which makes me vote against popt ...
> (which we may require as per survey results, but right now it seems a
> useless dependency).
Nope. git-gui got a script doing the job of msgfmt, which was the only
part of that beast known as gettext anyway.
So we will not require it for git-gui.
And I do not see core git being i18n'ised. Ever.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] t5403-post-checkout-hook.sh: don't use "==" as test operator
From: René Scharfe @ 2007-10-04 16:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Josh England
The POSIXly correct comparison operator of test is "=", not "=="; the
latter is a GNU invention. Without this patch the script fails (at
least) on Ubuntu 7.04, where /bin/sh is not bash.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/t/t5403-post-checkout-hook.sh b/t/t5403-post-checkout-hook.sh
index 487abf3..823239a 100755
--- a/t/t5403-post-checkout-hook.sh
+++ b/t/t5403-post-checkout-hook.sh
@@ -39,7 +39,7 @@ test_expect_success 'post-checkout receives the right arguments with HEAD unchan
old=$(awk "{print \$1}" clone1/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone1/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone1/.git/post-checkout.args) &&
- test $old = $new -a $flag == 1
+ test $old = $new -a $flag = 1
'
test_expect_success 'post-checkout runs as expected ' '
@@ -52,7 +52,7 @@ test_expect_success 'post-checkout args are correct with git checkout -b ' '
old=$(awk "{print \$1}" clone1/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone1/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone1/.git/post-checkout.args) &&
- test $old = $new -a $flag == 1
+ test $old = $new -a $flag = 1
'
test_expect_success 'post-checkout receives the right args with HEAD changed ' '
@@ -60,7 +60,7 @@ test_expect_success 'post-checkout receives the right args with HEAD changed ' '
old=$(awk "{print \$1}" clone2/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone2/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone2/.git/post-checkout.args) &&
- test $old != $new -a $flag == 1
+ test $old != $new -a $flag = 1
'
test_expect_success 'post-checkout receives the right args when not switching branches ' '
@@ -68,7 +68,7 @@ test_expect_success 'post-checkout receives the right args when not switching br
old=$(awk "{print \$1}" clone2/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone2/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone2/.git/post-checkout.args) &&
- test $old == $new -a $flag == 0
+ test $old = $new -a $flag = 0
'
test_done
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox