* Re: [PATCH/RFT] cvsserver: only allow checkout of branches
From: Frank Lichtenheld @ 2007-10-04 18:04 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: Johannes Schindelin, Martin Langhoff, git
In-Reply-To: <200710041906.21004.wielemak@science.uva.nl>
On Thu, Oct 04, 2007 at 07:06:20PM +0200, Jan Wielemaker wrote:
> On Thursday 04 October 2007 17:29, Johannes Schindelin wrote:
> > ) + {
> > + $log->warn("Checkout failed: $module is not a branch");
> > + print "error 1 Checkout failed: $module is not a branch\n";
>
> There are various places where it says print "...", one that even
> started some suggestion on what might be wrong, but these things don't
> end up at a visible place when using ssh as transport. Its a good idea
huh?
$ CVS_SERVER=/home/djpig/devel/git/git-cvsserver cvs -d :ext:localhost:/home/djpig/devel/gitcvs.git/ co -d cvswork HEAD
djpig@localhost's password:
server doesn't support gzip-file-contents
fatal: Needed a single revision
Checkout failed: HEAD is not a branch
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Wincent Colaiuta @ 2007-10-04 17:49 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: <04A74C2E-272B-4F5C-9254-11C9244091AF@zib.de>
El 4/10/2007, a las 18:24, Steffen Prohaska escribió:
> 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?
I think I'll leave it up to someone who knows a bit more than me to
answer that one... It's not a use case I've ever sought out as I
usually only work with one upstream remote. Sorry I don't have
anything intelligent to add.
Cheers,
Wincent
^ permalink raw reply
* Re: stgit: editing description of patch
From: Karl Hasselström @ 2007-10-04 17:39 UTC (permalink / raw)
To: Jon Smirl, Catalin Marinas; +Cc: Git Mailing List
In-Reply-To: <9e4733910710040945l2335f3d7le6f45510640d3a6e@mail.gmail.com>
On 2007-10-04 12:45:17 -0400, Jon Smirl wrote:
> On 10/4/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > 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.
>
> Why are the patch name and the short description independent
> variables? Wouldn't it make more sense to treat these as a single
> unified item? If I rename the patch it would automatically edit the
> first line of the description, etc...
I guess Catalin would have to answer that -- it's "always" been like
that. But one obvious problem are patches with identical messages --
just today I created a series of seven patches that all had "debug"
for a message. Another is that you usually want descriptive commit
messages, but may want short and easy-to-type patch names.
> When importing a patch from a saved email, stg should strip all the
> email headers out of the description. I have to manually fix that
> up.
Do you do "stg import -M"? That's for importing one or more patches
contained in an mbox. Without the -M, I think the default is to expect
plain diff input.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Karl Hasselström @ 2007-10-04 17:29 UTC (permalink / raw)
To: Jon Smirl, Git Mailing List
In-Reply-To: <20071004154508.GA15424@old.davidb.org>
On 2007-10-04 08:45:08 -0700, David Brown wrote:
> 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.
Bleh. For some reason that bug was marked "private" (possibly because
it was posted anonymously), and I didn't realize because _I_ could
read it just fine ... Sorry about that; I've made it public now.
> 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.
Yep. I hadn't really realized how bad this was, because I always run
stg from the root dir. Wonder how I picked up that habit? ;-)
Thanks for the report.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH/RFT] cvsserver: only allow checkout of branches
From: Johannes Schindelin @ 2007-10-04 17:18 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: Frank Lichtenheld, Martin Langhoff, git
In-Reply-To: <200710041906.21004.wielemak@science.uva.nl>
Hi,
On Thu, 4 Oct 2007, Jan Wielemaker wrote:
> On Thursday 04 October 2007 17:29, Johannes Schindelin wrote:
> > It does not make sense to check out tags or "HEAD".
> >
> > Noticed by Jan Wielemaker.
>
> Thanks (though it won't bite me a second time :-)
Heh. But this is Open Source, so we can make it better for others, too.
Thank you for spending so much time on this, and actually uncovering that
error in cvsserver!
> > ) + {
> > + $log->warn("Checkout failed: $module is not a branch");
> > + print "error 1 Checkout failed: $module is not a branch\n";
>
> There are various places where it says print "...", one that even
> started some suggestion on what might be wrong, but these things don't
> end up at a visible place when using ssh as transport. Its a good idea
> this one is at least in the logfile as well. Not sure, but might
> printing to stderr work better?
I think not. AFAICT stderr is not visible with cvs either. I somewhat
hoped that the "error 1" was an indicator to the cvs client to show the
message, but that's way beyond my knowledge...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFT] cvsserver: only allow checkout of branches
From: Jan Wielemaker @ 2007-10-04 17:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Frank Lichtenheld, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0710041622070.4174@racer.site>
On Thursday 04 October 2007 17:29, Johannes Schindelin wrote:
> It does not make sense to check out tags or "HEAD".
>
> Noticed by Jan Wielemaker.
Thanks (though it won't bite me a second time :-)
> ) + {
> + $log->warn("Checkout failed: $module is not a branch");
> + print "error 1 Checkout failed: $module is not a branch\n";
There are various places where it says print "...", one that even
started some suggestion on what might be wrong, but these things don't
end up at a visible place when using ssh as transport. Its a good idea
this one is at least in the logfile as well. Not sure, but might
printing to stderr work better?
Cheers --- Jan
^ permalink raw reply
* Re: [PATCH] fix t5403-post-checkout-hook.sh: built-in test in dash does not have "=="
From: René Scharfe @ 2007-10-04 16:47 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Josh England, git
In-Reply-To: <20071004133253.GA30393@steel.home>
Alex Riesen schrieb:
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
> Josh England, Wed, Sep 26, 2007 23:31:01 +0200:
>> t/t5403-post-checkout-hook.sh | 74 +++++++++++++++++++++++++++++++++++++++++
>
> on Ubuntu, /bin/sh is dash.
Ah, so YOU are the other Ubuntu user around here, Alex! ;-) I've just
sent out the exact same patch. Sorry for the duplication, please ignore me.
René
^ permalink raw reply
* Re: stgit: editing description of patch
From: Jon Smirl @ 2007-10-04 16:45 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <20071004154836.GB21717@diana.vm.bytemark.co.uk>
On 10/4/07, Karl Hasselström <kha@treskal.com> wrote:
> 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.
Why are the patch name and the short description independent
variables? Wouldn't it make more sense to treat these as a single
unified item? If I rename the patch it would automatically edit the
first line of the description, etc...
When importing a patch from a saved email, stg should strip all the
email headers out of the description. I have to manually fix that up.
--
Jon Smirl
jonsmirl@gmail.com
^ 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
* 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
* 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: 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: 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: 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: [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: 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: 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: [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: 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: 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: 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: 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: 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: 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: 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
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