* Re: git-feed-mail-list.sh
From: David Woodhouse @ 2006-05-09 1:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64kgc8ik.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
On Mon, 2006-05-08 at 18:05 -0700, Junio C Hamano wrote:
> That's the replacement of "git format-patch". If you have a
> chance, please try out what's in "next". Johannes did quite a
> nice enhancements.
I think I'd best wait for it to turn up in the release; preferably
already capable of MIME quoting. I don't like touching the scripts which
feed the mailing lists :)
This is what I currently have... since it changes the format I think
I'll won't deploy it yet -- I'll wait until the "replacement of
git-format-patch" is done, in case that would change the format _again_.
I'd rather not change the format I send to the list twice within a few
weeks.
--
dwmw2
[-- Attachment #2: git-feed-mail-list.sh --]
[-- Type: application/x-shellscript, Size: 2999 bytes --]
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Bertrand Jacquin @ 2006-05-09 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac9sc8m3.fsf@assigned-by-dhcp.cox.net>
On 5/9/06, Junio C Hamano <junkio@cox.net> wrote:
> "Bertrand Jacquin" <beber.mailing@gmail.com> writes:
>
> > Is there a way to track merge like that?
>
> The command line you quoted shows the relevant information for
> people who want to know what happened in that merge.
>
> Namely:
>
> * it always shows the header and the message
>
> * it shows the changes that are not trivial (i.e. merge parents
> have overlapping different versions and manual resolution
> resulted in something different from either parents).
>
> It is not a replacement for format-patch, but I think the commit
> mailing list is not for machines to receive and apply the
> received patches, but for humans to inspect, so it would be more
> suitable than a naive alternative of showing diff from all
> parents concatenated together.
That's right. And don't want to do that.
But I would like to send an email after merge to inform people that:
o tree ``a'' and ``b'' have been merged.
o made by John Doe at a time
o show a diffstat.
o show a --short-log=oneline from merge base.
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Junio C Hamano @ 2006-05-09 1:05 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1147136467.2694.53.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> Having 'git-show --pretty=email' would be nice. I think Junio is working
> on something which will achieve that, right?
That's the replacement of "git format-patch". If you have a
chance, please try out what's in "next". Johannes did quite a
nice enhancements.
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-09 1:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virogc90u.fsf@assigned-by-dhcp.cox.net>
On Mon, 8 May 2006, Junio C Hamano wrote:
> >
> > The problem with _that_ is that "git repo-config" can't add this kind of
> > setup sanely: it doesn't understand that kind of statefulness.
>
> Wait a minute... Statefulness is not the issue, I think.
Well, it does end up being..
> How would you tell your updated repo-config what to update and
> what to look up?
>
> - I want the url for branch whose name is "origin"
>
> - I want to fetch their "for-linus" branch when fetching
> from the branch whose name is "jgarzik" from now on.
Exactly, git repo-config would have to know about this magic thing, and
have a special argument like
--state=branch.name
that says that "state" is to be taken from the "branch.name" variable when
seen.
Then, in addition to the regexp, you would have a way to trigger on the
"state" variable.
> Now, how would that compare with:
>
> [branch.jgarzik]
> url = git://git.kernel.org/...
> fetch = for-linus
>
> or
> [branch."JGarzik"]
> url = git://git.kernel.org/...
> fetch = for-linus
It would be _able_ to do all the same things, but thanks to statefulness
you'd be able to keep the section (and key) names the way they are.
> On a related topic, I have always been torn about the "for"
> convention.
I agree. And I think it's actually very much the same thing. It adds
state, but it adds it to each _value_, instead of adding it once "before"
the values.
Linus
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Junio C Hamano @ 2006-05-09 1:03 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: git
In-Reply-To: <4fb292fa0605081755m22e8239cjda0b1ac74b84c0d9@mail.gmail.com>
"Bertrand Jacquin" <beber.mailing@gmail.com> writes:
> Is there a way to track merge like that?
The command line you quoted shows the relevant information for
people who want to know what happened in that merge.
Namely:
* it always shows the header and the message
* it shows the changes that are not trivial (i.e. merge parents
have overlapping different versions and manual resolution
resulted in something different from either parents).
It is not a replacement for format-patch, but I think the commit
mailing list is not for machines to receive and apply the
received patches, but for humans to inspect, so it would be more
suitable than a naive alternative of showing diff from all
parents concatenated together.
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: David Woodhouse @ 2006-05-09 1:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605081742330.3718@g5.osdl.org>
On Mon, 2006-05-08 at 17:45 -0700, Linus Torvalds wrote:
> As long as the "commit <sha1>" id is there (and "--pretty=fuller" does
> have it), I'll be happy.
Ah, right. Those are _commit_ IDs in that strange first line. I'll
reformat those to 'Commit:' and 'Parent:' for the mailing list.
Having 'git-show --pretty=email' would be nice. I think Junio is working
on something which will achieve that, right?
> At some point, the commit mailing list didn't
> actually mention the commit ID itself, just the tree/parent IDs.
Yeah, I know -- and I got complaints :)
--
dwmw2
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Bertrand Jacquin @ 2006-05-09 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejz4c8wm.fsf@assigned-by-dhcp.cox.net>
On 5/9/06, Junio C Hamano <junkio@cox.net> wrote:
> "Bertrand Jacquin" <beber.mailing@gmail.com> writes:
>
> > What is --parents for ?
>
> In the part you did not quote, David wanetd a way to grab the
> parents of the commit in question, so I gave it to him.
Ok, sorry. I read too fast.
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Junio C Hamano @ 2006-05-09 0:57 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: git
In-Reply-To: <4fb292fa0605081753r1d9e7cb6u3a9b513bcbf2404a@mail.gmail.com>
"Bertrand Jacquin" <beber.mailing@gmail.com> writes:
> What is --parents for ?
In the part you did not quote, David wanetd a way to grab the
parents of the commit in question, so I gave it to him.
> Is there a way to have a --pretty=fuller with date append to Author
> and Commiter name and email instead of have 1 lign after each ?
sed is your friend.
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Bertrand Jacquin @ 2006-05-09 0:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Woodhouse, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605081715270.3718@g5.osdl.org>
On 5/9/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> Ie you could probably more easily parse the data from something like
>
> git show -B --patch-with-stat --pretty=fuller $commit
>
Is there a way to track merge like that ? Documentation is not very
clear and near from empty.
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-09 0:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes.Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0605081731440.3718@g5.osdl.org>
On Mon, 8 May 2006 17:37:29 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> We could easily do
>
> [branch]
> name = "p4/BrAnCH"
> url = git://git.kernel.org/...
> pull = master
>
> ;
> ; Repeating the "[branch]" section here isn't
> ; needed, but doesn't hurt either, and is
> ; more readable
> ;
> [branch]
> name = "origin"
> url = ...
> pull = ...
>
> because the config file is always parsed linearly, and just
> trigger on "branch.name", and keep that around when parsing
> anything else.
That was pretty much what I was suggesting although i overlooked
the fact that you don't actually need to number the sections.
> The problem with _that_ is that "git repo-config" can't add this kind of
> setup sanely: it doesn't understand that kind of statefulness.
Shouldn't be too hard to deal with. So we would allow the following
command to make the url entry above:
$ git repo-config branch.p4/BrAnCH.url git://git.kernel.org/...
> The above would work without any changes what-so-ever to the config format
> and readers - and old versions of git wouldn't react badly either. But the
> writer would need to be taught about state.
Well it seems like maybe the best compromise, and it avoids having to put
files and directories into section names which Johannes was objecting to.
Sean
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Junio C Hamano @ 2006-05-09 0:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605081731440.3718@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 8 May 2006, sean wrote:
>>
>> One option, which I don't really like and comes with its own set of
>> problems, would be to do something like:
>>
>> [branch1]
>> streetname = "p4/BrAnCH"
>> [branch2]
>> streetname = "origin"
>
> You don't actually need that.
>
> We could easily do
>
> [branch]
> name = "p4/BrAnCH"
> url = git://git.kernel.org/...
> pull = master
>
> ;
> ; Repeating the "[branch]" section here isn't
> ; needed, but doesn't hurt either, and is
> ; more readable
> ;
> [branch]
> name = "origin"
> url = ...
> pull = ...
>
> because the config file is always parsed linearly, and just
> trigger on "branch.name", and keep that around when parsing
> anything else.
>
> The problem with _that_ is that "git repo-config" can't add this kind of
> setup sanely: it doesn't understand that kind of statefulness.
Wait a minute... Statefulness is not the issue, I think.
How would you tell your updated repo-config what to update and
what to look up?
- I want the url for branch whose name is "origin"
- I want to fetch their "for-linus" branch when fetching
from the branch whose name is "jgarzik" from now on.
In these query and update, you _are_ naming the branch with
name="xxx"; you just made "name" a special attribute.
Now, how would that compare with:
[branch.jgarzik]
url = git://git.kernel.org/...
fetch = for-linus
or
[branch."JGarzik"]
url = git://git.kernel.org/...
fetch = for-linus
I would say if we are grouping things together, if we can give
name to each group, _and_ if we are going to refer to the group
with its name, we are better off making the groups into distinct
sections _and_ make the syntax obvious that what name refers to
the section. I think [branch.jgarzik] syntax is more obvious
than your example where "name =" line is implicitly used as a
keyword to differenciate multiple occurrences of [branch]
sections.
Having said that, perhaps you have something more elaborate in mind,
e.g.
repo-config --get branch.url where name = 'origin'
repo-config --get branch.name where url like 'git://%'
repo-config branch.url 'git://git.kernel.org/...' where name = foo
;-) ;-) ;-) ??? If that is what you are after, then I agree
your syntax is more generic and suitable. But otherwise I fail
to see its point.
On a related topic, I have always been torn about the "for"
convention. While I think it was a cute hack, it would break
quite badly once we start doing anything complex.
[branch]
url = git://git.kernel.org/... for jgarzik
fetch = for-linus for jgarzik
proxy = none
url = git://git.kernel.org/... for torvalds
fetch = master for torvalds
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Bertrand Jacquin @ 2006-05-09 0:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Woodhouse, git
In-Reply-To: <7vu080c9uv.fsf@assigned-by-dhcp.cox.net>
On 5/9/06, Junio C Hamano <junkio@cox.net> wrote:
>
> If you are going to parse it anyway, this would probably be easier.
>
> $ git show --patch-with-stat --pretty=fuller --parents "$commit"
>
> Why would you want -B, by the way?
What is --parents for ?
Is there a way to have a --pretty=fuller with date append to Author
and Commiter name and email instead of have 1 lign after each ?
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Linus Torvalds @ 2006-05-09 0:45 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, git
In-Reply-To: <1147134522.2694.45.camel@shinybook.infradead.org>
On Tue, 9 May 2006, David Woodhouse wrote:
>
> Anyone got any objections to switching the kernel git-commits-* lists to
> this format?
As long as the "commit <sha1>" id is there (and "--pretty=fuller" does
have it), I'll be happy. At some point, the commit mailing list didn't
actually mention the commit ID itself, just the tree/parent IDs.
The "fuller" format should be fine, if you care about committer. Otherwise
just use the standard "--pretty", which drops committer info.
Linus
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-09 0:37 UTC (permalink / raw)
To: sean; +Cc: Johannes Schindelin, git
In-Reply-To: <BAYC1-PASMTP03ADC2F3E75E482ADC5CD3AEA90@CEZ.ICE>
On Mon, 8 May 2006, sean wrote:
>
> One option, which I don't really like and comes with its own set of
> problems, would be to do something like:
>
> [branch1]
> streetname = "p4/BrAnCH"
> [branch2]
> streetname = "origin"
You don't actually need that.
We could easily do
[branch]
name = "p4/BrAnCH"
url = git://git.kernel.org/...
pull = master
;
; Repeating the "[branch]" section here isn't
; needed, but doesn't hurt either, and is
; more readable
;
[branch]
name = "origin"
url = ...
pull = ...
because the config file is always parsed linearly, and just
trigger on "branch.name", and keep that around when parsing
anything else.
The problem with _that_ is that "git repo-config" can't add this kind of
setup sanely: it doesn't understand that kind of statefulness.
The above would work without any changes what-so-ever to the config format
and readers - and old versions of git wouldn't react badly either. But the
writer would need to be taught about state.
Linus
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Junio C Hamano @ 2006-05-09 0:36 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1147134522.2694.45.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> ... I think I
> have to add the commit and the parent manually, but that's easy enough
> to do -- the commit is obviously known, and the parent is just
> $(git-rev-parse $commit^1).
If you are going to parse it anyway, this would probably be easier.
$ git show --patch-with-stat --pretty=fuller --parents "$commit"
Why would you want -B, by the way?
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: David Woodhouse @ 2006-05-09 0:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605081715270.3718@g5.osdl.org>
On Mon, 2006-05-08 at 17:19 -0700, Linus Torvalds wrote:
> Well, you might choose to just not use "git-cat-file commit" but instead
> ask git to format the thing for you.
>
> Ie you could probably more easily parse the data from something like
>
> git show -B --patch-with-stat --pretty=fuller $commit
>
> instead of using "git-cat-file commit $commit" and generating the stat and
> diff manually.
>
> That way you get the dates etc pretty-printed for you by git.
Aha, thanks. Git has learned to do a lot more since I first started
hacking up a copy of git-log.sh to feed the mailing lists, and it even
had to walk the commit tree manually :)
The output of (the undocumented) '--pretty=fuller' is probably good
enough that I can just feed the mailing list with it directly. I think I
have to add the commit and the parent manually, but that's easy enough
to do -- the commit is obviously known, and the parent is just
$(git-rev-parse $commit^1).
Anyone got any objections to switching the kernel git-commits-* lists to
this format?
--
dwmw2
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Johannes Schindelin @ 2006-05-09 0:23 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP03ADC2F3E75E482ADC5CD3AEA90@CEZ.ICE>
Hi,
On Mon, 8 May 2006, sean wrote:
> [branch1]
> streetname = "p4/BrAnCH"
> [branch2]
> streetname = "origin"
Conceptually, it feels just wrong to me that a section name should contain
a filename. A section is something which contains data regarding a certain
concept. Such as "core", which has values concerning the core of git.
In that sense, I stay with my preferance:
[branch]
defaultRemote = bla for bloop
defaultRemote = connery for sean
No need to extend the simple config file. And remember, it is so simple,
because it is so strict.
Ciao,
Dscho
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Linus Torvalds @ 2006-05-09 0:19 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, git
In-Reply-To: <1147131877.2694.37.camel@shinybook.infradead.org>
On Tue, 9 May 2006, David Woodhouse wrote:
>
> The remaining problem is that the invocation of 'date' doesn't work with
> new versions of coreutils. This...
>
> date=(${rest#*> })
> sec=${date[0]}; tz=${date[1]}
> dtz=${tz/+/+ }; dtz=${dtz/-/- }
> pdate="$(date -Rud "1970-01-01 UTC + $sec sec $dtz" 2>/dev/null)"
>
> ... doesn't work any more on FC-5, because:
Well, you might choose to just not use "git-cat-file commit" but instead
ask git to format the thing for you.
Ie you could probably more easily parse the data from something like
git show -B --patch-with-stat --pretty=fuller $commit
instead of using "git-cat-file commit $commit" and generating the stat and
diff manually.
That way you get the dates etc pretty-printed for you by git.
Linus
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-09 0:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605090142280.5778@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 9 May 2006 01:44:31 +0200 (CEST)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 8 May 2006, sean wrote:
>
> > There's no good reason for git to break with traditional and common
> > practice in this case.
>
> It is well established common practice that ini files (and everything in
> config resembles an ini file) have case insensitive section headers as
> well as keys.
Not in ini files that support section headers that represent filenames
and directories. Exactly because those things _are_ case sensitive
and include more characters than just alnums. But we're not just
talking about the config file syntax we're talking about how the
user must ultimately refer to branches with uppercase character.
Now everytime a person wants to add a branch attribute via repo-config
they have to remember that git thinks uppercase characters should
be quoted. Doesn't that sound ridiculous to you?
The point is that we should make the config file and the repo-config
command easy for the _users_. Instead we're going to make them use
some crazy extra syntax because we refuse to come to terms with the
limitations of the choices we've made so far.
One option, which I don't really like and comes with its own set of
problems, would be to do something like:
[branch1]
streetname = "p4/BrAnCH"
[branch2]
streetname = "origin"
And then allow reference to it from git-repo-config by either branch#
or the value of street name. While it would take some extra coding
but at least it lives within the current restrictions for key names.
It just seems that once you have to even consider options like this,
a big red flag should be raised about some of the assumptions we've
built into the system.
Sean
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: David Woodhouse @ 2006-05-08 23:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzdy9zl2.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]
On Wed, 2006-05-03 at 21:35 -0700, Junio C Hamano wrote:
> If you were to do bashism local, don't you want to also localize
> other variables like key, SUBHEX, NEWSUB,...?
>
> It may make sense to enhance format-patch to do the Q encoding,
> so that you do not have to do this part by hand...
Yes, that would be useful. We should perhaps to the From: and To:
headers too. Here's my current version (thanks for the feedback)...
The remaining problem is that the invocation of 'date' doesn't work with
new versions of coreutils. This...
date=(${rest#*> })
sec=${date[0]}; tz=${date[1]}
dtz=${tz/+/+ }; dtz=${dtz/-/- }
pdate="$(date -Rud "1970-01-01 UTC + $sec sec $dtz" 2>/dev/null)"
... doesn't work any more on FC-5, because:
$ date -Rud '1970-01-01 UTC + 1147104611 sec + 0100'
date: invalid date `1970-01-01 UTC + 1147104611 sec + 0100'
--
dwmw2
[-- Attachment #2: git-feed-mail-list.sh --]
[-- Type: application/x-shellscript, Size: 3600 bytes --]
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Johannes Schindelin @ 2006-05-08 23:44 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP0453E2D70B10C6D116167EAEA80@CEZ.ICE>
Hi,
On Mon, 8 May 2006, sean wrote:
> There's no good reason for git to break with traditional and common
> practice in this case.
It is well established common practice that ini files (and everything in
config resembles an ini file) have case insensitive section headers as
well as keys.
Ciao,
Dscho
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Johannes Schindelin @ 2006-05-08 23:40 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605081905240.6713@iabervon.org>
Hi,
On Mon, 8 May 2006, Daniel Barkalow wrote:
> You could tell people always to use:
>
> [branch."name"]
I find this utterly ugly.
> I don't think that people are likely to use older versions of git on the
> same repository they've used newer versions on. (Clones of it, sure, but
> that doesn't matter here.) But we should, in any case, make the code
> ignore sections or lines with syntax errors, under the assumption that
> they're a later extension and possibly legal but not anything the code
> could be interested in getting from a parser that doesn't support them.
I have to bisect git sometimes, just because I have some local changes.
Older gits do barf with a fatal error when encountering a bad config.
Further, it is probably not a good idea to relax error-checking. It is too
easy to overlook.
Ciao,
Dscho
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-08 23:30 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0605081905240.6713@iabervon.org>
On Mon, 8 May 2006 19:20:17 -0400 (EDT)
Daniel Barkalow <barkalow@iabervon.org> wrote:
> You could tell people always to use:
>
> [branch."name"]
>
> even if the branch name is all lowercase anyway. They could even use:
>
> [Branch."MyMixedCaseBranch"]
>
> Then when you refer to something case-sensitive with the possibility of
> funny characters, you put it in quotes, regardless of what it is.
>
> For that matter, we could retain the quotes when we parse the file, and
> reject [branch.master] for lacking the quotes, so that people who are only
> exposed to branch names all in lowercase letters don't get habits that
> will fail when they have a v2.6.16.x branch.
>
> I don't think that people are likely to use older versions of git on the
> same repository they've used newer versions on. (Clones of it, sure, but
> that doesn't matter here.) But we should, in any case, make the code
> ignore sections or lines with syntax errors, under the assumption that
> they're a later extension and possibly legal but not anything the code
> could be interested in getting from a parser that doesn't support them.
Unfortunately that's not the only place where you have to use the
excessive quoting; you also have to do the same when using the git
repo-config command line. All because we're clinging to case
insensitivity and a very restrictive set of characters for
identifiers in the config file. And just why are we clinging?
Believe when Linus offered the code originally he said that it was
easier to start out very restrictive and loosen up later than it was
to start loose and become restrictive later. That makes a lot of
sense, but somewhere along the way we seem to have made a virtue
out of something that is actually getting in the way of natural
syntactic usage. There's no good reason for git to break with
traditional and common practice in this case.
Sean
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Daniel Barkalow @ 2006-05-08 23:20 UTC (permalink / raw)
To: sean; +Cc: Junio C Hamano, git
In-Reply-To: <BAYC1-PASMTP110777A694DAF1D7623895AEA80@CEZ.ICE>
On Sun, 7 May 2006, sean wrote:
> On Sun, 07 May 2006 19:29:50 -0700
> Junio C Hamano <junkio@cox.net> wrote:
>
>
> > Not at all. Whatever Porcelain that runs repo-config to record
> > the branch name needs to spell that branch name with proper
> > quoting, like:
>
> Okay. It just seems nuts to require quoting because you happen
> to use an uppercase character. People are used to quoting
> special characters like * and $, not uppercase letters.
You could tell people always to use:
[branch."name"]
even if the branch name is all lowercase anyway. They could even use:
[Branch."MyMixedCaseBranch"]
Then when you refer to something case-sensitive with the possibility of
funny characters, you put it in quotes, regardless of what it is.
For that matter, we could retain the quotes when we parse the file, and
reject [branch.master] for lacking the quotes, so that people who are only
exposed to branch names all in lowercase letters don't get habits that
will fail when they have a v2.6.16.x branch.
I don't think that people are likely to use older versions of git on the
same repository they've used newer versions on. (Clones of it, sure, but
that doesn't matter here.) But we should, in any case, make the code
ignore sections or lines with syntax errors, under the assumption that
they're a later extension and possibly legal but not anything the code
could be interested in getting from a parser that doesn't support them.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH/RFC] Teach git-clean optional <paths>... parameters.
From: Pavel Roskin @ 2006-05-08 22:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wv4gx0r.fsf@assigned-by-dhcp.cox.net>
On Mon, 2006-05-08 at 12:02 -0700, Junio C Hamano wrote:
> When optional paths arguments are given, git-clean passes them
> to underlying git-ls-files; with this, you can say:
>
> git clean 'temp-*'
>
> to clean only the garbage files whose names begin with 'temp-'.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Pavel Roskin <proski@gnu.org>
> * I usually do not use clean myself, so I am not sure if this
> is the kind of thing people who do use 'clean' regularly
> would generally want, hence this RFC.
I'm not likely to use this feature, but I think it's OK to have it.
It would be nice to have "--" support (see e.g. git-commit).
> + -X remove only ignored files as well
That's my stupid error, "as well" should be removed.
--
Regards,
Pavel Roskin
^ 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