* Re: [msysGit] Using VC build git
From: Frank Li @ 2009-08-11 1:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysGit
In-Reply-To: <alpine.DEB.1.00.0908101609170.8324@intel-tinevez-2-302>
Thank you take care my patch.
I can fix all problems.
This patch is base on v1.6.4 release. My working branch is vc_build
at git://repo.or.cz/tgit.git.
That is actually prototype to approve VC can build git.
The code style is not big problem. I will fix it.
VC build will reuse many msysgit works because msysgit really do many
work at windows porting.
I think the below is most important problem.
1. Where are vcbuild directory put, is it okay under contrib ?
2. How to handle external library, such as zlib? Can use submodule?
2009/8/10, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Mon, 10 Aug 2009, Johannes Schindelin wrote:
>
>> Please, we have _high_ standards in git.git, and I really do not want to
>> have to take anything to Junio that does not fulfill that standard.
>
> To elaborate: if I see something like this in the --stat:
>
> contrib/vcbuild/include/zlib.h | 1357
> +++++++++++++++++++++++++++++++++
> contrib/vcbuild/lib/zlib.lib | Bin 0 -> 104148 bytes
>
> ... I know already that there is no way this can make it into git.git.
> There just is not.
>
> Also, if the first commit says nothing else than "Rebase to v1.6.4", it
> is pretty obvious to me that I will not sign off on that (and I just guess
> that is the very reason you did not sign off on that, either).
>
> Further, putting anything into contrib/ that really belongs into contrib/
> is not cutting it, either.
>
> And I am pretty astonished that mingw.[ch] is touched, as VC is definitely
> not MinGW32.
>
> Changing 1000+ lines of libgit.vcproj in almost every commit is also
> something I really do not look upon favorably.
>
> Finally, if _no single_ commit message says _anything_ about the reasons
> why you had to change code outside of vcbuild/, I am only puzzled.
>
> Now, I want to give you a pretty clear idea what has to be done if this is
> going into 4msysgit.git, ever, because you obviously spent a lot of time
> on it, and other people want it, too:
>
> - changing "open" to "_open" in mingw.c is a no-no-no. If you need to use
> "_open" in VC, then define "open" in the compile flags for mingw.c, but
> leave code that is not written for VC alone.
>
> - introducing trailing whitespace is usually a sign of not caring enough
> about clean and neat code. So just don't do it.
>
> - making link() fail on MinGW32 just to be able to compile it with VC is
> outright rude against all people who use a free and open compiler
> instead of a closed one.
>
> - changing an "_snprintf" to "_vsnprintf" in vcbuild/porting.c without
> anything else is a clear and loud sign that the code before was broken,
> and that you fix a faulty patch in a later patch. This is not how we do
> things in git.git. We fix the proper patch before the patch series is
> accepted into mainline.
>
> - violating the coding style -- even if it is in your VC-specific part --
> is not an option. You need to fix the coding style.
>
> - violating the coding style in files that are not VC-specific is not an
> option at all. You really need to fix it.
>
> - changing the default editor from "vi" to "notepad2" will break almost
> every existing Git user's setup. That is just inexcusable.
>
> Note: these comments are _just for the last_ of your 5 patches.
>
> Just a brief comment on the 4th patch, because I really do not want to
> spend more time on this round of patches: spelling the opendir() function
> as "open dir" function in the commit message is misleading, to say the
> least, and moving code that was added in a previous patch in the same
> patch series just shows that it was a mistake to begin with. Besides,
> don't move anything into mingw.c if MinGW32 does not need it.
>
> Hth,
> Dscho
>
>
>
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] Prevent diff machinery from examining assume-unchanged entries on worktree
From: Nguyen Thai Ngoc Duy @ 2009-08-11 1:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0908101800480.8324@intel-tinevez-2-302>
2009/8/10 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> +test_expect_success 'setup' '
>> + echo zero > zero &&
>> + git add zero &&
>> + git commit -m zero &&
>> + echo one > one &&
>> + echo two > two &&
>> + git add one two &&
>> + git commit -m onetwo &&
>> + git update-index --assume-unchanged one &&
>> + echo borked >> one &&
>> + test "$(git ls-files -v one)" = "h one"
>> +'
>
> Maybe use test_commit, to make it more readable?
Thanks. I did not know that (or forgot already). Will use it.
>
>> +
>> +test_expect_success 'diff-index does not examine assume-unchanged entries' '
>> + git diff-index HEAD^ -- one | grep -q 5626abf0f72e58d7a153368ba57db4c673c0e171
>> +'
>> +
>> +# TODO ced_uptodate()
>
> What is this about?
It tests "if (ce_uptodate(ce) || (ce->ce_flags & CE_VALID))" and I was
pretty sure it hit ce_uptodate() first, so the second expression was
not tested.
--
Duy
^ permalink raw reply
* Re: [RFC PATCH v2 4/4] read-tree: add --no-sparse to turn off sparse hook
From: Nguyen Thai Ngoc Duy @ 2009-08-11 1:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0908101842530.8324@intel-tinevez-2-302>
2009/8/10 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Mon, 10 Aug 2009, Nguyễn Thái Ngọc Duy wrote:
>
>> diff --git a/unpack-trees.c b/unpack-trees.c
>> index f407bf5..d087112 100644
>> --- a/unpack-trees.c
>> +++ b/unpack-trees.c
>> @@ -530,8 +530,10 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
>> if (o->trivial_merges_only && o->nontrivial_merge)
>> return unpack_failed(o, "Merge requires file-level merging");
>>
>> - if (run_sparse_hook(o))
>> - return unpack_failed(o, NULL);
>> + if (!o->no_sparse_hook) {
>> + if (run_sparse_hook(o))
>> + return unpack_failed(o, NULL);
>> + }
>>
>
> IMHO this would read nicelier as
>
> if (!o->no_sparse_hook && run_sparse_hook(o))
> return unpack_failed(o, NULL);
Right.
>> diff --git a/unpack-trees.h b/unpack-trees.h
>> index ad21823..81eb2ef 100644
>> --- a/unpack-trees.h
>> +++ b/unpack-trees.h
>> @@ -30,6 +30,7 @@ struct unpack_trees_options {
>> skip_unmerged,
>> initial_checkout,
>> diff_index_cached,
>> + no_sparse_hook,
>> gently;
>
> Hmm. I understand that the assumption is that memset(&opts, 0,
> sizeof(opts)); should give you a sensible default, but I cannot avoid
> noticing that "no_sparse_hook = 0" is a double negation, something to be
> avoided...
skip_sparse_hook then? :-)
--
Duy
^ permalink raw reply
* Re: [RFC PATCH v2 3/4] unpack_trees(): add support for sparse checkout
From: Nguyen Thai Ngoc Duy @ 2009-08-11 1:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0908101837510.8324@intel-tinevez-2-302>
2009/8/10 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Mon, 10 Aug 2009, Nguyễn Thái Ngọc Duy wrote:
>
>> This patch teaches unpack_trees() to checkout/remove entries on working
>> directories appropriately when sparse checkout area is changed. Hook
>> "sparse" is needed to help determine which entry will be checked out,
>> which will not be.
>>
>> When the hook is run, it is prepared with a pseudo index. The hook then
>> can use "git update-index --[no-]assume-unchanged" to manipulate the
>> index. It should not do anything else on the index. Assume unchanged
>> information from the index will be used to shape working directory.
>
> If I understand correctly, the purpose of the hook is to allow the user to
> mark something as unwanted preemptively, right?
>
> If that is the sole reason for the hook, would it not be better to add
> support for a file .git/info/sparse which has the same syntax as
> .git/info/exclude, and which is used to determine if an
> added/modified/deleted file is supposed to be in the "sparse" area or not?
>
> Something like
>
> *
> !/Documentation/
>
> comes to mind.
That was what the original series was about (although I used git
config instead of .git/info/sparse). The hook has two advantages:
- flexibility: you can set things differently based on branch, for
example, or filter files based on certain file content.
- less code bloat (and less intrusive too), compare ~1000 lines of
change of the original series with this series.
--
Duy
^ permalink raw reply
* Re: [RFC PATCH v2 2/4] gitignore: read from index if .gitignore is assume-unchanged
From: Nguyen Thai Ngoc Duy @ 2009-08-11 1:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0908101826250.8324@intel-tinevez-2-302>
2009/8/10 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Mon, 10 Aug 2009, Nguyễn Thái Ngọc Duy wrote:
>
>> diff --git a/dir.c b/dir.c
>> index e05b850..e55344f 100644
>> --- a/dir.c
>> +++ b/dir.c
>> @@ -200,11 +200,36 @@ void add_exclude(const char *string, const char *base,
>> which->excludes[which->nr++] = x;
>> }
>>
>> +static void *read_index_data(const char *path, size_t *size)
>
> How about calling it "read_assume_unchanged_from_index()" instead? I
> suggest this because it does not read the index from the data if the path
> is not marked assume unchanged...
Agree.
>> @@ -212,27 +237,31 @@ static int add_excludes_from_file_1(const char *fname,
>>
>> [...]
>>
>> if (buf_p)
>> *buf_p = buf;
>> - buf[size++] = '\n';
>> entry = buf;
>> - for (i = 0; i < size; i++) {
>> - if (buf[i] == '\n') {
>> + for (i = 0; i <= size; i++) {
>> + if (i == size || buf[i] == '\n') {
>> if (entry != buf + i && entry[0] != '#') {
>> buf[i - (i && buf[i-1] == '\r')] = 0;
>> add_exclude(entry, base, baselen, which);
>
> Should this change not rather be a separate one?
You meant a separate patch? It is tied to this patch, because if bus
is read from read_index_data, it does not have extra space for '\n' at
the end.
>> @@ -241,17 +270,12 @@ static int add_excludes_from_file_1(const char *fname,
>> }
>> }
>> return 0;
>> -
>> - err:
>> - if (0 <= fd)
>> - close(fd);
>> - return -1;
>> }
>>
>> void add_excludes_from_file(struct dir_struct *dir, const char *fname)
>> {
>> if (add_excludes_from_file_1(fname, "", 0, NULL,
>> - &dir->exclude_list[EXC_FILE]) < 0)
>> + &dir->exclude_list[EXC_FILE], 0) < 0)
>
> Could you mention in the commit message why this function does not want to
> check the index (I _guess_ it is because this code path only tries to read
> .git/info/exclude, but it would be better to be sure).
To retain old behaviour. But I have to check its callers. Maybe we
want to check the index too.
>> @@ -85,6 +85,26 @@ test_expect_success \
>> >output &&
>> test_cmp expect output'
>>
>> +test_expect_success 'setup sparse gitignore' '
>> + git add .gitignore one/.gitignore one/two/.gitignore &&
>> + git update-index --assume-unchanged .gitignore one/.gitignore one/two/.gitignore &&
>> + rm .gitignore one/.gitignore one/two/.gitignore
>> +'
>
> You're probably less sloppy than me; I'd have defined a variable like
> this:
>
> ignores=".gitignore one/.gitignore one/two/.gitignore"
>
> and used it for the three calls, just to make sure that I do not fsck
> anything up there due to fat fingers.
I have slim ones :-) But "git add $ignores && git update-index
$ignores && rm $ignores" is easier to read.
--
Duy
^ permalink raw reply
* Re: [PATCH] Fix typos in git-remote.txt and git-symbolic-ref.txt
From: Junio C Hamano @ 2009-08-11 5:13 UTC (permalink / raw)
To: Štěpán Němec; +Cc: git, trast
In-Reply-To: <20090811005207.GE24183@headley>
Thanks.
^ permalink raw reply
* Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs
From: Junio C Hamano @ 2009-08-11 5:12 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Daniel Barkalow, Brian Gernhardt, Johannes Schindelin
In-Reply-To: <200908101032.12835.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> On Monday 10 August 2009, Daniel Barkalow wrote:
> ...
>> The only way I've been able to come up with to support this at all
>> usefully is to have a bunch of helper-specific options that specify what
>> the helper needs to know about the locations you consider to be part of
>> the project and an option that tells git that this remote uses the p4
>> helper. I'm not sure what makes sense for other helpers, but the case I
>> actually use needs something like what's in this patch.
>
> I'm somewhat agnostic on this issue. At the moment, I follow the P4 cues,
> and use a config like this:
>
> [remote "foo"]
> vcs = cvs
> cvsRoot = ":pserver:user@cvs.server.example.com/var/cvs/cvsroot"
> cvsModule = "bar"
> ...
>
> But I could just as well use a config like this instead:
>
> [remote "foo"]
> url = "cvs::pserver:user@cvs.server.example.com/var/cvs/cvsroot#bar"
> ...
>
> Either is fine with me, although I suspect users might find the
> current/first alternative easier to parse.
Ah, ok, that is a much better (rather, easier to understand for _me_)
example to illustrate what Daniel meant, and I can well imagine P4
counterpart of cvsRoot may resemble an URL even less than your cvsRoot
example does.
If the foreign system uses a single string as "the string to identify
location", like the latter (which is a good example, even though I do not
think a CVS folks write a reference to a module like you wrote), then I
think it makes sense to use that form as remote.$name.url. But if naming
a location with a single simple string is an alien notion to the foreign
system, I agree with Daniel that we do not gain much by trying to shoehorn
them into a single remote.$name.url configuration.
^ permalink raw reply
* Re: [PATCH] Fix typos in git-remote.txt and git-symbolic-ref.txt
From: Thomas Rast @ 2009-08-11 7:09 UTC (permalink / raw)
To: Štěpán Němec; +Cc: git
In-Reply-To: <20090811005207.GE24183@headley>
Thanks for the updated version!
Štěpán Němec wrote:
>
> I did look at some of the other documentation files (and now also grepped
> the whole directory for `--' and `\--' occurences), but wasn't able to see
> any rule or consistence in the usage. Whether it is an indication of
> real inconsistence or just another example of my ignorance I do not know
> (not now, at least).
Well, as I said I'm not sure what asciidoc versions, if any, needed
the backslash inside backtick quoting. However, there is precedent in
commit e1ccf53a60657930ae7892387736c8b6a91ec610
Author: Yasushi SHOJI <yashi@atmark-techno.com>
Date: Mon Sep 12 02:29:10 2005 +0900
[PATCH] Escape asciidoc's built-in em-dash replacement
AsciiDoc replace '--' with em-dash (—) by default. em-dash
looks a lot like a single long dash and it's very confusing when
we are talking about command options.
Section 21.2.8 'Replacements' of AsciiDoc's User Guide says that a
backslash in front of double dash prevent the replacement. This
patch does just that.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
So until we know for certain that they're not needed, I'd rather not
actively remove them. Admittedly, there are lots of instances of `--
in the docs too, so making sure which way is "right" and then
replacing _all_ of them would probably be a nice cleanup.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* blame -M vs. log -p|grep -c ^+ weirdness
From: Thomas Rast @ 2009-08-11 10:16 UTC (permalink / raw)
To: git; +Cc: Björn Steinbrink
[-- Attachment #1: Type: Text/Plain, Size: 3047 bytes --]
Hi all
I think I'm fundamentally misunderstanding something about the blame
code... The other day I wanted to see how much our local fork of
DOMjudge diverged from their upstream. You can grab the entire
history at
git://csa.inf.ethz.ch/domjudge-public.git
if you want to try the commands I ran.
As a first statistic I looked at how many lines are blamed to our
local team (Christoph, Florian and me) by running
git ls-files | while read f; do git blame -M -- "$f"; done |
perl -pe 's/^\^?[a-f0-9]* (?:[^(]* )?\(([^2]*?) *20.*/$1/' |
sort | uniq -c | sort -n
This shows that over 8000 lines are attributed to the three of us:
1 domjudge
2 rob
113 Stijn van Drongelen
126 Jeroen Schot
149 neus
866 Peter van de Werken
1245 Thomas Rast
1752 Christoph Krautz
5350 Florian Jug
10293 Thijs Kinkhorst
20397 Jaap Eldering
However, sanity checking this against the diffs of the single commits
shows quite a different number:
git log --no-merges -p upstream/2.2.. | grep '^+' | grep -v -c '^+++'
gives only 4943 '+' lines, and you can easily verify with
git shortlog -sn upstream/2.2..
that indeed all commits in that range are ours. So why does the blame
think more lines are ours than we even added *in total*?
Björn Steinbrink suggested on IRC that I use -M5 -C5 -C5 -C5, which
indeed reduces it to
1 domjudge
2 rob
115 Stijn van Drongelen
116 Jeroen Schot
149 neus
390 Florian Jug
930 Peter van de Werken
1209 Thomas Rast
1612 Christoph Krautz
11750 Thijs Kinkhorst
24020 Jaap Eldering
Note especially the huge drop in Florian's numbers. What's going on
here?
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Unable to checkout a branch after cloning
From: Matthew Lear @ 2009-08-11 10:10 UTC (permalink / raw)
To: git
Hi all,
Apologies for perhaps a silly question, but I'd very much appreciate a
little bit of assistance.
I've set up a git repository on a machine accessible from the internet
with the intention to share code with another developer. We clone the
repository, commit changes then push back as you'd expect. The server
runs gitweb for repository browsing. Clients are running git v1.6.0.6.
When I created the initial repository I also created two additional
branches - 'upstream' and 'custom'. The former is to act as a 'vendor
branch' and the latter contains code specific to the custom platform
that we're working on. The master branch contains merges from the
upstream branch and also changes that we've made. The custom branch
contains merges from master with custom platform specific changes.
I've committed changes and on both upstream and custom branches as work
progressed, merged them where appropriate, added tags etc and pushed
everything to the remote repository. No problem. I can view the
branches, tags etc in gitweb and everything looks fine.
However, I can clone a new repository just fine but I'm unable to
checkout the upstream or custom branches. After cloning, only the master
branch is available, ie:
> git checkout upstream
error: pathspec 'upstream' did not match any file(s) known to git.
> git branch -a
* master
origin/HEAD
origin/master
.git/config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = https://mysite/git/project.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
But the initial local repository where I work (ie created the branches,
committed changes, tag, push etc) seems to be fine, ie
> git checkout upstream
Switched to branch "upstream"
> git branch -a
custom
* master
upstream
.git/config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = https://mysite/git/project.git
fetch = +refs/heads/*:refs/remotes/origin/*
Developers need to be able to clone the repository and then switch to
the appropriate branch in order to work. However it seems that after a
clone, only the master branch is available.
Why is this?
Any help would be much appreciated indeed.
Many thanks,
-- Matt
^ permalink raw reply
* [PATCH] git stash: Give friendlier error when there is nothing to apply
From: Ori Avtalion @ 2009-08-11 11:12 UTC (permalink / raw)
To: git
The old message was scary and included a 'fatal' error from rev-parse:
fatal: Needed a single revision
: no valid stashed state found
The new message is identical to the one given by 'git stash branch', and
given *before* the check for a dirty working tree.
Previously, the command prompted the user to clean a dirty working tree
when there is nothing to apply.
Signed-off-by: Ori Avtalion <ori@avtalion.name>
---
git-stash.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 03e589f..aa84144 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -162,6 +162,8 @@ show_stash () {
}
apply_stash () {
+ have_stash || die 'Nothing to apply'
+
git update-index -q --refresh &&
git diff-files --quiet --ignore-submodules ||
die 'Cannot apply to a dirty working tree, please stage your changes'
--
1.6.4.73.gc144.dirty
^ permalink raw reply related
* RFC: default version of the documentation tool chain (git 1.7)
From: Michael J Gruber @ 2009-08-11 9:28 UTC (permalink / raw)
To: Git Mailing List
The current defaults for building the documentation are so that asciidoc
up to 7.1.2 and docbook-xsl 1.69.0 and 1.71.1 need no extra settings,
whereas all other versions need extra options (1 or more of ASCIIDOC8,
ASCIIDOC_NO_ROFF, DOCBOOK_XSL_172, DOCBOOK_SUPPRESS_SP), see below. This
basically means that all current distros need extra options.
I suggest changing the defaults for the git-1.7 cycle. Below I list the
package versions in current mainstream distros, without using third
party repositories, but including the leading edge which foreshadows
upcoming versions.
Based on that, I suggest the following defaults for the git-1.7
documentation build file:
- ASCIIDOC8=yes. Caters for everything non-EOLed (8.0 and above)
- ASCIIDOC_NO_ROFF=yes. Caters for everything non-EOLed (1.73 and above,
1.68.1 and below)
[I'm not sure RHEL is EOLed but I don't think we need to care.]
It would be helpful if people with newer versions (asciidoc 8.4,
docbook-xsl 1.75) could test building the git documentation, in order to
verify "and above" ;)
Also, I don't know about the two proprietary OSes we support.
Cheers,
Michael
Current mainstream versions of asciidoc are:
Debian Etch (EOLed): 7.1.2
Debian Lenny: 8.2.7
Debian Squeeze: 8.4.4
Debian Sid: 8.4.4
Ubuntu Dapper (EOLed): 7.0.2
Ubuntu Hardy: 8.2.2
Ubuntu Intrepid: 8.2.6
Ubuntu Jaunty: 8.2.7
Ubuntu Karmic: 8.4.4
Fedora 9 (EOLed): 8.2.5
Fedora 10: 8.2.5
Fedora 11: 8.2.5
Fedora rawhide: 8.2.5
Fedora Koji (12): 8.4.5
Redhat EL4 extras: 7.0.2
Redhat EL5 extras: 8.1.0
OpenSUSE 10: 8.2.1
OpenSUSE 11: 8.2.7
OpenSUSE factory: 8.4.5
OpenBSD 4.3: 8.2.5
OpenBSD 4.4: 8.2.6
OpenBSD 4.5: 8.2.7
Current mainstream versions of docbook-xsl are:
Debian Etch (EOLed): 1.71.0
Debian Lenny: 1.73.2
Debian Squeeze: 1.75.2
Debian Sid: 1.75.2
Ubuntu Dapper (EOLed): 1.68.1
Ubuntu Hardy: 1.73.2
Ubuntu Intrepid: 1.73.2
Ubuntu Jaunty: 1.73.2
Ubuntu Karmic: 1.75.1
Fedora 9 (EOLed): 1.73.2
Fedora 10: 1.74.0
Fedora 11: 1.74.3
Fedora rawhide: 1.75.2
Fedora Koji (12): 1.75.2
Redhat EL4: 1.65.1
OpenSUSE 11: 1.74.0
OpenSUSE factory: 1.75.2
OpenBSD 4.3: 1.68
OpenBSD 4.4: 1.68
OpenBSD 4.5: 1.68
>From Documentation/Makefile:
#
# For asciidoc ...
# -7.1.2, no extra settings are needed.
# 8.0-, set ASCIIDOC8.
#
#
# For docbook-xsl ...
# -1.68.1, set ASCIIDOC_NO_ROFF? (based on changelog from
1.73.0)
# 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
#
#
# If you had been using DOCBOOK_XSL_172 in an attempt to get rid
# of 'the ".ft C" problem' in your generated manpages, and you
# instead ended up with weird characters around callouts, try
# using ASCIIDOC_NO_ROFF instead (it works fine with ASCIIDOC8).
#
^ permalink raw reply
* Re: blame -M vs. log -p|grep -c ^+ weirdness
From: Thomas Rast @ 2009-08-11 11:56 UTC (permalink / raw)
To: git; +Cc: Björn Steinbrink
In-Reply-To: <200908111216.05131.trast@student.ethz.ch>
[-- Attachment #1: Type: Text/Plain, Size: 822 bytes --]
Thomas Rast wrote:
> git://csa.inf.ethz.ch/domjudge-public.git
Turns out this is locked down from the outside as of this writing, so
I mirrored it at
git://thomasrast.ch/domjudge.git
> git ls-files | while read f; do git blame -M -- "$f"; done |
[...]
> git log --no-merges -p upstream/2.2.. | grep '^+' | grep -v -c '^+++'
[...]
> Björn Steinbrink suggested on IRC that I use -M5 -C5 -C5 -C5, which
> indeed reduces it to
As Björn kindly pointed out once he had access to the repo, the blame
-M works for binary files too, while log -p doesn't; and
'bin/sh-static' and 'doc/logos/DOMjudgelogo.pdf' live under other
names in the upstream repository too, so sufficiently many -C blame
them on upstream instead. So that resolves the mystery.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Change mentions of "git programs" to "git commands"
From: Ori Avtalion @ 2009-08-11 11:49 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20090811125813.6117@nanako3.lavabit.com>
On 08/11/2009 06:58 AM, Nanako Shiraishi wrote:
> From: Ori Avtalion<ori@avtalion.name>
> Date: Fri, 7 Aug 2009 17:24:21 +0300
> Subject: [PATCH] Change mentions of "git programs" to "git commands"
>
> Most of the docs and printouts refer to "commands" when discussing what
> the end users call via the "git" top-level program. We should refer them
> as "git programs" when we discuss the fact that the commands are
> implemented as separate programs, but in other contexts, it is better to
> use the term "git commands" consistently.
>
> Signed-off-by: Ori Avtalion<ori@avtalion.name>
> Signed-off-by: Nanako Shiraishi<nanako3@lavabit.com>
> ---
>
Thanks Nanako!
I'm fine with the changes.
(it doesn't help much to nitpick on 'git-foo' vs 'git foo' vs 'foo' :)
You might want to consider this patch too:
diff --git a/Documentation/git-mailsplit.txt
b/Documentation/git-mailsplit.txt
index 5cc94ec..8f1b99b 100644
--- a/Documentation/git-mailsplit.txt
+++ b/Documentation/git-mailsplit.txt
@@ -3,7 +3,7 @@ git-mailsplit(1)
NAME
----
-git-mailsplit - Simple UNIX mbox splitter program
+git-mailsplit - Simple UNIX mbox splitter
SYNOPSIS
--------
^ permalink raw reply related
* Re: Unable to checkout a branch after cloning
From: Michael J Gruber @ 2009-08-11 12:04 UTC (permalink / raw)
To: Matthew Lear; +Cc: git
In-Reply-To: <4A814392.4080803@bubblegen.co.uk>
Matthew Lear venit, vidit, dixit 11.08.2009 12:10:
> Hi all,
>
> Apologies for perhaps a silly question, but I'd very much appreciate a
> little bit of assistance.
>
> I've set up a git repository on a machine accessible from the internet
> with the intention to share code with another developer. We clone the
> repository, commit changes then push back as you'd expect. The server
> runs gitweb for repository browsing. Clients are running git v1.6.0.6.
>
> When I created the initial repository I also created two additional
> branches - 'upstream' and 'custom'. The former is to act as a 'vendor
> branch' and the latter contains code specific to the custom platform
> that we're working on. The master branch contains merges from the
> upstream branch and also changes that we've made. The custom branch
> contains merges from master with custom platform specific changes.
>
> I've committed changes and on both upstream and custom branches as work
> progressed, merged them where appropriate, added tags etc and pushed
> everything to the remote repository. No problem. I can view the
> branches, tags etc in gitweb and everything looks fine.
>
> However, I can clone a new repository just fine but I'm unable to
> checkout the upstream or custom branches. After cloning, only the master
> branch is available, ie:
>
>> git checkout upstream
> error: pathspec 'upstream' did not match any file(s) known to git.
>
>> git branch -a
> * master
> origin/HEAD
> origin/master
>
> .git/config:
>
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [remote "origin"]
> url = https://mysite/git/project.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
> But the initial local repository where I work (ie created the branches,
> committed changes, tag, push etc) seems to be fine, ie
>
>> git checkout upstream
> Switched to branch "upstream"
>
>> git branch -a
> custom
> * master
> upstream
>
> .git/config:
>
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [remote "origin"]
> url = https://mysite/git/project.git
> fetch = +refs/heads/*:refs/remotes/origin/*
>
>
> Developers need to be able to clone the repository and then switch to
> the appropriate branch in order to work. However it seems that after a
> clone, only the master branch is available.
>
> Why is this?
>
> Any help would be much appreciated indeed.
If I understand you correctly you have 3 repos: the "initial" one on
which everything is as expected, the "server" one and the "new clone"
which is missing branches.
Now: How's the server one doing, i.e. what does "git ls-remote
https://mysite/git/project.git" say? I suspect that one either does not
have the branches (you haven't told us how you pushed) or in the wrong
place (remotes/).
Michael
^ permalink raw reply
* Re: bug with .git file and aliases
From: Michael J Gruber @ 2009-08-11 10:37 UTC (permalink / raw)
To: Johannes Sixt
Cc: Jeff King, Geoffrey Irving, git, Lars Hjemli, Johannes Schindelin
In-Reply-To: <4A81474C.70804@viscovery.net>
Johannes Sixt venit, vidit, dixit 11.08.2009 12:26:
> Michael J Gruber schrieb:
>> ...because it was up to the brave git-on-win folks to decide whether
>> setenv() on win would be rewritten to not use putenv() when the value is
>> "". J&J, has anything happened on the front or is it likely to? (I'm
>> sorry I can't offer help, only moral support...)
>
> Nothing has changed since. Nothing is likely to happen until there is a
> need to touch compat/setenv.c, like, for example, a test in the test suite
> that fails only on Windows...
...well, that can be taken care of quickly. Go, Jeff, go :)
Michael
^ permalink raw reply
* Re: [PATCH] gitk: parse arbitrary commit-ish in SHA1 field
From: Junio C Hamano @ 2009-08-11 5:13 UTC (permalink / raw)
To: Thomas Rast; +Cc: Paul Mackerras, git
In-Reply-To: <f7e6f82a33aa8496de81262d641953534089e980.1249742874.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> + } else {
> + if {[catch {set id [exec git rev-parse $sha1string]}]} {
"--verify", or "--no-flags --revs-only"? Examples of possible bad input
strings that you may otherwise not catch are:
master..
--merge -- a
^ permalink raw reply
* Re: [PATCH (resend) 3/3] Check return value of ftruncate call in http.c
From: Junio C Hamano @ 2009-08-11 5:13 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Jeff Lasslett
In-Reply-To: <20090811000506.c63eb8f1.rctay89@gmail.com>
Thanks; all three patches queued.
^ permalink raw reply
* Re: [RFC PATCH v2 4/4] read-tree: add --no-sparse to turn off sparse hook
From: Junio C Hamano @ 2009-08-11 5:13 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0908101838k37751fclac5c572eb042138e@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>> Hmm. I understand that the assumption is that memset(&opts, 0,
>> sizeof(opts)); should give you a sensible default, but I cannot avoid
>> noticing that "no_sparse_hook = 0" is a double negation, something to be
>> avoided...
>
> skip_sparse_hook then? :-)
Why not making the hook to be skipped by default, and pass an explicit
option to trigger the hook?
I like Dscho's other suggestion to use patterns like .gitignore instead of
using hook scripts that needs to be ported across platforms, by the way.
^ permalink raw reply
* Re: bug with .git file and aliases
From: Geoffrey Irving @ 2009-08-11 3:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git, Lars Hjemli
In-Reply-To: <alpine.DEB.1.00.0908110101110.8306@pacific.mpi-cbg.de>
On Mon, Aug 10, 2009 at 7:05 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 10 Aug 2009, Geoffrey Irving wrote:
>
>> On Mon, Jul 20, 2009 at 11:21 AM, Jeff King<peff@peff.net> wrote:
>> > On Mon, Jul 20, 2009 at 09:54:12AM -0400, Geoffrey Irving wrote:
>> >
>> >> git 1.6.3.3 has a bug related to .git file support and aliases.
>> >> Specifically, if you make an alias for status and call it from a
>> >> subdirectory, git status chdirs into the true .git dir but then
>> >> chdir's back to the wrong place in order to run the lstats for status.
>> >> The result is that git status thinks all files have disappeared.
>> >
>> > Yeah, this is a known problem. The problem is that the 'git' wrapper
>> > sets up the environment only partially when running aliases, and then
>> > the resulting command ends up confused about where the worktree is. I
>> > really don't remember the specifics, but you can probably find some
>> > discussion in the list archives. Fixing it, IIRC, required some
>> > refactoring of the setup code (which I had hoped to get to at some
>> > point, but I am way behind on my git todo list).
>>
>> The attached patch fixes the bug for me. I'll leave it to others to
>> determine whether this is a good way to fix the problem.
>
> Note that you made it particularly hard to comment on your patch by not
> granting us the wish stated in Documentation/SubmittingPatches, namely to
> inline your patch.
>
> I'll just forego inlining it myself, as I am way past my bed-time and
> cannot be bothered.
Oops. Here's the inlined patch with offset fixed, for others:
From ec47aa09e5bc8d9a8c07cca9f8ef17a9898819c1 Mon Sep 17 00:00:00 2001
From: Geoffrey Irving <irving@naml.us>
Date: Mon, 10 Aug 2009 15:59:21 -0400
Subject: [PATCH] setup.c: fix work tree setup for .git-files and aliases
When .git-files and aliases are used together, the setup machinery
gets confused and ends up with the wrong work_tree. Specifically,
git_work_tree_cfg is set to the correct value first, but set_work_tree
resets git_work_tree_cfg to the current directory, which (at least in
this case) is incorrect.
set_work_tree now detects this case by checking to see if
git_work_tree_cfg is already set. If so, it leaves git_work_tree_cfg
unchanged and instead uses the current directory to compute and return
the correct prefix (where we are relative to the work tree).
Signed-off-by: Geoffrey Irving <irving@naml.us>
---
setup.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/setup.c b/setup.c
index e3781b6..97f7eb1 100644
--- a/setup.c
+++ b/setup.c
@@ -198,13 +198,24 @@ int is_inside_work_tree(void)
static const char *set_work_tree(const char *dir)
{
char buffer[PATH_MAX + 1];
if (!getcwd(buffer, sizeof(buffer)))
die ("Could not get the current working directory");
- git_work_tree_cfg = xstrdup(buffer);
inside_work_tree = 1;
- return NULL;
+ if (!git_work_tree_cfg) {
+ git_work_tree_cfg = xstrdup(buffer);
+ return NULL;
+ } else {
+ size_t offset = strlen(git_work_tree_cfg);
+ if (memcmp(git_work_tree_cfg, buffer, offset)
+ || (buffer[offset] && buffer[offset] != '/'))
+ die ("fatal: not inside work tree (should not happen)");
+ if (!buffer[offset] || !buffer[offset+1])
+ return NULL;
+ return xstrdup(strcat(buffer + offset + 1, "/"));
+ }
}
void setup_work_tree(void)
--
1.6.3.3
> However, I think that it is necessary to comment on your patch.
>
> There is a few style issues, such as declaring offset outside of the
> block that is the only user, and there is the issue that you go out of
> your way to append a slash if you're resetting the work tree, but not when
> not resetting it.
>
> But the bigger issue is that you now broke overriding the work tree via
> the command line.
>
> The proper fix, of course, is to avoid calling the function with the wrong
> path to begin with.
I'm happy that the correct fix is obvious, and apologize for missing it.
Geoffrey
^ permalink raw reply related
* Re: [PATCH] git stash: Give friendlier error when there is nothing to apply
From: Thomas Rast @ 2009-08-11 12:09 UTC (permalink / raw)
To: Ori Avtalion; +Cc: git
In-Reply-To: <4a81559c.05ae660a.591b.010b@mx.google.com>
Ori Avtalion wrote:
> apply_stash () {
> + have_stash || die 'Nothing to apply'
> +
> git update-index -q --refresh &&
> git diff-files --quiet --ignore-submodules ||
> die 'Cannot apply to a dirty working tree, please stage your changes'
>
This needs a guard against the case where the user says
git stash apply $some_sha1
but his refs/stash is empty. This could be the case, e.g., after
mistakenly blowing away the reflog with 'git stash clear' and then
going on a recovery hunt through the unreferenced commits.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] Prevent diff machinery from examining assume-unchanged entries on worktree
From: Johannes Schindelin @ 2009-08-11 6:45 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0908101834n7cc7cfaakbf2d92fe8f32e9b1@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 661 bytes --]
Hi,
On Tue, 11 Aug 2009, Nguyen Thai Ngoc Duy wrote:
> >> +test_expect_success 'diff-index does not examine assume-unchanged entries' '
> >> + git diff-index HEAD^ -- one | grep -q 5626abf0f72e58d7a153368ba57db4c673c0e171
> >> +'
> >> +
> >> +# TODO ced_uptodate()
> >
> > What is this about?
>
> It tests "if (ce_uptodate(ce) || (ce->ce_flags & CE_VALID))" and I was
> pretty sure it hit ce_uptodate() first, so the second expression was not
> tested.
Ah. I was distracted by the "d" before the underscore.
ce_uptodate(ce) checks the time stamp amongst other things, right? How
about using test-chmtime to force an mtime mismatch?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH v2 2/4] gitignore: read from index if .gitignore is assume-unchanged
From: Johannes Schindelin @ 2009-08-11 8:12 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0908101857x7a44d3dfge20e45d24daee9bf@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3211 bytes --]
Hi,
On Tue, 11 Aug 2009, Nguyen Thai Ngoc Duy wrote:
> 2009/8/10 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Mon, 10 Aug 2009, Nguyễn Thái Ngọc Duy wrote:
> >
> >> @@ -212,27 +237,31 @@ static int add_excludes_from_file_1(const char *fname,
> >>
> >> [...]
> >>
> >> if (buf_p)
> >> *buf_p = buf;
> >> - buf[size++] = '\n';
> >> entry = buf;
> >> - for (i = 0; i < size; i++) {
> >> - if (buf[i] == '\n') {
> >> + for (i = 0; i <= size; i++) {
> >> + if (i == size || buf[i] == '\n') {
> >> if (entry != buf + i && entry[0] != '#') {
> >> buf[i - (i && buf[i-1] == '\r')] = 0;
> >> add_exclude(entry, base, baselen, which);
> >
> > Should this change not rather be a separate one?
>
> You meant a separate patch?
Yes, sorry, I meant exactly that.
> It is tied to this patch, because if bus is read from read_index_data,
> it does not have extra space for '\n' at the end.
But you could separate it out as a patch that just avoids writing to buf.
IMHO this would make following the patch series easier.
> >> @@ -241,17 +270,12 @@ static int add_excludes_from_file_1(const char *fname,
> >> }
> >> }
> >> return 0;
> >> -
> >> - err:
> >> - if (0 <= fd)
> >> - close(fd);
> >> - return -1;
> >> }
> >>
> >> void add_excludes_from_file(struct dir_struct *dir, const char *fname)
> >> {
> >> if (add_excludes_from_file_1(fname, "", 0, NULL,
> >> - &dir->exclude_list[EXC_FILE]) < 0)
> >> + &dir->exclude_list[EXC_FILE], 0) < 0)
> >
> > Could you mention in the commit message why this function does not
> > want to check the index (I _guess_ it is because this code path only
> > tries to read .git/info/exclude, but it would be better to be sure).
>
> To retain old behaviour. But I have to check its callers. Maybe we
> want to check the index too.
Yes, it would be good to illustrate in the commit message which code paths
want to check the index, and why.
> >> @@ -85,6 +85,26 @@ test_expect_success \
> >> >output &&
> >> test_cmp expect output'
> >>
> >> +test_expect_success 'setup sparse gitignore' '
> >> + git add .gitignore one/.gitignore one/two/.gitignore &&
> >> + git update-index --assume-unchanged .gitignore one/.gitignore one/two/.gitignore &&
> >> + rm .gitignore one/.gitignore one/two/.gitignore
> >> +'
> >
> > You're probably less sloppy than me; I'd have defined a variable like
> > this:
> >
> > ignores=".gitignore one/.gitignore one/two/.gitignore"
> >
> > and used it for the three calls, just to make sure that I do not fsck
> > anything up there due to fat fingers.
>
> I have slim ones :-)
Oh, don't get me wrong: my fingers are slim enough to play piano, and even
to write pretty fast on my EeePC 701.
But darn, there are days when they feel as if they were thick like a
brick.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH v2 4/4] read-tree: add --no-sparse to turn off sparse hook
From: Johannes Schindelin @ 2009-08-11 6:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vhbwforvk.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1018 bytes --]
Hi,
On Mon, 10 Aug 2009, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
> >> Hmm. I understand that the assumption is that memset(&opts, 0,
> >> sizeof(opts)); should give you a sensible default, but I cannot avoid
> >> noticing that "no_sparse_hook = 0" is a double negation, something to be
> >> avoided...
> >
> > skip_sparse_hook then? :-)
It nicely avoids the double negation, indeed.
> Why not making the hook to be skipped by default, and pass an explicit
> option to trigger the hook?
>
> I like Dscho's other suggestion to use patterns like .gitignore instead
> of using hook scripts that needs to be ported across platforms, by the
> way.
I forgot to mention that I checked dir.c to verify that
add_excludes_from_file_1() (which is static, so you'll either need to use
it in the same file, or even better, export it renaming it to something
like add_excludes_from_file_to_list()) and excluded_1() (same here)
already do a large part of what you need.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH 5/6] Let transport_helper_init() decide if a remote helper program can be used
From: Johannes Schindelin @ 2009-08-11 12:21 UTC (permalink / raw)
To: Johan Herland; +Cc: git, barkalow, gitster, benji
In-Reply-To: <1249985426-13726-6-git-send-email-johan@herland.net>
Hi,
On Tue, 11 Aug 2009, Johan Herland wrote:
> diff --git a/transport-helper.c b/transport-helper.c
> index d3ce984..de30727 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -5,6 +5,7 @@
> #include "commit.h"
> #include "diff.h"
> #include "revision.h"
> +#include "help.h"
>
> struct helper_data
> {
> @@ -279,11 +280,18 @@ static int curl_transport_push(struct transport *transport, int refspec_nr, cons
>
> int transport_helper_init(struct transport *transport)
> {
> - struct helper_data *data = xcalloc(sizeof(*data), 1);
> + struct helper_data *data;
> + struct strbuf buf = STRBUF_INIT;
> + char *cmd;
> +
> + if (!transport->remote)
> + return -1;
>
> + data = xcalloc(sizeof(*data), 1);
> if (transport->remote->foreign_vcs) {
> data->name = xstrdup(transport->remote->foreign_vcs);
> - transport->url = transport->remote->foreign_vcs;
> + if (!transport->url)
> + transport->url = transport->remote->foreign_vcs;
> } else {
> char *eom = strchr(transport->url, ':');
> if (!eom) {
IMHO it would be better to decide early if there is no vcs helper, rather
than doing all kinds of set up, only to free() the data we worked so hard
in setting up later. Something like
if (!transport->remote->foreign_vcs) {
const char *colon = transport->url ?
strchr(transport->url, ':') : NULL;
if (!colon)
return -1;
transport->remote->foreign_vcs =
xstrndup(transport->url, colon - transport->url);
}
strbuf_addf(&buf, "remote-%s", transport->remote->foreign_vcs);
if (!is_git_command_or_alias(buf.buf)) {
error("Could not find remote helper '%s'", buf.buf);
strbuf_release(&buf);
return -1;
}
> diff --git a/transport.c b/transport.c
> index 81a28bc..b7033eb 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -794,11 +794,12 @@ struct transport *transport_get(struct remote *remote, const char *url)
> ret->fetch = fetch_objs_via_rsync;
> ret->push = rsync_transport_push;
>
> - } else if (!url
> - || !prefixcmp(url, "http://")
> - || !prefixcmp(url, "https://")
> - || !prefixcmp(url, "ftp://")) {
> - transport_helper_init(ret);
> + } else if ((!url
> + || (prefixcmp(url, "git:")
> + && prefixcmp(url, "ssh:")
> + && prefixcmp(url, "file:")))
> + && !transport_helper_init(ret)) {
> + /* no-op, ret is initialized by transport_helper_init() */
>
> } else if (url && is_local(url) && is_file(url)) {
Confusing...
When is transport_helper_init(ret) called now? What is done in the code
block? Ah, nothing is done, but we usually write that this way:
; /* do nothing */
And a comment would have been in order to say that we fall back to native
Git transport, which will probably silently fail when there is no URL (I
_know_ that allowing two different ways to specify the same thing are not
only inconsistent and confusing, they lead to errors -- if not here then
somewhere else).
Also, you missed two cases mentioned in connect.c: "git+ssh" and
"ssh+git". Which brings me to another thing: I'd rather handle the known
protocols and fall back to a remote helper. The other way round seems
pretty backwards.
Sidenote: I have to admit that I find it distracting that "ret" is passed
to transport_helper_init(), either, it's probably not an "int" but an
instance of struct transport.)
Ciao,
Dscho
^ 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