* Re: Git User's Survey 2007 unfinished summary continued
From: Matthew Andrews @ 2007-10-14 22:23 UTC (permalink / raw)
To: David Kastrup; +Cc: Jakub Narebski, Johannes Schindelin, git
In-Reply-To: <85k5ppjqfu.fsf@lola.goethe.zz>
I'm trying to see this negative tone that apparently exists on the
list. As a long-time lurker, I only see a fairly standard open-source
expectation of basic knowledge and strong opinion. The list is fairly
good about point people to existing documentation. If you do something
that somebody thinks is stupid, they'll tell you so. They don't coddle
you here, but they are more than willing to help.
On 10/14/07, David Kastrup <dak@gnu.org> wrote:
> "Jakub Narebski" <jnareb@gmail.com> writes:
>
> > On 10/13/07, David Kastrup <dak@gnu.org> wrote:
> >
> >> I find it a pity that my suggestion to ask about how comfortable
> >> people are with the tone on the list did not make it into the survey.
> >> Enough core developers make the tone sufficiently unconstructive to
> >> make it quite understandable that people are unwilling to ask
> >> questions here, in order to avoid getting their heads banged against a
> >> wall, virtual or not.
> >
> > I think next to last question in the survey
> >
> > 61. Did you have problems getting GIT help on mailing list or on
> > IRC channel? What were it? What could be improved?
> >
> > was the place to put complaints about git mailing list.
>
> What if there are no problems getting help once you submit to letting
> your head get bashed in?
>
> The problem is not with getting help on the list: the list is
> bristling with competent people. The problem is the price to pay in
> self-esteem and comfort.
>
> --
> David Kastrup, Kriemhildstr. 15, 44793 Bochum
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: David Kastrup @ 2007-10-14 22:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0710142303170.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
>> > I find it a pity that my suggestion to ask about how comfortable
>> > people are with the tone on the list did not make it into the
>> > survey.
>
> Well, everybody knows who wanted to have that question in the
> survey, and everybody knows why.
And would it not be good to corroborate that "who" is alone with his
opinion? The purpose of a survey is to get, not to push opinions. So
why fear the question?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Jakub Narebski @ 2007-10-14 22:15 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Schindelin, git
In-Reply-To: <85k5ppjqfu.fsf@lola.goethe.zz>
On 10/15/07, David Kastrup <dak@gnu.org> wrote:
> "Jakub Narebski" <jnareb@gmail.com> writes:
>
> > On 10/13/07, David Kastrup <dak@gnu.org> wrote:
> >
> >> I find it a pity that my suggestion to ask about how comfortable
> >> people are with the tone on the list did not make it into the survey.
> >> Enough core developers make the tone sufficiently unconstructive to
> >> make it quite understandable that people are unwilling to ask
> >> questions here, in order to avoid getting their heads banged against a
> >> wall, virtual or not.
> >
> > I think next to last question in the survey
> >
> > 61. Did you have problems getting GIT help on mailing list or on
> > IRC channel? What were it? What could be improved?
> >
> > was the place to put complaints about git mailing list.
>
> What if there are no problems getting help once you submit to letting
> your head get bashed in?
>
> The problem is not with getting help on the list: the list is
> bristling with competent people. The problem is the price to pay in
> self-esteem and comfort.
"What could be improved?"
--
Jakub Narebski
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-14 22:14 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Andreas Ericsson, Benoit SIGOURE, git list, Eli Zaretskii,
Make Windows
In-Reply-To: <Pine.LNX.4.64.0710142112540.25221@racer.site>
Johannes Schindelin, Sun, Oct 14, 2007 22:14:25 +0200:
> On Sun, 14 Oct 2007, Andreas Ericsson wrote:
> > Johannes Schindelin wrote:
> >
> > > I do not see any reason why libification helps the user experience on
> > > Windows.
> >
> > I was under the impression that the windows port suffers from Windows'
> > lack of a proper fork() and friends and that a proper library would help
> > solving those problems. Perhaps I was misinformed.
>
> It suffered. Until Hannes Sixt did a very fine job which cumulated in the
> patch series he posted yesterday. Of course, this work is the reason
> msysGit is functional.
>
Re "functional". Have to remind something (besides the fork):
Filesystem:
- no proper VFS (can't do anything with files opened elsewhere, and we
have not enough error handling and diagnostic output to detect the
problems)
- no proper filename semantics (case-insensitivity and stupid rules for
allowed characters in filenames, like ":" in filenames in
cross-platform projects)
- no acceptable level of performance in filesystem and VFS (readdir,
stat, open and read/write are annoyingly slow)
- it is the only OS in the world with multi-root (/a/b/c and /a/b/c
can be not the same, depending on what current "drive" is) and
multi-cwd, which hasn't had formed itself into a problem yet, but
surely will
- no real "mmap" (which kills perfomance and complicates code)
Interprocess communication:
- no reliable text environment (I'm programming in the damn thing for
10 years and I still don't know how to pass an environment variable
_for_sure_)
- it has only one argument (limited in size) passed to started
programs, which means that there is no possible way to safely pass
file and text arguments on command line (more than one, that is)
^ permalink raw reply
* Re: [PATCH] parse-options: Allow abbreviated options when unambiguous
From: Johannes Schindelin @ 2007-10-14 22:12 UTC (permalink / raw)
To: Eric Wong; +Cc: Pierre Habouzit, git
In-Reply-To: <20071014210130.GA17675@soma>
Hi,
On Sun, 14 Oct 2007, Eric Wong wrote:
> Pierre Habouzit <madcoder@debian.org> wrote:
> > On Sun, Oct 14, 2007 at 06:02:33PM +0000, Johannes Schindelin wrote:
> > > Hi,
> > >
> > > On Sun, 14 Oct 2007, Johannes Schindelin wrote:
> > >
> > > > When there is an option "--amend", the option parser now recognizes
> > > > "--am" for that option, provided that there is no other option beginning
> > > > with "--am".
> > >
> > > And an amend for ultra-abbreviated options (as you noticed on IRC):
> > >
> > > diff --git a/parse-options.c b/parse-options.c
> > > index afc6c89..acabb98 100644
> > > --- a/parse-options.c
> > > +++ b/parse-options.c
> > > @@ -137,6 +137,11 @@ is_abbreviated:
> > > abbrev_flags = flags;
> > > continue;
> > > }
> > > + /* negated and abbreviated very much? */
> > > + if (!prefixcmp("no-", arg)) {
> > > + flags |= OPT_UNSET;
> > > + goto is_abbreviated;
> > > + }
> > > /* negated? */
> > > if (strncmp(arg, "no-", 3))
> > > continue;
> >
> > squashed on top on the previous, and pushed to my ph/parseopt branch.
>
> Awesome. Thanks to both of you.
Hehe, you're welcome. Pierre even realised that my patch was not complete
(it did not catch overly short abbreviations "--n" and "--no"), and that
has been fixed, too.
While I have your attention: last weekend, I spoke to a guy from the
ffmpeg project, and he said that the only thing preventing them from
switching to git was the lack of svn:external support...
(Of course I know that it is more difficult than that: ffmpeg itself is an
svn:external of MPlayer, but maybe we can get both of them to switch ;-)
Do you have any idea when/if you're coming around to add that to git-svn?
Ciao,
Dscho
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: David Kastrup @ 2007-10-14 22:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johannes Schindelin, git
In-Reply-To: <8fe92b430710141449r3f1b1a85oae2a5fb5b30c8b47@mail.gmail.com>
"Jakub Narebski" <jnareb@gmail.com> writes:
> On 10/13/07, David Kastrup <dak@gnu.org> wrote:
>
>> I find it a pity that my suggestion to ask about how comfortable
>> people are with the tone on the list did not make it into the survey.
>> Enough core developers make the tone sufficiently unconstructive to
>> make it quite understandable that people are unwilling to ask
>> questions here, in order to avoid getting their heads banged against a
>> wall, virtual or not.
>
> I think next to last question in the survey
>
> 61. Did you have problems getting GIT help on mailing list or on
> IRC channel? What were it? What could be improved?
>
> was the place to put complaints about git mailing list.
What if there are no problems getting help once you submit to letting
your head get bashed in?
The problem is not with getting help on the list: the list is
bristling with competent people. The problem is the price to pay in
self-esteem and comfort.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Imports without Tariffs
From: Michael Witten @ 2007-10-14 22:10 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20071014164001.GC27595@sigill.intra.peff.net>
On 14 Oct 2007, at 12:40:01 PM, Jeff King wrote:
> On Sat, Oct 13, 2007 at 07:04:52PM -0400, Michael Witten wrote:
>> Do I just submit the patch to this list? How do I know it will be
>> used?
>
> Yes, send a patch to the list and to Junio (the maintainer). See
> Documentation/SubmittingPatches for details.
Indeed! RTFM, as they say. ;-)
>> Frankly, I don't know how robust my idea is either, but it's simple
>> enough not to have many problems lurking in the shadows.
>>
>> It would certainly be more useful than not.
>
> Then submit a patch implementing it. :)
Perl. Ugh. I'll see what I can do, though it may take 1.5 weeks.
> I like the idea of git secretly infiltrating institutions,
> replacing CVS unbeknownst to management. It was the same for Linux in
> the mid-90's ("our mail server is running on what!?").
:-)
Replace CVS or Bust!
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-14 22:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <8fe92b430710141449r3f1b1a85oae2a5fb5b30c8b47@mail.gmail.com>
Hi,
> > I find it a pity that my suggestion to ask about how comfortable
> > people are with the tone on the list did not make it into the survey.
Well, everybody knows who wanted to have that question in the survey, and
everybody knows why.
> > Enough core developers make the tone sufficiently unconstructive to
> > make it quite understandable that people are unwilling to ask
> > questions here, in order to avoid getting their heads banged against a
> > wall, virtual or not.
My experience is that people come here, ask questions, and get served.
Often to stay. So it cannot be that bad.
On Sun, 14 Oct 2007, Jakub Narebski wrote:
> I think next to last question in the survey
>
> 61. Did you have problems getting GIT help on mailing list or on IRC channel?
> What were it? What could be improved?
>
> was the place to put complaints about git mailing list. I didn't want to
> add separate question because this survey has too many questions (is too
> long) already.
That is the problem of most surveys. Usually you can see that after
50-75% of the questions, people are too bored, and just stop the survey
right then and there. Or, if forced, give stupid answers because they are
annoyed with them.
Given that only one answer hinted at that AFAIR (it was something along
the lines "I already wasted too much time on this survey, so I cannot work
on git" or some such), I think you did a good job, though.
Again, thanks for all the work that you did/will do. I know how tedious
it is to evaluate such surveys, especially the free form answers. Must
have taken you days of real effort.
Ciao,
Dscho
^ permalink raw reply
* Git User's Survey 2007 summary - git homepage improvements
From: Jakub Narebski @ 2007-10-14 22:05 UTC (permalink / raw)
To: git, Petr Baudis
50. What could be improved on the GIT homepage?
TO DO
171 / 683 non-empty responses
--
Note from the homepage, http://git.or.cz/
This website itself is tracked in Git as well - you can browse its
development history or even clone it from
http://repo.or.cz/r/git-homepage.git. The site is covered by GPLv2 and
maintained by Petr Baudis who always takes patches eagerly. ;-)
--
List of answers, without count, divided into broad categories.
Some answers were hard to classify into one section, so please read
carefully.
Generic
* Keep it always up-to-date!
* Catch up with the latest version in kernel.org/.../RPMS. ;-)
1.5.3.2 is out.
* Publicity. Until the survey I didn't know it had all that!
There is a homepage?
* More active movement between IRC/list and FAQs
* Less Linux programmer focused.
* Maybe provide translation
Translations to other languages for better adaption elsewhere.
i18n.
* A dedicated domain name, easy to remember and find.
Nicer URL? (git.org?)
* Change the site name to have 'git' in it! Like 'TheGitSite.com'
rather than git.qk.wkx.or (ir is git.or.cz) or whatever.
* It could use a better url than 'git.or.cz'; the URL looks like a
mirror and I'm not sure I'm on the official home page.
* Git could use a real logo.
Code and design
* Could be more sexy.
* Graphical design.
* Give it some nice & fresh design.
* Make it more attractive.
* Color scheme (?)
* Better design and appreciation for aesthetics. For the typical
'programmer' whose position is 'who cares what it looks like' they
won't care. For the managers and other folks that need to be
convinced it will look more polished and professional. Appearances
matter.
* Move the details on fetching the development code to the 'getting
git' page.
* More prominent links to documentation on how to get started with
GIT.
* More bling :-) but I'm not really sure about that.
Non-technical users get scared away anyway.
* Smarten it up with some colour and graphics.
* Maybe get a graphics monkey and make it less dull but otherwise the
content is OK.
* Make it prettier. Sounds silly but it counts. Bazaar's main feature
is a pretty website ;).
* The layout. It's ok for me but it looks like a minor hobby
project's page
* Make it easier to find information.
Reorganization to find the most important information easily.
* The page has too much info and is hard to navigate.
Look at http://www.mozilla.com/ for contrast.
* Better layout. It seems busy and hard to find things. Simplify.
Better layout to make things easier to find.
* Move the documentation up to the top.
It's what people want to access the most!
* Perhaps divide it again into separate pages if it grows
* The layout and the organization of the sections. It's pretty hard
to know why should I use git just looking at the webpage.
* A proper side bar for things that are currently in boxes.
* Hide the rarer commands and special tricks deeper and emphasize the
best usage practices.
* Less text on the front page, less text per page
* Web 2.0 type interface as Ruby and Ubuntu have.
* Pictures. Fancy layout.
Less clutter.
I find it somewhat unstructured.
* Modern styles look and feel.
* Download link needs to stand out more. The homepage appears rather
'flat' that is nothing stands out as more important than the rest.
In order of importance, I think there should be:
1. Download
2. Git Quickstart Guide
3. Documentation
* The lines are too long. Try to find a better proportion.
* It doesn't look like a project home page.
Mercurial does a better job with the look of their page IMHO.
* Make it less monolithic. Stick documentation on its own page,
methods of acquiring GIT on its own page and so forth. That allows
more room for each without making one huge homepage.
* Divide content up into sets of info related to tasks a person would
be interested in
- getting a first setup
- maintaining/updates
- introductory documentation
- reference/refresh-memory info
- project/git-developer info
* Make it look more modern but don't use too many web features
(i.e. make sure it works on elinks).
Documentation
* Link to Git User's Manual and not only to crash course/tutorial
Feature the User Manual more prominently
* More documentation.
More tutorials and examples.
More workflow examples, more crash courses.
* More links to documentation/tutorials/howto
* Recipes for how to do things with git.
Examples and workflows.
Common pitfalls.
* More visible link to the tutorial.
* Old documentation removed / updated (index, staging, cache).
Less emphasis on cogito / Remove Cogito references.
* Remove more aggressively outdated documentation for historic tools
(like cogito).
* Fluxograms describing some use cases.
Perhaps some diagrams.
* More comprehensive tutorial with optional boxouts.
* Up to date information about best practises and recommended tools.
* Add a new users section with some walkthroughs that show how to use
git practically on a real repository. Maybe add comparable commands
from other SCMs. (git clone -> cvs checkout)
* 'git for svn/cvs people' could use an overhaul
(at least they did a few months ago)
The Git for SVN users tutorial is incomplete and does not explain
for example how the index works and why it's there. Thus people end
up thinking that 'svn add' is like 'git add' whereas it's not.
* A 'git features tour' showing the great features git has.
* Add some material for presenting git to others (slides)
* Add a tutorial helping deal with a conflict merge.
* Feature-driven help: a list of features with short tutorial on how
to use each one.
* Example of interacting with CVS repository
(import, export, cvsserver)
* Highlight those pieces of documentation that aren't easily
available through --help and man 'git-something'.
* Getting started for new users.
* Simple online demo and beginner Tutorial on one page.
The demo could be an applet giving access to a terminal of a
running virtual machine with git and some demo repositories.
The virtual machine is reset every full hour.
* Some way to indicate which version of Git a specific piece of
documentation refers to.
* Missing information: examples of ways diffent (real) projects use
Git.
* More details on how to make a centralized workflow work
* A prominent 'Why git?' or 'Why distributed?' section might be good.
* Better SVN -> Git
Downloads
* It could be more up-to-date about new git versions (sometimes it
lags behind a bit).
* Catch up with the latest version in kernel.org/.../RPMS. ;-)
1.5.3.2 is out.
* Current official version should include the one on master.
Snapshots. Results of nightly builds and tests.
There should be links to download pu/next/master/maint branches
tar.gz trees (snapshots) from gitweb.
* Information about Windows version(s).
Easier for windows users to find msysgit (maybe with a development
warning) under 'Getting git'.
Links to windows ports: http://code.google.com/p/msysgit/
and a plea for help.
* Download link needs to stand out more.
* Download repository for the most common distros (Ubuntu, RedHat /
Fedora Core, SuSE).
* Provide processed man pages to install
Provide PDF documentation
Information, new links, new features
* What's New section
* News and info about where things are going (roadmap).
* Link to the latest release announcement. Now you can only find a
link to the tarball but most of the time I only want to take a
quick look at the announcement (RelNotes).
* Add a news section and maybe some pointers to interesting
user-contributed HOWTOs or something.
* Add more external porcelains like Guilt to the frontpage.
* Recommended 'out-of-the-box' package of GUI or CLI interface.
* Cogito state should be better clarified.
* Bring the porcelains list up-to-date -- in particular mark
Cogito (cg) as outright deprecated.
* More information on project around GIT (like GUIs etc).
* Perhaps making some pages like FAQ or Tips and Tricks, or
discussion about nature of branches in git taken from GitWiki when
they are mature enough
* I wish for Git Traffic: digest of git mailing list discussions
(there was one at http://kerneltraffic.org/git/index.html but it
stopped after one issue; KernelTraffic is also no longer updated)
Some type of recent news collected from the mailing list 'what's
new in the latest release' or coming-soon previews would be nice.
* The layout and the organization of the sections. It's pretty hard
to know why should I use git just looking at the webpage.
* More marketing on what projects use git and perhaps more blurb on
why git is better than other SCMs.
* Easier access to release notes and changleogs (i.e. the history)
without having to browse the git repo or read separate pages from
the documentation.
* A blog or news page (not everyone enjoys mailing lists),
perhaps link to mailing list archive
* Provide 'A note from the maintainer' as a prominent link probably
named as 'How the git project is managed and how to participate'
* Place links to direct git's plugins core and tools source tree.
* Link to some good GUIs. Giggle is a good GUI that serves my needs.
One person seems to mistake git documentation page ("reprint of the
man pages") at http://www.kernel.org/pub/software/scm/git/docs/
for the homepage, another mistook (kernel.org?) gitweb for it.
Here is short summary of most common answers, with a short comment if
appropriate:
Generic:
# Dedicated domain name / site name, e.g. git.org or git.com
to have it look less like mirror or unofficial page
(git.or.cz still comes first when searching Google for "git";
current domain name was available to homepage admin - historical
reason)
# Better design: make it prettier, easier to find information,
move more important things first, use sidebar instead of boxes,
perhaps divide it into separate pages (again). But make sure it
works on Elinks for example.
(IIRC pasky is not web designer, so help is appreciated)
Documentation
# More documentation: tutorials, workflow examples, walkthroughs,
SCM commands comparison, interacting with other SCMs, HOWTOs, best
practices, recommended tools, fluxograms describing use cases
(graphics). Make link to Git User's Manual stand out better.
# Less emphasizis on Cogito, mark it more explicitely as deprecated
and slowly try to get rid of Cogito references in documentation
(e.g. crash courses).
(Cogito is officially deprecated from not a long time; the process
of removing references to cg in crash courses is AFAIK ongoing)
# More emphasizis on "Why git?" and "Why distributed SCM?".
A 'git features tour' showing the great features git has.
In short: why and when to choose git.
(Someone would have to write it)
# Simple online demo. The demo could be an applet giving access to a
terminal of a running virtual machine with git and some demo
repositories. The virtual machine is reset every full hour.
(This might be a good idea, but I think it is a bit hard to do from
technical point of view; at least securely, securing against
intrusion and, perhaps accidental, denial of service)
Downloads:
# More up-to-date about new git versions.
(With one person updating homepage, who is not git maintainer...)
# There should be links to download pu/next/master/maint branches
tar.gz trees (snapshots) from gitweb.
(The source snapshot part is quite easy to do, but it might
increase load on kernel.org / repo.or.cz, unless snapshots are
somehow cached)
# Results of nightly builds and tests.
Static binaries for other OS (FreeBSD, MacOS X).
(There is a matter of machine park. Somewhere those nightly builds,
perhaps together with nightly running of test suite, have to run.)
# Information about MS Windows version(s). Link to MSys Git, marking
it as under development; perhaps plea for help?
# Provide processed man pages to install. Provide PDF documentation,
at least PDF version of Git User's Manual.
(Having PDF version is quite new; there is no manual.pdf target in
official Makefile.)
Information, new links, new features
# Link to the latest release announcement (RelNotes) on download page.
(Links to relnotes are in HTML version of git(7) manpage, but I
think it is not enough. Happily we _have_ release announcements)
# News section, info about where things are goung (roadmap)
(Junio has a hard time maintaining TODO, and git doesn't have
roadmap AFAICT)
# Provide 'A note from the maintainer' as a prominent link probably
named as 'How the git project is managed and how to participate'
(That is a good idea I think, better than having it on GitWiki.
We can put direct link to SubmittingPatches nearby.)
# I wish for Git Traffic: digest of git mailing list discussions
Some type of recent news collected from the mailing list 'what's
new in the latest release' or coming-soon previews would be nice.
(There was one at http://kerneltraffic.org/git/index.html but it
stopped after one issue; KernelTraffic is also no longer updated.
Do you volunteer?)
# Links to more tools, GUIs, version control interface layers.
A somewhat related request: copy pages like FAQ or Tips and Tricks,
or discussion about branches from GitWiki when they are mature
enough.
(For example there was requests to put links to / info about Guilt
and Giggle on git homepage. Giggle has quite a bit of users among
GUIs).
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] [BUG FIXED 2] git-add (-a|-u) and -n support
From: Michael Witten @ 2007-10-14 22:00 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <vpq3awd25hs.fsf@bauges.imag.fr>
Thanks for the reply!
On 14 Oct 2007, at 9:25:03 AM, Matthieu Moy wrote:
> Michael Witten <mfwitten@MIT.EDU> writes:
>
>> Subject: [PATCH] git-add now understands two kinds of update:
>>
>> -u: update as before
>> -a: update all as in a true 'git commit -a'
>
> I don't find the option set very intuitive. I'd prefer
>
> - git add -u . => update the current directory as before
> - git add -u => update all files from the root.
>
> But your solution has the advantage of being backward compatible, so,
> no strong opinion here.
Here's compromise that is backwards compatible. For both git-add
and git-commit:
-a dir [dir2 ...] => all changes in the given dirs.
-a => all changes from the root.
Then we can just leave -u in place for now, and mark it as deprecated.
In any case, the goal is to make the intuition solid between
git-commit and git-add.
> (side note: also, while you're here, it would be nice to have a single
> command to do "git add .; git add -u", i.e add all unknown files,
> update all existing files, and actally remove all deleted files. In
> one word, synchronize the index with the working tree completely.
> Perhaps "-a" would be a good name for that, not sure)
We can couple the above with -f to do this.
>> builtin-add.c | 69 +++++++++++++++++++++++++++++++++++++
>> +-------------------
>
> Your patch is whitespace-damaged. I don't know how to fix that for
> Apple Mail, but git-send-email can help.
I see that now; Apple's trying to be smart about blank lines, it
would seem.
>> static const char builtin_add_usage[] =
>> "git-add [-n] [-v] [-f] [--interactive | -i] [-u] [--refresh] [--]
>> <filepattern>...";
>
> You should document -a here, and in Documentation/git-add.txt if you
> introduce it.
Let's get -a/-u squared away first.
Thanks again,
Michael Witten
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Jakub Narebski @ 2007-10-14 21:49 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Schindelin, git
In-Reply-To: <853awepyz6.fsf@lola.goethe.zz>
On 10/13/07, David Kastrup <dak@gnu.org> wrote:
> I find it a pity that my suggestion to ask about how comfortable
> people are with the tone on the list did not make it into the survey.
> Enough core developers make the tone sufficiently unconstructive to
> make it quite understandable that people are unwilling to ask
> questions here, in order to avoid getting their heads banged against a
> wall, virtual or not.
I think next to last question in the survey
61. Did you have problems getting GIT help on mailing list or on IRC channel?
What were it? What could be improved?
was the place to put complaints about git mailing list. I didn't want
to add separate question because this survey has too many questions
(is too long) already.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 2/6] add get_sha1_with_real_ref() returning full name of ref on demand
From: Steffen Prohaska @ 2007-10-14 21:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710141819490.25221@racer.site>
On Oct 14, 2007, at 7:21 PM, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 14 Oct 2007, Steffen Prohaska wrote:
>
>> Deep inside get_sha1() the name of the requested ref is matched
>> according to the rules documented in git-rev-parse. This patch
>> introduces a function that returns the full name of the matched
>> ref to the outside.
>>
>> For example 'master' is typically returned as 'refs/heads/master'.
>>
>> The new function can be used by "git rev-parse" to print the full
>> name of the matched ref and can be used by "git send-pack" to expand
>> a local ref to its full name.
>
> I have not really studies your patch, but from your description it
> sounds
> as if dwim_ref() does what you want.
Without my patch get_sha1_with_mode() calls get_sha1_1() calls
get_sha1_basic()
calls dwim_ref(). I didn't analyze in detail what the *sha1*
functions add
to what dwim_ref() provides.
The patch passes the information from dwim_ref() up the callstack.
Maybe this
is not needed and I could directly call dwim_ref(). But I don't know.
Steffen
^ permalink raw reply
* Re: [PATCH] Fix a crash in ls-remote when refspec expands into nothing
From: Lars Hjemli @ 2007-10-14 21:26 UTC (permalink / raw)
To: Alex Riesen
Cc: Shawn O. Pearce, Jeff King, Väinö Järvelä,
git, Junio C Hamano
In-Reply-To: <20071012204004.GA6700@steel.home>
On 10/12/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> Shawn O. Pearce, Fri, Oct 12, 2007 06:07:45 +0200:
> > I think the above patch is the only thing to do here. Perhaps Alex
> > can write up a formal patch and send it to back to the list and CC
> > Lars Hjemli <hjemli@gmail.com> so he can put it into the patch queue.
>
> here you go
>
Thanks. I've replaced the tip of q/vj/fetch-t (in
git://hjemli.net/pub/git/git) with this patch.
--
larsh
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: David Tweed @ 2007-10-14 21:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0710130130380.25221@racer.site>
On 10/13/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Figure out why people find git hard to learn and eliminate those
> > barriers to entry. Make git more task-oriented rather than
> > data-model-oriented the way it is now.
>
> Frankly, expectations like these make me want to bang somebody's head on
> the wall. Why do people expect others to work for them for free? Hard?
Since no-one else has mentioned it, I -- and I suspect some others --
try to use the "beer round" model with FOSS. When I go out for drinks
with people from work, I don't try and keep a precisely tally of who
has bought a drink for me and so whom I shoud buy a drink, and worry
about what how the accounting changes if me or someone goes home
early. I generally take the view that all the imbalances will roughly
balance out over the future. Sure you keep an eye out for complete
freeloaders, but you don't get overexcited about a temporary
imbalance.
Likewise, I will sometimes make suggestions -- hopefully politely --
of various projects where my skills don't fit. (Eg, I'm not going to
add non-trivial features to the git shell scripts because I just don't
know non-trivial shell.) Hopefully some minor patch I've submitted
somewhere has, possibly through helping someone else who's helped
someone else.... , helped you some minuscule amount.
I'm perfectly fine with someone politely saying "no developers are
interested in this, so it won't happen if you don't implement it
yourself", but when you accuse people who just bring up a possible
feature of being free-loaders it makes them question whether other
projects would be more productive places to spend one's time.
It's the difference between being told "I suspect you'll have to do it
yourself" and "how dare you even ask that! do it yourself!".
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* Re: [PATCH] Add color to git-add--interactive diffs (Take 2: now without spurious line break!)
From: Wincent Colaiuta @ 2007-10-14 21:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tom Tobin, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710141814100.25221@racer.site>
El 14/10/2007, a las 19:15, Johannes Schindelin escribió:
> On Sun, 14 Oct 2007, Wincent Colaiuta wrote:
>
>>> +sub parse_color {
>>
>> You could simplify the manual escape sequence construction that
>> you're
>> doing here by using Term::ANSIColor like the other patches did. I see
>> that git-send-email.perl uses that module too, so I guess
>> depending on
>> that module is ok.
>
> Wrong. Depending on that module is not correct, you always have to
> wrap
> it into an "if (<is_color>) {...}".
>
> I use git add -i quite often, and I _never_ use git send-email. My
> guess
> is that I am not alone with that.
In that case I propose factoring out the escape sequence generation
into git.pm, where it can be used by git-send-email, git-add--
interactive, or any other Perl script in Git. Do you think that's a
good idea? If so I'll try whipping up a patch along those lines.
Wincent
^ permalink raw reply
* Re: [PATCH] parse-options: Allow abbreviated options when unambiguous
From: Eric Wong @ 2007-10-14 21:01 UTC (permalink / raw)
To: Pierre Habouzit, Johannes Schindelin, git
In-Reply-To: <20071014180815.GK1198@artemis.corp>
Pierre Habouzit <madcoder@debian.org> wrote:
> On Sun, Oct 14, 2007 at 06:02:33PM +0000, Johannes Schindelin wrote:
> > Hi,
> >
> > On Sun, 14 Oct 2007, Johannes Schindelin wrote:
> >
> > > When there is an option "--amend", the option parser now recognizes
> > > "--am" for that option, provided that there is no other option beginning
> > > with "--am".
> >
> > And an amend for ultra-abbreviated options (as you noticed on IRC):
> >
> > diff --git a/parse-options.c b/parse-options.c
> > index afc6c89..acabb98 100644
> > --- a/parse-options.c
> > +++ b/parse-options.c
> > @@ -137,6 +137,11 @@ is_abbreviated:
> > abbrev_flags = flags;
> > continue;
> > }
> > + /* negated and abbreviated very much? */
> > + if (!prefixcmp("no-", arg)) {
> > + flags |= OPT_UNSET;
> > + goto is_abbreviated;
> > + }
> > /* negated? */
> > if (strncmp(arg, "no-", 3))
> > continue;
>
> squashed on top on the previous, and pushed to my ph/parseopt branch.
Awesome. Thanks to both of you.
--
Eric Wong
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: J. Bruce Fields @ 2007-10-14 20:24 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Andreas Ericsson, Steven Grimm, Reece Dunn, Shawn O. Pearce,
Linus Torvalds, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0710142117220.25221@racer.site>
On Sun, Oct 14, 2007 at 09:18:16PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 14 Oct 2007, Andreas Ericsson wrote:
>
> > J. Bruce Fields wrote:
> >
> > > Though actually the quickest way to checkout an arbitrary revision is
> > > with detached heads, and that doesn't require learning git-branch
> > > right away.
> >
> > But the *easiest* way, where "easiest" means "involves the fewest
> > commands with smallest risk of fscking up your own repo", is to do
> >
> >
> > git clone <other-devs-repo> other-devs-repo
> > cd other-devs-repo
> > git checkout -b thebug <the-bug-hash>
>
> I'd just do
>
> git checkout <the-bug>^{commit}
>
> and be done...
The detached-HEAD approach also has the advantage that you don't leave
around stuff (new branch heads) that may have to be cleaned up or
modified in the future. So you can tell someone about
git clone git://url/
git fetch origin
git checkout <whatever>
git remote add remotename git://other-url/
git fetch remotename
and as long as they're not making changes, that's pretty much all
they'll ever need to do to checkout any version.
Sure, you can tell them to reclone every time, but I think they'll get
frustrated with that pretty soon.
--b.
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-14 20:22 UTC (permalink / raw)
To: Johannes Schindelin
Cc: J. Bruce Fields, Steven Grimm, Reece Dunn, Shawn O. Pearce,
Linus Torvalds, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0710142117220.25221@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sun, 14 Oct 2007, Andreas Ericsson wrote:
>
>> J. Bruce Fields wrote:
>>
>>> Though actually the quickest way to checkout an arbitrary revision is
>>> with detached heads, and that doesn't require learning git-branch
>>> right away.
>> But the *easiest* way, where "easiest" means "involves the fewest
>> commands with smallest risk of fscking up your own repo", is to do
>>
>>
>> git clone <other-devs-repo> other-devs-repo
>> cd other-devs-repo
>> git checkout -b thebug <the-bug-hash>
>
> I'd just do
>
> git checkout <the-bug>^{commit}
>
> and be done...
>
So:
if (have_bug_in_repo)
do_the_dscho_way()
else ...
See what I mean?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git blame crashes with internal error
From: Johannes Schindelin @ 2007-10-14 20:21 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Andreas Ericsson, gitster, git
In-Reply-To: <20071014201813.GA26872@atjola.homenet>
Hi,
On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:
> On 2007.10.14 18:32:44 +0100, Johannes Schindelin wrote:
> >
> > On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:
> >
> > > On 2007.10.14 16:51:46 +0200, Andreas Ericsson wrote:
> > > > Bj?rn Steinbrink wrote:
> > > >> I tried all git releases from 1.5.3 to 1.5.3.4 as well as the current
> > > >> master and all of them crashed. A small shell script to reproduce the
> > > >> problem is attached.
> > > >
> > > > Manual bisect? Ugh. This *is* the century of the competent developer
> > > > tools, you know... ;-)
> > >
> > > Then, how do I search for a good version with git bisect if I only have
> > > the one data-point "master is bad"?
> >
> > AFAIK Junio introduced the option to start with just a bad commit, and no
> > known "good" one.
> >
> > Yep, just found it. Since v1.5.2-rc0~77^2(git-bisect: allow bisecting
> > with only one bad commit.) it is supported.
> >
> > >From the commit message:
> >
> > This allows you to say:
> >
> > git bisect start
> > git bisect bad $bad
> > git bisect next
>
> OK, using that approach, I bisected it, and even found a "guilty"
> commit, although it is pretty much useless:
>
> 1cfe77333f274c9ba9879c2eb61057a790eb050f is first bad commit
> commit 1cfe77333f274c9ba9879c2eb61057a790eb050f
> Author: Junio C Hamano <junkio@cox.net>
> Date: Tue Jan 30 01:11:08 2007 -0800
>
> git-blame: no rev means start from the working tree file.
I think it is not useless. It says exactly the same as I did, in another
reply: git blame starts with your working tree. As such, it has to do
some operations which happen to fail on unmerged files.
So the solution in your case _really_ is:
git blame HEAD file2
Explanation: with that command line, you ask git blame to start with a
given revision (instead of the working tree), which just so happens to be
the HEAD revision.
Hth,
Dscho
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-14 20:18 UTC (permalink / raw)
To: Andreas Ericsson
Cc: J. Bruce Fields, Steven Grimm, Reece Dunn, Shawn O. Pearce,
Linus Torvalds, Jakub Narebski, git
In-Reply-To: <471272F5.2000902@op5.se>
Hi,
On Sun, 14 Oct 2007, Andreas Ericsson wrote:
> J. Bruce Fields wrote:
>
> > Though actually the quickest way to checkout an arbitrary revision is
> > with detached heads, and that doesn't require learning git-branch
> > right away.
>
> But the *easiest* way, where "easiest" means "involves the fewest
> commands with smallest risk of fscking up your own repo", is to do
>
>
> git clone <other-devs-repo> other-devs-repo
> cd other-devs-repo
> git checkout -b thebug <the-bug-hash>
I'd just do
git checkout <the-bug>^{commit}
and be done...
Ciao,
Dscho
^ permalink raw reply
* Re: git blame crashes with internal error
From: Björn Steinbrink @ 2007-10-14 20:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, gitster, git
In-Reply-To: <Pine.LNX.4.64.0710141830050.25221@racer.site>
On 2007.10.14 18:32:44 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:
>
> > On 2007.10.14 16:51:46 +0200, Andreas Ericsson wrote:
> > > Bj?rn Steinbrink wrote:
> > >> I tried all git releases from 1.5.3 to 1.5.3.4 as well as the current
> > >> master and all of them crashed. A small shell script to reproduce the
> > >> problem is attached.
> > >
> > > Manual bisect? Ugh. This *is* the century of the competent developer
> > > tools, you know... ;-)
> >
> > Then, how do I search for a good version with git bisect if I only have
> > the one data-point "master is bad"?
>
> AFAIK Junio introduced the option to start with just a bad commit, and no
> known "good" one.
>
> Yep, just found it. Since v1.5.2-rc0~77^2(git-bisect: allow bisecting
> with only one bad commit.) it is supported.
>
> >From the commit message:
>
> This allows you to say:
>
> git bisect start
> git bisect bad $bad
> git bisect next
OK, using that approach, I bisected it, and even found a "guilty"
commit, although it is pretty much useless:
1cfe77333f274c9ba9879c2eb61057a790eb050f is first bad commit
commit 1cfe77333f274c9ba9879c2eb61057a790eb050f
Author: Junio C Hamano <junkio@cox.net>
Date: Tue Jan 30 01:11:08 2007 -0800
git-blame: no rev means start from the working tree file.
Warning: this changes the semantics.
This makes "git blame" without any positive rev to start digging
from the working tree copy, which is made into a fake commit
whose sole parent is the HEAD.
It also adds --contents <file> option to pretend as if the
working tree copy has the contents of the named file. You can
use '-' to make the command read from the standard input.
If you want the command to start annotating from the HEAD
commit, you need to explicitly give HEAD parameter.
Signed-off-by: Junio C Hamano <junkio@cox.net>
> I don't know if it is in the documentation (I rarely read it), so if it is
> missing, it would be nice if you could add the description there.
Nothing in there yet AFAICT. Will try to get a patch done tomorrow.
thanks,
Björn
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-14 20:14 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Benoit SIGOURE, git list, Eli Zaretskii, Make Windows
In-Reply-To: <47126957.1020204@op5.se>
Hi,
On Sun, 14 Oct 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > I do not see any reason why libification helps the user experience on
> > Windows.
>
> I was under the impression that the windows port suffers from Windows'
> lack of a proper fork() and friends and that a proper library would help
> solving those problems. Perhaps I was misinformed.
It suffered. Until Hannes Sixt did a very fine job which cumulated in the
patch series he posted yesterday. Of course, this work is the reason
msysGit is functional.
Ciao,
Dscho
^ permalink raw reply
* Re: Addition of "xmlto" to install documentation
From: Markus Elfring @ 2007-10-14 19:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
> Well, it is not strictly necessary to build git, and not even
> to install it, if you have the "man" branch.
Thanks for your reply.
I'll have to admit that I overlooked the hint for "the asciidoc/xmlto toolchain" because it was in a separate paragraph instead of another item in the system requirements enumeration. (The tool's version number does not look promising so far.)
I rebuilt Git on my system because I was notified that a newer release became available.
Regards,
Markus
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 1768 bytes --]
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-14 19:50 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Steven Grimm, Reece Dunn, Shawn O. Pearce, Linus Torvalds,
Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <20071014184050.GB31260@fieldses.org>
J. Bruce Fields wrote:
> On Sun, Oct 14, 2007 at 11:12:07AM -0700, Steven Grimm wrote:
>
>> It's possible git's introductory documentation should delay talking
>> about "git branch" until later, and start off talking about how to work
>> with one (checked out) branch per repo.
>
> One frequent use case is the case of a tester that wants to try out a
> bugfix in some topic branch. You want to tell them: "please test the
> fix-that-bug branch in git://myproject.org/~me/repo.git". They need to
> get that checked out somehow. And they should be able to do it without
> re-cloning every time.
>
> That's one motivation, among others, for including git-branch (and
> git-remote) very early.
>
> Though actually the quickest way to checkout an arbitrary revision is
> with detached heads, and that doesn't require learning git-branch right
> away.
But the *easiest* way, where "easiest" means "involves the fewest commands
with smallest risk of fscking up your own repo", is to do
git clone <other-devs-repo> other-devs-repo
cd other-devs-repo
git checkout -b thebug <the-bug-hash>
The proper command-sequence for any other way of doing it will inevitably
be different depending on whether or not the user has changes in his
worktree or not, whether or not those changes conflict with the bug-spot,
whether or not he's got the other developer's repo added as a remote, etc,
etc.
Too many ifs, really, whereas the first way is guaranteed to work exactly
the same way everytime, at the cost of almost always being ridiculously
suboptimal.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Nicolas Pitre @ 2007-10-14 19:44 UTC (permalink / raw)
To: Steven Grimm
Cc: Reece Dunn, Shawn O. Pearce, Linus Torvalds, Johannes Schindelin,
J. Bruce Fields, Jakub Narebski, git
In-Reply-To: <47125BF7.2070503@midwinter.com>
On Sun, 14 Oct 2007, Steven Grimm wrote:
> Verbosity. IMO Mercurial swings too far in this direction, but in general it's
> either completely silent or very terse in its output. There is never, as far
> as I can see, any low-level diagnostic information spit out to the user unless
> an hg command is run with a "verbose" option. Here's "hg pull; hg update", for
> example (and "pull" is one of hg's chattier commands):
>
> pulling from ../child1
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 8 changesets with 8 changes to 3 files (+1 heads)
> (run 'hg heads' to see heads, 'hg merge' to merge)
> 3 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
> Compare with the equivalent "git pull" and put yourself in the shoes of a user
> who is running that command for the first time:
BTW I have patches here reworking the progress code for a more compact
display which should mitigate this issue quite a bit.
Nicolas
^ 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