* 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
* 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: 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
* 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: 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: [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
* 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: [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
* 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: 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] 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: 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: 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: [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: [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: [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
* [EGIT] Supported Eclipse version
From: Marek Zawirski @ 2008-07-24 13:57 UTC (permalink / raw)
To: git, Robin Rosenberg, Shawn O. Pearce
This topic arose after 3.4 release. Are we dropping support for 3.2.x
release or not?
I've recently reported some bug at eclipse.org bugzilla regarding broken
FileDialog for 3.3.x and it was closed, marked as resolved in 3.4 with
comment that 3.3.x stream is finished. Actually, this bug is not
critical, just annoying.
It just seems that eclipse.org is trying to force users to update their
Eclipse soon after next stable release.
3.3 also added some interesting APIs, Robin mentioned it one day. I'm
currently just touching TableViewer API and it also have some nice new
features being available since 3.3.
Do we still have to be compatible with 3.2 release? It's about 2 years
old, with last synchronized release/build February 2007. On the other
hand, some commercial tools are still based upon 3.2 release.
Maybe some users (or developers) from mailing list can tell us about
their opinion?
Marek Zawirski
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 13:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807241443230.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:
> > > > > No, I did mean the index. This is an attribute of the index:
> > > > > either it is sparsely checked out or not. You can even have
> > > > > multiple indices (switching between them by setting
> > > > > GIT_INDEX_FILE) which have different prefixes.
> > > >
> > > > I don't think so. It's a mask for workdir, right? If you save it it
> > > > index, you can switch index and the prefix as well, but workdir
> > > > only has several subtrees that do not fit any other prefix than the
> > > > original prefix.
> > >
> > >
> > > Ah, you adroitly avoided addressing the issue that the user can change
> > > the prefix without the index ever noticing.
> >
> > Forgive my ignorance. I still do not get why index must notice prefix
> > change? The only reason I can think of is that we must make sure there
> > won't be any user-modification in index outside the prefix. But that can
> > be guarded from higher level (plumbings and porcelains) because index is
> > allowed to have modification outside sparse prefix (auto-merged
> > entries).
>
>
> Why do you want to guard it from the outside? When the obvious fix is to
> put together what belongs together?
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). But we
are in -rc period now, probably should not put too much time on this.
I will take time to think about this.
--
Duy
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Johannes Schindelin @ 2008-07-24 13:44 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0807240629v6958014bpfa9aebde281ff57@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:
> > > > No, I did mean the index. This is an attribute of the index:
> > > > either it is sparsely checked out or not. You can even have
> > > > multiple indices (switching between them by setting
> > > > GIT_INDEX_FILE) which have different prefixes.
> > >
> > > I don't think so. It's a mask for workdir, right? If you save it it
> > > index, you can switch index and the prefix as well, but workdir
> > > only has several subtrees that do not fit any other prefix than the
> > > original prefix.
> >
> >
> > Ah, you adroitly avoided addressing the issue that the user can change
> > the prefix without the index ever noticing.
>
> Forgive my ignorance. I still do not get why index must notice prefix
> change? The only reason I can think of is that we must make sure there
> won't be any user-modification in index outside the prefix. But that can
> be guarded from higher level (plumbings and porcelains) because index is
> allowed to have modification outside sparse prefix (auto-merged
> entries).
Why do you want to guard it from the outside? When the obvious fix is to
put together what belongs together?
Hth,
Dscho
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 13:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807241340490.8986@racer>
Hi,
On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > No, I did mean the index. This is an attribute of the index: either
> > > it is sparsely checked out or not. You can even have multiple indices
> > > (switching between them by setting GIT_INDEX_FILE) which have
> > > different prefixes.
> >
> > I don't think so. It's a mask for workdir, right? If you save it it
> > index, you can switch index and the prefix as well, but workdir only has
> > several subtrees that do not fit any other prefix than the original
> > prefix.
>
>
> Ah, you adroitly avoided addressing the issue that the user can change the
> prefix without the index ever noticing.
Forgive my ignorance. I still do not get why index must notice prefix
change? The only reason I can think of is that we must make sure there
won't be any user-modification in index outside the prefix. But that
can be guarded from higher level (plumbings and porcelains) because
index is allowed to have modification outside sparse prefix
(auto-merged entries).
--
Duy
^ permalink raw reply
* [PATCH] git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
From: Abhijit Menon-Sen @ 2008-07-24 13:28 UTC (permalink / raw)
To: Murphy, John; +Cc: git
In-Reply-To: <80915B5E107BED488500050294C6F48712136B@ex2k.bankofamerica.com>
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
At 2008-07-24 09:01:48 -0400, john.murphy@bankofamerica.com wrote:
>
> I presume this was just an oversight when git- commands were removed
> from the bin directory.
Looks like it. The following patch fixes it for me. Does it work for
you on Windows?
-- ams
git-gui/git-gui.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 940677c..a70fa67 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -1670,10 +1670,10 @@ proc do_gitk {revs} {
# -- Always start gitk through whatever we were loaded with. This
# lets us bypass using shell process on Windows systems.
#
- set exe [file join [file dirname $::_git] gitk]
+ set exe [_which gitk]
set cmd [list [info nameofexecutable] $exe]
- if {! [file exists $exe]} {
- error_popup [mc "Unable to start gitk:\n\n%s does not exist" $exe]
+ if {$exe eq {}} {
+ error_popup [mc "Couldn't find gitk in PATH"]
} else {
global env
--
1.5.6.GIT
^ permalink raw reply related
* Git Gui bug calling gitk
From: Murphy, John @ 2008-07-24 13:01 UTC (permalink / raw)
To: git
I have recently installed git: v1.5.6.1-167-gbf270ab and git gui:
gitgui-0.10.2-8-g2add5cb
>From Git Gui we try to run Visualize Branch History and get the
following error:
Unable to start gitk:
c:/cygwin/usr/local/git/libexec/git-core/gitk does not exist
I presume this was just an oversight when git- commands were removed
from the bin directory.
-John Murphy
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Olivier Marin @ 2008-07-24 12:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Nanako Shiraishi, Johannes Schindelin,
René Scharfe, Stephan Beyer, Joe Fiorini, git, Jari Aalto
In-Reply-To: <7v1w1ke9k5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano a écrit :
> Olivier Marin <dkr+ml.git@free.fr> writes:
>
>> Junio C Hamano a écrit :
>>>> diff --git a/git-am.sh b/git-am.sh
>>> ...
>>>> @@ -202,8 +202,15 @@ then
>>> ...
>>>> + case "$skip,$abort" in
>>>> + t,)
>>>> + git rerere clear
>>>> + git read-tree --reset -u HEAD HEAD
>>>> + orig_head=$(cat "$GIT_DIR/ORIG_HEAD")
>>>> + git reset HEAD
>>>> + git update-ref ORIG_HEAD $orig_head
>>>> + ;;
>>> ...
>> I add reset to unstage paths with no conflict that are left behind.
>
> Does removing the last three lines (1) change the behaviour? (2) break any test?
>
> If the answers are "Yes and No", we would need a few more tests in the
> testsuite.
The answers are "Yes and No" and test case update follow.
-- >8 --
From: Olivier Marin <dkr@freesurf.fr>
[PATCH] update test case to protect am --skip behaviour
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
---
t/t4151-am-abort.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh
index f45ab0a..7d86cdf 100755
--- a/t/t4151-am-abort.sh
+++ b/t/t4151-am-abort.sh
@@ -17,6 +17,8 @@ test_expect_success setup '
for i in 2 3 4 5 6
do
echo $i >>file-1 &&
+ echo $i >otherfile-$i &&
+ git add otherfile-$i &&
test_tick &&
git commit -a -m $i || break
done &&
--
1.6.0.rc0.44.gd618.dirty
^ permalink raw reply related
* Re: [RFC PATCH 00/12] Sparse checkout
From: Johannes Schindelin @ 2008-07-24 12:42 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0807240127p5226822atcd4a0711f1bc9c5c@mail.gmail.com>
Hi,
On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> >
> > > On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > > And with core.sparseCheckout you are at the whim of the user,
> > > > since .git/config is _supposed_ to be user-editable.
> > >
> > > Well, whatever place. I chose .git/config because I did not want to
> > > introduce a new config place. But then how about
> > > .git/sparsecheckout?
> >
> > No, I did mean the index. This is an attribute of the index: either
> > it is sparsely checked out or not. You can even have multiple indices
> > (switching between them by setting GIT_INDEX_FILE) which have
> > different prefixes.
>
> I don't think so. It's a mask for workdir, right? If you save it it
> index, you can switch index and the prefix as well, but workdir only has
> several subtrees that do not fit any other prefix than the original
> prefix.
Ah, you adroitly avoided addressing the issue that the user can change the
prefix without the index ever noticing.
Well, in any case, if you do not agree that the prefix is really an
attribute of the index, then there is nothing else I have to say on this
series.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Preserve cwd in setup_git_directory()
From: Nguyen Thai Ngoc Duy @ 2008-07-24 12:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Geoff Russell
In-Reply-To: <alpine.DEB.1.00.0807241324040.8986@racer>
On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> 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().
--
Duy
^ 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