* Re: [PATCH rev-list.c] max-count in terms of intersection
From: Luben Tuikov @ 2005-11-18 22:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x1dha6x.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > diff-tree 768b79de9eadc38a839332df0fcce021f7174d6d (from
> 2e67a5f449f4026097494569f871d79bf263ab28)
> > tree 6403fc730f8d5843043788f4c2f466727ba94bc0
> > parent 2e67a5f449f4026097494569f871d79bf263ab28
> > author Luben Tuikov <ltuikov@yahoo.com> 1132349344 -0500
> > committer Luben Tuikov <ltuikov@yahoo.com> 1132349344 -0500
> >
> > [PATCH rev-list.c] max-count in terms of intersection
> >
>
> Documentation/SubmittingPatches, perhaps?
Sorry, I just saw this document existed for GIT too.
Would you like me to resubmit?
> > When a path designation is given, max-count counts the number
> > of commits therein (intersection), not globally.
>
> This makes sense, but I wonder if the same logic applies to
> max_age as well. If we have clock-skewed commits that are
> skipped by the DENSE processing, we probably do not want them to
> be affecting what to do on the commits that matter.
As far as I understand it, I think max-age is fine the way
it is. After all, max-age depends on date/time which is
absolute (i.e. applies to commits in the whole set and in
the intersection just the same).
Luben
^ permalink raw reply
* [PATCH] Document the "ignore objects" feature of git-pack-redundant
From: Lukas Sandström @ 2005-11-18 22:20 UTC (permalink / raw)
To: git; +Cc: Lukas Sandström, Junio C Hamano
In-Reply-To: <437E530E.1020803@etek.chalmers.se>
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
Documentation/git-pack-redundant.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
applies-to: 5053091ee7d1f4b32b18a21f4b255cf1141cf72c
e417344dab21aca41fbc1f99d935ef033e53e3a8
diff --git a/Documentation/git-pack-redundant.txt b/Documentation/git-pack-redundant.txt
index 2e23cbc..9fe86ae 100644
--- a/Documentation/git-pack-redundant.txt
+++ b/Documentation/git-pack-redundant.txt
@@ -16,6 +16,14 @@ This program computes which packs in you
are redundant. The output is suitable for piping to
'xargs rm' if you are in the root of the repository.
+git-pack-redundant accepts a list of objects on standard input. Any objects
+given will be ignored when checking which packs are required. This makes the
+following command useful when wanting to remove packs which contain unreachable
+objects.
+
+git-fsck-objects --full --unreachable | cut -d ' ' -f3 | \
+git-pack-redundant --all | xargs rm
+
OPTIONS
-------
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH rev-list.c] max-count in terms of intersection
From: Junio C Hamano @ 2005-11-18 22:18 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20051118214722.4449.qmail@web31813.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> diff-tree 768b79de9eadc38a839332df0fcce021f7174d6d (from 2e67a5f449f4026097494569f871d79bf263ab28)
> tree 6403fc730f8d5843043788f4c2f466727ba94bc0
> parent 2e67a5f449f4026097494569f871d79bf263ab28
> author Luben Tuikov <ltuikov@yahoo.com> 1132349344 -0500
> committer Luben Tuikov <ltuikov@yahoo.com> 1132349344 -0500
>
> [PATCH rev-list.c] max-count in terms of intersection
>
Documentation/SubmittingPatches, perhaps?
> When a path designation is given, max-count counts the number
> of commits therein (intersection), not globally.
This makes sense, but I wonder if the same logic applies to
max_age as well. If we have clock-skewed commits that are
skipped by the DENSE processing, we probably do not want them to
be affecting what to do on the commits that matter.
^ permalink raw reply
* [PATCH] Make git-pack-redundant take a list of unimportant objs on stdin
From: Lukas Sandström @ 2005-11-18 22:17 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Lukas Sandström
This lets us do "git-fsck-objects --full --unreachable | cut -d ' ' -f3 |
git-pack-redundant --all", which will keep git-pack-redundant from keeping
packs just because they contain unreachable objects.
Also add some more --verbose output.
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
pack-redundant.c | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
applies-to: 3771756c044fa4338acc9f6acac3971f2309cc7c
4173f0c77793b13ad50d9c1a1ff5da32fec5e573
diff --git a/pack-redundant.c b/pack-redundant.c
index fb6cb48..f3097a1 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -579,6 +579,8 @@ int main(int argc, char **argv)
{
int i;
struct pack_list *min, *red, *pl;
+ struct llist *ignore;
+ char *sha1, buf[42]; /* 40 byte sha1 + \n + \0 */
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
@@ -621,6 +623,23 @@ int main(int argc, char **argv)
if (alt_odb)
scan_alt_odb_packs();
+ /* ignore objects given on stdin */
+ llist_init(&ignore);
+ if (!isatty(0)) {
+ while (fgets(buf, sizeof(buf), stdin)) {
+ sha1 = xmalloc(20);
+ if (get_sha1_hex(buf, sha1))
+ die("Bad sha1 on stdin: %s", buf);
+ llist_insert_sorted_unique(ignore, sha1, NULL);
+ }
+ }
+ llist_sorted_difference_inplace(all_objects, ignore);
+ pl = local_packs;
+ while (pl) {
+ llist_sorted_difference_inplace(pl->unique_objects, ignore);
+ pl = pl->next;
+ }
+
minimize(&min);
if (verbose) {
@@ -647,6 +666,8 @@ int main(int argc, char **argv)
pl->pack->pack_name);
pl = pl->next;
}
+ if (verbose)
+ fprintf(stderr, "%luMB of redundant packs in total.\n", pack_set_bytecount(red)/(1024*1024));
return 0;
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: Rss produced by git is not valid xml?
From: H. Peter Anvin @ 2005-11-18 22:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kay Sievers, Ismail Donmez, git
In-Reply-To: <Pine.LNX.4.64.0511181338460.13959@g5.osdl.org>
Linus Torvalds wrote:
>
> Want to do on-the-fly conversion on CVS import (or worse yet - something
> like clearcase)? With magic rules or fragile heuristics for binary files?
> That's crazy, and that's not how these things work. No, the way these
> things work is that they continue to be maintained in EUC-JP or whatever,
> and a tool that requires conversion is a tool that just doesn't get used.
>
On the fly conversion on CVS import isn't particularly crazy, as long as
it's under user control. Although I was primarly thinking about it in
the context of commit messages, it could be done on file contents as
well, since CVS has the ability to flag files as text or as binary
(-kb). We already have a bunch of options relating to how to map CVS
onto git, and conversion time is a good time to do it.
Similarly, it may not be a bad idea to add an *option* -- now when we
have a config file mechanism -- to signal error on invalid UTF-8 import.
This would keep a correct UTF-8 repository from getting inadvertently
messed up.
What *does* need to happen, I'm convinced, is that any tool that handles
email needs to be able to take the email and convert its character set
encodings (by default to UTF-8). Most MUAs today use all kinds of weird
heuristics for which character set to use, and it's frequently not what
the user expected.
-hpa
^ permalink raw reply
* Re: git fetch --tags doesn't quite do what I expect
From: Luck, Tony @ 2005-11-18 22:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tony Luck, git
In-Reply-To: <7v1x1diuuy.fsf@assigned-by-dhcp.cox.net>
On Fri, Nov 18, 2005 at 12:06:29PM -0800, Junio C Hamano wrote:
> I am not good at documenting things, so I'd appreciate if
> somebody paraphrased the above and send it back to me in a patch
> form to update the document ;-).
How about this:
[PATCH] Update pull/fetch --tags documentation
When fetching/pulling from a remote repository the "--tags" option
can be used to pull tags too. Document that it will limit the pull
to only commits reachable from the tags.
Signed-off-by: Tony Luck <tony.luck@intel.com>
---
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 0e502ae..a25d04a 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -8,7 +8,9 @@
-t, \--tags::
By default, the git core utilities will not fetch and store
tags under the same name as the remote repository; ask it
- to do so using `--tags`.
+ to do so using `--tags`. Using this option will bound the
+ list of objects pulled to the remote tags. Commits in branches
+ beyond the tags will be ignored.
-u, \--update-head-ok::
By default `git-fetch` refuses to update the head which
^ permalink raw reply related
* [PATCH] Fix a bug in get_all_permutations.
From: Lukas Sandström @ 2005-11-18 21:53 UTC (permalink / raw)
To: junkio; +Cc: Alex Riesen, git, Lukas Sandström
In-Reply-To: <437C819C.4040507@etek.chalmers.se>
This line was missing in the previous patch for some reason.
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
pack-redundant.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
applies-to: 5b820842ce0afb836ddbeded3a3f9e8d0ba223f9
e65d77b8ece9f6e463de0ceeaf6812a2df6d7d96
diff --git a/pack-redundant.c b/pack-redundant.c
index 3655609..3e3f33a 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -291,6 +291,7 @@ struct pll * get_all_permutations(struct
hint[0] = new_pll;
new_pll->next = NULL;
new_pll->pl = list;
+ new_pll->pl_size = 1;
return new_pll;
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: Rss produced by git is not valid xml?
From: Linus Torvalds @ 2005-11-18 21:48 UTC (permalink / raw)
To: Kay Sievers; +Cc: Ismail Donmez, git
In-Reply-To: <Pine.LNX.4.64.0511181314470.13959@g5.osdl.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1820 bytes --]
On Fri, 18 Nov 2005, Linus Torvalds wrote:
>
> And last I heard (if I remember correctly), Junio explicitly said that a
> lot of the people he works with still use shift-jis.
I should have dug it up. Apparently it's AUC-JP, not SJIS.
Anyway. I literally have _no_ idea what the difference between those
encodings are. I'm totally clueless when it comes to how the encodings
actually work etc. I wouldn't know a Japanese character if it painted
itself purple and did a risqué dance number.
But I do know just how slowly these conversions happen, and what a huge
deal it is for people who have documents and tools and databases that are
encoded in some particular encoding.
You do have to realize that while you may think that it's stupid that
people use a non-utf8 encoding, those very people don't actually see a
huge advantage from switching away from what has worked for them for
decades, and they _do_ see huge transition pains and costs.
So let's say that you have a project where the coding style includes S-JIS
or EUC-JP (of which there are multiple variations, I believe, just to make
things even more fun). You could argue that if such a project moves into
git, it should be converted to UTF-8 at that point. That's all fine and
dandy, but usually you don't do flag-days. You have people who start
tracking it in git, and maybe even developing it in git, but they still
have to work with the outside people.
Want to do on-the-fly conversion on CVS import (or worse yet - something
like clearcase)? With magic rules or fragile heuristics for binary files?
That's crazy, and that's not how these things work. No, the way these
things work is that they continue to be maintained in EUC-JP or whatever,
and a tool that requires conversion is a tool that just doesn't get used.
Linus
^ permalink raw reply
* [PATCH rev-list.c] max-count in terms of intersection
From: Luben Tuikov @ 2005-11-18 21:47 UTC (permalink / raw)
To: git
diff-tree 768b79de9eadc38a839332df0fcce021f7174d6d (from 2e67a5f449f4026097494569f871d79bf263ab28)
tree 6403fc730f8d5843043788f4c2f466727ba94bc0
parent 2e67a5f449f4026097494569f871d79bf263ab28
author Luben Tuikov <ltuikov@yahoo.com> 1132349344 -0500
committer Luben Tuikov <ltuikov@yahoo.com> 1132349344 -0500
[PATCH rev-list.c] max-count in terms of intersection
When a path designation is given, max-count counts the number
of commits therein (intersection), not globally.
This avoids the case where in case path has been inactive
for the last N commits, --max-count=N and path designation
at git-rev-list is given, would give no commits.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
diff --git a/rev-list.c b/rev-list.c
index 6e6ffde..e17f928 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -124,8 +124,6 @@ static int filter_commit(struct commit *
stop_traversal=1;
return CONTINUE;
}
- if (max_count != -1 && !max_count--)
- return STOP;
if (no_merges && (commit->parents && commit->parents->next))
return CONTINUE;
if (paths && dense) {
@@ -148,6 +146,9 @@ static int process_commit(struct commit
return CONTINUE;
}
+ if (max_count != -1 && !max_count--)
+ return STOP;
+
show_commit(commit);
return CONTINUE;
^ permalink raw reply related
* Re: Rss produced by git is not valid xml?
From: Ismail Donmez @ 2005-11-18 21:33 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511181314470.13959@g5.osdl.org>
On Friday 18 November 2005 23:30, you wrote:
> On Fri, 18 Nov 2005, Kay Sievers wrote:
> > Actually, the real bug is not to try to prevent binary nonsense in
> > textual commit logs, which are distibuted. Remember, that you provide a
> > SCM not a filesystem.
>
> I never said they were text, and in fact, I never even said I'm doing an
> SCM. Quite the reverse. I very much said that I'm doing a filesystem that
> is flexible.
>
> The fact that the headers are text-like is not so much about text as it is
> about flexibility and easy tool access. If you look at the git object
> format, for example, the header is strictly NUL-terminated ASCII, but the
> object itself is a pure binary data stream. Which obviously just _happens_
> to often be text too, since quite often the object contents is something
> like a C source file, but there's a real power to _not_ thinking that it
> means that files are text-files.
>
> And I like UTF-8, but the fact is, all my editors and mail tools are still
> Latin-1. My editor converts the UTF-8 input into latin1 and keeps it in
> that format on disk (it writes it to the _screen_ as UTF-1 just to make
> the glyphs come out right, but the file it works with is still latin1).
>
> Could I change? Yup, I could change pretty easily. I wrote the code that
> did the latin1 conversion, and I've got source for my tools, so I could
> just decide one day that I'll join the 21st century and switch. I just
> haven't done so yet.
>
> The fact that _I_ can't be bothered, even though I'm in just about the
> best possible situation (I've got a keyboard with åäö on it, but they're
> not in my name, so I don't use them that much) should tell you something.
> Namely, it should tell you that there's a _lot_ of people who have a much
> harder time than I do in changing their setups.
>
> I think most of Asia _still_ doesn't use utf-8. And I _guarantee_ you that
> it's a hell of a lot easier for you to complain about it and say "they
> should" than it is for them to actually do so and convert all the programs
> they use.
>
> On this mailing list, the only person that I've seen pipe up about these
> things in the past _and_ that I suspect actually has to work with this
> thing in real life (instead of just from a theoretical "this is how things
> should be done" standpoint) is Junio. And last I heard (if I remember
> correctly), Junio explicitly said that a lot of the people he works with
> still use shift-jis.
>
> And I'm not surprised. Look on the web. As far as I know, shift-jis is
> still much more common than utf-8.
>
> AND IT DOESN'T MATTER ONE WHIT WHEN SOME GEEK SAYS "THEY SHOULDN'T DO
> THAT, THEN"!
>
> Software should conform to people, not the other way around.
Linus,
I got your point. But the XML should reflect the data it contains. This _is_
my problem. Will the data be latin-1, OK then the xml should say its latin-1
and not lie as utf-8.
Regards,
ismail
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Linus Torvalds @ 2005-11-18 21:30 UTC (permalink / raw)
To: Kay Sievers; +Cc: Ismail Donmez, git
In-Reply-To: <20051118205513.GA3168@vrfy.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2625 bytes --]
On Fri, 18 Nov 2005, Kay Sievers wrote:
>
> Actually, the real bug is not to try to prevent binary nonsense in textual
> commit logs, which are distibuted. Remember, that you provide a SCM not a
> filesystem.
I never said they were text, and in fact, I never even said I'm doing an
SCM. Quite the reverse. I very much said that I'm doing a filesystem that
is flexible.
The fact that the headers are text-like is not so much about text as it is
about flexibility and easy tool access. If you look at the git object
format, for example, the header is strictly NUL-terminated ASCII, but the
object itself is a pure binary data stream. Which obviously just _happens_
to often be text too, since quite often the object contents is something
like a C source file, but there's a real power to _not_ thinking that it
means that files are text-files.
And I like UTF-8, but the fact is, all my editors and mail tools are still
Latin-1. My editor converts the UTF-8 input into latin1 and keeps it in
that format on disk (it writes it to the _screen_ as UTF-1 just to make
the glyphs come out right, but the file it works with is still latin1).
Could I change? Yup, I could change pretty easily. I wrote the code that
did the latin1 conversion, and I've got source for my tools, so I could
just decide one day that I'll join the 21st century and switch. I just
haven't done so yet.
The fact that _I_ can't be bothered, even though I'm in just about the
best possible situation (I've got a keyboard with åäö on it, but they're
not in my name, so I don't use them that much) should tell you something.
Namely, it should tell you that there's a _lot_ of people who have a much
harder time than I do in changing their setups.
I think most of Asia _still_ doesn't use utf-8. And I _guarantee_ you that
it's a hell of a lot easier for you to complain about it and say "they
should" than it is for them to actually do so and convert all the programs
they use.
On this mailing list, the only person that I've seen pipe up about these
things in the past _and_ that I suspect actually has to work with this
thing in real life (instead of just from a theoretical "this is how things
should be done" standpoint) is Junio. And last I heard (if I remember
correctly), Junio explicitly said that a lot of the people he works with
still use shift-jis.
And I'm not surprised. Look on the web. As far as I know, shift-jis is
still much more common than utf-8.
AND IT DOESN'T MATTER ONE WHIT WHEN SOME GEEK SAYS "THEY SHOULDN'T DO
THAT, THEN"!
Software should conform to people, not the other way around.
Linus
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Ismail Donmez @ 2005-11-18 21:29 UTC (permalink / raw)
To: git
In-Reply-To: <7v7jb5hcm2.fsf@assigned-by-dhcp.cox.net>
On Friday 18 November 2005 23:25, you wrote:
> Ismail Donmez <ismail@uludag.org.tr> writes:
> >> I agree that UTF-8 is a good idea, but that's a totally different
> >> argument.
> >
> > Maybe you could officially require all commit messages to be UTF-8 then
> > the problem would be just solved for future commits at least. Until then
> > it should be workarounded in gitweb I guess.
>
> No, that's something I will *not* do.
>
> Linus is right --- he is always right but he is slightly more
> right than he usually is in this particular case ;-).
>
> We allow any 8-bit data in commit log messages. We even make it
> easier to use utf-8 than other encodings, and we encourage use
> of utf-8 for obvious reasons. But we do not go further than
> that. Any patch to change commit-tree.c to reject binary data
> in a commit log message that utf-8 validator chokes at *will* be
> rejected.
>
> Go back to the list archive. Dig out messages on this topic.
> Summarize the ones that say why we encourage utf-8 in textual
> commit log messages, submit a patch to add that to
> Documentation/howto/ or perhaps Documentation/tutorial.txt, to
> further encourage people to use utf-8. Just do not forbid non
> utf-8 text nor binary data in general.
Your produced XML is NOT valid then. You put encoding=utf-8 and then put
latin-1 encoded data in it. You SHOULD NOT do that. Either put latin-1 as
encoding in the RSS because you say its the way data should be else encode
non-utf stuff to be utf-8.
Regards,
ismail
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Junio C Hamano @ 2005-11-18 21:25 UTC (permalink / raw)
To: Ismail Donmez; +Cc: git
In-Reply-To: <200511182245.01713.ismail@uludag.org.tr>
Ismail Donmez <ismail@uludag.org.tr> writes:
>> I agree that UTF-8 is a good idea, but that's a totally different
>> argument.
>
> Maybe you could officially require all commit messages to be UTF-8 then the
> problem would be just solved for future commits at least. Until then it
> should be workarounded in gitweb I guess.
No, that's something I will *not* do.
Linus is right --- he is always right but he is slightly more
right than he usually is in this particular case ;-).
We allow any 8-bit data in commit log messages. We even make it
easier to use utf-8 than other encodings, and we encourage use
of utf-8 for obvious reasons. But we do not go further than
that. Any patch to change commit-tree.c to reject binary data
in a commit log message that utf-8 validator chokes at *will* be
rejected.
Go back to the list archive. Dig out messages on this topic.
Summarize the ones that say why we encourage utf-8 in textual
commit log messages, submit a patch to add that to
Documentation/howto/ or perhaps Documentation/tutorial.txt, to
further encourage people to use utf-8. Just do not forbid non
utf-8 text nor binary data in general.
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Ismail Donmez @ 2005-11-18 21:22 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511181301320.13959@g5.osdl.org>
On Friday 18 November 2005 23:13, you wrote:
> On Fri, 18 Nov 2005, Ismail Donmez wrote:
> > Maybe you could officially require all commit messages to be UTF-8 then
> > the problem would be just solved for future commits at least.
>
> Just think about what that would mean for a second.
>
> What do people put in commit messages? They put things like filenames, to
> indicate that they changed file so-and-so because of issue so-and-so, or
> they needed to include header file so-and-so to fix a problem.
>
> So by virtue of forcing all commit messages to be in UTF-8, you've
> suddenly forced all filesystems to do UTF-8 too.
>
> Take that one step further: you've also forced all the file _contents_
> you talk about to be in UTF-8, since the commit message might quote part
> of the file ("'xyzzy' was misspelled, it should be 'abcde'").
>
> Or alternatively, you've forced the commit message to no longer match the
> reality that it tries to explain.
>
> See the problem?
>
> And that's ignoring the fact that you've unilaterally forced probably 50%
> of asian users to use an environment that they don't normally use.
>
> Remember: it's actually pretty _easy_ for most of the western world to
> move to UTF-8, because 99% of what we do doesn't really care one whit, and
> the remaining 1% isn't usually even a huge problem (ie it's such a small
> percentage that even if you show the wrong character for it, people
> understand what it said).
These days you can just open kwrite, select encoding and voila you don't have
to change anything on the filesystem you can still use whatever $LANG you
use. We would just force them to use a working editor imho. Nothing else. And
thats not much to ask is it? Even joe(1) can edit utf-8 these days that must
tell something.
Regards,
ismail
^ permalink raw reply
* Re: [PATCH] Remove all old packfiles when doing "git repack -a -d"
From: Junio C Hamano @ 2005-11-18 21:15 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git
In-Reply-To: <437E3B3C.9000409@etek.chalmers.se>
Lukas Sandström <lukass@etek.chalmers.se> writes:
> No point in running git-pack-redundant if we already know
> which packs are redundant.
>
> Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
This makes sense and makes me feel safer somehow. Thanks.
^ permalink raw reply
* Re: [PATCH 5/5] git-daemon support for user-relative paths.
From: Junio C Hamano @ 2005-11-18 21:13 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <437DAA66.6070301@op5.se>
Andreas Ericsson <ae@op5.se> writes:
>>>-static int upload(char *dir)
>>>-{
>>>- /* Try paths in this order */
>>>- static const char *paths[] = { "%s", "%s/.git", "%s.git", "%s.git/.git", NULL };
>
>...
>
>> Under strict-path, I think not doing any DWIM like this is fine,
>> but otherwise I suspect changing this would break existing
>> remotes/origin file people may have. In addition enter_repo()
>> as posted does its own DWIM to chdir to ".git" unconditionally
>> as I pointed out...
>
> DWIM? That's an acronym I don't know.
"Do what I mean". It lets users say:
git clone git://sample.xz/pub/uemacs uemacs
when the repository on the server side is at any of the
following places:
/pub/uemacs
-- a regular naked repository, with subdirectories
/pub/uemacs/refs and /pub/uemacs/objects/, obviously.
/pub/uemacs/.git
-- /pub/uemacs is an ordinary repository with possibly a
working tree; has /pub/uemacs/.git/refs and friends.
/pub/uemacs.git
-- when above two do not exist but this does; a regular
naked repository, with subdirectories
/pub/uemacs.git/refs and friends.
/pub/uemacs.git/.git
-- no /pub/uemacs, and /pub/uemacs.git is an ordinary
repository with possibly a working tree; has
/pub/uemacs.git/.git/refs and friends.
which is a nice feature, but under --strict-path we need to be
careful that we apply whitelist correctly while allowing DWIM.
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Linus Torvalds @ 2005-11-18 21:13 UTC (permalink / raw)
To: Ismail Donmez; +Cc: git
In-Reply-To: <200511182245.01713.ismail@uludag.org.tr>
On Fri, 18 Nov 2005, Ismail Donmez wrote:
>
> Maybe you could officially require all commit messages to be UTF-8 then the
> problem would be just solved for future commits at least.
Just think about what that would mean for a second.
What do people put in commit messages? They put things like filenames, to
indicate that they changed file so-and-so because of issue so-and-so, or
they needed to include header file so-and-so to fix a problem.
So by virtue of forcing all commit messages to be in UTF-8, you've
suddenly forced all filesystems to do UTF-8 too.
Take that one step further: you've also forced all the file _contents_
you talk about to be in UTF-8, since the commit message might quote part
of the file ("'xyzzy' was misspelled, it should be 'abcde'").
Or alternatively, you've forced the commit message to no longer match the
reality that it tries to explain.
See the problem?
And that's ignoring the fact that you've unilaterally forced probably 50%
of asian users to use an environment that they don't normally use.
Remember: it's actually pretty _easy_ for most of the western world to
move to UTF-8, because 99% of what we do doesn't really care one whit, and
the remaining 1% isn't usually even a huge problem (ie it's such a small
percentage that even if you show the wrong character for it, people
understand what it said).
There's only one thing that is easier still: to force your way of working
on others.
This is why I'm so steadfast on it being just a stream of bytes. Because
let's face it, no english-speaking project will ever _really_ care: we'll
get a few peoples names wrong, but it's all going to be pretty irrelevant,
and there's not going to be any real confusion.
In contrast, _forcing_ people to use UTF-8 results in real problems, and
really limits what can be done.
A data stream of 8-bit bytes is really powerful. And oh, btw, it just
happens to be the UNIX way.
Linus
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Kay Sievers @ 2005-11-18 21:01 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511182151.56161.Josef.Weidendorfer@gmx.de>
On Fri, Nov 18, 2005 at 09:51:56PM +0100, Josef Weidendorfer wrote:
> On Friday 18 November 2005 21:28, H. Peter Anvin wrote:
> > I think the point is: what do you do with the data? If it *looks* like
> > valid UTF-8, you pretty much have to assume it is; if it's not (it
> > contains invalid UTF-8 sequences), what do you do? There are only a
> > small handful of alternatives, and none are really good:
> >
> > - Reject it (it's kind of too late, should have been done at
> > checkin)
> > - Show them as SUBSTITUTE characters (U+FFFD).
> > - Show them as Latin-1 or Windows-1252
> > - Provide a complex configuration mechanism
> >
> > I think Kay is going with the second option.
>
> In the case of the Linux kernel, UTF-8 of course is the
> way to go. As you can not reject already commited objects, the second
> option seems the best way.
>
> But I think it would be better to have a config option specifying the
> prefered encoding for commit comments in a project. Something like
>
> core.commit-encoding = Latin-1
>
> gitweb should use this.
Sorry, the 90's are over. Patch it, if you need it, I will not make it happen.
Kay
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: H. Peter Anvin @ 2005-11-18 20:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ismail Donmez, git
In-Reply-To: <Pine.LNX.4.64.0511181237040.13959@g5.osdl.org>
Linus Torvalds wrote:
>
> Which is a fine option. Latin-1 is probably the right choice for the
> kernel, but not necessarily for other projects.
>
> Another option is to just pass them through unmodified, and encourage the
> XML parser to handle it. Anything that takes UTF-8 and doesn't have some
> fallback to handle malformed input is basically buggy. It simply _will_
> happen occasionally, quite independently of git. You can either give up,
> or try to handle it. And giving up is always the wrong choice.
>
Not necessarily. If you can't guarantee that you won't do something
that's bad for security, giving up is the only valid choice.
The problem, of course, comes into place when people write generic XML
parsers -- or, for that matter, UTF-8 decoders -- and don't know what
will happen to the data downstream. Trying to make invalid data valid
has the same problems as DWIM (after all, it *is* DWIM): if done on the
wrong side of a security barrier it has unpredictable consequences.
Thus, making gitweb -- a producer application -- do the guessing is
probably the right thing.
Sorry, Mr. Protocol; in this malware-infested world the old adage "be
liberal in what you accept, conservative in what you send" unfortunately
has had to be modified.
-hpa
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Kay Sievers @ 2005-11-18 20:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ismail Donmez, git
In-Reply-To: <Pine.LNX.4.64.0511181220350.13959@g5.osdl.org>
On Fri, Nov 18, 2005 at 12:22:34PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 18 Nov 2005, Ismail Donmez wrote:
> >
> > > And git guys, please start to think again about your insane options,
> > > that cause more harm than anything good.
> >
> > Can git maintainer(s) comment on this please?
>
> It's easy to say "just do the right thing", and ignore reality.
Well the reality tells that everything that is successful does not give
too many options that harm adoption. For me it's a very simple and "real"
rule.
It's all about a sane default, which git obviously doesn't have. You
guys may look at it from the very low level, but that isn't what I call
"reality".
> git commit logs have always been "8-bit data". It's actually gitweb that
> is buggy if it claims it is UTF-8 without checking or converting it to
> such.
Actually, the real bug is not to try to prevent binary nonsense in textual
commit logs, which are distibuted. Remember, that you provide a SCM not a
filesystem.
> I agree that UTF-8 is a good idea, but that's a totally different
> argument.
Well, I don't see real arguments against sane a default.
Thanks,
Kay
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Josef Weidendorfer @ 2005-11-18 20:51 UTC (permalink / raw)
To: git
In-Reply-To: <437E3971.3060803@zytor.com>
On Friday 18 November 2005 21:28, H. Peter Anvin wrote:
> I think the point is: what do you do with the data? If it *looks* like
> valid UTF-8, you pretty much have to assume it is; if it's not (it
> contains invalid UTF-8 sequences), what do you do? There are only a
> small handful of alternatives, and none are really good:
>
> - Reject it (it's kind of too late, should have been done at
> checkin)
> - Show them as SUBSTITUTE characters (U+FFFD).
> - Show them as Latin-1 or Windows-1252
> - Provide a complex configuration mechanism
>
> I think Kay is going with the second option.
In the case of the Linux kernel, UTF-8 of course is the
way to go. As you can not reject already commited objects, the second
option seems the best way.
But I think it would be better to have a config option specifying the
prefered encoding for commit comments in a project. Something like
core.commit-encoding = Latin-1
gitweb should use this.
Josef
>
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Linus Torvalds @ 2005-11-18 20:47 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Ismail Donmez, git
In-Reply-To: <437E3971.3060803@zytor.com>
On Fri, 18 Nov 2005, H. Peter Anvin wrote:
>
> I think the point is: what do you do with the data? If it *looks* like valid
> UTF-8, you pretty much have to assume it is; if it's not (it contains invalid
> UTF-8 sequences), what do you do?
Btw, this is not a new issue.
This is true even of data that _claims_ to be UTF-8 but contains sequences
that are illegal. A program that just barfs on it is a buggy program.
And yes, I know there are buggy programs out there. I seem to recall some
perl(?) problems when it got UTF-8 strings that weren't, and did
impossible things.
> There are only a small handful of alternatives, and none are really good:
>
> - Reject it (it's kind of too late, should have been done at
> checkin)
It can't be done at checkin, since it's not _wrong_. It's 8-bit data.
It's like saying that /bin/echo is an illegal program and shouldn't be
executed, because it's not encoded in utf-8.
I can well imagine somebody wanting to put a binary signature at the end
of a commit. git shouldn't care, and the important thing to realize is
that there _is_ no "encoding" for such things. So the commits don't
necessarily have to have a font encoding at all, and any visualization
tool should just accept that fact.
> - Show them as SUBSTITUTE characters (U+FFFD).
> - Show them as Latin-1 or Windows-1252
> - Provide a complex configuration mechanism
>
> I think Kay is going with the second option.
Which is a fine option. Latin-1 is probably the right choice for the
kernel, but not necessarily for other projects.
Another option is to just pass them through unmodified, and encourage the
XML parser to handle it. Anything that takes UTF-8 and doesn't have some
fallback to handle malformed input is basically buggy. It simply _will_
happen occasionally, quite independently of git. You can either give up,
or try to handle it. And giving up is always the wrong choice.
Linus
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Ismail Donmez @ 2005-11-18 20:45 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511181220350.13959@g5.osdl.org>
On Friday 18 November 2005 22:22, you wrote:
> On Fri, 18 Nov 2005, Ismail Donmez wrote:
> > > And git guys, please start to think again about your insane options,
> > > that cause more harm than anything good.
> >
> > Can git maintainer(s) comment on this please?
>
> It's easy to say "just do the right thing", and ignore reality.
>
> git commit logs have always been "8-bit data". It's actually gitweb that
> is buggy if it claims it is UTF-8 without checking or converting it to
> such.
>
> I agree that UTF-8 is a good idea, but that's a totally different
> argument.
Maybe you could officially require all commit messages to be UTF-8 then the
problem would be just solved for future commits at least. Until then it
should be workarounded in gitweb I guess.
Regards
ismail
^ permalink raw reply
* Re: [PATCH 5/5] git-daemon support for user-relative paths.
From: H. Peter Anvin @ 2005-11-18 20:41 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <437DAA66.6070301@op5.se>
Andreas Ericsson wrote:
>
> It's already there but in a different format. Adding "if (!strict)" to
> the previously unconditional 'chdir(".git");' won't change that.
>
> Like I said, I made sure everything that worked before works now too.
>
>> Under strict-path, I think not doing any DWIM like this is fine,
>> but otherwise I suspect changing this would break existing
>> remotes/origin file people may have. In addition enter_repo()
>> as posted does its own DWIM to chdir to ".git" unconditionally
>> as I pointed out...
>
> DWIM? That's an acronym I don't know.
>
DWIM = "Do What I Mean", i.e. program trying to be clever. A (usually)
good thing for usability, a very bad thing for security.
In particular, DWIM is bad for security when you have a flow like:
user input -> security check -> DWIM
... which lets the user subvert the security check by knowing how the
DWIM will mangle the input. What's worse, programmers like yourself
frequently say "oh, it's okay, though, I know what the DWIM does and it
can't break the security checks I do."
Well, then someone comes along and changes either the security checks
(e.g. add a blacklist), or the DWIM, or both. Security hole opens.
Therefore, the flow must *ALWAYS* be:
user input -> DWIM -> security check
Your patch re-introduces the incorrect flow.
-hpa
^ permalink raw reply
* Re: [ANNOUNCE] gitfs pre-release 0.03
From: Mitchell Blank Jr @ 2005-11-18 20:50 UTC (permalink / raw)
To: Paolo Teti; +Cc: git
In-Reply-To: <34a7ae040511180620v5f6ac014g@mail.gmail.com>
Paolo Teti wrote:
> A question: the gitFS in your intent has to became a "clone" of the
> Rational MultiVersion File System?
Well, I guess I can't give a real solid answer since I've never used
Rational and I'm only vaguely aware of its capabilities. However I think
the answer is "no". My personal belief is that the filesystem abstraction
isn't a good fit to be the main interface to an SCM, especially git.
That's why I'm currently working on just visualizing the contents of the
git repository and I'll add features on top of that as they seem to make
sense.
-Mitch
^ 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