* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 14:07 UTC (permalink / raw)
To: Marek Zawirski; +Cc: Junio C Hamano, git, Stephan Beyer
In-Reply-To: <48886B8F.6000304@gmail.com>
On Tue, 24 July 2008, Marek Zawirski wrote:
> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>> (...)
>>
>>> 27. Which of the following features do you use?
>>> (zero or more: multiple choice)
>>> - git-gui or other commit tool, gitk or other history viewer, patch
>>> management interface (e.g. StGIT), bundle, eol conversion,
>>> gitattributes, submodules, separate worktree, reflog, stash,
>>> shallow clone, detaching HEAD, mergetool, interactive rebase,
>>> add --interactive or other partial commit helper, commit
>>> templates, bisect, other (not mentioned here)
>>>
> I've got lost a little bit in this discussion, but some question about
> used GUI for Git maybe interesting - the above one is touching the
> problem. Just egit is missing there.
Actually jgit is in the list of possible choices for the following
question:
16. Which porcelains / interfaces / implementations do you use?
But you have remind me about one feature that is missing from the 27.
list, namely "integration with IDE/editor" (I mean here things like
egit for Eclipse, future KDevelop DVCS integration, future Anjuta
Git integration, git.el or DVC for Emacs, plugin for TextMate, etc.)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [EGIT] Supported Eclipse version
From: Jean-François Veillette @ 2008-07-24 14:07 UTC (permalink / raw)
To: Marek Zawirski; +Cc: git, Robin Rosenberg, Shawn O. Pearce
In-Reply-To: <48888A2E.4030302@gmail.com>
> Maybe some users (or developers) from mailing list can tell us
> about their opinion?
I think keeping comptability for one version behind the
'current' (still compatible 3.3 while 3.4 is the current) is a
reasonable goal.
3.2 is relatively far behind, tools vendor had time to get up to date
by now.
If a user is using a third party version of eclipse based on 3.2,
then I guess he should not expect egit to work with it (he should
just pray and hope for the best).
For myself, I use 3.3.x, I have not yet moved to 3.4 since my main
plugin (WOLips) is not ready yet for 3.4.
- jfv
^ permalink raw reply
* Re: [PATCH] Preserve cwd in setup_git_directory()
From: Johannes Schindelin @ 2008-07-24 14:09 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Geoff Russell
In-Reply-To: <fcaeb9bf0807240540i400fe0d1s7ea8efe72203471d@mail.gmail.com>
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.
This patch is definitely the opposite of "obviously correct".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-24 14:09 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Schindelin, Junio C Hamano, Git Mailing List
In-Reply-To: <FCAEAB20-750E-47B9-B58D-9BB0CB1EEAFF@zib.de>
On Thu, Jul 24, 2008 at 08:06:29AM +0200, Steffen Prohaska wrote:
>
> I have however a related question:
>
> Dscho,
> Is the following your use case?
>
> "I am the maintainer of this project. I know that this project needs
> crlf conversion, because it is a cross-platform project. Therefore,
> I want to force crlf conversion for this specific project, even if
> the user did not configure core.autocrlf=input on Unix."
I suspect that most problems with crlf is caused by Windows users who
have core.autocrlf=false for whatever reason (I suspect without a good
reason in most cases). But perhaps having core.autocrlf=input as default
on Unix and Mac will be better than the current core.autocrlf=false.
> Maybe we could allow 'crlf=guess' in .gitattributes with the following
> documentation:
Please, no. It feels wrong to complicate crlf settings to workaround
incorrect user configuration. I don't think that many people really will
be able to benefit from that. In most cases, people end up with the
incorrect value autocrlf just because the documentation is complicated
and it is difficult to understand from it what autocrlf does.
So I believe the real solution is providing more reasonable defaults
for autocrlf and more clear and simple explanation, i.e. to have
something like in the introduction section describing how to set up
your own repository:
===
If you work on Windows, you are most likely use text files with CRLF
endings. To ensure that your line endings will be correctly represented
on other platforms, you should set core.autocrlf=true.
If you prefer to have LF endings in your text files, you may want to set
core.autocrlf=input to ensure that files with inconsistent end-of-lines
will not enter into your repository.
autocrlf conversion will automatically detect text files and convert
line endings accordingly to the specified settings. In very rare cases,
heuristic may be wrong[*], so you may want to specify what files should
bed considered as text and what as binary explicitly. You can do that by
setting the crlf attribute in .gitattributes, like this:
*.exe -crlf
*.c crlf
The above says that all files with the .exe extension should be treated
as binary and all files with the .c extension should treated as text.
[*] You do not have to worry too much about heuristic being wrong,
because you will be warned if conversion for a file is irreversible.
See core.safecrlf in linkgit:gitattributes[5] for more information.
===
We should not expect every users to read everything written in
gitattributes just to get autocrlf correctly.
Dmitry
^ permalink raw reply
* Re: git-svn does not seems to work with crlf convertion enabled.
From: Dmitry Potapov @ 2008-07-24 14:24 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Johannes Schindelin, git
In-Reply-To: <200807231852.10206.litvinov2004@gmail.com>
On Wed, Jul 23, 2008 at 06:52:09PM +0700, Alexander Litvinov wrote:
> > On Wed, 23 Jul 2008, Alexander Litvinov wrote:
> > > In short: I can't clone svn repo into git when crlf convertion is
> > > activated.
> >
> > This is a known issue, but since nobody with that itch seems to care
> > enough to fix it, I doubt it will ever be fixed.
>
> That is a bad news for me. Anyway I will spend some time at holidays during
> digging this bug.
I don't want to discourage from digging into this problem, but there are
two reasons why no one has fixed this issue yet. First, configuration
CRLF conversion in Git and SVN is quite different, so it may not be easy
to have the solution that will work in all cases. Second, in many cases,
you can workaround this issue.
If I understood your situation correctly, you use SVN repo where text
files are marked with svn:eol-style=native. In this case, SVN stores
these files with LF endings internally, and git-svn receives files in
that format (at least, it is so on Debian). Practically all Windows
editors do not have problems to open and edit files with LF endings, but
some of them will write back using CRLF. You do not want CRLF to get in
your Git repository, so you can do that by setting core.autocrlf=input.
This might work for you...
Dmitry
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-24 14:38 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Steffen Prohaska, Junio C Hamano, Git Mailing List
In-Reply-To: <20080724140959.GU2925@dpotapov.dyndns.org>
Hi,
On Thu, 24 Jul 2008, Dmitry Potapov wrote:
> On Thu, Jul 24, 2008 at 08:06:29AM +0200, Steffen Prohaska wrote:
> >
> > I am the maintainer of this project. I know that this project needs
> > crlf conversion, because it is a cross-platform project.
> > Therefore, I want to force crlf conversion for this specific
> > project, even if the user did not configure core.autocrlf=input on
> > Unix.
>
> I suspect that most problems with crlf is caused by Windows users who
> have core.autocrlf=false for whatever reason (I suspect without a good
> reason in most cases).
Almost correct. It is _unset_! And it should be perfectly valid for
users not having to set anything there.
> But perhaps having core.autocrlf=input as default on Unix and Mac will
> be better than the current core.autocrlf=false.
Have you read Junio's reply? If so, how can you suggest any change for
Unix and Mac?
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn does not seems to work with crlf convertion enabled.
From: Johannes Schindelin @ 2008-07-24 14:40 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Alexander Litvinov, git
In-Reply-To: <20080724142453.GV2925@dpotapov.dyndns.org>
Hi,
On Thu, 24 Jul 2008, Dmitry Potapov wrote:
> On Wed, Jul 23, 2008 at 06:52:09PM +0700, Alexander Litvinov wrote:
> > > On Wed, 23 Jul 2008, Alexander Litvinov wrote:
> > > > In short: I can't clone svn repo into git when crlf convertion is
> > > > activated.
> > >
> > > This is a known issue, but since nobody with that itch seems to care
> > > enough to fix it, I doubt it will ever be fixed.
> >
> > That is a bad news for me. Anyway I will spend some time at holidays
> > during digging this bug.
>
> I don't want to discourage from digging into this problem
Great. Thanks. There is someone who is actually willing to work on the
problem.
> Practically all Windows editors do not have problems to open and edit
> files with LF endings, but some of them will write back using CRLF.
95.23% of all statistics are made up on the spot. I would be surprised if
that was not the case here.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 7/9] builtin-checkout-index.c: use parse_options()
From: Johannes Schindelin @ 2008-07-24 14:44 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git, gitster
In-Reply-To: <1216849332-26813-8-git-send-email-barra_cuda@katamail.com>
Hi,
On Wed, 23 Jul 2008, Michele Ballabio wrote:
> + { OPTION_CALLBACK, 'f', "force", &state, NULL,
> + "force overwrite of existing files",
> + PARSE_OPT_NOARG, parse_state_force_cb, 0 },
I wonder if this could not be written as
OPT_BOOLEAN('f', "force", &state.force,
"force overwrite of existing files"),
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jon Loeliger @ 2008-07-24 14:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Stephan Beyer
In-Reply-To: <200807230325.04184.jnareb@gmail.com>
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?
> 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?
> (The choices include programming languages used by git)
> (zero or more: multiple choice)
> - C, shell, Perl, Python, Tcl/Tk
> + (should we include other languages, like C++, Java, PHP,
> Ruby,...?)
>
>
> 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.
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.
> 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?
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]
> 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.)
> + 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.
>
> 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?
> 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?" ?
> 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...
> 12. Why did you choose other SCMs? (if you use other SCMs)
> What do you like about using other SCMs?
> Note: please write name of SCMs you are talking about.
> (free form, not to be tabulated).
>
>
> 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.
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.
> 14. How do you obtain Git?
> - binary package/source package or source script(*)/
> source tarball/pull from main repository
> (*) this includes source based distributions like Gentoo
> + added new option: source package or source script
> + should this be multiple choice?
> 15. What operating system do you use Git on?
> (one or more: multiple choice, as one can use more than one OS)
> - Linux, *BSD (FreeBSD, OpenBSD, etc.), MS Windows/Cygwin,
> MS Windows/msysGit, MacOS X, other UNIX, other
> + "What hardware platforms do you use GIT on?" question was
> removed; should it stay?
> 15b.If you selected "other UNIX", or "other", what operating system
> or systems it was/were?
> (free form)
> 16. Which porcelains / interfaces / implementations do you use?
> (zero or more: multiple choice)
> - core-git, Cogito (deprecated), StGIT, Guilt, pg (deprecated),
> Pyrite, Easy Git, IsiSetup, jgit, my own scripts, other
> 16b.If you selected "other porcelain", what is its name?
> (free form)
> 17. Which git GUI (commit tool or history viewer, or both) do you use
> (zero or more: multiple choice)
> - CLI, gitk, git-gui, qgit, gitview, giggle, tig, instaweb,
> (h)gct, qct, KGit, git-cola / ugit, GitNub, Pyrite, git.el, other
> 17b.If you selected "other GUI", what is its name?
> (free form)
> 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, ...)
> used to host git web interface?
Probably not. Most people might not even know.
> 18b.If you selected "other web interface", what it was?
> (free form)
> 19. How do you publish/propagate your changes?
> (zero or more: multiple choice)
> - push, pull request, format-patch + email, bundle, other
> 19b.If the way you publish your changes is not mentioned above, how
> do you publish your changes?
> (free form)
> 20. Does git.git repository include code produced by you?
> - yes/no
>
>
> What you think of Git
>
> 21. Overall, how happy are you with Git?
> - unhappy/not so happy/happy/very happy/completely ecstatic
> 22. How does Git compare to other SCM tools you have used?
> - worse/equal (or comparable)/better
> 23. What would you most like to see improved about Git?
> (features, bugs, plug-ins, documentation, ...)
> 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... :-)
>
> Changes in Git (since year ago, or since you started using it)
>
> 25. Did you participate in previous Git User's Surveys?
> (zero or more, multiple choice)
> - 2006, 2007
> 26. How do you compare current version with version from year ago?
> - current version is: better/worse/no changes
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.
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.
> 27. Which of the following features do you use?
> (zero or more: multiple choice)
> - git-gui or other commit tool, gitk or other history viewer, patch
> management interface (e.g. StGIT), bundle, eol conversion,
> gitattributes, submodules, separate worktree, reflog, stash,
> shallow clone, detaching HEAD, mergetool, interactive rebase,
> add --interactive or other partial commit helper, commit
> templates, bisect, other (not mentioned here)
> + should probably be sorted in some resemblance of order
> + are there any new features which should be listed here?
> 28. If you use some important Git features not mentioned above,
> what are it?
> (free form)
>
>
> Documentation
>
> 29. Do you use the Git wiki?
> - yes/no
> 30. Do you find Git wiki useful?
> - yes/no/somewhat
> 31. Do you contribute to Git wiki?
> - yes/no/only corrections or spam removal
If "no", why not? [Wikis suck, I don't know the answers, no time...]
> 32. Do you find Git's on-line help (homepage, documentation) useful?
> - yes/no/somewhat
Confusing.
> 33. Do you find help distributed with Git useful
> (manpages, manual, tutorial, HOWTO, release notes)?
> - yes/no/somewhat
> 34. What could be improved on the Git homepage?
> (free form)
> 35. What could be improved in Git documentation?
> (free form)
>
>
> Getting help, staying in touch
>
> 36. Have you tried to get Git help from other people?
> - yes/no
> 37. What channel did you use to request help?
> (zero or more: multiple choice)
> - git mailing list, git users group, IRC, blog post,
> other
> + this is one question which doesn't need, I think, explanation
> of "other" choice
> 38. If yes, did you get these problems resolved quickly
> and to your liking?
> - yes/no
> 39. Would commerical (paid) support from a support vendor
> be of interest to you/your organization?
> - yes/no/not applicable
s/commerical/commercial/
> 40. Do you read the mailing list?
> - yes/no
> 41. If yes, do you find it useful?
> - yes/no (optional)
> 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]
> 43. Do you use the IRC channel (#git on irc.freenode.net)?
> - yes/no
> 44. If yes, do you find IRC channel useful?
> - yes/no (optional)
> 45. Did you have problems getting GIT help on mailing list or
> on IRC channel? What were it? What could be improved?
> (free form)
>
> 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,
jdl
^ permalink raw reply
* gitweb tags feed, Re: New version announcements?
From: Petr Baudis @ 2008-07-24 14:49 UTC (permalink / raw)
To: Jordi Bunster; +Cc: git, gitster
In-Reply-To: <3B8DB770-5ADC-4B99-9A12-F1DABA20C34D@bunster.org>
Hi,
On Thu, Jul 24, 2008 at 10:38:24AM -0400, Jordi Bunster wrote:
> I've been following the git mailing list to stay on top of new releases,
> but the traffic got too high.
>
> Any way that a git-announce list could be created for security fixes and
> new releases? Or maybe an RSS feed on the website?
>
> If there's a news file or some-such, I'd be glad to write the code to
> convert it to a subscription feed.
I believe you meant to write this to the list directly, I'm cc'ing it
now. Basically, this depends on whether Junio finds it worth-while. :-)
I think these requests do not pop up often, but that might mean that
most people are simply discouraged right away and too shy to ask for it.
One thing that comes on my mind would be to implement RSS feed of new
tags to gitweb; this could supply the information about new releases
easily. Any bored gitweb hacker willing to implement this? ;-)
(Of course, it is a bit of pity that release announcements aren't part
of the tag comment when Git already makes tag comments possible; that
could be a part of the feed. Maybe with the feed as a nice use-case,
Junio could get convinced to do that though, if it doesn't disrupt his
release workflow too much.)
--
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] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Steffen Prohaska @ 2008-07-24 14:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Potapov, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807241537000.8986@racer>
On Jul 24, 2008, at 4:38 PM, Johannes Schindelin wrote:
> On Thu, 24 Jul 2008, Dmitry Potapov wrote:
>
>> On Thu, Jul 24, 2008 at 08:06:29AM +0200, Steffen Prohaska wrote:
>>>
>>> I am the maintainer of this project. I know that this project
>>> needs
>>> crlf conversion, because it is a cross-platform project.
>>> Therefore, I want to force crlf conversion for this specific
>>> project, even if the user did not configure core.autocrlf=input on
>>> Unix.
>>
>> I suspect that most problems with crlf is caused by Windows users who
>> have core.autocrlf=false for whatever reason (I suspect without a
>> good
>> reason in most cases).
>
> Almost correct. It is _unset_! And it should be perfectly valid for
> users not having to set anything there.
Why is it unset? Since 1.5.5, our installer sets core.autocrlf=true
on Windows. So we *do* set a sane default for Windows users.
In the projects I am using git, the problematic platform is *Unix*.
To work around the default on Unix (core.autocrlf=false), I deliver
a custom script to our developers that verifies the setup on Unix and
complains if core.autocrlf is not set to "input". Since I do this,
I haven't seen any further problems.
Steffen
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Ingo Molnar @ 2008-07-24 15:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: SZEDER Gábor, git
In-Reply-To: <7v8wvscqtm.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> wrote:
> Ingo Molnar <mingo@elte.hu> writes:
>
> > hm, it's very slow:
> >
> > $ time git branch --no-merged
> > [...]
> >
> > real 0m9.177s
> > user 0m9.027s
> > sys 0m0.129s
> >
> > when running it on tip/master:
> >
> > http://people.redhat.com/mingo/tip.git/README
>
> Hmmm, does not reproduce for me with a copy of that repository.
perhaps you need to run tip-create-local-branches.sh to create all the
local branches? You can find it in:
tip/tip .tip/bin/tip-create-local-branches.sh
(does/should the presence of local branches matter?)
Ingo
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Ingo Molnar @ 2008-07-24 15:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: SZEDER Gábor, git
In-Reply-To: <7vy73seb2p.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> wrote:
> (with patch)
> 0.15user 0.03system 0:00.18elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
> (without patch)
> 0.58user 0.03system 0:00.61elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
cool - a 3.3x speedup :-) Will check that out.
Ingo
^ permalink raw reply
* Re: gitweb tags feed, Re: New version announcements?
From: Julian Phillips @ 2008-07-24 15:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jordi Bunster, git, gitster
In-Reply-To: <20080724144939.GI10151@machine.or.cz>
On Thu, 24 Jul 2008, Petr Baudis wrote:
> Hi,
>
> On Thu, Jul 24, 2008 at 10:38:24AM -0400, Jordi Bunster wrote:
>> I've been following the git mailing list to stay on top of new releases,
>> but the traffic got too high.
>>
>> Any way that a git-announce list could be created for security fixes and
>> new releases? Or maybe an RSS feed on the website?
An RSS feed already exists, have a look at http://gitrss.q42.co.uk/.
>>
>> If there's a news file or some-such, I'd be glad to write the code to
>> convert it to a subscription feed.
>
> I believe you meant to write this to the list directly, I'm cc'ing it
> now. Basically, this depends on whether Junio finds it worth-while. :-)
> I think these requests do not pop up often, but that might mean that
> most people are simply discouraged right away and too shy to ask for it.
There was a request for RSS feeds some time ago, and I setup the above
feeds which automatically process the git mailing list traffic - haven't
bothered to actually monitor if anyone is using them though ;)
>
> One thing that comes on my mind would be to implement RSS feed of new
> tags to gitweb; this could supply the information about new releases
> easily. Any bored gitweb hacker willing to implement this? ;-)
>
> (Of course, it is a bit of pity that release announcements aren't part
> of the tag comment when Git already makes tag comments possible; that
> could be a part of the feed. Maybe with the feed as a nice use-case,
> Junio could get convinced to do that though, if it doesn't disrupt his
> release workflow too much.)
>
>
--
Julian
---
Peter's hungry, time to eat lunch.
^ permalink raw reply
* Submodules: Publishing a locally created submodule.
From: Thomas Adam @ 2008-07-24 15:40 UTC (permalink / raw)
To: git mailing list
Hello all,
I'm a little confused having read the submodule chapter in the GIT
users' manual and was wondering if someone here can help.
I've setup a bare repository with some submodule in it which I and
others are able to clone from just fine -- in that sense, it acts just
like an "ordinary" repository.
But I am a little stuck getting my head around a scenario:
Most us here work in a very CVS-like way. I did the following:
git clone ssh://foo/bar/project myclone
cd ./myclone
In there is a directory which is a submodule. At the time I created
the bare repo it was cloned already from a repo which had a submodule.
I decided I wanted another submodule to be published so I did this:
cp -r ./mysubmoduleA ./mysubmoduleB && rm ./mysubmoduleB/.git
Now: I want to make mysubmoduleB a submodule which I can publish to
the shared repository and when others pull, to see that submodule and
be able to treat it as such.
But I can't see how to do that. Can someone help?
Many thanks in advance.
-- Thomas Adam
^ permalink raw reply
* Re: gitweb tags feed, Re: New version announcements?
From: Jakub Narebski @ 2008-07-24 15:54 UTC (permalink / raw)
To: Julian Phillips; +Cc: Petr Baudis, Jordi Bunster, git, gitster
In-Reply-To: <Pine.LNX.4.64.0807241600190.7093@reaper.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
> On Thu, 24 Jul 2008, Petr Baudis wrote:
>> On Thu, Jul 24, 2008 at 10:38:24AM -0400, Jordi Bunster wrote:
>>>
>>> I've been following the git mailing list to stay on top of new releases,
>>> but the traffic got too high.
>>>
>>> Any way that a git-announce list could be created for security fixes and
>>> new releases? Or maybe an RSS feed on the website?
>
> An RSS feed already exists, have a look at http://gitrss.q42.co.uk/.
>
>>> If there's a news file or some-such, I'd be glad to write the code to
>>> convert it to a subscription feed.
> There was a request for RSS feeds some time ago, and I setup the above
> feeds which automatically process the git mailing list traffic -
> haven't bothered to actually monitor if anyone is using them though ;)
If I didn't thank you for this web service (http://gitrss.q42.co.uk/)
thanks, if I did thank yoy, thanks again :-)
I have used this service (to be more exact one of feeds offered by
this service, which basically is very filtered git mailing list feed)
as a source of "News" section for Git project at Ohloh[1]:
http://www.ohloh.net/projects/git
[1] http://www.ohloh.net/projects/git/rss_subscriptions uses
http://gitrss.q42.co.uk/announce.rss)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 6/9] builtin-init-db.c: use parse_options()
From: Olivier Marin @ 2008-07-24 16:15 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git, gitster
In-Reply-To: <1216849332-26813-7-git-send-email-barra_cuda@katamail.com>
Michele Ballabio a écrit :
>
> + const struct option options[] = {
> + OPT_STRING(0, "template", &template_dir, "dir",
> + "directory from which templates will be used"),
Perhaps "path", "path to the template repository" to stay consistent with clone.
> + OPT_BOOLEAN(0, "bare", &bare, "set up a bare repo"),
s/set up/setup/ and s/repo/repository/?
> + { OPTION_CALLBACK, 0, "shared", &shared_repository,
> + "type", "type of shared repository",
What about "permissions", "setup a shared repository"?
> + PARSE_OPT_OPTARG, parse_opt_shared_cb, PERM_GROUP },
Are you sure the default value is really used here?
Also, perhaps we can play it safer by avoiding changing "share_repository"
directly.
$ git init -> shared_repository == PERM_UMASK
$ git init --shared --no-shared -> shared_repository == 0
It works because PERM_UMASK == 0, but it is a side effect. Don't you think?
> + OPT_BIT('q', "quiet", &flags, "be quiet", INIT_DB_QUIET),
OPT__QUIET(&quiet),
if (quiet)
flags |= INIT_DB_QUIET;
to use the same quiet option everywhere?
Just my opinion,
Olivier.
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Avery Pennarun @ 2008-07-24 16:22 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0807240650v6eab6ad4n63c39973b3b43658@mail.gmail.com>
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).
I think what Dscho is saying is simply that it's natural to put
information about the currently-checked-out tree in the index, and
unnatural to put it in the config.
If I switch branches, or checkout different versions, or git add, or
git rm, it all affects the index, never the config. The index stores
the attributes of which files are checked out, and can detect whether
those files are different from before. Choosing which subtrees to
check out sounds a lot more like one of those operations than it does
like a configuration change.
Also, I don't know if git supports this right now, but I can imagine
situations where you'd want to have more than one index (and
associated working trees) sharing the exact same .git folder. It
would be fine to share the config between these parallel checkouts,
but you certainly couldn't share the index. And you probably wouldn't
want to check out exactly the same set of subtrees in every working
tree.
The information required to do a checkout is in the index. And
"sparse checkout" is all about checking out :)
Have fun,
Avery
^ permalink raw reply
* Re: Submodules: Publishing a locally created submodule.
From: Sean Estabrooks @ 2008-07-24 16:21 UTC (permalink / raw)
To: Thomas Adam; +Cc: git mailing list
In-Reply-To: <18071eea0807240840g79da962ci8fbc65546d496323@mail.gmail.com>
On Thu, 24 Jul 2008 16:40:43 +0100
"Thomas Adam" <thomas.adam22@gmail.com> wrote:
> Now: I want to make mysubmoduleB a submodule which I can publish to
> the shared repository and when others pull, to see that submodule and
> be able to treat it as such.
Hi Thomas,
Submodules are very much fully formed independent repositories. So the
first step is to create a new Git repo that holds the files you want. Publish
this repo in a public place, presumably the same place you published your
other submodules.
In your supermodule use "git submodule add" to include the new public repo
as a submodule in the directory of your choice. After which you can commit
the change and push it out. Other people will need to do "git submodule update"
to make their repos aware of the new submodule.
HTH,
Sean
^ permalink raw reply
* Re: git-svn does not seems to work with crlf convertion enabled.
From: Avery Pennarun @ 2008-07-24 16:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Potapov, Alexander Litvinov, git
In-Reply-To: <alpine.DEB.1.00.0807241539400.8986@racer>
On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 24 Jul 2008, Dmitry Potapov wrote:
> > Practically all Windows editors do not have problems to open and edit
> > files with LF endings, but some of them will write back using CRLF.
>
> 95.23% of all statistics are made up on the spot. I would be surprised if
> that was not the case here.
Without assigning a specific number, Dmitry's experience matches mine.
I haven't seen an editor that can't *read* LF since notepad. But
many of them happily mangle the files.
Of course, notepad is probably at least 50% of the editors most
Windows users actually use, on a per-transaction basis.
Have fun,
Avery
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Johannes Schindelin @ 2008-07-24 16:38 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <32541b130807240922r733dce6aw8b123bbb28c9002@mail.gmail.com>
Hi,
On Thu, 24 Jul 2008, Avery Pennarun wrote:
> [a nice summary about why the index should know the sparse checkout
> prefix]
Thanks.
> Also, I don't know if git supports this right now, but I can imagine
> situations where you'd want to have more than one index (and
> associated working trees) sharing the exact same .git folder.
It is. And I already mentioned it. Note that it can make sense to work
on an index only, without ever touching a working directory.
For example, I do that a lot when importing projects that use
"tarball+patches" for version control.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Avery Pennarun @ 2008-07-24 16:44 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Johannes Schindelin, Dmitry Potapov, Junio C Hamano,
Git Mailing List
In-Reply-To: <465DE5CD-DA13-42B4-B0D8-961F3D118F59@zib.de>
On 7/24/08, Steffen Prohaska <prohaska@zib.de> wrote:
> Why is it unset? Since 1.5.5, our installer sets core.autocrlf=true
> on Windows. So we *do* set a sane default for Windows users.
Well, if you've been following the thread, not everyone uses msysGit,
and cygwin Git doesn't set autocrlf by default, and changing such
things behind people's backs can be really nasty.
So I can't decide if I mean the following as a joke or not ;)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 38b4fcb..91b79dd 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -314,10 +314,19 @@ int init_db(const char *template_dir, unsigned int flags)
}
if (!(flags & INIT_DB_QUIET))
+ {
printf("%s%s Git repository in %s/\n",
reinit ? "Reinitialized existing" : "Initialized empty",
shared_repository ? " shared" : "",
get_git_dir());
+#ifdef _WIN32
+ if (!auto_crlf)
+ printf("WARNING: You're using Windows but core.autocrlf is not set!\n");
+#else
+ if (auto_crlf)
+ printf("WARNING: You're not using Windows but core.autocrlf is set!\n");
+#endif
+ }
return 0;
}
^ permalink raw reply related
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-24 16:45 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Dmitry Potapov, Junio C Hamano, Git Mailing List
In-Reply-To: <465DE5CD-DA13-42B4-B0D8-961F3D118F59@zib.de>
Hi,
On Thu, 24 Jul 2008, Steffen Prohaska wrote:
> On Jul 24, 2008, at 4:38 PM, Johannes Schindelin wrote:
>
> >On Thu, 24 Jul 2008, Dmitry Potapov wrote:
> >
> > >On Thu, Jul 24, 2008 at 08:06:29AM +0200, Steffen Prohaska wrote:
> > > >
> > > > I am the maintainer of this project. I know that this project
> > > > needs crlf conversion, because it is a cross-platform project.
> > > > Therefore, I want to force crlf conversion for this specific
> > > > project, even if the user did not configure core.autocrlf=input on
> > > > Unix.
> > >
> > >I suspect that most problems with crlf is caused by Windows users who
> > >have core.autocrlf=false for whatever reason (I suspect without a
> > >good reason in most cases).
> >
> >Almost correct. It is _unset_! And it should be perfectly valid for
> >users not having to set anything there.
>
> Why is it unset? Since 1.5.5, our installer sets core.autocrlf=true
> on Windows. So we *do* set a sane default for Windows users.
As I mentioned earlier, these users use Cygwin's Git. And they do not
update frequently.
> In the projects I am using git, the problematic platform is *Unix*. To
> work around the default on Unix (core.autocrlf=false), I deliver a
> custom script to our developers that verifies the setup on Unix and
> complains if core.autocrlf is not set to "input". Since I do this, I
> haven't seen any further problems.
That is exactly the use case I had in mind for my patch. If we already
bother to mark the files with crlf=input in .gitattributes, then Git could
be so nice to respect it.
However, I see Junio's point: on sane platforms you have to work hard to
get CR-damaged files. And the regular sane platform user should not be
punished for the brain/CR damage a certain monopolist has brought over
this planet.
Ciao,
Dscho
^ permalink raw reply
* git svn throws locale related error when built from source
From: Anton Mostovoy @ 2008-07-24 16:49 UTC (permalink / raw)
To: git
Hi
I built git 1.5.6.3 manually (no package with 1.5.4+ on gutsy), and I am
getting the error below when running 'git svn rebase'.
svn works fine on its own though.
The default locale is set to en_US.UTF-8
svn: error: cannot set LC_ALL locale
svn: error: environment variable LANG is en_US.UTF-8
svn: error: please check that your locale name is correct
I found a workaround that works, but it would be nice to have it work
properly.
$> LANG= git svn rebase"
Thanks in advance.
-Anton
P.s. I am sending this again, because I did not find the message on
http://dir.gmane.org/gmane.comp.version-control.git
^ permalink raw reply
* Re: gitweb tags feed, Re: New version announcements?
From: Pedro Melo @ 2008-07-24 16:51 UTC (permalink / raw)
To: Julian Phillips; +Cc: Petr Baudis, Jordi Bunster, git, gitster
In-Reply-To: <Pine.LNX.4.64.0807241600190.7093@reaper.quantumfyre.co.uk>
Hi,
On Jul 24, 2008, at 4:04 PM, Julian Phillips wrote:
>> On Thu, Jul 24, 2008 at 10:38:24AM -0400, Jordi Bunster wrote:
>>>
>>> Any way that a git-announce list could be created for security
>>> fixes and
>>> new releases? Or maybe an RSS feed on the website?
>
> An RSS feed already exists, have a look at http://gitrss.q42.co.uk/.
Thanks Julian, did not knew these feeds.
You might want to look at the script that generates the announces
feed. It missed the 1.5.6.4 announcement.
http://article.gmane.org/gmane.comp.version-control.git/89148/
match=1.5.6.4
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ 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