* Re: [PATCH 0/4] send-email: correct various issues
From: Matthieu Moy @ 2009-04-01 8:33 UTC (permalink / raw)
To: Jay Soffian
Cc: git, Junio C Hamano, Björn Steinbrink, Uwe Kleine-König
In-Reply-To: <cover.1238516122.git.jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Junio, these are technically all independent bug fixes, but they were
> minor, so I've lumped them together. I figured you'd just add them to
> the js/send-email topic anyway. Also, I apologize for causing trouble in
> master. :-(
But I shall thank you for fixing them ;-).
> Jay Soffian (4):
> send-email: don't attempt to prompt if tty is closed
Works, I don't have garbage anymore in my logs.
> send-email: ask_default should apply to all emails, not just the
> first
Works, I get the informational message in my logs once, and all the
mails are sent successfully.
> send-email: correct two tests which were going interactive
> send-email: ensure quoted addresses are rfc2047 encoded
Didn't test these.
--
Matthieu
^ permalink raw reply
* Re: [PATCH 6/8 v2] sh-tools: add a run_merge_tool function
From: David Aguilar @ 2009-04-01 8:36 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: James Pickens, gitster, git
In-Reply-To: <200904010011.10296.markus.heidelberg@web.de>
On 0, Markus Heidelberg <markus.heidelberg@web.de> wrote:
> James Pickens, 31.03.2009:
> > On Mon, Mar 30, 2009 at 1:11 AM, David Aguilar <davvid@gmail.com> wrote:
> > > This function launches merge tools and will be used to refactor
> > > git-(diff|merge)tool.
sorry this whole series is being rewriten...
> >
> > Thanks for writing difftool; I find it quite useful. I tried it with
> > tkdiff, and noticed that it shows the 'merge preview' window even though it
> > isn't doing a merge. If a user with unstaged changes were to carelessly
> > click the 'save and exit' button, his changes could be lost. So I think
> > it's a good idea to stop the merge preview window from showing up under
> > difftool. To do that I think you just have to remove the '-o "$MERGED"'
> > option to tkdiff.
>
> This mail made me see an issue with your patch series. Sorry, I haven't
> seen this earlier, my review was just scratching the surface, I merely
> applied it and looked through it, but didn't actually test it. Lack of
> time.
>
> The invocations seem to be appropriate only for mergetool, it is just
> the invocations from the old git-mergetool.sh, not from the old
> git-difftool-helper.sh. This means, git-difftool opens 3 files instead
> of 2.
>
> I think there are preset diff tools, which opened 3 files instead of 2
> before this series (I just tested kdiff3, it opened 3 files). Seems to
> be originated from the fact, that they were initially copied from
> git-mergetool.sh.
>
> Markus
>
--
David
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Andreas Ericsson @ 2009-04-01 8:37 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Russ Dill, H.Merijn Brand, git
In-Reply-To: <49D339B2.4388.6B1DEF@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
Ulrich Windl wrote:
> On 29 Mar 2009 at 23:18, Russ Dill wrote:
>
>> On Fri, Mar 27, 2009 at 2:50 AM, Ulrich Windl
>> <ulrich.windl@rz.uni-regensburg.de> wrote:
>>> On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:
>>>
>>>> On Fri, 27 Mar 2009 08:21:36 +0100, "Ulrich Windl"
>>>> <ulrich.windl@rz.uni-regensburg.de> wrote:
>>>>
>>>>> What I'd like to see in git (My apologies if some were already discussed to
>>>>> death):
>>>>>
>>>>> 1) The ability to use the file's time at the time of add/commit instead of
>>>>> the current time, and the ability tho check outfiles with the times stored
>>>>> in the repository.
>>>>>
>>>>> 2) Keyword substitution. I know it's controverse (dealing with binary files),
>>>>> but I'd like to have some automatic version numbering keyword at least:
>>>>> Initial idea is that every commit with a change increments the number by
>>>>> one, and when merging numbers a and b, the resulting number is max(a, b) + 1.
>>>> impossible. Even with checkin- and checkout hooks, you won't get that
>>>> SCCS behaviour. They have to be better in something too :)
>>>> /me still misses that but got used to it
>>> Hi,
>>>
>>> what made me wonder is this (about item 1): I thought I've read that blobs store
>>> content and attributes, so very obviously I wondered why not store thr "right
>>> attributes" (i.e. the time of the file). My reasoning: You make some changes, then
>>> test them (which might last several hours or days). The if I'm happy I'll
>>> "commit". Naturally I want to see the time of change for each file when the change
>>> had been actually made, not when the change was committed. Likewise when checking
>>> out, I want to be able to see the time of modification, not the time of commit.
>>> I'm aware that many people don't care about such differences...
>>>
>> Ok, so if Nancy did some work on the part number form 6 months ago,
>> but it got merged into master yesterday. What date should the file
>> have? This kind of incremental version number, and trusting of file
>
> If Nancy committed it with my semantics, the file's date would be 6 months old
> before the merge. If the merge would not require any change, the file's date would
> still be six months old. If a change was required, the file's date would be the
> time of change. That sounds quite logical to me.
>
But if you built the old source before you merged but after Nancy made her
changes, make wouldn't grok that the file is actually changed. Trust me,
the current semantics are far better.
>> dates really only matters on a centralized system with a single
>> branch.
>>
>> Not only that, but modification times are much more useful with make.
>> Merging or pulling small changes into a tree shouldn't require a full
>> rebuild of the entire tree which in some cases could take hours.
>
> Git is not a build system, and I really dislike "full rebuilds", but for
> stability, before releasing anything, one should test it with a full rebuild.
I build all the time. Before and after every commit (merges are one type of
commit). I rely on file timestamps to be an accurate indicator of when the
file last changed *on my disk*.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Andreas Ericsson @ 2009-04-01 8:41 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Andreas Ericsson, git
In-Reply-To: <49D33EC0.29775.7EDC13@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
Ulrich Windl wrote:
> On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:
>
> [...]
>> 3 It's far better to set the version number in the release-process. Usually
>> this can be done automatically by one invocation of "git describe", just
>> as git.git does it.
>
> However if you put a version number into every file and THEN commit, it's somewhat
> ridiculous (I'll have to learn about "git describe"). But for configuration
> management you want to have exactly that (find exactly the file that was shipped
> (or used to build)).
>
>> We've adopted "3" full out at $dayjob. Our build-machinery gets the version
>> number from the git tag (releases can only be built from signed tags), and
>> it updates macros and whatnot used for informing the user which version he
>> or she is running. This makes a lot more sense both from a bug-reporting
>> and from a release process view than having generated version-numbers in
>
> So your "release commits" are outside GIT? (see above)
>
They aren't release commits. Just a script that creates a tarball and an RPM
(in our case).
>> files. On a side-note; When I told my co-workers I'd like us to switch to
>> git, two of them asked about autoversioning features. I said there weren't
>> any and asked them to name a single time when we've actually used them for
>> anything *at all*. In a team of eight, having been programming for three
>> years with 12 releases and about 800 bugreports + feature-requests, noone
>> could mention a single time when the autogenerated version numbers had
>> actually been used for anything.
>
> Hmm: Were they visible to customers?
>
Ofcourse they were, but they were rather useless even there, as a customer
could upgrade and the $Id$ tag still wouldn't get updated. It caused a lot
of confusion for our not-so-techsavvy users and customers.
>> Otoh, having the entire repository locally makes it painless to view the
>> commit-log for an entire project (or parts of it) and see who changed what
>> when and why, which is information that's actually *useful*.
>
> [Big meals need time to digest: Just give me more time to do so (getting into
> git). As with vi and Emacs (usualy I prefer Emacs), there will be situations when
> I won't use Git however]
>
Take all the time you need. It's a paradigm-shift, because the information you
thought you needed is made obsolete by the information you *actually* need.
Wrapping ones head around the fact that one's been wrong for several years takes
a little time ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* [PATCH] Documentation: use "spurious .sp" XSLT if DOCBOOK_SUPPRESS_SP is set
From: Chris Johnsen @ 2009-04-01 8:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Heiko Voigt, git, Chris Johnsen
In-Reply-To: <7vljql4586.fsf@gitster.siamese.dyndns.org>
With this change, the "spurious .sp" suppression XSLT code is
disabled by default. It can be enabled by defining
DOCBOOK_SUPPRESS_SP.
The "spurious .sp" XSLT fragment was used to work around a bug
first released in docbook-xsl 1.69.1. Modern versions of
docbook-xsl are negatively affected by the code (some empty lines
are omitted from manpage output; see
<http://article.gmane.org/gmane.comp.version-control.git/115302>).
The key revisions in the docbook SVN repo seem to be 5144 (before
docbook-xsl 1.69.1) and 6359 (before docbook-xsl 1.71.1).
Testing done with asciidoc 8.3.1 and docbook-xsl 1.74.0.
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
---
Here is a proof-of-concept. It is on top of next (it requires the
previous XSLT/asciidoc cleanup).
I went with a "feature knob" instead of a "version knob" since my
research in the docbook SVN repo indicates that multiple versions
are affected. Maybe the name could be better. Also I am not at
all sure that my research into past docbook-xsl releases is 100%
accurate. Anyone motivated enough to install old versions of
docbook-xsl and test with them?
The message that Peff cites
(<http://article.gmane.org/gmane.comp.version-control.git/32957>)
seems to indicate that the "spurious .sp" problem was injected
_between_ 1.69.0 and 1.69.1. So, I did some research in the
docbook SVN repo.
I grepped for ".sp" and "simpara" in
<http://docbook.svn.sourceforge.net/viewvc/docbook/trunk/xsl/manpages/block.xsl?view=log>
to find likely interesting spots (sure, not thorough, but I hoped
to get lucky). Then I slogged through the "tags" directory to
find out when in the revision stream docbook-xsl releases seemed
to have been cut.
Here are some of the "interesting" revision numbers:
5119 1.69.0
5144 .sp instead of blank line in mixed blocks
5152 1.69.1
5755 newline before .sp in verbatims (not simpara)
5985 1.70.0
6003 1.70.1
6166 suppress .sp inside {author,person}blurb
6279 1.71.0
6359 newline before .sp in simpara
6373 1.71.1
6552 1.72.0
...
7398 1.73.2
no tags for 1.74.*?
7782 move .sp to before, not after simpara text
7844 suppress .sp inside callout
? 1.74.0 {relnotes include descriptions of 7782 and 7844}
Before I got tired of digging through the SVN history, it seemed
to me that the problematic ".sp" was introduced at 5144 and
resolved at 6359. The code in Git's XSLT is very similar to that
of revision 6359, lines 81-91 (with a double newline instead of a
properly positioned ".sp" command).
So, it seems that the "spurious .sp" problem that Git's simpara
template "fixes" is not present in docbook-xsl 1.69.0, but is
present in 1.69.1, 1.70.0, 1.70.1, and 1.71.0. The "spurious .sp"
might not be present in 1.69.0 and earlier, but I would guess
that there are still line spacing issues there.
Should more of this background info be in the commit message?
Less?
---
Documentation/Makefile | 7 ++++++-
Documentation/manpage-base.xsl | 13 -------------
Documentation/manpage-suppress-sp.xsl | 21 +++++++++++++++++++++
3 files changed, 27 insertions(+), 14 deletions(-)
create mode 100644 Documentation/manpage-suppress-sp.xsl
diff --git a/Documentation/Makefile b/Documentation/Makefile
index dae3174..dba97dc 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -69,7 +69,9 @@ endif
#
# For docbook-xsl ...
# -1.68.1, set ASCIIDOC_NO_ROFF? (based on changelog from 1.73.0)
-# 1.69.0-1.71.1, no extra settings are needed?
+# 1.69.0, no extra settings are needed?
+# 1.69.1-1.71.0, set DOCBOOK_SUPPRESS_SP?
+# 1.71.1, no extra settings are needed?
# 1.72.0, set DOCBOOK_XSL_172.
# 1.73.0-, set ASCIIDOC_NO_ROFF
#
@@ -97,6 +99,9 @@ endif
ifdef MAN_BOLD_LITERAL
XMLTO_EXTRA += -m manpage-bold-literal.xsl
endif
+ifdef DOCBOOK_SUPPRESS_SP
+XMLTO_EXTRA += -m manpage-suppress-sp.xsl
+endif
#
# Please note that there is a minor bug in asciidoc.
diff --git a/Documentation/manpage-base.xsl b/Documentation/manpage-base.xsl
index 16e2e40..a264fa6 100644
--- a/Documentation/manpage-base.xsl
+++ b/Documentation/manpage-base.xsl
@@ -32,17 +32,4 @@
<xsl:text>br </xsl:text>
</xsl:template>
-<!-- attempt to work around spurious .sp at the tail of the line
- that docbook stylesheets seem to add -->
-<xsl:template match="simpara">
- <xsl:variable name="content">
- <xsl:apply-templates/>
- </xsl:variable>
- <xsl:value-of select="normalize-space($content)"/>
- <xsl:if test="not(ancestor::authorblurb) and
- not(ancestor::personblurb)">
- <xsl:text> </xsl:text>
- </xsl:if>
-</xsl:template>
-
</xsl:stylesheet>
diff --git a/Documentation/manpage-suppress-sp.xsl b/Documentation/manpage-suppress-sp.xsl
new file mode 100644
index 0000000..a63c763
--- /dev/null
+++ b/Documentation/manpage-suppress-sp.xsl
@@ -0,0 +1,21 @@
+<!-- manpage-suppress-sp.xsl:
+ special settings for manpages rendered from asciidoc+docbook
+ handles erroneous, inline .sp in manpage output of some
+ versions of docbook-xsl -->
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+ version="1.0">
+
+<!-- attempt to work around spurious .sp at the tail of the line
+ that some versions of docbook stylesheets seem to add -->
+<xsl:template match="simpara">
+ <xsl:variable name="content">
+ <xsl:apply-templates/>
+ </xsl:variable>
+ <xsl:value-of select="normalize-space($content)"/>
+ <xsl:if test="not(ancestor::authorblurb) and
+ not(ancestor::personblurb)">
+ <xsl:text> </xsl:text>
+ </xsl:if>
+</xsl:template>
+
+</xsl:stylesheet>
--
1.6.2.1.556.g581a3
^ permalink raw reply related
* Re: Implementing stat() with FindFirstFile()
From: Nazri Ramliy @ 2009-04-01 9:28 UTC (permalink / raw)
To: Magnus Bäck, git
In-Reply-To: <20090321154738.GA27249@jeeves.jpl.local>
On Sat, Mar 21, 2009 at 11:47 PM, Magnus Bäck <baeck@swipnet.se> wrote:
> Is there any reason why compat/win32.h uses GetFileAttributesEx()
> instead of FindFirstFile() to implement the stat() call on Windows?
This blog post explains checking file existence using GetFileAttributes(Ex) vs.
FindFirstFile quite nicely:
http://blogs.msdn.com/oldnewthing/archive/2007/10/23/5612082.aspx
nazri.
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-04-01 9:38 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jakub Narebski, Michael J Gruber, git
In-Reply-To: <vpq63horepl.fsf@bauges.imag.fr>
On 1 Apr 2009 at 9:54, Matthieu Moy wrote:
> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
>
> >> Not to mention that you can have multiple roots (multiple commits with
> >> no parent) in git repository; besides independent branches (like
> >> 'man', 'html' or 'todo') it is usually result of absorbing or
> >> subtree-merging other projects. In 'master' branch there are 5 roots
> >> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
> >> and subtree-merged gitk and git-gui. And here you would again have
> >> multiple commits with the same number...
> >
> > Which would not harm, because it would be version N from committer X. Any if
> > committer X merges from anything else, the next number would be > N. I did not
> > claim that my method makes a total ordering of commits and merges possible.
>
> Neither does it make the numbers unique for committer X.
>
> If commiter X commits a successor to commit N, it's labeled N+1. If
> later, he creates another branch from commit N, and commit, the new,
> other commit will be labeled N+1.
Correct: They live in a parallel universe. But on the long term they will either
vanish or be merged in which case the number will be "> N+1" (on the main branch).
So we have a branch plus a sequence number all the time.
>
> This means even within a repository, you cannot say things like
> "commit number N", so, OK, you have numerical IDs, but you can't use
> them.
I never wanted to have such a thing (using those numbers for commit).
>
> What can be interesting is that a commit takes
> max{all commits in repository}+1, not just max{parents} + 1. Then, you
> have local revision numbers, but they're not stable. Indeed, that's
> precisely what Mercurial does.
That would be a (temporary) total ordering, which I did not want, exactly for that
reason.
[I did not intend the following use case]
Ulrich
>
> But I'm not sure how much simplicity it adds compared to the confusion
> it adds. Newbies will see Mercurial identifiers as
>
> changeset: 2:699b81a5851b
> changeset: 1:fd4b6597548f
> changeset: 0:58cff172192e
>
> And think "OK, the revision numbers are 0, 1, 2, and the hexadecimal
> stuff beside is useless". And one day, he'll send a mail, post a
> bugreport, or whatever, saying "I have a problem with revision number
> 42", and no one else but him will know which revision is called "42".
>
> > I truly believe in unique IDs, but they are just not handy in every situation.
>
> Usually, people find Git IDs to be non-handy until the find out they
> can cut-and-paste only the first few digits in most cases, like
> 442dd42 instead of 442dd42d6d4903640b0dc5561481a77c88dcea90 ;-).
>
> --
> Matthieu
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-04-01 9:47 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Russ Dill, H.Merijn Brand, git
In-Reply-To: <49D327C4.7000101@op5.se>
On 1 Apr 2009 at 10:37, Andreas Ericsson wrote:
> >> Not only that, but modification times are much more useful with make.
> >> Merging or pulling small changes into a tree shouldn't require a full
> >> rebuild of the entire tree which in some cases could take hours.
> >
> > Git is not a build system, and I really dislike "full rebuilds", but for
> > stability, before releasing anything, one should test it with a full rebuild.
>
> I build all the time. Before and after every commit (merges are one type of
> commit). I rely on file timestamps to be an accurate indicator of when the
> file last changed *on my disk*.
>
But you are silently assuming that the make files are correct: If a file is not
being rebuilt, you might be using an old compile without noticing. There a full
recompile will at least 1) either trigger an error (missing object file) or 2)
build every file. So I really don't see that relying on file dates is much better
than doing a full rebuild. That's specifically true if you pull a new tree: If I
understand things right, EVERY file will have a current date, so you'll rebuild
everything anyway. So you could also have the "real file dates" and then do "make
clean; make all". I see no benefit from either approach.
Regards,
Ulrich
^ permalink raw reply
* Re: Segfault on merge with 1.6.2.1
From: Miklos Vajna @ 2009-04-01 9:50 UTC (permalink / raw)
To: Michael Johnson; +Cc: git
In-Reply-To: <op.uro0u0xuso3nzr@sulidor.mdjohnson.us>
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
On Wed, Apr 01, 2009 at 12:43:38AM -0500, Michael Johnson <redbeard@mdjohnson.us> wrote:
> Anyway, I decided to try an experiment, as I had mentioned to someone that
> if I couldn't get this bug tracked down, I'd have to do the merge
> manually. So... I figured out the common ancestor (I used git show-branch,
> but I'm betting there's an easier way), and merged the ancestor + 1 of the
> other branch into my HEAD. It segfaulted. So, I tried the resolve strategy
> at the same point. Amazingly, it worked. And a default recursive merge
> handled the rest.
I initially replied to this thread as I wasn't sure if it's a bug in
merge-recursive or builtin-merge itself. I'm not that familiar with
merge-recursive, that's why I didn't reply so far. ;-)
> In short, I don't personally need a fix right now, but I can help figure
> out what is broken with it.
If you don't need rename detection, you can merge with '-s resolve', I
think that would do what you need and it avoids the problematic
codepath.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-04-01 9:55 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Andreas Ericsson, git
In-Reply-To: <49D328C2.4000006@op5.se>
On 1 Apr 2009 at 10:41, Andreas Ericsson wrote:
> Ulrich Windl wrote:
> > On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:
> >
> > [...]
> >> 3 It's far better to set the version number in the release-process. Usually
> >> this can be done automatically by one invocation of "git describe", just
> >> as git.git does it.
> >
> > However if you put a version number into every file and THEN commit, it's somewhat
> > ridiculous (I'll have to learn about "git describe"). But for configuration
> > management you want to have exactly that (find exactly the file that was shipped
> > (or used to build)).
> >
> >> We've adopted "3" full out at $dayjob. Our build-machinery gets the version
> >> number from the git tag (releases can only be built from signed tags), and
> >> it updates macros and whatnot used for informing the user which version he
> >> or she is running. This makes a lot more sense both from a bug-reporting
> >> and from a release process view than having generated version-numbers in
> >
> > So your "release commits" are outside GIT? (see above)
> >
>
> They aren't release commits. Just a script that creates a tarball and an RPM
> (in our case).
OK, that's what I did with CVS also, but with "CVS diff" I see the revision
numbers (old and new) for every single file in a patch, while Git just uses "a"
and "b". There I'd still prefer what CVS does.
>
> >> files. On a side-note; When I told my co-workers I'd like us to switch to
> >> git, two of them asked about autoversioning features. I said there weren't
> >> any and asked them to name a single time when we've actually used them for
> >> anything *at all*. In a team of eight, having been programming for three
> >> years with 12 releases and about 800 bugreports + feature-requests, noone
> >> could mention a single time when the autogenerated version numbers had
> >> actually been used for anything.
> >
> > Hmm: Were they visible to customers?
> >
>
> Ofcourse they were, but they were rather useless even there, as a customer
> could upgrade and the $Id$ tag still wouldn't get updated. It caused a lot
> of confusion for our not-so-techsavvy users and customers.
What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade?
Because it's a manual process?
[...]
Regards,
Ulrich
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Andreas Ericsson @ 2009-04-01 10:10 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Matthieu Moy, Jakub Narebski, Michael J Gruber, git
In-Reply-To: <49D35254.4137.CB56FE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
Ulrich Windl wrote:
> On 1 Apr 2009 at 9:54, Matthieu Moy wrote:
>
>> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
>>
>>>> Not to mention that you can have multiple roots (multiple commits with
>>>> no parent) in git repository; besides independent branches (like
>>>> 'man', 'html' or 'todo') it is usually result of absorbing or
>>>> subtree-merging other projects. In 'master' branch there are 5 roots
>>>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
>>>> and subtree-merged gitk and git-gui. And here you would again have
>>>> multiple commits with the same number...
>>> Which would not harm, because it would be version N from committer X. Any if
>>> committer X merges from anything else, the next number would be > N. I did not
>>> claim that my method makes a total ordering of commits and merges possible.
>> Neither does it make the numbers unique for committer X.
>>
>> If commiter X commits a successor to commit N, it's labeled N+1. If
>> later, he creates another branch from commit N, and commit, the new,
>> other commit will be labeled N+1.
>
> Correct: They live in a parallel universe. But on the long term they will either
> vanish or be merged in which case the number will be "> N+1" (on the main branch).
> So we have a branch plus a sequence number all the time.
>
>> This means even within a repository, you cannot say things like
>> "commit number N", so, OK, you have numerical IDs, but you can't use
>> them.
>
> I never wanted to have such a thing (using those numbers for commit).
>
If you weren't going to use them for commits, what use are they at all?
I think you need to show us at least one use-case where this would
be beneficial *at all* before anyone is going to take this suggestion
seriously (this time around; It's been dropped on the floor numerous
times before when those original posters came to their senses).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH] Documentation: use "spurious .sp" XSLT if DOCBOOK_SUPPRESS_SP is set
From: Jeff King @ 2009-04-01 10:14 UTC (permalink / raw)
To: Chris Johnsen; +Cc: Junio C Hamano, Heiko Voigt, git
In-Reply-To: <1238575834-17838-1-git-send-email-chris_johnsen@pobox.com>
On Wed, Apr 01, 2009 at 03:50:34AM -0500, Chris Johnsen wrote:
> With this change, the "spurious .sp" suppression XSLT code is
> disabled by default. It can be enabled by defining
> DOCBOOK_SUPPRESS_SP.
> [...]
> Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
Acked-by: Jeff King <peff@peff.net>
This looks good to me. Thank you for being so thorough in both the
research and implementation, especially when I was being so lazy. :)
> I went with a "feature knob" instead of a "version knob" since my
> research in the docbook SVN repo indicates that multiple versions
> are affected. Maybe the name could be better. Also I am not at
> all sure that my research into past docbook-xsl releases is 100%
> accurate. Anyone motivated enough to install old versions of
> docbook-xsl and test with them?
I think the "feature knob" makes sense. I don't know that it is worth
extensive testing with old releases. You have a pretty good guess about
which versions are affected, and people who experience the problem can
turn the knob. Your Makefile comments make it easy for them find the
knob once they see the breakage.
It is probably worth mentioning in the release notes to give a heads-up,
though.
Something like:
-- >8 --
Subject: mention docbook knob in the release notes
People with ancient docbook-xsl will see the return of the "spurious
.sp" unless this knob is turned, so let's inform them.
---
diff --git a/Documentation/RelNotes-1.6.3.txt b/Documentation/RelNotes-1.6.3.txt
index f0a2e41..0c8a14e 100644
--- a/Documentation/RelNotes-1.6.3.txt
+++ b/Documentation/RelNotes-1.6.3.txt
@@ -107,6 +107,11 @@ Updates since v1.6.2
* Makefile learned 'coverage' option to run the test suites with
coverage tracking enabled.
+* Building the manpages with docbook-xsl between 1.69.1 and 1.71.1 now
+ requires setting DOCBOOK_SUPPRESS_SP to work around a docbook-xsl bug.
+ This workaround used to be enabled by default, but causes problems
+ with newer versions of docbook-xsl.
+
Fixes since v1.6.2
------------------
^ permalink raw reply related
* Re: On git 1.6 (novice's opinion)
From: Andreas Ericsson @ 2009-04-01 10:17 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Andreas Ericsson, Russ Dill, H.Merijn Brand, git
In-Reply-To: <49D35454.12423.D32681@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
Ulrich Windl wrote:
> On 1 Apr 2009 at 10:37, Andreas Ericsson wrote:
>
>>>> Not only that, but modification times are much more useful with make.
>>>> Merging or pulling small changes into a tree shouldn't require a full
>>>> rebuild of the entire tree which in some cases could take hours.
>>> Git is not a build system, and I really dislike "full rebuilds", but for
>>> stability, before releasing anything, one should test it with a full rebuild.
>> I build all the time. Before and after every commit (merges are one type of
>> commit). I rely on file timestamps to be an accurate indicator of when the
>> file last changed *on my disk*.
>>
>
> But you are silently assuming that the make files are correct: If a file is not
> being rebuilt, you might be using an old compile without noticing. There a full
> recompile will at least 1) either trigger an error (missing object file) or 2)
> build every file. So I really don't see that relying on file dates is much better
> than doing a full rebuild. That's specifically true if you pull a new tree: If I
> understand things right, EVERY file will have a current date, so you'll rebuild
> everything anyway. So you could also have the "real file dates" and then do "make
> clean; make all". I see no benefit from either approach.
>
You'll see the benefit of not rebuilding everything when your projects start
spanning more than 30k lines. Buildtesting a subsystem of the linux kernel
would be a major pain if object files weren't kept around from previous builds,
and integration-testing the hundreds (sometimes) of feature-branches would be
completely impossible if timestamps on files weren't updated when files change
on disk.
Incidentally, we do full rebuilds too, but no developer sits around watching
them. They're handled by our (stupid but efficient) homegrown CI-solution,
which emails the results to the devs. This happens every push though, not
every commit, but in our rather tight environment at $dayjob we push
frequently enough for that not to be a problem.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Andreas Ericsson @ 2009-04-01 10:21 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Andreas Ericsson, git
In-Reply-To: <49D35616.1812.DA02BA@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
Ulrich Windl wrote:
> On 1 Apr 2009 at 10:41, Andreas Ericsson wrote:
>
>> Ulrich Windl wrote:
>>> On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:
>>>
>>> [...]
>>>> 3 It's far better to set the version number in the release-process. Usually
>>>> this can be done automatically by one invocation of "git describe", just
>>>> as git.git does it.
>>> However if you put a version number into every file and THEN commit, it's somewhat
>>> ridiculous (I'll have to learn about "git describe"). But for configuration
>>> management you want to have exactly that (find exactly the file that was shipped
>>> (or used to build)).
>>>
>>>> We've adopted "3" full out at $dayjob. Our build-machinery gets the version
>>>> number from the git tag (releases can only be built from signed tags), and
>>>> it updates macros and whatnot used for informing the user which version he
>>>> or she is running. This makes a lot more sense both from a bug-reporting
>>>> and from a release process view than having generated version-numbers in
>>> So your "release commits" are outside GIT? (see above)
>>>
>> They aren't release commits. Just a script that creates a tarball and an RPM
>> (in our case).
>
> OK, that's what I did with CVS also, but with "CVS diff" I see the revision
> numbers (old and new) for every single file in a patch, while Git just uses "a"
> and "b". There I'd still prefer what CVS does.
>
>>>> files. On a side-note; When I told my co-workers I'd like us to switch to
>>>> git, two of them asked about autoversioning features. I said there weren't
>>>> any and asked them to name a single time when we've actually used them for
>>>> anything *at all*. In a team of eight, having been programming for three
>>>> years with 12 releases and about 800 bugreports + feature-requests, noone
>>>> could mention a single time when the autogenerated version numbers had
>>>> actually been used for anything.
>>> Hmm: Were they visible to customers?
>>>
>> Ofcourse they were, but they were rather useless even there, as a customer
>> could upgrade and the $Id$ tag still wouldn't get updated. It caused a lot
>> of confusion for our not-so-techsavvy users and customers.
>
> What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade?
> Because it's a manual process?
>
It MAY not get updated, since $Id$ tags are per-file instead of per-project.
Any sane project will have more than one file, and the file listing the
$Id$ that the end-user sees may not have changed since the last release.
Per-file revision tags are stupid and useless for anything but a one-file
project.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH] Add configuration variable for sign-off to format-patch
From: Jeff King @ 2009-04-01 10:26 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Junio C Hamano
In-Reply-To: <20090331204338.GA88381@macbook.lan>
On Tue, Mar 31, 2009 at 10:43:48PM +0200, Heiko Voigt wrote:
> I see, it is of course true that you should not just sign off
> everything without thinking about it.
>
> However I always read through my messages before sending them and it is
> way easier to delete that line than typing/copying it.
I agree. Personally, the concept of writing something that I _couldn't_
sign off on is so foreign to me that I would be very conscious of the
fact, and it would be simple to remove it during the final proof-read of
the patch that I do.
I think to satisfy everyone, though, you need some extra text in the
documentation indicating that signing off is supposed to be conscious,
and you should understand the implications of setting the variable.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: use "spurious .sp" XSLT if DOCBOOK_SUPPRESS_SP is set
From: Jeff King @ 2009-04-01 10:34 UTC (permalink / raw)
To: Chris Johnsen; +Cc: Junio C Hamano, Heiko Voigt, git
In-Reply-To: <1238575834-17838-1-git-send-email-chris_johnsen@pobox.com>
On Wed, Apr 01, 2009 at 03:50:34AM -0500, Chris Johnsen wrote:
> The key revisions in the docbook SVN repo seem to be 5144 (before
> docbook-xsl 1.69.1) and 6359 (before docbook-xsl 1.71.1).
>
> Testing done with asciidoc 8.3.1 and docbook-xsl 1.74.0.
In the course of your SVN research, did you find the fixes between
1.73.1 and 1.74.3 that fixed the spacing issue? If so, I wonder if it's
worth backporting that fix to DOCBOOK_FIX_LIST_SPACING.
-Peff
^ permalink raw reply
* [JGIT PATCH/RFC] Added -crlf attribute for test patch files
From: Constantine Plotnikov @ 2009-04-01 10:59 UTC (permalink / raw)
To: git
The method RawParseUtils.nextLF(byte[],int,char) used for parsing
patches expects \n as a line separator. However on MinGW git
uses \r\n as line separator for text files by default, and patch
files in egit/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/patch
are treated as text files. This caused test suit failure. To prevent
test suit failure, "-crlf" attribute is added for patch files.
Signed-off-by: Constantine Plotnikov <constantine.plotnikov@gmail.com>
---
I'm not completely sure whether I have fixed a correct place.
MinGW itself uses \n as line separator in patches. Thus I think
it is an error to have \r\n in the patch file, so I have fixed
patch files rather than parsing code. Other possible solution
is to fix nextLF() to handle \r\n as well.
Without this fix the egit could not be built on the maven when
it is checked out using MinGW git.
.../tst-rsrc/org/spearce/jgit/patch/.gitattributes | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644
org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/patch/.gitattributes
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/patch/.gitattributes
b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/patch/.gitattributes
new file mode 100644
index 0000000..b38f87f
--- /dev/null
+++ b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/patch/.gitattributes
@@ -0,0 +1 @@
+*.patch -crlf
--
1.6.0.2.1172.ga5ed0
^ permalink raw reply related
* [PATCH] builtin-clone.c: no need to strdup for setenv
From: Ali Gholami Rudi @ 2009-04-01 11:22 UTC (permalink / raw)
To: git
The setenv function makes a copy, itself.
Signed-off-by: Ali Gholami Rudi <ali@rudi.ir>
---
builtin-clone.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 0031b5f..28d15bb 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -406,7 +406,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
atexit(remove_junk);
sigchain_push_common(remove_junk_on_signal);
- setenv(CONFIG_ENVIRONMENT, xstrdup(mkpath("%s/config", git_dir)), 1);
+ setenv(CONFIG_ENVIRONMENT, mkpath("%s/config", git_dir), 1);
if (safe_create_leading_directories_const(git_dir) < 0)
die("could not create leading directories of '%s'", git_dir);
^ permalink raw reply related
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-04-01 11:52 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Andreas Ericsson, git
In-Reply-To: <49D34015.9080709@op5.com>
On 1 Apr 2009 at 12:21, Andreas Ericsson wrote:
[...]
> > What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade?
> > Because it's a manual process?
> >
>
> It MAY not get updated, since $Id$ tags are per-file instead of per-project.
> Any sane project will have more than one file, and the file listing the
> $Id$ that the end-user sees may not have changed since the last release.
>
> Per-file revision tags are stupid and useless for anything but a one-file
> project.
Hmm...:
# what vmunix
vmunix:
ivt.s $Date: 2008/11/21 09:10:19 $Revision: r11.31/5 PATCH_11.31 (B11.3
1.0903LR)
side_dumpdev - HP IDE Dump Driver B.11.31 /ux/core/kern/em/svc/dump/scs
i_ide_dumpdev.c: Jan 8 2009, 23:48:25
eschgr - Changer Driver B.11.31.01 /ux/core/kern/common/io/escsi/eschgr
/eschgr.c:Jan 10 2007,17:04:47
eschgr - Changer Driver B.11.31.01 /ux/core/kern/common/io/escsi/eschgr
/eschgr_diag.c:Dec 27 2006,16:59:17
[...]
vxfs:$RCSfile: vx_portal.c,v $ $Revision: 4.14.26.3 $
vxfs:$RCSfile: vx_portal_osrel.c,v $ $Revision: 1.1.2.1 $
vxfs:$RCSfile: vx_portal_dlkm.c,v $ $Revision: 1.1.2.1 $
vxfs:$RCSfile: vxportal50.modmeta,v $ $Revision: 1.1.2.5 $
wsio_cdio.c $Date: 2008/06/03 05:52:50 $Revision: r11.31/13 PATCH_11.31
(B11.31.0809LR)
$Revision: wsio: B11.31.0809LR
$Revision: wxb_hp: B.11.31_LR
tracer.s $Date: 2008/04/28 17:14:06 $Revision: r11.31/3 PATCH_11.31 (B1
1.31.0809LR)
For a kernel, where development is decentralized, it would make sense: Imageine a
user (or distributor) will nut upgrade anything to the latest version, but only
parts (subsystems). Then the single kernel version number is meaningless.
Regards,
Ulrich
^ permalink raw reply
* [JGIT PATCH] Addition of source and javadoc plugins to maven script
From: Constantine Plotnikov @ 2009-04-01 11:48 UTC (permalink / raw)
To: git
When JGIT jar is bundled with projects, it often needed
to inspect JGIT sources in order to look for documentation
and implementation. The sources are also very useful during
debugging. The patch adds source plugin that builds source jar,
so the matching version of the source.jar could be easily
bundled. The javadoc plugin generates ready to use archive with
javadoc.
---
jgit-maven/jgit/pom.xml | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/jgit-maven/jgit/pom.xml b/jgit-maven/jgit/pom.xml
index c370783..75c4b75 100644
--- a/jgit-maven/jgit/pom.xml
+++ b/jgit-maven/jgit/pom.xml
@@ -169,6 +169,26 @@ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
</includes>
</configuration>
</plugin>
+ <plugin>
+ <artifactId>maven-source-plugin</artifactId>
+ <executions>
+ <execution>
+ <goals>
+ <goal>jar</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
+ <plugin>
+ <artifactId>maven-javadoc-plugin</artifactId>
+ <executions>
+ <execution>
+ <goals>
+ <goal>jar</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
</plugins>
</build>
<dependencies>
--
1.6.0.2.1172.ga5ed0
^ permalink raw reply related
* [JGIT PATCH v2] Addition of source and javadoc plugins to maven script
From: Constantine Plotnikov @ 2009-04-01 11:50 UTC (permalink / raw)
To: git
In-Reply-To: <85647ef50904010448j688b1c7agd01e7dfef107b36d@mail.gmail.com>
When JGIT jar is bundled with projects, it often needed
to inspect JGIT sources in order to look for documentation
and implementation. The sources are also very useful during
debugging. The patch adds source plugin that builds source jar,
so the matching version of the source.jar could be easily
bundled. The javadoc plugin generates ready to use archive with
javadoc.
Signed-off-by: Constantine Plotnikov <constantine.plotnikov@gmail.com>
---
Forgot Signed-off-by in the previous version.
jgit-maven/jgit/pom.xml | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/jgit-maven/jgit/pom.xml b/jgit-maven/jgit/pom.xml
index c370783..75c4b75 100644
--- a/jgit-maven/jgit/pom.xml
+++ b/jgit-maven/jgit/pom.xml
@@ -169,6 +169,26 @@ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
</includes>
</configuration>
</plugin>
+ <plugin>
+ <artifactId>maven-source-plugin</artifactId>
+ <executions>
+ <execution>
+ <goals>
+ <goal>jar</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
+ <plugin>
+ <artifactId>maven-javadoc-plugin</artifactId>
+ <executions>
+ <execution>
+ <goals>
+ <goal>jar</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
</plugins>
</build>
<dependencies>
--
1.6.0.2.1172.ga5ed0
^ permalink raw reply related
* Re: [StGit PATCH] Convert "pop" to the lib infrastructure
From: Karl Hasselström @ 2009-04-01 12:05 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20090331113027.2524.60993.stgit@pc1117.cambridge.arm.com>
On 2009-03-31 12:30:27 +0100, Catalin Marinas wrote:
> @@ -47,7 +47,7 @@ test_expect_success 'Try to reset with --hard' '
> stg reset --hard master.stgit^~1 &&
> stg status a > actual.txt &&
> test_cmp expected.txt actual.txt &&
> - test "$(echo $(stg series))" = "> p1 - p3 - p2"
> + test "$(echo $(stg series))" = "> p1 - p2 - p3"
> '
Hmm, why this change in behavior? Something that should be noted in
the commit message?
> @@ -47,7 +47,7 @@ test_expect_success 'Try to undo with --hard' '
> stg undo --hard &&
> stg status a > actual.txt &&
> test_cmp expected.txt actual.txt &&
> - test "$(echo $(stg series))" = "> p1 - p3 - p2"
> + test "$(echo $(stg series))" = "> p1 - p2 - p3"
> '
And I guess this is the same.
Otherwise, this looks good.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH] Convert "push" to the lib infrastructure
From: Karl Hasselström @ 2009-04-01 12:06 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20090331113033.2524.27502.stgit@pc1117.cambridge.arm.com>
On 2009-03-31 12:30:33 +0100, Catalin Marinas wrote:
> Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
Acked-by: Karl Hasselström <kha@treskal.com>
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Documentation: use "spurious .sp" XSLT if DOCBOOK_SUPPRESS_SP is set
From: Chris Johnsen @ 2009-04-01 12:19 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Heiko Voigt, git
In-Reply-To: <20090401103442.GD26181@coredump.intra.peff.net>
On 2009 Apr 1, at 05:34, Jeff King wrote:
> On Wed, Apr 01, 2009 at 03:50:34AM -0500, Chris Johnsen wrote:
>
>> The key revisions in the docbook SVN repo seem to be 5144 (before
>> docbook-xsl 1.69.1) and 6359 (before docbook-xsl 1.71.1).
>>
>> Testing done with asciidoc 8.3.1 and docbook-xsl 1.74.0.
>
> In the course of your SVN research, did you find the fixes between
> 1.73.1 and 1.74.3 that fixed the spacing issue? If so, I wonder if
> it's
> worth backporting that fix to DOCBOOK_FIX_LIST_SPACING.
I guess you are referring to an issue different from the one created
by using the "spurious .sp" simpara template, but I am not familiar
with another one. If not, then I am confused. The new patch to avoid
using the "spurious .sp" template fixes the list spacing in pu's git-
cvsimport.1 when I generate it here (using docbook-xsl 1.74.0). For
example, the extra blank line after "Problems related to timestamps:"
goes away and a new blank line is inserted before "Problems related
to branches:".
My poking around in the docbook SVN repo was largely limited to the
manpages/block.xsl file since that is where the normal simpara
template lives. If this other issue is list specific, it seems likely
that fixes would be in manpages/lists.xsl. It looks like there have
only been around ten commits to that lists.xsl since 1.73.1, but none
of them jumped out at me as likely culprits unless the spacing you
mean is indentation or "bullet"-to-text spacing (though my brain is
tired right now).
--
Chris
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Andreas Ericsson @ 2009-04-01 12:40 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Andreas Ericsson, Andreas Ericsson, git
In-Reply-To: <49D37190.23422.145597D@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
Ulrich Windl wrote:
> On 1 Apr 2009 at 12:21, Andreas Ericsson wrote:
>
> [...]
>>> What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade?
>>> Because it's a manual process?
>>>
>> It MAY not get updated, since $Id$ tags are per-file instead of per-project.
>> Any sane project will have more than one file, and the file listing the
>> $Id$ that the end-user sees may not have changed since the last release.
>>
>> Per-file revision tags are stupid and useless for anything but a one-file
>> project.
>
> Hmm...:
> # what vmunix
> vmunix:
> ivt.s $Date: 2008/11/21 09:10:19 $Revision: r11.31/5 PATCH_11.31 (B11.3
> 1.0903LR)
> side_dumpdev - HP IDE Dump Driver B.11.31 /ux/core/kern/em/svc/dump/scs
> i_ide_dumpdev.c: Jan 8 2009, 23:48:25
> eschgr - Changer Driver B.11.31.01 /ux/core/kern/common/io/escsi/eschgr
> /eschgr.c:Jan 10 2007,17:04:47
> eschgr - Changer Driver B.11.31.01 /ux/core/kern/common/io/escsi/eschgr
> /eschgr_diag.c:Dec 27 2006,16:59:17
> [...]
> vxfs:$RCSfile: vx_portal.c,v $ $Revision: 4.14.26.3 $
> vxfs:$RCSfile: vx_portal_osrel.c,v $ $Revision: 1.1.2.1 $
> vxfs:$RCSfile: vx_portal_dlkm.c,v $ $Revision: 1.1.2.1 $
> vxfs:$RCSfile: vxportal50.modmeta,v $ $Revision: 1.1.2.5 $
> wsio_cdio.c $Date: 2008/06/03 05:52:50 $Revision: r11.31/13 PATCH_11.31
> (B11.31.0809LR)
> $Revision: wsio: B11.31.0809LR
> $Revision: wxb_hp: B.11.31_LR
> tracer.s $Date: 2008/04/28 17:14:06 $Revision: r11.31/3 PATCH_11.31 (B1
> 1.31.0809LR)
>
> For a kernel, where development is decentralized, it would make sense: Imageine a
> user (or distributor) will nut upgrade anything to the latest version, but only
> parts (subsystems). Then the single kernel version number is meaningless.
>
Not really. They can (and should) create their own version numbers. I can't make
sense of the above output. If you ask a developer to piece together the puzzle
that makes up this subsystem and then fit it into the bigger picture, he won't
love you for it. Not only because this particular subsystem might well be the
same version across several different releases with all their different API's
(the input system has changed its API's incompatibly quite frequently over the
last six months, fe, so a driver-version *alone* in that system makes absolutely
no sense if you're trying to debug it).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ 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