* [PATCH] Help people in finding the download links
From: Paolo Ciarrocchi @ 2007-10-16 21:58 UTC (permalink / raw)
To: pasky, git
I believe that with the following change it's a bit easier to visualize the table including the links to the tar.bz2 and tar.gz source packages.
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
index.html | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/index.html b/index.html
index dc5189a..b061178 100644
--- a/index.html
+++ b/index.html
@@ -54,7 +54,7 @@ Junio C Hamano.</p>
<div style="float: right"><table class="releases">
- <tr class="odd" align="center"><td colspan="2"><!--@DATE@-->[2007-10-03]</td></tr>
+ <tr class="odd" align="center"><td colspan="2"><b>Download GIT source package</b> <!--@DATE@-->[2007-10-03]</td></tr>
<tr align="center"><td colspan="2">The latest stable Git release is <b><!--@VNUM@-->v1.5.3.4</b>:</td></tr>
<tr align="center"><td>
<!--@TARLINK@--><a href="http://kernel.org/pub/software/scm/git/git-1.5.3.4.tar.bz2">tar.bz2</a>
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* [PATCH] Remove link to the survey from the git home page.
From: Paolo Ciarrocchi @ 2007-10-16 21:57 UTC (permalink / raw)
To: pasky, git
As far as I know the survey is close so it makes sense to remove the link/text from the home page.
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
index.html | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/index.html b/index.html
index 5d14acf..dc5189a 100644
--- a/index.html
+++ b/index.html
@@ -50,7 +50,7 @@ the <a href="http://www.gnu.org/licenses/gpl2.txt">GNU General Public License v2
It was originally written by Linus Torvalds and is currently maintained by
Junio C Hamano.</p>
-<p><strong><a href="http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3ee1856d9">The Git User Survey</a> is up now! Please devote a few minutes of your time to fill this simple questionnaire, it will help a lot the git community to understand your needs, what you like of GIT, and of course what you don't like of it.</strong></p>
+
<div style="float: right"><table class="releases">
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: remote#branch
From: Johannes Schindelin @ 2007-10-16 21:35 UTC (permalink / raw)
To: Jan Hudec; +Cc: Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <20071016210904.GI26127@efreet.light.src>
Hi,
On Tue, 16 Oct 2007, Jan Hudec wrote:
> If it is a fragment, than "#" is the only correct separator and should
> stay that way.
You did not listen, did you? '#' is allowed in ref names. Therefore this
character really would lock us in to only ever reference _one_ and _only_
one remote branch at a time. This might have worked for cogito, but it
does not for git.
So, I say it again, '#' is _out_.
> If it is not a true fragment, than we might want to phase it out in
> favor of something else. But I would strongly prefer staying within
> characters allowed in URI (as per rfc2396).
If you do that, "http://<xyz-with-branch>" would be ambiguous, wouldn't
it? This would already reference an HTTP resource, and you could not
embed refnames into the URL.
> As for multiple branches, separating them with "," feels logical to me,
> no matter what separates them from the repository path. On the other
> hand given that neither ":" nor "@" is allowed in refnames, reusing the
> same separator would make sense especially if git switched to either of
> those.
',' is allowed in ref names, so ',' is out.
Ciao,
Dscho
^ permalink raw reply
* Re: Is there any plan to support partial checkout or submoudule improvement?
From: Jan Hudec @ 2007-10-16 21:33 UTC (permalink / raw)
To: franky; +Cc: 'Johannes Schindelin', 'Lars Hjemli', git
In-Reply-To: <20071016115310.5FB957E6D@mail.kooxoo.com>
[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]
On Tue, Oct 16, 2007 at 19:53:08 +0800, franky wrote:
> > You are talking as if your partial checkout was a project in its own
> > right. Then make it so. Do not use a partial checkout, but make that a
> > submodule.
>
> As I said in the first email, the submodule way suffers from the multiple
> commit problem: src and bin as two submodules of project, three commits (for
> the 3 dirs separately) are needed when src directory changes and compiled
> binaries being put in bin directory. It's annoying to have to give 3 commit
> logs.
Thinking about it, it's only two commits -- src can be a submodule, but bin
a normal directory (you can choose not to check out subprojects during
repository checkout).
This has the advantage, that bin, even when src is not checked out, always
knows what version of src it is based on (it's in the gitlink) and you only
give two commit messages.
Now I would actually say that commiting bin independently is better.
It allows you to commit sources more often (eg. if you are doing series of
small fixes) and more flexibility for branching (you don't want to merge
binaries).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] git-cvsexportcommit.perl: git-apply no longer needs --binary
From: Robin Rosenberg @ 2007-10-16 21:20 UTC (permalink / raw)
To: Michael Witten; +Cc: Johannes Schindelin, git
In-Reply-To: <19B03C18-6BBD-4F67-93DC-37B422445C82@mit.edu>
tisdag 16 oktober 2007 skrev Michael Witten:
>
> On 16 Oct 2007, at 9:04:34 AM, Johannes Schindelin wrote:
>
> > Hi,
> >
> > does --binary hurt?
>
> It's a no op according to the documentation.
>
> In my experience, the healthier the trees are,
> the healthier the forest is.
>
> Michael Witten
So all this series does is... making it harder to follow the history?
Ack for removing the --binary, the rest is just noise, and the remove tempdir
patch should be attributed to Johannes since he wrote the patch (ack to that one
too, which he wrote and submitted exactly two minutes ahead of me, just enough
for me not to submit it.).
-- robin
^ permalink raw reply
* Re: [PATCH] cvsexportcommit: get rid of temporary directory
From: Robin Rosenberg @ 2007-10-16 21:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, hjemli, gitster
In-Reply-To: <Pine.LNX.4.64.0710152332230.25221@racer.site>
tisdag 16 oktober 2007 skrev Johannes Schindelin:
>
> Since commit e86ad71fe5f53ae4434566bd09ea4256090e5a3a we do not use
> a temporary directory in cvsexportcommit. So there is no need to set
> one up.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked
Discovered because Wingit made a lot of noise about $tmpdir being used only
once.
-- robin
^ permalink raw reply
* Re: Some git mv questions
From: Jan Wielemaker @ 2007-10-16 21:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Lars Hjemli, git list
In-Reply-To: <alpine.LFD.0.999.0710161030430.6887@woody.linux-foundation.org>
On Tuesday 16 October 2007 19:34, Linus Torvalds wrote:
> On Tue, 16 Oct 2007, Lars Hjemli wrote:
> > On 10/16/07, Jan Wielemaker <wielemak@science.uva.nl> wrote:
> > > * On a somewhat bigger test I moved a large directory using
> > > "git mv dir newdir" (where newdir is an existing directory).
> > > Now "git status" gives a lot of new and deleted files!?
> >
> > You could try to adjust diff.renameLimit in .git/config
>
> Yes. The default rename limit I did has turned out to be a disaster. It's
> quite common to have more than a 100x100 matrix of deleted files.
>
> For people with any kind of beefy hardware, I'd just suggest doing a
>
> git config --global diff.renamelimit 0
>
> which disables the rename limiting entirely.
>
> There's a related (embarrassing) problem, namely that I think that the
> current released versions (1.5.3.3 and 1.5.3.4) don't honor the
> renamelimit configuration for merging, so if you do merges across renames
> with changes to the renamed files, you need to use either an older git
> that didn't have the rename limit at all (nor any of the speed-ups) or you
> need to use current git from the 'master' branch.
Thanks both of you. I can master that. I understand I only should ensure
to be running the latest version if I start the merge?
Cheers --- Jan
^ permalink raw reply
* Re: remote#branch
From: Jan Hudec @ 2007-10-16 21:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <Pine.LNX.4.64.0710161139530.25221@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]
On Tue, Oct 16, 2007 at 11:49:58 +0100, Johannes Schindelin wrote:
> In related news, I recently thought about the url#branch issue.
>
> There were three arguments against it AFAIR: "#" is a comment marker, and
> this syntax is not extensible to more than one branch names. And that the
> branch name is not really a part of the URL.
>
> Turns out that I am not so sure about the last two issues.
>
> It is easily extensible to more than one branch by remote#branch1#branch2,
> and in a very real sense, this is a resource locator.
>
> And we could replace the "#" by every character that is illegal in ref
> names as well as URLs. I propose SPC. ('#' is allowed in refnames.)
It's a question, whether the branch name is part of the URI, or a fragment.
Current usage suggests it is a fragment, but according to the URL
specification that is supposed to mean that the resource is always accessed
the same (fragment is NOT part of the URL) and the fragment only affects
local handling. Which I don't think is really true.
If it is a fragment, than "#" is the only correct separator and should stay
that way.
If it is not a true fragment, than we might want to phase it out in favor of
something else. But I would strongly prefer staying within characters allowed
in URI (as per rfc2396). We could consider whether the branch is not
a component parameter -- which would imply ";" as separator, but I would vote
against that on the basis that it's shell special. Non-special characters
allowed by URL in this context would be ":", "@", "=", "+", and ",", of which
":" or "@" seem best to me.
As for multiple branches, separating them with "," feels logical to me, no
matter what separates them from the repository path. On the other hand given
that neither ":" nor "@" is allowed in refnames, reusing the same separator
would make sense especially if git switched to either of those.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: On Tabs and Spaces
From: Sam Ravnborg @ 2007-10-16 20:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jari Aalto, git
In-Reply-To: <alpine.LFD.0.999.0710161214530.6887@woody.linux-foundation.org>
On Tue, Oct 16, 2007 at 12:20:50PM -0700, Linus Torvalds wrote:
>
> The answer is *also* not "tabs are just for initial code
> indents", because not only will most sane editors never even show the
> difference, it's simply not how people work. So such a rule about
> invisible things doesn't work.
It is insane to *require* diciplined people to use tabs for more than
code indents.
If you insist on using tabs all over the place - fine with me.
But do not frown upon me and other diciplined people becasue we use
spaces to make sure our arguments to a function call is properly
aligned in a tab=10,tab=8,tab=2 environment.
The arguments "tabs are always 8 spaces properly aligned" is just
to reach the lowest common denominator around developers.
And frankly there are some that do better than that.
The root casue are the stupid editors that does not make it
easy to be diciplined and thats where the errors come from
and all the stupid rules like the above.
Sam
^ permalink raw reply
* RE: linux-2.6.git mirror
From: Medve Emilian-EMMEDVE1 @ 2007-10-16 20:47 UTC (permalink / raw)
To: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E2701684C77@az33exm24.fsl.freescale.net>
> I'm trying to setup a mirror of your Linux tree with git 1.5.3.1 and
> v2.6.23-5054-g821f3ef and I get the following error during this
> scenario:
Instead of v2.6.23-5054-g821f3ef please read v1.5.3.4-206-g58ba4f6.
^ permalink raw reply
* Re: [PATCH] tail -n not supported in all OSs
From: Florian Weimer @ 2007-10-16 20:37 UTC (permalink / raw)
To: git
In-Reply-To: <1192553837-18302-1-git-send-email-jari.aalto@cante.net>
* Jari Aalto:
> $ uname -a
> SunOS host 5.9 Generic_118558-35 sun4u sparc SUNW,Serverblade1
>
> $ echo | tail -n 1
>
> usage: tail [+/-[n][lbc][f]] [file]
> tail [+/-[n][l][r|f]] [file]
What about /usr/xpg4/bin/tail? Why aren't you using that?
^ permalink raw reply
* Re: On Tabs and Spaces
From: Matthieu Moy @ 2007-10-16 20:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Mike Hommey, Jari Aalto, git
In-Reply-To: <alpine.LFD.0.999.0710161240510.6887@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, 16 Oct 2007, Mike Hommey wrote:
>>
>> Actually, part of the mess with tabs is due to the fact they're not
>> exactly 8 spaces wide, but any width that ends at a multiple of 8
>> characters from the start of the line. So 0 <= n < 8 spaces and a tab
>> is still 8 spaces.
>
> Umm.. That's the definition of "tab width".
>
> The tab width is 8. Not "0 < n <= 8". Not "depends on where you are". The
> tab width is 8.
Read better before replying, and I'm sure you'll agree with Mike ...
--
Matthieu
^ permalink raw reply
* Re: What's cooking in git/spearce.git (topics)
From: Theodore Tso @ 2007-10-16 19:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0710161209480.25221@racer.site>
On Tue, Oct 16, 2007 at 12:16:28PM +0100, Johannes Schindelin wrote:
>
> first let me thank you for being the interim maintainer. I know it is
> much work, and I frankly do not have the time, or nerve, to do it. Out of
> curiousity: did you use the scripts in "todo" to send these emails?
I've recently started trying to use some of the scripts in "todo" to
send similar "What's cooking" messages, and started wondering if they
were what Junio actually used in production to send his notes. For
example, the scripts don't work particularly well if the refs have
been packed. So I had to make changes such as these so they would
work for me.
I was waiting for Junio to get back from vacation to ask if he was
interested in accepting such changes, and/or changes to make the
scripts more general purpose, and possibly useful for other projects.
- Ted
diff --git a/PU b/PU
index 4b4be2b..4643a42 100755
--- a/PU
+++ b/PU
@@ -26,8 +26,8 @@ case "$#" in
0)
# interactive ;-)
shift
- HH=`cd .git/refs/heads && find -type f |
- sed -e 's/^\.\///' \
+ HH=`git-show-ref --heads | awk '{print $2}' |\
+ sed -e 's;refs/heads/;;' \
-e '/^naster$/d' -e '/^master$/d' -e '/^maint$/d' -e '/^pu$/d'`
while test "$HH"
do
diff --git a/RB b/RB
index 918a372..a890cfd 100755
--- a/RB
+++ b/RB
@@ -3,9 +3,9 @@
master_sha1=`git rev-parse --verify refs/heads/master`
LF='
'
-(cd .git/refs/heads && find -type f) |
+git-show-ref --heads | awk '{print $2}' |
sed -n \
- -e 's/^\.\///' \
+ -e 's;refs/heads/;;' \
-e '/^[^\/][^\/]\//p' |
while read topic
do
^ permalink raw reply related
* linux-2.6.git mirror
From: Medve Emilian-EMMEDVE1 @ 2007-10-16 20:27 UTC (permalink / raw)
To: git
Hi Linus,
I'm trying to setup a mirror of your Linux tree with git 1.5.3.1 and
v2.6.23-5054-g821f3ef and I get the following error during this
scenario:
$ mkdir linux
$ cd linux
$ git --bare init --shared=all
Initialized empty shared Git repository in /home/emmedve1/linux/
$ git remote add --mirror -f origin
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
$ git fsck --full --strict <- all fine
$ git remote update
Updating origin
error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a
commit
error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a
commit
$ git fsck --full --strict <- all fine
The situation is similar with the git tree:
error: Object a0e7d36193b96f552073558acf5fcc1f10528917 is a blob, not a
commit
Other repositories (sparse for example) don't necessarily expose this,
but I didn't test too many. This situation doesn't seem to surface for
non-bare clones. I searched a bit the web for this, but nothing obvious
showed up.
Is this something I should be worried about?
Thanks for your patience,
Emil.
^ permalink raw reply
* Re: What's in git/spearce.git (stable)
From: Michele Ballabio @ 2007-10-16 20:28 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <20071016055634.GB13801@spearce.org>
On Tuesday 16 October 2007, Shawn O. Pearce wrote:
> * The 'maint' branch has these fixes since the last announcement.
There are typos in RelNotes-1.5.3.5.txt:
s/wilh/will
s/Documention/Documentation
^ permalink raw reply
* Re: On Tabs and Spaces
From: Tom Tobin @ 2007-10-16 20:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710161214530.6887@woody.linux-foundation.org>
On Tue, 2007-10-16 at 12:20 -0700, Linus Torvalds wrote:
> The only sane solution is the one the kernel and git have always used:
> tabs are 8 spaces wide, and anybody who disagrees can go screw themselves.
> If you don't have 8-character tabs, you *will* get odd indentation.
>
> And no, the answer is not to say "don't use tabs at all" and replace them
> by spaces. The answer is *also* not "tabs are just for initial code
> indents", because not only will most sane editors never even show the
> difference, it's simply not how people work. So such a rule about
> invisible things doesn't work.
[...]
> The fact that some projects have encouraged bad coding style and *insane*
> tab values is not a git problem. We should teach people to do *better*,
> not become worse just because others have done idiotic things.
I'm reading two different ideas here, and it seems like you're
conflating the two — and, in the process, telling some pretty smart
people (smarter than me, anyhow) to go fuck themselves.
If a project uses tabs, your statement regarding 8-char-width tabs makes
sense; you need some rule by which you can assume others are viewing the
same thing you are.
But you then dismiss out of hand the option of using all spaces; Python
has been getting along perfectly well for quite some time by following
this rule, and my experience with the language leads me to believe it's
the wiser of the choices. Questions over tab width simply *go away*;
you pick an indentation level (Python uses 4) and stick with it.
I'm not arguing that git should switch to all spaces; projects tend to
become set in their ways, and consistency can be valuable. I'm merely
pointing out that all-spaces is a quite *sane* option, even if it's one
git doesn't choose.
^ permalink raw reply
* Re: Git User's Survey 2007 summary - git homepage improvements
From: Jan Hudec @ 2007-10-16 20:12 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Jakub Narebski, git, Petr Baudis
In-Reply-To: <20071014225618.GH31659@planck.djpig.de>
[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]
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
> > to have it look less like mirror or unofficial page
> >
> > (git.or.cz still comes first when searching Google for "git";
> > current domain name was available to homepage admin - historical
> > reason)
>
> Hmm, I guess most names that would qualify are already taken
> (most of them by squatters, though). So someone
> would have to pay money for this...
> (And I guess something like git-scm.org wouldn't qualify as more
> "official", would it?)
It certainly would. It would be 2nd level domain, not a 3rd level one.
Note, that none of the other vcs' have a homepage at theirname.org --
subversion is svn.tigris.org, bazaar is bazaaz-vcs.org, mercurial is
www.selenic.com/mercurial, svk is svk.bestpractical.com, monotone is
monotone.ca. So git-vcs.org would be quite good.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-send-email: add a new sendemail.to configuration variable
From: Miklos Vajna @ 2007-10-16 20:05 UTC (permalink / raw)
To: git
In-Reply-To: <1191242562-27486-1-git-send-email-vmiklos@frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 299 bytes --]
On Mon, Oct 01, 2007 at 02:42:42PM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> Several projects prefers to receive patches via a given email address. In these
> cases it's handy to configure that address once.
could somebody please comment this patch? does it look ok?
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-16 19:51 UTC (permalink / raw)
To: Mike Hommey; +Cc: Jari Aalto, git
In-Reply-To: <alpine.LFD.0.999.0710161240510.6887@woody.linux-foundation.org>
On Tue, 16 Oct 2007, Linus Torvalds wrote:
>
> But when it comes to computers, 8-character wide tab stops is the
> de-facto standard. It's what every single terminal defaults to. It's the
> only thing that some printers/terminals support. Anything else is by
> definition non-standard.
Side note: one reason you *have* to use 8-character wide tab stops if you
want to be sane is that while your editor may have alternate tab-stops,
but when you look at the sources any other ways or on any other setup, the
default is *always* going to be that 8-character wide tab-stop.
Do a "git cat-file -p :Makefile", and it will default to using "less".
Have you added "-x2" to you LESS environment variable? Has everybody else?
Not likely.
Or what happens when you just cat it straight, without any less at all?
In short: using anything but 8-char wide tab-stops is INSANE, because it
will inevitably showing the same source code in different ways depending
on which editor or other environment you use.
In contrast, if you just accept that 8-wide tabs are a fact, you never see
any of these issues. Everything "just works".
Linus
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-16 19:47 UTC (permalink / raw)
To: Mike Hommey; +Cc: Jari Aalto, git
In-Reply-To: <20071016193605.GA829@glandium.org>
On Tue, 16 Oct 2007, Mike Hommey wrote:
>
> Actually, part of the mess with tabs is due to the fact they're not
> exactly 8 spaces wide, but any width that ends at a multiple of 8
> characters from the start of the line. So 0 <= n < 8 spaces and a tab
> is still 8 spaces.
Umm.. That's the definition of "tab width".
The tab width is 8. Not "0 < n <= 8". Not "depends on where you are". The
tab width is 8.
The whole history of tab is that it comes from mechanical "tab stops" that
you could set, and that were independent of the text - pressing the tab
key would move to the next tab stop.
Now, those tab stops were movable, and in fact, I think lots of terminals
still support setting those tab stops dynamically (ie you can send control
sequences to set their "tab stops" to different points, exactly like an
old mechanical typewriter).
But when it comes to computers, 8-character wide tab stops is the
de-facto standard. It's what every single terminal defaults to. It's the
only thing that some printers/terminals support. Anything else is by
definition non-standard.
Linus
^ permalink raw reply
* Re: On Tabs and Spaces
From: Mike Hommey @ 2007-10-16 19:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jari Aalto, git
In-Reply-To: <alpine.LFD.0.999.0710161214530.6887@woody.linux-foundation.org>
On Tue, Oct 16, 2007 at 12:20:50PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 16 Oct 2007, Jari Aalto wrote:
>
> > * Tue 2007-10-16 Michael Witten <mfwitten AT MIT.EDU>
> > >
> > > However, 8 spaces per tab is a lot of wasted
> > > information to be bandying about.
> >
> > Spaces are guaranteed to interpreted correctly in all environments. TABs
> > are the source of too many problems.
>
> No.
>
> Tabs are 8 spaces wide. Live with it. It's the only sane solution.
Actually, part of the mess with tabs is due to the fact they're not
exactly 8 spaces wide, but any width that ends at a multiple of 8
characters from the start of the line. So 0 <= n < 8 spaces and a tab
is still 8 spaces.
Anyways, it's maybe just simpler to run indent before sending patches.
Mike
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Linus Torvalds @ 2007-10-16 19:28 UTC (permalink / raw)
To: Jan Hudec; +Cc: Pete/Piet Delaney, VMiklos, free cycle, git
In-Reply-To: <20071016191549.GG26127@efreet.light.src>
On Tue, 16 Oct 2007, Jan Hudec wrote:
>
> Kompare (KDE analog of meld) can. It is even bound to text/x-diff in
> konqueror, so opening patches with konqueror yields side-by-side diff view.
> On the other hand it still keeps a unixy behaviour:
> git diff | kompare -
> works.
Side note: I think kompare is beautiful, but kompare does one thing
totally wrong: it seems to think that you only want to look at the diff
fragments one file at a time.
That's totally bogus. My trivial four-liner shell script does this better
than kompare does - as does "gitk" in the diff view window.
The fact is, quite often you have diffs that are lots of small changes to
tons of files, and the kompare interface is totally ludicrous and useless.
It would be *much* nicer to literally show them as one long flowing diff.
And yes, it will depend on circumstances, but I can't seem to even find
the config option to not do that. As a result, you have to click through
all the files manually (even the "Next file" thing is grayed out when I do
the "git diff | kompare -", so I can't even use the keyboard shortcut to
go to the next file).
So I have to say, after playing with it, my shell-script "viewdiff" is
actually infinitely better than "kompare -" is, at least for my workflow.
Linus
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-16 19:20 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <3awb7zw6.fsf@blue.sea.net>
On Tue, 16 Oct 2007, Jari Aalto wrote:
> * Tue 2007-10-16 Michael Witten <mfwitten AT MIT.EDU>
> >
> > However, 8 spaces per tab is a lot of wasted
> > information to be bandying about.
>
> Spaces are guaranteed to interpreted correctly in all environments. TABs
> are the source of too many problems.
No.
Tabs are 8 spaces wide. Live with it. It's the only sane solution.
The fact is, people do mix the two. No ifs, buts or maybes about it. Even
in the absense of any actual *spaces*, the size of a tab matters, since
you can - and do - have two separately indented things (the initial
indentation, and then things like comments being indented separately).
The only sane solution is the one the kernel and git have always used:
tabs are 8 spaces wide, and anybody who disagrees can go screw themselves.
If you don't have 8-character tabs, you *will* get odd indentation.
And no, the answer is not to say "don't use tabs at all" and replace them
by spaces. The answer is *also* not "tabs are just for initial code
indents", because not only will most sane editors never even show the
difference, it's simply not how people work. So such a rule about
invisible things doesn't work.
People who want to be contrary, and have a 2-character-wide tab only have
themselves to blame. It's THEIR problem, not somethign that is even worth
trying to address.
If there are problems with people having small screens, that is damn well
not about TAB, it's about code being way too deeply indented, and smaller
indents are absolutely *not* the answer - they are part of the damn
problem to begin with.
The fact that some projects have encouraged bad coding style and *insane*
tab values is not a git problem. We should teach people to do *better*,
not become worse just because others have done idiotic things.
Linus
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Jan Hudec @ 2007-10-16 19:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pete/Piet Delaney, VMiklos, free cycle, git
In-Reply-To: <alpine.LFD.0.999.0710151711280.6887@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]
On Mon, Oct 15, 2007 at 17:45:44 -0700, Linus Torvalds wrote:
> I don't actually know of any sane programs to view unified diffs, but you
> can script one with little trouble. Here's a really hacky one I just came
> up with:
>
> #!/bin/sh
> cat "$@" > /tmp/diff
> grep '^[ -]' /tmp/diff > /tmp/orig
> grep '^[ +]' /tmp/diff > /tmp/result
> meld /tmp/orig /tmp/result
>
> which fools 'meld' into showing a unified diff in a nice graphical manner.
>
> [ Quite frankly, I don't understand why tools like meld and kdiff3 can't
> just take the unified diff directly - they have *all* the logic, it
> should be trivial to do, and very useful to view diffs for those people
> who like that graphical bling. ]
Kompare (KDE analog of meld) can. It is even bound to text/x-diff in
konqueror, so opening patches with konqueror yields side-by-side diff view.
On the other hand it still keeps a unixy behaviour:
git diff | kompare -
works.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: On Tabs and Spaces
From: Jan-Benedict Glaw @ 2007-10-16 18:34 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Jeffrey C. Ollie, Adam Piatyszek, Lars Hjemli, Michael Witten,
git
In-Reply-To: <4714F3A2.3080103@op5.se>
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
On Tue, 2007-10-16 19:23:46 +0200, Andreas Ericsson <ae@op5.se> wrote:
> Jeffrey C. Ollie wrote:
> > On Tue, 2007-10-16 at 12:16 +0200, Adam Piatyszek wrote:
> > > And if one change the tab size, it will result in a messy alignment in
> > > line 5.
> >
> > Which is why one should never should change the tab size from anything
> > but 8.
>
> I have mine set to 4. With an 11.2" screen and 1024x768 resolution, it's
You fir 768 lines of text and 1024 chars per line to such a small
display and still argue about too large tabs?
SCNR, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: Ich hatte in letzter Zeit ein bißchen viel Realitycheck.
the second : Langsam möchte ich mal wieder weiterträumen können.
-- Maximilian Wilhelm (18. Mai 2006, #lug-owl.de)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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