* [RFC] Another way to provide help details. (was Re: [PATCH] Add help details to git help command.)
From: Steven Cole @ 2005-04-19 1:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <4263E782.6040608@mesatop.com>
On Monday 18 April 2005 10:59 am, Steven Cole wrote:
> Petr Baudis wrote:
> > Dear diary, on Mon, Apr 18, 2005 at 06:42:26AM CEST, I got a letter
> > where Steven Cole <elenstev@mesatop.com> told me that...
> [snippage]
> >
> >>This patch will provide the comment lines in the shell script associated
> >>with the command, cleaned up a bit for presentation.
> >>
> >>BUGS: This will also print any comments in the entire file, which may
> >>not be desired. If a command name and shell script filename
> >>do not follow the usual convention, this won't work, e.g. ci for commit.
> >
> >
> > Hey, those BUGS are the only slightly non-trivial thing on the whole
> > thing! I could do this patch myself... ;-) Also, you don't want to print
> > the first newline and the Copyright notices.
Here is perhaps a better way to provide detailed help for each
git command. A command.help file for each command can be
written in the style of a man page.
The modfication to the main git script will be trivial.
Here are the two commands I've done so far.
What do folks think about this approach?
Steven
[steven@spc git-pasky]$ ./git help add
NAME
add - Add new file or files to a GIT repository.
SYNOPSIS
add FILE...
DESCRIPTION
Takes a list of file names at the command line, and schedules them
for addition to the GIT repository at the next commit.
AUTHOR
Written by Petr Baudis.
REPORTING BUGS
Report bugs to <git@vger.kernel.org>
COPYRIGHT
Copyright (c) Petr Baudis, 2005
BUGS
Those files are omitted from show-diff output!
SEE ALSO
The source code for this command is gitadd.sh.
[steven@spc git-pasky]$ ./git help addremote
NAME
addremote - Add new "remote" to the GIT repository.
SYNOPSIS
addremote RNAME RSYNC_URL
DESCRIPTION
Takes the remote's name and rsync URL.
After you add a remote, you can "git pull" it whenever you want
and it will keep your dircache in sync with it. Its latest commit
is accessible as .git/heads/remotename (or - more conveniently -
as $(commit-id remotename)). For example, to make a diff between
Linus (after you added him) and your current tree, do
git pull linus
git diff $(commit-id linus)
AUTHOR
Written by Petr Baudis.
REPORTING BUGS
Report bugs to <git@vger.kernel.org>
COPYRIGHT
Copyright (c) Petr Baudis, 2005
TODO
gitdiff.sh et al should accept remote names as ids.
SEE ALSO
The source code for this command is gitaddremote.sh.
^ permalink raw reply
* Re: [darcs-devel] Darcs and git: plan of action
From: Ray Lee @ 2005-04-19 1:43 UTC (permalink / raw)
To: Juliusz Chroboczek; +Cc: darcs-devel, Git Mailing List, Linus Torvalds
In-Reply-To: <7iy8bf7fh2.fsf@lanthane.pps.jussieu.fr>
On Tue, 2005-04-19 at 02:55 +0200, Juliusz Chroboczek wrote:
> > But avoiding "mv" patches would be downright silly.
>
> Aye, that will require some metadata on the git side (the hack,
> suggested by Linus, of using git hashes to notice moves won't work).
Okay, I'm coming to believe I missed something. So, why won't it work?
Ray
^ permalink raw reply
* Re: [darcs-devel] Darcs and git: plan of action
From: Ray Lee @ 2005-04-19 1:42 UTC (permalink / raw)
To: Kevin Smith; +Cc: git, darcs-devel
In-Reply-To: <42645969.2090609@qualitycode.com>
On Mon, 2005-04-18 at 21:05 -0400, Kevin Smith wrote:
> >>The other is "replace very instace of identifier `foo` with identifier`bar`".
> > That could be derived, however, by a particularly smart parser [1].
>
> No, it can't. Seriously. A darcs replace patch is encoded as rules, not
> effects, and it is impossible to derive the rules just by looking at the
> results. Not difficult. Impossible.
Okay, either I'm a sight stupider than I thought, or I'm not
communicating well. Same net effect either way, I 'spose.
If I do a token replace in an editor (say one of those fancy new-fangled
refactoring thangs, or good ol' vi), a token-level comparator can
discover what I did. That link I sent is an example of one such beast.
> You could guess, but that's not good
> enough for darcs to be able to reliably commute the patches later.
Who said anything about guessing? If a user replaces all instances of
foo with bar, that's as close to proof as you can ever get, without
recording intent of the user at the time it's done. Now, I realize that
darcs *does* record intent, but I claim that's immaterial.
Perhaps I'm clueless; it's happened before, I'm resigned to it happening
again. So, tell it to me with full jargon, if you will. When it comes
down to brass tacks, why does my suggestion place weaker guarantees
about the quality of the resulting patch operator?
> > As for "darcs mv", that can be derived from the before/after pictures of
> > the trees.
>
> Perhaps. If a file is moved and edited within the same commit, I'm not
> sure that you can be certain whether it was done with d 'darcs mv' or
> not.
Agreed. But then you go lart the committer of that patch.
> Requiring separate checkins for the rename and the subsequent
> modify would make things easier on SCM's, but is impractical in real
> life.
Eh? Why? "darcs mv" *is* a commit. Just because it doesn't seem to look
like one doesn't change the fact that you just invoked the SCM.
> Automated refactoring tools, for example, perform the
> rename+modify as an atomic operation.
And that's harder, I agree. But unless I'm missing some nifty
refactoring editor out there that integrates with darcs during the edit
session, the user *still* has to tell the SCM about the rename manually.
> Now, git might not need to deal with any of this, because it only needs
> to work with the kernel project.
It'd be unfortunate if git were limited to such a small developer base.
> I'm *not* advocating cluttering up git with features that are not
> directly needed for kernel development.
I'm not claiming you are. We want the same thing -- a nuanced SCM that
can take some of the drudge-work away from this stuff.
Ray
^ permalink raw reply
* Re: [0/5] Parsers for git objects, porting some programs
From: Daniel Barkalow @ 2005-04-19 1:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Petr Baudis, git
In-Reply-To: <7v7jizsh1f.fsf@assigned-by-dhcp.cox.net>
On Mon, 18 Apr 2005, Junio C Hamano wrote:
> I was looking at the tree part and am thinking that it would
> make it much nicer if your tree object records path for each
> entry.
You're entirely right, and I've actually now written the code that does
it. I'm planning to send out a patch for that shortly.
> Currently it just borrows from object.refs to represent
> its children
Note that object.refs needs to get filled out for those
applications, even if the information is also included in the
parse; object.refs is for finding what you can reach without worrying
about how you do it.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] provide better committer information to commit-tree.c
From: David Woodhouse @ 2005-04-19 1:20 UTC (permalink / raw)
To: Greg KH; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050419011236.GA22091@kroah.com>
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 to be forced to obfuscate his
> email addresses in the changelog commits (as he did for the bk ones.)
He's talking about his own interpretation of the UK's Data Protection
Act, which requires you to be registered and fulfil certain other
requirements if you keep personal information about people in a
database. Email addresses have been ruled to be 'personal information'
in this context, but this _isn't_ an email address -- and there are
other get-out clauses for noncommercial situations such as this anyway,
I believe.
Besides, he can still obscure the author information as he unfortunately
insists on doing; it's the _committer_ information which we're
discussing here -- and that's always going to be himself in this case.
--
dwmw2
^ permalink raw reply
* Re: [0/5] Parsers for git objects, porting some programs
From: Junio C Hamano @ 2005-04-19 1:15 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.21.0504181558180.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> On Mon, 18 Apr 2005, Linus Torvalds wrote:
>> On Sun, 17 Apr 2005, Daniel Barkalow wrote:
>> >
>> > This series introduces common parsers for objects, and ports the programs
>> > that currently use revision.h to them.
>> >
>> > 1: the header files
>> > 2: the implementations
>> > 3: port rev-tree
>> > 4: port fsck-cache
>> > 5: port merge-base
>>
>> Ok, having now looked at the code, I don't have any objections at all.
I was looking at the tree part and am thinking that it would
make it much nicer if your tree object records path for each
entry. Currently it just borrows from object.refs to represent
its children, which is good enough for the applications listed
above (none of them would care where in the tree the object
belongs to), but I was thinking about an incremental dumper I
talked about in another thread and noticed that I cannot use the
current struct tree as is to compare two trees to find related
sha1 files (then I would inflate both, run diff and record the
output as a recipe to create one sha1 object from the other).
Or am I misreading the code that parses tree objects?
^ permalink raw reply
* Re: [PATCH] provide better committer information to commit-tree.c
From: Petr Baudis @ 2005-04-19 1:15 UTC (permalink / raw)
To: Greg KH; +Cc: David Woodhouse, Linus Torvalds, Git Mailing List
In-Reply-To: <20050419011236.GA22091@kroah.com>
Dear diary, on Tue, Apr 19, 2005 at 03:12:37AM CEST, I got a letter
where Greg KH <greg@kroah.com> told me that...
> But I'll wait for Russell to wake up and start quoting the proper EU
> privacy laws that he feels causes him to be forced to obfuscate his
> email addresses in the changelog commits (as he did for the bk ones.)
I'd be actually pretty interested in knowing about such laws; I think I
missed it on LKML when it went through. And after all, being an EU
citizen myself...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] provide better committer information to commit-tree.c
From: Greg KH @ 2005-04-19 1:12 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <1113871951.3579.25.camel@localhost.localdomain>
On Tue, Apr 19, 2005 at 10:52:30AM +1000, David Woodhouse wrote:
> 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 greg@dunce.kroah.org address
> > showing up :)
>
> Why not? Do they complain that we see 'greg@dunce.kroah.org' when you
> connect to an IRC server?
No, this employer seems quite sane :)
However, irc connections are as "real" as a kernel changelog message to
a lot of people.
> This _isn't_ an email address, and doesn't really need to be treated
> as such.
Ok, then why display it as one? Seriously, it doesn't really bother me,
just added it as I thought others would need it. I know the "shortlog"
program can pick the real names out of the Signed-off-by: lines.
But I'll wait for Russell to wake up and start quoting the proper EU
privacy laws that he feels causes him to be forced to obfuscate his
email addresses in the changelog commits (as he did for the bk ones.)
thanks,
greg k-h
^ permalink raw reply
* Re: Re: Re: Add "clone" support to lntree
From: Petr Baudis @ 2005-04-19 1:12 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0504161951160.30848-100000@iabervon.org>
For the record, mostly... (this is how it already is in git-pasky-0.5)
Dear diary, on Sun, Apr 17, 2005 at 02:07:36AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > Now, what about git branch and git update for switching between
> > branches? I think this is the most controversial part; these are
> > basically just shortcuts for not having to do git fork, and I wouldn't
> > mind so much removing them, if you people really consider them too ugly
> > a wart for the soft clean git skin. I admit that they both come from a
> > hidden prejudice that git fork is going to be slow and eat a lot of
> > disk.
>
> I think that this just confuses matters.
I killed them both for good.
> > The idea for git update for switching between branches is that
> > especially when you have two rather similar branches and mostly do stuff
> > on one of them, but sometimes you want to do something on the other one,
> > you can do just quick git update, do stuff, and git update back, without
> > any forking.
>
> I still think that fork should be quick enough, or you could leave the
> extra tree around. I'm not against having such a command, but I think it
> should be a separate command rather than a different use of update, since
> it would be used by poeople working in different ways.
I've removed git branch, removed the possibility for git update to
switch branches and renamed git update to git seek. You can do
git seek git-pasky-0.1
and examine stuff, but your tree is also blocked at the same time - git
won't let you commit, merge and such. By doing
git seek
or
git seek master
you return back to your branch (assuming its name is master).
I think git fork is after all good enough for branching and it is the
clean way. Shall there be a big demand for it, it should be minimal
hassle to implement 'git switch', which would do that.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [GIT PATCH] USB updates for 2.6.12-rc2
From: Greg KH @ 2005-04-19 1:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, linux-usb-devel, linux-kernel
Hm, I think I got this set up properly, but don't have an automated
script to generate the changelog and diffstat messages yet, so bear with
me...
Could you merge with:
kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/
It should be against your latest git tree. It contains a number of USB
patches (that I'm holding on to still, in case something happens to
this...) that are bug fix only. The diffstat is below. I'll figure out
how to send the patches out to the mailing list later on, if these
"stick".
And damm if git isn't fast on applying these patches, very nice job, I
like it.
thanks,
greg k-h
drivers/net/irda/stir4200.c | 4
drivers/usb/class/audio.c | 48 +++-------
drivers/usb/class/bluetty.c | 4
drivers/usb/core/config.c | 3
drivers/usb/core/devices.c | 8 -
drivers/usb/core/devio.c | 72 ++++++----------
drivers/usb/core/file.c | 2
drivers/usb/core/hcd-pci.c | 151 ++++++++++++++++++++--------------
drivers/usb/core/hcd.h | 4
drivers/usb/core/hub.c | 24 ++---
drivers/usb/core/inode.c | 1
drivers/usb/core/message.c | 25 -----
drivers/usb/core/urb.c | 16 ++-
drivers/usb/core/usb.c | 13 --
drivers/usb/core/usb.h | 8 +
drivers/usb/gadget/ether.c | 56 +++++-------
drivers/usb/gadget/omap_udc.c | 12 +-
drivers/usb/gadget/rndis.c | 40 ++++-----
drivers/usb/gadget/rndis.h | 4
drivers/usb/gadget/serial.c | 5 -
drivers/usb/host/ehci-dbg.c | 2
drivers/usb/host/ehci-hcd.c | 4
drivers/usb/host/ehci-mem.c | 3
drivers/usb/host/ehci-sched.c | 4
drivers/usb/host/ehci.h | 2
drivers/usb/host/ohci-omap.c | 4
drivers/usb/host/ohci-pci.c | 21 +++-
drivers/usb/host/ohci-pxa27x.c | 5 -
drivers/usb/host/ohci-q.c | 13 ++
drivers/usb/host/ohci.h | 2
drivers/usb/host/uhci-hcd.c | 9 --
drivers/usb/input/aiptek.c | 1
drivers/usb/input/hid-core.c | 9 --
drivers/usb/media/dabusb.c | 3
drivers/usb/media/ov511.c | 12 --
drivers/usb/media/se401.c | 15 +--
drivers/usb/media/usbvideo.c | 6 -
drivers/usb/media/w9968cf.c | 6 -
drivers/usb/misc/auerswald.c | 26 ++---
drivers/usb/misc/sisusbvga/sisusb.c | 3
drivers/usb/net/pegasus.c | 22 ++++
drivers/usb/net/usbnet.c | 32 +++++--
drivers/usb/net/zd1201.c | 3
drivers/usb/serial/belkin_sa.c | 3
drivers/usb/serial/cypress_m8.c | 5 -
drivers/usb/serial/digi_acceleport.c | 10 +-
drivers/usb/serial/empeg.c | 6 -
drivers/usb/serial/ftdi_sio.c | 10 --
drivers/usb/serial/io_edgeport.c | 24 +----
drivers/usb/serial/io_ti.c | 5 -
drivers/usb/serial/kl5kusb105.c | 3
drivers/usb/serial/omninet.c | 5 -
drivers/usb/serial/pl2303.c | 56 ++++++++----
drivers/usb/serial/pl2303.h | 4
drivers/usb/serial/ti_usb_3410_5052.c | 3
drivers/usb/serial/visor.c | 6 +
drivers/usb/serial/visor.h | 4
drivers/usb/storage/sddr55.c | 24 +----
drivers/usb/storage/transport.c | 2
drivers/usb/storage/unusual_devs.h | 13 ++
include/linux/usb.h | 4
include/linux/usb_cdc.h | 2
62 files changed, 467 insertions(+), 429 deletions(-)
^ permalink raw reply
* Re: [darcs-devel] Darcs and git: plan of action
From: Kevin Smith @ 2005-04-19 1:05 UTC (permalink / raw)
To: Ray Lee; +Cc: git, darcs-devel
In-Reply-To: <1113869248.23938.94.camel@orca.madrabbit.org>
Ray Lee wrote:
> On Mon, 2005-04-18 at 21:04 +0000, linux@horizon.com wrote:
>
>>The other is "replace very instace of identifier `foo` with identifier`bar`".
>
>
> That could be derived, however, by a particularly smart parser [1].
No, it can't. Seriously. A darcs replace patch is encoded as rules, not
effects, and it is impossible to derive the rules just by looking at the
results. Not difficult. Impossible. You could guess, but that's not good
enough for darcs to be able to reliably commute the patches later.
I am curious whether Linus's suggestion about including the
corresponding darcs patch id in the git commit comments would be good
enough.
> As for "darcs mv", that can be derived from the before/after pictures of
> the trees.
Perhaps. If a file is moved and edited within the same commit, I'm not
sure that you can be certain whether it was done with d 'darcs mv' or
not. Requiring separate checkins for the rename and the subsequent
modify would make things easier on SCM's, but is impractical in real
life. Automated refactoring tools, for example, perform the
rename+modify as an atomic operation.
Now, git might not need to deal with any of this, because it only needs
to work with the kernel project. But darcs does have to deal with this
wide range of uses, as does just about any other SCM.
I'm *not* advocating cluttering up git with features that are not
directly needed for kernel development. I'm just trying to clarify the
facts so everyone can understand what darcs is trying to do.
Kevin
^ permalink raw reply
* [PATCH] Automerge fix
From: Petr Baudis @ 2005-04-19 1:02 UTC (permalink / raw)
To: torvalds; +Cc: git
Hello,
this patch fixes git-merge-one-file-script's automerge.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
git-merge-one-file-script: 7ebf5dac4c69043cd2ff89bf7ee552152802f8d1
--- a/git-merge-one-file-script
+++ b/git-merge-one-file-script
@@ -43,7 +43,7 @@ case "${1:-.}${2:-.}${3:-.}" in
orig=$(unpack-file $1)
src1=$(unpack-file $2)
src2=$(unpack-file $3)
- merge "$src2" "$orig" "$src1" || echo Leaving conflict merge in $src2 && exit 1
+ merge "$src2" "$orig" "$src1" || (echo Leaving conflict merge in $src2 && exit 1)
cp "$src2" "$4" && update-cache --add -- "$4" && exit 0
;;
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] provide better committer information to commit-tree.c
From: David Woodhouse @ 2005-04-19 0:52 UTC (permalink / raw)
To: Greg KH; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050419004548.GA21623@kroah.com>
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 greg@dunce.kroah.org address
> showing up :)
Why not? Do they complain that we see 'greg@dunce.kroah.org' when you
connect to an IRC server? This _isn't_ an email address, and doesn't
really need to be treated as such.
--
dwmw2
^ permalink raw reply
* Re: GIT Web Interface
From: Petr Baudis @ 2005-04-19 0:52 UTC (permalink / raw)
To: Kay Sievers; +Cc: git
In-Reply-To: <20050419004415.GA10628@vrfy.org>
Dear diary, on Tue, Apr 19, 2005 at 02:44:15AM CEST, I got a letter
where Kay Sievers <kay.sievers@vrfy.org> told me that...
> I'm hacking on a simple web interface, cause I missed the bkweb too much.
> It can't do much more than browse through the source tree and show the
> log now, but that should change... :)
> http://ehlo.org/~kay/gitweb.pl?project=linux-2.6
Hmm, looks nice for a start. (But you have obsolete git-pasky tree there! ;-)
> How can I get the files touched with a changeset and the corresponding
> diffs belonging to it?
diff-tree to get the list of files, you can do the corresponding diffs
e.g. by doing git diff -r tree1:tree2. Preferably make a patch for it
first to make it possible to diff individual files this way.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Darcs and git: plan of action
From: Juliusz Chroboczek @ 2005-04-19 0:55 UTC (permalink / raw)
To: darcs-devel; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050418122011.GA13769@abridgegame.org>
[Using git as a backend for Darcs.]
> The problem I have with this is that "other" repository formats (e.g. git)
> store "tree versions", not "changes", and I think it would be fragile to
> try to store "changes" (in the darcs sense) in them.
Not really; a Darcs patch is just a pair of two git versions (from and
to). Which is why Darcs needs to support arbitrarily formatted patch
ids -- a patch originating from git will be identified by a pair of
git hashes.
Obviously, we'll need to think harder when pushing from darcs into git
(we'll need to preserve the Darcs patch id somehow), but it's premature
to worry about that right now.
>> 1. remove the assumption that patch IDs have a fixed format. Patch
>> IDs should be opaque blobs of binary data that Darcs only compares
>> for equality.
> I'm not really comfortable with this,
Why?
>> 3. allow a patch to have multiple IDs; if the IDs associated to two
>> patches are not disjoint, then the patches are the same patch.
>
> This I find a bit confusing. So a patch can have two IDs, presumably
> something like a "darcs ID" and a "git ID"? I can see that this might
> simplify some things, but am not sure how it would work. The IDs would
> have to have a hierarchy, so that you wouldn't ever end up with the "same"
> patch having disjoint IDs in two cases.
It's a case of ``don't do that''.
Suppose I record a patch in Darcs; it gets a Darcs id. I push it into
git, at which point it gets a git id, whether we want it to or not.
What do we do when we pull that patch back into darcs?
Either we arbitrarily discard one of the ids (which one?), or we keep
both. If there's more pulling/pushing going on on the git side, we
definitely need to keep both.
> Here's where I think I'd differ.
Same to you ;-)
> I think when dealing with git (and probably also with *any* other
> SCM (arch being a possible exception), we need to consider the
> exchange medium to be not a patch, but a tag.
We're thinking in opposite directions -- you're thinking of the alien
versions as integrals of Darcs patches, I'm thinking of Darcs patches
as derivatives of alien versions.
You: alien version = Darcs tag
Me: Darcs patch = pair of successive alien versions
My gut instinct is that the second model can be made to work almost
seamlessly, unlike the first one. But that's just a guess.
> if we want long-term stability we might need to mummify a variant of
> the diff algorithm that we agree not to change,
Good point, noted.
> But avoiding "mv" patches would be downright silly.
Aye, that will require some metadata on the git side (the hack,
suggested by Linus, of using git hashes to notice moves won't work).
Happily, it's premature to worry about that, too.
Juliusz
^ permalink raw reply
* Re: [PATCH] provide better committer information to commit-tree.c
From: Greg KH @ 2005-04-19 0:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504181730130.15725@ppc970.osdl.org>
On Mon, Apr 18, 2005 at 05:31:16PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 18 Apr 2005, Greg KH wrote:
> >
> > Here's a small patch to commit-tree.c that does two things:
>
> Gaah, I really was hoping that people wouldn't feel like they have to lie
> about their committer information.
>
> I guess we don't have much choice, but I'm not happy about it.
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 greg@dunce.kroah.org address
showing up :)
But if you really don't like it, and you don't want anyone trying to
hide anything, at least allow for a proper domainname. On my boxes, the
domainname doesn't show up at all without that patch (just the
getdomainname() part). I'll split it out if you want.
thanks,
greg k-h
^ permalink raw reply
* GIT Web Interface
From: Kay Sievers @ 2005-04-19 0:44 UTC (permalink / raw)
To: git
I'm hacking on a simple web interface, cause I missed the bkweb too much.
It can't do much more than browse through the source tree and show the
log now, but that should change... :)
http://ehlo.org/~kay/gitweb.pl?project=linux-2.6
How can I get the files touched with a changeset and the corresponding
diffs belonging to it?
Thanks,
Kay
--
#!/usr/bin/perl
# This file is licensed under the GPL v2, or a later version
# (C) 2005, Kay Sievers <kay.sievers@vrfy.org>
use strict;
use warnings;
use CGI;
use CGI::Carp qw(fatalsToBrowser);
my $query = new CGI;
my $gitbin = "/home/kay/bin";
my $gitroot = "/home/kay/public_html";
my $project = $query->param("project") || "";
my $action = $query->param("action") || "";
my $hash = $query->param("hash") || "";
my $projectroot = "$gitroot/$project";
$ENV{'SHA1_FILE_DIRECTORY'} = "$projectroot/.git/objects";
sub header {
print $query->header();
print $query->start_html("gitweb");
print $query->h1($project);
}
sub footer {
print $query->end_html();
}
if ($project eq "") {
open my $fd, "-|", "ls", "-1", $gitroot;
my (@path) = map { chomp; $_ } <$fd>;
close $fd;
header();
print "projects:<br/>\n";
foreach my $line (@path) {
if (-e "$gitroot/$line/.git/HEAD") {
print $query->a({-href => "gitweb.pl?project=$line"}, $line) . "<br/>\n";
}
}
footer();
exit;
}
if ($action eq "") {
print $query->redirect("gitweb.pl?project=$project&action=show_log");
exit;
}
if ($action eq "show_file") {
header();
print "<pre>\n";
open my $fd, "-|", "$gitbin/cat-file", "blob", $hash;
my $nr;
while (my $line = <$fd>) {
$nr++;
print "$nr\t$line";
}
close $fd;
print "</pre>\n";
footer();
} elsif ($action eq "show_tree") {
if ($hash eq "") {
open my $fd, "$projectroot/.git/HEAD";
my $head = <$fd>;
chomp $head;
close $fd;
open $fd, "-|", "$gitbin/cat-file", "commit", $head;
my $tree = <$fd>;
chomp $tree;
$tree =~ s/tree //;
close $fd;
$hash = $tree;
}
open my $fd, "-|", "$gitbin/ls-tree", $hash;
my (@entries) = map { chomp; $_ } <$fd>;
close $fd;
header();
foreach my $line (@entries) {
$line =~ m/^([0-9]+)\t(.*)\t(.*)\t(.*)$/;
my $t_type = $2;
my $t_hash = $3;
my $t_name = $4;
if ($t_type eq "blob") {
print "B\t" . $query->a({-href => "gitweb.pl?project=$project&action=show_file&hash=$3"}, $4) . "<br/>\n";
} elsif ($t_type eq "tree") {
print "T\t" . $query->a({-href => "gitweb.pl?project=$project&action=show_tree&hash=$3"}, $4) . "<br/>\n";
}
}
footer();
} elsif ($action eq "show_log") {
open my $fd, "$projectroot/.git/HEAD";
my $head = <$fd>;
chomp $head;
close $fd;
open my $fd, "-|", "$gitbin/rev-tree", $head;
my (@revtree) = map { chomp; $_ } <$fd>;
close $fd;
header();
foreach my $rev (reverse sort @revtree) {
$rev =~ m/^([0-9]+) ([0-9a-fA-F]+)/;
my $time = $1;
my $commit = $2;
open my $fd, "-|", "$gitbin/cat-file", "commit", $commit;
print "commit $commit<br/>\n";
while (my $line = <$fd>) {
if ($line =~ m/^tree (.*)$/) {
print $query->a({-href => "gitweb.pl?project=$project&action=show_tree&hash=$1"}, $line) . "<br/>\n";
} elsif ($line =~ m/^(author|committer) (.*)/) {
$line =~ m/^(.*) (.*>) ([0-9]+) (.*)$/;
my $type = $1;
my $name = $2;
my $time = $3;
my $timezone = $4;
$name =~ s/</</;
$name =~ s/>/>/;
$time = gmtime($time);
print "$type $name $time $timezone<br/>\n";
} else {
$line =~ s/</</;
$line =~ s/>/>/;
print "$line<br/>\n";
}
}
close $fd;
print "====================================<br/><br/>\n";
}
footer();
} else {
header();
print "unknown action\n";
footer();
}
^ permalink raw reply
* Re: SCSI trees, merges and git status
From: David Woodhouse @ 2005-04-19 0:41 UTC (permalink / raw)
To: James Bottomley; +Cc: Linus Torvalds, git
In-Reply-To: <1113869817.4998.106.camel@mulgrave>
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 digressing and talking about pruning ancient history
which _is_ theoretically reachable. It's not being 'undone'; it's just
being omitted from the current _working_ tree. The whole point is that
in a fully-populated tree the history _should_ be accessible all the way
back.
We're trying to get the older history available on kernel.org ASAP. The
blobs are rsyncing to ~dwmw2/git/kernel-tglx1; the trees and commit
objects will be coming soon.
Theoretically all Linus actually needs in order to rebuild his current
tree is the sha1 hash of the final commit in that historical tree, which
corresponds to 2.6.12-rc2.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] provide better committer information to commit-tree.c
From: Linus Torvalds @ 2005-04-19 0:31 UTC (permalink / raw)
To: Greg KH; +Cc: Git Mailing List
In-Reply-To: <20050419001126.GB21170@kroah.com>
On Mon, 18 Apr 2005, Greg KH wrote:
>
> Here's a small patch to commit-tree.c that does two things:
Gaah, I really was hoping that people wouldn't feel like they have to lie
about their committer information.
I guess we don't have much choice, but I'm not happy about it.
Linus
^ permalink raw reply
* Re: SCSI trees, merges and git status
From: Linus Torvalds @ 2005-04-19 0:29 UTC (permalink / raw)
To: James Bottomley; +Cc: git, SCSI Mailing List
In-Reply-To: <1113869594.4998.103.camel@mulgrave>
On Mon, 18 Apr 2005, James Bottomley wrote:
>
> Then the git-pull... script actually does the merge and the resulting
> tree checks out against BK
So?
What do you intend to do with all the other stuff I've already put on top?
Yes, I can undo my tree, but my tree has had more stuff in it since I
pulled from you, so not only will that confuse everybody who already got
the up-to-date tree, it will also undo stuff that was correct.
In other words, HISTORY CANNOT BE UNDONE.
That's the rule, and it's a damn good one. It was the rule when we used
BK, and it's the rule now. The fact that you can undo your history in
_your_ tree doesn't change anything at all.
So I can merge with your new tree, but that won't actually help any: I'll
just get a superset, the way you did things.
The way to remove patches is to explicitly revert them (effectively
applying a reverse diff), but I'm wondering if it's worth it in this case.
I looked at the patches I did get, and they didn't look horribly bad per
se. Are they dangerous?
2.6.12 is some time away, if for no other reason than the fact that this
SCM thing has obviously eaten two weeks of my time. So I'd be inclined to
chalk this up as a "learning experience" with git, and just go forward.
Linus
^ permalink raw reply
* Re: SCSI trees, merges and git status
From: James Bottomley @ 2005-04-19 0:16 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, git
In-Reply-To: <1113869456.3579.12.camel@localhost.localdomain>
On Tue, 2005-04-19 at 10:10 +1000, David Woodhouse wrote:
> 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 from fetching commits
> older than a certain threshold.
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
removes all the objects from the tree prior to the bogus commit---it's
based on your (Linus') git-prune-script.
James
^ permalink raw reply
* Re: SCSI trees, merges and git status
From: James Bottomley @ 2005-04-19 0:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, SCSI Mailing List
In-Reply-To: <Pine.LNX.4.58.0504181651241.15725@ppc970.osdl.org>
On Mon, 2005-04-18 at 17:03 -0700, Linus Torvalds wrote:
> The patches from you I have in my tree are:
>
> scsi: add DID_REQUEUE to the error handling
> zfcp: add point-2-point support
> [PATCH] Convert i2o to compat_ioctl
> [PATCH] kill old EH constants
> [PATCH] scsi: remove meaningless scsi_cmnd->serial_number_at_timeout field
> [PATCH] scsi: remove unused scsi_cmnd->internal_timeout field
> [PATCH] remove outdated print_* functions
> [PATCH] consolidate timeout defintions in scsi.h
Those are a subset of patches from my scsi-misc-2.6 tree .. that's the
problem. The actual patches should be:
o zfcp: convert to compat_ioctl
o sg.c: update
o updates for CFQ oops fix
o finally fix 53c700 to use the generic iomem infrastructure
o fix NMI lockup with CFQ scheduler
I've redone the scsi-rc-fixes-2.6 tree to remove all the contamination
and reset the head correctly.
I've verified that if I strip your tree back to
54ff646c589dcc35182d01c5b557806759301aa3
and then do a
git-pull-script rsync://www.parisc-linux.org/~jejb/scsi-rc-fixes-2.6.git
Then the git-pull... script actually does the merge and the resulting
tree checks out against BK
Sorry for the screw up.
James
> or at least that's what they claim in their changelogs.
>
> Oh, and here's the diffstat that matches "scsi":
>
> drivers/block/scsi_ioctl.c | 5 -
> drivers/s390/scsi/zfcp_aux.c | 4 -
> drivers/s390/scsi/zfcp_def.h | 5 +
> drivers/s390/scsi/zfcp_erp.c | 20 +++++
> drivers/s390/scsi/zfcp_fsf.c | 38 ++++++++--
> drivers/s390/scsi/zfcp_fsf.h | 6 +
> drivers/s390/scsi/zfcp_sysfs_adapter.c | 6 +
> drivers/scsi/53c7xx.c | 23 +++---
> drivers/scsi/BusLogic.c | 7 -
> drivers/scsi/NCR5380.c | 9 +-
> drivers/scsi/advansys.c | 7 -
> drivers/scsi/aha152x.c | 17 ++--
> drivers/scsi/arm/acornscsi.c | 9 +-
> drivers/scsi/arm/fas216.c | 9 +-
> drivers/scsi/arm/scsi.h | 2
> drivers/scsi/atari_NCR5380.c | 9 +-
> drivers/scsi/constants.c | 2
> drivers/scsi/ips.c | 7 -
> drivers/scsi/ncr53c8xx.c | 14 ---
> drivers/scsi/pci2000.c | 4 -
> drivers/scsi/qla2xxx/qla_dbg.c | 6 -
> drivers/scsi/scsi.c | 5 -
> drivers/scsi/scsi.h | 43 -----------
> drivers/scsi/scsi_error.c | 11 ---
> drivers/scsi/scsi_ioctl.c | 5 -
> drivers/scsi/scsi_lib.c | 2
> drivers/scsi/scsi_obsolete.h | 106 -----------------------------
> drivers/scsi/scsi_priv.h | 5 -
> drivers/scsi/seagate.c | 5 -
> drivers/scsi/sg.c | 3
> drivers/scsi/sun3_NCR5380.c | 9 +-
> drivers/scsi/sym53c8xx_2/sym_glue.c | 6 -
> drivers/scsi/ultrastor.c | 4 -
>
> so it doesn't look like there's a _lot_ wrong. Send in a patch to revert
> anything that needs reverting..
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] provide better committer information to commit-tree.c
From: Greg KH @ 2005-04-19 0:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
Here's a small patch to commit-tree.c that does two things:
- allows the committer email address and name to be overridden
by environment variables (if you don't like the environment
variable names I've used (COMMIT_AUTHOR_NAME,
COMMIT_AUTHOR_EMAIL), feel free to change them.)
- provide the proper domainname to the author/committer email
address (otherwise, my address was only showing up as from the
hostname.)
This allows people to set sane values for the commit names and email
addresses, preventing odd, private hostnames and domains from being
exposed to the world.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
--- a/commit-tree.c.orig 2005-04-18 17:02:50.000000000 -0700
+++ b/commit-tree.c 2005-04-18 17:03:19.000000000 -0700
@@ -284,8 +284,8 @@
unsigned char tree_sha1[20];
unsigned char parent_sha1[MAXPARENT][20];
unsigned char commit_sha1[20];
- char *gecos, *realgecos;
- char *email, realemail[1000];
+ char *gecos, *realgecos, *commitgecos;
+ char *email, *commitemail, realemail[1000];
char date[20], realdate[20];
char *audate;
char comment[1000];
@@ -317,20 +317,24 @@
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
gethostname(realemail+len+1, sizeof(realemail)-len-1);
+ strcat(realemail, ".");
+ getdomainname(realemail+strlen(realemail), sizeof(realemail)-strlen(realemail)-1);
time(&now);
tm = localtime(&now);
strftime(realdate, sizeof(realdate), "%s %z", tm);
strcpy(date, realdate);
+ commitgecos = getenv("COMMIT_AUTHOR_NAME") ? : realgecos;
+ commitemail = getenv("COMMIT_AUTHOR_EMAIL") ? : realemail;
gecos = getenv("AUTHOR_NAME") ? : realgecos;
email = getenv("AUTHOR_EMAIL") ? : realemail;
audate = getenv("AUTHOR_DATE");
if (audate)
parse_rfc2822_date(audate, date, sizeof(date));
- remove_special(gecos); remove_special(realgecos);
- remove_special(email); remove_special(realemail);
+ remove_special(gecos); remove_special(realgecos); remove_special(commitgecos);
+ remove_special(email); remove_special(realemail); remove_special(commitemail);
init_buffer(&buffer, &size);
add_buffer(&buffer, &size, "tree %s\n", sha1_to_hex(tree_sha1));
@@ -345,7 +349,7 @@
/* Person/date information */
add_buffer(&buffer, &size, "author %s <%s> %s\n", gecos, email, date);
- add_buffer(&buffer, &size, "committer %s <%s> %s\n\n", realgecos, realemail, realdate);
+ add_buffer(&buffer, &size, "committer %s <%s> %s\n\n", commitgecos, commitemail, realdate);
/* And add the comment */
while (fgets(comment, sizeof(comment), stdin) != NULL)
^ permalink raw reply
* Re: SCSI trees, merges and git status
From: David Woodhouse @ 2005-04-19 0:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: James Bottomley, git
In-Reply-To: <Pine.LNX.4.58.0504181651241.15725@ppc970.osdl.org>
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 from fetching commits
older than a certain threshold.
However, we can't _add_ the history if the current commits don't refer
to it. I really think we should take the imported git history and make
our 'current' tree refer to it -- even if just by having an appropriate
'parent' record in what is currently the oldest changeset in our tree;
the 2.6.12-rc2 import.
It doesn't matter that our oldest commit object refers to a nonexistent
parent, but that does allow us to import historical data if we _want_
to, and have it all work properly.
We should have the full historical git repo available within a day or
so, I believe. It would be really useful if we could make the current
trees refer back to that, instead of starting at 2.6.12-rc2.
--
dwmw2
^ permalink raw reply
* Re: yet another gitting started
From: Alex Riesen @ 2005-04-19 0:10 UTC (permalink / raw)
To: randy_dunlap; +Cc: git
In-Reply-To: <20050417195512.061e617a.rdunlap@xenotime.net>
On 4/18/05, randy_dunlap <rdunlap@xenotime.net> wrote:
> Here's the beginnings of yet another git usage/howto/tutorial.
>
> It can grow or die... I'll gladly take patches for it,
> or Pasky et al can merge more git plumbing and toilet usages
> into it, with or without me.
>
> http://www.xenotime.net/linux/doc/git-usage-howto
Thanks! Helped me to start :)
^ 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