* Re: Implementing branch attributes in git config
From: Junio C Hamano @ 2006-05-09 5:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605081828250.3718@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> [branch]
>> name = linus
>> url = git://git.kernel.org/../torvalds/linux-2.6
>>
>> [branch]
>> url = git://git.kernel.org/../jgarzik/libata-dev
>> name = libata
>
> Yes, that would be a silent and confusing error.
Although I haved raised objections, I actually started to like
the idea of using multiple [branch] (or wasn't it [remote] given
the example variables we have been using?) sections.
We should first depart from the Windoze .INI mindset. While I
do not think users expect case insensisitivity, only because the
section headers are marked with [brackets], if that syntax
somehow makes people expect such, maybe we should stop using
[bracket] as section markers.
Whatever marker we end up using, I'd suggest somewhat different
approach.
- Treat each part that are grouped under [bracketted-string]
marker as a bag of variable=value pairs. Loosely speaking,
the bracketted-string defines a schema -- what kind of
variables are expected to be there in that seciton. For
example, a section for things we traditionally had in remotes
file would contain fields (variables) such as url, fetch, and
push (we might add proxy to this list). And we call this
"bag of variable=value" a section.
- There can be multiple sections in a config file that uses the
same schema. The example at the beginning of this message
is perfectly valid. It defines two sections of type
[branch], each of which has two variables (name and url) in
it.
Unlike your earlier suggestion, the second [branch] is not just
for readability; it is mandatory, because we are talking about
two different [branch]es (eh, that's [remote]s, really), it
needs to be there to separate two instances.
The above would break the existing repo-config command, but
let's forget about it for now. I think we are breaking
forward/backward compatibility in any proposals brought up so
far anyway.
We would need user interface level commands to
add a new section
delete a section
We would need a way to identify a secion, perhaps using a value
of arbitrary key (e.g. "where name=blah"). Creating a section
could be implicit, just like the current repo-config.
add a variable=value to a section
delete a variable=value from a section
retrieve variables' values from a section
list value of a variable from all sections of a kind.
Probably need to support the same variable name appearing more
than once, just like the current multi-value support.
The current multi-value stuff assumes that multi-values are
exceptions, and rare. While I do not necessarily agree with
that, for now let's assume that is true.
Creating a new section with given variables:
$ cfg --set section var value var value ...
(eg) $ cfg --set branch name master merge origin pull linus
Here, 'var' and 'value' are case sensitive; if they have
syntactical metacharacters (WS, =, quotes, etc), they need
to be quoted when cfg command writes to the file (i.e. the
user do not have to quote more than necessary to protect
them from the shell).
Updating an existing section's variables, or create a new one:
$ cfg --replace section.var value where var0 = val0
(eg) $ cfg --replace remote.url git://... where name = linus
Look for a "remote" section that has a variable "name" with
value "linus" in it, and replace its "url" variable with
"git://...". If there is no "remote" section with such a
name, create it. For the key matching syntax, I do not
insist on using "where" (I merely used it for continuity
from the previous discussion). For the comparison operator,
in addition to the '=' shown above, we would probably want
to have regexp match (perhaps ':' to emulate "expr") as well.
Retrieving a variable:
$ cfg --get section.var [where var0 = val0]
(eg) $ cfg --get remote.url where name = linus
List sections:
$ cfg --list section.var
(eg) $ cfg --list remote.name
So, an equivalent of "grep -H URL: .git/remotes/*" becomes something like:
for name in `cfg --list remote.name`
do
url=`cfg --get remote.url where name = "$name"`
echo "$name: URL: $url"
done
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Jakub Narebski @ 2006-05-09 4:28 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605082100460.3718@g5.osdl.org>
Linus Torvalds wrote:
> I would suggest a much more readable format:
>
> [core]
> ...
>
> [branch "core"]
> ...
>
> [remote "core"]
> ...
>
> and yes, enforce the <space>+<quoted name> format. We'd turn it internally
> into some random internal string format (probably replacing the space with
> a dot, and removing the quotes, so it would become "remote.core.<key>").
I'm all for it. Nice compromise of [branch."miXedCaps"] and ["miXedCaps"],
human readable end editable, and easy parsable.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Pavel Roskin @ 2006-05-09 4:20 UTC (permalink / raw)
To: git
In-Reply-To: <20060508230752.43118643.seanlkml@sympatico.ca>
Hello!
I feel so bad that I sparked this discussion about config files and
couldn't participate in it in real time. I'd like to summarize my
thoughts on the subject - maybe they will help us come to an agreement.
User convenience trumps backward compatibility.
Case in-sensitivity is almost a foreign concept for POSIX. There is no
expectation (except among newbies) that bash would run grep if it's
asked to run Grep. Why would git-repo-config need to foster such
expectations, and do so inconsistently, e.g. for key names but not for
values?
The config files use escaping by backslash, which is easier to work with
than quoting. Quoting should be introduced if backslash escaping
doesn't work, and I think backslash escaping in fine.
Users who edit the config file manually and mindlessly get what they
deserve. Users who misspell "master" as "Master" get what they deserve.
Occasional typos could be caught and reported if practical, but hand
holding shouldn't be a design goal.
Either we need the third layer in key hierarchy, and that layer should
support user defined strings, or we need to relax one of the layers to
user define strings. User defined means that it can include spaces,
slashes, dots and many other characters. Whenever a character is not
allowed, we should have a good reason.
An example of two-layer approach:
[branchdescriptions]
master = My master branch
netdev-master = Patches for netdev
[branchremotes]
master = origin
netdev-master = netdev
All other examples quoted here are examples of three-layer approach.
Either the extra key is inserted into the section name (Linus) or into
the value (Dscho). It can also be inserted into the existing key.
If we want to group all branch properties for each branch, we have to go
three-layer. If we don't want that, the above example should accepted
as the simplest approach.
Adding an additional key layer to the existing keys is syntactically
nice, but buys us very little in terms of ability to group branch data:
[branchdata]
remote[master] = origin
remote[netdev-master] = master
description[master] = My master branch
description[netdev-master] = Patches for netdev
Adding an additional key layer to the value is inherently fragile. The
value has free format, and so is the new key. It also has the same
problem that the data for different branches is mixed together.
Adding an additional key layer to the section name looks strange
syntactically, but it's the approach that gives us immediate grouping of
all branch data for every branch.
My personal preference is the Linus' proposal, but with backslash
escaping instead of quoting, with explicit "branch." in the section
names, and with case sensitive sections and keys.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-09 4:11 UTC (permalink / raw)
To: sean; +Cc: junkio, git
In-Reply-To: <BAYC1-PASMTP05953E2B948CB07A171FD8AEA90@CEZ.ICE>
On Mon, 8 May 2006, sean wrote:
>
> [core]
> ...
> [branch.core]
> ...
> [remote.core]
> ...
Ok. In that case, I would suggest a much more readable format:
[core]
...
[branch "core"]
...
[remote "core"]
...
and yes, enforce the <space>+<quoted name> format. We'd turn it internally
into some random internal string format (probably replacing the space with
a dot, and removing the quotes, so it would become "remote.core.<key>").
> But it's not just the config file, it's also how it ends up being used
> on the command line..
Actually, the command line migth as well allow any strange thing, and
_add_ the quotes internally. So you could do something that does
git repo-config set Remote.Core.Pull master
and we could just let that generate
[remote "Core"]
pull = master
or whatever.
I care about the _file_ being human-editable, but that means that I think
it's perfectly fine to have some smarts in the tools that help us do so,
and let them recognize the magic "remote" and "branch" prefixes.
Linus
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-09 3:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0605082007100.3718@g5.osdl.org>
On Mon, 8 May 2006 20:08:41 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> On Mon, 8 May 2006, sean wrote:
> >
> > What's the advantage of section quotation marks over just allowing these
> > characters in regular section names? To be specific, what is wrong with:
> >
> > [jc/show-branch-dense]
>
> This would _suck_
>
> What if you have a branch called "core"? Not all all unlikely.
>
> Think about what a section like
>
> [core]
>
> really means.
Yeah, but the part of my message you didn't quote made it quite clear i know
about this problem, what i would really propose is:
[core]
...
[branch.core]
...
[remote.core]
...
etc...
> Plus I really want to not be case sensitive by default. Case sensitivity
> really is _not_ normal for this kind of config file syntax.
But it's not just the config file, it's also how it ends up being used
on the command line.. you have to admit silent differences between
these two command lines is _not_ desirable:
$ git repo-config "Branch".url
$ git repo-config Branch.url
That can't be something you want to see either.
Sean
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-09 3:08 UTC (permalink / raw)
To: sean; +Cc: junkio, git
In-Reply-To: <BAYC1-PASMTP04C9C4BF5B89E55B9D877AAEA90@CEZ.ICE>
On Mon, 8 May 2006, sean wrote:
>
> What's the advantage of section quotation marks over just allowing these
> characters in regular section names? To be specific, what is wrong with:
>
> [jc/show-branch-dense]
This would _suck_
What if you have a branch called "core"? Not all all unlikely.
Think about what a section like
[core]
really means.
Plus I really want to not be case sensitive by default. Case sensitivity
really is _not_ normal for this kind of config file syntax.
Linus
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Linus Torvalds @ 2006-05-09 3:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bertrand Jacquin, git
In-Reply-To: <7vwtcvc42s.fsf@assigned-by-dhcp.cox.net>
On Mon, 8 May 2006, Junio C Hamano wrote:
> "Bertrand Jacquin" <beber.mailing@gmail.com> writes:
>
> > 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.
>
> Forgetting about a fast-forward merge, (1) and (2) are
> available in the commit header and the commit log, so is (4) if
> you enable merge.summary configuration like Linus does in his
> kernel repository.
NOTE! Please don't enable "merge.summary" if you ever merge from the
upstream tree. That just looks ugly. Your merge messages will be just
filled with crap that has nothing to do with your tree - and everything to
do with all the _unrelated_ normal development that happened in the tree.
So in general, "merge.summary" makes sense only for trees that pull from
downstreams, and never merge with anything upstream. My tree obviously
does that for the kernel. Think of it as a "top-level maintainer" flag,
although it works find also for sub-maintainers as long as they
synchronize upwards _purely_ by being pulled from, not by pulling.
But if you want to get it for any random merges, you can always just do
git log -11 --pretty=oneline ^$commit^ $commit^@ |
sed 's/[0-9a-f]* // ; 11 s/.*/\.\.\./'
which will show up to the ten first commits that were merged (and turn the
eleventh one, if it exists, into "..." - that's a pretty disgusting trick
to make it show when you left things out).
That "^$commit^ $commit^@" part is important. It may look like some
deranged git smiley, but it does exactly what you want it to do: take all
the parents of the commit, but ignore any commit reachable from the first
one (the "mainline" of the person who did the commit).
The ^@ syntax is obviously pretty new, so it requires a modern git.
Linus
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-09 2:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0605081854190.3718@g5.osdl.org>
On Mon, 8 May 2006 18:57:08 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> Btw, I keep coming back to the same
>
> ["jc/show-branch-dense"]
> remote = git://...
>
> branch specifier syntax. It just seems very intuitive and is easy to
> parse.
We already need such section headers for remotes, and for branches..
both which may well need to be quoted as above.. how to distinguish
between them? How to handle the next case that comes along where we
want these special header semantics?
We really need:
[branch.Whatever]
and:
[remote.Whatever]
As in the case of "origin" where we have a remote and a branch
named that.
> The only real downside ends up being the non-forwards-compatibility thing.
> But trying to be forwards-compatible for old git versions with this thing
> would seem to be a major pain for rather slim gain.
What's the advantage of section quotation marks over just allowing these
characters in regular section names? To be specific, what is wrong with:
[jc/show-branch-dense]
remote = git://...
If we just relax the legal characters in identifiers to include slash and dash?
It doesn't seem to be any different in amount of code needed to achieve, and it
is just as intuitive (perhaps more so) and no worse on the forward-compatibility
thing.
If we continue with case insensitive section names, it's quite possible for
the user to mess up while hand editing or forgetting proper "git" quoting
rules on the command line and end up with silent breakage:
$ git repo-config "Branch".url = git://...
(updates section ["Branch"])
And then the next time forget the quotes and use:
$ git repo-config Branch.url = git://...
(updates section [branch])
And all of a sudden the user is updating _different_ sections with
unpredictable results. This is just awkward; why not just admit that
section names should always be case sensitive if we're going to put
filenames inside them?
Sean
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Junio C Hamano @ 2006-05-09 2:41 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: Junio C Hamano, git
In-Reply-To: <4fb292fa0605081809r6aa76baai5eac9823183fc3fc@mail.gmail.com>
"Bertrand Jacquin" <beber.mailing@gmail.com> writes:
> 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.
Forgetting about a fast-forward merge, (1) and (2) are
available in the commit header and the commit log, so is (4) if
you enable merge.summary configuration like Linus does in his
kernel repository.
The comment on diffstat Linus already made applies to (3), but
if you want you could do "git diff --stat HEAD^..HEAD" to see
what happened to that branch by merging the other branch into
it.
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-09 1:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wv4c7wk.fsf@assigned-by-dhcp.cox.net>
On Mon, 8 May 2006, Junio C Hamano wrote:
>
> Yes, but that statefulness is inviting user errors, and you need
> to update repo-config and config parser anyway, so I still do
> not see what the advantage is.
Btw, I keep coming back to the same
["jc/show-branch-dense"]
remote = git://...
branch specifier syntax. It just seems very intuitive and is easy to
parse.
The only real downside ends up being the non-forwards-compatibility thing.
But trying to be forwards-compatible for old git versions with this thing
would seem to be a major pain for rather slim gain.
Linus
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-09 1:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wv4c7wk.fsf@assigned-by-dhcp.cox.net>
On Mon, 8 May 2006, Junio C Hamano wrote:
>
> You dodged my comments on the SQL-like queries ;-). I was half
> (perhaps 3/4) joking, but some people actually might like to be
> able to say:
>
> git repo-config --get-all branch.name where url like 'git://%'
I think databases tend to be a huge mistake. Show me a SQL database where
users can edit the data by hand, and it's all readable, and maybe I'll
change my mind.
The monotone guys have almost everything in a database, and from what I
can tell it results in (a) you can do some really funky queries and (b)
it's confusing and slow as hell.
Now, the speed issue doesn't matter for a config file, but there the
editability very much does.
> Oops, by the way, why does a [branch] have url as its attribute?
> I think this was a bad example -- we are talking about [remote]
> here. But the main point is about syntax, so that is OK.
Yeah, "remote" is clearly better than "url".
> I am reluctant to buy that argument (I see it is an easy way
> from the implementation point of view) -- it appears to me that
> it would invite this easy user error.
>
> [branch]
> name = linus
> url = git://git.kernel.org/../torvalds/linux-2.6
>
> [branch]
> url = git://git.kernel.org/../jgarzik/libata-dev
> name = libata
Yes, that would be a silent and confusing error.
Linus
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Linus Torvalds @ 2006-05-09 1:27 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, git
In-Reply-To: <1147136467.2694.53.camel@shinybook.infradead.org>
On Tue, 9 May 2006, David Woodhouse wrote:
>
> Ah, right. Those are _commit_ IDs in that strange first line. I'll
> reformat those to 'Commit:' and 'Parent:' for the mailing list.
Right. That first line (that starts with "commit") lists the commit ID,
and if you say "--parents", the commit ID's of the parents will be
appended.
So if you want to turn that into "Commit: <id>" and "Parent: <id>", you'll
want to do something like this:
git show --no-abbrev -C --patch-with-stat --pretty=fuller --parents $commit |
sed '1 s/commit \([0-9a-f]*\)/Commit: \1\nParent: /'
which should look pretty (count the spaces to make sure it lines up
right with the other fields).
(And if you ever want to report on merges, you'll want to change that a
bit, but it should be reasonably close to the above)
Linus
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Junio C Hamano @ 2006-05-09 1:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605081801360.3718@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 8 May 2006, Junio C Hamano wrote:
>>
>> Wait a minute... Statefulness is not the issue, I think.
>
> Well, it does end up being..
Not really, you ended up making it so, perhaps, but I do not
think it needs to be.
You dodged my comments on the SQL-like queries ;-). I was half
(perhaps 3/4) joking, but some people actually might like to be
able to say:
git repo-config --get-all branch.name where url like 'git://%'
to list all the repositories reachable via git-native protocol.
Oops, by the way, why does a [branch] have url as its attribute?
I think this was a bad example -- we are talking about [remote]
here. But the main point is about syntax, so that is OK.
> 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.
I am reluctant to buy that argument (I see it is an easy way
from the implementation point of view) -- it appears to me that
it would invite this easy user error.
[branch]
name = linus
url = git://git.kernel.org/../torvalds/linux-2.6
[branch]
url = git://git.kernel.org/../jgarzik/libata-dev
name = libata
> 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.
Yes, but that statefulness is inviting user errors, and you need
to update repo-config and config parser anyway, so I still do
not see what the advantage is.
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Linus Torvalds @ 2006-05-09 1:18 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: David Woodhouse, Junio C Hamano, git
In-Reply-To: <4fb292fa0605081755m22e8239cjda0b1ac74b84c0d9@mail.gmail.com>
On Tue, 9 May 2006, Bertrand Jacquin wrote:
> 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.
Sure.
If you want to track merges and get their patches, add the "--cc" flag,
which tells git to use the "conflict combination patch" that shows any
visible conflicts.
(NOTE NOTE NOTE! This is _not_ the same as showing what conflicted: if you
edited the result to match one of the original branches, it will be quiet
in --cc, but if the result of a conflict was something that was in
_neither_ branch, it will be shown! So most clean merges will not show any
conflict diff at all, but the diffstat will be shown against the "first
parent").
And you probably don't want to abbreviate the parent commit SHA1's (which
are shown for merges, but not regular commits), so add "--no-abbrev".
If you want to show parents for _all_ commits, you could do something like
git show --no-abbrev --cc -C --patch-with-stat --pretty=fuller --parents |
sed '1 s/commit [0-9a-f]*/\0\nParents: / ; /^Merge: / d'
which removes a potential "Merge: " line in favour of listing the parents
on a "Parents:" line, and which also shows merges nicely.
That said, the diffstat for merges is usually just a lot of noise. It's
sometimes nice (you've merged from a topic branch), but if you have merged
from the mainline _into_ a topic branch, it's just annoying.
So the above is just a wild suggestion. Caveat emptor.
Linus
^ permalink raw reply
* 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
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