* Re: Teach "approxidate" about weekday syntax
From: Johannes Schindelin @ 2005-11-20 23:36 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.11.18.18.07.37.819505@smurf.noris.de>
Hi,
On Fri, 18 Nov 2005, Matthias Urlichs wrote:
> Linus Torvalds wrote:
> > I'm sorry, but having "git log --since=confusion" would just be
> > irresponsible.
> >
> Possibly, but on the other hand there'd be a lot more truth in these than
> in our current month names. (November hasn't been the ninth month for
> *some* time now...)
Well, I know a girl who gave birth to her child in November. And I guess
she's not the only one.
Hth,
Dscho
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Josef Weidendorfer @ 2005-11-20 23:26 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511200935081.13959@g5.osdl.org>
On Sunday 20 November 2005 19:09, Linus Torvalds wrote:
> [branches.origin]
> url = master.kernel.org:/pub/scm/git/git.git
> pull = master:origin
Two things:
* base names are case insensitive. Repository shortcuts are case
sensitive (and head names, too)
* to get rid of .git/branches/XXX, XXX has to be allowed as
base name. But XXX can contain anything a head name can (including ".").
Not really a problem. Use the ' for ' syntax:
[remotes]
url = master.kernel.org:/pub/scm/git/git.git for origin
pull = master:origin for origin
Not really nice. We can not have "for" as head name.
Josef
^ permalink raw reply
* Re: non-trivial merge failures
From: Ryan Anderson @ 2005-11-20 23:07 UTC (permalink / raw)
To: David S. Miller; +Cc: git
In-Reply-To: <20051120.134945.104623647.davem@davemloft.net>
On Sun, Nov 20, 2005 at 01:49:45PM -0800, David S. Miller wrote:
>
> Every time I try to do a non-trivial merge, I always
> get this:
git-merge-recursive became the default merge tool recently, and Debian
uses Python 2.3 as the default, which lacks "subprocess.py". Luckily,
git ships a backport, so you can do:
make WITH_OWN_SUBPROCESS_PY=YesPlease all doc test install install-doc
or
make PYTHON_PATH=/usr/bin/python2.4 all doc test install install-doc
and fix things up (the second assuming, of course, you have python-2.4
installed)
Alternatively, you can build your own Debian packages with "make deb"
and just install them.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Yann Dirson @ 2005-11-20 22:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthias Urlichs, git
In-Reply-To: <Pine.LNX.4.63.0511201242210.27791@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, Nov 20, 2005 at 12:44:28PM +0100, Johannes Schindelin wrote:
> On Sun, 20 Nov 2005, Matthias Urlichs wrote:
>
> > Why not simply use info/grafts?
>
> 'Cause you can't fetch a graft. But I agree, instead of telling somebody:
> "I have this new branch which unifies history", you can send your friend a
> oneliner which appends a graft.
It can also be useful to work with grafts locally, and then use a
script to convert the grafted tree into real commits.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Yann Dirson @ 2005-11-20 22:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthias Urlichs, git
In-Reply-To: <Pine.LNX.4.63.0511200217200.11653@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, Nov 20, 2005 at 02:24:53AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 19 Nov 2005, Matthias Urlichs wrote:
>
> > [...] What can you do with such a thing that you cannot do now, just as
> > easily, besides slow down your programs with an unnecessary level of
> > indirection?
>
> I tend to agree. In fact, if I would like to introduce earlier history
> (for the sake of archeology or whatever), I would import the earlier
> history into git, possibly finding the best match in the current
> development branch (for example, when the original project continued for a
> while to be tracked in CVS), and then make a merge between these two.
>
> Then, I'd merge the new development's HEAD, and it would be fine:
>
> ORIG1 .. ORIG2 .. .. ORIG_HEAD
> |
> | GIT1 .. GIT2 .. .. GIT_HEAD
> | / /
> | / /
> UNIFYING_MERGE /
> \ /
> \ /
> NEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES
>
> Where ORIG_HEAD's tree is identical with GIT1's tree. The resulting branch
> would serve every research purpose I can think of (just be sure not to
> use "-m" with git-whatchanged).
Note: it's not only about research (ie. something that would be static
for browsing only), it's also about using the results of the research
in further developement.
Well, no doubt this approach can be used in many cases. But it makes
IMHO the history somewhat confusing, and has limitations. Let's say I
had a patch against ORIG2, and at a later date I find a successor for
it, based on GIT2. I would not have an incarnation of GIT2 with ORIG2
as ancestor: to be on the safe side I would have had to duplicate the
whole GIT1..* history.
And after I have done some work on my branch of duplicate commits, if
I used the type of unifying merges you suggest, I'm stuck forever with
the old GIT1..GIT_HEAD line, whether I need it or not (if it comes
from import of 2.4 patches, and thus has no signed tags whatsoever, I
do not need it any more).
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: non-trivial merge failures
From: Ismail Donmez @ 2005-11-20 21:51 UTC (permalink / raw)
To: git
In-Reply-To: <20051120.134945.104623647.davem@davemloft.net>
Sunday 20 November 2005 23:49 tarihinde şunları yazmıştınız:
> ImportError: No module named subprocess
You need Python 2.4.x, subprocess is a new module in Python 2.4
Regards,
ismail
^ permalink raw reply
* non-trivial merge failures
From: David S. Miller @ 2005-11-20 21:49 UTC (permalink / raw)
To: git
Every time I try to do a non-trivial merge, I always
get this:
davem@sunset:~/src/GIT/net-2.6$ git pull git://git.skbuff.net/gitroot/yoshfuji/linux-2.6.14+advapi-fix/
Unpacking 21 objects
100% (21/21) done
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Traceback (most recent call last):
File "/home/davem/bin/git-merge-recursive", line 13, in ?
from gitMergeCommon import *
File "/home/davem/share/git-core/python/gitMergeCommon.py", line 18, in ?
import subprocess
ImportError: No module named subprocess
Automatic merge failed/prevented; fix up by hand
davem@sunset:~/src/GIT/net-2.6$
(one can reproduce this exact tree state by cloning:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git
then executing the above pull command)
Maybe something is wrong with my python installation or
something like that?
It looks like it's failing to import some python module called
"subprocess", and I aparently don't have that installed.
/usr/bin/python on this Debian box is aparently python-2.3, do
I need to be using python-2.4 for this merge stuff to work?
^ permalink raw reply
* [PATCH] git-reset.txt: Small fix + clarifications.
From: Andreas Ericsson @ 2005-11-20 21:42 UTC (permalink / raw)
To: git
This basically translates the man-page from 'git-developerish' to plain
english, adding some almost-sample output from git-status so users can
recognize what will happen.
Also mention explicitly that --mixed updates the index, while --soft
doesn't. I understood the old text to mean "--mixed is exactly like
--soft, but verbose".
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
Documentation/git-reset.txt | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
applies-to: 0262dd41632580ee56288ad12fce71b6d260bf38
615aa2e01117c5ec82df3a5ad2f0328c89acdde8
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 31ec207..6af3a4f 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -14,19 +14,30 @@ DESCRIPTION
Sets the current head to the specified commit and optionally resets the
index and working tree to match.
+This command is useful if you notice some small error in a recent
+commit (or set of commits) and want to redo that part without showing
+the undo in the history.
+
+If you want to undo a commit other than the latest on a branch,
+gitlink:git-revert[1] is your friend.
+
OPTIONS
-------
--mixed::
- Like --soft but reports what has not been updated. This is the
- default action.
+ Resets the index but not the working tree (ie, the changed files
+ are preserved but not marked for commit) and reports what has not
+ been updated. This is the default action.
--soft::
Does not touch the index file nor the working tree at all, but
- requires them in a good order.
+ requires them to be in a good order. This leaves all your changed
+ files "Updated but not checked in", as gitlink:git-status[1] would
+ put it.
--hard::
Matches the working tree and index to that of the tree being
- switched to.
+ switched to. Any changes to tracked files in the working tree
+ since <commit-ish> are lost.
<commit-ish>::
Commit to make the current HEAD.
---
0.99.9.GIT
^ permalink raw reply related
* Re: Diffs "from" working directory
From: J. Bruce Fields @ 2005-11-20 20:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Blaisorblade, Chuck Lever, Catalin Marinas, git
In-Reply-To: <Pine.LNX.4.64.0511201010490.13959@g5.osdl.org>
On Sun, Nov 20, 2005 at 10:13:32AM -0800, Linus Torvalds wrote:
> On Sun, 20 Nov 2005, J. Bruce Fields wrote:
> >
> > That's a diff *to* the working directory. My complaint was that there
> > wasn't a convenient way to get a diff *from* the working directory.
>
> Something like
>
> git diff -R -M -p
>
> should do it, no?
A "-R" option to "stg diff" would be convenient, sure.--b.
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Matthias Urlichs @ 2005-11-18 18:07 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.58.0511180806550.25159@shark.he.net>
Randy.Dunlap wrote:
> ~Randy [who would just use ISO standard date format]
You can't just use non-confusing dates.
People used to confusion would be confused.
Speaking of which ..:
Linus Torvalds wrote:
>> 5 months with 73 days each; Chaos, Discord, Confusion, Bureaucracy, The
>> Aftermath
> I'm sorry, but having "git log --since=confusion" would just be
> irresponsible.
>
Possibly, but on the other hand there'd be a lot more truth in these than
in our current month names. (November hasn't been the ninth month for
*some* time now...)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
While there's life, there's hope.
-- Publius Terentius Afer (Terence)
^ permalink raw reply
* Re: [PATCH 5/5] git-daemon support for user-relative paths.
From: Matthias Urlichs @ 2005-11-18 17:57 UTC (permalink / raw)
To: git
In-Reply-To: <437DAA66.6070301@op5.se>
Hi, Andreas Ericsson wrote:
> DWIM? That's an acronym I don't know.
"Do What I Mean".
It's actually meant to be DMNS ("Do what i Mean, Not what i Say"),
but some early AI hackers at MIT shortened it maliciously so that
they could claim at least *some* success. :-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
do you want my self-identities alphabetically, chronologically, or in
random order? -- Misha
^ permalink raw reply
* Re: [PATCH] Support username and password inside URL
From: Krzysztof Halasa @ 2005-11-20 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtj3xe72.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> It is handy to have weak "authentication" in some situations. I
> am not ashamed to admit that I've used security-by-obscurity
> myself, when I sent an email to a friend, saying:
>
> Hi, I have some pictures I took during our last trip
> together, but due to their size I am not attaching them
> to this e-mail. Please pick them up at:
>
> http://members.cox.net/junkio/r0ZIEF/5S54m/
If the above is security by obscurity then any password scheme is, too.
After all you're obscuring the password, right?
Well, private key and its password can be obscure as well. :-)
A common definition says that security by obscurity is using a hidden
algorithm and not a shared or private secret.
--
Krzysztof Halasa
^ permalink raw reply
* [PATCH] Allow hierarchical section names
From: Johannes Schindelin @ 2005-11-20 20:22 UTC (permalink / raw)
To: git
A .git/config like follows becomes valid with this patch:
[remote.junio]
url = git://git.kernel.org/pub/scm/git/git.git
pull = master:junio todo:todo +pu:pu
[remote.ibook]
url = ibook:git/
pull = master:ibook
push = master:quetzal
(This patch only does the ini file thing, git-fetch and friends still
ignore these values).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Note that -- since don't favor that approach -- this patch
does *not* allow for "citing hierarchies" like this:
[Tyrannosaurus.rex]
jaw = big
[.minor]
jaw = unknown
i.e. the complete key of the second entry would be ".minor.jaw",
not "Tyrannosaurus.minor.jaw".
config.c | 19 ++++++++++---------
t/t1300-config-set.sh | 19 +++++++++++++++++++
2 files changed, 29 insertions(+), 9 deletions(-)
applies-to: b86aaa1512dbd810af049ec0611604272ac731e7
ff7acdf861ddcb9ff385476c68d35777469494bc
diff --git a/config.c b/config.c
index 5d237c8..38c0edd 100644
--- a/config.c
+++ b/config.c
@@ -143,7 +143,7 @@ static int get_base_var(char *name)
return -1;
if (c == ']')
return baselen;
- if (!isalnum(c))
+ if (!isalnum(c) && c != '.')
return -1;
if (baselen > MAXNAME / 2)
return -1;
@@ -405,28 +405,29 @@ int git_config_set_multivar(const char*
int fd;
char* config_file = strdup(git_path("config"));
char* lock_file = strdup(git_path("config.lock"));
-
- store.multi_replace = multi_replace;
+ const char* last_dot = strrchr(key, '.');
/*
* Since "key" actually contains the section name and the real
* key name separated by a dot, we have to know where the dot is.
*/
- for (store.baselen = 0;
- key[store.baselen] != '.' && key[store.baselen];
- store.baselen++);
- if (!key[store.baselen] || !key[store.baselen+1]) {
+
+ if (last_dot == NULL) {
fprintf(stderr, "key does not contain a section: %s\n", key);
return 2;
}
+ store.baselen = last_dot - key;
+
+ store.multi_replace = multi_replace;
/*
* Validate the key and while at it, lower case it for matching.
*/
store.key = (char*)malloc(strlen(key)+1);
for (i = 0; key[i]; i++)
- if (i != store.baselen && (!isalnum(key[i]) ||
- (i == store.baselen+1 && !isalpha(key[i])))) {
+ if (i != store.baselen &&
+ ((!isalnum(key[i]) && key[i] != '.') ||
+ (i == store.baselen+1 && !isalpha(key[i])))) {
fprintf(stderr, "invalid key: %s\n", key);
free(store.key);
return 1;
diff --git a/t/t1300-config-set.sh b/t/t1300-config-set.sh
index 59b6c4c..7a5849a 100644
--- a/t/t1300-config-set.sh
+++ b/t/t1300-config-set.sh
@@ -248,5 +248,24 @@ test_expect_failure 'invalid key' 'git-c
test_expect_success 'correct key' 'git-config-set 123456.a123 987'
+test_expect_success 'hierarchical section' \
+ 'git-config-set 1.2.3.alpha beta'
+
+cat > expect << EOF
+[beta] ; silly comment # another comment
+noIndent= sillyValue ; 'nother silly comment
+
+# empty line
+ ; comment
+[nextSection]
+ NoNewLine = wow2 for me
+[123456]
+ a123 = 987
+[1.2.3]
+ alpha = beta
+EOF
+
+test_expect_success 'hierarchical section value' 'cmp .git/config expect'
+
test_done
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] Support username and password inside URL
From: Junio C Hamano @ 2005-11-20 20:21 UTC (permalink / raw)
To: Kalle Valo; +Cc: git
In-Reply-To: <873blriqh0.fsf@litku.valo.iki.fi>
Kalle Valo <Kalle.Valo@iki.fi> writes:
> Currently usage of curl was so that netrc was mandatory and passwords in URL
> weren't allowed. Change netrc to optional to make HTTP basic authentication
> with username and password in URL also work.
HTTP "basic"? Let's at least say "digest" for starters ;-).
I am modestly against letting users use auth-embedding URLs, and
fairly strongly against encouraging users to do so.
It is handy to have weak "authentication" in some situations. I
am not ashamed to admit that I've used security-by-obscurity
myself, when I sent an email to a friend, saying:
Hi, I have some pictures I took during our last trip
together, but due to their size I am not attaching them
to this e-mail. Please pick them up at:
http://members.cox.net/junkio/r0ZIEF/5S54m/
Please drop me a note after picking them up, so that I
can clean-up the directory.
Auth-embedding URLs are about as secure as the above URL, but it
is worse because they may tempt you to reuse the same username
password pair for other purposes later.
If you are using the password protected URL yourself, I'd
imagine having them in your netrc would not be such a big deal,
so I suspect your expected usage is not for yourself, but more
like giving a temporary, even one-shot, access to others like
the above example, and making it more convenient for them (even
in that case, if it is not one-shot but for repeated use, I'd
imagine it would not be such a big deal to ask them to do
appropriate netrc). If that is what is going on here, then
IMNSHO it would be better to make it clear that you are doing
security-by-obscurity by not using username password pair, which
makes you pretend that you are doing _some_ security.
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Johannes Schindelin @ 2005-11-20 19:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511200935081.13959@g5.osdl.org>
Hi,
On Sun, 20 Nov 2005, Linus Torvalds wrote:
> [branches.origin]
> url = master.kernel.org:/pub/scm/git/git.git
> pull = master:origin
>
> [branches.mine]
> url = my.domain.com:/other/repo
> pull = master:mine
I like this approach best. In fact, that was my idea on how to go about
implementing that feature.
However,
> [branches.origin]
> url = master.kernel.org:/pub/scm/git/git.git
> pull = master:origin
>
> [.mine]
> url = my.domain.com:/other/repo
> pull = master:mine
I don't like this. Usually, data in ini files is not dependent on its
position in the file, with the notable exception of section names. I never
ran across nested sections (probably for all the reasons XML is
unreadable). And the sections should be exchangable, just for clarities
sake.
> And I'm not 100% convinced that putting these branches in the config file
> has any real advantages over keeping them as separate files. Having
> everything in one place is nice, of course, and being able to copy just
> one file around might be convenient, but it _does_ make the config file
> more complicated.
And it _does_ make finding the information for less savvy git users more
easy.
I'm not 100% convinced, either, but it could be a better concept than
different files in different places and different formats basically doing
the same.
But my thinking went like this: if Pasky and Junio can not agree on one
location and format, and therefore none of the two is deprecated, how
about giving them a way out they both might be able to agree to?
Ciao,
Dscho
P.S.: Anybody noticed that I did not use 0xb4 in five days?
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Andreas Ericsson @ 2005-11-20 19:16 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511201103280.13959@g5.osdl.org>
Linus Torvalds wrote:
>
> I'd rather have just _pure_ braces, but while that is natural to
> programmers, it's not very natural to most users, I think.
>
Sysadmins should be used to braces too (xinetd, dhcpd, named...).
How many office clerks do you expect to use git?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Linus Torvalds @ 2005-11-20 19:07 UTC (permalink / raw)
To: skimo; +Cc: Johannes Schindelin, git
In-Reply-To: <20051120182943.GG8383MdfPADPa@greensroom.kotnet.org>
On Sun, 20 Nov 2005, Sven Verdoolaege wrote:
>
> Not sure if this falls in the ".ini-file-like" category, but
> YAML (www.yaml.org) does nesting based on indentation.
The main reason I don't like indentation is that it tends to have strange
rules for "tab". Some people (incorrectly, of course) think that tabs are
not at fixed 8-byte things, so deciding the indentation of a tab often
ends up either disallowing tabs altogether (bad) or having other strange
rules (disallowing spaces).
So I'm not religiously opposed to it, but I find it to be less than
optimal.
I'd rather have just _pure_ braces, but while that is natural to
programmers, it's not very natural to most users, I think.
Linus
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Sven Verdoolaege @ 2005-11-20 18:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0511200935081.13959@g5.osdl.org>
On Sun, Nov 20, 2005 at 10:09:50AM -0800, Linus Torvalds wrote:
> and that would result in a parse of
>
> core.values.fixed = true
> core.values.nested = fine
> core.values.example.test = Hell yes
> core.other.example = strange
> core.name = hi
> secontion.example = yet another
>
[..]
> I dunno. That seems a nice extension, and it would make these things
> very unambiguous. But how do other .ini-file-like things do this?
Not sure if this falls in the ".ini-file-like" category, but
YAML (www.yaml.org) does nesting based on indentation.
Your example would look like
core:
values:
fixed: true
nested: fine
example:
test: Hell yes
other:
example: strange
name: hi
secontion:
example: yet another
or
core:
values: { fixed: true, nested: fine, example: { test: Hell yes } }
other: { example: strange }
name: hi
secontion: { example: 'yet another' }
skimo
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: H. Peter Anvin @ 2005-11-20 18:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kay Sievers, Ismail Donmez, git
In-Reply-To: <Pine.LNX.4.63.0511190101590.28126@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 18 Nov 2005, Kay Sievers wrote:
>
>
>>Yes, convince the git maintainers, that it's incredibly stupid not to
>>enforce utf8 in commit messages. It makes absolutely zero sense in a
>>SCM, which merges forth and back between people around the world to
>>allow random encodings from the last century.
>
>
> Oh, but it makes sense! Just because you happen to work on a very
> international project does not mean everybody does.
>
> Just because you happen to like utf-8 does not mean that you still do in
> 2046. The encoding-du-jour might well be a 64-bit wide char code by then,
> since they'll laugh about our dreaming about terabytes.
>
> BTW, utf-8 was designed on purpose to be easily distinguishable from other
> encodings so that you don't have to rely on every document obeying a
> certain encoding.
>
No, it wasn't. It was designated on purpose to be ASCII-compatible,
substring-safe, and minimally stateful.
Furthermore, it's extensible. Although the original UTF-8 is limited to
31 bits, and the officially published UTF-8 is further crippled to 21
bits by Mirco$oft cronies who wanted it to be brainfuck-compatible with
UTF-16, it could easily be extended to 64 bits or beyond.
I think it's *definitely* safe to say that whatever encoding we'll use
in 2046, current UTF-8 will be a subset. If you don't believe me,
consider how long we've had ASCII and the first of the design criteria
for UTF-8 that I listed in the first paragraph.
-hpa
^ permalink raw reply
* Re: Diffs "from" working directory
From: Linus Torvalds @ 2005-11-20 18:13 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Blaisorblade, Chuck Lever, Catalin Marinas, git
In-Reply-To: <20051120174359.GA24177@fieldses.org>
On Sun, 20 Nov 2005, J. Bruce Fields wrote:
>
> That's a diff *to* the working directory. My complaint was that there
> wasn't a convenient way to get a diff *from* the working directory.
Something like
git diff -R -M -p
should do it, no?
("git diff" has the strange property that if you give it any diff flags at
all, it forgets all the default ones. So it defaults to "-M -p", but if
you just say "-R", it will drop its own defaults, and use _just_ "-R").
[ Which is almost certainly not what most users want, but it's practical
when you want to get the internal git format. Whether that is important
enough to confuse users or not, I dunno ]
Linus
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Linus Torvalds @ 2005-11-20 18:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511201748440.14258@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, 20 Nov 2005, Johannes Schindelin wrote:
>
> I just had a crazy idea. Since we have a framework in place to read/write
> .git/config, I thought that maybe it would be a nice thing to move the
> information which is in .git/branches or .git/remotes into the config.
I considered it, but thee thing is, it really wants "nested names", ie
having multi-level base-names for the variables. At the same time, I
absolutely _abhor_ horrible crap like XML, which make nesting a
fundamental part of their structure.
XML may be "logical", but it has absolutely zero to do with being
human-readable and clean. In short, XML is total and absolute CRAP (in
fact, the "X" in "XML" stands for "Crap", but the XML designers were also
incredibly bad spellers).
So while the basic notion of the git ini file does support nesting (we
could just make variable names be "base.level1.final" or any number of
levels deep), I don't know what a sane format would be. I have one
suggestion that in my opinion "fits" the .ini file syntax (see below), but
people may well hate it.
Basically I've considered saying that one or more '.' characters at the
start of a section name would mean "re-use the previous one", so we could
have (this is a really bad example, just to show the implications):
[core]
[.values]
fixed = true
nested = fine
[..example]
test = Hell yes
[.other]
example = strange
[.]
name = hi
[section]
example = yet another
and that would result in a parse of
core.values.fixed = true
core.values.nested = fine
core.values.example.test = Hell yes
core.other.example = strange
core.name = hi
secontion.example = yet another
and that seems reasonably clean. I'd also allow explicit
multi-level section names:
[core.values]
fixed = true
so you could always write the above config file in an alternate format:
[core.values] fixed = true
[core.values] nested = fine
[core.values.example] test = Hell yes
[core.other] example = strange
[core] name = hi
[section] example = yet another
instead, using no implicit nesting at all (or, indeed, even re-using
sections like "core.values").
That would allow things like
[branches]
[.origin]
url = master.kernel.org:/pub/scm/git/git.git
pull = master:origin
[.mine]
url = my.domain.com:/other/repo
pull = master:mine
(which could also be written as
[branches.origin]
url = master.kernel.org:/pub/scm/git/git.git
pull = master:origin
[branches.mine]
url = my.domain.com:/other/repo
pull = master:mine
and the following mixed-indentation usage would be technically correct,
but perhaps crazy:
[branches.origin]
url = master.kernel.org:/pub/scm/git/git.git
pull = master:origin
[.mine]
url = my.domain.com:/other/repo
pull = master:mine
Basically, right now we only allow alphanumeric characters in the base
name, and a new section name completely clears the old one. The above
would be a very simple extension of that: we would allow '.' in addition
to alphanumerics, and any initial '.' characters would _keep_ that many
levels of the old name.
I dunno. That seems a nice extension, and it would make these things
very unambiguous. But how do other .ini-file-like things do this?
And I'm not 100% convinced that putting these branches in the config file
has any real advantages over keeping them as separate files. Having
everything in one place is nice, of course, and being able to copy just
one file around might be convenient, but it _does_ make the config file
more complicated.
Anyway, if you want to play with this, here's a trivial patch that may or
may not work.
Linus
----
diff --git a/config.c b/config.c
index 915bb97..3b9f300 100644
--- a/config.c
+++ b/config.c
@@ -136,6 +136,19 @@ static int get_base_var(char *name)
return -1;
if (c == ']')
return baselen;
+ if (c == '.') {
+ if (!baselen || name[baselen-1] == '.') {
+ for (;;) {
+ if (!name[baselen])
+ return -1;
+ if (name[baselen++] == '.')
+ break;
+ }
+ continue;
+ }
+ name[baselen++] = c;
+ continue;
+ }
if (!isalnum(c))
return -1;
if (baselen > MAXNAME / 2)
^ permalink raw reply related
* Re: [PATCH] merge-one-file: remove empty directories
From: H. Peter Anvin @ 2005-11-20 18:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Christoph Hellwig, Paul Mackerras, linuxppc64-dev,
Git Mailing List, Fredrik Kuivinen
In-Reply-To: <Pine.LNX.4.64.0511200901450.13959@g5.osdl.org>
Linus Torvalds wrote:
>
> Even VMS seems to have it (although if git is ever ported to VMS, I'll
> just have to shoot myself. I used VMS in -88, and the scars are _still_
> fresh).
>
Yeah, well, WinNT is basically the successor to VMS. (I have heard from
several ex-DECers that WNT was done on top of a stolen copy of what was
supposed-to-have-been the successor to VMS.)
-hpa
^ permalink raw reply
* Re: Diffs "from" working directory
From: J. Bruce Fields @ 2005-11-20 17:43 UTC (permalink / raw)
To: Blaisorblade; +Cc: Chuck Lever, Catalin Marinas, git
In-Reply-To: <200511201817.15780.blaisorblade@yahoo.it>
On Sun, Nov 20, 2005 at 06:17:15PM +0100, Blaisorblade wrote:
> I've given a look at commit fcc1ad70be5ff89996358b6d770cd229fec2a3ba, and
> while it may or may not be the right thing to do, there's a misunderstanding
> at the base.
What misunderstanding? Could you quote it?
> For instance, in the stg tree, before that patch, I can do:
>
> $ echo ciao >> README
> $ stg diff -r HEAD:
> $ stg diff -r HEAD
> diff --git a/README b/README
> index 184ded8..adb3970 100644
> --- a/README
> +++ b/README
> @@ -12,3 +12,4 @@ StGIT commands.
>
> For the latest version see http://www.procode.org/stgit/
> For a tutorial see http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT_Tutorial
> +ciao
That's a diff *to* the working directory. My complaint was that there
wasn't a convenient way to get a diff *from* the working directory.
It's nice to have a convenient shorthand for the current working
directory, and since there's already a shorthand for the HEAD ("HEAD")
it seemed more sensible to make "" the current working directory.
It's a minor point, but it seems convenient.
--b.
^ permalink raw reply
* Re: [PATCH] merge-one-file: remove empty directories
From: Linus Torvalds @ 2005-11-20 17:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Fredrik Kuivinen, linuxppc64-dev, Paul Mackerras,
Git Mailing List
In-Reply-To: <7v4q683qhe.fsf@assigned-by-dhcp.cox.net>
On Sat, 19 Nov 2005, Junio C Hamano wrote:
>
> [jc: We probably could use "rmdir -p", but for now we do that by
> hand for portability.]
Some googling seems to imply that "-p" is pretty much globally available.
It's in POSIX.1, but more importantly, it seems to actually be actively
used in BSD projects, and I found a man-page with copyright date in -92
(SCO of all places) which mentiones AT&T SVID2 - but not the more modern
standards.
Even VMS seems to have it (although if git is ever ported to VMS, I'll
just have to shoot myself. I used VMS in -88, and the scars are _still_
fresh).
Linus
^ permalink raw reply
* Get rid of .git/branches/ and .git/remotes/?
From: Johannes Schindelin @ 2005-11-20 17:00 UTC (permalink / raw)
To: git
Hi,
I just had a crazy idea. Since we have a framework in place to read/write
.git/config, I thought that maybe it would be a nice thing to move the
information which is in .git/branches or .git/remotes into the config.
Advantages:
- it would be easy to copy your private configuration by copying just one
file,
- it would be easy to add a switch to git-fetch/git-pull to actually
store/update the URL and head mapping under a certain nick,
- we could get rid of some parsing code, and
- it would arguably be more consistent.
Disadvantage:
- I know, I know, yet another change to the location of this
information...
- (very lame) you could not find out which nicks you have stored with "ls"
Comments?
Ciao,
Dscho
P.S.: I did not yet say anything about .git/info/, did I?
^ 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