* Re: [PATCH] urls.txt: Use substitution to escape square brackets
From: Alp Toker @ 2006-07-15 0:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonas Fonseca
In-Reply-To: <7v3bd3ois4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Alp is right -- the comments in [attributes] section after the
> definition do appear in the output, even with asciidoc 7.1.2, so
> here is a replacement proposal from me.
>
> The one by Alp is an easy work-around, but I do not want to
> worry about potential, unintended, breakages that might be
> caused by changing delimited blocks to literal paragraphs (and
> it changes the resulting rendering from the original).
>
> -- >8 --
> From: Jonas Fonseca <fonseca@diku.dk>
>
> This changes "[user@]" to use {startsb} and {endsb} to insert [ and ],
> similar to how {caret} is used in git-rev-parse.txt.
>
> [jc: Removed a well-intentioned comment that broke the final
> formatting from the original patch. While we are at it,
> updated the paragraph that claims to be equivalent to the
> section that was updated earlier without making matching
> changes.]
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Alp Toker <alp@atoker.com>
^ permalink raw reply
* Re: [PATCH] urls.txt: Use substitution to escape square brackets
From: Alp Toker @ 2006-07-14 23:57 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7v8xmvok49.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Alp Toker <alp@atoker.com> writes:
>
>> Junio C Hamano wrote:
>>> Looks nicer. Alp? Does this work with your version of
>>> asciidoc?
>> I'm using asciidoc 7.0.2, which came with Ubuntu Dapper.
>>
>> The man page output now looks like this:
>>
>> · 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
>
> I got a bit inventive and removed the comments after #, which
> were in Jonas's version, when I tried it out. Maybe doing the
> same might help you, since I suspect the above '#' are coming
> from the comment part.
No. Removing the comments doesn't help -- the output remains broken.
>> Out of the three patches,
>>
>> (at) "ssh://[user@]host.xz/path/to/repo.git/"
>> (jc) "ssh://+++[user@+++]host.xz/path/to/repo.git/"
>> (jf) "ssh://{startsb}user@{endsb}host.xz/path/to/repo.git/"
>>
>> I'd say (at) is still most readable, not requiring +++ markup (jc) or
>> hacks to asciidoc.conf (jf).
>
> I do not think defining [attribute] is a hack; it is a
> documented feature.
"You write an AsciiDoc document the same way you would write a normal
text document, there are no markup tags or weird format notations."
asciidoc solves this problem by design and without markup, with the
prescribed syntax being to indent and quote the text verbatim, just as
it was meant to be read.
Why try to fit a square peg in a round hole by defining attributes? It's
a good indicator that there's a hack going down when three competent
programmers can't escape a square bracket after three attempts spanning
two days ;-)
^ permalink raw reply
* [PATCH] urls.txt: Use substitution to escape square brackets
From: Junio C Hamano @ 2006-07-14 23:42 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git, Alp Toker
In-Reply-To: <20060714215039.GA21994@diku.dk>
Alp is right -- the comments in [attributes] section after the
definition do appear in the output, even with asciidoc 7.1.2, so
here is a replacement proposal from me.
The one by Alp is an easy work-around, but I do not want to
worry about potential, unintended, breakages that might be
caused by changing delimited blocks to literal paragraphs (and
it changes the resulting rendering from the original).
-- >8 --
From: Jonas Fonseca <fonseca@diku.dk>
This changes "[user@]" to use {startsb} and {endsb} to insert [ and ],
similar to how {caret} is used in git-rev-parse.txt.
[jc: Removed a well-intentioned comment that broke the final
formatting from the original patch. While we are at it,
updated the paragraph that claims to be equivalent to the
section that was updated earlier without making matching
changes.]
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/asciidoc.conf | 2 ++
Documentation/urls.txt | 17 +++++++++--------
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 7ce7151..8196d78 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -9,6 +9,8 @@ # the command.
[attributes]
caret=^
+startsb=[
+endsb=]
ifdef::backend-docbook[]
[gitlink-inlinemacro]
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 9d2ad46..26ecba5 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -10,20 +10,21 @@ 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://{startsb}user@{endsb}host.xz/path/to/repo.git/
+- ssh://{startsb}user@{endsb}host.xz/~user/path/to/repo.git/
+- ssh://{startsb}user@{endsb}host.xz/~/path/to/repo.git
===============================================================
-SSH Is the default transport protocol and also supports an
-scp-like syntax. Both syntaxes support username expansion,
+SSH is the default transport protocol. You can optionally specify
+which user to log-in as, and an alternate, scp-like syntax is also
+supported. 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
+- {startsb}user@{endsb}host.xz:/path/to/repo.git/
+- {startsb}user@{endsb}host.xz:~user/path/to/repo.git/
+- {startsb}user@{endsb}host.xz:path/to/repo.git
===============================================================
To sync with a local directory, use:
--
1.4.1.g28ec
^ permalink raw reply related
* Re: [PATCH 1/2] Avoid using the git wrapper in git-rebase.sh.
From: Shawn Pearce @ 2006-07-14 23:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsg8qhj9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> 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.
Doh. I must have missed the emails which decided that... For some
reason I remember only the emails discussing shadowing happening
but that internal stuff should use 'git-am' to prevent the shadowing
from occuring. Thanks for the correction.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] urls.txt: Use substitution to escape square brackets
From: Junio C Hamano @ 2006-07-14 23:13 UTC (permalink / raw)
To: git
In-Reply-To: <44B82243.20604@atoker.com>
Alp Toker <alp@atoker.com> writes:
> Junio C Hamano wrote:
>>
>> Looks nicer. Alp? Does this work with your version of
>> asciidoc?
>
> I'm using asciidoc 7.0.2, which came with Ubuntu Dapper.
>
> The man page output now looks like this:
>
> · 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
I got a bit inventive and removed the comments after #, which
were in Jonas's version, when I tried it out. Maybe doing the
same might help you, since I suspect the above '#' are coming
from the comment part.
> Out of the three patches,
>
> (at) "ssh://[user@]host.xz/path/to/repo.git/"
> (jc) "ssh://+++[user@+++]host.xz/path/to/repo.git/"
> (jf) "ssh://{startsb}user@{endsb}host.xz/path/to/repo.git/"
>
> I'd say (at) is still most readable, not requiring +++ markup (jc) or
> hacks to asciidoc.conf (jf).
I do not think defining [attribute] is a hack; it is a
documented feature.
^ permalink raw reply
* Re: [PATCH] urls.txt: Use substitution to escape square brackets
From: Alp Toker @ 2006-07-14 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyh3on6w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jonas Fonseca <fonseca@diku.dk> writes:
>
>> This changes "[user@]" to use {startsb} and {endsb} to insert [ and ],
>> similar to how {caret} is used in git-rev-parse.txt.
>>
>> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>
> Looks nicer. Alp? Does this work with your version of
> asciidoc?
I'm using asciidoc 7.0.2, which came with Ubuntu Dapper.
The man page output now looks like this:
· 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
Still not correct.
Out of the three patches,
(at) "ssh://[user@]host.xz/path/to/repo.git/"
(jc) "ssh://+++[user@+++]host.xz/path/to/repo.git/"
(jf) "ssh://{startsb}user@{endsb}host.xz/path/to/repo.git/"
I'd say (at) is still most readable, not requiring +++ markup (jc) or
hacks to asciidoc.conf (jf). And it's the only fix that's compatible
with older versions.
That's unless I've missed out on some detail that makes (at) unworkable.
If it's the dozen or so modified lines that are a problem, we can work
on a wdiff merge strategy or something in the time we save looking for
the asciidoc escape sequence that works for everyone. Junio?
^ permalink raw reply
* Re: [PATCH] urls.txt: Use substitution to escape square brackets
From: Junio C Hamano @ 2006-07-14 22:07 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Alp Toker, git, junkio
In-Reply-To: <20060714215039.GA21994@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> This changes "[user@]" to use {startsb} and {endsb} to insert [ and ],
> similar to how {caret} is used in git-rev-parse.txt.
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Looks nicer. Alp? Does this work with your version of
asciidoc?
^ permalink raw reply
* [PATCH] urls.txt: Use substitution to escape square brackets
From: Jonas Fonseca @ 2006-07-14 21:50 UTC (permalink / raw)
To: Alp Toker; +Cc: git, junkio
In-Reply-To: <11528726881431-git-send-email-alp@atoker.com>
This changes "[user@]" to use {startsb} and {endsb} to insert [ and ],
similar to how {caret} is used in git-rev-parse.txt.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Alternate "fix".
---
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 7ce7151..41754d5 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -9,6 +9,8 @@ # the command.
[attributes]
caret=^
+startsb=[ # [
+endsb=] # ]
ifdef::backend-docbook[]
[gitlink-inlinemacro]
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 93378d2..2950ac9 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://{startsb}user@{endsb}host.xz/path/to/repo.git/
+- ssh://{startsb}user@{endsb}host.xz/~user/path/to/repo.git/
+- ssh://{startsb}user@{endsb}host.xz/~/path/to/repo.git
===============================================================
SSH Is the default transport protocol and also supports an
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] Documentation: Fix ssh:// URLs in generated documentation
From: Junio C Hamano @ 2006-07-14 21:46 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <1152872688966-git-send-email-alp@atoker.com>
Alp Toker <alp@atoker.com> writes:
> Commit c3f17061be95de3498449a548e93883aebff23d6 was causing warnings
> during doc generation due to bad asciidoc markup.
It seems that the '+++' quoting does not seem to work with older asciidoc.
However, I just noticed that what the text talks about is wrong
to begin with (not your fault):
> + 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
So how about something like this instead, until people have up
to date asciidoc?
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 93378d2..a5519e5 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -10,12 +10,12 @@ 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://host.xz/path/to/repo.git/
+- ssh://host.xz/~user/path/to/repo.git/
+- ssh://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:
@@ -26,6 +26,10 @@ identical to the last three above, respe
- host.xz:path/to/repo.git
===============================================================
+In addition, you can specify the name of the user to log in as
+by saying `ssh://user@host.xz/\...` and `user@host.xz:\...` for
+the SSH protocol.
+
To sync with a local directory, use:
===============================================================
^ permalink raw reply related
* Re: [PATCH 1/3] git-format-patch: Make the second and subsequent mails replies to the first
From: Junio C Hamano @ 2006-07-14 19:32 UTC (permalink / raw)
To: Josh Triplett; +Cc: git
In-Reply-To: <1152904829.5177.19.camel@josh-work.beaverton.ibm.com>
Josh Triplett <josht@us.ibm.com> writes:
> ..., but you
> suggested that you didn't mind having threading as the default.
Did I? ... then that was either a mistake or miscommunication.
I do mind changing the default output. I do not mind threading
as the default ONLY IF user asks for output with these extra
headers.
^ permalink raw reply
* Re: [PATCH 1/3] git-format-patch: Make the second and subsequent mails replies to the first
From: Josh Triplett @ 2006-07-14 19:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pxkoxjp.fsf@assigned-by-dhcp.cox.net>
On Fri, 2006-07-14 at 11:23 -0700, Junio C Hamano wrote:
> Josh Triplett <josht@us.ibm.com> writes:
>
> >> 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?
>
> Eh, that's not what I meant.
>
> I do not mind the code you added to log-tree.c and revision.h,
> and honestly I do not care which of threading or non-threading
> mode is the default, although I think your explanation that it
> parallels what send-email does makes a lot of sense.
>
> But I do mind that the code added by the first patch to
> cmd_format_patch runs by default, and worse yet, there is no
> option turn it off. Setting message_id and ref_message_id in
> rev_info struct should be something the end user should ask for
> explicitly by invoking the command with an option, perhaps
> --with-message-id, which you probably would also want to turn on
> when any of --no-thread, --thread or --initial-reply-to options
> are given.
How would that work though? Threading requires a Message-Id on at least
the first message, so to avoid Message-IDs by default would require
turning off threading by default; I can do that if you like, but you
suggested that you didn't mind having threading as the default. I
could, however, avoid generating Message-Id on the subsequent messages,
and avoid generating that Message-Id if you give --no-thread. Would
that work?
- Josh Triplett
^ permalink raw reply
* Re: German documentation for git, cogito, gitweb
From: Christopher Faylor @ 2006-07-14 18:52 UTC (permalink / raw)
To: Git ML
In-Reply-To: <81b0412b0607140631w2ab8f69cm4c83980fcc93d7d7@mail.gmail.com>
On Fri, Jul 14, 2006 at 03:31:41PM +0200, Alex Riesen wrote:
>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.
Someone proposed git as a cygwin package last year but they went radio
silent shortly thereafter.
A git package would pretty much be automatically accepted for inclusion
in cygwin if someone wanted to propose one. Details (such as they are)
for doing generating a package and proposing it for inclusion are at the
Cygwin web site:
http://cygwin.com/setup.html
cgf
^ permalink raw reply
* Re: [PATCH 1/3] git-format-patch: Make the second and subsequent mails replies to the first
From: Junio C Hamano @ 2006-07-14 18:23 UTC (permalink / raw)
To: Josh Triplett; +Cc: git
In-Reply-To: <1152897407.5177.8.camel@josh-work.beaverton.ibm.com>
Josh Triplett <josht@us.ibm.com> writes:
>> 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?
Eh, that's not what I meant.
I do not mind the code you added to log-tree.c and revision.h,
and honestly I do not care which of threading or non-threading
mode is the default, although I think your explanation that it
parallels what send-email does makes a lot of sense.
But I do mind that the code added by the first patch to
cmd_format_patch runs by default, and worse yet, there is no
option turn it off. Setting message_id and ref_message_id in
rev_info struct should be something the end user should ask for
explicitly by invoking the command with an option, perhaps
--with-message-id, which you probably would also want to turn on
when any of --no-thread, --thread or --initial-reply-to options
are given.
-
^ permalink raw reply
* Re: Kernel headers git tree
From: David Woodhouse @ 2006-07-14 18:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64i0qd4d.fsf@assigned-by-dhcp.cox.net>
On Fri, 2006-07-14 at 11:01 -0700, Junio C Hamano wrote:
> David Woodhouse <dwmw2@infradead.org> writes:
>
> > 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.
>
> Since you are not building an exact parallel history with the
> same topology (you are trying to cull the commits in the new
> tree that do not change the resulting header files), I do not
> see much point in the parent conversion loop in the first script
> to compute CONVERTEDPARENTS.
>
> How about making it simpler?
>
> * Keep the current HEAD of the "headers" branch at in
> refs/heads/kernel-headers
>
> * Whenever you see $UPSTREAM_GITDIR/refs/heads/master
> changes, you do your converttree to come up with the
> new header tree
>
> * See if the resulting tree changed by doing something
> like this:
>
> TREE=`converttree $INCDIR $KBUILDASMSHA`
> case "`git diff-tree --name-only kernel-headers $TREE`" in
> '')
> # No changes in the result
> exit
> esac
>
> Stop processing here if there is no change.
>
> * Make a new commit, with its parent set to the current
> value of refs/heads/kernel-headers, perhaps with the
> same message as $UPSTREAM_GITDIR/refs/heads/master
> has as you do already.
>
> * Advance refs/heads/kernel-headers only when you
> actually make a new commit.
Unless I'm misunderstanding, I then don't get a tree with a topology
which matches Linus' tree -- I just get a series of snapshots, and it's
dependent on the timing of my cron jobs.
That means that there isn't a 1:1 relationship between any commit in the
slave tree and a corresponding commit in the upstream tree, and that the
slave tree can't (sensibly) be reproduced.
I'd much rather keep it the way it is -- but I'm certainly interested in
ways that I could simplify the process of generating what I have at the
moment.
> I would further suggest to record the value of the upstream
> commit object name, $UPSTREAM_GITDIR/refs/heads/master,
> somewhere in the commit message, by using "git describe". This
> will help people who use your converted headers to know which
> released version of the Linus kernel the headers correspond to,
> and also help you notice when the upstream is updated during the
> next run.
Yeah, that was already suggested. I'll do that.
--
dwmw2
^ permalink raw reply
* Re: Kernel headers git tree
From: Daniel Barkalow @ 2006-07-14 18:21 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <1152899889.3191.71.camel@pmac.infradead.org>
On Fri, 14 Jul 2006, David Woodhouse wrote:
> 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.
I think the mechanism you're using is fine, but it's also generally
useful, and it would be nice to have the generic part split out from the
particular application. Also, those scripts really are as evil as
advertized, and using more of the git programs would make that a lot
saner.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Kernel headers git tree
From: David Woodhouse @ 2006-07-14 18:16 UTC (permalink / raw)
To: Ingo Oeser; +Cc: linux-kernel, git
In-Reply-To: <200607142005.36998.ioe-lkml@rameria.de>
On Fri, 2006-07-14 at 20:05 +0200, Ingo Oeser wrote:
> Hi David,
>
> On Friday, 14. July 2006 01:59, David Woodhouse wrote:
> > 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.
>
> Where can I subscribe for commit messages there?
Well, they're all derived from commits in Linus' tree. I could set up
another mailing list feed script which tracks it, but I'd like to give
it a while (until I'm happy with the export scripts) first.
--
dwmw2
^ permalink raw reply
* Re: Kernel headers git tree
From: Ingo Oeser @ 2006-07-14 18:05 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-kernel, git
In-Reply-To: <1152835150.31372.23.camel@shinybook.infradead.org>
Hi David,
On Friday, 14. July 2006 01:59, David Woodhouse wrote:
> 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.
Where can I subscribe for commit messages there?
Every serious systems programmer (for Linux) will ask this question soon :-)
Maybe one of the Postmasters at vger.kernel.org can setup
a mailing list for this.
Regards
Ingo Oeser, happy to see this project finally there
^ permalink raw reply
* Re: Kernel headers git tree
From: Junio C Hamano @ 2006-07-14 18:01 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1152869915.3191.12.camel@pmac.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> 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.
Since you are not building an exact parallel history with the
same topology (you are trying to cull the commits in the new
tree that do not change the resulting header files), I do not
see much point in the parent conversion loop in the first script
to compute CONVERTEDPARENTS.
How about making it simpler?
* Keep the current HEAD of the "headers" branch at in
refs/heads/kernel-headers
* Whenever you see $UPSTREAM_GITDIR/refs/heads/master
changes, you do your converttree to come up with the
new header tree
* See if the resulting tree changed by doing something
like this:
TREE=`converttree $INCDIR $KBUILDASMSHA`
case "`git diff-tree --name-only kernel-headers $TREE`" in
'')
# No changes in the result
exit
esac
Stop processing here if there is no change.
* Make a new commit, with its parent set to the current
value of refs/heads/kernel-headers, perhaps with the
same message as $UPSTREAM_GITDIR/refs/heads/master
has as you do already.
* Advance refs/heads/kernel-headers only when you
actually make a new commit.
I would further suggest to record the value of the upstream
commit object name, $UPSTREAM_GITDIR/refs/heads/master,
somewhere in the commit message, by using "git describe". This
will help people who use your converted headers to know which
released version of the Linus kernel the headers correspond to,
and also help you notice when the upstream is updated during the
next run.
^ 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
* 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: [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
* [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/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
* 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: 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
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