* Re: New ref generates 8MB mail message
From: Linus Torvalds @ 2006-01-18 16:12 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: git
In-Reply-To: <20060118140907.GV19769@parisc-linux.org>
On Wed, 18 Jan 2006, Matthew Wilcox wrote:
>
> Based on the idea that a new branch is probably a branch off master, and
> if it isn't, then at least sending a log vs master is better than a log
> vs the beginning of time, I propose this patch:
Actually, since the update hook _should_ be called before the ref has
actually been updated, it's probably much better to instead of this:
> - git-rev-list --pretty "$3"
> + git-rev-list --pretty "$3" ^master
do something like this:
git-rev-list --pretty "$3" $(git-rev-parse --not --all)
which basically says: show any commits that are in the new ref, but are
not in _any_ other ref.
Untested, of course.
Linus
^ permalink raw reply
* "git cat" and "git ls"
From: Santi Béjar @ 2006-01-18 15:10 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 389 bytes --]
Hello,
following the "git diff" wrapper I've done two new wrappers:
git cat: USAGE='<tag|commit|blob> | [<ent>|-1|-2|-3] -- <file>'
It shows the content of the giventag/commit/blob.
You can also ask for a file in a tree or in the index (stage
optional).
git ls: USAGE='[<ent>] [--] <path>'
It lists the files in <path> in the <ent> or in the index.
Santi
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: git-cat.sh --]
[-- Type: text/x-sh, Size: 1011 bytes --]
#!/bin/sh
#
USAGE='<tag|commit|blob> | [<ent>|-1|-2|-3] -- <file>'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
rev=$(git-rev-parse --revs-only --no-flags --sq "$@") || exit
flags=$(git-rev-parse --no-revs --flags "$@")
files=$(git-rev-parse --no-revs --no-flags --sq "$@")
case "$rev,$files" in
?*' '?*,*|*,?*' '?*)
usage
;;
?*,?*)
sha1=$(eval "git-ls-tree $rev $files" | cut -f 1 | cut -d " " -f 3)
;;
?*,)
sha1=$rev
;;
,?*)
# Only one file
[ $(eval "git-ls-files $files | wc -l") != 1 ] && usage
stg=0
flag=${flags#-}
case $flag in
1|2|3) stg=$flag;;
esac
sha1=$(eval "git-ls-files -s $files" | while read -r mode sha stage name ; do
[ $stage -eq $stg ] && echo $sha && break ; done)
;;
*)
usage
;;
esac
[ -z $sha1 ] && echo "$(basename $0): $files: Not found" && exit 1
type=$(eval "git-cat-file -t $sha1")
case $type in
tree)
usage
;;
tag|blob)
cmd="git-cat-file $type $sha1"
;;
commit)
cmd="git-rev-list --max-count=1 $sha1 --pretty=fuller"
;;
esac
eval "$cmd"
exit
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: git-ls.sh --]
[-- Type: text/x-sh, Size: 335 bytes --]
#!/bin/sh
#
USAGE='[<ent>] [--] <path>'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
tree=$(git-rev-parse --verify $1^{tree} 2>/dev/null)
[ -n "$tree" ] && shift
files=$(git-rev-parse --no-revs --no-flags --sq "$@")
case "$tree" in
"")
cmd="git-ls-files -s $files"
;;
?*)
cmd="git-ls-tree $tree $files"
;;
esac
eval "$cmd"
exit
^ permalink raw reply
* "tla missing -s" equivalent with git/cogito
From: Belmar-Letelier @ 2006-01-18 14:53 UTC (permalink / raw)
To: git
Hello,
Could someone say me how we do in cogito or git the
arch-tla equivalent of
$ cd project--luis--0.1
$ tla missing -sD paul@mail.com--public/project--paul--0.1
so I get the information like what are the interesting patch to get
and then I take all of them with
$ tla star-merge -t paul@mail.com--public/project--paul--0.1
or I cherry pick only one of them (here patch-6) with
$ tla replay somefriend@mail.com--public/project--branchA--0.1--patch-6
tks
--
Luis
^ permalink raw reply
* Re: Joining Repositories
From: Ryan Anderson @ 2006-01-18 14:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: Mathias Waack, git
In-Reply-To: <20060118142139.GQ28365@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
Petr Baudis wrote:
>Dear diary, on Wed, Jan 18, 2006 at 03:09:17PM CET, I got a letter
>where Ryan Anderson <ryan@michonline.com> said that...
>
>
>>... Why would that be the optimal method?
>>
>Ow. I suppose that's what you call "blinded by invalid implicit
>assumptions". Obviously, if you are ok with such a grand move, this is
>the best.
>
>
Sorry, that came out a bit harsher than I had intended.
>This also reminds me that I should finally merge the cg-mv patch.
>
>> git fetch ../r1/
>> GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
>> GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
>> git-update-cache --add -- $(GIT_INDEX_FILE=.git/tmp-index git-ls-files)
>> cp .git/FETCH_HEAD .git/MERGE_HEAD
>> git commit
>>
>>
>
>But if you want to have an idea what's actually going on on the high
>level, perhaps the
>
> cd r2
> cg-branch-add r1 ../r1/.git
> cg-fetch r1
> cg-merge -j r1
>
>might be easier. ;-)
>
Ah, yes, cg-merge seems like it might be somewhat simpler here.
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: Joining Repositories
From: Petr Baudis @ 2006-01-18 14:21 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Mathias Waack, git
In-Reply-To: <20060118140917.GA15438@mythryan2.michonline.com>
Dear diary, on Wed, Jan 18, 2006 at 03:09:17PM CET, I got a letter
where Ryan Anderson <ryan@michonline.com> said that...
> ... Why would that be the optimal method?
Ow. I suppose that's what you call "blinded by invalid implicit
assumptions". Obviously, if you are ok with such a grand move, this is
the best.
This also reminds me that I should finally merge the cg-mv patch.
> git fetch ../r1/
> GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
> GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
> git-update-cache --add -- $(GIT_INDEX_FILE=.git/tmp-index git-ls-files)
> cp .git/FETCH_HEAD .git/MERGE_HEAD
> git commit
But if you want to have an idea what's actually going on on the high
level, perhaps the
cd r2
cg-branch-add r1 ../r1/.git
cg-fetch r1
cg-merge -j r1
might be easier. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Joining Repositories
From: Andreas Ericsson @ 2006-01-18 14:14 UTC (permalink / raw)
To: Mathias Waack; +Cc: git
In-Reply-To: <200601181501.38791.Mathias.Waack@rantzau.de>
Mathias Waack wrote:
> Hello Petr,
>
> thanks for your quick answer, but...
>
> On Wednesday 18 January 2006 01:58 pm, Petr Baudis wrote:
>
>>Dear diary, on Wed, Jan 18, 2006 at 01:51:58PM CET, I got a letter
>>where Petr Baudis <pasky@suse.cz> said that...
>>
>>
>>> But if you want r1/a, r2/b to turn to r/r1/a, r/r2/b, you will have
>>>to rewrite the history of each (and then do the above). One rough
>>>and untested sketch...
>>>
>>> mkdir r1-rewritten
>>> cd r1-rewritten
>>> cp -a ../r1/.git .
>>
>> mkdir commitmap
>>
>>
>>> for commit in $(git-rev-list --topo-order HEAD | tac); do
>>> git-read-tree --prefix=r1/ $commit
>
>
> ...git-read-tree doesn't know the parameter --prefix (just downloaded and
> tried it on 0.99.9i). What version shall I use?
>
If you're using 0.99.9i you're missing out on the 584 commits that has
been committed since then. 1.1.3 was released a couple of days ago. I
suggest you upgrade.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Joining Repositories
From: Petr Baudis @ 2006-01-18 14:14 UTC (permalink / raw)
To: Mathias Waack; +Cc: git
In-Reply-To: <200601181501.38791.Mathias.Waack@rantzau.de>
Hello,
Dear diary, on Wed, Jan 18, 2006 at 03:01:38PM CET, I got a letter
where Mathias Waack <Mathias.Waack@rantzau.de> said that...
> On Wednesday 18 January 2006 01:58 pm, Petr Baudis wrote:
> > Dear diary, on Wed, Jan 18, 2006 at 01:51:58PM CET, I got a letter
> > where Petr Baudis <pasky@suse.cz> said that...
> >
> > > But if you want r1/a, r2/b to turn to r/r1/a, r/r2/b, you will have
> > > to rewrite the history of each (and then do the above). One rough
> > > and untested sketch...
> > >
> > > mkdir r1-rewritten
> > > cd r1-rewritten
> > > cp -a ../r1/.git .
> >
> > mkdir commitmap
> >
> > > for commit in $(git-rev-list --topo-order HEAD | tac); do
> > > git-read-tree --prefix=r1/ $commit
>
> ...git-read-tree doesn't know the parameter --prefix (just downloaded and
> tried it on 0.99.9i). What version shall I use?
oops, it seems this is only in the latest pu branch of git. If you are
not brave enough for that, you will need to use the prefix facility of
checkout-index instead, and it'll take much longer:
git-read-tree $commit
git-checkout-index -a --prefix=r1/
rm .git/index
cg-add -r r1/
rm -rf r1
.. then proceed with git-cat-file etc ..
Note that I'm not sure when which feature was introduced. Your best
bet is to just use the latest stable GIT/Cogito versions.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Joining Repositories
From: Ryan Anderson @ 2006-01-18 14:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: Mathias Waack, git
In-Reply-To: <20060118125158.GN28365@pasky.or.cz>
On Wed, Jan 18, 2006 at 01:51:58PM +0100, Petr Baudis wrote:
> Hello,
>
> Dear diary, on Wed, Jan 18, 2006 at 01:25:59PM CET, I got a letter
> where Mathias Waack <Mathias.Waack@rantzau.de> said that...
> > we're using git with cogito as a frontend. For some reasons I forgot we have
> > some repositories which belong to the same project. To simplify the whole
> > thing I would like to join these repositories. It mainly means to move some
> > directories. So lets say I have:
> >
> > /r1/.git
> > /r2/.git
> >
> > and what I would like to have is
> >
> > /r/.git
> > r1
> > r2
> >
> > Of course the history should remain (otherwise it would be to easy).
> >
> > How should I do this?
>
> The crucial question is what the joined repository's directory
> structure should be. If from r1/a, r2/b you want r/a, r/b then it's
> easy:
>
> cd r1
> cg-branch-add r2 ../r2/.git
> cg-fetch r2
> cg-merge -j r2
>
> But if you want r1/a, r2/b to turn to r/r1/a, r/r2/b, you will have
> to rewrite the history of each (and then do the above). One rough
> and untested sketch...
... Why would that be the optimal method?
Assuming both repositories are clean, no extraneous files, and without
testing, of course:
In r1:
mkdir r1
# move everything into the subdirectory called r1.
git mv $(ls -a | grep -v -e ^.git$ -e ^r1$) r1/
git commit -a "Restructure directory"
In r2:
mkdir r2
# move all files into r2/
git mv $(ls -a | grep -v -e ^.git$ -e ^r2$) r2/
git commit -a "Restructure directory"
git fetch ../r1/
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- $(GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit
No history rewritten, merging with the old repositories should, at least
theoretically, work, etc.
(This is just a restatement of Linus's "Coolest merge ever" / union
merge)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* New ref generates 8MB mail message
From: Matthew Wilcox @ 2006-01-18 14:09 UTC (permalink / raw)
To: git
There's a bit of an unfortunate mistake in the default mail script
that causes making a new ref for Linus' kernel tree to generate an 8MB
mail message.
Based on the idea that a new branch is probably a branch off master, and
if it isn't, then at least sending a log vs master is better than a log
vs the beginning of time, I propose this patch:
diff --git a/templates/hooks--update b/templates/hooks--update
index 6db555f..609b4fe 100644
--- a/templates/hooks--update
+++ b/templates/hooks--update
@@ -13,7 +13,7 @@ recipient="commit-list@example.com"
if expr "$2" : '0*$' >/dev/null
then
echo "Created a new ref, with the following commits:"
- git-rev-list --pretty "$3"
+ git-rev-list --pretty "$3" ^master
else
base=$(git-merge-base "$2" "$3")
case "$base" in
^ permalink raw reply related
* Re: Joining Repositories
From: Mathias Waack @ 2006-01-18 14:01 UTC (permalink / raw)
To: git
In-Reply-To: <20060118125857.GO28365@pasky.or.cz>
Hello Petr,
thanks for your quick answer, but...
On Wednesday 18 January 2006 01:58 pm, Petr Baudis wrote:
> Dear diary, on Wed, Jan 18, 2006 at 01:51:58PM CET, I got a letter
> where Petr Baudis <pasky@suse.cz> said that...
>
> > But if you want r1/a, r2/b to turn to r/r1/a, r/r2/b, you will have
> > to rewrite the history of each (and then do the above). One rough
> > and untested sketch...
> >
> > mkdir r1-rewritten
> > cd r1-rewritten
> > cp -a ../r1/.git .
>
> mkdir commitmap
>
> > for commit in $(git-rev-list --topo-order HEAD | tac); do
> > git-read-tree --prefix=r1/ $commit
...git-read-tree doesn't know the parameter --prefix (just downloaded and
tried it on 0.99.9i). What version shall I use?
Mathias
^ permalink raw reply
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Alex Riesen @ 2006-01-18 13:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvewi2typ.fsf@assigned-by-dhcp.cox.net>
On 1/18/06, Junio C Hamano <junkio@cox.net> wrote:
> Instead of depending on $SECONDS (isn't it a bashism?), how
> about doing something like this?
Probably not, even QNX6 ksh has it, and being the most broken shell
I ever met, I'd consider $SECONDS safe 8-)
^ permalink raw reply
* cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Alex Riesen @ 2006-01-18 13:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 996 bytes --]
For reasons unknown, cygwin decided to use our sockaddr_storage.
As it is redefined to sockaddr_in it'd cause compilation errors in
cygwin headers. Fixed by first patch, which uses a more git-related
name (can we claim rights for the symbol, being first to use it? :-)
For the other, probably unrelated, reasons, they decided to leave
declarations of DT_* macros in dirent.h without providing dirent->d_type.
This is what NO_DTYPE in the 0002-patch is all about.
And on top of that, they removed dirent->d_ino (or probably replaced
it by __ino32, if at all).
BTW, can we somehow avoid using d_ino? It is referenced only in fsck-objects.c
Anyway, to workaround this I put
COMPAT_CFLAGS += -Dd_ino=__ino32
It helps, but surely is not the solution.
P.S. For all you poor souls on Win2k, my config.mak contains:
NO_MMAP = YesPlease
NO_DTYPE = YesPlease
COMPAT_CFLAGS += -Dd_ino=__ino32
Just to make it work (at least it's enough for me, even the tests run...)
[-- Attachment #2: 0001-fix-compilation-of-sockaddr_storage.txt --]
[-- Type: text/plain, Size: 1355 bytes --]
>From nobody Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Wed Jan 18 14:02:54 2006 +0100
Subject: fix compilation of sockaddr_storage
---
Makefile | 2 +-
daemon.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
59379c380a6c2829c5614aadd4a5492abb8d14c8
diff --git a/Makefile b/Makefile
index f6d9e0a..5782e2a 100644
--- a/Makefile
+++ b/Makefile
@@ -342,7 +342,7 @@ ifdef NO_MMAP
COMPAT_OBJS += compat/mmap.o
endif
ifdef NO_IPV6
- ALL_CFLAGS += -DNO_IPV6 -Dsockaddr_storage=sockaddr_in
+ ALL_CFLAGS += -DNO_IPV6 -Dsockaddr_stg_git=sockaddr_in
endif
ifdef PPC_SHA1
diff --git a/daemon.c b/daemon.c
index bb014fa..b424e5e 100644
--- a/daemon.c
+++ b/daemon.c
@@ -277,7 +277,7 @@ static unsigned int children_deleted = 0
static struct child {
pid_t pid;
int addrlen;
- struct sockaddr_storage address;
+ struct sockaddr_stg_git address;
} live_child[MAX_CHILDREN];
static void add_child(int idx, pid_t pid, struct sockaddr *addr, int addrlen)
@@ -578,7 +578,7 @@ static int service_loop(int socknum, int
for (i = 0; i < socknum; i++) {
if (pfd[i].revents & POLLIN) {
- struct sockaddr_storage ss;
+ struct sockaddr_stg_git ss;
unsigned int sslen = sizeof(ss);
int incoming = accept(pfd[i].fd, (struct sockaddr *)&ss, &sslen);
if (incoming < 0) {
--
1.1.2-ge577
[-- Attachment #3: 0002-fix-compilation-of-dirent-d_type.txt --]
[-- Type: text/plain, Size: 1137 bytes --]
>From nobody Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Wed Jan 18 14:04:34 2006 +0100
Subject: fix compilation of dirent->d_type
---
Makefile | 3 +++
cache.h | 10 +++++++++-
2 files changed, 12 insertions(+), 1 deletions(-)
5232f9128ad9d10368525fe709954acc2d6f49b3
diff --git a/Makefile b/Makefile
index 5782e2a..c3bae0f 100644
--- a/Makefile
+++ b/Makefile
@@ -329,6 +329,9 @@ ifdef NEEDS_NSL
LIBS += -lnsl
SIMPLE_LIB += -lnsl
endif
+ifdef NO_DTYPE
+ COMPAT_CFLAGS += -DNO_DTYPE
+endif
ifdef NO_STRCASESTR
COMPAT_CFLAGS += -DNO_STRCASESTR
COMPAT_OBJS += compat/strcasestr.o
diff --git a/cache.h b/cache.h
index 29c9e81..3846fb9 100644
--- a/cache.h
+++ b/cache.h
@@ -10,13 +10,21 @@
#define deflateBound(c,s) ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11)
#endif
-#ifdef DT_UNKNOWN
+#ifndef NO_DTYPE
#define DTYPE(de) ((de)->d_type)
#else
+#ifndef DT_UNKNOWN
#define DT_UNKNOWN 0
+#endif
+#ifndef DT_DIR
#define DT_DIR 1
+#endif
+#ifndef DT_REG
#define DT_REG 2
+#endif
+#ifndef DT_LNK
#define DT_LNK 3
+#endif
#define DTYPE(de) DT_UNKNOWN
#endif
--
1.1.2-ge577
^ permalink raw reply related
* Re: RFC: Subprojects
From: Andreas Ericsson @ 2006-01-18 13:29 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Junio C Hamano, git
In-Reply-To: <200601181747.15609.lan@ac-sw.com>
Alexander Litvinov wrote:
>>I started this "bind" design as a thought experiment, but I
>>started to like it more and more.
>>
>
>
> Is there a version of git with this to try it ?
The pu branch of the official git repo.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Joining Repositories
From: Petr Baudis @ 2006-01-18 12:58 UTC (permalink / raw)
To: Mathias Waack; +Cc: git
In-Reply-To: <20060118125158.GN28365@pasky.or.cz>
Dear diary, on Wed, Jan 18, 2006 at 01:51:58PM CET, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> But if you want r1/a, r2/b to turn to r/r1/a, r/r2/b, you will have
> to rewrite the history of each (and then do the above). One rough
> and untested sketch...
>
> mkdir r1-rewritten
> cd r1-rewritten
> cp -a ../r1/.git .
mkdir commitmap
> for commit in $(git-rev-list --topo-order HEAD | tac); do
> git-read-tree --prefix=r1/ $commit
> # here, setup the AUTHOR/COMMITTER variables
> # appropriately (you can look at cg-commit's
> # $copy_commit handler)
> git-cat-file commit "$commit" | sed -e '1,/^$/d' | \
> git-commit-tree $(git-write-tree) \
> $(for parent in $(cg-object-id -p $commit); do
echo -p
> cat commitmap/$parent
> done) >commitmap/$commit
> last_commit=$commit
> done
> git-update-ref HEAD $(cat commitmap/$last_commit)
rm -rf commitmap
cg-reset
And at this point, git-prune will have plenty of work to do (many of
your tree and commit objects will be outdated - you just rewrote them).
It's quite beautiful that you can do this all without checkouting a
single thing - you just load the tree to the index, prepend "r1/" to all
the paths, and commit it back.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Joining Repositories
From: Petr Baudis @ 2006-01-18 12:51 UTC (permalink / raw)
To: Mathias Waack; +Cc: git
In-Reply-To: <200601181325.59832.Mathias.Waack@rantzau.de>
Hello,
Dear diary, on Wed, Jan 18, 2006 at 01:25:59PM CET, I got a letter
where Mathias Waack <Mathias.Waack@rantzau.de> said that...
> we're using git with cogito as a frontend. For some reasons I forgot we have
> some repositories which belong to the same project. To simplify the whole
> thing I would like to join these repositories. It mainly means to move some
> directories. So lets say I have:
>
> /r1/.git
> /r2/.git
>
> and what I would like to have is
>
> /r/.git
> r1
> r2
>
> Of course the history should remain (otherwise it would be to easy).
>
> How should I do this?
The crucial question is what the joined repository's directory
structure should be. If from r1/a, r2/b you want r/a, r/b then it's
easy:
cd r1
cg-branch-add r2 ../r2/.git
cg-fetch r2
cg-merge -j r2
But if you want r1/a, r2/b to turn to r/r1/a, r/r2/b, you will have
to rewrite the history of each (and then do the above). One rough
and untested sketch...
mkdir r1-rewritten
cd r1-rewritten
cp -a ../r1/.git .
for commit in $(git-rev-list --topo-order HEAD | tac); do
git-read-tree --prefix=r1/ $commit
# here, setup the AUTHOR/COMMITTER variables
# appropriately (you can look at cg-commit's
# $copy_commit handler)
git-cat-file commit "$commit" | sed -e '1,/^$/d' | \
git-commit-tree $(git-write-tree) \
$(for parent in $(cg-object-id -p $commit); do
cat commitmap/$parent
done) >commitmap/$commit
last_commit=$commit
done
git-update-ref HEAD $(cat commitmap/$last_commit)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Joining Repositories
From: Mathias Waack @ 2006-01-18 12:25 UTC (permalink / raw)
To: git
Hello everybody,
we're using git with cogito as a frontend. For some reasons I forgot we have
some repositories which belong to the same project. To simplify the whole
thing I would like to join these repositories. It mainly means to move some
directories. So lets say I have:
/r1/.git
/r2/.git
and what I would like to have is
/r/.git
r1
r2
Of course the history should remain (otherwise it would be to easy).
How should I do this?
Thanks for your answers
Mathias
^ permalink raw reply
* Re: RFC: Subprojects
From: Alexander Litvinov @ 2006-01-18 11:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy81eyz47.fsf@assigned-by-dhcp.cox.net>
> I started this "bind" design as a thought experiment, but I
> started to like it more and more.
>
Is there a version of git with this to try it ?
^ permalink raw reply
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Johannes Schindelin @ 2006-01-18 11:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vmzhtzzlf.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 18 Jan 2006, Junio C Hamano wrote:
> @@ -48,7 +48,7 @@ EOF
>
> test_expect_success \
> 'diff removed symlink' \
> - 'rm frotz &&
> + 'mv frotz nitfol &&
> git-diff-index -M -p $tree > current &&
> compare_diff_patch current expected'
>
> @@ -58,8 +58,7 @@ EOF
>
> test_expect_success \
> 'diff identical, but newly created symlink' \
> - 'sleep 1 &&
> - ln -s xyzzy frotz &&
> + 'ln -s xyzzy frotz &&
And where does the time lag (required for the test) come from now?
Ciao,
Dscho
^ permalink raw reply
* Re: [QUESTION] What is a tag for?
From: Andreas Ericsson @ 2006-01-18 10:35 UTC (permalink / raw)
To: kernel-hacker; +Cc: git
In-Reply-To: <1137538344.9104.34.camel@malory>
Alex Bennee wrote:
> Hi,
>
> So I want to track Linus's 2.6 git tree as well as do a little small
> time hacking. I'm not brave enough to sit on the very bleeding edge and
> build what ever happens to be at the "HEAD" of the tree. However when a
> kernel releases I'd like to build *that* kernel.
>
> I keep thinking of tags like labels in the old convetional SCM case. Is
> this correct? I can see once I've done my update (fetch/cogito what
> ever) that these tags apear in my local tree:
>
I'm not sure if you got the answer you wanted from Junio or Petr, so I
thought I'd add my own explanation to this as well. If nothing else it
might be useful for someone greping through the archives.
There are three types of tags: simple, annotated and signed+annotated.
All tags work just as a branch head, except that you can't do 'git
checkout' on it (i.e. it's a pointer to a particular commit, but lives
in $GIT_DIR/refs/tags instead of $GIT_DIR/refs/heads).
Simple, or unannotated, tags are useful for creating anchor points so
that you can jump to a particular state of development that's useful for
you as a developer to know about (I for one think sha-hashes are a tad
hard to remember). You could just as easily create a branch for doing
this, but that's not always practical. F.e. when you're resetting or
rebasing the current branch or doing some other of gits more voodoo-ish
things. If you do
$ git cat-file -t <tagname>
on a simple tag it'll tell you it's a "commit" object, because that's
the type of the object it points to in the object database.
If you do the same on an annotated tag, whether it's signed or not, "git
cat-file -t <tagname>" will tell you it's a 'tag' object.
A tag object has a reference to a commit-object and some additional data
inside it. Try
$ git cat-file tag v1.0.0
in the current git-repo and you'll see the following output
----8<---8<---8<----
object c2f3bf071ee90b01f2d629921bb04c4f798f02fa
type commit
tag v1.0.0
tagger Junio C Hamano <junkio@cox.net> 1135152060 -0800
GIT 1.0.0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQBDqOh7wMbZpPMRm5oRAg+OAJ90pNi/fq5rguVou1PSxx95PYCVeACfbnZM
nN/PlwOWKA3rW8EPmWO4BzE=
=TCRg
-----END PGP SIGNATURE-----
----8<----8<----8<----
'object' at the first line is the commit the tag points to. The rest
should be fairly self-evident.
After the empty line there follows a message that the tagger can enter
when typing the tag. This can be fairly useful if you wish to make it
so. I use it to write a gisted changelog, listing new features and fixed
bugs in a few words. All annotated tags that gets pushed to our shared
repos are automatically, through the 'update' hook, sent by email to our
sales and marketing people. I like that, since I only have to use one
tool for hacking, reporting, logging history and everything else that's
real developer work. It also means I never forget sending feature
updates to the suits, so they pester me less and life is a bit sweeter.
A signed annotated tag requires that you have a valid gpg key. The tag
shown above is signed using gpg (the only way of signing supported, I
think).
So, in essence;
* A simple, or unannotated tag just points to a commit object and has no
message attached to it.
* An annotated tag points to a tag object and has a message of arbitrary
length attached to it. The tag object points to a commit object.
* Only annotated tags can be signed.
I'd recommend not allowing un-annotated tags in your shared repo. I sent
a patch for the default update-hook sometime ago that disallows this.
Junio seemed happy about it so I don't understand why it hasn't been
pushed to the master branch yet.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [QUESTION] What is a tag for?
From: Petr Baudis @ 2006-01-18 10:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Bennee, git
In-Reply-To: <7v1wz648jc.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Jan 18, 2006 at 02:41:27AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Alex Bennee <kernel-hacker@bennee.com> writes:
> > Is the
> > only way to know I'm building 2.6.16-rc1 to branch from it as described
> > in git-branch, even if I'm not planning on doing any development?
>
> I do not quite understand. Immediately after the above example
> checkout, before or after doing the hackhack and commit, git
> branch would probably say:
>
> $ git branch
> origin
> master
> * myhack
Well if I understand it, at this point he would just periodically fetch
and get the tags, and when a new release appears, he would merge it to
myhack, and so on. Which is probably the only way if you don't have
cg-seek (I thought git checkout could do it, but it doesn't seem to be
the case), but I can see no advantage of doing it if you can just
cg-seek (unless, after all, you do want to do some development). But
just in case, with Cogito that would be:
$ cg-switch -r v2.6.16-rc1 myhack
# You need Cogito-0.17.GIT for this. It is equivalent to git
# branch, I think.
$ cg-fetch
$ cg-fetch
$ cg-fetch
$ cg-merge v2.6.16-rc2
$ cg-fetch
$ cg-merge v2.6.16
...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [QUESTION] What is a tag for?
From: Petr Baudis @ 2006-01-18 9:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0c2ywq1.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]
Dear diary, on Wed, Jan 18, 2006 at 05:40:54AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > You fundamentally want to have some _other_ reason to trust the key, like
> > the fact that you can find it independently with google ;)
> >
> > Linus
>
> True. Here is mine, for google.
And here is my SuSE public key (which I use for signing Cogito tags)
for Google to mine. (And for a record, my personal PGP key which
I normally use for non-job related stuff is different and is available
at my homepage; I've also signed this mail with it, FWIW.)
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.2 (GNU/Linux)
mQGiBELIc0YRBADDsuMs8bWaEB85db2PLgGan0vXLp2ztfhuG0iSvFqRxhqwLW4F
RJuFp8+53dHzgSVSw7QETX0HeQCycg+dflKirhfQwJGmcm2Gkn9L3BtAhz855rug
WLct4RL/j3eusIR6wyOfMaNsHglVXzQT5h9kn6p0h5pP2E+v177qlnhqKwCgmYbq
eF5cEBUV2P/BMmXzVqBelGkD/jjAnsE38s+schg4xYZLTF1GLwnf7na3ddMLd2Pj
o2V0KSSMZMaDJ7dHgCl9dTwiE2IDJxnqMbHuaE5QuUrzbpi7X47IkK8wHIbSUHOZ
hyQBLiIJ2PXOSxwn6J4zIn2oysKwOsxbBE4RRJ90f/jpHw3q0P2YNtIgiQeyZZxi
MbltBACv56gQKBNAebms4AXx/8pFHc+YeYaK1STMpRnR6pNKkREz/nfa0IGkf59n
F+gARxEqjOPaCrNLEjwymAEmPJC/F46sgfOR5djihOs+GX4E4msqDE1Ht+jIc6xS
2M0tXLEZ5RAogJ53XyDsQnFBW1JyM9FKYiojoiRzlJB8FWuiPLQnUGV0ciBCYXVk
aXMgKFN1U0UgTGFicykgPHBhc2t5QHN1c2UuY3o+iF4EExECAB4FAkLIc0YCGwMG
CwkIBwMCAxUCAwMWAgECHgECF4AACgkQoqZU+9z5OURXUQCdHeDMjOoWkRZ47wJ4
7BkVu+siXC0Anjv9n+q15/h1My9e4NAr6X8GS217uQINBELIc0oQCAC1BRdneY8m
Goayc37lc0/aSlypmpwNTu8CRFoxl/JTXoqW31czfVFes1tlSJaLRidBFF9gW/An
KOIMhbOtMRZ4RGxorhrMYDjLQzYVkb1kJspMkG0BdCz3Cy3WKz/f4uvgImqOVx3E
uP/6DwsidUite4m0xPPXMRip4bRuoBatI3K/6UyUkxxDJ44Mnd7CqpF4+4YXgZTy
UuXRLo1P9/KcbcW+gngUBCQOjOYNLxup1rrRtcmP1qc2gmaNxUop6/zsBwuQPPVL
7iTgw00q9aVLSvFEXpjDl5qy+oau+kCeuza6liApOc5H18b6mXzEczn7vDF9XZwB
/diPXrZsiYFfAAMHCACZD9PrSCSmYdnfgKX+qElOmOXHi59CYj2B/o8Qn0Yh0jjK
63aBdVviqUGfunkC+dZgcMYvS5anfiGzeOFa90/z9O2Mr+WdCR/JG3DHXpKhFSKj
Ko6iQ6N6qnDcN1tskjfyv0cW+lEyCZjmgNqGBM7jGYVZ7JlOKtM/Jd9nzEo7HKjr
m+MihsduyXzqkEqn6H8k1ZxvcxgnQwBaZUBMSbBbYNTewBR7GkOoiGwPUFUaIBjP
CEyWjCEZmHRpGnKKxBLsxf7aUkr1JlEPFjDmx50YzxBAJ0oX1Y/ftePItPq9SzQM
j5GItjrP0KKNdm6R7SgVyiq5jLDVHeKh3zMjRspliEkEGBECAAkFAkLIc0oCGwwA
CgkQoqZU+9z5OUS99gCfV8ufkdnRSxVlv9Ej6nyUP1JBNo0An1/oDuJn8fcbfBFj
RDJA/3ar4p+f
=q7rT
-----END PGP PUBLIC KEY BLOCK-----
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Junio C Hamano @ 2006-01-18 8:53 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0601170325y60094b4w693ac37490c67410@mail.gmail.com>
Sorry, but the previous patch turns out to be bogus as well.
'touch' did not affect the timestamp of the symbolic link but
ended up creating a file pointed by it, and since we (hopefully)
correctly do lstat() not stat(), it did not have any good
effect. Here is an replacement.
-- >8 --
Subject: [PATCH] t4011: "sleep 1" sleeps too little on cygwin
This test depended on "sleep 1" not to return until the next
second boundary, to get a dirty index entry. An initial fix was
provided by Alex Riesen using a bashism $SECONDS, but make it a
bit more portable, and also work around a potential problem on a
filesystem with coarser-than-a-second timestamp granularity,
this patch fixes it a bit differently.
The test is checking if we correctly notice the stat changes,
and the timestamp is not the only thing we have in the stat part
of the index. This commit fixes the problem by leaving the
original symlink we create on the filesystem, so that it keeps
the inode number used for the original symlink in use, and then
create a second one which should get a different inode number.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
t/t4011-diff-symlink.sh | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
5f6849e7b60bc4908bf10a7946fd93d4aaaf9c35
diff --git a/t/t4011-diff-symlink.sh b/t/t4011-diff-symlink.sh
index e3ebf38..f0e3491 100755
--- a/t/t4011-diff-symlink.sh
+++ b/t/t4011-diff-symlink.sh
@@ -48,7 +48,7 @@ EOF
test_expect_success \
'diff removed symlink' \
- 'rm frotz &&
+ 'mv frotz nitfol &&
git-diff-index -M -p $tree > current &&
compare_diff_patch current expected'
@@ -58,8 +58,7 @@ EOF
test_expect_success \
'diff identical, but newly created symlink' \
- 'sleep 1 &&
- ln -s xyzzy frotz &&
+ 'ln -s xyzzy frotz &&
git-diff-index -M -p $tree > current &&
compare_diff_patch current expected'
--
1.1.3.gce7b
^ permalink raw reply related
* Re: [QUESTION] What is a tag for?
From: Junio C Hamano @ 2006-01-18 4:40 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0601171949430.3240@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> You fundamentally want to have some _other_ reason to trust the key, like
> the fact that you can find it independently with google ;)
>
> Linus
True. Here is mine, for google.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.2 (GNU/Linux)
mQGiBEAXWL4RBAC1hDSYXpgyl8Dyyd+fcVH6wKiCTKsCv1AkdTQP0M+N/+2JbS1n
okt+7UBbI31s2ZtXRmXjru1Kzq6Z/HLLsZCF1fH8iLXMe1YtVN81Rn9jpqPvs+l/
zvbVoVE/qwx0eHj/nl4jI9D8RYp8x+Ixor2MzNh/MKs02UtT8egPZVU3bwCgn7vF
D+xpLwmUnWRaAqFhlRnjGKsD+wSAspa3k70LqatuasE8urLTUnDw+AYLfSI4QYXA
S/uEDcV3VmeLpcV51YgsVqCDJk5jLe3EYENM6cFA5kGRZEPXqtwihXqXZuKD5m7j
g/3cbrKELEZuYiGrRzgJwW43RWc1FpA2TwpxI8k+XlI5u1p2AXo8vP5OoZ28ePZX
tXHdBACKlYxpeqspxgfZbFBlu1d0yPJqZkIaHzrZv7UOQPzvnFzTZSBk3ctx7ev8
AqYTUDZCm68yql4olTOvqlS/e6iQEU131NbEHvnq3BcXaKmr3L/rpo2b+LUyNKvu
vrBrNIznnPobWMZQ+nAzcKg5QrJ7IMr4RbYBMrULkYtu62HoqLQfSnVuaW8gQyBI
YW1hbm8gPGp1bmtpb0Bjb3gubmV0PoheBBMRAgAeBQJAF1i+AhsDBgsJCAcDAgMV
AgMDFgIBAh4BAheAAAoJEMDG2aTzEZuau1EAoITfGTTGbFYnCy/QFpwU1n9pehoo
AJ9giNg0AMiJ9F5KcZNfweDeRVZ5WNHFPMU6ARAAAQEAAAAAAAAAAAAAAAD/2P/g
ABBKRklGAAEBAQBIAEgAAP/bAEMACAYGBwYFCAcHBwkJCAoMFA0MCwsMGRITDxQd
Gh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv/bAEMBCQkJDAsM
GA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMv/AABEIADAAMAMBIgACEQEDEQH/xAAZAAACAwEAAAAAAAAAAAAA
AAAEBQMGBwj/xAA0EAABAwIGAAQEBQMFAAAAAAABAgMEBREABhITITEHFCJBMlFh
gQgWQlKRFRgjVZKh0eH/xAAaAQACAwEBAAAAAAAAAAAAAAACAwEEBQAG/8QAJxEA
AgEDAwQABwAAAAAAAAAAAQIDAAQREzFBBRIhUSJSkaGxwfD/2gAMAwEAAhEDEQA/
AK7gz+lT/Jeb8o7sfv0+1r3t3a3v1gvJ+RhXMzJr1SkJdp0I/wCGMeLOgA3V8x7/
ADJ74HOtwZ9OqkZS4EmPJYSooUWVBSQodjj3x6m7600MpjVNjya15r8o5QLtWG4l
jRnpkluPHbU464bJQnsnDGvZdpNMqUqpUZxBYlPFp9togobdQTccdE3N0+xH8SZF
hQ8h0uqZsrb61ia/tR0tp1LWnUegLDUTe/Fhbg84dJ1YrbLOqb5G+x4o2vsQiQLv
9qnk5JrkZhLpjJcBTqUltYJRxex/8v1ioRKvBnSFx47xU6gEqSW1JIANj2B7nHQK
qjGL6ojchjz2jWmOtwBXVxcd2+2Meq8CBPfXmiPCVT55ecp9RiagUpfSQSoWHNxb
ni4txipZdXuJplicDB/vdJgvpJJAhx5phRfESg0ilyqDWpXliGzoWhtS7hd7g6Qb
Ed824I7xJleHTKl4YM0elZgmN+WkEuzKclaFqOsqsUkBViFD+BybYrsPwSqmbAur
QpUeFGfJUnfJVuK1EKI03I5HRt3xx1cKF4O5jy9CVGh1iKkLVrWUyHE3VYDoI64+
uM+4gEl0/ewUZPOaqyxBpm7iB5qk1rMlFg1asMpmN2ly0vlCEqUGylAQehwonUSP
txg17OOWK3l1ijVOrKjS4b6HIskMqcQhaD6TYCxFjY8i4F784Kf/AA4VRckLZqsF
pkm6mytaj30Do44+YP3wP/bZXv8AXKb/ALV/9YU7vo6HwkA5znz+f1QHIj0vBGc1
o8qo5SjPwM0T50FMpUYtMSi7YLSbE6Ek/wDPdj3bGf5gzllybINHozjsh6TNclvv
j4CvR8+L+kAC1/h++CJ/4fKzLh0+O1U6cyIjJbJ1OK3CVFRVa3HJPX0+WE8zwSqm
UwirTZUebGYIUrYJTtq1AJJ1WJ5PQv1zx3NkjrcoQRuORXW6MJVIxv7Fbi0gjJ1A
eNdnUlsR4zN4jTK9xbu22gHcaXb1KA4t8Rvx0YqI81XIcZeaqrvLa3kxCzG0PIa2
0uFR2Li5Wm9lD4zpsBxVafIydm7KlLhV409EmnBkaZQRqToWk2SpxNilYaAUE/pV
Y/PDZVO8PTXIdXCsvolRGtprSY4Att6FdX1IDSQgg+kEgfRNxbyrKwKnc8VEkbhy
CKcUVhxE+alWZKlUzFX5d5iU0wlLbhQhwEFtlBJ0rT7keo+44TsZrqT8+hgGmtsV
yQtDEdeoSYiWkKW4HE3stdkFCgNOytQB3bcyUWLkPL0+bNpcihRn5a7qU0thG2nQ
hOhGmxCCWwoj9xJ98Dtw8spzOK6vNjDj4kGRtbkNCVK21tJClIbDiwlDignUs2+u
FaMnyn6UGm/qmlNm1J13Mwjxm3ZkephptmTPVslOwwoaVBolsFKtRTpV6yrkg3Ce
l1mqVjw0kO1cQRKcoSJOpiVuOOBxlR3HG9tAbuUmwBULhQB9PLSm/kOjSFSKX+W4
L6kFCnIuw0opuDYlNja4Bt9BhLXalk7L2W6lHoLNIbkz2Czt05tCdf6bqLYt6Qsk
au+QMNt7eVpVAU7jijijcuABX//ZiF4EExECAB4FAkOfYfsCGwMGCwkIBwMCAxUC
AwMWAgECHgECF4AACgkQwMbZpPMRm5p1jACeJJpN/pzhXNIyIvHonUz/TOPzKVwA
nRopEwhA93VM6wCRV3zoSIYdswRiuQGNBEAXWMEQBgCDx+4Wn6bUxy3BDkUV9Tu6
ozi+z4FVwmgUgR5loLp2ay1wksE8QresmJuY1Hxypb7ODpqqoEiXtULf5XEsUJCQ
asYTkpWsUJjolfpiNwNaypfhZlA9rVpEhNEpupHmH4yqwd9NsULtE8Fy+8SWqPDm
Is5/Nj1Z5XvOaZBSBMVGgNDbK6PN702tYU9b9PMDF0D4auIA6vZxmncF+fcTgCEZ
kZjbwnQJgyb1bUpHyVwx2JIxHXVp8kyAKCezGYhrQx8AAwUGAIEzIeVo7C+Y5S8f
QzIXjorF6TALyrjCAlr+/tGsRBl5XwXuSyMZ71JR6lJ751wjhW48qjOuWnJjNLP+
6/AUjj/qibdoyZ/4Le9QlEbWJ6Et2wMdi1Dxp16EYoKO2EsGJOisxegJ4shUut0Q
2lETT5l2P78XmY+v8ZmaApRTPCVTIV4DQHoqPrmW7u9mfijR8KjqbLdfq7HCcXTV
ZOu31gagtrjVRRtM2B0k/3wHADRR4O9rYLuJO4bQgFk95Uv7R4hJBBgRAgAJBQJA
F1jBAhsMAAoJEMDG2aTzEZuanFQAn1O290ssuCN2APIWNs04nsOSYJV7AJwL+mWe
3ZMYGVhS3LY9Pa5ynxZLOA==
=avEp
-----END PGP PUBLIC KEY BLOCK-----
^ permalink raw reply
* Re: [QUESTION] What is a tag for?
From: Linus Torvalds @ 2006-01-18 4:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Bennee, git
In-Reply-To: <7v1wz648jc.fsf@assigned-by-dhcp.cox.net>
On Tue, 17 Jan 2006, Junio C Hamano wrote:
>
> <offtopic>
> Does anybody know where to obtain the public key to verify
> v2.6.16-rc1 tag?
> </offtopic>
Do a google search for "torvalds" and "tag signing key", and you'll find
the thread that has the original key in it.
In fact, if you search for "torvalds" "tag" and "BEGIN PGP PUBLIC KEY
BLOCK", it will be the first hit.
Anyway, here it is again. Linus' tag signing key. I could do what you do,
but I feel that it's kind of pointless to put the public key with the
project, since if you don't trust the project, you shouldn't trust the key
it contains as being from me.
You fundamentally want to have some _other_ reason to trust the key, like
the fact that you can find it independently with google ;)
Linus
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.1 (GNU/Linux)
mQGiBEJqZ4sRBADKttqQOCAxRzz5qGmo5QnSR5GTkSlPTm4lCuaVUon0qQPNrasr
cSBAOJ1MlXjhbRPrN3pAhI+taLgrWQ231zUNHxCTmWJZV3Yzxr8xJQGlfHlVOxXB
LI42tAfCjHOF7z8pPj6AGhtE2+fzq1U3mOlA/fUG4uYDOwIoPK+qgbM6SwCgulqs
DGlQKFFtFgW8HVnDftFmyZMD+wc0E9jRa9HJ3b1U3vY1jrxpoVw5QeeIZdSRnRFy
sknOHca5mlJvTidu1cs7xCuvpufw1VIVvgf4tPwXcTDEKthYEhoty+DFOqZ9R7pg
EMhjYbq+Q8yLT3OWQtUKV4B10FRYIWidnJ8y2CjLduTmB+cyj976oxEY/llLBbQM
yuDrBADDLw/3KZL5D75icA0l/uebQ6/73j8jcRoVu0gTqAdQBYL6Zv7Y0G7xHUCo
Eqgo+p2LXAeU9IoeA5/h8SNVDw4fYoqo6VQTkr+ydegHkjwlbrhOL/gxzlY1Pde1
TBi6+QCUssk0FCPMALt7M+OgFpSKx7pP2xSsDsMvvNNAmLl0JrQ0TGludXMgVG9y
dmFsZHMgKHRhZyBzaWduaW5nIGtleSkgPHRvcnZhbGRzQG9zZGwub3JnPoheBBMR
AgAeBQJCameLAhsDBgsJCAcDAgMVAgMDFgIBAh4BAheAAAoJEBd2LEZ24hy7I84A
nROHRYes4RU8btdleR0TgwJG7jMvAKCF2CingjxaC4sTL7BkFfNacTkBYLkBDQRC
ameMEAQAlJiw0IBltu5ihEXE4mFYiWHuVAoeufVJ9fONv67y6fu3efJ10PJ7AQdG
Ufez+8yxkrahyIVC77NuQLDrRfvgmrJ8sbP8xb6QEbY1bnwLeuciTolGjL+kYi17
J74iG2cQDyimnLWJm5lNqeUOz3nTW429SyLCRhXpR1lUjijiVi8AAwcD/1f4VEql
u9HHTA4S+1aoOQV5guZCr6JbYdWkAZeeFRpFSXfCae6uO8DhpD7o/8kiK3O8qP1O
yjQF0bG26iLCm8MdJCO0WQ2xsVlwrrvnNPpgRgbirOgoxHM4ESq/YV+MqXo41Hm0
ilHRM7OIbmm7uvFSlUJmUasuJRsrhibilbvNiEkEGBECAAkFAkJqZ4wCGwwACgkQ
F3YsRnbiHLsolQCfRVImDkgijhPGmwyI7T19bWltXwsAniMi9gakkN+9DT8E5kli
e8uTEk8f
=PRrZ
-----END PGP PUBLIC KEY BLOCK-----
^ permalink raw reply
* Re: RFC: Subprojects
From: Junio C Hamano @ 2006-01-18 3:49 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Josef Weidendorfer, git
In-Reply-To: <7vpsmq2tyb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>>> Reading such a commit is easy:
>>>
>>> $ git-read-tree $tree ;# ;-)
>>>
>>> But that is cheating.
>>
>> This is for backwards compatibility, I assume?
>
> This is done more for not having to touch *anything* that does
> "index vs working file", "tree vs index" and "tree vs working
> file via index". It also is the easiest way to keep the "a
> commit object name can be used in place of the tree object name
> of the tree it contains" invariant. Also I suspect this
> organization might help recursive subprojects, but if it is the
> case, that is just a byproduct, not a design goal.
I started this "bind" design as a thought experiment, but I
started to like it more and more.
One interesting outcome of keeping the whole tree in the index
and the tree object recorded in the commit object of the
toplevel project is that a merge in the toplevel project "just
works".
To preserve our sanity, let's say we refuse to merge two commits
that have different sets of subprojects. That is, they must
have the "bind" lines for the same set of subdirectories. The
commits bound at these subdirectories do not need to match.
Before starting a merge, we require that the index is in sync
with the tree object recorded in the top commit, just like we do
for a normal merge[*1*]. Then we use the current merge
machinery that does not know anything about "bind" to perform
the merge, using the merge base of the toplevel project and
usual three-way merge. From the mechanism point of view, there
is no need to look at commits on "bind" line of either side to
come up with the resulting tree.
We could notice that the commit bound at linux-2.6/ subdirectory
of one side is v2.6.15 and the other side is v2.6.16-rc1, and
because one is a fast-forward of the other, choose to pick the
tree associated with v2.6.16-rc1 commit without actually doing
the 3-way resolve of linux-2.6/ subtree part, but that is purely
a performance optimization [*2*].
When writing out the merge result as a commit, we would create
(this is the fun part) a commit for linux-2.6/ part that has two
parents: the commits bound to linux-2.6/ tree from the two
toplevel commits being merged are the parents of such a
subproject commit. And the resulting toplevel merge commit
would have that commit object name on its "bind" line.
Obviously, when the bound subproject head of one side is a
fast-forwad of the other, we do not create such a merge commit
for the subproject; instead, we just record the one that is
ahead on the "bind" line of the resulting toplevel merge commit.
[Footnote]
*1* As a side effect, this also ensures the index is in sync
with the bound commits of the subprojects. As an additional
requirement, we may want to enforce that the bound commits must
match the branch heads that keep track of subprojects.
*2* Of course, from the usability, safety and confusion
avoidance point of view, it _might_ make sense to require that
bound commits are in such fast-forward relationship. But that
is a policy issue; at the mechanism level, there is no need to
impose such a requirement.
^ 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