* Re: [3/4] What's not in 1.5.2 (new topics)
From: Josef Weidendorfer @ 2007-05-18 9:18 UTC (permalink / raw)
To: Petr Baudis
Cc: Steven Grimm, Michael S. Tsirkin, Junio C Hamano, Andy Parkins,
git, Nicolas Pitre
In-Reply-To: <20070518045025.GT4489@pasky.or.cz>
On Friday 18 May 2007, Petr Baudis wrote:
> The problem is ugly too, though - suddenly, you have created a SINGLE
> UNIVERSE-WIDE NAMESPACE INSIDE A DISTRIBUTED VCS. And that's not going
> to work well.
Actually, tags are already such a namespace. If you want to merge
two projects which have the same tag names, of course you still
preserve the different tag objects, but only one will appear in the
refs/tags namespace.
So what is the best identifier for a subprobject? It is one that
probably never clashes with any subproject identifier of another
superproject. At least, it should not clash between any superprojects
which ever could be a candidate for merging the two into one.
Junios proposal using an URL as identifier actually is quite good in
this regard, similar to JAVA package names.
However, I wonder whether the possible merge of two superprojects
into one is a real issue. When they use the same subprojects identifiers,
there is a workaround: instead of merging, make one superproject the
subproject of the other.
Josef
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Andy Parkins @ 2007-05-18 9:21 UTC (permalink / raw)
To: git; +Cc: Josef Weidendorfer, Michael S. Tsirkin, Junio C Hamano,
Nicolas Pitre
In-Reply-To: <200705181043.09203.Josef.Weidendorfer@gmx.de>
On Friday 2007 May 18, Josef Weidendorfer wrote:
> It all depends on how we construct the default URL out of the subproject
> identifier. Options:
> (1) do not try to construct a default URL at all. Error out without a
> config (2) use a configurable rewriting scheme like s/(.*)/git://host/\1/
> (3) automatically detect a senseful rewriting scheme
>
> Let's start with (1). We can invent convenient default schemes later on.
All good; except let's start with
(1) if no config, try using the key itself - error out if that fails
Then everybody is happy - if you want to use your system where the key is not
a URL, then don't - you'll get the error you want. If the user chose to use
a URL then magic will happen.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Andy Parkins @ 2007-05-18 9:40 UTC (permalink / raw)
To: git, Michael S. Tsirkin; +Cc: Josef Weidendorfer, Junio C Hamano, Nicolas Pitre
In-Reply-To: <20070518085708.GC4708@mellanox.co.il>
On Friday 2007 May 18, Michael S. Tsirkin wrote:
> > I think that's the wrong solution. A change of source URL for a
> > submodule from what upstream uses to your own server is a _fork_ from
> > upstream, therefore you would fork your own branch in your supermodule
> > and alter .gitmodules to point at your server. Everybody is happy, and
> > the fork is recorded.
>
> Why should I record it? If the content is the same, the commit name should
> be the same, it shouldn't matter where did the content came from.
Because you have changed something that the upstream repository supplied with
no way of detecting it. It's the same as if upstream supplied
important_login_function.c and then you clone it; if your clone had a way of
changing important_login_function.c to add a backdoor and passing that to
people who clone from you without changing the commit hash that would be bad.
Submodules is the same; upstream might say
kernel git://git.kernel.org/kernel-2.6.git
Then you clone it and use the override system to override that to
kernel git://git.dodgykernel.org/backdoors.git
without having to change the repository.
The server should not be allowed to override the url that the client sees.
Only the client should make that decision.
> I wouldn't be happy: I have just cloned both project and superproject,
> but to re-publish the superproject using my clone of subproject, I have
> to create a new commit, which would have a different hash from the origin.
> So how do people know they can trust my tree?
That problem exists regardless of the method of changing URL - in your method
though the change is entirely unrecorded because you've changed something
that upstream supplied in an out-of-band manner.
> And what happens when the original super-project pulls from me -
> it seems that his .gitmodules will now point to my server?
Now that one is a good defence. Okay; I accept that changing .gitmodules
won't work. However, I don't accept that the server should be allowed to
supply overrides to the client. Another method is needed.
> > The override system is only there for the local repository (which always
> > takes precedence) not for the server provider to hide detail from those
> > checking the repo out.
>
> I really like it that currently, in git, there is no difference between a
> public and local repository. If the override system is only for the local
Of course there is a difference. .git/config is different; .git/refs is
different; .git/info/exclude is different; etc. These are all per-repository
settings - and there is no way for a server to force it's version of those
files on a client.
> So I have have cloned the supermodule and the submodule to my laptop -
> it's enough to edit .git/config and I can use the history locally - that's
> good. But now I try to clone the local tree - and a clone will try to go
> out to the URL which I cloned - bad.
Yep. That is the problem. In the end the only practical solution might be to
allow the server to supply part of the .git/config (which is essentially what
your suggestion would do); but I think that that is a big step to take and
has potential to be abused.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* autocrlf
From: Andy Parkins @ 2007-05-18 10:11 UTC (permalink / raw)
To: Git Mailing List
Hello,
I've just been playing with gitattributes and was trying the crlf attribute.
The behaviour of this and/or core.autocrlf is not as I was expecting.
What I had imagined was that I could use .gitattributes to tell git which
files in my tree were text. Then the line endings on checkout would be set
as appropriate to my platform, and on check in set to LF.
What actually happens is that any file with the crlf attribute is being
checked out with LF expanded to CRLF (I'm running Linux of course), which is
completely not what I wanted.
I've looked at convert.c:crlf_to_worktree(), and it seems that that is exactly
what is programmed:
dst = buffer;
do {
unsigned char c = *src++;
if (c == '\n' && last != '\r')
*dst++ = '\r';
*dst++ = c;
last = c;
} while (--size);
This seems completely crazy. What is automatic about that? I had imagined
the point of the crlf flag was to make it possible for windows users and
linux users to work on the same project, each using their native line endings
locally. Have I misunderstood? Am I doing something wrong?
How would you set up a repository so that checking it out on Linux results in
LF endings, and on Windows it results in CRLF endings?
This also makes me think that the crlf attribute is wrong; what I really want
to say in .gitattributes is something like
# Check out text to platform-dependent endings
*.txt lineending=native
# Check out svg to LF endings
*.svg lineending=lf
# Check out Z80 assembly files to CRLF
*.mac lineending=crlf
# Check out png untouched
*.png lineending=binary
With the default for the lineending attribute being "binary".
Then in .git/config I would have "core.nativelineending = crlf"; with the
default being to use the ending appropriate to the platform.
I'll write patches for this, but I wanted to make sure I haven't completely
gotten the wrong end of the stick before I do.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Johannes Sixt @ 2007-05-18 10:16 UTC (permalink / raw)
To: git
In-Reply-To: <200705181040.37648.andyparkins@gmail.com>
Andy Parkins wrote:
> On Friday 2007 May 18, Michael S. Tsirkin wrote:
> > I wouldn't be happy: I have just cloned both project and superproject,
> > but to re-publish the superproject using my clone of subproject, I have
> > to create a new commit, which would have a different hash from the origin.
> > So how do people know they can trust my tree?
>
> That problem exists regardless of the method of changing URL - in your method
> though the change is entirely unrecorded because you've changed something
> that upstream supplied in an out-of-band manner.
And it doesn't matter: Once you trust the superproject with its
.gitmodules (versioned or not), the trust is based on the SHA1 of the
gitlink entry. Where the so named subproject commit came from is
secondary.
-- Hannes
^ permalink raw reply
* Re: git-rebase (1.5.0.6) errors
From: Paolo Teti @ 2007-05-18 10:31 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705181130570.28356@kivilampi-30.cs.helsinki.fi>
2007/5/18, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>:
> Hi,
>
>
> ijjarvin@kivilampi-30:~/work/src/submit$ git-rebase net-2.6.22-origin
> First, rewinding head to replay your work on top of it...
> HEAD is now at d739437... [IPV4]: Correct rp_filter help text.
> fatal: cannot convert from utf-8 to utf-8
Now I can't test or try to reproduce your error,
but looking at the source code (only with gitweb)
I have found another bad use of size_t instead of ssize_t
in the reencode_string(..) that take part at the conversion process.
Using size_t in the next portion of code the check "count == -1" is never true.
while (1) {
size_t cnt = iconv(conv, &cp, &insz, &outpos, &outsz);
if (cnt == -1) {
size_t sofar;
if (errno != E2BIG) {
free(out);
iconv_close(conv);
return NULL;
}
Please someone could fixes this bad use of size_t?..
Sorry, but now I can't install/use git because I'm on a customer workstation..
^ permalink raw reply
* Re: autocrlf
From: Raimund Bauer @ 2007-05-18 10:34 UTC (permalink / raw)
To: Andy Parkins; +Cc: Git Mailing List
In-Reply-To: <200705181111.53823.andyparkins@gmail.com>
On Fri, 2007-05-18 at 11:11 +0100, Andy Parkins wrote:
> Hello,
>
> I've just been playing with gitattributes and was trying the crlf attribute.
> The behaviour of this and/or core.autocrlf is not as I was expecting.
>
> What I had imagined was that I could use .gitattributes to tell git which
> files in my tree were text. Then the line endings on checkout would be set
> as appropriate to my platform, and on check in set to LF.
>
> What actually happens is that any file with the crlf attribute is being
> checked out with LF expanded to CRLF (I'm running Linux of course), which is
> completely not what I wanted.
you need to set core.autoCrlf=input
I had the same problem some time ago ...
> Andy
--
best regards
Ray
^ permalink raw reply
* Re: git-rebase (1.5.0.6) errors
From: David Kastrup @ 2007-05-18 10:49 UTC (permalink / raw)
To: git
In-Reply-To: <34a7ae040705180331x1a86782fh3b2c6a87db32030e@mail.gmail.com>
"Paolo Teti" <paolo.teti@gmail.com> writes:
> 2007/5/18, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>:
>> Hi,
>>
>>
>> ijjarvin@kivilampi-30:~/work/src/submit$ git-rebase net-2.6.22-origin
>> First, rewinding head to replay your work on top of it...
>> HEAD is now at d739437... [IPV4]: Correct rp_filter help text.
>> fatal: cannot convert from utf-8 to utf-8
>
>
> Now I can't test or try to reproduce your error,
> but looking at the source code (only with gitweb)
> I have found another bad use of size_t instead of ssize_t
> in the reencode_string(..) that take part at the conversion process.
>
> Using size_t in the next portion of code the check "count == -1" is
> never true.
Only if size_t is a larger type than int (could be on x86-64 and alpha
architectures). Other than that, this comparison would work. Which
does not mean that this does not warrant fixing, but it is not
necessarily the cause of this problem.
>
> while (1) {
> size_t cnt = iconv(conv, &cp, &insz, &outpos, &outsz);
>
> if (cnt == -1) {
> size_t sofar;
> if (errno != E2BIG) {
> free(out);
> iconv_close(conv);
> return NULL;
> }
>
>
> Please someone could fixes this bad use of size_t?..
--
David Kastrup
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Michael S. Tsirkin @ 2007-05-18 11:08 UTC (permalink / raw)
To: Andy Parkins
Cc: git, Josef Weidendorfer, Michael S. Tsirkin, Junio C Hamano,
Nicolas Pitre
In-Reply-To: <200705181021.30062.andyparkins@gmail.com>
> Quoting Andy Parkins <andyparkins@gmail.com>:
> Subject: Re: [3/4] What's not in 1.5.2 (new topics)
>
> On Friday 2007 May 18, Josef Weidendorfer wrote:
>
> > It all depends on how we construct the default URL out of the subproject
> > identifier. Options:
> > (1) do not try to construct a default URL at all. Error out without a
> > config (2) use a configurable rewriting scheme like s/(.*)/git://host/\1/
> > (3) automatically detect a senseful rewriting scheme
> >
> > Let's start with (1). We can invent convenient default schemes later on.
>
> All good; except let's start with
>
> (1) if no config, try using the key itself - error out if that fails
>
> Then everybody is happy - if you want to use your system where the key is not
> a URL, then don't - you'll get the error you want. If the user chose to use
> a URL then magic will happen.
I don't want an error. No one wants an error.
I want to be able to clone a super project, a subproject,
and use my copy of both instead of the original - including
cloning my copy, pulls between such clones, being able to verify
that they are identical.
What I *don't* want is a situation where the fact that original repository
resides in north america necessarily means that everyone who looks at *my* clone
of it will do a round trip to north america too.
And this means that URLs must be out of tree, but does *not* mean that
git-daemon should not serve them for user's convenience.
How about an ability for git-daemon to get commands with git-config?
--
MST
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Michael S. Tsirkin @ 2007-05-18 11:22 UTC (permalink / raw)
To: Andy Parkins
Cc: git, Michael S. Tsirkin, Josef Weidendorfer, Junio C Hamano,
Nicolas Pitre
In-Reply-To: <200705181040.37648.andyparkins@gmail.com>
> The server should not be allowed to override the url that the client sees.
> Only the client should make that decision.
Why is that? Content is what is important. URLs are only a convenience measure
to help clients find the content. The link must have a commit hash, so git can
*verify* that the content is correct. Where it comes from must be irrelevant.
So if someone looks at my tree, and does not know where to get the content, he
might want my hint on this.
--
MST
^ permalink raw reply
* Re: git-rebase (1.5.0.6) errors
From: Paolo Teti @ 2007-05-18 11:29 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86y7jmmmnq.fsf@lola.quinscape.zz>
2007/5/18, David Kastrup <dak@gnu.org>:
> "Paolo Teti" <paolo.teti@gmail.com> writes:
>
> > 2007/5/18, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>:
> >> Hi,
> >>
> >>
> >> ijjarvin@kivilampi-30:~/work/src/submit$ git-rebase net-2.6.22-origin
> >> First, rewinding head to replay your work on top of it...
> >> HEAD is now at d739437... [IPV4]: Correct rp_filter help text.
> >> fatal: cannot convert from utf-8 to utf-8
> >
> >
> > Now I can't test or try to reproduce your error,
> > but looking at the source code (only with gitweb)
> > I have found another bad use of size_t instead of ssize_t
> > in the reencode_string(..) that take part at the conversion process.
> >
> > Using size_t in the next portion of code the check "count == -1" is
> > never true.
>
> Only if size_t is a larger type than int (could be on x86-64 and alpha
> architectures). Other than that, this comparison would work. Which
> does not mean that this does not warrant fixing, but it is not
> necessarily the cause of this problem.
1. Yes this is not necessarily the cause.. I agree.
2. size_t as I know is unsigned and ssize_t is the signed version of
size_t.. so to
compare with -1 we want ssize_t.
^ permalink raw reply
* Re: autocrlf
From: Johannes Sixt @ 2007-05-18 11:45 UTC (permalink / raw)
To: git
In-Reply-To: <200705181111.53823.andyparkins@gmail.com>
Andy Parkins wrote:
> What I had imagined was that I could use .gitattributes to tell git which
> files in my tree were text. Then the line endings on checkout would be set
> as appropriate to my platform, and on check in set to LF.
>
> What actually happens is that any file with the crlf attribute is being
> checked out with LF expanded to CRLF (I'm running Linux of course), which is
> completely not what I wanted.
If I understand the documentation correctly
(Documentation/gitattributes.txt) then you set core.autocrlf to true on
Windows and false everywhere else, and things should start working like
you imagined.
I have not checked whether the behavior is according to the
documentation, though.
-- Hannes
^ permalink raw reply
* Re: [PATCH] gitweb: Add support for grep searches
From: Jakub Narebski @ 2007-05-18 11:58 UTC (permalink / raw)
To: git
In-Reply-To: <20070517023112.21056.62390.stgit@rover>
[Cc: Petr Baudis <pasky@suse.cz>, Junio C Hamano <junkio@cox.net>,
git@vger.kernel.org]
Petr Baudis wrote:
> The 'grep' type of search greps the currently selected tree for given
> regexp and shows the results in a fancy table with links into blob view.
> The number of shown matches is limited to 1000 and the whole feature
> can be turned off (grepping linux-2.6.git already makes repo.or.cz a bit
> unhappy).
Ack, FWIW.
By the way, I wonder if we should make search context (view) sensitive.
For example for 'history' view search would be limited to given pathspec,
grep search in a 'tree' view would search given tree only.
Additionally it would be nice to have links from search results page to
have search match highlighted, like search results on GitWiki.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: autocrlf
From: Andy Parkins @ 2007-05-18 12:01 UTC (permalink / raw)
To: git; +Cc: Raimund Bauer
In-Reply-To: <1179484482.6453.19.camel@localhost>
On Friday 2007 May 18, Raimund Bauer wrote:
> you need to set core.autoCrlf=input
>
> I had the same problem some time ago ...
The documentation says:
core.autocrlf::
If true, makes git convert `CRLF` at the end of lines in text files to
`LF` when reading from the filesystem, and convert in reverse when
writing to the filesystem. The variable can be set to
'input', in which case the conversion happens only while
reading from the filesystem but files are written out with
`LF` at the end of lines. Currently, which paths to consider
"text" (i.e. be subjected to the autocrlf mechanism) is
decided purely based on the contents.
That is: "input" ensures that CRLF is stripped on input to the repository.
While that is fine in some circumstances, the situation I'm describing here
is what happens on output from the repository.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Jakub Narebski @ 2007-05-18 12:00 UTC (permalink / raw)
To: git
In-Reply-To: <20070518045025.GT4489@pasky.or.cz>
[Cc: Petr Baudis <pasky@suse.cz>, Josef Weidendorfer
<Josef.Weidendorfer@gmx.de>, "Michael S. Tsirkin" <mst@dev.mellanox.co.il>,
Junio C Hamano <junkio@cox.net>, Andy Parkins <andyparkins@gmail.com>,
Nicolas Pitre <nico@cam.org>, git@vger.kernel.org]
Petr Baudis wrote:
> On Fri, May 18, 2007 at 02:32:53AM CEST, Steven Grimm wrote:
>> For example -- and yes, this is partially a rehash of other people's
>> ideas -- instead of mapping a subproject path directly to revision@URL,
>> instead map it to revision@symbolic name. The symbolic name is then
>> separately mapped to a URL, and it's that symbolic name that can be
>> locally overridden. The mappings of symbolic names to URLs is
>> unversioned; the mapping of subprojects to revision@symbolic is
>> versioned. Local overrides happen at the symbolic->URL mapping.
>>
>> So you'd have something like
>>
>> version 1: kernel-src/ -> kernel24
>> version 2: kernel-src/ -> kernel26
>> unversioned:
>> kernel24 -> git://whatever/2.4
>> kernel26 -> git://whatever/2.6
>>
>> And then locally, the override is:
>>
>> kernel24 -> git://myhost/2.4
>
> Yes, this would be nice; in one of my first mails in this thread I
> devoted a non-trivially large writeup to this, then proceeded to remove
> it since this has a serious problem.
>
> Actually, Git already has a nice mechanism to handle these unversionaed
> pointers - tags. Just make refs/tags/subproject/kernel24 containing the
> URL to fetch. It's even easily overridable locally (and not easily
> overridable remotely...).
>
> The problem is ugly too, though - suddenly, you have created a SINGLE
> UNIVERSE-WIDE NAMESPACE INSIDE A DISTRIBUTED VCS. And that's not going
> to work well. I think I don't have to elaborate too much - the
> aforementioned FreeBSD people will have different ideas about kernels
> than you, _you_ will have different idea about kernels in few tens of
> years than now, then if you need to merge or probably even fetch, you
> will get into big trouble.
>
> Notice that we don't have any such namespace right now (except the
> D(SHA1) namespace, which is however possible only because it's so huge
> _and_ the names are assigned automagically in a way that virtually
> guarantees uniqueness across the whole universe) - tags come closest,
> but there is nothing that fundamentally breaks when a clash happens
> inside the namespace - it's just UI thing. But subproject names are
> etched to the history - once you name it, you just can't get rid of it
> forever.
There is a bit ugly solution for this: instead of using symbolic name
in versioned .gitmodules for a subproject (for a repo), use subproject
identifier (inode), and put it in the tag object (or config) together with
the URL. Git would then search all the subproject / submodule info for
a given inode. You could have more than one inode / identifier name for
a subproject repo; this would avoid the "independently created" issue
with using inodes / file-ids in distributed SCM. One would have to
ensure however that different subprojects get assigned different inodes.
This is yet another level of indirection, and needs searching all the
subprojects info; but I don't think that there would be that many
subprojects used.
Besides we make use of one such global namespace: version tags (although
they _could_ have different names, e.g. v0.6.0 and gitgui-0.6.0).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Josef Weidendorfer @ 2007-05-18 12:27 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Andy Parkins, git, Junio C Hamano, Nicolas Pitre
In-Reply-To: <20070518110804.GD4708@mellanox.co.il>
On Friday 18 May 2007, Michael S. Tsirkin wrote:
> > Quoting Andy Parkins <andyparkins@gmail.com>:
> > Subject: Re: [3/4] What's not in 1.5.2 (new topics)
> >
> > On Friday 2007 May 18, Josef Weidendorfer wrote:
> >
> > > It all depends on how we construct the default URL out of the subproject
> > > identifier. Options:
> > > (1) do not try to construct a default URL at all. Error out without a
> > > config (2) use a configurable rewriting scheme like s/(.*)/git://host/\1/
> > > (3) automatically detect a senseful rewriting scheme
> > >
> > > Let's start with (1). We can invent convenient default schemes later on.
> >
> > All good; except let's start with
> >
> > (1) if no config, try using the key itself - error out if that fails
> >
> > Then everybody is happy - if you want to use your system where the key is not
> > a URL, then don't - you'll get the error you want. If the user chose to use
> > a URL then magic will happen.
>
> I don't want an error. No one wants an error.
Heh.
Of course, a git-clone should come up with a URL in the local config
such that subproject clones can happen without any an error.
The error would potentially happen after cloning if no config entry
for the URL can be found, e.g. when you decided at clone time to not
fetch any subprojects, but do that later.
> I want to be able to clone a super project, a subproject,
> and use my copy of both instead of the original - including
> cloning my copy, pulls between such clones, being able to verify
> that they are identical.
What about using user-global git configuration for this *before*
git-clone of the superprojects happens?
Lets say you have a clone of the linux-2.6 repository at ~/gitrepo/linux26,
and you want to clone a superproject which includes linux-2.6 as subproject,
using "linux26" (or perhaps "git://git.kernel.org/pub/linux-2.6.git") as
subproject identifier.
Before cloning this superproject, you should be able to set up in ~/.gitconfig
[project "linux26"]
localurl = ~/gitrepo/linux26
and the clone of the superproject should be able to use this repository as
subproject repository.
> What I *don't* want is a situation where the fact that original repository
> resides in north america necessarily means that everyone who looks at *my* clone
> of it will do a round trip to north america too.
Someone which clones from you probably does not have access to "~/gitrepo/linux26",
so you have to provide a public visible URL either way, like
[project "linux26"]
localurl = ~/gitrepo/linux26
url = git://myhost/mylinux26.git
and the "url" should be configured at the remote side at clone time.
Josef
^ permalink raw reply
* Re: autocrlf
From: Andy Parkins @ 2007-05-18 12:32 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
In-Reply-To: <464D91E7.FB3F9B4@eudaptics.com>
On Friday 2007 May 18, Johannes Sixt wrote:
> > What actually happens is that any file with the crlf attribute is being
> > checked out with LF expanded to CRLF (I'm running Linux of course), which
> > is completely not what I wanted.
>
> If I understand the documentation correctly
> (Documentation/gitattributes.txt) then you set core.autocrlf to true on
> Windows and false everywhere else, and things should start working like
> you imagined.
Presumably then it is defaulting to false for Linux as everything is working
fine for me at present. However, that is not the case when I set the crlf
attribute.
Documentation/gitattributes.txt:
This attribute controls the line-ending convention.
Set::
Setting the `crlf` attribute on a path is meant to mark
the path as a "text" file. 'core.autocrlf' conversion
takes place without guessing the content type by
inspection.
I read that as meaning the automatic detection of file type is overridden by
the crlf attribute. What I'm actually seeing is that it has the same effect
as enabling "autocrlf = true" for that file. As you say "autocrlf = true" is
for windows, the crlf attribute should not be forcing it on as that then
applies to all platforms.
I think this is a bug. The code agrees with the observed behaviour but not
with the documentation. Patch to follow.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* [PATCH] Fix crlf attribute handling to match documentation
From: Andy Parkins @ 2007-05-18 12:33 UTC (permalink / raw)
To: git
gitattributes.txt says, of the crlf attribute:
Set::
Setting the `crlf` attribute on a path is meant to mark
the path as a "text" file. 'core.autocrlf' conversion
takes place without guessing the content type by
inspection.
That is to say that the crlf attribute does not force the file to have
CRLF line endings, instead it removes the autocrlf guesswork and forces
the file to be treated as text. Then, whatever line ending is defined
by the autocrlf setting is applied.
However, that is not what convert.c was doing. The conversion to CRLF
was being skipped in crlf_to_worktree() when the following condition was
true:
action == CRLF_GUESS && auto_crlf <= 0
That is to say conversion took place when not in guess mode (crlf attribute
not specified) or core.autocrlf set to true. This was wrong. It meant
that the crlf attribute being on for a given file _forced_ CRLF
conversion, when actually it should force the file to be treated as
text, and converted accordingly. The real test should simply be
auto_crlf <= 0
That is to say, if core.autocrlf is falsei (or input), conversion from
LF to CRLF is never done. When core.autocrlf is true, conversion from
LF to CRLF is done only when in CRLF_GUESS (and the guess is "text"), or
CRLF_TEXT mode.
Similarly for crlf_to_worktree(), if core.autocrlf is false, no conversion
should _ever_ take place. In reality it was only not taking place if
core.autocrlf was false _and_ the crlf attribute was unspecified.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
convert.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/convert.c b/convert.c
index 12abdaf..86d8167 100644
--- a/convert.c
+++ b/convert.c
@@ -86,7 +86,7 @@ static char *crlf_to_git(const char *path, const char *src, unsigned long *sizep
unsigned long size, nsize;
struct text_stat stats;
- if ((action == CRLF_BINARY) || (action == CRLF_GUESS && !auto_crlf))
+ if ((action == CRLF_BINARY) || !auto_crlf)
return NULL;
size = *sizep;
@@ -154,7 +154,7 @@ static char *crlf_to_worktree(const char *path, const char *src, unsigned long *
unsigned char last;
if ((action == CRLF_BINARY) || (action == CRLF_INPUT) ||
- (action == CRLF_GUESS && auto_crlf <= 0))
+ auto_crlf <= 0)
return NULL;
size = *sizep;
--
1.5.2.rc3.51.gd07bc
^ permalink raw reply related
* Re: [PATCH] gitweb: Add support for grep searches
From: Petr Baudis @ 2007-05-18 12:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f2k4d5$879$1@sea.gmane.org>
On Fri, May 18, 2007 at 01:58:28PM CEST, Jakub Narebski wrote:
> [Cc: Petr Baudis <pasky@suse.cz>, Junio C Hamano <junkio@cox.net>,
> git@vger.kernel.org]
Your MUA seems to have finally decided to go completely crazy or
something. :-) Different mails go to us and the list.
> Petr Baudis wrote:
>
> > The 'grep' type of search greps the currently selected tree for given
> > regexp and shows the results in a fancy table with links into blob view.
> > The number of shown matches is limited to 1000 and the whole feature
> > can be turned off (grepping linux-2.6.git already makes repo.or.cz a bit
> > unhappy).
>
> Ack, FWIW.
I want to implement the regexp checkbox.
> By the way, I wonder if we should make search context (view) sensitive.
> For example for 'history' view search would be limited to given pathspec,
> grep search in a 'tree' view would search given tree only.
I think it would be nice (if it's clearly visible that the results are
filtered), but I'm probably not the one who is going to implement this.
;-)
> Additionally it would be nice to have links from search results page to
> have search match highlighted, like search results on GitWiki.
I'm sorry, I don't understand.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Andy Parkins @ 2007-05-18 12:36 UTC (permalink / raw)
To: git, Michael S. Tsirkin; +Cc: Josef Weidendorfer, Junio C Hamano, Nicolas Pitre
In-Reply-To: <20070518112202.GE4708@mellanox.co.il>
On Friday 2007 May 18, Michael S. Tsirkin wrote:
> Why is that? Content is what is important. URLs are only a convenience
> measure to help clients find the content. The link must have a commit
> hash, so git can *verify* that the content is correct. Where it comes from
> must be irrelevant.
>
> So if someone looks at my tree, and does not know where to get the content,
> he might want my hint on this.
True. Hannes also pointed out that the trust comes from the hash contained in
the gitlink that is in tree, there is no need to assign trust to the URL.
I withdraw my objection.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Petr Baudis @ 2007-05-18 12:41 UTC (permalink / raw)
To: Jakub Narebski
Cc: Josef Weidendorfer, Michael S. Tsirkin, Junio C Hamano,
Andy Parkins, Nicolas Pitre, git
In-Reply-To: <f2k4g6$879$2@sea.gmane.org>
On Fri, May 18, 2007 at 02:00:07PM CEST, Jakub Narebski wrote:
> There is a bit ugly solution for this: instead of using symbolic name
> in versioned .gitmodules for a subproject (for a repo), use subproject
> identifier (inode), and put it in the tag object (or config) together with
> the URL. Git would then search all the subproject / submodule info for
> a given inode. You could have more than one inode / identifier name for
> a subproject repo; this would avoid the "independently created" issue
> with using inodes / file-ids in distributed SCM. One would have to
> ensure however that different subprojects get assigned different inodes.
Well, then it doesn't make any difference, no? You just renamed the
problem but it stays the same - to ensure uniqueness even across
repositories.
Ok, you can declare now that you will just think out a UUID for the
subproject, but aside of not fitting well with the whole git philosophy,
then you don't need the indirection again, just use the UUID as the tag
name.
I have the feeling that I'm missing something basic in your proposal...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Jeff King @ 2007-05-18 12:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Alex Riesen, Andy Parkins, git
In-Reply-To: <7vzm438evr.fsf@assigned-by-dhcp.cox.net>
On Thu, May 17, 2007 at 11:49:12AM -0700, Junio C Hamano wrote:
> > Instead, why not:
> > 1. url location is supplied in configuration as
> > [subproject "kernel/"]
> > url = git://git.kernel.org/pub/linux-2.4.git
> > 2. .gitmodules is simply read as a lower-priority version of
> > configuration
>
> That does not support seeking back and forth between appliance
> release #1 and release #2 which wants to say they want to bind
> two different things at the same kernel/ path, does it?
I had a vague notion that the subproject could hold _both_ of them,
since it's really the commits you're flipping between. But obviously
that has quite complex semantics, so now it's me doing the handwaving.
What is the planned behavior when doing such a switch? I.e., if I have
kernel/ bound to linux-2.6, and I do a 'git-checkout' back in time to a
version that wants linux-2.4 bound at kernel/, what will happen? Blowing
away my subproject repo doesn't seem right.
-Peff
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Michael S. Tsirkin @ 2007-05-18 12:46 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Michael S. Tsirkin, Andy Parkins, git, Junio C Hamano,
Nicolas Pitre
In-Reply-To: <200705181427.03598.Josef.Weidendorfer@gmx.de>
> > What I *don't* want is a situation where the fact that original repository
> > resides in north america necessarily means that everyone who looks at *my* clone
> > of it will do a round trip to north america too.
>
> Someone which clones from you probably does not have access to "~/gitrepo/linux26",
> so you have to provide a public visible URL either way, like
>
> [project "linux26"]
> localurl = ~/gitrepo/linux26
> url = git://myhost/mylinux26.git
>
> and the "url" should be configured at the remote side at clone time.
Right. In other words, urls for each project are unversioned file, and git-daemon
needs to be taught to serve them up (I think it already serves head names, which are
unversioned too). Actually, can't something like what we do for remotes head
names work here as well?
--
MST
^ permalink raw reply
* Re: Documentation (mainly user-manual) patches
From: J. Bruce Fields @ 2007-05-18 13:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20070518045634.GU4489@pasky.or.cz>
On Fri, May 18, 2007 at 06:56:35AM +0200, Petr Baudis wrote:
> BTW, there is this nice git-request-pull tool which will prepare this
> mail for you and additionally include the list of commits included in
> that repository, which is somewhat more friendly to the readers (I
> myself wondered). ;-)
OK! I'll start including the shortlog. Appended, if anyone's still
curious about this one.--b.
J. Bruce Fields (10):
user-manual: revise birdseye-view chapter
glossary: expand and clarify some definitions, prune cross-references
user-manual: move quick-start to an appendix
Documentation: remove howto's now incorporated into manual
user-manual: move howto/make-dist.txt into user manual
user-manual: move howto/using-topic-branches into manual
user-manual: add a "counting commits" example
user-manual: introduce git
user-manual: listing commits reachable from some refs not others
user-manual: reorganize public git repo discussion
Johannes Schindelin (1):
Add a birdview-on-the-source-code section to the user manual
^ permalink raw reply
* [PATCH] Documentation: Added [verse] to SYNOPSIS where necessary
From: Matthias Kestenholz @ 2007-05-18 13:39 UTC (permalink / raw)
To: junkio; +Cc: git, Matthias Kestenholz
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
---
Documentation/git-archive.txt | 1 +
Documentation/git-bundle.txt | 1 +
Documentation/git-fmt-merge-msg.txt | 1 +
Documentation/git-name-rev.txt | 1 +
Documentation/git-rebase.txt | 2 +-
5 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index d3ca9a9..721e035 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -8,6 +8,7 @@ git-archive - Creates an archive of files from a named tree
SYNOPSIS
--------
+[verse]
'git-archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
[--remote=<repo>] <tree-ish> [path...]
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 92e7a68..5051e2b 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -8,6 +8,7 @@ git-bundle - Move objects and refs by archive
SYNOPSIS
--------
+[verse]
'git-bundle' create <file> [git-rev-list args]
'git-bundle' verify <file>
'git-bundle' list-heads <file> [refname...]
diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt
index e560b30..4913c25 100644
--- a/Documentation/git-fmt-merge-msg.txt
+++ b/Documentation/git-fmt-merge-msg.txt
@@ -8,6 +8,7 @@ git-fmt-merge-msg - Produce a merge commit message
SYNOPSIS
--------
+[verse]
git-fmt-merge-msg [--summary | --no-summary] <$GIT_DIR/FETCH_HEAD
git-fmt-merge-msg [--summary | --no-summray] -F <file>
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index 5b5c4c8..d6c8bf8 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation/git-name-rev.txt
@@ -8,6 +8,7 @@ git-name-rev - Find symbolic names for given revs
SYNOPSIS
--------
+[verse]
'git-name-rev' [--tags] [--refs=<pattern>]
( --all | --stdin | <committish>... )
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2f417a8..753b275 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -7,8 +7,8 @@ git-rebase - Forward-port local commits to the updated upstream head
SYNOPSIS
--------
+[verse]
'git-rebase' [-v] [--merge] [-C<n>] [--onto <newbase>] <upstream> [<branch>]
-
'git-rebase' --continue | --skip | --abort
DESCRIPTION
--
1.5.2.rc3.50.gfdcb7
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox