* Re: [PATCH 01/12] git-grep: read config
From: Sverre Rabbelier @ 2008-07-24 19:12 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jeff King, git
In-Reply-To: <fcaeb9bf0807241203yd57e675j964594c501ce59a2@mail.gmail.com>
On Thu, Jul 24, 2008 at 9:03 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 7/25/08, Sverre Rabbelier <alturin@gmail.com> wrote:
>> On Thu, Jul 24, 2008 at 8:45 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> >
>>
>> Something went wrong replying here possibly? Or is it just me who is
>> receiving empty messages? (At least the 3rd empty mail I see.)
>
> I blame gmail MTA or my name's having non-ascii chars in it. Combining
> those two, it produces base64-encoded messages, which are usually
> refused by vger.
Curiously enough, in the first mail there -are- non-asci characters in
your name, in the 'empty' mail there are non, instead the 'letter
decorations' were removed.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 01/12] git-grep: read config
From: Nguyen Thai Ngoc Duy @ 2008-07-24 19:07 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080724185844.GC21186@sigill.intra.peff.net>
On 7/25/08, Jeff King <peff@peff.net> wrote:
> On Fri, Jul 25, 2008 at 01:45:58AM +0700, Nguyen Thai Ngoc Duy wrote:
>
> > > The commit message is a bit lacking...what config are we interested in?
> >
> > core.sparsecheckout, but I will probably stay away from config.
>
>
> Right, I kind of guessed that from reading the rest of the series. But
> that sort of "why" really should go into the commit message.
There was "why" in the commit before but I wanted to make the first
two patches independent to this series. Turns out bad, I think :)
--
Duy
^ permalink raw reply
* Re: [PATCH 01/12] git-grep: read config
From: Nguyen Thai Ngoc Duy @ 2008-07-24 19:03 UTC (permalink / raw)
To: sverre; +Cc: Jeff King, git
In-Reply-To: <bd6139dc0807241153v5055e922p69a176b5b706f98e@mail.gmail.com>
On 7/25/08, Sverre Rabbelier <alturin@gmail.com> wrote:
> On Thu, Jul 24, 2008 at 8:45 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> >
>
> Something went wrong replying here possibly? Or is it just me who is
> receiving empty messages? (At least the 3rd empty mail I see.)
I blame gmail MTA or my name's having non-ascii chars in it. Combining
those two, it produces base64-encoded messages, which are usually
refused by vger.
--
Duy
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Sverre Rabbelier @ 2008-07-24 19:01 UTC (permalink / raw)
To: Petr Baudis
Cc: Johannes Schindelin, Jeff King, Nguy?n Thái Ng?c Duy, git
In-Reply-To: <20080724185332.GQ32184@machine.or.cz>
On Thu, Jul 24, 2008 at 8:53 PM, Petr Baudis <pasky@suse.cz> wrote:
> I don't follow how these two issues arise, if the server will do the
> pruning for you. It will just skip entering some tree objects when doing
> object traversal; why opening the git protocol or faking commits? This
> would be a simple extra capability in the protocol.
Wouldn't that be as simple as passing a pathspec to git-rev-list? Not
a lot of overhead there I reckon.
> One question is what to do with delta chains including unwanted
> objects, but I think that given the objects' associativity for delta
> chains, this shouldn't be huge practical issues and it could be
> affordable in principle to include even unwanted objects.
Just keep them? What we're doing here is trying to optimize in the
case that someone has a sparse checkout, nothing bad will happen if
they get too many info surely? (Save for them not getting as much
improvement as would have been possible would the pack have been
created differently.)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 18:59 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Johannes Schindelin, git
In-Reply-To: <32541b130807240922r733dce6aw8b123bbb28c9002@mail.gmail.com>
On 7/24/08, Avery Pennarun <apenwarr@gmail.com> wrote:
> On 7/24/08, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > OK. I am lost here. I do not know how putting sparse prefix and index
> > together could fix "it" (I think you meant the index guarding).
>
> [snip]
>
> The information required to do a checkout is in the index. And
> "sparse checkout" is all about checking out :)
That was better Dscho's questions ;) Thanks for the enlightenment.
--
Duy
^ permalink raw reply
* Re: [PATCH 01/12] git-grep: read config
From: Jeff King @ 2008-07-24 18:58 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0807241145y16bb5f94q9f7e3c09c3184782@mail.gmail.com>
On Fri, Jul 25, 2008 at 01:45:58AM +0700, Nguyen Thai Ngoc Duy wrote:
> > The commit message is a bit lacking...what config are we interested in?
>
> core.sparsecheckout, but I will probably stay away from config.
Right, I kind of guessed that from reading the rest of the series. But
that sort of "why" really should go into the commit message.
-Peff
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Petr Baudis @ 2008-07-24 18:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Nguy?n Thái Ng?c Duy, git
In-Reply-To: <alpine.DEB.1.00.0807241837441.8986@racer>
Hi,
On Thu, Jul 24, 2008 at 06:41:03PM +0100, Johannes Schindelin wrote:
> On Thu, 24 Jul 2008, Jeff King wrote:
>
> > As a user, I would expect "sparse clone" to also be sparse on the
> > fetching. That is, to not even bother fetching tree objects that we are
> > not going to check out. But that is a whole other can of worms from
> > local sparseness, so I think it is worth saving for a different series.
>
> I think this is not even worth of a series. Sure, it would have benefits
> for those who want sparse checkouts. But it comes for a high price on
> everyone else:
>
> - security issues (you'd need to open the git protocol to give you
> something else than a ref, _including_ refs that were deleted)
>
> - performance issues (the server would have to do a lot more, faking
> commits, or in the alternative serving a gazillion more sessions if the
> client does the reconstruction)
I don't follow how these two issues arise, if the server will do the
pruning for you. It will just skip entering some tree objects when doing
object traversal; why opening the git protocol or faking commits? This
would be a simple extra capability in the protocol.
One question is what to do with delta chains including unwanted
objects, but I think that given the objects' associativity for delta
chains, this shouldn't be huge practical issues and it could be
affordable in principle to include even unwanted objects.
> ... and I am sure there are tons more issues.
I do agree on this. :-)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH 01/12] git-grep: read config
From: Sverre Rabbelier @ 2008-07-24 18:53 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jeff King, git
In-Reply-To: <fcaeb9bf0807241145y16bb5f94q9f7e3c09c3184782@mail.gmail.com>
On Thu, Jul 24, 2008 at 8:45 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>
Something went wrong replying here possibly? Or is it just me who is
receiving empty messages? (At least the 3rd empty mail I see.)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* git reset musings
From: Sverre Rabbelier @ 2008-07-24 18:51 UTC (permalink / raw)
To: Git Mailinglist
Heya,
After doing "git reset" you always get a whole bunch of lines saying
"foo: locally modified". Now I have a "OMG?!" reaction to that every
so often, where for a brief moment I think something went wrong. A bit
silly surely, but I suspect that some other users (especially those
new to git) have had similar reactions. Maybe it would be worth
letting the user know what's going on? E.g., before suddenly spitting
out an un-asked-for status report, let the user know that a status
report is following? Why not just do a 'git status' instead of this
we-hacked-up-a-quick-status-listing thing?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Lachele Foley (Lists) @ 2008-07-24 18:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jon Loeliger, git
In-Reply-To: <200807242018.27663.jnareb@gmail.com>
>> > 01. What country are you in?
>> > 02. What is your preferred non-programming language?
>> > (or) What is the language you want computer communicate with you?
>>
>> How about: What is your preferred natural language?
>
> Perhaps it is a better formulation. I am not native English speaker.
> (But so would be some people who would answer this survey).
According to Wikipedia
(http://en.wikipedia.org/wiki/Natural_language), "natural language"
could include, for example, bee dances. "...a language that is
spoken, written, or signed by animals for general-purpose
communication..." And, it might also exclude constructed languages
like Esperanto and Klingon. How about:
02. What language do you prefer to use when communicating with people?
In case there are, for example, any Klingons, sentient machines, etc.,
in the audience, the sentence does not assume the answerer is human...
:-) It's a tricky question to write.
I'm a total newbie here, by the way.
01. USA
02. Probably best I stick to English, but I'm willing to negotiate.
06. Not sure yet.
09. Last month. I think.
--
:-) Lachele
Lachele Foley
CCRC/UGA
^ permalink raw reply
* Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Nguyen Thai Ngoc Duy @ 2008-07-24 18:47 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080724171952.GB21043@sigill.intra.peff.net>
On 7/25/08, Jeff King <peff@peff.net> wrote:
> On Wed, Jul 23, 2008 at 09:57:18PM +0700, Nguyen Thai Ngoc Duy wrote:
>
> > + if (option_sparse_prefix) {
> > + git_config_set("core.sparsecheckout", option_sparse_prefix);
> > + set_sparse_prefix(option_sparse_prefix);
> > + }
> > +
>
>
> As a user, I would expect "sparse clone" to also be sparse on the
> fetching. That is, to not even bother fetching tree objects that we are
> not going to check out. But that is a whole other can of worms from
> local sparseness, so I think it is worth saving for a different series.
>
> So instead I would suggest that this be mentioned in the documentation
> for --path, but there doesn't seem to be any.
Thanks. Will mention it when I write documentation for this.
--
Duy
^ permalink raw reply
* Re: [PATCH 01/12] git-grep: read config
From: Nguyen Thai Ngoc Duy @ 2008-07-24 18:45 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080724171519.GA21043@sigill.intra.peff.net>
On 7/25/08, Jeff King <peff@peff.net> wrote:
> On Wed, Jul 23, 2008 at 09:55:35PM +0700, Nguyen Thai Ngoc Duy wrote:
>
> >
> > Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>
>
> The commit message is a bit lacking...what config are we interested in?
core.sparsecheckout, but I will probably stay away from config.
--
Duy
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Nguyen Thai Ngoc Duy @ 2008-07-24 18:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0807241837441.8986@racer>
On 7/25/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 24 Jul 2008, Jeff King wrote:
>
> > As a user, I would expect "sparse clone" to also be sparse on the
> > fetching. That is, to not even bother fetching tree objects that we are
> > not going to check out. But that is a whole other can of worms from
> > local sparseness, so I think it is worth saving for a different series.
>
> I think this is not even worth of a series. Sure, it would have benefits
> for those who want sparse checkouts. But it comes for a high price on
> everyone else:
>
> - security issues (you'd need to open the git protocol to give you
> something else than a ref, _including_ refs that were deleted)
>
> - performance issues (the server would have to do a lot more, faking
> commits, or in the alternative serving a gazillion more sessions if the
> client does the reconstruction)
>
> ... and I am sure there are tons more issues.
Widen checkout won't work and probably more.
--
Duy
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 18:42 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <20080724175714.GZ2925@dpotapov.dyndns.org>
On Thu, 24 Jul 2008, Dmitry Potapov wrote:
> On Wed, Jul 23, 2008 at 03:25:03AM +0200, Jakub Narebski wrote:
> >
> > Is there some channel that I have forgot about?
>
> If the start of this survey can be timed to release 1.6.0 then the
> announce about Git 1.6.0 release may also contain reference to that
> survey, and because release announcements are usually widely distributed
> by online magazines such as LinuxToday and LWN, anyone who is interested
> in Git will learn about this survey too.
You can send a story to LWN with two weeks notice; IIRC Git user's
Survey 2007 was announced in LWN around the middle of its duration.
I don't know about LinuxToday / Linux.com.
IIRC tentative date for 1.6.0 release is around August 10. It is
quite a bit of time from now. On the other hand that mean lot
of time to prepare questions, and to put survey on the web.
P.S. <tongue in cheek> are there enough of us to Digg / Mixx / Reddit
Git User's Survey 2008 announcement? ;-P </tongue in cheek>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Preserve cwd in setup_git_directory()
From: Nguyen Thai Ngoc Duy @ 2008-07-24 18:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Geoff Russell
In-Reply-To: <alpine.DEB.1.00.0807241506340.8986@racer>
On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
>
> > On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
>
> > > On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> > >
> > > > When GIT_DIR is not set, cwd is used to determine where .git is. If
> > > > core.worktree is set, setup_git_directory() needs to jump back to
> > > > the original cwd in order to calculate worktree, this leads to
> > > > incorrect .git location later in setup_work_tree().
> > >
> > > I do not understand. core.worktree is either absolute, in which case
> > > there is no problem. Or it is relative to where the config lives, no?
> >
> > The problem is GIT_DIR is not absolute in this case. So cwd must stay
> > where git dir is until it is absolute-ized by setup_work_tree().
>
>
> I do not see GIT_DIR being set in your test case at all.
>
> I do not see how get_git_work_tree() ro get_relative_cwd() should ever be
> allowed to chdir().
>
> _If_ they were (which I strongly doubt), they should chdir() back
> themselves.
>
> I now wasted easily 30 minutes just trying to make sense of your patch and
> your response. And I am still puzzled.
>
> Your commit message was of no help.
Alright, let's look at the code.
1. cwd is moved to toplevel working directory by setup_git_directory_gently()
2. setup_git_env() by default will set git_dir variable as ".git" as
part of check_repository_format_gently()
3. now in setup_git_directory() finds out core.worktree, it chdir()
to get relative prefix
4. setup_work_tree() sees that git_dir is not absolute path, it makes
git_dir absolute
If in step 3, it does not chdir(), step 4 will be right. In this case,
step 3 does chdir() and not going back, access to git repository will
fail as Geoff Russell discovered.
--
Duy
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Jeff King @ 2008-07-24 18:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <alpine.DEB.1.00.0807241837441.8986@racer>
On Thu, Jul 24, 2008 at 06:41:03PM +0100, Johannes Schindelin wrote:
> > As a user, I would expect "sparse clone" to also be sparse on the
> > fetching. That is, to not even bother fetching tree objects that we are
> > not going to check out. But that is a whole other can of worms from
> > local sparseness, so I think it is worth saving for a different series.
>
> I think this is not even worth of a series. Sure, it would have benefits
> for those who want sparse checkouts. But it comes for a high price on
> everyone else:
I agree there are a lot of issues. I am just thinking of the person who
said they had a >100G repository. But I am also not volunteering to do
it, so I will let somebody who really cares about it try to defend the
idea.
-Peff
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 18:18 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <48889591.9020208@freescale.com>
On Thu, 24 July 2008, Jon Loeliger wrote:
> Jakub Narebski wrote:
> >
> > About you
> >
> > 01. What country are you in?
> > 02. What is your preferred non-programming language?
> > (or) What is the language you want computer communicate with you?
>
> How about: What is your preferred natural language?
Perhaps it is a better formulation. I am not native English speaker.
(But so would be some people who would answer this survey).
The problem with this question is that people does not understand it,
and either do not answer or answer for example with computer language
(C, Perl, or something like that). For 2007 survey, when the question
was formulated as "02. What is your preferred non-programming language?"
there were 37 invalid responses (computer language), and 4 "not
understand" responses out of 662 people who answered this question.
On of the goals (besides curiosity about demographics) of this question
is to get to know if Git core should provide infrastructure for
translating messages, in addition to what already exists for git-gui
and gitk. But as currently there are no other questions about l10n
and i18n perhaps it would be better to simply remove this question.
> > 03. How old are you (in years)?
> > (free form, integer)
> > 04. Which programming languages you are proficient with?
>
> Perhaps:
> With which programming languages are you proficient?
Again: I am not native English speaker.
> > Getting started with GIT
> >
> > 05. How did you hear about Git?
> > (single choice?, in 2007 it was free-form)
> > - Linux kernel news (LKML, LWN, KernelTrap, KernelTraffic,...),
> > news site or magazine, blog entry, some project uses it,
> > presentation or seminar (real life, not on-line),
> > SCM research, IRC, mailing list, other Internet,
> > other off-line, other(*)
> > + the problem is with having not very long list (not too many
> > choices), but spanning all possibilities.
>
> So go more general? Don't specify actual news (web)sites.
I didn't mean here enumerating actual news (web)sites, but to provide
examples.
> Don't forge that there is a whole raft of Ruby-n-rails folks who
> are embracing Git these days too. They have their own whole 'nuther
> set of mailing lists, websites, (news) lists, etc.
>
> > + is this question interesting/important to have in survey?
>
> Look to the history to answer this question. Did we really
> learn anything from the earlier surveys by this question?
> Maybe it would make more sense to get a feel for which general
> camp led them to Git? That is, did they come from the Kernel
> side of the world, or Ruby-on-Rails, or self-exploration, etc.
That is what I think we want to find through this question.
Unfortunately I have found about Git by reading KernelTraffic
and later KernelTrap during the whole "BitKeeper fiasco"; I have
next to no idea about how other people have heard about Git.
Help!?
There is other side to this question, _if_ we were some company, or/and
_if_ we were concerned about making Git more popular, namely to
identify the paces where "advertising" would make most impact.
> > 06. Did you find GIT easy to learn?
> > - very easy/easy/reasonably/hard/very hard
>
> But that has to be contrasted with their _current_ notion
> in order to know if they make progress or not. If the
> difficulty persists, we're in trouble. If it is just a
> steep learning curve, we might be able to address that.
>
> So maybe some variant questions like:
> How do you find it now (after some use)?
> same [very easy..very hard] scale
> How long have you been using Git?
The question is here to either dispel the myth that Git is hard to
learn, or find that we have steep learning curve and that we should
perhaps do something about it.
> Rate your own Git proficiency:
> [noob, casual, I survive, everyday use,
> I answer questions from others,
> I use plumbing in scripts daily,
> Power User, Godly, I am Junio]
Good idea about question about Git proficiency.
> > 07. What helped you most in learning to use it?
> > (free form question)
> > 08. What did you find hardest in learning Git?
> > What did you find harderst in using Git?
> > (free form question)
> > 09. When did you start using git? From which version?
> > - pre 1.0, 1.0, 1.1, 1.2, 1.3, 1.4, 1.5
>
> It's likely that most people don't know the specific answer
> to that question and will just guess, if anything. It is
> also semi-subject to time-slide as old installs are made on
> different distributions [*cough*] Debian. I think the question
> "How long have you been using Git?" Might be more easily
> answered and show better data. (Adoption curve.)
True. I think "How long have you been using Git?" with log-like
multiple choice scale: few days/few weeks/month/few months/year/few
years would be better idea.
On the other hand knowing which version someone started his/her
"Git adventure" would help to find probable causes where some of ideas
about git were already corrected in later versions...
> > + might be important when checking "what did you find
> > hardest" etc.
> > + perhaps we should ask in addition to this question, or in
> > place of this question (replacing it) what git version one
> > uses; it should be multiple choice, and allow 'master',
> > 'next', 'pu', 'dirty (with own modifications)' versions
> > in addition.
It would be next (additional) question, probably multiple choice, and
easy to check out with "git version" or "git --version" command.
> > Other SCMs (shortened compared with 2007 survey)
> >
> > 10. What other SCM did or do you use?
> > (zero or more: multiple choice)
> > - CVS, Subversion, GNU Arch or arch clone (ArX, tla, ...),
> > Bazaar-NG, Darcs, Mercurial, Monotone, SVK, AccuRev,
> > Perforce, BitKeeper, ClearCase, MS Visual Source Safe,
> > MS Visual Studio Team System, custom, other(*)
>
> What? No SCCS?
Hmmm... SCCS got 18 out of 654 responses, only one less than SVK.
I'd add it to the list of choices for this question, then.
> > 10b.If you selected other above, what SCM it was?
>
> s/it was/was it/
>
> > (free form)
> > 11. Why did you choose Git? (if you use Git)
>
> That's a bit vague... First, maybe they didn't choose Git.
> Maybe they are on a project where it was mandated.
> So, Why did they choose Git for _what_?
>
> Are we trying to ask "Why did you decide to use Git?" ?
Yes, that was I wanted to ask. "Why do you use Git? (if you do use it)".
> > What do you like about using Git?
> > (free form, not to be tabulated)
>
> Presuming they do... :-) So, maybe add:
>
> I enjoy using Git: [-5 .. 0 .. +5]
> Git satisfies my use cases: [-5 .. 0 .. +5]
> I prefer Git over CVS/SVN: [-5 .. 0 .. +5]
>
> Or so...
I'm not sure if it wouldn't be more interesting to have free-form here.
I think we would get quite a number of unique and non-obvious answers.
Besides the above form depends on survey site to be able to create such
matrix of responses...
> > How you use Git
> >
> > 13. Do you use Git for work, unpaid projects, or both?
> > (single choice)
> > - work/unpaid projects/both
>
> But there are other uses too. I use it for personal crap
> like my Brewing Log. Sure, it is an "unpaid project", but
> that's not very useful information. Maybe it would make
> sense to expand this question into, say, 10 choices that
> we feel are likely uses cases and see what the actual
> demographics are. That is, the two-part-with-waffle isn't
> that informative.
>
> Maybe:
> I use Git for: [check all that apply]
> Work projects
> Personal data
> Unpaid Open Source Development
> Sharing Data with my Niece
> Maintaining my Website
> Backending my Blog
> etc.
Very good idea. This way we can share this question with question about
kind of data one uses Git for.
By the way, perhaps we should split "Work projects" into "Work projects"
and "Work projects (private git)" to distinguish between cases where Git
is used at work, and where you use Git privately (for example via
git-svn, or git-p4) to interact with other SCM that is used at work.
> My point here is that we can learn what Git is being
> used for, and ....
>
> Although for some reason I can't yet, I would
> really like to use Git for:
> My Wordpress backend
> Maintaining my {pr0n,mp3} Collection
> Work projects
> Sharing data with my boss
> etc.
>
> That would give us a sense of direction possibly.
> It might provide a notion as to what people are wanting
> to do, but for some reason find it hard to pull off.
> That is, help us identify use-cases that are being limited
> but would otherwise be adoptive.
Hmmmm...
> > 18. Which (main) git web interface do you use for your projects?
> > (zero or more: multiple choice)
> > - gitweb, cgit, wit (Ruby), git-php, viewgit (PHP), other
> > + should there be a question about web server (Apache,
> > IIS, webrick, LigHTTPd, ...) used to host git web interface?
>
> Probably not. Most people might not even know.
I can agree with that.
On the other hand the purpose of this question was to get a list
of most popular servers to put example configuration for hosting git
repositories via HTTP(S) protocol, and for setting up gitweb.
> > What you think of Git
> >
> > 24. If you want to see Git more widely used, what do you
> > think we could do to make this happen?
> > + Is this question necessary/useful? Do we _need_
> > wider adoption?
>
> Hmmm. See some ramblings of mine above too... :-)
What ramblings were they?
> >
> > Changes in Git (since year ago, or since you started using it)
> >
> > 26. How do you compare current version with version from
> > year ago?
> > - current version is: better/worse/no changes
The list of possible answers should (just in case, because you can
simply not answer this question, although some would not know this)
also "I don't know, I didn't use Git for a year".
> More fine detail needed there? To help identify what people
> think have improved and what has not yet improved?
>
> Since you started using Git, rate how the following
> functional areas have/have-not improved:
> The User Interface [-5 .. 0 .. +5]
> The command line interface [-5 .. 0 .. +5]
> The intuitive behavior [-5 .. 0 .. +5]
> The overall experience
> The behavior of 'fetch'
> The behavior of "git log'
> The config file
> etc.
This of course depends on web survey site allowing such feature
in survey.
> A -5 means it still sucks or got worse, 0 is neutral
> or no opinion, and +5 means it rocks or got better.
> This would give us direct feedback indicating if we,
> as a whole, are headed in the right direction with our
> development efforts. It will also directly tell us
> which features people find still suck.
>
> We should attempt to get direct feedback on many Git features.
The trouble of course would be with coming up with the "laundry list" of
features people did or can have a problem with.
> > Documentation
> >
> > 31. Do you contribute to Git wiki?
> > - yes/no/only corrections or spam removal
>
> If "no", why not?
Good idea.
> [Wikis suck, I don't know the answers, no time...]
[We have a wiki???] ;-)
> > 32. Do you find Git's on-line help (homepage, documentation)
> > useful?
> > - yes/no/somewhat
>
> Confusing.
I think it would fall in "somewhat" category I think.
> > Getting help, staying in touch
> >
> > 42. Do you find traffic levels on Git mailing list OK.
> > - yes/no? (optional)
>
> I find the mailing list traffic level to be:
> [too low, OK, just right, tolerable, intolerable,
> a bit high, absurdly high]
Good idea of expanding the list of answers, otherwise it is hard to
answer this question. Although perceived signal to noise ratio might
be more important than bare traffic.
> > Open forum
> >
> > 46. What other comments or suggestions do you have that are not
> > covered by the questions above?
> > (free form)
> >
>
> I've got to ... ramble on,
:-DDDDD
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v3] t6030 (bisect): work around Mac OS X "ls"
From: Jonathan Nieder @ 2008-07-24 18:16 UTC (permalink / raw)
To: Mike Hommey; +Cc: Christian Couder, git
In-Reply-To: <Pine.GSO.4.62.0807241233190.16518@harper.uchicago.edu>
Jonathan Nieder wrote:
> - test_must_fail ls .git/BISECT_* &&
> + case $(echo .git/BISECT_*) in *\*) ;; *) false ;; esac &&
Actually, if we want to go that route, I prefer the version Dscho gave.
So please ignore my patch v3; I'd rather people choose between
Christian's and Dscho's suggestions.
Personally, without knowing how much time avoiding the ls saves, I
am not sure which is best. Certainly the version with "ls" is clearer,
which is most important; but if the time savings (of avoiding such
constructs generally) are significant, then that is very much worthwhile
- a faster test suite can be run more often.
Jonathan
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Dmitry Potapov @ 2008-07-24 18:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200807232349.42244.jnareb@gmail.com>
On Wed, Jul 23, 2008 at 11:49:41PM +0200, Jakub Narebski wrote:
> On Wed, 23 Jul 2008, Dmitry Potapov wrote:
> > On Wed, Jul 23, 2008 at 03:25:03AM +0200, Jakub Narebski wrote:
> > >
> > > 02. What is your preferred non-programming language?
> > > (or) What is the language you want computer communicate with you?
> >
> > IMHO, the later wording of the question is much better.
>
> First just satisfies demographic curiosity. Second is more question
> about internationalization (i18n).
I think demographic is largely covered by the first question about
country. As to i18n, I don't think it is fully covered just by the
question about one's language preference to communicate with computer
(which is probably is more correctly to call localization). Possible
questions related to i18n are:
- Do you use file names with non-ASCII characters?
- Do you use text files with non-ASCII characters?
- Do you (or members of your team) use computers with different
character sets and have to deal with non-ASCII characters?
But I guess we do not want to have so many questions. So, maybe
something simple instead:
- Are you satisfied with support for non-ASCII characters in Git?
> Should "What version do you use now?" be multiple choice (using git
> on more than one machine / operating system)?
I think we already have another question about what OS one uses.
So I believe it should be only version number here.
> What should be possible
> choices for "How long do you use git?"? Perhaps.
>
> 10. How long do you use git?
> (single choice)
> - never/few days/few weeks/month/few months/year/few years/
> from beginning/I wrote it(*)
> + (*) just kidding ;-)
I would rather use numbers like that:
never
less than month
1-3 months
3-6 months
6-12 months
1-2 year
more than 2 years
from the beginning
Dmitry
^ permalink raw reply
* Re: [PATCH] index-pack: correctly initialize appended objects
From: Björn Steinbrink @ 2008-07-24 18:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, spearce, git, gitster
In-Reply-To: <alpine.DEB.1.00.0807241821440.8986@racer>
On 2008.07.24 18:32:00 +0100, Johannes Schindelin wrote:
>
> From: Björn Steinbrink <B.Steinbrink@gmx.de>
>
> When index-pack completes a thin pack it appends objects to the pack.
> Since the commit 92392b4(index-pack: Honor core.deltaBaseCacheLimit when
> resolving deltas) such an object can be pruned in case of memory
> pressure.
>
> To be able to re-read the object later, a few more fields have to be set.
Ah, thanks a lot! I tried to come up with a sane commit message
yesterday but totally failed, and then after a night of sneezing, I had
forgotten about it. And I wouldn't have managed to write an equally good
message anyway ;-)
> Noticed by Pierre Habouzit.
>
> Hopefully-signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Sure!
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Thanks,
Björn
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: James Pickens @ 2008-07-24 17:59 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0807240200x10a6a267h4c37e4566da967ba@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
> This one is difficult (and may probably produce more intrusive patch).
> Let's see what I can do.
This is not a high priority for me, so if the added
difficulty/intrusiveness means it would take longer for the sparse
checkout capability to make it into mainline git, then I would drop this
request, or at least delay it until some later time.
> > Second, I would want a capability to checkout and release directories
> > incrementally, similar to how we do it in cvs. For example, I might do
> > the following in cvs:
>
> You can do that with "git checkout --path" (non-recursive checkout aside):
>
> $ git checkout --path=A # checkout full A
> $ git checkout --path=A/B1/C1 # no, limit to A/B1/C1 only
> $ git checkout --path=A/B1/C1:A/B2 # extend to A/B2 too
My point was not that incremental checkout is impossible, just that it
would be easier if I didn't have to re-type the full path list again.
Suppose I had 9 directories (A/B1 through A/B9) in my sparse checkout,
and I wanted to add a 10th directory (A/B10). It would be much easier
to type something like
$ cd A
$ git checkout B10
instead of
$ git checkout --path=A/B1:A/B2:A/B3:A/B4:A/B5:A/B6:A/B7:A/B8:A/B9:A/B10
Another thing I thought of, which I'm not sure if it's sensible or not,
is to make sparse checkout a persistent branch attribute by creating a
.gitpaths (or whatever) file containing a list of directories that
should be checked out. This would be analogous to the .gitmodules file.
The .gitpaths file could then be checked in, and applied automatically
any time the user checks out a branch containing such file. This is
just an idea for discussion, not a feature request.
James
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Dmitry Potapov @ 2008-07-24 17:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Stephan Beyer
In-Reply-To: <200807230325.04184.jnareb@gmail.com>
On Wed, Jul 23, 2008 at 03:25:03AM +0200, Jakub Narebski wrote:
> Is there some channel that I have forgot about?
If the start of this survey can be timed to release 1.6.0 then the
announce about Git 1.6.0 release may also contain reference to that
survey, and because release announcements are usually widely distributed
by online magazines such as LinuxToday and LWN, anyone who is interested
in Git will learn about this survey too.
Dmitry
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-24 17:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807241811580.8986@racer>
On Thu, Jul 24, 2008 at 06:14:09PM +0100, Johannes Schindelin wrote:
> On Thu, 24 Jul 2008, Dmitry Potapov wrote:
> >
> > Here is the average based on 3 attempts:
> > 0.232s with autocrlf=false
> > 0.265s with autocrlf=input (14% increase)
>
> And you tested... on git.git? One of the smallest serious Git users?
If you take a huge repo, you are going to be bound by disk IO unless
huge amount memory, so all files reside in the filesystem cache.
>
> If you want to come close to the hard cases (that you would punish with
> setting autocrlf = input, not yourself of course), test _at least_ the
> Linux kernel.
false input
6.913s 8.426s
6.922s 8.337s
6.969s 8.335s
6.975s 8.386s
6.939s 8.435s
6.954s 8.320s
autocrlf=input takes 20% more than autocrlf=false, which is rather
strange, because I clearly saw some disk activity... so I expected
it to be less...
In any case, this test is rather artificial, and the real one should
be is of course applying patches... Maybe I will try that later...
Dmitry
^ permalink raw reply
* [PATCH v3] t6030 (bisect): work around Mac OS X "ls"
From: Jonathan Nieder @ 2008-07-24 17:51 UTC (permalink / raw)
To: Mike Hommey; +Cc: Christian Couder, git
In-Reply-To: <20080724165434.GA26660@glandium.org>
t6030-bisect-porcelain.sh relies on "ls" exiting with nonzero
status when asked to list nonexistent files. Unfortunately,
/bin/ls on Mac OS X 10.3 exits with exit code 0. So use "echo"
instead.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Mike Hommey wrote:
>>>> + test -z "$(ls .git/BISECT_*)" &&
>>> That is still a useless use of ls ;)
>> It is much better than what I wrote, at least.
> But could also be written with echo instead of ls.
How about this? (The echo is necessary because the argument
to a case statement does not undergo filename expansion.)
t/t6030-bisect-porcelain.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 0626544..b6841fe 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -76,7 +76,7 @@ test_expect_success 'bisect fails if given any junk instead of revs' '
test_must_fail git bisect start foo $HASH1 -- &&
test_must_fail git bisect start $HASH4 $HASH1 bar -- &&
test -z "$(git for-each-ref "refs/bisect/*")" &&
- test_must_fail ls .git/BISECT_* &&
+ case $(echo .git/BISECT_*) in *\*) ;; *) false ;; esac &&
git bisect start &&
test_must_fail git bisect good foo $HASH1 &&
test_must_fail git bisect good $HASH1 bar &&
--
1.5.6.3.549.g8ca11
^ permalink raw reply related
* Re: [PATCH v2] t6030 (bisect): work around Mac OS X "ls"
From: Johannes Schindelin @ 2008-07-24 17:44 UTC (permalink / raw)
To: Mike Hommey; +Cc: Jonathan Nieder, Christian Couder, git
In-Reply-To: <20080724165434.GA26660@glandium.org>
Hi,
On Thu, 24 Jul 2008, Mike Hommey wrote:
> On Thu, Jul 24, 2008 at 02:43:51AM -0500, Jonathan Nieder wrote:
>
> > Mike Hommey wrote:
> >
> > > On Thu, Jul 24, 2008 at 07:57:26AM +0200, Christian Couder wrote:
> > >
> > >> + test -z "$(ls .git/BISECT_*)" &&
> > >
> > > That is still a useless use of ls ;)
> >
> > It is much better than what I wrote, at least.
>
> But could also be written with echo instead of ls.
Sure, but then it looks uglier:
test ".git/BISECT_*" = "$(echo .git/BISECT_*)" &&
and it is much easier to hide a typo there.
And now the big question: is it performance critical? Or is obvious
correctness the highest goal here?
Hth,
Dscho
^ 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