* Re: obnoxious CLI complaints
From: Todd Zullinger @ 2009-09-10 1:25 UTC (permalink / raw)
To: Brendan Miller; +Cc: Jakub Narebski, git
In-Reply-To: <ef38762f0909091709t7336d86dkd2f175e5b3a6a3f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 634 bytes --]
Brendan Miller wrote:
> On Wed, Sep 9, 2009 at 2:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Brendan Miller <catphive@catphive.net> writes:
>> First question: which git version do you use?
>
> It sounds like a bunch of things have been fixed in yet to be released
> versions. That's great.
If I am not mistaken, support for cloning an empty repo was available
in 1.6.2, which was released in March.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Drugs may lead to nowhere, but at least it's the scenic route.
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: [git-svn] always prompted for passphrase with subversion 1.6
From: Tim Potter @ 2009-09-10 0:58 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090905064649.GD22272@dcvr.yhbt.net>
Eric Wong wrote:
> Tim Potter <tpot@hp.com> wrote:
>> Hi everyone. I am using git-svn with the Subversion 1.6 client compiled
>> with GNOME Keyring support. This neat features allows a SSL client
>> certificate password to be cached inside GNOME Keyring instead of being
>> prompted to enter it every time. However the git-svn script doesn't
>> appear to know about this and always prompts for a password.
>>
>> Obviously there's some tweak required in the _auth_providers()
>> subroutine but I don't know enough about the Subversion Perl client to
>> figure out a fix.
>>
>> Has anyone else run in to this problem? I did a quick search on the
>> list but didn't find anything relevant.
>
> Hi Tim,
>
> I think one user wanted to get SSL certificate authentication going but
> my SSL knowledge was too weak at the time[1] and I think we both forgot
> about it or lost interest.
Hi Eric. Thanks for the reply.
It's probably just a matter of adding another entry to the
_auth_providers() function in git-svn. My thought was that there might
be a new auth provider in the Subversion 1.6 client library for GNOME
Keyring support that could be used for this.
I'll have a search through and see what I can find.
Regards,
Tim.
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Brendan Miller @ 2009-09-10 0:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3fxavvl5k.fsf@localhost.localdomain>
On Wed, Sep 9, 2009 at 2:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Brendan Miller <catphive@catphive.net> writes:
> First question: which git version do you use?
It sounds like a bunch of things have been fixed in yet to be released
versions. That's great.
>>
>> This is what I want to do 90% of the time, so it should just have the
>> proper defaults, and not make me look at the man page every time I
>> want to use it.
>
> You learn those idioms.
I guess. Is that a good thing? Is the goal of interface design to make
it difficult so I need to learn a lot of things, or easy so I can
remain blissfully ignorant but still do what I want?
>
>>
>> 6. Where is the bug tracker? If people users can't find the bug
>> tracker, they can't report issues, and obnoxious bugs go unfixed, or
>> people have to whine on the mailing list. There should be a nice big
>> link on the front page of git-scm.com. A bug tracker is really the
>> only way for the vast majority of a community that use a tool can give
>> feedback on the problems the tool has.
>
> Do you offer to maintain and manage such bug tracker? I mean here
> taking care of duplicated bugs, tracking which bugs are resolved and
> which are not, checking if bug is reproductible, etc. Do you?
> Unmaintained bugtracker is worse than useless.
>
> Using mailing list for bug reports and for patches is time-honored
> workflow, which works rather well for smaller projects such as Git.
> Note that git mailing list is free for all; you don't need to
> subscribe to send, and you can watch it via many archives and gateways
> (like GMane).
Bug trackers are a hassle, believe me, I know... but I think they
contribute to the overall quality of the product if used effectively.
Mailing lists seem like a good way to forget about bugs after people
have given up on getting developers to fix them.
>
>>
>> 7. Man pages: It's nice we have them, but we shouldn't need them to do
>> basic stuff. I rarely had to look at the man pages using svn, but
>> every single time I use git I have to dig into these things. Frankly,
>> I have better things to do than RTFM.
>
> Learn. If you learn the philosophy behind git design, you would have
> much easier understanding and remembering git.
I think what you mean by philosophy is the underlying data structures,
which are discussed in the manual (how many apps do you have that do
that!). I have read that. However, that one needs to understand
underlying data structure is just one more hurdle to understanding
git.
If I use GCC, do I need to know that it has a recursive descent
parser? That it is implemented with a garbage collector? No. I just
need to know that I give it C, and it gives me a binary.
Example:
gcc main.c
Think about all the defaults that are specified here! I don't
explicitly tell it how to find libc.so or what path the dynamic linker
is at. I don't even really need to tell it which operation it is
performing, i.e. generating a binary, .o, .so, .os, .a, etc because it
has a smart default.
This an order of magnitude more complex than any git operation in
terms of implementation, but it is dead simple from the users
perspective.
>
> There is "Git User's Manual", "The Git Community Book", "Pro Git" and
> many other references.
Yeah, I've been reading them. I'm saying that the docs are a crutch.
RTFM is the problem not the solution. It makes the user do more work
to avoid fixing usability issues.
A CLI has some inherent limitations in that it doesn't have big
labeled buttons to press. However, that doesn't mean it has to be hard
to use. I think a lot of the strength of the linux CLI is that most of
the utilities have actually pretty well thought out interfaces that
have been refined over time. That one's that aren't like that... well,
no one uses them.
I'm not saying that a unixy approach is wrong, but that most unix
utilities are much easier to use than git, and that git needs
improvement on this front.
Brendan
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Nanako Shiraishi @ 2009-09-09 23:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Clemens Buchacher, SZEDER Gbor, git
In-Reply-To: <7vy6ot4x61.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> We could probably declare "In 1.X.0 everything will be relative to the
> root and you have to give an explicit '.' if you mean the cwd".
>
> Three questions:
>
> #1 What are the commands that will be affected, other than "add -u" and
> "grep"? Are there others?
>
> #2 Do all the commands in the answer to #1 currently behave exactly the
> same when run without any path parameter and when run with a single
> '.'?
'git-archive' behaves relative to your current directory.
http://thread.gmane.org/gmane.comp.version-control.git/41300/focus=44125
You can limit it to the current directory with a dot.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Pierre Habouzit @ 2009-09-09 22:58 UTC (permalink / raw)
To: Brendan Miller; +Cc: git
In-Reply-To: <ef38762f0909091427m5b8f3am72c88fd4dbfebc59@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]
On Wed, Sep 09, 2009 at 02:27:56PM -0700, Brendan Miller wrote:
> 5. Most commands require lots of flags, and don't have reasonable
> defaults. e.g. archive.
>
> git archive --format=tar --prefix=myproject/ HEAD | gzip >myproject.tar.gz
>
> Should just be:
> git archive
> run from the root of the repo.
You can't, because "myproject" cannot be guessed most of the time.
If you really want to automatize it, it's a 2 liner shell script, or
alternatively you can add that to your .gitconfig:
[alias]
archive-gz=!git archive --prefix="$(basename "$(dirname "$(readlink -m "$(git rev-parse --git-dir)")")")"/ HEAD | gzip -c
It will use the name of the directory containing your .git/ directory as a
prefix, and compress it using gzip to stdout.
git archive-gz > myproject.tar.gz will do what you want.
See, that's the point about git having so many flags. You only need to
look the man page _once_ (despite what you pretend): the one time you
need to write your convenient wrapper around git commands that suits
your exact needs.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Problem with "dashless options"
From: Pierre Habouzit @ 2009-09-09 22:49 UTC (permalink / raw)
To: Henrik Tidefelt; +Cc: Jeff King, git
In-Reply-To: <4EEF55B5-46E1-4C06-AA60-62F700F7B279@isy.liu.se>
[-- Attachment #1: Type: text/plain, Size: 935 bytes --]
On Wed, Sep 09, 2009 at 11:12:12PM +0200, Henrik Tidefelt wrote:
> No, but it is mapped to WHITE FROWNING FACE; I guess I defined it so
> to avoid the trouble I was previously experiencing from accidentally
> typing the instead of space without being able to see the
> difference on screen. Why would it matter?
well because then one of your space could have been that, and the shell
doesn't consider non breakable space as .. breakable, hence you can read
something where you believe there is (n+1) arguments but the shell (and
git) see only n.
It often yields errors really hard to grasp like the dreaded:
$ ls | grep
zsh: command not found: grep
notice the ^
sorry then I don't really know what happened...
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Wincent Colaiuta @ 2009-09-09 22:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Brendan Miller, git
In-Reply-To: <m3fxavvl5k.fsf@localhost.localdomain>
El 09/09/2009, a las 23:54, Jakub Narebski escribió:
> Brendan Miller <catphive@catphive.net> writes:
>
>> 5. Most commands require lots of flags, and don't have reasonable
>> defaults. e.g. archive.
>>
>> git archive --format=tar --prefix=myproject/ HEAD | gzip
>> >myproject.tar.gz
>>
>> Should just be:
>> git archive
>> run from the root of the repo.
>
> I'd rather not have "git archive" work without specifying tree-ish.
Why, out of interest? I would've thought that HEAD would be a pretty
good default, although I confess that I have never used "git archive"
without specifying a particular signed tag.
Cheers,
Wincent
^ permalink raw reply
* Re: [StGit PATCH] Add import -p option
From: Catalin Marinas @ 2009-09-09 22:09 UTC (permalink / raw)
To: Karl Wiberg; +Cc: Gustav Hållberg, Git Mailing List
In-Reply-To: <20090908223714.GA6364@diana.vm.bytemark.co.uk>
2009/9/8 Karl Wiberg <kha@treskal.com>:
> On 2009-09-08 22:43:39 +0100, Catalin Marinas wrote:
>
>> This patch renames some of the existing import options and adds the
>> -p (--strip) option which allows stripping the leading slashes of
>> the diff paths.
>
> Looks good (and the intent is very good). The import test should
> probably be augmented with a test case for -pN, though.
Yes. I'll try to add one. As you noticed, not all options are tested.
>> + if strip:
>> + cmd += ['-p', strip]
>
> This test should probably be "if strip != None". It doesn't _really_
> matter, technically, since -p0 is the default, but still ...
I modified it after posting the patch. The git default is -p1, so we
would miss the -p0 case.
--
Catalin
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Sverre Rabbelier @ 2009-09-09 21:58 UTC (permalink / raw)
To: Brendan Miller; +Cc: git
In-Reply-To: <ef38762f0909091427m5b8f3am72c88fd4dbfebc59@mail.gmail.com>
Heya,
On Wed, Sep 9, 2009 at 23:27, Brendan Miller<catphive@catphive.net> wrote:
> 1. cloning from a new empty repo fails, and so do a lot of other
> operations. This adds unnecessary steps to setting up a new shared
> repo.
Actually, it works in recent git.
> 2. git --bare init. The flag goes before the operation unlike every other flag?
Because unlike most flags it applies to anything git does, e.g. 'git
--bare status' to treat the current directory as a git repository
rather than looking for a .git directory.
> 4. The index is inconsistently referred to as too many different
> things (cache, index, staging area) and only the last one makes any
> intuitive sense to a new user. This is partially a CLI issue, and
> partially a documentation issue, but both add up to cause confusion.
>
> 5. Most commands require lots of flags, and don't have reasonable
> defaults. e.g. archive.
Most git commands need no more than two flags, and the defaults are
reasonable to me; of course everybody has different needs, git
aliasses make it easy to overcome this.
> This is what I want to do 90% of the time, so it should just have the
> proper defaults, and not make me look at the man page every time I
> want to use it.
Again, make an alias if you use it a lot; it might be what _you_ want
to do, but as you can see from the plethora of other examples, it is
perhaps not what everybody else wants to do 90% of the time.
> 6. Where is the bug tracker? If people users can't find the bug
> tracker, they can't report issues, and obnoxious bugs go unfixed, or
> people have to whine on the mailing list. There should be a nice big
> link on the front page of git-scm.com. A bug tracker is really the
> only way for the vast majority of a community that use a tool can give
> feedback on the problems the tool has.
Nope, that's not how things work for us. We _want_ people to 'whine'
on the mailing list, so that if they really don't care that much about
something, it is "dropped on the floor" (because the thread becomes
stale) after a while, and we move on. Bug trackers are notorious for
growing in size very fast, and becoming cluttered (I have experience
with this as well, and am very pleased with how the git's mailing list
approach solves this).
> 7. Man pages: It's nice we have them, but we shouldn't need them to do
> basic stuff. I rarely had to look at the man pages using svn, but
> every single time I use git I have to dig into these things. Frankly,
> I have better things to do than RTFM.
Honestly, you never had to consult the help for svn? Perhaps the help
was not in a man page, but in some obscure website online; I for one
welcome our on-disk information bringing overlords.
> 8. There's no obvious way to make a remote your default push pull
> location without editing the git config file. Why not just something
> like
> It's ok to have kind of a weak UI on a new tool, when people are busy
> adding basic functionality. However, at this point git already has way
> more features than most of the competition, and the needless
> complexity of the CLI is the biggest issue in day to day use.
If you don't need all that functionality, why not just use one of them
fancy GUI's out there?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Jakub Narebski @ 2009-09-09 21:54 UTC (permalink / raw)
To: Brendan Miller; +Cc: git
In-Reply-To: <ef38762f0909091427m5b8f3am72c88fd4dbfebc59@mail.gmail.com>
Brendan Miller <catphive@catphive.net> writes:
> Here are a bunch of really basic usability issues I have with git:
First question: which git version do you use?
> 1. cloning from a new empty repo fails, and so do a lot of other
> operations. This adds unnecessary steps to setting up a new shared
> repo.
I think it works in modern git (where modern might mean 'master',
i.e. not yet released version)
>
> 2. git --bare init. The flag goes before the operation unlike every
> other flag?
"git init --bare" works in fit version 1.6.4.2
In "git --bare init" the --bare option is to 'git' wrapper, not to
git-init command (see git(1)):
--bare Treat the repository as a bare repository. If GIT_DIR
environment is not set, it is set to the current working
directory.
>
> 3. It's not obvious whether operations work on the working
> directory/the "index"/the repository
> e.g. get reset --soft, --mixed, --hard. git diff --cached
There is "git diff --staged" synonym for "git diff --cached"
>
> 4. The index is inconsistently referred to as too many different
> things (cache, index, staging area) and only the last one makes any
> intuitive sense to a new user. This is partially a CLI issue, and
> partially a documentation issue, but both add up to cause confusion.
Usage of '--index' and '--cached' in CLI is consistent, and different.
See gitcli(7) manpage.
Some of those inconsistences are historical remainings (I think we got
rid of 'dircache' and 'ent'). Do you offer to do a cleanup?
>
> 5. Most commands require lots of flags, and don't have reasonable
> defaults. e.g. archive.
>
> git archive --format=tar --prefix=myproject/ HEAD | gzip >myproject.tar.gz
>
> Should just be:
> git archive
> run from the root of the repo.
I'd rather not have "git archive" work without specifying tree-ish.
As for having to do compression using separate program: do one thing
and do it well is UNIX philosophy, and Git is UNIX-y tool.
BTW. git-archive _has_ default format type (and empty prefix by
default).
>
> This is what I want to do 90% of the time, so it should just have the
> proper defaults, and not make me look at the man page every time I
> want to use it.
You learn those idioms.
>
> 6. Where is the bug tracker? If people users can't find the bug
> tracker, they can't report issues, and obnoxious bugs go unfixed, or
> people have to whine on the mailing list. There should be a nice big
> link on the front page of git-scm.com. A bug tracker is really the
> only way for the vast majority of a community that use a tool can give
> feedback on the problems the tool has.
Do you offer to maintain and manage such bug tracker? I mean here
taking care of duplicated bugs, tracking which bugs are resolved and
which are not, checking if bug is reproductible, etc. Do you?
Unmaintained bugtracker is worse than useless.
Using mailing list for bug reports and for patches is time-honored
workflow, which works rather well for smaller projects such as Git.
Note that git mailing list is free for all; you don't need to
subscribe to send, and you can watch it via many archives and gateways
(like GMane).
>
> 7. Man pages: It's nice we have them, but we shouldn't need them to do
> basic stuff. I rarely had to look at the man pages using svn, but
> every single time I use git I have to dig into these things. Frankly,
> I have better things to do than RTFM.
Learn. If you learn the philosophy behind git design, you would have
much easier understanding and remembering git.
There is "Git User's Manual", "The Git Community Book", "Pro Git" and
many other references.
>
> 8. There's no obvious way to make a remote your default push pull
> location without editing the git config file. Why not just something
> like
origin is default, I think.
>
> git remote setdefault origin
>
> or even
>
> git remote add --default origin http://somegiturl.org/
>
> This come up in the use case where I:
> 1. set up a remote bare repo
> 2. push from my local repo, and thence forth want to keep local and
> remote in sink.
>
> Right now I have to modify .git/config to do this.
And?
> It's ok to have kind of a weak UI on a new tool, when people are busy
> adding basic functionality. However, at this point git already has way
> more features than most of the competition, and the needless
> complexity of the CLI is the biggest issue in day to day use.
Creating good UI is not easy, especially if you are limited by
backward compatibility.
--
Jakub Narebski
Git User's Survey 2009: http://tinyurl.com/GitSurvey2009
^ permalink raw reply
* Re: [PATCH 1/2] push: make non-fast-forward help message configurable
From: Junio C Hamano @ 2009-09-09 21:47 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Nanako Shiraishi, Matthieu Moy, Teemu Likonen,
git
In-Reply-To: <20090909203939.GA10438@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... It also turns typo-checking into
> a run-time error rather than a compile-time error, which is IMHO a bad
> idea. And if you care about such things, it is worse for using something
> like ctags to find variable uses.
Fair enough.
^ permalink raw reply
* obnoxious CLI complaints
From: Brendan Miller @ 2009-09-09 21:27 UTC (permalink / raw)
To: git
Here are a bunch of really basic usability issues I have with git:
1. cloning from a new empty repo fails, and so do a lot of other
operations. This adds unnecessary steps to setting up a new shared
repo.
2. git --bare init. The flag goes before the operation unlike every other flag?
3. It's not obvious whether operations work on the working
directory/the "index"/the repository
e.g. get reset --soft, --mixed, --hard. git diff --cached
4. The index is inconsistently referred to as too many different
things (cache, index, staging area) and only the last one makes any
intuitive sense to a new user. This is partially a CLI issue, and
partially a documentation issue, but both add up to cause confusion.
5. Most commands require lots of flags, and don't have reasonable
defaults. e.g. archive.
git archive --format=tar --prefix=myproject/ HEAD | gzip >myproject.tar.gz
Should just be:
git archive
run from the root of the repo.
This is what I want to do 90% of the time, so it should just have the
proper defaults, and not make me look at the man page every time I
want to use it.
6. Where is the bug tracker? If people users can't find the bug
tracker, they can't report issues, and obnoxious bugs go unfixed, or
people have to whine on the mailing list. There should be a nice big
link on the front page of git-scm.com. A bug tracker is really the
only way for the vast majority of a community that use a tool can give
feedback on the problems the tool has.
7. Man pages: It's nice we have them, but we shouldn't need them to do
basic stuff. I rarely had to look at the man pages using svn, but
every single time I use git I have to dig into these things. Frankly,
I have better things to do than RTFM.
8. There's no obvious way to make a remote your default push pull
location without editing the git config file. Why not just something
like
git remote setdefault origin
or even
git remote add --default origin http://somegiturl.org/
This come up in the use case where I:
1. set up a remote bare repo
2. push from my local repo, and thence forth want to keep local and
remote in sink.
Right now I have to modify .git/config to do this.
It's ok to have kind of a weak UI on a new tool, when people are busy
adding basic functionality. However, at this point git already has way
more features than most of the competition, and the needless
complexity of the CLI is the biggest issue in day to day use.
Brendan
^ permalink raw reply
* Re: Problem with "dashless options"
From: Henrik Tidefelt @ 2009-09-09 21:12 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Jeff King, git
In-Reply-To: <20090909163001.GE4859@laphroaig.corp>
No, but it is mapped to WHITE FROWNING FACE; I guess I defined it so
to avoid the trouble I was previously experiencing from accidentally
typing the instead of space without being able to see the
difference on screen. Why would it matter?
Henrik
On 09-09-09, at 18:30 , Pierre Habouzit wrote:
> On Wed, Sep 09, 2009 at 06:26:37PM +0200, Henrik Tidefelt wrote:
>> Yes, that was a strange error. I applied the patch, but could not
>> reproduce the error any more. Also, Gustaf Hendeby built git
>> directly from the git distribution (not via MacPorts) on my machine,
>> and could not reproduce the error. Then I simply tried to clean and
>> build the git from MacPorts again, and voila!, now it works.
>> Something very strange must have happened during the previous build.
>
> Are you using a keyboard mapping where AltGr+space produces an
> ?
>
> --
> ·O· Pierre Habouzit
> ··O madcoder@debian.org
> OOO http://www.madism.org
^ permalink raw reply
* Re: [ JGIT ] incompatiblity found in DirCache
From: Robin Rosenberg @ 2009-09-09 21:11 UTC (permalink / raw)
To: Adam W. Hawks, spearce; +Cc: git
In-Reply-To: <4AA7FA2B.4090707@writeme.com>
onsdag 09 september 2009 20:55:39 skrev "Adam W. Hawks" <awhawks@writeme.com>:
> When using the DirCache interface to the index you can create a invalid/corrupt tree for git 1.6.5.
>
> The problem seems to be you can add a path to the index that starts with a "/" and DirCache creates a entry with a mode but no path.
> This causes git 1.6.5 to fail with a corrupt tree.
I think there are more ways of entering bad stuff. Preventing a deliberate programmatic creation of invalid trees is probably not the most important
thing, but then again, validating the data to prevent e.g. the EGit plugin from doing it by mistake due to bugs could probably
be worthwhile.
-- robin
^ permalink raw reply
* Re: [PATCH 1/2] push: make non-fast-forward help message configurable
From: Jeff King @ 2009-09-09 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <7vr5ugszte.fsf@alter.siamese.dyndns.org>
On Wed, Sep 09, 2009 at 12:06:21PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > diff --git a/advice.c b/advice.c
> > new file mode 100644
> > index 0000000..b5216a2
> > --- /dev/null
> > +++ b/advice.c
> > @@ -0,0 +1,25 @@
> > +#include "cache.h"
> > +
> > +int advice_push_nonfastforward = 1;
> > +
> > +static struct {
> > + const char *name;
> > + int *preference;
> > +} advice_config[] = {
> > + { "pushnonfastforward", &advice_push_nonfastforward },
> > +};
>
> Can we have the value inside this struct, instead of having a pointer
> to another variable, and get rid of that variable altogether?
We could, but then callers need some way of indexing into the array.
Which means either:
- a constant offset (like "#define ADVICE_PUSH_NONFASTFORWARD 0"). The
problem with that is you get no compile-time support for making sure
that your index matches the variable you want. I.e., you have:
{ "pushnonfastforward", 1 } /* ADVICE_PUSH_NONFASTFORWARD */
with the position in the array implicitly matching the manually
assigned numbers. We do have precedent in things like diff_colors.
I don't remember if we have ever screwed it up.
- a dynamic offset, like (as you noted):
> If we did so, this part needs to become
>
> if (nonfastforward && check_advice("pushnonfastforward")) {
>
> which would be less efficient, but by definition advices are on the slow
> path, right?
which, as you note, is less efficient. It also turns typo-checking into
a run-time error rather than a compile-time error, which is IMHO a bad
idea. And if you care about such things, it is worse for using something
like ctags to find variable uses.
I went the way I did because it provides compile-time checking, and
because the variable is referred to by name in the table, the matching
is explicit and thus harder to screw up.
One final option would be to get rid of the table altogether. Its
function is to allow you to iterate over all of the variables. Now that
the "advice.all" option has been dropped, the only use is during config
parsing. We could simply unroll that loop to:
if (!strcmp(k, "pushnonfastforward")) {
advice_push_nonfastforward = git_config_bool(var, value);
return 0;
}
if (!strcmp(k, "statushints")) {
advice_status_hints = git_config_bool(var, value);
return 0;
}
as we do in other config parsing.
-Peff
^ permalink raw reply
* [PATCH] preserve mtime of local clone
From: Clemens Buchacher @ 2009-09-09 19:51 UTC (permalink / raw)
To: git; +Cc: msysgit, Junio C Hamano, Shawn O. Pearce
A local clone without hardlinks copies all objects, including dangling
ones, to the new repository. Since the mtimes are renewed, those
dangling objects cannot be pruned by "git gc --prune", even if they
would have been old enough for pruning in the original repository.
Instead, preserve mtime during copy. "git gc --prune" will then work
in the clone just like it would have in the original.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
I noticed this problem when I cloned a repo with lots of old dangling
objects onto a windows machine. git-gui immediately recommended running
git-gc, and I did. But each time I restarted git-gui, it recommended git-gc
again, because there were still plenty of dangling objects lying around
which could not be removed due to their recent mtimes.
So there is actually a problem with git-gui's recommendation. Especially on
Windows, where it only checks for 1 or more files in .git/objects/42 (as
opposed to 8 files on other platforms). The probability of that happening if
the repo contains about 100 loose objects is 1-(254/255)^100 = 32%. The
probability for the same to happen with at least 2 files is only 6% [*].
Maybe that would be a good compromise?
Alternatively, git-gc could remember the number of dangling objects, and
git-gui can adjust its recommendation accordingly, taking that number and
the date of the lastest repack into account.
Clemens
[*] The following octave script shows the probability for m or more objects
to be in .git/objects/42 for a total of n objects.
m = [1 2 8];
n = 100:100:3000;
P = zeros(length(n), length(m));
for k = 1:length(n)
P(n(k), :) = 1-binocdf(m-1, n(k), 1/255);
end
plot(n, P);
n \ m 1 2 8
100 32% 6% 0%
500 86% 58% 0%
1000 98% 90% 5%
2000 100% 100% 55%
---
builtin-clone.c | 2 +-
builtin-init-db.c | 2 +-
cache.h | 6 ++++--
copy.c | 25 ++++++++++++++++++++++---
lockfile.c | 2 +-
rerere.c | 2 +-
6 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index ad04808..cb3c895 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -269,7 +269,7 @@ static void copy_or_link_directory(struct strbuf *src, struct strbuf *dest)
die_errno("failed to create link '%s'", dest->buf);
option_no_hardlinks = 1;
}
- if (copy_file(dest->buf, src->buf, 0666))
+ if (copy_file(dest->buf, src->buf, 0666, 1))
die_errno("failed to copy file to '%s'", dest->buf);
}
closedir(dir);
diff --git a/builtin-init-db.c b/builtin-init-db.c
index dd84cae..5deb81d 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -100,7 +100,7 @@ static void copy_templates_1(char *path, int baselen,
die_errno("cannot symlink '%s' '%s'", lnk, path);
}
else if (S_ISREG(st_template.st_mode)) {
- if (copy_file(path, template, st_template.st_mode))
+ if (copy_file(path, template, st_template.st_mode, 0))
die_errno("cannot copy '%s' to '%s'", template,
path);
}
diff --git a/cache.h b/cache.h
index 5fad24c..1875c97 100644
--- a/cache.h
+++ b/cache.h
@@ -921,8 +921,10 @@ extern const char *git_mailmap_file;
/* IO helper functions */
extern void maybe_flush_or_die(FILE *, const char *);
-extern int copy_fd(int ifd, int ofd);
-extern int copy_file(const char *dst, const char *src, int mode);
+extern int copy_fd(int ifd, int ofd, int preserve_times);
+extern int copy_file(const char *dst, const char *src, int mode, int
+ preserve_times);
+extern int copy_times(int ofd, int ifd);
extern ssize_t read_in_full(int fd, void *buf, size_t count);
extern ssize_t write_in_full(int fd, const void *buf, size_t count);
extern void write_or_die(int fd, const void *buf, size_t count);
diff --git a/copy.c b/copy.c
index e54d15a..fe0380e 100644
--- a/copy.c
+++ b/copy.c
@@ -1,6 +1,6 @@
#include "cache.h"
-int copy_fd(int ifd, int ofd)
+int copy_fd(int ifd, int ofd, int preserve_times)
{
while (1) {
char buffer[8192];
@@ -31,11 +31,18 @@ int copy_fd(int ifd, int ofd)
}
}
}
+ if (preserve_times && copy_times(ofd, ifd)) {
+ int time_error = errno;
+ close(ifd);
+ return error("copy-fd: failed to preserve times: %s",
+ strerror(time_error));
+ }
close(ifd);
return 0;
}
-int copy_file(const char *dst, const char *src, int mode)
+int copy_file(const char *dst, const char *src, int mode,
+ int preserve_times)
{
int fdi, fdo, status;
@@ -46,7 +53,7 @@ int copy_file(const char *dst, const char *src, int mode)
close(fdi);
return fdo;
}
- status = copy_fd(fdi, fdo);
+ status = copy_fd(fdi, fdo, preserve_times);
if (close(fdo) != 0)
return error("%s: close error: %s", dst, strerror(errno));
@@ -55,3 +62,15 @@ int copy_file(const char *dst, const char *src, int mode)
return status;
}
+
+int copy_times(int ofd, int ifd)
+{
+ struct stat st;
+ struct timespec times[2];
+ if (fstat(ifd, &st))
+ return -1;
+ times[0].tv_nsec = UTIME_OMIT;
+ times[1].tv_sec = st.st_mtime;
+ times[1].tv_nsec = ST_MTIME_NSEC(st);
+ return futimens(ofd, times);
+}
diff --git a/lockfile.c b/lockfile.c
index eb931ed..c7bbd4d 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -196,7 +196,7 @@ int hold_lock_file_for_append(struct lock_file *lk, const char *path, int flags)
close(fd);
return error("cannot open '%s' for copying", path);
}
- } else if (copy_fd(orig_fd, fd)) {
+ } else if (copy_fd(orig_fd, fd, 0)) {
if (flags & LOCK_DIE_ON_ERROR)
exit(128);
close(fd);
diff --git a/rerere.c b/rerere.c
index 87360dc..d25f5f1 100644
--- a/rerere.c
+++ b/rerere.c
@@ -326,7 +326,7 @@ static int do_plain_rerere(struct string_list *rr, int fd)
continue;
fprintf(stderr, "Recorded resolution for '%s'.\n", path);
- copy_file(rerere_path(name, "postimage"), path, 0666);
+ copy_file(rerere_path(name, "postimage"), path, 0666, 0);
mark_resolved:
rr->items[i].util = NULL;
}
--
1.6.4.2.266.gbaa17
^ permalink raw reply related
* Re: [PATCH] git.el: Use git-add-file for unmerged files, remove git-resolve-file
From: Junio C Hamano @ 2009-09-09 19:10 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: Martin Nordholts, git
In-Reply-To: <87ocpk6qwe.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I do not know all the details of how Emacs keybinding works, but I had an
>> impression that something-x sequence is triggered if you type something-X
>> and you do not have an explicit binding for something-X but you do have a
>> binding for something-x.
>>
>> IOW, if I only have
>>
>> (define-key global-map "\C-xc" 'compile)
>>
>> then both "\C-xc" and "\C-xC" runs "compile", but in addition to the
>> above if I also have
>>
>> (define-key global-map "\C-xC" 'grep-find)
>>
>> then I can invoke these two commands with lower- and upper- case 'c/C'
>> after control-x.
>>
>> If people have been relying on the historical behaviour that typing "R"
>> marked the path resolved (which may internally have been implemented with
>> whatever way), and if you are removing that binding, wouldn't that now
>> expose them to whatever happens to be bound to "r"?
>
> No, I don't claim to understand exactly how that works for the C-x case,
> but it doesn't apply here, "r" and "R" are two different bindings.
Thanks. I just wanted to make sure that a user who is used to typing "R"
won't get the file removed with the new code.
^ permalink raw reply
* Re: Issue 323 in msysgit: Can't clone over http
From: Junio C Hamano @ 2009-09-09 19:08 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: Junio C Hamano, git, msysgit, Tom Preston-Werner, Jakub Narebski
In-Reply-To: <20090909203350.e3d7e5dc.rctay89@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> I still think github.com should look into this issue (of differing
> responses for HEAD and GET requests).
>
> -- >8 --
>
> Subject: [PATCH] http.c: remove verification of remote packs
>
> Make http.c::fetch_pack_index() no longer check for the remote pack
> with a HEAD request before fetching the corresponding pack index file.
>
> Not only does sending a HEAD request before we do a GET incur a
> performance penalty, it does not offer any significant error-
> prevention advantages (pack fetching in the *_http_pack_request()
> methods is capable of handling any errors on its own).
>
> This addresses an issue raised elsewhere:
>
> http://code.google.com/p/msysgit/issues/detail?id=323
> http://support.github.com/discussions/repos/957-cant-clone-over-http-or-git
>
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
> ---
>
> Junio, I'm not sure if the credits and references ("This addresses...")
> should be included, since the patch doesn't look like it's fixing any
> thing, even though it is a response to an acknowledged issue.
>
> Please remove those lines if you so wish.
I think the backstory deserves to be recorded in this case, which is what
you did.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] push: make non-fast-forward help message configurable
From: Junio C Hamano @ 2009-09-09 19:06 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090909113858.GA31051@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> diff --git a/advice.c b/advice.c
> new file mode 100644
> index 0000000..b5216a2
> --- /dev/null
> +++ b/advice.c
> @@ -0,0 +1,25 @@
> +#include "cache.h"
> +
> +int advice_push_nonfastforward = 1;
> +
> +static struct {
> + const char *name;
> + int *preference;
> +} advice_config[] = {
> + { "pushnonfastforward", &advice_push_nonfastforward },
> +};
Can we have the value inside this struct, instead of having a pointer
to another variable, and get rid of that variable altogether?
> diff --git a/builtin-push.c b/builtin-push.c
> index 787011f..6eda372 100644
> --- a/builtin-push.c
> +++ b/builtin-push.c
> @@ -157,7 +157,7 @@ static int do_push(const char *repo, int flags)
> continue;
>
> error("failed to push some refs to '%s'", url[i]);
> - if (nonfastforward) {
> + if (nonfastforward && advice_push_nonfastforward) {
If we did so, this part needs to become
if (nonfastforward && check_advice("pushnonfastforward")) {
which would be less efficient, but by definition advices are on the slow
path, right?
And check_advice() implementation can find programming errors by barfing
when the given string token does not exist in the table.
^ permalink raw reply
* [ JGIT ] incompatiblity found in DirCache
From: Adam W. Hawks @ 2009-09-09 18:55 UTC (permalink / raw)
To: git
When using the DirCache interface to the index you can create a invalid/corrupt tree for git 1.6.5.
The problem seems to be you can add a path to the index that starts with a "/" and DirCache creates a entry with a mode but no path.
This causes git 1.6.5 to fail with a corrupt tree.
The following code will create the problem
import java.io.File;
import java.io.IOException;
import java.util.Calendar;
import java.util.Date;
import java.util.TimeZone;
import org.spearce.jgit.dircache.DirCache;
import org.spearce.jgit.dircache.DirCacheBuilder;
import org.spearce.jgit.dircache.DirCacheEntry;
import org.spearce.jgit.lib.Commit;
import org.spearce.jgit.lib.FileMode;
import org.spearce.jgit.lib.ObjectId;
import org.spearce.jgit.lib.ObjectWriter;
import org.spearce.jgit.lib.PersonIdent;
import org.spearce.jgit.lib.RefUpdate;
import org.spearce.jgit.lib.Repository;
import org.spearce.jgit.lib.RefUpdate.Result;
public class BuildTest
{
private Repository db;
public static void main(String[] args)
{
BuildTest bt = new BuildTest();
bt.doit();
}
public void doit()
{
Date when = Calendar.getInstance().getTime();
File gitDir = new File("gitProblem/.git");
gitDir.mkdirs();
try
{
db = new Repository(gitDir);
db.create(true);
DirCache dirc = DirCache.newInCore();
DirCacheBuilder dcb = dirc.builder();
byte[] data = "Some File data".getBytes();
ObjectWriter ow = new ObjectWriter(db);
ObjectId dataId = ow.writeBlob(data);
DirCacheEntry newEntry = new DirCacheEntry("/someDir/someFile");
newEntry.setAssumeValid(false);
newEntry.setFileMode(FileMode.REGULAR_FILE);
newEntry.setLastModified(when.getTime());
newEntry.setLength(data.length);
newEntry.setObjectId(dataId);
dcb.add(newEntry );
dcb.finish();
dirc = dcb.getDirCache();
PersonIdent pi = new PersonIdent("someonw","someone@somewhere",when,TimeZone.getDefault());
ObjectId tree = dirc.writeTree(new ObjectWriter(db));
Commit commit = new Commit(db);
commit.setAuthor(pi);
commit.setCommitter(pi);
commit.setMessage("This causes a corrupt tree");
commit.setTreeId(tree);
commit.commit();
ObjectId cid = commit.getCommitId();
RefUpdate ru = db.updateRef("refs/heads/master");
ru.setExpectedOldObjectId(ObjectId.zeroId());
ru.setNewObjectId(cid);
ru.setRefLogIdent(pi);
ru.setRefLogMessage("some reflog message", true);
Result result = ru.update();
System.out.println("Result = "+result.toString());
}
catch (IOException e)
{
System.out.println(e);
e.printStackTrace();
System.exit(1);
}
}
}
^ permalink raw reply
* Re: Problem with "dashless options"
From: Pierre Habouzit @ 2009-09-09 16:30 UTC (permalink / raw)
To: Henrik Tidefelt; +Cc: Jeff King, git
In-Reply-To: <AB9C50E3-E2BB-4449-B8F9-75777ADE1602@isy.liu.se>
On Wed, Sep 09, 2009 at 06:26:37PM +0200, Henrik Tidefelt wrote:
> Yes, that was a strange error. I applied the patch, but could not
> reproduce the error any more. Also, Gustaf Hendeby built git
> directly from the git distribution (not via MacPorts) on my machine,
> and could not reproduce the error. Then I simply tried to clean and
> build the git from MacPorts again, and voila!, now it works.
> Something very strange must have happened during the previous build.
Are you using a keyboard mapping where AltGr+space produces an ?
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
^ permalink raw reply
* Re: Problem with "dashless options"
From: Henrik Tidefelt @ 2009-09-09 16:26 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090909143455.GA10092@sigill.intra.peff.net>
Yes, that was a strange error. I applied the patch, but could not
reproduce the error any more. Also, Gustaf Hendeby built git
directly from the git distribution (not via MacPorts) on my machine,
and could not reproduce the error. Then I simply tried to clean and
build the git from MacPorts again, and voila!, now it works.
Something very strange must have happened during the previous build.
I am sorry for taking your time.
Henrik
On 9Sep , 2009, at 16:34 , Jeff King wrote:
> On Wed, Sep 09, 2009 at 03:21:30PM +0200, Henrik Tidefelt wrote:
>
>> Yesterday I installed a fresh git (1.6.4.2) on my system using
>> MacPorts. Some of the git sub-commands work fine (for instance,
>> checkout, status, remote), while push gives an error as follows:
>>
>> $ git push isy next
>> fatal: BUG: dashless options don't support arguments
>
> Hmm. Very strange. The only code path that triggers this is an option
> declared with PARSE_OPT_NODASH but not PARSE_OPT_NOARG. But there are
> only two options in all of git that use PARSE_OPT_NODASH, and:
>
> 1. They are in git grep, not git push.
>
> 2. They correctly have PARSE_OPT_NOARG set.
>
> Which leads me to believe that something is writing random cruft on
> top
> of the options struct. Either a stack overflow, or some issue
> related to
> your compiler (either a bug in the compiler, or something non-portable
> we are doing).
>
> Can you try applying the patch below which will at least give us a bit
> more information about the offending option?
>
> Also, does 1.6.4.1 work OK? Or any other earlier version? If so,
> can you
> try bisecting?
>
> diff --git a/parse-options.c b/parse-options.c
> index f7ce523..e93eb67 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -275,7 +275,15 @@ static int parse_nodash_opt(struct
> parse_opt_ctx_t *p, const char *arg,
> continue;
> if ((options->flags & PARSE_OPT_OPTARG) ||
> !(options->flags & PARSE_OPT_NOARG))
> - die("BUG: dashless options don't support arguments");
> + die("BUG: dashless options don't support arguments\n"
> + "buggy option is:\n"
> + " type: %d\n"
> + " short_name: %c\n"
> + " long_name: %s\n"
> + " flags: %d\n",
> + options->type, options->short_name,
> + options->long_name, options->flags
> + );
> if (!(options->flags & PARSE_OPT_NONEG))
> die("BUG: dashless options don't support negation");
> if (options->long_name)
^ permalink raw reply
* Re: [PATCH] git.el: Use git-add-file for unmerged files, remove git-resolve-file
From: Alexandre Julliard @ 2009-09-09 16:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Nordholts, git
In-Reply-To: <7vtyzdrq1h.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I do not know all the details of how Emacs keybinding works, but I had an
> impression that something-x sequence is triggered if you type something-X
> and you do not have an explicit binding for something-X but you do have a
> binding for something-x.
>
> IOW, if I only have
>
> (define-key global-map "\C-xc" 'compile)
>
> then both "\C-xc" and "\C-xC" runs "compile", but in addition to the
> above if I also have
>
> (define-key global-map "\C-xC" 'grep-find)
>
> then I can invoke these two commands with lower- and upper- case 'c/C'
> after control-x.
>
> If people have been relying on the historical behaviour that typing "R"
> marked the path resolved (which may internally have been implemented with
> whatever way), and if you are removing that binding, wouldn't that now
> expose them to whatever happens to be bound to "r"?
No, I don't claim to understand exactly how that works for the C-x case,
but it doesn't apply here, "r" and "R" are two different bindings.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* git-cvsserver man page needs examples...
From: david.hagood @ 2009-09-09 16:00 UTC (permalink / raw)
To: git
I'm trying to work out how I can use git-cvsserver on a local repository
to allow a stupid program that only understands CVS to work.
I've looked over the man page, but it really isn't clear as to what the
command lines and settings would look like. There seems to be a lot of
assumptions in the man page that aren't spelled out, such as the
assumption that you are making a repo available to many other hosts.
There is the tantalizing hint that "you can rename git-cvsserver to cvs"
which would lead me to believe that I might just be able to point the
stupid program at git-cvsserver and be done with it, but that doesn't
really seem clear.
It also isn't clear what effect operations on the repo, such as "git
checkout", would have on the view that the CVS client sees - if any at
all.
Then there is the statement "You also need to ensure that each repository
is "bare" (without a git index file) for cvs commit to work." Does that
mean that I have to have a repository that operates differently for CVS
commit to work than a standard repository for local use?
Might I suggest that the man page either contain or point to some examples
of using git-cvsserver for different use cases, such as:
local repo and server, for stupid programs that speak CVS but not GIT.
local repo and server exporting to other workstations.
I haven't found any good examples on-line of how to achieve these goals -
just reiterations of the man pages.
^ permalink raw reply
* [PATCH] rebase: use plumbing to show dirty state
From: Jeff King @ 2009-09-09 14:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
Commit 4cfbe06 introduced the use of "git diff" to show
dirty state in a format more familiar to users. However, it
should have used the plumbing "git diff-files" instead.
Not only is it good practice in general to use plumbing in
scripts, but in this case we really don't want the automatic
pager to kick in for an error message.
Signed-off-by: Jeff King <peff@peff.net>
---
I got quite a surprise when I ran "git rebase" and was presented with a
pager with nothing but:
M foo.c
in it. I suspect this issue wasn't noticed while testing because most
people use "-FX" with "less", so their short list of dirty files causes
the pager to exit immediately.
git-rebase.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 2315d95..6ec155c 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -387,7 +387,7 @@ fi
# The tree must be really really clean.
if ! git update-index --ignore-submodules --refresh > /dev/null; then
echo >&2 "cannot rebase: you have unstaged changes"
- git diff --name-status -r --ignore-submodules -- >&2
+ git diff-files --name-status -r --ignore-submodules -- >&2
exit 1
fi
diff=$(git diff-index --cached --name-status -r --ignore-submodules HEAD --)
--
1.6.5.rc0.166.ge65f.dirty
^ 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