* Re: Some git mv questions
From: Linus Torvalds @ 2007-10-16 17:34 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jan Wielemaker, git list
In-Reply-To: <8c5c35580710160905v69787856m7ed11b037c1adef1@mail.gmail.com>
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.
Linus
^ permalink raw reply
* Re: On Tabs and Spaces
From: Sam Ravnborg @ 2007-10-16 17:40 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Michael Witten, Shawn O. Pearce, git
In-Reply-To: <4714F2CA.5000509@op5.se>
General comment about the <tab> versus spaces debate.
The root problem is stupid editors that does not show when a tab is used
and when spaces are used.
So people continue to mix tabs and spaces.
In linux people generally think that 8 aligned spaces equal a tab
which is IMHO stupid.
Tabs should be used for indent and not general alignment.
Consider:
<tab>if (some long condition that
<tab>....&& spans two lines) {
<tab><tab>my_private_printf("bla bla bla"
<tab><tab>.................."more bla bla\n");
<tab><tab>}
This will look good and align "more bla bla\n" as
intended no matter your tab setting.
But replacing the 8 spaces with a tab will
cause it to look bad.
And using tabs let me use the tabsetting I like (8) and other
use the tab setting they like (2,3,4,5,6,7) and all is good.
And why a tab is 8 spaces and in considered good.
Thats to teach people to write small independent functions
that does _one_ thing and does it well.
Mega functions with 6 times indent or more usually needs to
be breaked up anyway.
Sam
^ permalink raw reply
* [PATCH] GIT home page. Mentioning that Cogito is no longer maintained.
From: Paolo Ciarrocchi @ 2007-10-16 17:54 UTC (permalink / raw)
To: pasky, git
As discussed on the git mailing list
http://marc.info/?l=git&m=119252168629733&w=2
it seems to be a good idea to mention on the git home page that cogito
is no longer maintained.
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
index.html | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/index.html b/index.html
index 340aee0..5d14acf 100644
--- a/index.html
+++ b/index.html
@@ -289,12 +289,12 @@ a gitweb interface, at <a href="http://repo.or.cz/">http://repo.or.cz/</a>.</p>
<dt id="cogito">Cogito</dt>
<dd>
<a href="http://git.or.cz/cogito/">Cogito</a>
-is a popular version control system on top of Git.
-It aims at seamless user interface and ease of use, providing
-generally smoother user experience than the "raw" Git interface
-and indeed also many other version control systems. However, it
-also lacks many advanced capabilities of Git and is currently
-being slowly phased out.</dd>
+ Cogito was a popular version control system on top of Git. It aims
+at seamless user interface and ease of use, providing generally
+smoother user experience than the "raw" Git interface and indeed also
+many other version control systems. However, it also lacks many
+advanced capabilities of Git and is not actively maintained any
+longer.</dd>
<dt id="stgit">StGIT</dt>
<dd><a href="http://www.procode.org/stgit/">Stacked Git</a> provides
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: [PATCH 04/25] Rework make_usage to print the usage message immediately
From: Alex Riesen @ 2007-10-16 17:56 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Shawn O. Pearce
In-Reply-To: <1192523998-19474-4-git-send-email-madcoder@debian.org>
Pierre Habouzit, Tue, Oct 16, 2007 10:39:37 +0200:
> From: Alex Riesen <raa.lkml@gmail.com>
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
> parse-options.c | 48 ++++++++++++++++++++++--------------------------
> 1 files changed, 22 insertions(+), 26 deletions(-)
Got it three times: you put git@kernel.org into To: and Cc:
Why stderr, BTW? For instance, the output from "git help" is on
stdout. To be fair, I don't know why it is stdout there either.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Christopher Faylor @ 2007-10-16 18:06 UTC (permalink / raw)
To: 'Andreas Ericsson', barkalow, raa.lkml, make-w32, git,
'Eli Zaretskii', Dave Korn, Joh
In-Reply-To: <03f401c81010$d8833de0$2e08a8c0@CAM.ARTIMI.COM>
On Tue, Oct 16, 2007 at 05:23:11PM +0100, Dave Korn wrote:
>On 16 October 2007 16:56, David Brown wrote:
>
>> On Tue, Oct 16, 2007 at 02:25:21AM -0400, Eli Zaretskii wrote:
>>
>>> On the other hand, what packages have 100K files? If there's only one
>>> -- the Linux kernel -- then I think this kind of performance is for
>>> all practical purposes unimportant on Windows, because while it is
>>> reasonable to assume that someone would like to use git on Windows,
>>> assuming that someone will develop the Linux kernel on Windows is --
>>> how should I put it -- _really_ far-fetched ;-)
>>
>> Oh, I wish others could think this clearly. Quoting a serious line off of
>> a task list at an unnamed company:
>>
>> - Make Linux kernel compile under windows.
>>
>> I don't think it will move past just being a wish list item, but there seem
>> to be people that think it should be done.
>>
>> Admittedly, they don't want developers doing it on windows, but want to
>> integrate kernel building into a windows-heavy build and release process.
>
> Do that kind of thing here all the time, hence my previous post. Apart from
>the netfilter stuff with the filenames-that-match-in-all-but-case, no real
>problems, took me a couple of hours one afternoon.
Ditto.
Coincidentially enough this is the reason I wrote managed mode for cygwin's
mount.
But, we're pretty far off-topic aren't we?
cgf
^ permalink raw reply
* Re: git-merge performance
From: Andrew Morton @ 2007-10-16 18:18 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4714F612.2010905@op5.se>
On Tue, 16 Oct 2007 19:34:10 +0200
Andreas Ericsson <ae@op5.se> wrote:
> Andrew Morton wrote:
> > My git-pulling script (git-1.4.2) seems to have got quite a bit slower
> > since the post-2.6.23 patchflood. I just did a bit of poking and it's
> > git-merge which is taking most of the time.
> >
>
> That's odd. If it had been the remote fetching it would have been
> understandable. Is this also happening with more recent gits? I know there
> are some significant performance-improvements in 1.5.3.4 (or below).
>
1.5.0 is no faster, but 1.5.3 appears to be seven times quicker. Neato.
^ permalink raw reply
* Re: On Tabs and Spaces
From: Jari Aalto @ 2007-10-16 17:06 UTC (permalink / raw)
To: git
In-Reply-To: <B2F6DB0C-4EFE-4C56-8E7A-31820320CA02@mit.edu>
* Tue 2007-10-16 Michael Witten <mfwitten AT MIT.EDU>
* Message-Id: B2F6DB0C-4EFE-4C56-8E7A-31820320CA02 AT mit.edu
> On 16 Oct 2007, at 11:26:07 AM, Jeffrey C. Ollie wrote:
>
>> Instead of using "(setq indent-tabs-mode t)" use "(setq indent-tabs-
>> mode
>> nil)". This will force emacs to always use spaces to indent.
>
> 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.
Jari
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply
* Re: On Tabs and Spaces
From: Andreas Ericsson @ 2007-10-16 18:51 UTC (permalink / raw)
To: Jan-Benedict Glaw
Cc: Jeffrey C. Ollie, Adam Piatyszek, Lars Hjemli, Michael Witten,
git
In-Reply-To: <20071016183401.GR16774@lug-owl.de>
Jan-Benedict Glaw wrote:
> 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?
>
If by "char" you mean "pixel", then yes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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
* 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: 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: 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: 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: 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: 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: [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: 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: 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: 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
* 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 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
* 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: [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: 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: 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
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