* Re: [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Johannes Schindelin @ 2007-10-04 12:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Waitz, Andreas Ericsson, git
In-Reply-To: <7vir5nb89d.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 4 Oct 2007, Junio C Hamano wrote:
> I do not think git on Cygwin nor WinGit creates $GIT_DIR/config with
> executable bit set. Is this pretty much a workaround only for
> vfat-on-Linux ?
I do not know precisely about Cygwin (a quick test on my USB stick shows
that .git/config is created without the executable bit set), but in MSys
plain files which start with a she-bang are automatically +x, while all
other plain files are automatically -x (therefore this applies to
.git/config).
Given these findings, I fail to see what the patch should achieve, as
the first test (for -x) always succeeds...
Ciao,
Dscho
^ permalink raw reply
* Re: git-cvsserver commit trouble BUG+Work-around
From: Johannes Schindelin @ 2007-10-04 12:56 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <46823.146.50.26.20.1191496739.squirrel@webmail.science.uva.nl>
Hi,
On Thu, 4 Oct 2007, Jan Wielemaker wrote:
> Indeed, the trouble is here: git-cvsserver, near line 1203:
>
> my $parenthash = `git show-ref -s refs/heads/$state->{module}`;
>
> $state->{module} is -of course- HEAD. git show-ref -s refs/heads/HEAD
> indeed gives no output. git show-ref -s refs/heads/master works just
> fine.
Ah! Did you do "CVSROOT=:ext:blablub cvs co HEAD"?
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).
Ciao,
Dscho
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Wincent Colaiuta @ 2007-10-04 12:54 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30710040527j61152b2dh1b073504ba19d490@mail.gmail.com>
El 4/10/2007, a las 14:27, Paolo Ciarrocchi escribió:
> Hi all,
> I'm having and interesting discussion with an happy mercurial users
> which started reading the git documentation. He raised aquestion that
> I'm not able to answer:
>
>> $ git diff --cached
>>
>> (Without —cached, git-diff(1) will show you any changes that you've
>> made but not yet added to the index.) You can also get a brief
>> summary
>> of the situation with git-status(1):
>
> Why do we have the option "--cached" and not "--index"?
I am not an "old timer", but I believe that it's because what we now
know as "the index" was original called "the cache". See:
<http://git.or.cz/gitwiki/GitHistory>
You're probably right that the option name is confusing, I guess
changing it to "--index" would be a good idea, continuing to support
"--cached" but marking it as deprecated before finally removing it at
some point in the future.
Cheers,
Wincent
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Miklos Vajna @ 2007-10-04 12:56 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30710040527j61152b2dh1b073504ba19d490@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 375 bytes --]
On Thu, Oct 04, 2007 at 02:27:41PM +0200, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> Why do we have the option "--cached" and not "--index"?
according to glossary.txt, 'cache' is an obsolete for 'index'. probably
this is the reason
probably cache.h will be never renamed to index.h, i don't know if diff
--cached will be ever renamed to diff --index
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Jon Smirl @ 2007-10-04 13:06 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <20071004083304.GB17778@diana.vm.bytemark.co.uk>
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.
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?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Paolo Ciarrocchi @ 2007-10-04 13:10 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Git Mailing List
In-Reply-To: <20071004125641.GE15339@genesis.frugalware.org>
On 10/4/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Thu, Oct 04, 2007 at 02:27:41PM +0200, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> > Why do we have the option "--cached" and not "--index"?
>
> according to glossary.txt, 'cache' is an obsolete for 'index'. probably
> this is the reason
>
> probably cache.h will be never renamed to index.h, i don't know if diff
> --cached will be ever renamed to diff --index
Believe me, for a GIT newbie git --cached is confusing.
That user started reading "A tutorial introduction to git (for version
1.5.1 or newer)",
after a cuple of minutes of reading he reached "Making changes" saw:
" You are now ready to commit. You can see what is about to be
committed using git-diff(1) with the —cached option:
$ git diff --cached "
$ git diff --index sound a lof more consistent with the general documentation.
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://ubuntista.blogspot.com
^ permalink raw reply
* Re: git-cvsserver commit trouble BUG+Work-around
From: Jan Wielemaker @ 2007-10-04 13:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710041352480.4174@racer.site>
Hi Dscho,
On Thursday 04 October 2007 14:56, Johannes Schindelin wrote:
> On Thu, 4 Oct 2007, Jan Wielemaker wrote:
> > Indeed, the trouble is here: git-cvsserver, near line 1203:
> >
> > my $parenthash = `git show-ref -s refs/heads/$state->{module}`;
> >
> > $state->{module} is -of course- HEAD. git show-ref -s refs/heads/HEAD
> > indeed gives no output. git show-ref -s refs/heads/master works just
> > fine.
>
> 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 :-(
Part of the two days is that during all the things I tried somehow
messed up with master too, so the one time I tried that it failed as
well :-(
Anyway, case closed. On with the testing ...
Thanks --- Jan
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Junio C Hamano @ 2007-10-04 13:14 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <20071004125641.GE15339@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Thu, Oct 04, 2007 at 02:27:41PM +0200, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
>> Why do we have the option "--cached" and not "--index"?
>
> according to glossary.txt, 'cache' is an obsolete for 'index'. probably
> this is the reason
>
> probably cache.h will be never renamed to index.h, i don't know if diff
> --cached will be ever renamed to diff --index
Probably never.
Some commands support both --index and --cached and have
different meanings. For them,
* --index means work on both index and work tree;
* --cached means work only on index and ignore work tree.
In the case of "diff --cached", the latter is exactly what's
happening. We do not say "git diff-index --index $commit"
because "git diff-index" (and by extension, when you give only
one commit to "git diff" as parameter) is all about a commit vs
your uncommitted changes, so having you say "--index" is just
silly. "git diff --cached" is just a shorthand for "git diff
--cached HEAD". Because --cached would make sense to no other
form of diff, its presense by definition means you are talking
about the one-tree form of diff i.e. compare a commit with your
uncommitted changes.
An example of a command that supports both is "git apply".
Actually it is an extreme case in that it allows "no index" form
of operation, so it has "git apply", "git apply --cached", and
"git apply --index". The --cached would only apply to index
without touching work tree, the --index would apply to both
index and work tree.
^ permalink raw reply
* Re: stgit: editing description of patch
From: Jon Smirl @ 2007-10-04 13:16 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <20071004082624.GA17778@diana.vm.bytemark.co.uk>
On 10/4/07, Karl Hasselström <kha@treskal.com> wrote:
> > > On my box all of the patches have names -- stg series shows them.
> > > But when I emailed them half of the patch didn't have the right
> > > subjects.
> >
> > this is controled in the template files
>
> Anything here you'd characterize as a bug?
No, not after I have learned more about stg. The missing subjects were
from other patches I had imported from emails. They has all of the
email headers on them. Once I edited those out the subjects appeared
ok. 'stg edit' should help with this, it was non-obvious to use 'stg
refresh' to edit the patch descriptions.
Why is mailing a patch series so slow?
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.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] fix t5403-post-checkout-hook.sh: built-in test in dash does not have "=="
From: Alex Riesen @ 2007-10-04 13:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josh England, git
In-Reply-To: <1190842261-9750-1-git-send-email-jjengla@sandia.gov>
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.
t/t5403-post-checkout-hook.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
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
--
1.5.3.3.147.g2054
^ permalink raw reply related
* Re: A few usability question about git diff --cached
From: Paolo Ciarrocchi @ 2007-10-04 13:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Git Mailing List
In-Reply-To: <7vy7ej9g38.fsf@gitster.siamese.dyndns.org>
On 10/4/07, Junio C Hamano <gitster@pobox.com> wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > On Thu, Oct 04, 2007 at 02:27:41PM +0200, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> >> Why do we have the option "--cached" and not "--index"?
> >
> > according to glossary.txt, 'cache' is an obsolete for 'index'. probably
> > this is the reason
> >
> > probably cache.h will be never renamed to index.h, i don't know if diff
> > --cached will be ever renamed to diff --index
>
> Probably never.
Ouch!
> Some commands support both --index and --cached and have
> different meanings. For them,
>
> * --index means work on both index and work tree;
> * --cached means work only on index and ignore work tree.
>
> In the case of "diff --cached", the latter is exactly what's
> happening. We do not say "git diff-index --index $commit"
> because "git diff-index" (and by extension, when you give only
> one commit to "git diff" as parameter) is all about a commit vs
> your uncommitted changes, so having you say "--index" is just
> silly. "git diff --cached" is just a shorthand for "git diff
> --cached HEAD". Because --cached would make sense to no other
> form of diff, its presense by definition means you are talking
> about the one-tree form of diff i.e. compare a commit with your
> uncommitted changes.
I see. But the problem is real. If we cannot solve the problem
changing the code of git we'll need to avoid this kind of
misunderstanding having "better" documentation.
As soon as I'll find some spare time I'll propose a patch to "A
tutorial introduction to git (for version 1.5.1 or newer)".
Thanks!
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://ubuntista.blogspot.com
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Wincent Colaiuta @ 2007-10-04 14:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <7vy7ej9g38.fsf@gitster.siamese.dyndns.org>
El 4/10/2007, a las 15:14, Junio C Hamano escribió:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
>> On Thu, Oct 04, 2007 at 02:27:41PM +0200, Paolo Ciarrocchi
>> <paolo.ciarrocchi@gmail.com> wrote:
>>> Why do we have the option "--cached" and not "--index"?
>>
>> according to glossary.txt, 'cache' is an obsolete for 'index'.
>> probably
>> this is the reason
>>
>> probably cache.h will be never renamed to index.h, i don't know if
>> diff
>> --cached will be ever renamed to diff --index
>
> Probably never.
>
> Some commands support both --index and --cached and have
> different meanings. For them,
>
> * --index means work on both index and work tree;
> * --cached means work only on index and ignore work tree.
Look at that with fresh eyes and you can see how it makes very little
sense.
The option named "--index" works on more than the index and the
option named "--cached" works only on the index. This sounds back-to-
front.
IMO, better names would be:
--index : means work only on the index (and ignore the work tree);
ie. it means what it says
--index-and-worktree : it also means what it says
The latter is more keystrokes but it's clearer.
Having said all this, I recognize that the likelihood of these option
names ever being changed is close to zero. Like Paolo says in his
other email, the documentation could be made clearer to avoid
possible confusion.
Cheers,
Wincent
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Johannes Schindelin @ 2007-10-04 14:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <7vy7ej9g38.fsf@gitster.siamese.dyndns.org>
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").
Ciao,
Dscho
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Junio C Hamano @ 2007-10-04 14:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710041534000.4174@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 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").
A handy mnemonic might be:
* --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.
Any change like swapping them or renaming --cached to --index
and making something else to mean what --index always meant will
break existing setups and people's scripts. Won't happen.
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.
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Matthieu Moy @ 2007-10-04 14:44 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>
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".
So, to me (non-native speaker), "index" doesn't mean much, "cache" is
worse, it means something which isn't correct, and "staging area"
means the right thing (but is longer to type). For example, I
understand immediately when git-gui talks me about staging/unstaging
changes ;-).
--
Matthieu
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Steffen Prohaska @ 2007-10-04 14:47 UTC (permalink / raw)
To: Git Mailing List
Cc: Johannes Schindelin, Pierre Habouzit, Wincent Colaiuta,
Miles Bader, Junio C Hamano, Karl Hasselström
In-Reply-To: <20071003170241.GA7571@diana.vm.bytemark.co.uk>
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?
Steffen
^ permalink raw reply
* 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
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