* Re: Linux BKCVS kernel history git import..
From: A Large Angry SCM @ 2005-07-26 22:01 UTC (permalink / raw)
To: git
In-Reply-To: <20050726213643.7ca44e96.diegocg@gmail.com>
Diego Calleja wrote:
> El Tue, 26 Jul 2005 11:57:43 -0700 (PDT),
> Linus Torvalds <torvalds@osdl.org> escribió:
>
>>I'm planning on doing the 2.4 tree too some day - either as a separate
>>branch in the same archive, or as a separate git archive, I haven't quite
>
> It'd be great to have the same thing but for the 1.0 - 2.2 tree. Of course
> there are no "changelogs" for that, but incremental patches are still
> available, and it'd be very interesting (for "historical reasons") to see how
> things were added/removed
Also a really good stress test for the various git-blame/git-annotate
implementations.
^ permalink raw reply
* Re: [PATCH] git-cvsimport-script: parse multidigit revisions
From: Linus Torvalds @ 2005-07-26 22:01 UTC (permalink / raw)
To: David Mansfield
Cc: Matthias Urlichs, Sven Verdoolaege, Git Mailing List,
David Mansfield
In-Reply-To: <42E6AF1C.9050606@cobite.com>
Ahh, the cobite.com address worked ;)
David, as you may or may not be aware, the dm.cobite.com address was
bouncing at least as of yesterday.
On Tue, 26 Jul 2005, David Mansfield wrote:
>
> It 'smells' wierd to have to revisions in the same patchset at all, but
> I suppose you've all been through that before.
It seems to be just a result of how BK ends up having this internal notion
of a "delta", and one commit can contain multiple deltas to the same file.
That's really just some BK internal implementation issue showing through -
the deltas really aren't even individually accessible, it's just that BK
has this two-stage commit thing where you first commit the individual file
changes (the "delta") and then you do the _real_ commit which gathers them
all up.
Normally you don't even see this at all, since the tools basically hide
this, but especially if you script things you'll see the difference.
In fact, in many ways the usage model when scripting ends up being a bit
like the git two-phase "git-update-cache" + "git commit" approach,
although for totally different reasons. But unlike git, you can actually
tell how somebody did several updates on the same file, and it seems to
show through in the bkcvs archives.
I bet that it wasn't even intentional, and that it's really just a result
of the bkcvs thing really just being pretty much a raw SCCS->RCS
translation (with the addition of the "changeset" notion at a higher
level).
So normally you'd not like to see this unless you use the --bkcvs flag,
but I suspect that with a big fuzz-factor and repeated commit messages you
can see it even with a perfectly normal CVS tree - if only because cvsps
might collapse two separate commits that shouldn't really be collapsed.
Linus
^ permalink raw reply
* Meet the new maintainer..
From: Linus Torvalds @ 2005-07-27 3:24 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
I'm sure some of you eagle-eyes have already noticed this, but for the
last 24 hours the "owner" field on the main git project at www.kernel.org
hasn't been pointing to yours truly any more. It says "Junio C Hamano"
instead.
The description may still say "Linus' core git plumbing", but I think
that's just because Junio is being shy about things, and not very
assertive, but the fact is, in the great tag-game of project
maintainership, Junio is the new "it".
I always said I didn't really want to maintain it in the long run, and
maybe some of you thought I was just saying that, especially as the weeks
dragged out to over three months, but hey, that's just because this thing
ended up being a bit bigger and more professional than I originally even
envisioned.
Junio was the obvious choice, and since he accepted the maintainership
position, it means that I don't have to track the git details as closely,
and can go back to reading the linux kernel mailing list more actively.
I'll just continue to send patches to Junio instead of applying them to my
tree and pushing them out that way (or maybe I'll try to push any changes
through my slaved git trees instead). In other words, I'm not "dropping"
git, I just prefer working on it as a contributor rather than trying to
keep track of everything that happens.
So I don't think much will change, except I suspect Junio will drop fewer
patches on the floor and ask for fewer re-sends or need less prodding ;)
Linus
^ permalink raw reply
* A note from the new GIT maintainer
From: Junio C Hamano @ 2005-07-27 6:04 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507262004320.3227@g5.osdl.org>
As some of you seem to have noticed even before the announcement
by Linus, the official GIT repository at kernel.org is now owned
by me. As Linus said in his message, this does not mean he is
leaving us, so please do not panic.
I would like to thank everybody on the GIT list for what we have
achieved so far. Getting your ideas blown away and still being
able to feel happy about it is a privilege granted only to those
who are fortunate enough to work with very talented people. It
has been quite a fun experience for me.
I would also like to thank Twin Sun Inc (my employer) and NEC
for promising to support me working on GIT on a part time basis
from now on. I expect to be spending 8 to 12 day-job hours per
week; evenings and weekends are my own time as before. My
tentative plan is to make Wednesdays and Saturdays my primary
GIT days.
Earlier, I was producing as many patches as ideas cross my mind,
throwing all of them at the list to see which ones stick,
relying on somebody with a good taste upstream to drop all the
bad ones. Although it has been fun working that way with Linus,
regrettably, I ended up wasting a lot of his time.
I will slow down and be more careful as the "shepherd of the
main repository" from now on. At least for now, you will see
patches from me posted on the list like everybody else's, before
they hit the main repository.
In other words, I will make you my "adult supervision," so
please help me out by raising objections, giving alternatives,
or just plainly saying "your patch is ugly".
Some of you may have also noticed that the main GIT repository
has an extra branch, "pu" ("proposed updates"). My patches,
along with patches from others I collect from the list that I
intend to eventually apply, will first go there, before hitting
the master branch. You can probably tell, by looking at this
branch, what my priorities are, which patches are being
considered, and responses to which ones I am still waiting for.
Please note that I expect to rewind and rebase this branch quite
often.
I was planning to talk about the remaining tasks for 1.0 in this
message when Linus asked me if I wanted to take over the core
GIT project a couple of weeks ago. But I think we have done
most, if not all, of what we would want to have in 1.0 since
then. Of course there are still ongoing discussions for various
improvements, but I feel that that can continue without blocking
the 1.0 pre-release engineering process. Please keep bugfixes
and documentation updates flowing.
After the 1.0 release, I plan to start a branch for 1.0
maintenance, separate from the "master" branch. I think the
intent of having GIT RPM support, which was done before me, was
to force Pasky's hand to split core part from the Cogito
package, but as the prerequisite for the split to happen, the
interface to the core GIT part must be reasonably stable. We
operated without even having any formal version numbers for
quite some time, which I am sure made Pasky's life more
miserable then it should have been. This must be rectified.
I have not decided if we want to use even-odd scheme like the
kernel used to have, or just keep the "master" a bleeding edge
branch which is occasionally tagged.
That's about it from me for now. Let's continue to have fun!
^ permalink raw reply
* [PATCH] git-status-script was missed during the conversion from N -> A
From: Ryan Anderson @ 2005-07-27 8:36 UTC (permalink / raw)
To: git
git-status-script was missed during the conversion from "N" to "A" as
the new-file marker flag.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
git-status-script | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
10d81954c415dc46287f9d135e2b94302d4d7e84
diff --git a/git-status-script b/git-status-script
--- a/git-status-script
+++ b/git-status-script
@@ -18,7 +18,7 @@ report () {
T ) echo "# typechange: $name";;
C*) echo "# copied: $name -> $newname";;
R*) echo "# renamed: $name -> $newname";;
- N*) echo "# new file: $name";;
+ A*) echo "# new file: $name";;
U ) echo "# unmerged: $name";;
esac
done
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [PATCH/RFC] "Recursive Make considered harmful"
From: Ryan Anderson @ 2005-07-27 8:39 UTC (permalink / raw)
To: git
Convert build process from recurse Make to a single Make
The old Makefiles in Documentation/ and tools/ still exist until we feel
confident that I didn't miss anything on this conversion.
Most of this patch is fixing up the main Makefile to avoid overlapping
target names.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
Documentation/Makefile.inc | 50 ++++++++++++++++++++++++++++++++++++++++++++
Makefile | 24 ++++++++++++++-------
tools/Makefile.inc | 12 +++++++++++
3 files changed, 78 insertions(+), 8 deletions(-)
create mode 100644 Documentation/Makefile.inc
create mode 100644 tools/Makefile.inc
003afd3ed1f83b4533b628182fa16c9ab0dc0467
diff --git a/Documentation/Makefile.inc b/Documentation/Makefile.inc
new file mode 100644
--- /dev/null
+++ b/Documentation/Makefile.inc
@@ -0,0 +1,50 @@
+MAN1_TXT=$(wildcard Documentation/git-*.txt)
+MAN7_TXT=Documentation/git.txt
+
+DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT))
+
+DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
+DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
+
+mandir=$(prefix)/man
+man1=$(mandir)/man1
+man7=$(mandir)/man7
+
+#
+# Please note that there is a minor bug in asciidoc.
+# The version after 6.0.3 _will_ include the patch found here:
+# http://marc.theaimsgroup.com/?l=git&m=111558757202243&w=2
+#
+# Until that version is released you may have to apply the patch
+# yourself - yes, all 6 characters of it!
+#
+
+all-doc: html man
+
+html: $(DOC_HTML)
+
+
+man: man1 man7
+man1: $(DOC_MAN1)
+man7: $(DOC_MAN7)
+
+install-doc:
+ $(INSTALL) -m755 -d $(dest)/$(man1) $(dest)/$(man7)
+ $(INSTALL) $(DOC_MAN1) $(dest)/$(man1)
+ $(INSTALL) $(DOC_MAN7) $(dest)/$(man7)
+
+# 'include' dependencies
+Documentation/git-diff-%.txt: Documentation/diff-format.txt Documentation/diff-options.txt
+ touch $@
+
+clean-doc:
+ rm -f Documentation/*.xml Documentation/*.html Documentation/*.1 Documentation/*.7
+
+%.html : %.txt
+ asciidoc -b xhtml11 -d manpage $<
+
+%.1 %.7 : %.xml
+ xmlto -o Documentation/ man $<
+
+%.xml : %.txt
+ asciidoc -b docbook -d manpage $<
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -54,9 +54,17 @@ PROG= git-update-cache git-diff-files
git-show-index git-daemon git-var git-peek-remote \
git-update-server-info git-show-rev-cache git-build-rev-cache
-all: $(PROG)
+include Documentation/Makefile.inc
+include tools/Makefile.inc
-install: $(PROG) $(SCRIPTS)
+all: all-bin all-doc
+all-bin: $(PROG)
+#all-tools
+
+install: install-bin install-doc
+#install-tools
+
+install-bin: $(PROG) $(SCRIPTS)
$(INSTALL) -m755 -d $(dest)$(bin)
$(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin)
@@ -204,20 +212,20 @@ rpm: dist
test: all
$(MAKE) -C t/ all
-doc:
- $(MAKE) -C Documentation all
+doc: all-doc
+# $(MAKE) -C Documentation all
-install-tools:
+install-toolsxx:
$(MAKE) -C tools install
-install-doc:
+install-docxx:
$(MAKE) -C Documentation install
-clean:
+clean: clean-doc clean-tools
rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
rm -f git-core-*.tar.gz git-core.spec
$(MAKE) -C tools/ clean
- $(MAKE) -C Documentation/ clean
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
+
diff --git a/tools/Makefile.inc b/tools/Makefile.inc
new file mode 100644
--- /dev/null
+++ b/tools/Makefile.inc
@@ -0,0 +1,12 @@
+#
+# Make Linus git-tools
+#
+
+PROG += $(addprefix tools/,git-mailsplit git-mailinfo)
+SCRIPTS += $(addprefix tools/,git-applymbox git-applypatch)
+
+tools/git-%: tools/%.c
+ $(CC) $(CFLAGS) -o $@ $(filter %.c,$^)
+
+clean-tools:
+ rm -f tools/*.o
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Linux BKCVS kernel history git import..
From: David Woodhouse @ 2005-07-27 9:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: tglx, Git Mailing List, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.58.0507261136280.19309@g5.osdl.org>
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..v2.6.12
That's a bit of a hack which really doesn't belong in the git tools.
It's not particularly hard to reparent the tree for real -- I'd much
rather see a tool added to git which can _actually_ change the
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 commit to have a parent of
0bcc493c633d78373d3fcf9efc29d6a710637519, and ripple the corresponding
SHA1 changes up to the current HEAD.
Note that the latter commit ID I gave there was actually the 2.6.12-rc2
commit in Thomas' history import, not your own. Thomas has done a lot of
work on it, and it has the full names extracted from the shortlog
script, full timestamps, branch/merge history and consistent character
sets in the commit logs. I'd definitely suggest that you use that
instead of the import from bkcvs.
http://www.kernel.org/git/?p=linux/kernel/git/tglx/history.git;a=summary
--
dwmw2
^ permalink raw reply
* Git 1.0 Synopis (Draft v2)
From: Ryan Anderson @ 2005-07-27 10:01 UTC (permalink / raw)
To: git
[This is still a draft, but I think I incorporated the suggestons from
the last attempt.]
Source Code Management with Git
Git, sometimes called "global information tracker", is a "directory
content manager". Git has been designed to handle absolutely massive
projects with speed and efficiency, and the release of the 2.6.12 and
(soon) the 2.6.13 version of the Linux kernel would indicate that it
does this task well.
Git falls into the category of distributed source code management tools,
similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every Git
working directory is a full-fledged repository with full revision tracking
capabilities, not dependent on network access to a central server.
Git uses the SHA1 hash algorithm to provide a content-addressable pseudo
filesystem, complete with its own version of fsck.
o Speed of use, both for the project maintainer, and the end-users, is
a key development principle.
o The history is stored as a directed acyclic graph, making long-lived
branches and repeated merging simple.
o A collection of related projects are building on the core Git project,
either to provide an easier to use interface on top (StGit, Cogito, qgit,
gitk, gitweb), or to take some of the underlying concepts and reimplement
them directly into another system (Arch 2.0, Darcs-git).
o Two, interchangeable, on-disk formats are used:
o An efficient, packed format that saves spaced and network
bandwidth.
o An unpacked format, optimized for fast writes and incremental
work.
To get a copy of Git:
Daily snapshots are available at:
http://www.codemonkey.org.uk/projects/git-snapshots/git/
(Thanks to Dave Jones)
Source tarballs and RPMs at:
http://www.kernel.org/pub/software/scm/git/
Deb packages at:
<insert url here>
Or via Git itself:
git clone http://www.kernel.org/pub/scm/git/git.git/
git clone rsync://rsync.kernel.org/pub/scm/git/git.git/
(rsync is generally faster for an initial pull)
Git distributions contain a tutorial in the Documentation subdirectory.
Additionally, the Kernel-Hacker's Git Tutorial at
http://linux.yyz.us/git-howto.html may be useful. (Thanks to Jeff Garzik for
that document)
Git development takes place on the Git mailing list. To subscribe, send an
email with just "subscribe git" in the body to majordomo@vger.kernel.org.
Mailing list archives are available at http://marc.theaimsgroup.com/?l=git
Git results from the inspiration and frustration of Linus Torvalds, and
the enthusiastic help of over 300 participants on the development
mailing list.[1] It is maintained by Junio C Hamano <junkio@cox.net>.
1 - Generated with the following, in a maildir folder:
find . -type f | xargs grep -h "^From:" | perl -ne \
'tr#A-Z#a-z#; m#<(.*)># && print $1,"\n";' | sort -u | wc -l
(This summary written by Ryan Anderson <ryan@michonline.com>. Please bug him
with any corrections or complaints.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Josef Weidendorfer @ 2005-07-27 12:58 UTC (permalink / raw)
To: git
Hi,
if I clone a remote head other than master via Cogito with
cg-clone host:path#remoteHead,
work on this branch, and try to push back my changes with
cg-push,
I get the error
"pushing to a different head not supported yet".
As far as I can see, there is no support in core GIT to make this ever work
(at least with get-send-packs), as "git-send-pack" only updates a set of
heads with the same name both locally and remote.
I suppose the best would be to always keep the same head names in cloned
repositories - it seems to be easier to handle for users. Perhaps the only
exception would be "master", as one probably would like to pull masters of
different remote repositories into a local one (without really working on
them).
Thus, what about the following: Each time a remote head other than master is
cloned, a head with the same name is created locally which is an alias to the
local master. This way, cg-push almost works out of the box. Following patch
implements this behavior.
Josef
diff --git a/cg-clone b/cg-clone
--- a/cg-clone
+++ b/cg-clone
@@ -69,5 +69,12 @@ cp $_git/refs/heads/origin $_git/refs/he
git-read-tree HEAD
git-checkout-cache -a
git-update-cache --refresh
echo "Cloned to $dir/ (origin $location available as branch \"origin\")"
+
+if echo "$location" | grep -q "#" ; then
+ rembranch=$(echo "$location" | sed -e "s/.*#//")
+ (cd $_git/refs/heads; ln -s master "$rembranch")
+ echo "Remote head \"$rbranch\" locally available as alias for \"master\""
+fi
+
diff --git a/cg-push b/cg-push
--- a/cg-push
+++ b/cg-push
@@ -28,17 +28,18 @@ uri=$(cat "$_git/branches/$name" 2>/dev/
rembranch=master
if echo "$uri" | grep -q '#'; then
rembranch=$(echo $uri | cut -d '#' -f 2)
uri=$(echo $uri | cut -d '#' -f 1)
- die "pushing to a different head not supported yet"
+ [ -s $_git/refs/heads/$rembranch ] || (cd $_git/refs/heads;ln -s master $rembranch)
+ [ $(readlink $_git/refs/heads/$rembranch) = "master" ] || \
+ die "can not push to remote head \"$rembranch\""
fi
if echo "$uri" | grep -q "^http://"; then
die "pushing over HTTP not supported yet"
elif echo "$uri" | grep -q "^git+ssh://"; then
git-send-pack "$(echo "$uri" | sed 's#^git+ssh://\([^/]*\)\(/.*\)$#\1:\2#')" $rembranch
-elif echo "$uri" | grep -q ":"; then
+elif echo "$uri" | grep -q "^rsync://"; then
die "pushing over rsync not supported"
else
git-send-pack "$uri" $rembranch
fi
^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: A Large Angry SCM @ 2005-07-27 14:25 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050727083910.GG19290@mythryan2.michonline.com>
Ryan Anderson wrote:
> Convert build process from recurse Make to a single Make
>
Please explain the rational for this.
^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: Kirby C. Bohling @ 2005-07-27 14:37 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Ryan Anderson, git
In-Reply-To: <42E79946.2020309@gmail.com>
On Wed, Jul 27, 2005 at 10:25:10AM -0400, A Large Angry SCM wrote:
> Ryan Anderson wrote:
> >Convert build process from recurse Make to a single Make
> >
>
> Please explain the rational for this.
I'm new to the list, but given the subject, I'm fairly confident
it's this.
http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html
I'm a convert. I converted a fairly large code base at work, and it
was a huge boon for productivity. Build times dropped dramatically
(from 40 seconds to 2-5 for a single file change).
He used the exact wording just about everyone dones when referring
to it conceptually. It's easy to google for support and rebuttal:
http://www.google.com/search?hl=en&q=Recursive+Make+considered+harmful&btnG=Google+Search
Thanks,
Kirby
^ permalink raw reply
* Re: Linux BKCVS kernel history git import..
From: Linus Torvalds @ 2005-07-27 15:29 UTC (permalink / raw)
To: David Woodhouse; +Cc: tglx, Git Mailing List, Linux Kernel Mailing List
In-Reply-To: <1122457238.3027.37.camel@baythorne.infradead.org>
On Wed, 27 Jul 2005, David Woodhouse wrote:
> 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..v2.6.12
>
> That's a bit of a hack which really doesn't belong in the git tools.
Actually, it's not a hack at all. It's very fundamentally how git works:
you give it two trees that it knows about, and it will show the
differences between them - regardless of whether they share any common
ancestry or not.
> It's not particularly hard to reparent the tree for real -- I'd much
> rather see a tool added to git which can _actually_ change the
> 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 commit to have a parent of
> 0bcc493c633d78373d3fcf9efc29d6a710637519, and ripple the corresponding
> SHA1 changes up to the current HEAD.
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 some other improvements on the conversion (I think I'll
remove the BK files - "ChangeSet" etc).
And it's really much easier and more general to have a "graft" facility.
It's something that git can do trivially (literally a hook in
"parse_commit" to add a special parent), and it's actually a generic
mechanism exactly for issues like this ("project had old history in some
other format").
Somebody already asked for having the import history for old historic
patches - which we _do_ actually have as patches, but which obviously
don't have any changelogs except for the version information. Most people
may not want that, but the thing is, with a "graft" facility, the people
who _do_ want that can easily see it all, and it is totally seamless.
So it's not even a one-time hack - it's a real feature that just in the
kernel would have several cases we'd be able to use it for, and the same
is likely true for almost any other project that wasn't started purely
from git..
Linus
^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: A Large Angry SCM @ 2005-07-27 15:32 UTC (permalink / raw)
To: Kirby C. Bohling; +Cc: Ryan Anderson, git
In-Reply-To: <20050727143720.GG7410@birddog.com>
Kirby C. Bohling wrote:
> On Wed, Jul 27, 2005 at 10:25:10AM -0400, A Large Angry SCM wrote:
>>Ryan Anderson wrote:
>>>Convert build process from recurse Make to a single Make
>>>
>>Please explain the rational for this.
>
> I'm new to the list, but given the subject, I'm fairly confident
> it's this.
>
> http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html
>
...
>
> He used the exact wording just about everyone dones when referring
> to it conceptually. It's easy to google for support and rebuttal:
>
> http://www.google.com/search?hl=en&q=Recursive+Make+considered+harmful&btnG=Google+Search
Thanks for the references.
A quick read of the paper and some of the rebuttals make me think that
either way (recursive/non-recursive):
* require about the same amount of makefile/dependency maintenance work
from developers.
* allow developers to be lazy in different ways with
makefiles/dependencies.
* achieves the same end.
The non-recursive make method may have a small advantage for developers
using Git for their SCM because the Git operations are also performed at
the top level due to Git's design.
^ permalink raw reply
* Re: Linux BKCVS kernel history git import..
From: Linus Torvalds @ 2005-07-27 15:50 UTC (permalink / raw)
To: David Woodhouse; +Cc: tglx, Git Mailing List, Linux Kernel Mailing List
In-Reply-To: <1122478870.28128.52.camel@hades.cambridge.redhat.com>
On Wed, 27 Jul 2005, David Woodhouse wrote:
>
> Hm, OK. That works and can also be used for the "fake _absence_ of
> parent" thing -- if I'm space-constrained and want only the history back
> to some relatively recent point like 2.6.0, I can do that by turning the
> 2.6.0 commit into an orphan instead of also using all the rest of the
> history back to 2.4.0.
Yes. The grafting really should work pretty well for various things like
this, and at the same time I don't think it's ever going to be a huge
problem: people may have a couple of graft-points (if you want to drop
history, you may well have more than one point you need to "cauterize":
you may not be able to just cut it off at 2.6.0, since there may be merges
furhter back in history), but I don't think it's going to explode and
become unwieldly.
I just don't see people having more than a few trees that they might want
to graft together, and while the "drop history" thing might cause more
issues, even that is bounded by the amount of development parallellism, so
while it probably causes more graft-points than the "join trees" usage, it
should still be just a small handful of points.
Linus
^ permalink raw reply
* Re: Linux BKCVS kernel history git import..
From: David Woodhouse @ 2005-07-27 15:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: tglx, Git Mailing List, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.58.0507270819550.3227@g5.osdl.org>
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 some other improvements on the conversion (I think I'll
> remove the BK files - "ChangeSet" etc).
Thomas has done all that; it's on kernel.org already.
> And it's really much easier and more general to have a "graft" facility.
> It's something that git can do trivially (literally a hook in
> "parse_commit" to add a special parent), and it's actually a generic
> mechanism exactly for issues like this ("project had old history in some
> other format").
Hm, OK. That works and can also be used for the "fake _absence_ of
parent" thing -- if I'm space-constrained and want only the history back
to some relatively recent point like 2.6.0, I can do that by turning the
2.6.0 commit into an orphan instead of also using all the rest of the
history back to 2.4.0.
--
dwmw2
^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: Junio C Hamano @ 2005-07-27 21:50 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050727083910.GG19290@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> 003afd3ed1f83b4533b628182fa16c9ab0dc0467
> diff --git a/Documentation/Makefile.inc b/Documentation/Makefile.inc
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/Makefile.inc
> @@ -0,0 +1,50 @@
> +MAN1_TXT=$(wildcard Documentation/git-*.txt)
> +MAN7_TXT=Documentation/git.txt
> +
>...
While I do not have strong objections to make the build process
go faster, it is somewhat disturbing that the Makefile pieces
maintained in subdirectories need to name things they touch
using paths that include the subdirectory names. I do not have
a better alternative to suggest, though...
I'd keep it in the proposed updates branch for now and wait for
a bit until discussions on the list die out.
^ permalink raw reply
* Re: [PATCH] git-status-script was missed during the conversion from N -> A
From: Junio C Hamano @ 2005-07-27 21:45 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050727083608.GF19290@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> git-status-script was missed during the conversion from "N" to "A" as
> the new-file marker flag.
Thanks. Applied and pushed out.
^ permalink raw reply
* Re: Stacked GIT 0.4
From: Catalin Marinas @ 2005-07-27 21:26 UTC (permalink / raw)
To: Bryan Larsen; +Cc: GIT
In-Reply-To: <42D3A415.5000709@gmail.com>
On Tue, 2005-07-12 at 07:05 -0400, Bryan Larsen wrote:
> Here's my wishlist. Hopefully I'll be able to dig in and help out.
>
> import: the complement to export
A first implementation of 'import' is available in the tonight's
snapshot (and in the StGIT git repository mirror).
> template files for the "series" output of export, to put it into a
> format that "sendpatchset" understands.
As you noticed, I implemented the 'mail' command.
Once the current snapshot gets a bit more testing, I will release the
0.5 version. After that, I will focus more on a tutorial and the file
compatibility with Cogito.
--
Catalin
^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: A Large Angry SCM @ 2005-07-27 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git
In-Reply-To: <7v4qafrk8w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> While I do not have strong objections to make the build process
> go faster, it is somewhat disturbing that the Makefile pieces
> maintained in subdirectories need to name things they touch
> using paths that include the subdirectory names. I do not have
> a better alternative to suggest, though...
For a project the size of Git, is there any real benefit to this change?
Besides pathing issues, you also have to aware that all identifiers in
the included makefile fragments will be global.
I don't object to the change but I see it as trading one maintenance
issue for another.
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v2)
From: Junio C Hamano @ 2005-07-27 22:13 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050727100123.GH19290@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> Source Code Management with Git
Thanks for doing this. Generally looks excellent.
> o Two, interchangeable, on-disk formats are used:
> o An efficient, packed format that saves spaced and network
> bandwidth.
??? "spaced" ???
> Or via Git itself:
> git clone http://www.kernel.org/pub/scm/git/git.git/
> git clone rsync://rsync.kernel.org/pub/scm/git/git.git/
> (rsync is generally faster for an initial pull)
These need a target directory name to create, like this:
git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ $new_dir
git clone http://www.kernel.org/pub/scm/git/git.git/ $new_dir
> Git results from the inspiration and frustration of Linus Torvalds, and
> the enthusiastic help of over 300 participants on the development
> mailing list.[1] It is maintained by Junio C Hamano <junkio@cox.net>.
Please drop the e-mail address here; you mention nobody else's.
Well, dropping "the current maintainer" information altogether
might be even better; the above to a casual reader sounds like
Linus was frustrated and I wrote it for him, which is definitely
not what we would like to say. I suspect it still has more code
by Linus than anybody else (I stopped counting some time ago).
^ permalink raw reply
* Handover, Make
From: Brian O'Mahoney @ 2005-07-27 23:08 UTC (permalink / raw)
To: git
First, congratulations Junio, on taking over this stuff, and all the best.
Second, the killer argument, in the 'Recursive Make ... harmful' is the
basic one that Recursive Makes breaks up the dependancy graph, and
almost guarentees that it is wrong unless you do a lot of work to fix
that artifact. Now git is small enough that make clean; make won't take
too long but git is also a basis for other layers, so there is good
reason to try to get it right.
--
mit freundlichen Grüßen, Brian.
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Junio C Hamano @ 2005-07-28 1:32 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200507271458.43063.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> As far as I can see, there is no support in core GIT to make this ever work
> (at least with get-send-packs), as "git-send-pack" only updates a set of
> heads with the same name both locally and remote.
Yes, it is my understanding that "clone" means to literally
clone, not "pull into an empty repository with renamed head
names", to the core GIT. I do not speak for Pasky, but Cogito's
"clone" seems to have a bit different semantics (which I suspect
is more friendly to the users in many situations).
Similarly, "push" to the core GIT (that is what git-send-pack is
about) means performing a subset of "clone" in reverse. This is
primarily to synchronise two repositories owned by a single
person.
^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: Junio C Hamano @ 2005-07-28 7:04 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <7v4qafrk8w.fsf@assigned-by-dhcp.cox.net>
Ryan, I am dropping this patch, at least for now, after keeping
it in the "pu" (proposed updates) branch and using it myself.
There are two complaints from me.
I am used to "make bin=$HOME/bin/i386 install install-tools",
which the patch breaks (I do not want to build docs for myself).
This is minor; I could say "install-bin install-toolsxx"
instead.
I do not deal with RPM packages myself, but guessing by reading
git-core.spec.in, I think it relies on the install target not
touching the documentation, in order for it to be able to build
doc-full and/or doc-less binary packages. The patch makes
install target to also build and install docs.
The Debian build is not affected because it does not produce
separate git-core and doc-git-core packages[*1*]; probably this
was the reason you did not notice this.
I think what is installed from the toplevel and what comes from
tools/ subdirectory are divided mostly for historical reasons
and nothing else[*2*], and I do not mind the install target
depending on install-bin and install-tools, but I suspect that
binary packaging folks would appreciate to have a separate doc
target that is not done by a normal install.
Speeding up the build procedure by defining dependencies
correctly is a worthy goal. Personally I feel a low hanging
fruit is in the main Makefile, before worrying about the make
recursion. Many things are in libgit.a and when I touch
something only relevant to small number of things, say
csum-file.c, all "git-%: %.c" programs are recompiled and
relinked, even most of them do not link with csum-file.o (this
particular one is only used by git-pack-objects, by the way).
[Footnote]
*1* Which, BTW, would be the Debian way, if I am not mistaken.
*2* Although one _could_ argue that tools/ is primarily meant
for "project lead" role users who accept and incorporate patches
obtained via e-mails.
^ permalink raw reply
* [PATCH] gitk: Use GIT_DIR where appropriate.
From: Junio C Hamano @ 2005-07-28 7:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
Some places assumed .git is the GIT_DIR, resulting heads and
tags not showing when it was run like "GIT_DIR=. gitk --all".
This is not a contrived example --- I rely on it to verify
my private copy of git.git repository before pushing it out.
Define a single procedure "gitdir" and use it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** Paul, I will not be applying this to the copy Linus pulled
*** into git.git repository, but sending it to you in a patch
*** form. I believe that would be easier for you to work with
*** than pulling from git.git along with all the other stuff.
gitk | 24 +++++++++++++-----------
1 files changed, 13 insertions(+), 11 deletions(-)
c41a6a0271ea966f5d5cd648b854ec78b90096a6
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -7,17 +7,22 @@ exec wish "$0" -- "${1+$@}"
# and distributed under the terms of the GNU General Public Licence,
# either version 2, or (at your option) any later version.
+proc gitdir {} {
+ global env
+ if {[info exists env(GIT_DIR)]} {
+ return $env(GIT_DIR)
+ } else {
+ return ".git"
+ }
+}
+
proc getcommits {rargs} {
global commits commfd phase canv mainfont env
global startmsecs nextupdate
global ctext maincursor textcursor leftover
# check that we can find a .git directory somewhere...
- if {[info exists env(GIT_DIR)]} {
- set gitdir $env(GIT_DIR)
- } else {
- set gitdir ".git"
- }
+ set gitdir [gitdir]
if {![file isdirectory $gitdir]} {
error_popup "Cannot find the git directory \"$gitdir\"."
exit 1
@@ -212,7 +217,7 @@ proc parsecommit {id contents listed} {
proc readrefs {} {
global tagids idtags headids idheads
- set tags [glob -nocomplain -types f .git/refs/tags/*]
+ set tags [glob -nocomplain -types f [gitdir]/refs/tags/*]
foreach f $tags {
catch {
set fd [open $f r]
@@ -241,7 +246,7 @@ proc readrefs {} {
close $fd
}
}
- set heads [glob -nocomplain -types f .git/refs/heads/*]
+ set heads [glob -nocomplain -types f [gitdir]/refs/heads/*]
foreach f $heads {
catch {
set fd [open $f r]
@@ -2752,10 +2757,7 @@ proc domktag {} {
return
}
if {[catch {
- set dir ".git"
- if {[info exists env(GIT_DIR)]} {
- set dir $env(GIT_DIR)
- }
+ set dir [gitdir]
set fname [file join $dir "refs/tags" $tag]
set f [open $fname w]
puts $f $id
^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: Matthias Urlichs @ 2005-07-28 7:45 UTC (permalink / raw)
To: git
In-Reply-To: <7v64uvh0mo.fsf@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> The Debian build is not affected because it does not produce
> separate git-core and doc-git-core packages[*1*]; probably this
> was the reason you did not notice this.
git-core-doc, actually.
Debian does that only if the documentation is substantial. Even then,
manpages may not be segregated into -doc.
However, I *would* segregate gitk into its own Debian package, because
it requires wish et al., which would pull a large chunk of X11 stuff,
which people may not want on their server.
Patch follows separately -- I'll have to pull it from my other mess
(which includes yet another Debian package for Cogito ;-).
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
A zealot's stones will break my bones, but gods will never hurt me.
^ 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