On Sun, 2005-09-04 at 17:31 +0200, Jan Dittmer wrote:
> David Woodhouse wrote:
> > On Fri, 2005-09-02 at 02:00 -0700, Linus Torvalds wrote:
> >
> >>Ahh. Please change that to
> >>
> >>rm -rf tmp-empty-tree
> >>mkdir tmp-empty-tree
On Wed, 2005-08-31 at 15:34 +0200, Tomasz K³oczko wrote:
> Seems patches stored on ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots
> are empty (only logs are correct):
> -rw-r--r--1 536 53620 Aug 30 09:01 patch-2.6.13-git1.gz
> -rw-r--r--1 536 53620 A
On Wed, 2005-07-27 at 08:29 -0700, Linus Torvalds wrote:
> I used to think I wanted to, but these days I really don't. One of the
> reasons is that I expect to try to pretty up the old bkcvs conversion some
> time: use the name translation from the old "shortlog" scripts etc, and
> see if I can do
On Tue, 2005-07-26 at 11:57 -0700, Linus Torvalds wrote:
> If somebody adds some logic to "parse_commit()" to do the "fake parent"
> thing, you can stitch the histories together and see the end result as one
> big tree. Even without that, you can already do things like
>
> git diff v2.6.10
On Sun, 2005-07-10 at 10:31 -0700, Linus Torvalds wrote:
> No it's not, as far as I can tell:
>
> [EMAIL PROTECTED]:/home/dwmw2/git/mail-2.6(0)$ cat
> .git/branches/origin
> rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> so your scripts will go out to
On Sun, 2005-07-10 at 10:08 -0700, Linus Torvalds wrote:
> Which script is this? I'm looking at your scripts, but
> "cg-feedmaillist.sh" is unreadable for me, so I can't see all of it.
Hm. Dunno why that happened -- it's readable now, and also at
http://david.woodhou.se/cg-feedmaillist.sh
> Anywa
On Sun, 2005-07-10 at 00:38 +0100, David Woodhouse wrote:
> Doh. I thought I'd already done that, but in fact that was for the
> scripts which feed the mailing list, while the snapshot script kept
> using my copy.
Ok, the snapshot script starts working again if I change a f
On Sat, 2005-07-09 at 09:15 -0700, Linus Torvalds wrote:
> Yes, looks that way. Except it's not "git on master.kernel.org", it's "git
> in your home directory", I suspect. I expressly held off packing the
> kernel repo until git had been updated on kernel.org.
Doh. I thought I'd already done tha
Does git on master.kernel.org need to be updated to handle packed
objects? See attached.
Linus, please could you add the snapshot script to your regression
testing? http://david.woodhou.se/git-snapshot.sh
It'd be good to keep that working without too much manual intervention.
--
dwmw2
--- Be
On Thu, 2005-04-21 at 12:29 +0200, Arjan van de Ven wrote:
> with BK this was not possible, but could we please have -p added to the
> diff parameters with git ? It makes diffs a LOT more reasable!
With BK this was not possible, but could you please provide your
criticism in 'diff -up' form?
I've
Entirely untested.
Makefile: eca3a5d5256cca06d86ebb85ec9d3218752ffcd2
applypatch: 397e4a0e506f1c5765767057dfe506154b743b83
--- a/applypatch
+++ b/applypatch
@@ -26,6 +26,7 @@ EDIT=${EDIT:-vi}
export AUTHOR_NAME="$(sed -n '/^Author/ s/Author: //p' .dotest/info)"
export AUTHOR_EMAIL="$(sed -n '/
If we just strip out the setting of $FROM and $MLIST, the script I use
to feed bk-commits-head@vger.kernel.org is perfectly generic. Petr, can
you include it in the tree so it gets updated as things change please?
--
dwmw2
gitfeedmaillist.sh
Description: application/shellscript
On Wed, 2005-04-20 at 07:59 -0700, Linus Torvalds wrote:
> external-parent
> comment for this parent
>
> and the nice thing about that is that now that information allows you to
> add external parents at any point.
>
> Why do it like this? First off, I think that the "
On Wed, 2005-04-20 at 02:08 -0700, Linus Torvalds wrote:
> I converted my git archives (kernel and git itself) to do the SHA1
> hash _before_ the compression phase.
I'm happy to see that -- because I'm going to be asking you to make
another change which will also require a simple repository conver
On Tue, 2005-04-19 at 23:00 +1000, Paul Mackerras wrote:
> Is there a way to check out a tree without changing the mtime of any
> files that you have already checked out and which are the same as the
> version you are checking out? It seems that checkout-cache -a doesn't
> overwrite any existing f
On Mon, 2005-04-18 at 18:12 -0700, Greg KH wrote:
> Ok, then why display it as one?
Nobody ever displays it as one as far as I'm aware. That would be
something like "mailto:$COMMITTER";
> But I'll wait for Russell to wake up and start quoting the proper EU
> privacy laws that he feels causes him
On Mon, 2005-04-18 at 17:45 -0700, Greg KH wrote:
> Well Russell has stated that he has to for EU Privacy reasons. And I'd
> like to do it as I don't have a local suse.de hostname for my laptop and
> my employer probably doesn't really want my [EMAIL PROTECTED] address
> showing up :)
Why not? Do
On Mon, 2005-04-18 at 19:16 -0500, James Bottomley wrote:
> Yes, that's what I did to get back to the commit just before the
> merge:
>
> fsck-cache --unreachable 54ff646c589dcc35182d01c5b557806759301aa3|awk
> '/^unreachable /{print $2}'|sed 's:^\(..\):.git/objects/\1/:'|xargs rm
I was actually d
On Mon, 2005-04-18 at 17:03 -0700, Linus Torvalds wrote:
> Git does work like BK in the way that you cannot remove history when you
> have distributed it. Once it's there, it's there.
But older history can be pruned, and there's really no reason why an
http-based 'git pull' couldn't simply refrain
On Mon, 2005-04-18 at 12:36 +0200, Martin Schlemmer wrote:
> realgecos[strchr(realgecos, ',') - realgecos] = '\0';
Er, *strchr(realgecos, ',') = 0; surely? Even if the compiler is clever
enough to optimise out the gratuitous addition and subtraction, that's
no real excuse for it.
--
dwmw2
-
To
On Mon, 2005-04-18 at 12:27 +0200, Petr Baudis wrote:
> Yes. As far as I'm concerned, I'd put such stuff to git log, and extend
> it usage so that it is possible to print individual log entries with it
> - just make it accept a _range_ of commits, and then do
>
> git log $commit $commit
T
Add tool to render git's " " into an RFC2822-compliant
string, because I don't think date(1) can do it. Use same for 'git log'
output.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
--- Makefile
+++ Makefile2005-04-18 15:40:43.0 +1000
@@ -1
On Sun, 2005-04-17 at 18:15 -0700, Linus Torvalds wrote:
> In particular, is there some easy way to walk backwards by time? "git log"
> definitely needs that, and merge-base clearly wants something similar.
Actually the ideal output of 'git log' isn't strictly chronological.
IIRC my bkexport sc
On Sun, 2005-04-17 at 18:16 -0700, Linus Torvalds wrote:
> Alternatively, you can have just the rev-tree cache of them. That's what
> it was designed for (along with avoiding to have to read 60,000 commits).
Purely from a conceptual POV I'd be a little happier with the history
just ending with a p
On Mon, 2005-04-18 at 02:50 +0200, Petr Baudis wrote:
> I think I will make git-pasky's default behaviour (when we get
> http-pull, that is) to keep the complete commit history but only trees
> you need/want; togglable to both sides.
I think the default behaviour should probably be to fetch everyt
On Mon, 2005-04-18 at 02:35 +0200, Petr Baudis wrote:
> > For the special case of removing history before 2.6.12-rc2 from the
> > trees, I certainly think we can do it by leaving out all the commits,
> > not just the trees. We can do that easily, but there's no way we can
> > _add_ that history ret
On Mon, 2005-04-18 at 01:39 +0200, Petr Baudis wrote:
> I think this is bad, bad, bad. If you don't keep around all the
> _commits_, you get into all sorts of troubles - when merging, when doing
> git log, etc. And the commits themselves are probably actually pretty
> small portion of the thing. I
On Sun, 2005-04-17 at 19:25 -0400, jeff millar wrote:
> ln -sf /lib/modules/`uname -r`/build/include/linux
> /usr/local/include/linux
>
> This fix creates a symlink, on each boot up, in the local include
> directory that points to the kernel header files. If there's a better
> way to do thi
On Sat, 2005-04-16 at 10:04 -0700, Linus Torvalds wrote:
> So I'd _almost_ suggest just starting from a clean slate after all.
> Keeping the old history around, of course, but not necessarily putting it
> into git now. It would just force everybody who is getting used to git in
> the first place
On Sun, 2005-04-17 at 15:22 -0700, randy_dunlap wrote:
> David did the commits-mailing-list script and I'm working on a
> commits web-page like what was formerly seen at:
> http://www.kernel.org/pub/linux/kernel/v2.6/testing/cset/
> (with daily tarball)
>
> based on some older scripts from David,
On Sat, 2005-04-16 at 16:01 -0700, Linus Torvalds wrote:
> So I re-created the dang thing (hey, it takes just a few minutes), and
> pushed it out, and there's now an archive on kernel.org in my public
> "personal" directory called "linux-2.6.git". I'll continue the tradition
> of naming git-archive
On Sat, 2005-04-16 at 17:33 +0200, Johannes Schindelin wrote:
> > But if it can be done cheaply enough at a later date even though we end
> > up repeating ourselves, and if it can be done _well_ enough that we
> > shouldn't have just asked the user in the first place, then yes, OK I
> > agree.
>
>
On Fri, 2005-04-15 at 08:32 -0700, Linus Torvalds wrote:
> - you're doing the work at the wrong point. Doing it _well_ is quite
>expensive. So if you do it at commit time, you cannot _afford_ to do it
>well, and you'll always fall back to doing an ass-backwards job that
>doesn't rea
On Fri, 2005-04-15 at 07:53 -0700, Linus Torvalds wrote:
> Files DO NOT matter. Never have. It's an implementation limitation to
> think they do. You'll screw yourself up, and when somebody comes up with a
> half-way efficient way to generate inter-fiel diffs, your architecture is
> totally and
On Fri, 2005-04-15 at 16:53 +0200, Ingo Molnar wrote:
> but the specific scenario you described would require _Linus'_ tree to
> be in limbo for a long time, and have uncommitted half-done edits.
> I.e.:
>
>(A1B2)--(A2B2)--(A2'B3)
> / \ /\
>/\ / \
> (A1
On Fri, 2005-04-15 at 13:37 +, [EMAIL PROTECTED] wrote:
> > One option for optimising this, if we really need to, might be to track
> > the file back to its _first_ ancestor and use that as an identification.
> > The SCM could store that identifier in the blob itself, or we could
> > consider i
On Fri, 2005-04-15 at 11:36 +0200, Ingo Molnar wrote:
> do such cases occur frequently? In the kernel at least it's not too
> typical.
Isn't it? I thought it was a fairly accurate representation of the
process "I make a whole bunch of changes to files I maintain, pulling
from Linus while occasio
On Thu, 2005-04-14 at 17:42 -0700, Linus Torvalds wrote:
> I've not even been convinved that renames are worth it. Nobody has
> really given a good reason why.
>
> There are two reasons for renames I can think of:
>
> - space efficiency in delta-based trees.
> - "annotate".
Neither of those we
On Thu, 2005-04-14 at 11:36 -0700, Linus Torvalds wrote:
> And "merge these two trees" (which works on a _tree_ level)
> or "find the common commit" (which works on a _commit_ level)
I suspect that finding the common commit is actually a per-file thing;
it's not just something you do for the _comm
On Thu, 2005-04-14 at 18:23 -0400, Daniel Barkalow wrote:
> I personally think renames are a minor thing that doesn't happen
> much. What actually happens, in my opinion, is that some chunk of a
> file is moved to a different, possibly new, file. If this is supported
> (as something that the SCM no
On Thu, 2005-04-14 at 14:01 -0700, H. Peter Anvin wrote:
> Both of these are metadata; they may not be directly relevant to the
> filesystem, but are attributes relevant to the client thereof;
> effectively an xattr.
Right. That's perfectly acceptable -- and that's the reason why I think
it's al
On Thu, 2005-04-14 at 12:42 -0700, Luck, Tony wrote:
> This is a very good point ... but this still has problems with the
> "git is a filesystem, not a SCM" mantra. Timezone comments don't
> belong in the git inode.
Yeah, but really I'd want to see other serious users of it before I'd
accept that
On Thu, 2005-04-14 at 12:19 -0700, [EMAIL PROTECTED] wrote:
> With a UTC date, why would anyone care in which timezone the commit was
> made? Any pretty printing would most likely be prettiest if it is done
> relative to the timezone of the person looking at the commit record, not
> the person who
On Thu, 2005-04-14 at 20:58 +0200, Ingo Molnar wrote:
> The thing i tried to avoid was to list long filenames in the commit
> (because of the tree hierarchy we'd need to do tree-absolute pathnames
> or something like that, and escape things, and do lookups - duplicating
> a VFS which is quite ba
; > So a commit involving a rename would look something like this...
> >
> > tree 82ba574c85e9a2e4652419c88244e9dd1bfa8baa
> > parent bb95843a5a0f397270819462812735ee29796fb4
> > rename foo.c bar.c
> > author David Woodhouse <[EMAIL PROTECTED]&
e perfectly sufficient.
So a commit involving a rename would look something like this...
tree 82ba574c85e9a2e4652419c88244e9dd1bfa8baa
parent bb95843a5a0f397270819462812735ee29796fb4
rename foo.c bar.c
author David Woodhouse <[EMAIL PROTECTED]> 1113499
On Thu, 2005-04-14 at 02:12 -0700, Linus Torvalds wrote:
> I take that back. I'd be much happier with you doing and testing it,
> because now I'm crashing.
OK. commit-tree now eats RFC2822 dates as AUTHOR_DATE because that's
what you're going to want to feed it. We store seconds since UTC epoch,
On Thu, 2005-04-14 at 02:00 -0700, Linus Torvalds wrote:
> I do like text output, but if it is painful, the "unix seconds" format is
> certainly a hell of a lot simpler. And quite frankly, if we change it, we
> might as well just change it all the way. So I'd almost prefer (1).
Text _output_ is
The date handling is somewhat unreliable. We render dates into textual
representation using the committer's locale (day names, etc), then later
attempt to interpret that in some other locale. And we were just using
localtime without even specifying the timezone so the timestamp was
fairly randomise
49 matches
Mail list logo
