* 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
* Re: [RFC/PATCH] date parsing: be friendlier to our European friends.
From: David Woodhouse @ 2006-07-14 10:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd57zl9x.fsf@assigned-by-dhcp.cox.net>
On Wed, 2006-04-05 at 15:54 -0700, Junio C Hamano wrote:
> Before the list gets useless comments, the code prefer to accept
> more sensible and/or unambiguous forms, such as ISO or RFC2822.
> The issue this addresses is what to do when we get other forms.
Rejecting them and demanding unambiguous forms is better than silently
getting it wrong.
--
dwmw2
^ permalink raw reply
* German documentation for git, cogito, gitweb
From: Nico -telmich- Schottelius @ 2006-07-14 11:53 UTC (permalink / raw)
To: Git ML
[-- Attachment #1: Type: text/plain, Size: 668 bytes --]
Hello guys!
Under http://nico.schotteli.us/papers/linux/git-firmen/ you can
find some German documentation about those three nice
tools.
It is a little bit orientated on using git in companies and
starts up from installing it.
If you find error, spelling mistakes, ... whatever in them,
please send diff -u to me.
And yes, the document is also under git control:
http://unix.schottelius.org/cgi-bin/gitweb.cgi?p=documentations;a=summary
http://unix.schottelius.org/git/documentations/
Sincerly
Nico
--
Latest release: ccollect-0.4.2 (http://unix.schottelius.org/ccollect/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: German documentation for git, cogito, gitweb
From: Alex Riesen @ 2006-07-14 13:31 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: Git ML
In-Reply-To: <20060714115325.GA5919@schottelius.org>
I found the file under gitweb urls.
On 7/14/06, Nico -telmich- Schottelius <nico-linux-git@schottelius.org> wrote:
> If you find error, spelling mistakes, ... whatever in them,
> please send diff -u to me.
It's very linux centered, but the sad fact of life is the windows domination
in corporate networks. And while I firmly believe that windows will die, it
hasn't quite happened yet, and a short notice about cygwin version (and
how the installation there is done) would be useful. I actually am a bit
surprised git didn't made it into cygwin distribution yet.
The file does not mention gitk nor qgit, nor other visualisation tools. Pity.
^ permalink raw reply
* git 1.2.4 and linux-2.6 tree problem
From: Mariusz Kozlowski @ 2006-07-14 14:20 UTC (permalink / raw)
To: git
Hello,
I get repeatable errors when I follow steps from "Kernel Hackers' Guide to
git" (http://linux.yyz.us/git-howto.html). The thing is when I try to pull
Linus tree with:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
linux-2.6
After downloading approx. 60MB I get these errors:
fatal: packfile '/home/me/linux/linux-2.6/.git/objects/pack/tmp-lfnDg8' SHA1
mismatch
error: git-clone-pack: unable to read from git-index-pack
error: git-index-pack died with error code 128
clone-pack from
'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git'
failed.
The git version is 1.2.4 (marked as stable in gentoo). Any ideas?
Regards,
Mariusz
^ permalink raw reply
* [PATCH] Fix "git-fetch --tags" exit status when nothing has been changed
From: Sergey Vlasov @ 2006-07-14 15:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sergey Vlasov
After commit 55b7835e1b81a6debc7648149d2b8a4c5c64ddba git-fetch --tags
exits with status 1 when no tags have been changed, which breaks calling
git-fetch from scripts.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
git-fetch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index ff17699..ee99280 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -153,7 +153,7 @@ fast_forward_local () {
then
if now_=$(cat "$GIT_DIR/$1") && test "$now_" = "$2"
then
- [ "$verbose" ] && echo >&2 "* $1: same as $3"
+ [ "$verbose" ] && echo >&2 "* $1: same as $3" ||:
else
echo >&2 "* $1: updating with $3"
git-update-ref -m "$rloga: updating tag" "$1" "$2"
--
1.4.1.ga319
^ permalink raw reply related
* Re: German documentation for git, cogito, gitweb
From: Jakub Narebski @ 2006-07-14 15:13 UTC (permalink / raw)
To: git
In-Reply-To: <20060714115325.GA5919@schottelius.org>
Thanks.
Added to http://git.or.cz/gitwiki/GitLinks
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Kernel headers git tree
From: Linus Torvalds @ 2006-07-14 15:39 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, git
In-Reply-To: <1152869915.3191.12.camel@pmac.infradead.org>
On Fri, 14 Jul 2006, David Woodhouse wrote:
> 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...
Yes, I'm looking at "get_pathspec()", and noting that it really isn't able
to optimize away the ".".
It does turn it into an empty string (which is correct - git internally
does _not_ ever understand the notion of "." as the current working
directory), but it doesn't ever do the optimization of noticing that a
pathspec that consists solely of an empty string is "equivalent" to an
empty pathspec.
Which is exactly what you _want_ in this case, of course, but maybe we
should add a test-case for that, so that we never do that trivial
optimization by mistake.
Maybe something like
git init-db
echo Hello > a
git add a
git commit -m "Initial commit" a
and then:
commit=$(echo "Unchanged tree" | git-commit-tree "HEAD^{tree}" -p HEAD)
git-rev-list $commit | wc -l
git-rev-list $commit -- . | wc -l
where the first git-rev-list should return 2, and the second one should
return 1.
Anybody want to write that as a test, verify it, and send Junio a patch?
Linus
^ permalink raw reply
* [PATCH] daemon: documentation for --reuseaddr, --detach and --pid-file
From: Matthias Lederhofer @ 2006-07-14 15:53 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <E1G0zj7-0001c1-8q@moooo.ath.cx>
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
Matthias Lederhofer <matled@gmx.net> wrote:
> Documentation will follow if the changes are ok.
Here it is. I just found that --reuseaddr is not documented yet too
(I could really have used that while testing the git-daemon
patches...) but I have no idea how to describe it for someone who
does not know what it means. Perhaps someone else has an idea.
---
Documentation/git-daemon.txt | 8 +++++++-
daemon.c | 2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 4c357da..f5b08a6 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git-daemon' [--verbose] [--syslog] [--inetd | --port=n] [--export-all]
[--timeout=n] [--init-timeout=n] [--strict-paths]
[--base-path=path] [--user-path | --user-path=path]
- [directory...]
+ [--reuseaddr] [--detach] [--pid-file=file] [directory...]
DESCRIPTION
-----------
@@ -82,6 +82,12 @@ OPTIONS
--verbose::
Log details about the incoming connections and requested files.
+--detach::
+ Detach from the shell. Implies --syslog.
+
+--pid-file=file::
+ Save the process id in 'file'.
+
<directory>::
A directory to add to the whitelist of allowed directories. Unless
--strict-paths is specified this will also include subdirectories
diff --git a/daemon.c b/daemon.c
index e4ec676..810837f 100644
--- a/daemon.c
+++ b/daemon.c
@@ -19,7 +19,7 @@ static const char daemon_usage[] =
"git-daemon [--verbose] [--syslog] [--inetd | --port=n] [--export-all]\n"
" [--timeout=n] [--init-timeout=n] [--strict-paths]\n"
" [--base-path=path] [--user-path | --user-path=path]\n"
-" [--reuseaddr] [directory...]";
+" [--reuseaddr] [--detach] [--pid-file=file] [directory...]";
/* List of acceptable pathname prefixes */
static char **ok_paths = NULL;
--
1.4.1.g8b4b
^ permalink raw reply related
* Re: Kernel headers git tree
From: Linus Torvalds @ 2006-07-14 15:57 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, git
In-Reply-To: <1152872626.3191.56.camel@pmac.infradead.org>
On Fri, 14 Jul 2006, David Woodhouse wrote:
> On Thu, 2006-07-13 at 22:16 -0700, Linus Torvalds wrote:
> >
> > HEAD -> A
> > / \
> > B C
> > / \ \
> > D E F
> > \ / / \
> > G H I
> > .......
> >
>
> 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'.
Not necessarily.
> So the slave tree will look like this:
>
> A'
> / \
> B' F'
> | |
> E' I'
Yes, but ONLY IF the following is true: A is different from _both_ F and B
in the relevant files.
If A == F (in those files), then the A merge will have been simplified
away. Strictly speaking, what happens is that when it sees the merge A
(which has parents B and C), and sees that _all_ the changes came from C,
the simplification will decide that B simply isn't even interesting, and
rewrite the merge A as having _only_ C as a parent, since C clearly
explains everything that happened to those files, and B had nothing to do
with it.
It will then remove both A (which is no longer a merge) and C, since
neither of them change the files, and will leave you with just
F'
|
I'
instead.
> 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
Note that there are only two ways you can be missing a merge:
- you literally asked for it with "--no-merges"
- the merge had one parent that was identical to it, and the merge was
simplified as above.
> 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'
You will never see this, because D' is simply not reachable. You can have
either:
- A got simplified away as a merge entirely, because C was identical, and
B was thus considered "uninteresting" (as in "it not matter for the
end result"), and then the later phase will always remove A too (since,
by definition, for the merge to be simplified to a non-merge, it must
be identical to the parent it was simplified to have)
- or _both_ B and C were different to A in those files, and A still
exists as a merge, but B was identical to one of its parents (let's say
E), and was first simplified to "B->E->G", and then because B and E
were identical, B itself was dropped, and only
A'
/ \
E' F'
| |
G' I'
remains.
NOTE NOTE NOTE! This is how "git rev-list" (and all the other related git
tools, like "git log" etc) simplify the tree. It is, in my opinion, the
only sane way to do it, although you can pass in "--full-history" to say
that you don't want any merge simplification at all.
The reason I mention it is that _your_ simplifications may obviously do
something else entirely, and you may obviously have different rules for
how you simplify the tree further. But it sounds like you don't simplify
the history at all (apart from the simplification that git-rev-list did
for you)?
Linus
^ permalink raw reply
* Re: git 1.2.4 and linux-2.6 tree problem
From: Mariusz Kozlowski @ 2006-07-14 15:58 UTC (permalink / raw)
To: git
In-Reply-To: <200607141620.05350.m.kozlowski@tuxland.pl>
Hello again,
> The thing is when I try to pull
'clone'
> After downloading approx. 60MB I get these errors:
The same happens with git version 1.4.1:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
Generating pack...
Done counting 293611 objects.
Deltifying 293611 objects.
100% (293611/293611) done
fatal: unexpected EOF)
fatal: packfile '/home/me/linux/linux-2.6/.git/objects/pack/tmp-FtdxDS' SHA1 mismatch
error: git-fetch-pack: unable to read from git-index-pack
error: git-index-pack died with error code 128
fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed.
Hope that helps.
Regards,
Mariusz
^ permalink raw reply
* Re: [PATCH 1/2] Avoid using the git wrapper in git-rebase.sh.
From: Matthias Lederhofer @ 2006-07-14 16:10 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060714044655.GA1982@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> 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.
How did you alias an existing command so that the alias gets executed?
That is what I get:
% git repo-config alias.am ls-tree
% GIT_TRACE=1 git am
trace: exec: '/home/matled/local/stow/git/bin/git-am'
^ permalink raw reply
* Re: [PATCH 1/2] Avoid using the git wrapper in git-rebase.sh.
From: Junio C Hamano @ 2006-07-14 16:26 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060714044655.GA1982@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> 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.
In order to avoid confusion, we made aliases not to shadow real
commands, so this is not an argument to support this patch.
On distros that package git with gitexecdir set to somewhere not
on normal user $PATH, users are expected to use "git" wrapper to
invoke any commands (including git-rebase, so the user would say
"git rebase"), and "git" wrapper sets up the PATH to contain the
gitexecdir while it runs the subcommands, so spelling them
either way, be it "git am" or "git-am", is just fine.
>
> 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)
^ permalink raw reply
* [PATCH] argv created by handle_alias should be NULL terminated
From: Matthias Lederhofer @ 2006-07-14 16:37 UTC (permalink / raw)
To: git
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
Example:
% git repo-config alias.test am
% git test
error: cannot open mbox JÜ·JÜ·JÜ·JÜ· JÜ· JÜ·(JÜ·(JÜ [..]
---
git.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/git.c b/git.c
index 102735a..ee5a0e8 100644
--- a/git.c
+++ b/git.c
@@ -133,13 +133,12 @@ static int handle_alias(int *argcp, cons
fflush(stderr);
}
+ new_argv = realloc(new_argv, sizeof(char*) *
+ (count + *argcp + 1));
/* insert after command name */
- if (*argcp > 1) {
- new_argv = realloc(new_argv, sizeof(char*) *
- (count + *argcp));
- memcpy(new_argv + count, *argv + 1,
- sizeof(char*) * *argcp);
- }
+ memcpy(new_argv + count, *argv + 1,
+ sizeof(char*) * *argcp);
+ new_argv[count+*argcp] = NULL;
*argv = new_argv;
*argcp += count - 1;
--
1.4.1.g8b4b
^ permalink raw reply related
* Re: [PATCH 1/3] git-format-patch: Make the second and subsequent mails replies to the first
From: Josh Triplett @ 2006-07-14 17:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtal9lu1.fsf@assigned-by-dhcp.cox.net>
On Mon, 2006-07-10 at 14:44 -0700, Junio C Hamano wrote:
> Josh Triplett <josht@us.ibm.com> writes:
>
> > Add message_id and ref_message_id fields to struct rev_info, used in show_log
> > with CMIT_FMT_EMAIL to set Message-Id and In-Reply-To/References respectively.
> > Use these in git-format-patch to make the second and subsequent patch mails
> > replies to the first patch mail.
> >
> > Signed-off-by: Josh Triplett <josh@freedesktop.org>
> > ---
> > Resend of previous patch as part of new patch series.
>
> While I understand what you said about imap-send, I really would
> feel better if this was optional. Do not change the default
> output format, please.
So rather than the --no-thread option provided in the second patch of
this series, you'd prefer a --thread option to enable setting the
In-Reply-To/References headers?
Note that I based the direction of the --no-thread switch on
git-send-email's inclusion of these headers by default with no way to
turn them off, figuring that having an option to do so gave it an
advantage over git-send-email while remaining consistent with it. I
also figured that most people would not mess with the defaults, and thus
the default should make a patch series more readable on mailing lists.
- Josh Triplett
^ permalink raw reply
* Re: Kernel headers git tree
From: Daniel Barkalow @ 2006-07-14 17:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Woodhouse, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607140843570.5623@g5.osdl.org>
On Fri, 14 Jul 2006, Linus Torvalds wrote:
> On Fri, 14 Jul 2006, David Woodhouse wrote:
>
> > On Thu, 2006-07-13 at 22:16 -0700, Linus Torvalds wrote:
> > >
> > > HEAD -> A
> > > / \
> > > B C
> > > / \ \
> > > D E F
> > > \ / / \
> > > G H I
> > > .......
> > >
> >
> > 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'.
>
> Not necessarily.
>
> > So the slave tree will look like this:
> >
> > A'
> > / \
> > B' F'
> > | |
> > E' I'
>
> Yes, but ONLY IF the following is true: A is different from _both_ F and B
> in the relevant files.
Actually, this is an unlikely result, because B' and F' wouldn't appear
unless they either have multiple children that appear or they have new
modifications made to the files during the merge.
The result under the conditions that the only changes are in E and I is:
A'
/ \
E' I'
Which, of course, is what you should expect: it only includes E, I, and
merges which create a novel combination of changes (even if the changes
they include have appeared alone before).
> NOTE NOTE NOTE! This is how "git rev-list" (and all the other related git
> tools, like "git log" etc) simplify the tree. It is, in my opinion, the
> only sane way to do it, although you can pass in "--full-history" to say
> that you don't want any merge simplification at all.
>
> The reason I mention it is that _your_ simplifications may obviously do
> something else entirely, and you may obviously have different rules for
> how you simplify the tree further. But it sounds like you don't simplify
> the history at all (apart from the simplification that git-rev-list did
> for you)?
It seems like we ought to be able to provide the simplification procedure
to code that's done further filtering on the set of commits somehow, or
provide a framework with a callback, but it's a non-trivial design.
I think that a program to generate a slave git tree based in some
user-modifiable way on a parent repository would be useful and
implementable. I'd thought a bunch about it a while ago, for extracting
separable parts of projects (e.g., make a kbuild project that's pulled out
of the kernel tree, but is still a regular git project to anyone who
doesn't know this). My conclusion was that you need a cache of mappings,
because otherwise you can't identify that you already have a transformed
version of a commit, because you don't know its transformed parents,
unless you've gone all the way back to the root (which doesn't have
parents). But I think a "git2git" script wouldn't be any harder than the
other import scripts, and would solve this problem nicely.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Kernel headers git tree
From: David Woodhouse @ 2006-07-14 17:58 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607141256170.9789@iabervon.org>
On Fri, 2006-07-14 at 13:51 -0400, Daniel Barkalow wrote:
> I think that a program to generate a slave git tree based in some
> user-modifiable way on a parent repository would be useful and
> implementable. I'd thought a bunch about it a while ago, for extracting
> separable parts of projects (e.g., make a kbuild project that's pulled out
> of the kernel tree, but is still a regular git project to anyone who
> doesn't know this). My conclusion was that you need a cache of mappings,
> because otherwise you can't identify that you already have a transformed
> version of a commit, because you don't know its transformed parents,
> unless you've gone all the way back to the root (which doesn't have
> parents).
Absolutely. You don't want to go all the way back to the root every time
-- it's an incremental process, and you have to cache the mappings from
objects in the 'master' tree to objects in the 'slave' tree.
My existing scripts already do that part -- I didn't think it was worth
commenting on.
http://david.woodhou.se/extract-jffs2-git.sh
http://david.woodhou.se/extract-khdrs-git.sh
http://david.woodhou.se/extract-khdrs-stage2.sh
And no, I don't do any further simplification of the graph of commits
other than what 'git-rev-list' does for me. I need to fully go over
Linus' last mail and understand it, but I think the conclusion is that
the above scripts are fine, and I can happily drop --topo-order from
them.
--
dwmw2
^ 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