* Kernel headers git tree
From: David Woodhouse @ 2006-07-13 23:59 UTC (permalink / raw)
To: linux-kernel; +Cc: git
At http://git.kernel.org/git/?p=linux/kernel/git/dwmw2/kernel-headers.git
there's a git tree which contains the sanitised exported headers for all
architectures -- basically the result of 'make headers_install'.
It tracks Linus' kernel tree, by means of some evil scripts.¹
Only commits in Linus' tree which actually affect the exported result
should have an equivalent commit in the above tree, which means that any
changes which affect userspace should be clearly visible for review.
--
dwmw2
¹ http://david.woodhou.se/extract-khdrs-git.sh and
http://david.woodhou.se/extract-khdrs-stage2.sh for the stout of stomach
^ permalink raw reply
* Re: Kernel headers git tree
From: Junio C Hamano @ 2006-07-14 0:39 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1152835150.31372.23.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> ¹ http://david.woodhou.se/extract-khdrs-git.sh and
> http://david.woodhou.se/extract-khdrs-stage2.sh for the stout of stomach
With modern enough git, you can rewrite
KBUILDSHA=`git ls-tree $TREE -- Kbuild | cut -f3 -d\ | cut -f1`
with
KBUILDSHA1=`git rev-parse $TREE:Kbuild`
I am not sure what function incparent() is trying to do with
this:
git rev-list --max-count=1 --topo-order $1 -- .
^ permalink raw reply
* Re: Kernel headers git tree
From: David Woodhouse @ 2006-07-14 0:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pxlt3xg.fsf@assigned-by-dhcp.cox.net>
On Thu, 2006-07-13 at 17:39 -0700, Junio C Hamano wrote:
> With modern enough git, you can rewrite
> KBUILDSHA=`git ls-tree $TREE -- Kbuild | cut -f3 -d\ | cut -f1`
> with
> KBUILDSHA1=`git rev-parse $TREE:Kbuild`
Aha. Thanks.
> I am not sure what function incparent() is trying to do with
> this:
>
> git rev-list --max-count=1 --topo-order $1 -- .
Find the latest ancestor commit which actually changed any files. The
first script has a similar line, except that it finds the latest
ancestor which changed anything in include/
Consider a kernel tree with commits A-->B-->C-->D, of which only A and C
change anything in include/ and in fact only C actually changes the
_exported_ headers after the unifdef and sed bits.
The first script (extract-khdrs-git.sh) creates a 'stage1' branch which
only contains commits A'-->C', with the _exported_ header tree for each.
The second script (extract-khdrs-stage2.sh) then creates the master
branch with the same tree objects, but omitting the commits which don't
change anything. So it contains only commit C''
For an example of this, compare
http://git.kernel.org/git/?p=linux/kernel/git/dwmw2/kernel-headers.git
with
http://git.kernel.org/git/?p=linux/kernel/git/dwmw2/kernel-headers.git;a=shortlog;h=stage1
Btw, git-rev-list is _very_ slow at this. Even when the output is
actually HEAD, it takes my 2.3GHz G5 a _long_ time to give a result:
pmac /pmac/git/linux-2.6 $ git-rev-parse HEAD
ab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a
pmac /pmac/git/linux-2.6 $ time git-rev-list --max-count=1 --topo-order HEAD -- include
ab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a
real 0m18.840s
Is there a better way to do that step?
--
dwmw2
^ permalink raw reply
* Re: Kernel headers git tree
From: Linus Torvalds @ 2006-07-14 1:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Woodhouse, git
In-Reply-To: <7v4pxlt3xg.fsf@assigned-by-dhcp.cox.net>
On Thu, 13 Jul 2006, Junio C Hamano wrote:
>
> I am not sure what function incparent() is trying to do with
> this:
>
> git rev-list --max-count=1 --topo-order $1 -- .
Yeah, that looks strange.
The "--topo-order" in particular looks pointless, and just slows things
down.
The default ordering from git-rev-list (and all other revision listing
things, ie "git log" etc) _does_ guarantee that we never show a child
before _one_ of its parents has been shown (although "parent" in this case
may be the command line).
As such, "--max-count=1 --topo-order" is pointless if you only give one
revision, because whether you use --topo-order or not, the first commit
will always be the parent of all subsequent commits.
So --topo-order just makes things MUCH MUCH slower with no upsides.
But that thing is doubly strange, because it uses "." as a path specifier.
If this is done in the top-most directory, that should mean "all changes",
which in turn means that the whole thing should be equivalent to
git rev-parse "$1^0"
since all commits should make _some_ change, and thus the first revision
in the list should always be the top commit - the one you passed in as an
argument.
Linus
^ permalink raw reply
* Re: Kernel headers git tree
From: Linus Torvalds @ 2006-07-14 1:08 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, git
In-Reply-To: <1152838562.31372.58.camel@shinybook.infradead.org>
On Fri, 14 Jul 2006, David Woodhouse wrote:
>
> Btw, git-rev-list is _very_ slow at this. Even when the output is
> actually HEAD, it takes my 2.3GHz G5 a _long_ time to give a result:
>
> pmac /pmac/git/linux-2.6 $ git-rev-parse HEAD
> ab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a
> pmac /pmac/git/linux-2.6 $ time git-rev-list --max-count=1 --topo-order HEAD -- include
> ab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a
>
> real 0m18.840s
>
> Is there a better way to do that step?
Umm.. On my poor little 1.6GHz laptop:
[torvalds@evo linux]$ time git-rev-list --max-count=1 HEAD -- include
ab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a
real 0m0.014s
user 0m0.004s
sys 0m0.012s
that's 0.014 sec. Not exactly slow.
Now, the --topo-order you have there does slow it down a lot:
[torvalds@evo linux]$ time git-rev-list --max-count=1 --topo-order HEAD -- include
ab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a
real 0m24.016s
user 0m23.973s
sys 0m0.016s
so now it takes 24 seconds, and gives the same result.
Linus
^ permalink raw reply
* Re: Kernel headers git tree
From: David Woodhouse @ 2006-07-14 1:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607131800520.5623@g5.osdl.org>
On Thu, 2006-07-13 at 18:05 -0700, Linus Torvalds wrote:
>
> On Thu, 13 Jul 2006, Junio C Hamano wrote:
> >
> > I am not sure what function incparent() is trying to do with
> > this:
> >
> > git rev-list --max-count=1 --topo-order $1 -- .
>
> Yeah, that looks strange.
>
> The "--topo-order" in particular looks pointless, and just slows things
> down.
>
> The default ordering from git-rev-list (and all other revision listing
> things, ie "git log" etc) _does_ guarantee that we never show a child
> before _one_ of its parents has been shown (although "parent" in this case
> may be the command line).
Does it? I thought at one point it sorted on some random criterion like
alphabetically by author, or some other cosmetic information which isn't
really part of the git structure -- like the timestamp or something?
We still don't enforce monotonicity, do we? The timestamps are still
just fluff?
> But that thing is doubly strange, because it uses "." as a path specifier.
> If this is done in the top-most directory, that should mean "all changes",
> which in turn means that the whole thing should be equivalent to
>
> git rev-parse "$1^0"
>
> since all commits should make _some_ change, and thus the first revision
> in the list should always be the top commit - the one you passed in as an
> argument.
In this case, I really do have commits in the intermediate tree which
don't actually change anything, and I want to filter them out -- I
couldn't see a simple way to do it all in one pass.
--
dwmw2
^ permalink raw reply
* Most quality products for anyone who wants to become a champion in bed
From: Olive @ 2006-07-14 2:19 UTC (permalink / raw)
To: godard
Good Day!
Impress your girl with prolonged hardness, plentiful explosions and increased duration
Masculine performance has never been so easy to increase with these products
http://www.icicledid.com
To keep thee from the evil woman, from the flattery of the tongue of a strange woman. Little Strokes Fell Great Oaks There is always some madness in love But there is also always some reason in madness
The West Wind Always Brings Wet Weather, The East Wind Wet and Cold Together, the South Wind Surely Brings Us Rain, the North Wind Blows It Back Again All good things come to those who wait.
^ permalink raw reply
* Re: Kernel headers git tree
From: Junio C Hamano @ 2006-07-14 2:37 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1152838562.31372.58.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> On Thu, 2006-07-13 at 17:39 -0700, Junio C Hamano wrote:
>> With modern enough git, you can rewrite
>> KBUILDSHA=`git ls-tree $TREE -- Kbuild | cut -f3 -d\ | cut -f1`
>> with
>> KBUILDSHA1=`git rev-parse $TREE:Kbuild`
>
>
> Aha. Thanks.
>
>> I am not sure what function incparent() is trying to do with
>> this:
>>
>> git rev-list --max-count=1 --topo-order $1 -- .
>
> Find the latest ancestor commit which actually changed any files. The
> first script has a similar line, except that it finds the latest
> ancestor which changed anything in include/
>
> Consider a kernel tree with commits A-->B-->C-->D, of which only A and C
> change anything in include/ and in fact only C actually changes the
> _exported_ headers after the unifdef and sed bits.
>
> The first script (extract-khdrs-git.sh) creates a 'stage1' branch which
> only contains commits A'-->C', with the _exported_ header tree for each.
>
> The second script (extract-khdrs-stage2.sh) then creates the master
> branch with the same tree objects, but omitting the commits which don't
> change anything. So it contains only commit C''
I guess what I was getting at was if you can avoid creating
commits that do not change anything from previous in stage1
branch, you do not have to do this, but I haven't studied stage1
script deeply enough.
^ permalink raw reply
* Re: Error writing loose object on Cygwin
From: Shawn Pearce @ 2006-07-14 3:34 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060713055127.GA15960@trixie.casa.cgf.cx>
Christopher Faylor <me@cgf.cx> wrote:
> On Tue, Jul 11, 2006 at 09:15:38PM -0700, Junio C Hamano wrote:
> >Shawn Pearce <spearce@spearce.org> writes:
> >
> >> Has anyone else seen this type of behavior before? Any suggestions
> >> on debugging this issue?
> >
> >I would suggest raising this (politely) to Cygwin people.
>
> I lost the thread here but wasn't this referring to a samba mount? If so,
> it would be samba that's returning the wrong "errno".
I thought about that but Windows 2000 talking to the same samba
server issues back the correct errno. Running the exact same Cygwin
and GIT binaries (we've at least standardized on that). So it
seems weird that a samba server is issuing the correct error code
to a Windows 2000 client but the wrong one to a Windows XP client.
(In both cases the clients are accessing directories on the same
filesystem on the UNIX server.)
--
Shawn.
^ permalink raw reply
* [PATCH 1/2] Avoid using the git wrapper in git-rebase.sh.
From: Shawn Pearce @ 2006-07-14 4:46 UTC (permalink / raw)
To: git
Ideally 'shipped' commands (e.g. git-rebase) should avoid calling
the git wrapper when executing other commands to prevent the user
from shadowing those commands with aliases and causing the shipped
command behavior to differ unexpectedly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-rebase.sh | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 1b9e986..6d06665 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -131,7 +131,7 @@ do
finish_rb_merge
exit
fi
- git am --resolved --3way --resolvemsg="$RESOLVEMSG"
+ git-am --resolved --3way --resolvemsg="$RESOLVEMSG"
exit
;;
--skip)
@@ -150,7 +150,7 @@ do
finish_rb_merge
exit
fi
- git am -3 --skip --resolvemsg="$RESOLVEMSG"
+ git-am -3 --skip --resolvemsg="$RESOLVEMSG"
exit
;;
--abort)
@@ -163,7 +163,7 @@ do
else
die "No rebase in progress?"
fi
- git reset --hard ORIG_HEAD
+ git-reset --hard ORIG_HEAD
exit
;;
--onto)
@@ -231,7 +231,7 @@ esac
# The upstream head must be given. Make sure it is valid.
upstream_name="$1"
-upstream=`git rev-parse --verify "${upstream_name}^0"` ||
+upstream=`git-rev-parse --verify "${upstream_name}^0"` ||
die "invalid upstream $upstream_name"
# If a hook exists, give it a chance to interrupt
@@ -250,7 +250,7 @@ case "$#" in
git-checkout "$2" || usage
;;
*)
- branch_name=`git symbolic-ref HEAD` || die "No current branch"
+ branch_name=`git-symbolic-ref HEAD` || die "No current branch"
branch_name=`expr "z$branch_name" : 'zrefs/heads/\(.*\)'`
;;
esac
@@ -288,7 +288,7 @@ fi
if test -z "$do_merge"
then
git-format-patch -k --stdout --full-index "$upstream"..ORIG_HEAD |
- git am --binary -3 -k --resolvemsg="$RESOLVEMSG"
+ git-am --binary -3 -k --resolvemsg="$RESOLVEMSG"
exit $?
fi
--
1.4.1.gd3d5
^ permalink raw reply related
* [PATCH 2/2] Record rebase changes as 'rebase' in the reflog.
From: Shawn Pearce @ 2006-07-14 4:47 UTC (permalink / raw)
To: git
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-am.sh | 6 +++++-
git-rebase.sh | 9 ++++++---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index db9a20a..3a129e0 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -91,6 +91,7 @@ fall_back_3way () {
}
prec=4
+rloga=am
dotest=.dotest sign= utf8= keep= skip= interactive= resolved= binary= ws= resolvemsg=
while case "$#" in 0) break;; esac
@@ -130,6 +131,9 @@ do
--resolvemsg=*)
resolvemsg=$(echo "$1" | sed -e "s/^--resolvemsg=//"); shift ;;
+ --reflog-action=*)
+ rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`; shift ;;
+
--)
shift; break ;;
-*)
@@ -413,7 +417,7 @@ do
parent=$(git-rev-parse --verify HEAD) &&
commit=$(git-commit-tree $tree -p $parent <"$dotest/final-commit") &&
echo Committed: $commit &&
- git-update-ref -m "am: $SUBJECT" HEAD $commit $parent ||
+ git-update-ref -m "$rloga: $SUBJECT" HEAD $commit $parent ||
stop_here $this
if test -x "$GIT_DIR"/hooks/post-applypatch
diff --git a/git-rebase.sh b/git-rebase.sh
index 6d06665..14d7ed9 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -131,7 +131,8 @@ do
finish_rb_merge
exit
fi
- git-am --resolved --3way --resolvemsg="$RESOLVEMSG"
+ git-am --resolved --3way --resolvemsg="$RESOLVEMSG" \
+ --reflog-action=rebase
exit
;;
--skip)
@@ -150,7 +151,8 @@ do
finish_rb_merge
exit
fi
- git-am -3 --skip --resolvemsg="$RESOLVEMSG"
+ git-am -3 --skip --resolvemsg="$RESOLVEMSG" \
+ --reflog-action=rebase
exit
;;
--abort)
@@ -288,7 +290,8 @@ fi
if test -z "$do_merge"
then
git-format-patch -k --stdout --full-index "$upstream"..ORIG_HEAD |
- git-am --binary -3 -k --resolvemsg="$RESOLVEMSG"
+ git-am --binary -3 -k --resolvemsg="$RESOLVEMSG" \
+ --reflog-action=rebase
exit $?
fi
--
1.4.1.gd3d5
^ permalink raw reply related
* Re: Kernel headers git tree
From: Linus Torvalds @ 2006-07-14 5:16 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, git
In-Reply-To: <1152840456.31372.75.camel@shinybook.infradead.org>
On Fri, 14 Jul 2006, David Woodhouse wrote:
> >
> > The default ordering from git-rev-list (and all other revision listing
> > things, ie "git log" etc) _does_ guarantee that we never show a child
> > before _one_ of its parents has been shown (although "parent" in this case
> > may be the command line).
>
> Does it? I thought at one point it sorted on some random criterion like
> alphabetically by author, or some other cosmetic information which isn't
> really part of the git structure -- like the timestamp or something?
> We still don't enforce monotonicity, do we? The timestamps are still
> just fluff?
The timestamps are, and always have been, just a heuristic.
The output order of git-rev-list is actually entirely well-defined, but
it's the _cheap_ ordering, not the strict and full topological one.
The cheap ordering means that we don't ever look at the whole history, but
it's still a real "DAG reachability ordering" in the sense that when we
output a commit, we have _always_ output _one_ full path of commits to
reach that commit from one of the starting point.
But since you can traverse the DAG in any number of ways, the heuristic is
that when there are multiple choices, we pick the one with the most recent
commit date.
So to give an example, let's say we have
HEAD -> A
/ \
B C
/ \ \
D E F
\ / / \
G H I
.......
the difference between --topo-order and the default ordering for
git rev-list HEAD
is most visible for commit 'G'.
For --topo-order, we guarantee that before we show 'G', we _will_ have
shown both 'D' and 'E'. In other words, --topo-ordering guarantees that it
shows _all_ children before it shows the parent.
That's a _very_ very expensive thing to guarantee, because you can't
actually tell that you've seen all children on 'G' before you've basically
traversed most of the tree. In the above example, you CANNOT tell whether
'F' is a child of 'G', for exmaple. Think about it. You don't know - maybe
the missing piece is 'I' -> 'Z' -> 'G', but without having parsed all the
commits, you'll never know.
[ Actually, strictly speaking, you can guarantee it earlier than before
you parsed them _all_: you can guarantee it once _every_single_commit_
whose parents you haven't followed yet is a direct ancestor of 'G' - at
that point, and not before, do you know that 'G' can have no more
children. That's actually very expensive to compute, so we don't do it -
we will walk the whole history, and only _then_ do we use one of the
algorithms to generate a topological sort from the full DAG.
If somebody knows of an _incremental_ algorithm that doesn't need the
full DAG and can do a topo-ordering, that would be wonderful. But it's
basically very very very expensive. ]
So by default, we don't do that at all. By default, we will print out 'G'
whenever we have printed out _any_ path leading to 'G', and 'G' is the
commit with the most recent commit date.
So we might print things out as A, B, D, G, E ... - notice how we printed
out 'E' _after_ we did 'G', but we did have the A->B->D->G path, so G was
reachable from the top along the path we printed.
> In this case, I really do have commits in the intermediate tree which
> don't actually change anything, and I want to filter them out -- I
> couldn't see a simple way to do it all in one pass.
Ok, in that case, the "." is correct, but the --topo-order should be
unnecessary because you only care about the first entry.
Linus
^ permalink raw reply
* Re: Error writing loose object on Cygwin
From: Christopher Faylor @ 2006-07-14 5:24 UTC (permalink / raw)
To: Shawn Pearce, git
In-Reply-To: <20060714033435.GA1508@spearce.org>
On Thu, Jul 13, 2006 at 11:34:35PM -0400, Shawn Pearce wrote:
>Christopher Faylor <me@cgf.cx> wrote:
>> On Tue, Jul 11, 2006 at 09:15:38PM -0700, Junio C Hamano wrote:
>> >Shawn Pearce <spearce@spearce.org> writes:
>> >
>> >> Has anyone else seen this type of behavior before? Any suggestions
>> >> on debugging this issue?
>> >
>> >I would suggest raising this (politely) to Cygwin people.
>>
>> I lost the thread here but wasn't this referring to a samba mount? If so,
>> it would be samba that's returning the wrong "errno".
>
>I thought about that but Windows 2000 talking to the same samba
>server issues back the correct errno. Running the exact same Cygwin
>and GIT binaries (we've at least standardized on that). So it
>seems weird that a samba server is issuing the correct error code
>to a Windows 2000 client but the wrong one to a Windows XP client.
>(In both cases the clients are accessing directories on the same
>filesystem on the UNIX server.)
It's entirely possible that samba is behaving differently with different
versions of windows. OTOH, I believe that EACCES is the catch-all for
windows errors when translating into errnos so possibly it is an
uncaught error translation.
If you have the inclination and time, if you could run the session
under strace: "strace -o strace.out git ...",d snip twenty or
thirty lines on each side of the place where the the errno translation
is happening, and send it to the cygwin list at cygwin at cygwin
maybe something will be obvious.
Note that cygwin's strace is not anything like any other strace and
is quite a bit more wordy so, this file will be pretty large. That's
why I ask for some careful editing before sending it to the mailing
list. The errno number for EACCES on cygwin is 13.
cgf
^ permalink raw reply
* Re: Error writing loose object on Cygwin
From: Linus Torvalds @ 2006-07-14 5:26 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Christopher Faylor, git
In-Reply-To: <20060714033435.GA1508@spearce.org>
On Thu, 13 Jul 2006, Shawn Pearce wrote:
>
> I thought about that but Windows 2000 talking to the same samba
> server issues back the correct errno. Running the exact same Cygwin
> and GIT binaries (we've at least standardized on that). So it
> seems weird that a samba server is issuing the correct error code
> to a Windows 2000 client but the wrong one to a Windows XP client.
The samba connection protocol is fairly involved, and it will, as far as I
know, do a variety of "negotiation" of capabilities of both ends. What a
W2000 client does can very possibly be very different from what a WXP
client does, which in turn is certainly going to be different from a W98
client. It will simply talk a different version of the protocol.
I am also told that the error codes actually differ between different
versions of the samba protocol - not in the sense that different events
generate different error codes, but that the _same_ error (say "ENOENT")
is actually represented wioth different numbering in "old Windows SMB" and
"new windows SMB".
I don't know the details, and may have gotten them wrong, but the point
it, is't not at all impossible that the exact same version of Samba on the
server will negotiate a different protocol because the client OS is
different, and even though the Cygwin libraries and git binaries are the
exact same libraries/binaries, they might get different error codes from
the same system call.
(This may also explain why there are two "samba clients" in the kernel:
the CONFIG_SMB and CONFIG_CIFS. CIFS is the "new version SMB", and the
CIFS client currently doesn't even understand the old version - so you
might use SMB for old servers, and CIFS for new servers)
That said, I thought W2000 and WXP both negotiated the "new" protocol, but
there are probably config details even within that one..
Linus
^ permalink raw reply
* disable the compile-flags-changed check
From: Matthias Lederhofer @ 2006-07-14 5:47 UTC (permalink / raw)
To: git
Is there any way to disable the "the compile flags have changed,
recompile everything" check? I want to built with another prefix than
installing to create a tarball I copy to other machines. Is there any
way to do this? Otherwise: could we include something like this?
ifeq ($(IGNORE_CFLAG_CHANGES),)
# old GIT-CFLAGS rules
else
GIT-CFLAGS:
touch "$@"
endif
^ permalink raw reply
* Re: [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob
From: Junio C Hamano @ 2006-07-14 5:49 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20060712175220.73131.qmail@web31813.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
>> I think _allowing_ to accept filename not hash is a sane change,
>> and would be useful if you want to allow linking to always the
>> HEAD version from external sites,
>
> Indeed, it is useful.
>
>> but I do not think listing the
>> raw link in the tree view without the hash is a good idea. It
>> makes things quite confusing that "blob" link in its
>> neighbourhood gives the blob from that specific version, but
>> "raw" gives the version from HEAD, even when you are browsing
>> something other than HEAD.
>
> I just thought it to be an easy place to put the "raw"-no-hash
> link.
>
> BTW, Junio, it would be a shame to lose this capability. How
> would you like to proceed with this? Where would you like to
> see this kind of link go?
My preference?
Allowing to link the HEAD version from an _external_ source is
useful (i.e. you can put a link in gitwiki to point at a file
and say "the latest is always available at this URL").
We already support these:
a=blob&f=README
a=blob&f=README&hb=HEAD
a=blob&f=README&hb=HEAD~20
but not these:
a=blob_plain&f=README
a=blob_plain&f=t/test4012.png
The last example that does not generate text is less of a
problem, thanks to your previous patch, because "sub git_blob"
supports the "filename with or without hash base" syntax and
sends the correct hash to git_blob_plain to fall back, but that
does not help for text files. This patch corrects that, which
is nice.
However, I do not think the change to "sub git_tree" makes much
sense. The links within gitweb-generated pages are about
browsing the history. As I already said, having <blob> link
that is history specific and <raw> link which is not (iow always
goes to HEAD) next to each other is confusing, and you are
making it less easy to get a raw output from a specific version
because you removed that feature from the link and replaced it
with something less useful.
If somebody wants to see what the latest version of a blob looks
like while browsing the history with gitweb, I think it is a
more natural workflow to go to <history> link and find the
latest version. So maybe you might want to add <raw> link in
the output of the history action?
Side note: right now, <history> link does not show any
history newer than the commit that has the link itself;
maybe there is a room for improvement there but we need
to be careful not to trash the webserver caching.
Obviously you could go back to the repository top page and start
digging the latest tree from the top, but that is a bit more
cumbersome.
^ permalink raw reply
* Re: Kernel headers git tree
From: Linus Torvalds @ 2006-07-14 5:52 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, git
In-Reply-To: <1152840456.31372.75.camel@shinybook.infradead.org>
On Fri, 14 Jul 2006, David Woodhouse wrote:
>
> > But that thing is doubly strange, because it uses "." as a path specifier.
> > If this is done in the top-most directory, that should mean "all changes",
> > which in turn means that the whole thing should be equivalent to
> >
> > git rev-parse "$1^0"
> >
> > since all commits should make _some_ change, and thus the first revision
> > in the list should always be the top commit - the one you passed in as an
> > argument.
>
> In this case, I really do have commits in the intermediate tree which
> don't actually change anything, and I want to filter them out -- I
> couldn't see a simple way to do it all in one pass.
Btw, I'm actually surprised that my path simplification didn't filter out
the "." and make it mean exactly the same as not giving a path at all. I
thought I had done that earlier, but if you say "-- ." matters, then it
obviously does..
Linus
^ permalink raw reply
* Re: disable the compile-flags-changed check
From: Junio C Hamano @ 2006-07-14 6:06 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1G1GVy-00007o-PM@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Is there any way to disable the "the compile flags have changed,
> recompile everything" check? I want to built with another prefix than
> installing to create a tarball I copy to other machines. Is there any
> way to do this?
Perhaps
DESTDIR=/var/tmp/ make prefix=/usr install
is what you are looking for?
^ permalink raw reply
* Re: Kernel headers git tree
From: Ian Campbell @ 2006-07-14 7:20 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-kernel, git
In-Reply-To: <1152835150.31372.23.camel@shinybook.infradead.org>
On Fri, 2006-07-14 at 00:59 +0100, David Woodhouse wrote:
> At http://git.kernel.org/git/?p=linux/kernel/git/dwmw2/kernel-headers.git
> there's a git tree which contains the sanitised exported headers for all
> architectures -- basically the result of 'make headers_install'.
>
> It tracks Linus' kernel tree, by means of some evil scripts.¹
>
> Only commits in Linus' tree which actually affect the exported result
> should have an equivalent commit in the above tree, which means that any
> changes which affect userspace should be clearly visible for review.
It might be useful to append the commit checksum from Linus' tree to the
comments so it is easier to backtrack to the original commit.
Ian.
--
Ian Campbell
Your step will soil many countries.
^ permalink raw reply
* Re: Kernel headers git tree
From: Junio C Hamano @ 2006-07-14 7:52 UTC (permalink / raw)
To: Ian Campbell; +Cc: git, David Woodhouse
In-Reply-To: <1152861620.6977.3.camel@insmouth>
Ian Campbell <ijc@hellion.org.uk> writes:
> It might be useful to append the commit checksum from Linus' tree to the
> comments so it is easier to backtrack to the original commit.
Although I am not a kernel person, I can imagine how that would
be useful.
The pre-generated documentation branches in git.git repository
are managed similarly to allow tracking of the branch they
originate from.
^ permalink raw reply
* Re: Kernel headers git tree
From: David Woodhouse @ 2006-07-14 9:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607132251310.5623@g5.osdl.org>
On Thu, 2006-07-13 at 22:52 -0700, Linus Torvalds wrote:
> Btw, I'm actually surprised that my path simplification didn't filter out
> the "." and make it mean exactly the same as not giving a path at all. I
> thought I had done that earlier, but if you say "-- ." matters, then it
> obviously does..
In this specific case where I have a whole bunch of commits which don't
actually change anything, it definitely does make a difference...
hera /home/dwmw2 $ export GIT_DIR=/pub/scm/linux/kernel/git/dwmw2/kernel-headers.git
hera /home/dwmw2 $ git-rev-list --max-count=5 stage1
e4e2fcc2c333aac5f6331c1df256ff28d7ee76d7
32ca8021c5ab7b9d44e8a08aeb53e52af5223fec
6b8380885464e069ae22e1e04f4a905c9e918f4e
2dee58696cab32506f655cb94a63cf4b18a13b37
402429bc9ac5eb891f253f6dae1228338f7f0ea5
hera /home/dwmw2 $ git-rev-list --max-count=5 stage1 -- .
d1aba9314210d616cd2aa9ee91176c1dba6d3834
0b627fd403d6319fe50fbd8b95d5ea02017731fa
b29cfa21bbdfc25271ef446b9df94ed8b5425711
e2407b6a9a643b378700474c9079dd8620e820ed
c0df084d3e2ec0df6dafda8099e7c27c29760843
Junio is right -- if I can avoid creating commits that don't change any
files in the stage1 branch, then I don't have to do this. That would be
_hard_ though...
Currently, the selection of commits from your original tree to be
represented in the stage1 branch is simple -- it's "those commits which
touch include/". And 'rev-list -- include' works nicely for that.
Yet what I actually want in the final result is "those commits which
change the result of the _exported_ headers". It's slightly less
realistic to want rev-list to find that for me directly from the
original kernel tree without having done the export step in stage1 --
what I need to do is create the exported header tree for each commit
which _might_ change it, then filter out the commits which don't
_actually_ change it.
The extra commits in the stage1 branch are cheap enough -- by definition
they don't lead to any extra tree or blob objects. I think the two-stage
export is probably the best approach, unless I'm missing something.
--
dwmw2
^ permalink raw reply
* Re: Kernel headers git tree
From: David Woodhouse @ 2006-07-14 10:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607132157370.5623@g5.osdl.org>
On Thu, 2006-07-13 at 22:16 -0700, Linus Torvalds wrote:
> So to give an example, let's say we have
>
> HEAD -> A
> / \
> B C
> / \ \
> D E F
> \ / / \
> G H I
> .......
>
> the difference between --topo-order and the default ordering for
>
> git rev-list HEAD
>
> is most visible for commit 'G'.
>
> For --topo-order, we guarantee that before we show 'G', we _will_ have
> shown both 'D' and 'E'. In other words, --topo-ordering guarantees that it
> shows _all_ children before it shows the parent.
Ah, OK. Then it should probably be fine. I'll talk myself through it...
We're building a parallel graph of commits, containing a _subset_ of the
commits in the master tree -- only those which touch certain files.
For each 'interesting' commit X, we create a corresponding commit X' in
the slave tree -- we create the corresponding tree object, and we also
recursively create its parent commits -- replacing each parent in the
original commit X with the slave-tree equivalent of the closest
_interesting_ ancestor commit. It's that "closest interesting ancestor"
which we're finding with the 'rev-list --max-count-1 -- myfile'
invocation.
The extract-khdrs-stage2.sh script is a simple example of this, and
differs from the other script mostly in the way that it creates the
_tree_ objects.
So working from your example above, and assuming that only commits I and
E actually change the files we care about. This means that merges A, B
and F are _also_ going to show up in the output of 'rev-list -- myfile'.
So the slave tree will look like this:
A'
/ \
B' F'
| |
E' I'
The interesting case, if I'm trying to convince myself that my 'slave'
tree is always going to have the correct topology, is when a merge
commit is _missing_ from the rev-list output -- for example, if commits
D and E in your original tree both make the _same_ change, then I
believe that the merge commit B will no longer show up, because 'myfile'
is identical in B and in both of its parents.
In that case, we accept that the representation isn't going to be
perfect -- the left-hand parent of A' is going to appear to be _either_
D' or E', but not B'. In fact, since D' and E' are _identical_ as far as
we're concerned, it doesn't really matter which is chosen. The other one
of the two becomes an unused branch with no children -- we end up with a
graph looking like this.
A'
/ \
D' E' F'
\/ |
I'
... and the parent of D' and E' is the closest ancestor of G which
actually touches the files we care about, of course.
All we care about, in this case, is that the first commit listed by
rev-list is _either_ D or E, and not something further down the tree.
And that's obviously true from your description of the 'weak ordering',
so yes -- it does look like I can drop the '--topo-order'. Thanks.
(It would actually be quite nice if I _could_ find a cheap way to
include commit B' in that final example, but it's such a rare case and
it would be so expensive to do it that I don't think it's worth
pursuing.)
--
dwmw2
^ permalink raw reply
* [PATCH] Documentation: Fix ssh:// URLs in generated documentation
From: Alp Toker @ 2006-07-14 10:24 UTC (permalink / raw)
To: git; +Cc: junkio
In-Reply-To: <11528726881431-git-send-email-alp@atoker.com>
Commit c3f17061be95de3498449a548e93883aebff23d6 was causing warnings
during doc generation due to bad asciidoc markup.
This resulted in "ssh://[user@]host.xz/path/to/repo.git/" being rendered
as "host.xz/path/to/repo.git/" in the man pages and html output.
This patch converts sections listing URL formats to verbatim.
Signed-off-by: Alp Toker <alp@atoker.com>
---
Documentation/urls.txt | 30 ++++++++++++------------------
1 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 9abec80..a071915 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -4,33 +4,27 @@ GIT URLS[[URLS]]
One of the following notations can be used
to name the remote repository:
-===============================================================
-- rsync://host.xz/path/to/repo.git/
-- http://host.xz/path/to/repo.git/
-- https://host.xz/path/to/repo.git/
-- git://host.xz/path/to/repo.git/
-- git://host.xz/~user/path/to/repo.git/
-- ssh://[user@]host.xz/path/to/repo.git/
-- ssh://[user@]host.xz/~user/path/to/repo.git/
-- ssh://[user@]host.xz/~/path/to/repo.git
-===============================================================
+ rsync://host.xz/path/to/repo.git/
+ http://host.xz/path/to/repo.git/
+ https://host.xz/path/to/repo.git/
+ git://host.xz/path/to/repo.git/
+ git://host.xz/~user/path/to/repo.git/
+ ssh://[user@]host.xz/path/to/repo.git/
+ ssh://[user@]host.xz/~user/path/to/repo.git/
+ ssh://[user@]host.xz/~/path/to/repo.git
SSH Is the default transport protocol and also supports an
scp-like syntax. Both syntaxes support username expansion,
as does the native git protocol. The following three are
identical to the last three above, respectively:
-===============================================================
-- host.xz:/path/to/repo.git/
-- host.xz:~user/path/to/repo.git/
-- host.xz:path/to/repo.git
-===============================================================
+ host.xz:/path/to/repo.git/
+ host.xz:~user/path/to/repo.git/
+ host.xz:path/to/repo.git
To sync with a local directory, use:
-===============================================================
-- /path/to/repo.git/
-===============================================================
+ /path/to/repo.git/
REMOTES
-------
--
1.4.1.g28ec
^ permalink raw reply related
* [PATCH] Documentation: Minor capitalization typofix
From: Alp Toker @ 2006-07-14 10:24 UTC (permalink / raw)
To: git; +Cc: junkio
In-Reply-To: <1152872688966-git-send-email-alp@atoker.com>
This ended up appearing in several man pages by inclusion.
Signed-off-by: Alp Toker <alp@atoker.com>
---
Documentation/urls.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index a071915..2b5a7f8 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -13,7 +13,7 @@ to name the remote repository:
ssh://[user@]host.xz/~user/path/to/repo.git/
ssh://[user@]host.xz/~/path/to/repo.git
-SSH Is the default transport protocol and also supports an
+SSH is the default transport protocol and also supports an
scp-like syntax. Both syntaxes support username expansion,
as does the native git protocol. The following three are
identical to the last three above, respectively:
--
1.4.1.g28ec
^ permalink raw reply related
* [PATCH] Revert "Documentation: Fix ssh://[user@]host.xz URL"
From: Alp Toker @ 2006-07-14 10:24 UTC (permalink / raw)
To: git; +Cc: junkio
This reverts commit 8d5e26848d0ddd5063f078b0c34c6c48b68d0d94.
The patch did not eliminate warnings caused by bad asciidoc markup.
Nor did it correct the generated output, which remains unchanged.
Signed-off-by: Alp Toker <alp@atoker.com>
---
Documentation/urls.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 93378d2..9abec80 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -10,9 +10,9 @@ to name the remote repository:
- https://host.xz/path/to/repo.git/
- git://host.xz/path/to/repo.git/
- git://host.xz/~user/path/to/repo.git/
-- ssh://+++[user@+++]host.xz/path/to/repo.git/
-- ssh://+++[user@+++]host.xz/~user/path/to/repo.git/
-- ssh://+++[user@+++]host.xz/~/path/to/repo.git
+- ssh://[user@]host.xz/path/to/repo.git/
+- ssh://[user@]host.xz/~user/path/to/repo.git/
+- ssh://[user@]host.xz/~/path/to/repo.git
===============================================================
SSH Is the default transport protocol and also supports an
--
1.4.1.g28ec
^ 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