* [PATCH] send-email: let sanitize_address_rfc822 do rfc2047 quoting
From: Uwe Kleine-König @ 2007-08-05 20:09 UTC (permalink / raw)
To: git; +Cc: Uwe Kleine-König
Without this patch I'm not able to properly send emails as I have a
non-ascii character in my name.
The former version tried to fix-up the real name part with double quotes
if it includes a '.'. I removed this as rfc2047 can handle a dot, too.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
---
Hello,
I already sent a similar patch that was discussed a bit[1], but was not taken.
The list of allowed character was taken from Python's email package.
Comparing with the former version I removed the quoting as described in
the 2nd paragraph of the log and now I only test $recipient_name once.
I will try to send this patch with next + this patch. I think it should
work in principle, but --suppress-from is not honored. I will take a
look on this issue later.
Best regards
Uwe
[1] http://thread.gmane.org/gmane.comp.version-control.git/52093
git-send-email.perl | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index f43f92f..5785e29 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -459,16 +459,27 @@ sub unquote_rfc2047 {
return "$_";
}
-# If an address contains a . in the name portion, the name must be quoted.
+# The name part of an address must consist only of alnum chars, space and a few
+# others.
+# If it contains a "forbidden" char in the name port, quote it according to
+# rfc2047.
sub sanitize_address_rfc822
{
my ($recipient) = @_;
- my ($recipient_name) = ($recipient =~ /^(.*?)\s+</);
- if ($recipient_name && $recipient_name =~ /\./ && $recipient_name !~ /^".*"$/) {
- my ($name, $addr) = ($recipient =~ /^(.*?)(\s+<.*)/);
- $recipient = "\"$name\"$addr";
+ my ($recipient_name, $recipient_addr) = ($recipient =~ /^(.*?)(\s+<.*)/);
+
+ if ($recipient_name) {
+ if ($recipient_name =~ /[^-a-zA-Z0-9!*+\/ ]/ && $recipient_name !~ /=\?utf-8\?q?.*\?=/) {
+ $recipient_name =~ s/([^-a-zA-Z0-9!*+\/ ])/sprintf("=%02X", ord($1))/eg;
+ $recipient_name =~ s/ /_/;
+ $recipient_name =~ s/(.*)/=\?utf-8\?q\?$1\?=/;
+ }
+
+ return "$recipient_name$recipient_addr";
+
+ } else {
+ return "$recipient";
}
- return $recipient;
}
sub send_message
--
1.5.3.rc3.13.g7ab3
^ permalink raw reply related
* Re: way to automatically add untracked files?
From: Steffen Prohaska @ 2007-08-05 20:04 UTC (permalink / raw)
To: Theodore Tso; +Cc: Johan Herland, git, Shawn O. Pearce, Miles Bader
In-Reply-To: <20070805161117.GE28263@thunk.org>
On Aug 5, 2007, at 6:11 PM, Theodore Tso wrote:
> On Sun, Aug 05, 2007 at 02:11:24PM +0200, Johan Herland wrote:
>> $ hg addremove --help
>> hg addremove [OPTION]... [FILE]...
>>
>> add all new files, delete all missing files
>>
>> Add all new files and remove all missing files from the
>> repository.
>>
>> New files are ignored if they match any of the patterns
>> in .hgignore. As
>> with add, these changes take effect at the next commit.
>>
>> Adding a git-addremove command should not be much work, and it
>> would be a
>> lot friendlier to people whose workflow is more aligned with #2
>> than #1.
>
> Not much work at all:
>
> # git config --system --add alias.addremove "git add . ; git add -u"
But how can I handle the [FILE]... from above?
Steffen
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Matthieu Moy @ 2007-08-05 19:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Steven Grimm, Jean-Francois Veillette, git
In-Reply-To: <Pine.LNX.4.64.0708052044570.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I don't know whether it was a typo, but we're not talking about
>> "commit", but "status".
>
> No typo. "git status" is literally "git commit --dry-run". Why? Because
> people expected it to be called "git status".
>
> And even if I think about it over and over again, it makes sense.
I was surprised of that when looking at the source, but yes, it makes
sense.
But the message I was replying to claimed that
"git status-or-commit -a" _needed_ to put objects in the object
database. That's true of "git commit -a" but not of "git status -a",
even if you call it "git commit --dry-run -a", precisely because of
the --dry-run thing.
--
Matthieu
^ permalink raw reply
* Re: How to figure out what 'git push' would do?
From: Steffen Prohaska @ 2007-08-05 19:56 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20070805173340.GA3159@steel.home>
On Aug 5, 2007, at 7:33 PM, Alex Riesen wrote:
> Steffen Prohaska, Sun, Aug 05, 2007 13:37:34 +0200:
>> How can I check what a 'git push' would do, without
>> actually doing it?
>>
>> Is there something like 'git push --dry-run', similar
>> to 'rsync --dry-run'?
>
> No. It is often safe to just do git-push, unless you have naive
> developers doing pull every time some ref in your shared repo changes
> *and* expecting the result to compile (typical for CVS way of work).
> git-push will not overwrite anything, it always only forwards history.
>
> For the case you really want to know what the changes on remote repo
> will be it is possible to fetch them into the local repo first and
> compare with what you will push:
>
> $ git fetch git://remote/path/REPO master:refs/remotes/REPO/master
> $ gitk local..REPO/master
>
> It gives you all possible information, which may be worth that bit of
> work. Or, if you have all the remote configuration ready, it can be
> just:
>
> $ git fetch
> $ gitk local..REPO/master
>
That applies only for a single branch. If I prepared a couple of
branches for pushing and somehow want to double check what I prepared,
'git push --dry-run' would be quite handy. I know how to handle the
situation and could write a custom script that does all necessary
checks. But I haven't found an out-of-the-box solution for double
checking right before 'git push'
Steffen
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: Steffen Prohaska @ 2007-08-05 19:47 UTC (permalink / raw)
To: J. Bruce Fields, Junio C Hamano
Cc: Johannes Schindelin, Git Mailing List, David Kastrup
In-Reply-To: <85wswa6n1o.fsf@lola.goethe.zz>
On Aug 5, 2007, at 5:03 PM, David Kastrup wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> On Aug 5, 2007, at 3:58 PM, Johannes Schindelin wrote:
>>
>>> Hi,
>>>
>>> On Sun, 5 Aug 2007, Steffen Prohaska wrote:
>>>
>>>> git gui is especially useful because it allows to select diff
>>>> hunks.
>>>
>>> You should give a _big_ _fat_ _red_ warning there.
>>>
>>> If you selectively commit diff hunks, you _never_ tested what you
>>> committed.
>>>
>>> That is the reason we're not advertising git add -i more actively.
>>
>> Hmm... If you do 'git cherry-pick' or 'git rebase' you also did
>> not test what you committed. Should we advertise them less
>> actively as well?
>
> Selectively committing diff hunks also means that a subsequent rebase
> -i or git-cherry will have to reconsider the same commit as it has
> only been incompletely applied.
>
> So it can mean more work later. Also one would in general have to
> edit the commit message (if it describes everything that has been
> done).
>
> There are simply consequences for the workflow if you do things
> right. Whether they are worth a "big fat red warning" is one
> question, but mentioning them is probably not amiss.
I found it quite useful to be able to commit diff chunks selectively.
I started editing diffs as described in [1] but actually it turned
out to be easier for me to use git gui. I'm speaking unified diff
probably less fluently than Linus does.
My note about using git gui to select diff hunks is added to the
section 'Reordering or selecting from a patch series', which is in
my opinion the right section.
But apparently there's some dispute about usefulness of my comment on
cherry-picking. Maybe a separate section on rewriting changes would
be useful, which I do not have the time to start right now.
Junio, maybe you want to take only the first part of my patch?
Steffen
[1] http://thread.gmane.org/gmane.comp.version-control.git/46733
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Johannes Schindelin @ 2007-08-05 19:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, Steven Grimm, Jean-Francois Veillette, git
In-Reply-To: <vpqr6mhahtx.fsf@bauges.imag.fr>
Hi,
On Sun, 5 Aug 2007, Matthieu Moy wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> >
> >>> "git-status $args" on the other hand is a preview of "what would
> >>> happen if I say 'git-commit $args'", and in order to compute
> >>> that, you would fundamentally need to be able to write into the
> >>> object store. In a special case of giving empty $args it can be
> >>> read-only.
> >>
> >> Can you give an example where it _could_ not be read-only?
> >
> > Think of what "git commit -a" would have to do.
>
> I don't know whether it was a typo, but we're not talking about
> "commit", but "status".
No typo. "git status" is literally "git commit --dry-run". Why? Because
people expected it to be called "git status".
And even if I think about it over and over again, it makes sense.
Ciao,
Dscho
^ permalink raw reply
* Re: Problem with bisect
From: Thomas Glanzmann @ 2007-08-05 19:44 UTC (permalink / raw)
To: Larry Finger; +Cc: Sean, git
In-Reply-To: <46B623D6.7070809@lwfinger.net>
Hello,
> I'm using git version 1.4.4.2.g04509
1.4 has a issue with bisect at least the Debian 1.4 versio. Update to
1.5 and try again.
Thomas
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Matthieu Moy @ 2007-08-05 19:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: Steven Grimm, Jean-Francois Veillette, git, Johannes Schindelin
In-Reply-To: <7vlkcskx5z.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>>> "git-status $args" on the other hand is a preview of "what would
>>> happen if I say 'git-commit $args'", and in order to compute
>>> that, you would fundamentally need to be able to write into the
>>> object store. In a special case of giving empty $args it can be
>>> read-only.
>>
>> Can you give an example where it _could_ not be read-only?
>
> Think of what "git commit -a" would have to do.
I don't know whether it was a typo, but we're not talking about
"commit", but "status".
> It needs to hash and deposit a new object for blobs that have been
> modified. Where do those new blob object go?
git-status _does_ hash and deposit new objects, but it doesn't _need_
to. It can very well show you what "commit -a" would do without
actually doing it.
A trivial (and very stupid, yes) way to do this would be
cp -r . /tmp/git/
cd /tmp/git
git-status -a
There's no visible side-effects for the user.
IIRC, git-status -a does actually "git-add" the modified objects, but
does so in a temporary index, so I believe the objects you leave in
the objects database are not pointed to by anyone (indeed, I just
checked, git-fsck --unreachable shows the dangling blob), and are not
really useful (but will probably be used later when you run commit or
add).
> Maybe in a theoretical ideal world, you might prefer to
> reverting back to the stat-dirty original index to make
> git-status appear a read-only operation, with continued degraded
> performance. You are welcome to reimplement it that way, and
> the patch should be trivial (while git-commit.sh is still a
> script, at least) but that is not what we did.
You still didn't understand my point about the difference between
user-specification and internal behavior. I'm very happy with
git-status updating the stat information in the index, since it is not
suppose to have user-visible side effects (it has with the current
empty-diff-for-touched-files behavior of git-diff).
Now, at that point, if I still didn't manage to show you the
difference between user-visible behavior and implementation, I believe
I have no better thing to do than giving up.
--
Matthieu
^ permalink raw reply
* Re: possible bug in git apply?
From: David Kastrup @ 2007-08-05 19:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, david, git, rob
In-Reply-To: <alpine.LFD.0.999.0708051219440.5037@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 5 Aug 2007, David Kastrup wrote:
>>
>> But your proposed three passes won't work with a patch removing
>> "x/..." and creating "x" in its place, since "x/" gets only removed
>> in pass 3, and "x" needs to created in pass 2 already.
>
> Yes, I was wrong. The current two passes are the right thing to do, and we
> should just always remove empty directories (and my patch was fine: we can
> leave them alone if it's a pure "modify file in place", but that's really
> the only case).
The consequence will be that renaming all files in one directory (and
"all" can even be a single file) will temporarily delete and recreate
that directory. My proposed change of index sort and processing order
would take care of that without requiring multiple passes, at the cost
of changing the index format and processing. I think that it would be
a sound long-term solution.
Anyway, once directories can be tracked (again necessitating a change
of index format), surprising directory deletion and recreation should
become less of an issue, but it won't help with projects that continue
not tracking directories (presumably most patch-based workflows).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Linus Torvalds @ 2007-08-05 19:29 UTC (permalink / raw)
To: David Kastrup
Cc: Steven Grimm, Sam Ravnborg, Junio C Hamano, Ismail D?nmez, git
In-Reply-To: <85bqdlj1lh.fsf@lola.goethe.zz>
On Sun, 5 Aug 2007, David Kastrup wrote:
>
> > The fact that you cannot see that fact is a sign of your personal
> > (and rather odd) preferences.
>
> Yes, name-calling and ad hominem attacks again.
No. Emacs _is_ odd. It's not even installed by default on most modern
Linux distributions.
There's no name-calling there. That's just a solid fact. You are
emacs-fixated when you keep on trying to bring up totally irrelevant
emacs issues.
> Please try to remember that Texinfo is a _source_ format, and it
> produces reasonably hyperrefed and coherent PDF and HTML documents as
> well as plain ASCII. That it is also able to produce working info
> files should not bother you.
You do not even know what you are talking about.
AsciiDoc is *also* a source format. But the source format is already
readable IN ITSELF. Which is the whole point!
I don't even bother to run "make doc". I bet that is true of almost
everybody else too. Why? Because the *source* format we use (asciidoc) is
already basically as readable as any formatted man-page would ever be.
You don't have to even *know* that they are AsciiDoc pages - they're just
called "*.txt", and that's what they are. Text. With very minimal fixups
that *allow* them to be used as source for things like html, and
admittedly you get prettier output, but it really is perfectly
straightforward to just read them, in ways that pretty much no other
documentation format allows. Everybody else puts very intrusive crap in
there, so that you *have* to be aware of in ways you don't need to worry
about in AsciiDoc.
Headers? Lists? They look like headers and lists in the .txt files. No
need to think about it as a reader.
See? Texinfo is decidedly inferior. But you don't have to take it so
personally. So is pretty much anything else. Anything XML/SGML is even
*worse*.
Linus
^ permalink raw reply
* Re: Problem with bisect
From: Larry Finger @ 2007-08-05 19:24 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <20070805145234.554bf671.seanlkml@sympatico.ca>
Sean wrote:
> On Sun, 05 Aug 2007 11:02:21 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> I'm helping someone find what looks like a regression in bcm43xx-mac80211 between v2.6.22 and
>> v2.6.23-rc1. This driver is not in the mainstream kernel, but is found in John Linville's
>> wireless-dev git tree. When we do the first bisection between the current state and v2.6.22, we
>> obtain a kernel whose Makefile says it is v2.6.22; however, it's code is based on a state before
>> bcm43xx-mac80211 was introduced into this tree. My memory isn't what it used to be, but I think this
>> code was put into this tree during 2.6.19 or .20. When I used visualize to see the tree, the bottom
>> is all the way to v2.6.16, which I think is the origin of the git process.
>>
>> Is this a git bug, or is it some flaw in this particular tree? We have worked around the problem by
>> arbitrarily calling each bisection that does not have the bcm43xx-mac80211 code as "good". It has
>> been a source of confusion for the guy I'm helping as it is his first bisection. Unfortunately, the
>> bug doesn't show on my machine.
>>
The git repo is git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git.
The commands were:
git bisect start
git bisect bad
git bisect good v2.6.22
I'm using git version 1.4.4.2.g04509
Larry
^ permalink raw reply
* Re: possible bug in git apply?
From: Linus Torvalds @ 2007-08-05 19:20 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, david, git, rob
In-Reply-To: <853ayxiznp.fsf@lola.goethe.zz>
On Sun, 5 Aug 2007, David Kastrup wrote:
>
> But your proposed three passes won't work with a patch removing
> "x/..." and creating "x" in its place, since "x/" gets only removed
> in pass 3, and "x" needs to created in pass 2 already.
Yes, I was wrong. The current two passes are the right thing to do, and we
should just always remove empty directories (and my patch was fine: we can
leave them alone if it's a pure "modify file in place", but that's really
the only case).
Linus
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-05 19:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0708051933180.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 5 Aug 2007, Linus Torvalds wrote:
>
>> > You are still unable to focus on anything but name-calling and editors
>> > rather than documentation formats.
>>
>> No, it's the same thing.
>
> Hehe. Statements like the first made me set up a certain procmail
> filter. Made me much happier, too.
Interesting stance for somebody who has complained violently that I
should provide him with personal copies of mails to the list. So you
need those copies in order to keep your procmail busy...
> And now I see only one side of the conversation, which is actually
> pretty funny... much like listening in into a heated phone
> conversation, and guessing what the other one said. *grin*
You also get a chance of vetoing my patches only after they have been
applied, which happened a few times already.
To each his own, I guess.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-05 19:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Grimm, Sam Ravnborg, Junio C Hamano, Ismail D?nmez, git
In-Reply-To: <alpine.LFD.0.999.0708051118590.5037@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 5 Aug 2007, David Kastrup wrote:
>>
>> You are still unable to focus on anything but name-calling and editors
>> rather than documentation formats.
>
> No, it's the same thing.
>
> I started out by saying that Texinfo is horrible. It's horrible
> because it doesn't *buy* you anything.
No, that's not what makes it horrible.
> The only thing it buys you (the "info" format) is totally
> irrelevant, which I tried to explain.
By calling everybody names that would dare using it. That's not
really an explanation.
> AsciiDoc is much nicer. It does everything that Texinfo does for us,
> and it's readable on its own as plain text, something Texinfo isn't.
Readable plain text can be generated from Texinfo, so that is a red
herring.
> So by advocating Texinfo, you're advocating something that is
> OBJECTIVELY WORSE than what we have now.
>
> And I tried to explain why, by pointing out that info files (which
> was the case you tried to push as an advantage) aren't actually an
> advantage to any normal user.
Linus, your "normal user" does not get any documentation that can
usefully be employed for navigating a large body of documentation.
Anyway, this particular flame feast might be somewhat irrelevant: I
have read up a bit on AsciiDoc and Docbook, and it would appear that
quite a lot of what is needed for putting the required information for
indexes and nodes and other structural information is there in both
formats, and there is a tool called docbook2X that can presumably
convert to Texinfo (currently it barfs on the usermanual). So
basically a lot can be achieved by structuring the existing
documentation into book form in AsciiDoc and peppering it with
indexing (apparently only a single index is possible) and other
structural information.
This will make the AsciiDoc sources less readable, while improving the
structural information content of the generated output, presumably
also when not going via Texinfo conversion.
Restructuring the available documentation into something that _can_ be
used as a coherent book, whether as a single PDF, single or multiple
HTML pages or even (avaunt!) info is probably not too horrible a
long-term prospect, and if info gives you the heebies, just don't call
"make info install-info", and you'll never get contaminated with it.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: possible bug in git apply?
From: David Kastrup @ 2007-08-05 18:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, david, git, rob
In-Reply-To: <alpine.LFD.0.999.0708051106020.5037@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 5 Aug 2007, David Kastrup wrote:
[...]
>> > That said, if we really wanted to get it right, we should do this as
>> > a three-phase thing: (1) remove old files (2) create new files (3)
>> > for all removals and renames, try to remove source directories that
>> > might have become empty.
>> >
>> > That would fix it properly and for all cases.
>>
>> Stupid question from someone without good background: why do we need
>> two passes in the first place?
>
> For example, a patch that removes a directory structure "x/..." and then
> creates a file "x" in its place.
>
> In order for the patch ordering to not matter, you want to do the
> "remove old state" in an earlier phase.
But your proposed three passes won't work with a patch removing
"x/..." and creating "x" in its place, since "x/" gets only removed
in pass 3, and "x" needs to created in pass 2 already.
If you had bothered reading my mail to the end: I explained exactly
that. So your three pass scheme actually breaks the case for which
the two-pass scheme has been designed.
I propose you read my previous mail to its end: I explain a scheme
that will work in this case, but it would, as far as I understand
index processing, necessitate changing the index sort order, basically
having -depth order for deletion entries.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Johannes Schindelin @ 2007-08-05 18:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0708051118590.5037@woody.linux-foundation.org>
Hi,
On Sun, 5 Aug 2007, Linus Torvalds wrote:
> > You are still unable to focus on anything but name-calling and editors
> > rather than documentation formats.
>
> No, it's the same thing.
Hehe. Statements like the first made me set up a certain procmail filter.
Made me much happier, too.
And now I see only one side of the conversation, which is actually pretty
funny... much like listening in into a heated phone conversation, and
guessing what the other one said. *grin*
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Linus Torvalds @ 2007-08-05 18:23 UTC (permalink / raw)
To: David Kastrup
Cc: Steven Grimm, Sam Ravnborg, Junio C Hamano, Ismail D?nmez, git
In-Reply-To: <85bqdlj1lh.fsf@lola.goethe.zz>
On Sun, 5 Aug 2007, David Kastrup wrote:
>
> You are still unable to focus on anything but name-calling and editors
> rather than documentation formats.
No, it's the same thing.
I started out by saying that Texinfo is horrible. It's horrible because it
doesn't *buy* you anything. The only thing it buys you (the "info" format)
is totally irrelevant, which I tried to explain.
AsciiDoc is much nicer. It does everything that Texinfo does for us, and
it's readable on its own as plain text, something Texinfo isn't.
So by advocating Texinfo, you're advocating something that is OBJECTIVELY
WORSE than what we have now.
And I tried to explain why, by pointing out that info files (which was the
case you tried to push as an advantage) aren't actually an advantage to
any normal user.
Linus
^ permalink raw reply
* Re: possible bug in git apply?
From: Linus Torvalds @ 2007-08-05 18:18 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, david, git, rob
In-Reply-To: <85hcndj2b5.fsf@lola.goethe.zz>
On Sun, 5 Aug 2007, David Kastrup wrote:
>
> Which will let the user sit in an empty directory void of . and ..,
> and a parallel directory with the old name elsewhere. Unpretty...
It actually depends on the OS. POSIX allows the case of "rmdir()"
returning EBUSY if the directory is "in use", where "in use" may mean
being somebodys current working directory.
But yes, most UNIXes (Linux very much included) will just remove the
directory, and yes, the user ends up sitting in a directory that is empty
and not reachable from anywhere else.
Easy enough to see:
[torvalds@woody ~]$ mkdir test-me ; cd test-me ; rmdir $(pwd)
[torvalds@woody test-me]$ ls -a
[torvalds@woody test-me]$ pwd
/home/torvalds/test-me
[torvalds@woody test-me]$ /bin/pwd
/bin/pwd: couldn't find directory entry in `..' with matching i-node
(the first "pwd" is a shell built-in, and the shell caches is).
Under Linux, you can also see funky things like this:
[torvalds@woody test-me]$ ls -l /proc/self/cwd
lrwxrwxrwx 1 torvalds torvalds 0 2007-08-05 11:09 /proc/self/cwd -> /home/torvalds/test-me (deleted)
ie khe kernel actually shows you that you're in a deleted directory, that
_used_ to be called "test-me".
> > That said, if we really wanted to get it right, we should do this as
> > a three-phase thing: (1) remove old files (2) create new files (3)
> > for all removals and renames, try to remove source directories that
> > might have become empty.
> >
> > That would fix it properly and for all cases.
>
> Stupid question from someone without good background: why do we need
> two passes in the first place?
For example, a patch that removes a directory structure "x/..." and then
creates a file "x" in its place.
In order for the patch ordering to not matter, you want to do the "remove
old state" in an earlier phase.
And patch order shouldn't matter, since you can have interesting things
like mixing of renames and creates etc (ie maybe it's not "removing" that
directory x, it's just moving all the contents somewhere else, and maybe
the new file "x" is a move from somewhere else).
Criss-crossing renames make it even more interesting.
So git-apply actually does things in more than two phases: there's a whole
another phase that is the "read the patch and create the in-memory
result". The "two phases" above are actually just the two phases concerned
with actually modifying the working tree, there's more phases elsewhere.
Linus
^ permalink raw reply
* Re: [PATCH] Fix install-doc-quick target
From: Johannes Schindelin @ 2007-08-05 18:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, Mark Levedahl, Git Mailing List
In-Reply-To: <7vzm15eukf.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 5 Aug 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I do not like the behaviour "be stupid and assume cwd to be the working
> > tree root, if GIT_DIR is set and GIT_WORK_TREE is not".
> >
> > It bears _all_ kind of stupid connotations. Just imagine what would
> > happen with "git --git-dir=. add .".
> >
> > IMHO the new behaviour is _better_, since you can not shoot yourself in
> > the foot so easily. Being able to safeguard against doing a work tree
> > operation inside the git directory is a direct and elegant consequence of
> > defaulting to $GIT_DIR/.. in case $GIT_DIR ends in "/.git", and no work
> > tree if $GIT_DIR does _not_ end in "/.git".
> >
> > The semantics "if GIT_DIR is set, just assume the cwd to be the work tree
> > root unilaterally" is _broken_ as far as I am concerned.
>
> I am not disputing that. I was just pointing out that this is a
> change in semantics and we need to advertise it as such, and
> more importantly, advise people how to adjust to the new (and
> improved) world order.
Thanks. I will prepare a patch to ReleaseNotes, but that'll have to wait
until tomorrow. I'm pretty exhausted after the last night of msysGit
hacking.
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-05 18:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Grimm, Sam Ravnborg, Junio C Hamano, Ismail D?nmez, git
In-Reply-To: <alpine.LFD.0.999.0708051004480.5037@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 5 Aug 2007, David Kastrup wrote:
>>
>> So please get a grip and focus on what we were actually talking
>> about. Not Emacs, but rather documentation formats.
>
> You're the one who started talking about me expecting people to use
> *my* editor. I had never done that. I had talked about the
> _reverse_: the idiocy of emacs users expecting people to use that
> bloated piece of crap-ware.
Yes, and it was not the topic. So I pointed out your hypocrisy since
_you_ talk about editor preferences and "normal" people, while
preferring an editor yourself that is used by far fewer people.
You are still unable to focus on anything but name-calling and editors
rather than documentation formats.
> So stop this *insane* insistence of emacs. You should learn to just
> assume that people don't even have it installed!
We were discussing Texinfo, not Emacs. Please focus.
> Anything that works with some random emacs mode is a total
> non-usable piece of crap as far as most users are concerned.
Again, you are speaking for the rest of the world, conveniently
ignoring that more people use such a system than the one you use. But
please stop focusing on editors and focus on documentation formats.
>> Focus. How do you propose to manage documention of a hundred pages
>> an more conveniently, finding information easily by text, index,
>> hyperlinks? A single large HTML page? A documentation directory
>> full of *.txt files which you can grep through (not that Emacs
>> would not be useful for that, too)?
>
> Oh, a single large html page is certainly better than emacs and
> info, absolutely. Ask *any* normal person.
Which is why books nowadays always come as a single scroll without
index and table of contents, right? Ask any normal person.
> The fact that you cannot see that fact is a sign of your personal
> (and rather odd) preferences.
Yes, name-calling and ad hominem attacks again. It's getting old. So
you think a single large html page containing everything in the
git/Documentation directory is the way we should organize git
documentation for the sake of the users? All manual pages one after
the other, and some text in between explaining the connections? In
one large file?
While harping on my sanity and normality because of contemplating
something more structured?
Please.
For what it's worth: Texinfo documents _can_ be converted into a
single HTML file as _well_ as a hierarchically split document with a
hyperlinked index. So using Texinfo as a source format would _still_
allow preparing HTML in both multiple and single file form for the
sake of Torvalds-normal users.
Please try to remember that Texinfo is a _source_ format, and it
produces reasonably hyperrefed and coherent PDF and HTML documents as
well as plain ASCII. That it is also able to produce working info
files should not bother you.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Fix install-doc-quick target
From: Junio C Hamano @ 2007-08-05 17:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: René Scharfe, Mark Levedahl, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708051344430.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I do not like the behaviour "be stupid and assume cwd to be the working
> tree root, if GIT_DIR is set and GIT_WORK_TREE is not".
>
> It bears _all_ kind of stupid connotations. Just imagine what would
> happen with "git --git-dir=. add .".
>
> IMHO the new behaviour is _better_, since you can not shoot yourself in
> the foot so easily. Being able to safeguard against doing a work tree
> operation inside the git directory is a direct and elegant consequence of
> defaulting to $GIT_DIR/.. in case $GIT_DIR ends in "/.git", and no work
> tree if $GIT_DIR does _not_ end in "/.git".
>
> The semantics "if GIT_DIR is set, just assume the cwd to be the work tree
> root unilaterally" is _broken_ as far as I am concerned.
I am not disputing that. I was just pointing out that this is a
change in semantics and we need to advertise it as such, and
more importantly, advise people how to adjust to the new (and
improved) world order.
^ permalink raw reply
* Re: possible bug in git apply?
From: David Kastrup @ 2007-08-05 17:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, david, git, rob
In-Reply-To: <alpine.LFD.0.999.0708050949220.5037@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 4 Aug 2007, Junio C Hamano wrote:
>> >
>> > Does this fix it? Totally untested, but it _looks_ obvious enough..
>>
>> That would regress the fix made in aea19457, I am afraid.
>
> The fix in aea19457 is broken anyway.
>
> Why?
>
> That whole "do it in two phases" thing breaks it.
Did not know that.
> What can happen is that you have a directory with 100 files, and:
> - a patch modifies 99 of them
> - and removes one
>
> What happens is that during phase 0, we'll remove all the files (and *not*
> write new ones), and then beause the last patch entry is a removal, we'll
> also remove the directory (which succeeds, because all the files that got
> modified are all long gone).
>
> Then, in phase 1, we'll re-create the files that we modified, and create a
> whole new directory.
>
> IOW, as far as I can see we _already_ delete and then recreate the
> directory structure under some circumstances.
Which will let the user sit in an empty directory void of . and ..,
and a parallel directory with the old name elsewhere. Unpretty...
> I just extended it to also do it for "rename" and not just delete,
> since a rename may be renaming it to another directory.
>
> So I'd say that my patch is a clear improvement on the current
> situation.
>
> That said, if we really wanted to get it right, we should do this as
> a three-phase thing: (1) remove old files (2) create new files (3)
> for all removals and renames, try to remove source directories that
> might have become empty.
>
> That would fix it properly and for all cases.
Stupid question from someone without good background: why do we need
two passes in the first place? Can't we just do phase 1/2/3 for every
file in one step? Is there any case where not having done (1) for a
_different_ file is going to cause trouble for (2)? I presume this is
intended for something like
create a (plain file, coming in sort order before a/)
delete a/x
delete a/y (last file in a/)
in the index and frankly, this will cease working in your three-phase
scheme.
The problem is that we really need a -depth sort order for deletion in
the index, meaning that
delete xxx/yyy
sorts before
create xxx*
When we don't change the sorting order, one can do so with recursion:
when finding
create a
we postpone processing it until a prospective
delete a/*
is over. That means first processing a.txt, a.whatever/ and so on. I
think that is not sane.
As far as I can see, changing the index sort order for deletions is
probably the sanest _working_ way to go about this.
One problem is that corresponding "delete" and "create" items are then
no longer necessarily adjacent in the index. The sensible way to go
about this is to sort the requests into _two_ linked lists, one in
"create" order, one in "delete" order, and when merging a "create"
request in the index, one compares with the head of the "create"
ordered list, and when merging a "delete" request in the index, one
compares with the head of the "delete" ordered list.
Is this pretty? Not at all. But I don't see that any _fixed_ number
of phases will buy us out of the principal problem, namely that
deletions have to be done depth-first, and deletions of a directory
have to be finished before we can attempt creating a new file in their
place.
Yes, this implies changing the index sort order, unfortunately.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: How to figure out what 'git push' would do?
From: Julian Phillips @ 2007-08-05 17:45 UTC (permalink / raw)
To: Alex Riesen; +Cc: Steffen Prohaska, Git Mailing List
In-Reply-To: <20070805173340.GA3159@steel.home>
On Sun, 5 Aug 2007, Alex Riesen wrote:
> Steffen Prohaska, Sun, Aug 05, 2007 13:37:34 +0200:
>> How can I check what a 'git push' would do, without
>> actually doing it?
>>
>> Is there something like 'git push --dry-run', similar
>> to 'rsync --dry-run'?
>
> No. It is often safe to just do git-push, unless you have naive
> developers doing pull every time some ref in your shared repo changes
> *and* expecting the result to compile (typical for CVS way of work).
> git-push will not overwrite anything, it always only forwards history.
Not strictly true. You _can_ push out non fastforward changes, unless you
have receive.denyNonFastforwards in the repote repo - so you may well be
able to push out something that is completely unrelated to the last commit
the ref pointed to.
--
Julian
---
You never get a second chance to make a first impression.
^ permalink raw reply
* Re: How to figure out what 'git push' would do?
From: Alex Riesen @ 2007-08-05 17:33 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <267CDD46-549B-4BFE-B993-80CD1CFE75D8@zib.de>
Steffen Prohaska, Sun, Aug 05, 2007 13:37:34 +0200:
> How can I check what a 'git push' would do, without
> actually doing it?
>
> Is there something like 'git push --dry-run', similar
> to 'rsync --dry-run'?
No. It is often safe to just do git-push, unless you have naive
developers doing pull every time some ref in your shared repo changes
*and* expecting the result to compile (typical for CVS way of work).
git-push will not overwrite anything, it always only forwards history.
For the case you really want to know what the changes on remote repo
will be it is possible to fetch them into the local repo first and
compare with what you will push:
$ git fetch git://remote/path/REPO master:refs/remotes/REPO/master
$ gitk local..REPO/master
It gives you all possible information, which may be worth that bit of
work. Or, if you have all the remote configuration ready, it can be
just:
$ git fetch
$ gitk local..REPO/master
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Linus Torvalds @ 2007-08-05 17:08 UTC (permalink / raw)
To: David Kastrup
Cc: Steven Grimm, Sam Ravnborg, Junio C Hamano, Ismail D?nmez, git
In-Reply-To: <85bqdmctcl.fsf@lola.goethe.zz>
On Sun, 5 Aug 2007, David Kastrup wrote:
>
> So please get a grip and focus on what we were actually talking
> about. Not Emacs, but rather documentation formats.
You're the one who started talking about me expecting people to use *my*
editor. I had never done that. I had talked about the _reverse_: the
idiocy of emacs users expecting people to use that bloated piece of
crap-ware.
> > Man-pages with man.
>
> Actually, Emacs "woman" does a pretty good job with those, offers
> convenient man page name completion and works on Windows and similar
> platforms without needing
See? Can you not see that normal users don't want to have some random
emacs crap? In fact, even GNU emacs users (apart from the ones that have
used it for more than a decade) don't do it.
So stop this *insane* insistence of emacs. You should learn to just assume
that people don't even have it installed!
Anything that works with some random emacs mode is a total non-usable
piece of crap as far as most users are concerned.
> Focus. How do you propose to manage documention of a hundred pages an
> more conveniently, finding information easily by text, index,
> hyperlinks? A single large HTML page? A documentation directory full
> of *.txt files which you can grep through (not that Emacs would not be
> useful for that, too)?
Oh, a single large html page is certainly better than emacs and info,
absolutely. Ask *any* normal person.
The fact that you cannot see that fact is a sign of your personal (and
rather odd) preferences.
Linus
^ 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