* Re: On Tabs and Spaces
From: Christer Weinigel @ 2007-10-18 0:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Tom Tobin, git
In-Reply-To: <Pine.LNX.4.64.0710180040320.25221@racer.site>
On Thu, 18 Oct 2007 00:44:22 +0100 (BST)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 18 Oct 2007, Christer Weinigel wrote:
>
> > I'm not that invisible am I?
> >
> > cd linux-2.6.22.7
> > find . -type f | xargs egrep -il "weinigel" | wc -l
> > 17
>
> File or directory not found.
>
> We are not Linux specific here. Besides, I was talking about _git_
> source code, just in case I did not make myself clear.
You do not have a sense of humor, do you? And you elided the paragraph
where I said that I haven't contributed anything to git so far. :-/
> > [...] and privately I use CVS just because I started using CVS ten
> > years ago and haven't bothered to change.
>
> I wonder why you have to leave your hideout and comment on the source
> code of _git_, then. I mean, why do _you_ care? (It should have
> become apparent to you that _we_ care, so it looks even more like you
> wanted to dictate a policy on git, which you have no business with.)
Where did I say that I'm not interested in git? If I weren't I
wouldn't have been reading this mailing list since it was first
created. The reason I don't use git is a lack of time. Professionally
I usually have no need to use git since my employer doesn't use it.
On my own time, I haven't even had time and energy to switch away from
CVS, even though I ought to have done that years ago. I dabble a bit
with git, mercurial, org bitkeeper (or did at least) when I need to
access something out on the net which is stored in such a repository,
but I haven't switched any of my projects over to using anything else.
I'm definitely interested in git, and it's interesting to read the
mailing list to see where git is going. And I'd definitely like git to
move in a direction where it's usable for me, or even better, where I
can recommend it to my (often Windows-only) colleagues.
And once again you cut out the part where I said that git is Junio's
baby, he decides what goes into the main git tree, and if he says 8
wide hard tabs, that it is. I haven't argued against that at all. So
I'm wondering why you are trying to project things I haven't
said on me.
/Christer (pissing contensts are silly, so why the hell am I getting
involved in one?)
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Linus Torvalds @ 2007-10-17 23:59 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Geert Bosch, David Symonds, Wincent Colaiuta, Johan Herland, git,
Marius Storm-Olsen, Christian Couder, Ren? Scharfe, Junio Hamano
In-Reply-To: <Pine.LNX.4.64.0710180045160.25221@racer.site>
On Thu, 18 Oct 2007, Johannes Schindelin wrote:
>
> Could we, _please_, first decide if the implementation has merits, and
> just apply it as is in that case? We can rename it whatever anybody likes
> later, and we can paint the bikeshed brown if you want to.
I thought everybody really agreed that being able to skip commits that you
cannot say good/bad about is a feature worth doing?
Right now we actually have some docs in the man-page about doing that
avoidance manually, so it's not like it's debatable whether this issue
comes up. It most definitely does come up.
Does anybody really think it's not a good feature? And I've not seen
negative comments about the implementation either apart from some small
details that I think got fixed up already (but maybe the complaints were
all hidden by the shed color discussions ;)
Linus
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-17 23:53 UTC (permalink / raw)
To: Christer Weinigel; +Cc: Johannes Schindelin, Tom Tobin, git
In-Reply-To: <20071018011734.7b636141@localhost.localdomain>
On Thu, 18 Oct 2007, Christer Weinigel wrote:
>
> BTW, how serious is the problem with deltifying when there are a lot of
> spaces that David Kastrup mentioned?
I suspect it works quite well in practice.
But we've had to tweak the xdiff code before, and the hash calculations
for bucket size limits. If somebody actually points out a problem case, we
can probably tweak it again.
> Wouldn't it be a problem when people put ASCII graphics in comments or
> just have comments like /*********************************/ in their
> code?
In general, *any* situation where you have tons of character sequences
that are the same (and here it's not the characters *themselves* that have
to be the same - it's the *sequence* that has to be the same, so it's not
about repeating the same character over and over per se: it's about
repeating a certain block of characters many many times in the source
code) will be problematic for pretty much any similarity analysis.
Why? Because you just have a lot of the same sequence, and to get a good
delta you want to find common "sequences of these sequences" (call them
supersequences) in order to find the biggest common chunk.
So the badly performing cases for any delta algorithm (and I do want to
point out that this has nothing what-so-ever to do with the particular one
that git uses) tends to be exactly the ones where you have lots and lots
of smaller chunks that match in two files, and that then makes it costlier
to find the *bigger* chunks that are build up of those smaller chunks.
And generally you tend to have two situations: you either (a) take *much*
longer to find the common areas (they are often quadratic or worse
algorithms) or (b) you decide to ignore chunks that are so common that
they don't really add any real information when it comes to finding truly
common chunks. Where that second choice generally means that you can miss
some cases where you *could* have found a good match for deltification.
In fact, usually you have a combination of the above two effects: certain
deltas may be more expensive to find but there is also a limit that kicks
in and means that you never spend *too* much time on finding them if the
pattern space is not amenable to it.
Would lots of spaces be such a pattern? I personally doubt it would really
matter. In general, source code is easy to delta: the bulk of any common
sequences in most files will be found by the trivial "look for common
sequences in the beginning and the end". The really *bad* cases tend to be
rather odd, and often generated files.
So no, I don't think deltification is a huge deal for spaces. But it does
boil down to the same kind of issues: if you blow up the source base by
20%, you often slow down things by 20% or more, simply because there is
more data to process at all stages. It simply just slows down everything -
totally unnecessarily.
Linus
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Johannes Schindelin @ 2007-10-17 23:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Geert Bosch, David Symonds, Wincent Colaiuta, Johan Herland, git,
Marius Storm-Olsen, Christian Couder, Ren? Scharfe, Junio Hamano
In-Reply-To: <alpine.LFD.0.999.0710171553580.26902@woody.linux-foundation.org>
Hi,
On Wed, 17 Oct 2007, Linus Torvalds wrote:
> On Mon, 15 Oct 2007, David Kastrup wrote:
>
> > Geert Bosch <bosch@adacore.com> writes:
> >
> > > On Oct 15, 2007, at 13:53, David Symonds wrote:
> > >> That's also why I suggested "skip"; you might not be able to test a
> > >> particular commit, but you might also not *want* to test a
> > >> particular commit for some reason.
> > >
> > > Skip seems a great choice: it directly expresses the wish to not
> > > consider a certain commit. The reason is unimportant.
> >
> > But it is an _action_, while "good" and "bad" are properties.
>
> Well, this has been debated to death, but I actually think that "skip"
> is a good choice, exactly because it's an action.
Could we, _please_, first decide if the implementation has merits, and
just apply it as is in that case? We can rename it whatever anybody likes
later, and we can paint the bikeshed brown if you want to.
Ciao,
Dscho
^ permalink raw reply
* Re: On Tabs and Spaces
From: Johannes Schindelin @ 2007-10-17 23:44 UTC (permalink / raw)
To: Christer Weinigel; +Cc: Linus Torvalds, Tom Tobin, git
In-Reply-To: <20071018011734.7b636141@localhost.localdomain>
Hi,
On Thu, 18 Oct 2007, Christer Weinigel wrote:
> On Wed, 17 Oct 2007 23:11:37 +0100 (BST)
> Johannes Schindelin <Johannes.w@gmx.de> wrote:
>
> > On Wed, 17 Oct 2007, Christer Weinigel wrote:
> >
> > > I think you would get at lot less argument if you weren't so damn
> > > self righteous about it.
> >
> > Why is it that in this thread, people whom I have heard _nothing_ of
> > before seem to think this would be a good time to let their opinion
> > be heard? Now, _that_ is what I call righteous. Show nothing but
> > opinion.
>
> I'm not that invisible am I?
>
> cd linux-2.6.22.7
> find . -type f | xargs egrep -il "weinigel" | wc -l
> 17
File or directory not found.
We are not Linux specific here. Besides, I was talking about _git_ source
code, just in case I did not make myself clear.
> [...] and privately I use CVS just because I started using CVS ten years
> ago and haven't bothered to change.
I wonder why you have to leave your hideout and comment on the source code
of _git_, then. I mean, why do _you_ care? (It should have become
apparent to you that _we_ care, so it looks even more like you wanted to
dictate a policy on git, which you have no business with.)
Puzzled, and a little unnerved,
Dscho
^ permalink raw reply
* Re: [QGIT4 PATCH] Add --no-color option to several calls to git
From: Marco Costalba @ 2007-10-17 23:38 UTC (permalink / raw)
To: Yaacov Akiba Slama; +Cc: git
In-Reply-To: <1192643649-18908-1-git-send-email-ya@slamail.org>
On 10/17/07, Yaacov Akiba Slama <ya@slamail.org> wrote:
> Setting "diff.color = true" in the configuration makes
> the output of several git commands use color codes.
> The color codes aren't parsed by qgit, so adds the --no-color" option
> to the calls of these git commmands.
>
> Signed-off-by: Yaacov Akiba Slama <ya@slamail.org>
> ---
Thanks for the patch I will apply probably this week-end.
Probably a point release both for qgit-2.0 and qgit-1.5.7 will be
needed. This is a new feature of git that could break current qgit.
Could you please confirm me that with this patch qgit works flawless
for you when "diff.color = true", I' m worried to push a new point
release just to discover we need to fix some more.
Thanks
Marco
^ permalink raw reply
* Re: On Tabs and Spaces
From: Jari Aalto @ 2007-10-17 23:38 UTC (permalink / raw)
To: git
In-Reply-To: <47168E70.4070305@op5.se>
* Thu 2007-10-18 Andreas Ericsson <ae@op5.se> gmane.comp.version-control.git
* Message-Id: 47168E70.4070305@op5.se
> And simply because nearly all (unix) editors still insert a hard tab
> when pressing the tab key, and *mixing* tabs and spaces makes the
> situation *really* unbearable, one really shouldn't use all spaces.
There was no assumption about a particular OS or editors.
The QA tools will take care of warning or making automatic formatting
before the code is put to SCM. In projects you cannot assume anything
about people, their tools or what OS they might use at hand.
>> There is no such problem with spaces.
>>
>
> I beg to differ, for reasons stated multiple times elsewhere in this
> thread.
Consider:
- Any editor will display the text written in "all spaces"
100 % the same. Regradless of any viewer or editor used.
But the same is not true with text that uses tabs (because you
really can't know what options the editor is preset / user set /
regarding the treatment of tabs).
The score is 1 - 0 for "all spaces" in this contest.
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Christian Couder @ 2007-10-17 23:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Junio Hamano, git
In-Reply-To: <Pine.LNX.4.64.0710171906280.25221@racer.site>
Hi,
Le mercredi 17 octobre 2007, Johannes Schindelin a écrit :
> Hi,
>
> On Wed, 17 Oct 2007, Shawn O. Pearce wrote:
> > Christian Couder <chriscool@tuxfamily.org> wrote:
> > > Here is my bisect dunno patch series again.
> > > The changes since last time are the following:
> >
> > I now have this series queued in my pu branch. It passes the tests
> > it comes with, and doesn't appear to break anything, but apparently
> > there is also still some debate about what a dunno should be called
> > ("unknown", "void", "ugly", "dunno", "skip" ...).
>
> AFAICT these are all bikeshed painting arguments, not technical
> arguments. I was initially opposed to having --bisect-all, wanting to
> have
> --bisect-dunno <ref>...
>
> But in the end, the people doing the work decide, and therefore I am fine
> with --bisect-all, especially since it seems clean enough for me.
>
> As for all those "dunno is no English"... I'd first merge the technical
> part (i.e. what you have now in pu), and then let the discussion about
> which synonyms to choose continue, until a consensus is formed about
> other names (if there is a consensus at all!).
>
> IMHO there is no reason to hold of the fine work of Christian,
It's also the fine work of Junio as he wrote most of
the "rev-list --bisect-all" patch.
> just
> because there are non-technical arguments still in the air.
>
> I want bisect dunno. Even if there is another name later.
Thanks for your kind words,
Christian.
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.
From: Marco Costalba @ 2007-10-17 23:26 UTC (permalink / raw)
To: Robin Rosenberg
Cc: pete, piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <200710171800.37345.robin.rosenberg.lists@dewire.com>
On 10/17/07, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
>
> You could avoid the temporary files if you just pipe the diff to kompare. That
> would require an option to tell qgit that the external viewer can read a git diff.
>
> At the time qgit 1.5 was written, kompare could not handle git diffs.
>
So does the other tools I have checked at that time.
But I don't know if this fixes the problem of slowness reported. A
little test Pete may do is just as I have written in the former email:
try to save the big files that cause troubles where he prefers and run
Kompare on them directly from the command line.
Is kompare faster? If no probably the 'pipe' technique will not solve
the problem and shrinks the applicability of the external diff
launcher to tools that handle diffs directly.
Marco
^ permalink raw reply
* Re: On Tabs and Spaces
From: Christer Weinigel @ 2007-10-17 23:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Tom Tobin, git
In-Reply-To: <Pine.LNX.4.64.0710172310270.25221@racer.site>
On Wed, 17 Oct 2007 23:11:37 +0100 (BST)
Johannes Schindelin <Johannes.w@gmx.de> wrote:
> Hi,
>
> On Wed, 17 Oct 2007, Christer Weinigel wrote:
>
> > I think you would get at lot less argument if you weren't so damn
> > self righteous about it.
>
> Why is it that in this thread, people whom I have heard _nothing_ of
> before seem to think this would be a good time to let their opinion
> be heard? Now, _that_ is what I call righteous. Show nothing but
> opinion.
I'm not that invisible am I?
cd linux-2.6.22.7
find . -type f | xargs egrep -il "weinigel" | wc -l
17
Ahh, confirmation, I really do exist. The earliest LSM entry I can find
for myself is from 1995:
http://www.ibiblio.org/pub/linux/kernel/patches/scanners/hpscan-0.1.1.5.lsm
Mmm, nostalgia. :-)
But yes, I haven't contributed anything to git so far, I mostly lurk
on the mailing list and try to keep up with what's happening to git.
In the beginning I sent a few ideas to the list (which quite sadly were
ignored), but unfortunately I've been busy with paying work to do much
with git after that. And at work we use Perforce (yuk) or Subversion
(a lot nicer than Perforce) and privately I use CVS just because I
started using CVS ten years ago and haven't bothered to change. And
when I'm free I prefer to hack on hardware or device drivers instead.
The reason I wrote my first mail in this thread is that I work in a
different environment than Linus does and wanted to share that
experience. I usually work with embedded programming, where people use
lots of different editors and in mixed environments. Some people use
Visual Studio on Windows because that's what they use for host
programming, a lot of embedded development is done in the (almost
invariably sucky) IDE that comes with the compilers for the embedded
CPU, such as Microchips MPLAB or IAR Workbench, Eclipse is becoming
quite popular for C development, Slickedit is also popular on Windows,
a colleague prefers nedit for some strange reason, and so on. In such a
heterogeneous environment the easiest way to make sure that people see
the same indentation in all editors is to just tell them to use spaces
for indentation, and I think that every editor I just mentioned has a
setting to do that automatically. Microemacs is the odd one out in
that it doesn't support it. And my employers haven't really been
paying me to go on a crusade for the holy TAB is 8 spaces cause, they
just want things done, so I've had to settle for a "good enough"
solution which works most of the time.
So I just thought it was unfair of Linus to say that "use spaces"
doesn't solve any problems, in some environments it does. For the
Linux kernel and Git, it's easier for the maintainer to enforce
the coding standards and since Linus and Junio prefer to use hard tabs,
that are the rules that people who want to play with their toys
have to adhere to.
BTW, how serious is the problem with deltifying when there are a lot of
spaces that David Kastrup mentioned? It does sound like a quite
serious problem if it has a big impact on the performance of Git. Git
isn't only used for the Linux kernel, so there has to be some projects
that both use spaces for indentation and use Git out there. Wouldn't
it be a problem when people put ASCII graphics in comments or just have
comments like /*********************************/ in their code?
/Christer
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Linus Torvalds @ 2007-10-17 22:59 UTC (permalink / raw)
To: David Kastrup
Cc: Geert Bosch, David Symonds, Wincent Colaiuta, Johan Herland, git,
Marius Storm-Olsen, Christian Couder, Ren? Scharfe, Junio Hamano,
Johannes Schindelin
In-Reply-To: <85ve98gl57.fsf@lola.goethe.zz>
On Mon, 15 Oct 2007, David Kastrup wrote:
> Geert Bosch <bosch@adacore.com> writes:
>
> > On Oct 15, 2007, at 13:53, David Symonds wrote:
> >> That's also why I suggested "skip"; you might not be able to test a
> >> particular commit, but you might also not *want* to test a particular
> >> commit for some reason.
> >
> > Skip seems a great choice: it directly expresses the wish to
> > not consider a certain commit. The reason is unimportant.
>
> But it is an _action_, while "good" and "bad" are properties.
Well, this has been debated to death, but I actually think that "skip" is
a good choice, exactly because it's an action.
"good" and "bad" do indeed describe properties of the commit, and are used
to describe the state of the tree in question. In contrast, "git bisect
skip" says not somethign about the state of that tree - it talks about
what we should *do* with that tree.
IOW, I think "git bisect skip" in some sense has more to do with an action
like "git bisect start", than with "good" or "bad".
(Yes, "good" and "bad" have an action associated with them too - namely to
start the next bisection event - but they are not named according to the
action they cause, but because they describe the tree state)
Linus
^ permalink raw reply
* [PATCH] Bisect: fix a removed variable that is still used.
From: Christian Couder @ 2007-10-17 22:52 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
This is fix for something I forgot in the patch named:
[PATCH 6/7] Bisect: factorise "bisect_{bad,good,dunno}"
into "bisect_state".
I can send an updated version of the above patch if
needed.
diff --git a/git-bisect.sh b/git-bisect.sh
index b266d17..abae9a6 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -406,7 +406,7 @@ bisect_run () {
if [ $res -ne 0 ]; then
echo >&2 "bisect run failed:"
- echo >&2 "$next_bisect exited with error code $res"
+ echo >&2 "'bisect_state $state' exited with error code $res"
exit $res
fi
--
1.5.3.3.136.g591d1-dirty
^ permalink raw reply related
* Re: On Tabs and Spaces
From: Andreas Ericsson @ 2007-10-17 22:36 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <k5pll7rb.fsf@blue.sea.net>
Jari Aalto wrote:
> * Wed 2007-10-17 Michael Witten <mfwitten@MIT.EDU>
> * Message-Id: E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu
>> On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote:
>>
>>> But I still haven't seen any compelling arguments against the "all
>>> space" case
>> Overhead!
>>
>> If you use 8 spaces instead of one tab,
>> that's using up 7x more space!
>
> Software is the right place to worry about optimization. We should trust
> SCM to make proper and efficient deltas. If not, algorithms need
> improvemnts.
>
> Any cross platform development or electronic exchange is guaranteed to
> be interpreted correctly when policy enforces "only spaces"
>
> As we have already seen in numerous times in this thread, using tabs
> will - eventually - be interpreted in some editor, in some display, in
> some encironment using some tools ... incorrectly or different than the
> author intended. Simply because editors are configurable and we cannot
> know what settings they may have when they load the file in.
>
And simply because nearly all (unix) editors still insert a hard tab
when pressing the tab key, and *mixing* tabs and spaces makes the
situation *really* unbearable, one really shouldn't use all spaces.
It's code, not graphics. If it's really horrible, any editor can be
configured to change the non-default tab-setting back to 8 if that's
the problem. Mine's set to 4. Primarily because I think 8 is too
much. Sometimes (roughly once every 2 years), that gives me problem.
It's exclusively when someone has consciously mixed tabs and spaces.
Using either or *never* gives any problem.
> There is no such problem with spaces.
>
I beg to differ, for reasons stated multiple times elsewhere in this
thread.
> The storage constraints are insignificant given the disk space vs. cost;
Perhaps, but it's low-hanging fruit and since all spaces have its issues
too, why not just go with tabs?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] fixing output of non-fast-forward output of post-receive-email
From: Robert Schiele @ 2007-10-17 22:27 UTC (permalink / raw)
To: git; +Cc: gitster, andyparkins
post-receive-email has one place where the variable fast_forward is not
spelled correctly. At the same place the logic was reversed. The
combination of both bugs made the script work correctly for fast-forward
commits but not for non-fast-forward ones. This change fixes this to
be correct in both cases.
Signed-off-by: Robert Schiele <rschiele@gmail.com>
---
contrib/hooks/post-receive-email | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index cbbd02f..28a06c7 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -323,7 +323,7 @@ generate_update_branch_email()
echo " via $rev ($revtype)"
done
- if [ -z "$fastforward" ]; then
+ if [ "$fast_forward" ]; then
echo " from $oldrev ($oldrev_type)"
else
# 1. Existing revisions were removed. In this case newrev is a
--
1.5.2.4
^ permalink raw reply related
* Re: On Tabs and Spaces
From: Johannes Schindelin @ 2007-10-17 22:11 UTC (permalink / raw)
To: Christer Weinigel; +Cc: Linus Torvalds, Tom Tobin, git
In-Reply-To: <20071017232146.4b9e4097@localhost.localdomain>
Hi,
On Wed, 17 Oct 2007, Christer Weinigel wrote:
> I think you would get at lot less argument if you weren't so damn self
> righteous about it.
Why is it that in this thread, people whom I have heard _nothing_ of
before seem to think this would be a good time to let their opinion be
heard? Now, _that_ is what I call righteous. Show nothing but opinion.
Ciao,
Dscho
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-17 22:03 UTC (permalink / raw)
To: Christer Weinigel; +Cc: Tom Tobin, git
In-Reply-To: <20071017232146.4b9e4097@localhost.localdomain>
On Wed, 17 Oct 2007, Christer Weinigel wrote:
>
> But when you start claiming that there are no reasons to use all
> spaces, and that it doesn't solve any problems (it definitely does),
> and that all editors work with hard tabs at 8 (which they don't), at
> least I get a bit frustrated with you. It's very non-respectful of you
> to claim that everyone is stupid that doesn't agree with you and is
> just asking for silly arguments. Yes, I know, you're an opinionated
> bastard and proud of it, but maybe you should tone that down a bit.
Hey, fair enough.
I'm not very tolerant of people who haven't actually done anything, and
then come in and say things should be done certain ways. The fact is, code
talks, bullshit walks.
And bullshit should most definitely not be encouraged. People like that
should be discouraged *immediately*. I'm not interested in bikeshed
painters, I think they should be told so forcefully enough that they
either shut up or go away.
Maybe it's a character flaw. I'll respect people who do something
interesting, but re-implementing CVS (and badly, at that) or talking about
syntactic changes to other peoples projects is not going to fill me with
respect.
In short, I'll give respect when somebody is shown to be *worth* that
respect. But respect really has to be earned, not just "assumed",
otherwise it's pointless.
Linus
^ permalink raw reply
* Re: On Tabs and Spaces
From: Jari Aalto @ 2007-10-17 22:02 UTC (permalink / raw)
To: git
In-Reply-To: <E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu>
* Wed 2007-10-17 Michael Witten <mfwitten@MIT.EDU>
* Message-Id: E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu
> On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote:
>
>> But I still haven't seen any compelling arguments against the "all
>> space" case
>
> Overhead!
>
> If you use 8 spaces instead of one tab,
> that's using up 7x more space!
Software is the right place to worry about optimization. We should trust
SCM to make proper and efficient deltas. If not, algorithms need
improvemnts.
Any cross platform development or electronic exchange is guaranteed to
be interpreted correctly when policy enforces "only spaces"
As we have already seen in numerous times in this thread, using tabs
will - eventually - be interpreted in some editor, in some display, in
some encironment using some tools ... incorrectly or different than the
author intended. Simply because editors are configurable and we cannot
know what settings they may have when they load the file in.
There is no such problem with spaces.
The storage constraints are insignificant given the disk space vs. cost;
including possibly used compression algorithms in storage or transfers.
Jari
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Pete/Piet Delaney @ 2007-10-17 21:47 UTC (permalink / raw)
To: Marco Costalba; +Cc: Linus Torvalds, VMiklos, free cycle, git
In-Reply-To: <e5bfff550710170014m395d5b8cld87a5c2c9f7d71a@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marco Costalba wrote:
> On 10/17/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>> 't' worked fine but still can see how to diff do of the list of
>> changes for a file. Viewing diffs of files based on change sets
>> worked fine but I think with BitKeeper I found it helpful to be
>> able to do a full 'kompare' type diff the file only; often I'm
>> not interested in which change set it went into.
>>
>
> Well, open tree view ('t'), select the file you are interested of,
> then click the magic wand button on the tool bar, now revisions you
> see are filtered by that file, if you browse the revisions the
> patch/diff you see will always point to your file (also if you can see
> the whole patch).
I take it the "magic wand button" is the check mark on the upper right
that says "Pin View (Alt-V)". When I pin the view the view of the file
in Qgit locks to the selected file but the External diff seems to stay
the same. The External diff appears to show my last change to the file;
changing the change-set selection doesn't seem to change anything with
the view pinned.
>
>> Something for a future version or am I lucky and you have
>> it covered already?
>>
>
> Don't know, depends on how you answer to the above point ;-)
How'd I do?
>
>> Good Idea, thought it's brought up a few questions:
>>
>> 1. When I do the <control-minis> to Decrease the font size
>> I can't undo it with the <control-plus>. Also <control-plus>
>> doesn't seem to do anything.
>>
>> 2. When displaying the "Lane info" why can't I see the
>> branch names?
>>
>
> Thanks for the reports, I will investigate as soon as I have a bit of
> spare time.
ok, I suspect that's an easy one.
>
>> I'll read it a few more times. I seem to sometimes get into a state
>> where I'm locked onto the current change set and can't get back to
>> the other change sets without starting another qgit.
>>
>
> Please, could you be so kind to better explain me the above point.
> Seems interesting, but I didn't get how to reproduce.
I'm not sure how I get into this state either, I'll try to recall
how I get into this state the next time it occurs.
>
>>> Yes it is. There are a lot of new featrures, is almost as stable as
>>> the previous and if you are interested in file history (annotations)
>>> in qgit-2.0 this feature has been greatly speeded up.
>> Do you know if it's a lot of work to install Qt4?
>>
>
> With Mandriva you are just at an uprmi away.
>
> Try something like
>
> urpmi libqt4-devel
/nethome/piet$ su
/nethome/piet$ /usr/sbin/urpmi libqt4-devel
no package named libqt4-devel
/nethome/piet$
/urpmi libqt4 also didn't work.
>
> It worked for me ;-)
I'm running 2005 Limited Edition; I wonder if QT4 even existed then.
Think it's worth messing with QT4 just to upgrade to you latest version?
Some of these graphics libs can be bear to install from src.
- -piet
>
> Marco
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFoLhJICwm/rv3hoRAt73AJ9kWv8EhuaAH/69HqG0+FZOAD8LlgCdH6uU
2PJDFOuZENrKJBA66MOdANc=
=yd6t
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: On Tabs and Spaces
From: Christer Weinigel @ 2007-10-17 21:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tom Tobin, git
In-Reply-To: <alpine.LFD.0.999.0710171246500.26902@woody.linux-foundation.org>
This is bloody ridiculous, but...
On Wed, 17 Oct 2007 12:53:58 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> So what's your point? You're pushing something that is provably
> odd-ball, since almost nobody uses it, and you cannot even state what
> the huge advantages are, and you claim that I'm the one that ignores
> them, when it is *you* who have refused to acknowledge that there are
> reasons to *not* do it (one big reason being that there are current
> existing and productive developers that definitely do *not* want to
> change - and no, it wasn't just me, either).
>
> And you know what? I don't much care if you aren't swayed by mine.
> It's to some degree a matter of taste, and the fact is, if you don't
> like the current git model, you can go away and play with your own
> model. It *is* open source, after all.
>
> Put another way: if you cannot respect the wishes of the people who
> have done the work, then I damn well have no reason what-so-ever to
> respect *yours*.
I think you would get at lot less argument if you weren't so damn self
righteous about it. If you'd just said "it's a matter of taste and
hard tabs 8 spaces wide are the way we prefer to do it and that's the
way we want to keep doing it" I'd not have any problem with it.
But when you start claiming that there are no reasons to use all
spaces, and that it doesn't solve any problems (it definitely does),
and that all editors work with hard tabs at 8 (which they don't), at
least I get a bit frustrated with you. It's very non-respectful of you
to claim that everyone is stupid that doesn't agree with you and is
just asking for silly arguments. Yes, I know, you're an opinionated
bastard and proud of it, but maybe you should tone that down a bit.
(At least I got quite insulted by your Git talk at Google. People
are not stupid just because they don't agree with you, most of the time
they just have different preferences or different goals.)
/Christer (trying to escape from Lilliput)
^ permalink raw reply
* Re: On Tabs and Spaces
From: Johannes Schindelin @ 2007-10-17 21:08 UTC (permalink / raw)
To: Tom Tobin; +Cc: Linus Torvalds, git
In-Reply-To: <1192649598.6640.44.camel@athena>
Hi,
On Wed, 17 Oct 2007, Tom Tobin wrote:
> On Wed, 2007-10-17 at 11:54 -0700, Linus Torvalds wrote:
> >
> > On Wed, 17 Oct 2007, Tom Tobin wrote:
> > >
> > > Or is "unix developers" code for "my sample size of one"?
> >
> > Well, let's put it this way: that "sample" is the one that started the
> > project.
>
> And therefore your choices become magically reasonable?
Tom, you have to contribute way more code than you did, in order to be
taken seriously with statements as these.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/6] more compact progress display
From: Nicolas Pitre @ 2007-10-17 20:56 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071017082003.GA10799@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 580 bytes --]
On Wed, 17 Oct 2007, Karl Hasselström wrote:
> On 2007-10-16 22:11:37 -0400, Shawn O. Pearce wrote:
>
> > Nicolas Pitre <nico@cam.org> wrote:
> >
> > > Each progress can be on a single line instead of two.
> >
> > Nice. Of course that screws with git-gui and now I have to match two
> > regexs and not one. But whatever.
>
> Maybe an env variable could cause the code to emit machine-friendly
> progress information instead?
That won't help with remotely generated progress unaware of local env
variable, and the remote server might still be generating old format.
Nicolas
^ permalink raw reply
* Re: Git User's Survey 2007 summary - git homepage improvements
From: Daniel Barkalow @ 2007-10-17 20:45 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Petr Baudis, Jan Hudec, Frank Lichtenheld, Jakub Narebski, git,
Jonas Fonseca
In-Reply-To: <20071017002648.GH13801@spearce.org>
On Tue, 16 Oct 2007, Shawn O. Pearce wrote:
> Petr Baudis <pasky@suse.cz> wrote:
> > On Tue, Oct 16, 2007 at 10:12:47PM +0200, Jan Hudec wrote:
> > > On Mon, Oct 15, 2007 at 00:56:18 +0200, Frank Lichtenheld wrote:
> > > > On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
> > > > > Generic:
> > > > > # Dedicated domain name / site name, e.g. git.org or git.com
> ...
> > > > (And I guess something like git-scm.org wouldn't qualify as more
> > > > "official", would it?)
> > >
> ...
> > If someone trustworthy in the community has the resources to sponsor the
> > domain, I will only be happy and gladly set it up on my side (I can run
> > the nameservers myself too, if required). But I don't have the
> > resources for registering the domain myself, unfortunately.
>
> "git" is a three letter word. I don't think there have been *any*
> three letter .com/.org/.net domains available for years.
If anyone's in London, and could ask an Andy Ritchie nicely,
http://git.org/ doesn't seem to be doing much, and we might be able to get
a redirect.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: On Tabs and Spaces
From: David Kastrup @ 2007-10-17 20:31 UTC (permalink / raw)
To: Tom Tobin; +Cc: Linus Torvalds, git
In-Reply-To: <1192649598.6640.44.camel@athena>
Tom Tobin <korpios@korpios.com> writes:
> On Wed, 2007-10-17 at 11:54 -0700, Linus Torvalds wrote:
>
>> In contrast, your argument seems to be "I've not actually done
>> anything, but I want to paint the bikeshed pink".
>
> Because, once again, being new makes one incorrect, doesn't it?
>
> You've essentially demonstrated that git's "benevolent" dictator is
> an asshole, and even worse, an irrational asshole.
You are doing Junio a harsh injustice here.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 2/2] Quoting paths in tests
From: David Kastrup @ 2007-10-17 20:03 UTC (permalink / raw)
To: git
In-Reply-To: <864pgpfyrd.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Jonathan del Strother <maillist@steelskies.com> writes:
>
>> For instance, git_editor in git-sh-setup expects the editor path to be
>> pre-quoted. So in t3404, you need to produce escaped double quotes &
>> dollar signs, resulting in unpleasantness like this :
>>
>> VISUAL="`pwd`/fake-editor.sh"
>> VISUAL=${VISUAL//\"/\\\"}
>> VISUAL=${VISUAL//$/\\\$}
>> VISUAL=\"$VISUAL\"
>> export VISUAL
>
> EDITORPWD="`pwd`"
> VISUAL='$EDITORPWD/fake-editor.sh'
> export EDITORPWD VISUAL
Pffffft.
VISUAL='"$EDITORPWD/fake-editor.sh"'
of course. Or we still have problems with spaces in pwd.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: On Tabs and Spaces
From: David Kastrup @ 2007-10-17 19:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0710171337330.19446@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Wed, 17 Oct 2007, David Kastrup wrote:
>
>> Luke Lu <git@vicaya.com> writes:
>>
>> > But I still haven't seen any compelling arguments against the "all
>> > space" case, other than "people will screw it up into mixed spaces",
>> > which is really a straw man, as many multi-platform projects
>> > enforced the all-space policy easily by using a pre-commit hook in
>> > maintainers' repository.
>>
>> All-space indentation renders the binary delta algorithm git uses for
>> compression of packs slow and partly inoperative (all sequences of 16
>> spaces share the same finger print, and the number of identical finger
>> prints for which the file information is kept is reduced to 64).
>
> But sequences of 16 spaces are unlikely to land on 16-byte boundaries
> all the time in the file so adjacent data to those 16-space blocks will
> still provide good hashing.
Half of the three-tab equivalents and all of the four-tab equivalents
contain a 16-byte space sequence on the tested boundary.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ 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