* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Junio C Hamano @ 2006-01-18 16:55 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0601180550k4df9b89fwf73af7966095ffc7@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> 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-)
When I have to answer these questions myself, I mostly do so by
checking http://www.opengroup.org/onlinepubs/009695399/.
^ permalink raw reply
* Re: Joining Repositories
From: H. Peter Anvin @ 2006-01-18 16:38 UTC (permalink / raw)
To: Mathias Waack; +Cc: git
In-Reply-To: <200601181325.59832.Mathias.Waack@rantzau.de>
Mathias Waack wrote:
> 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?
>
Rename the files in each repository independently (with a checkin), then
merge the repositories.
Git *should* track across the rename, as long as it's "obvious".
-hpa
^ permalink raw reply
* Re: Joining Repositories
From: Linus Torvalds @ 2006-01-18 16:23 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Petr Baudis, Mathias Waack, git
In-Reply-To: <20060118140917.GA15438@mythryan2.michonline.com>
On Wed, 18 Jan 2006, Ryan Anderson wrote:
>
> 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,
Right.
> merging with the old repositories should, at least theoretically, work,
> etc.
No. This - and the history rewriting - both have a fundamental problem: it
becomes totally impossible to merge back any changes of the subprojects,
at least automatically. The renaming just ends up making pretty much any
merge a manual affair (git can _help_, but it's going to be a matter of
luck if it works or not - and it usually won't work very well, because
you'll probably end up having files that have the same name in the new and
the old repo, and eventually you'll just have tons of confusion).
So it works only if you want to _really_ join the projects (like in the
"git tools" case), and never touch the old one again but it sucks
otherwise.
In the "gitk" case, we could actually continue to merge stuff after a
join, but that was largaly because there was no renaming. That's a very
special case, and it also became impossible to merge back.
Now, let's see what Junio comes up with, but in the meantime, I'd almost
suggest just something like
git clone oldrepo r1
cd r1
git checkout -b join-branch
cd ..
git add r1/.git/refs/heads/join-branch
git commit -m "Join repo 'oldrepo' at 'r1'"
which should actually work except for the fact that we don't like the
".git" component even as part of a sub-component (ie small hack to git
required to make it not ignore that path).
Linus
^ permalink raw reply
* 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
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