* git-citool
From: arttuladhar @ 2012-02-10 17:54 UTC (permalink / raw)
To: git
When I perform commit in /git-citoo/l, the git hooks doesn't run. But for the
same repository, git hooks runs fine while using
command line git commit -a.
I wanted to get template enforcement on the /git-citool/.
Anybody have idea on recompiling the git-gui from which git-citool gets run.
I know the git-gui is built on tcl and i have the source code but i have no
experience with tck and the recompile.
Thanks,
ART
--
View this message in context: http://git.661346.n2.nabble.com/git-citool-tp7273576p7273576.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/3] Move git_version_string to help.c before diff changes
From: Junio C Hamano @ 2012-02-10 17:58 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, pclouds, Michael J Gruber
In-Reply-To: <1328891972-23695-2-git-send-email-zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> git_version_string lives in git.c. When diff.c starts to use functions
> from help.c, which in turn use git_version_string, linking against
> libgit.a will fail. This is because git_version_string is physically
> located in git.o, and this object file is not part of libgit.a.
But what is wrong about that?
If you are making the termio related code reusable and sharable by turning
the static "term_columns()" in help.o into an external symbol, there is no
reason that termio related function, which is now useful outside the
context of giving help, must stay in help.c where its life happened to
have started. In fact, "tell me how wide the terminal is" does not belong
to something called "help subsystem", no?
Wouldn't a new file, term.c or something, be a lot more suitable home for
the function you will be reusing from diff and other parts of the system?
^ permalink raw reply
* Re: A note on modern git plus ancient meld ("wrong number of arguments")
From: Jonathan Nieder @ 2012-02-10 17:59 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: David Aguilar, Jeff Epler, git, Charles Bailey
In-Reply-To: <CAHGBnuPBDO=tnoDFGOcGz4nZh9O_A803STmj7KALLuhwgf=hCg@mail.gmail.com>
Hi,
Sebastian Schuberth wrote:
> On Fri, Feb 10, 2012 at 09:23, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> + meld_version=${meld_version#GNOME }
>> + meld_version=${meld_version#* }
>
> Hmm, I might be mistaken, but aren't these string operations
> Bash-only? And AFAIK Git is striving for standard sh compatibility ...
They are widely supported in POSIX-style shells. See [1] and
Documentation/CodingGuidelines:
- We use POSIX compliant parameter substitutions and avoid bashisms;
namely:
- We use ${parameter-word} and its [-=?+] siblings, and their
colon'ed "unset or null" form.
- We use ${parameter#word} and its [#%] siblings, and their
doubled "longest matching" form.
A good way to catch these things is to try with dash or posh, which
are a little less full-featured than bash and ksh.
Thanks for looking it over.
Jonathan
[1] http://pubs.opengroup.org/onlinepubs/9699919799/
Search for "sh -".
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Theodore Tso @ 2012-02-10 18:00 UTC (permalink / raw)
To: Matthieu Moy
Cc: Theodore Tso, Junio C Hamano, Clemens Buchacher, ftpadmin,
Petr Onderka, git
In-Reply-To: <vpqbop6tyj6.fsf@bauges.imag.fr>
On Feb 10, 2012, at 11:59 AM, Matthieu Moy wrote:
>
> Is it possible to have the static HTML uploaded from another machine,
> not necessarily for each push, but e.g. for every release?
>
> I don't think anyone cares about having the very latest documentation
> there, but it would still be great to have an official place to point to
> when writing documentation on the web about such or such command.
I think that's a great idea.
I used to use that service quite a lot, so I'd be willing to push the tar balls
to kernel.org, since I have PGP key set up for kernel.org uploads (so do
other people, and if someone else wants to do it, I'm happy to let them get
all the glory :-) Most of the infrastructure to do this has been implemented,
except for the part where the tar ball gets unpacked in the correct directory.
This would satisfy the security concerns, and it wouldn't be hard, but it would
require some implementation work. Anyone have some perl hacking time to
take a look at:
git://git.kernel.org/pub/scm/utils/kup/kup.git
… and add a "UNPACK pathanme" to the kup-server file, and work with the
sysadmins at kernel.org to get it reviewed and accepted?
-- Ted
^ permalink raw reply
* git svn problem
From: Serhat Sevki Dincer @ 2012-02-10 18:15 UTC (permalink / raw)
To: git
Hi,
I am using git-svn (1.7.4.1-3 on ubuntu) to get a project. It has two
svn repositories, apparently disjoint. First half is at
http://svn.plone.org/svn/plone/plone.app.locales, and the continuation
at http://svn.plone.org/svn/collective/plone.app.locales
How can i get a nice linear git-svn repository? the second one is the
new location of the project. I am only interested in the trunks btw.
Thanks..
^ permalink raw reply
* Re: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Jakub Narebski @ 2012-02-10 18:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1uq2shwg.fsf@alter.siamese.dyndns.org>
On Fri, 10 Feb 2012, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > (with either "..., 'owner', ..." or "..., [ 'owner' ], ..." for single-key
> > filling), or
> >
> > if (project_info_needs_filled($pr, ['age', 'age_string'], \@fill_only) {
> >
> > Is it?
>
> Whatever. I am not sure what @fill_only is needed for, if the name stands
> for "only fill these fields, if this argument is empty". After all,
> doesn't the above example callsite, without ", \@fill_only" at the end,
> say "I am going to use age and age_string, so these two need to be filled"
> already?
No, the above example callsite says "Do I need to fill either 'age' or
'age_string'", and is followed by actually filling this info.
Currently the code flow WRT. project information goes like this:
git_get_projects_list()
# this fills some of project info; what is filled depends on whether
# $projects_list is a file with list of project or directory to scan
filter_forks_from_projects_list()
# this does not use project info
fill_project_list_info()
# this fills all the rest of project info on reduced list
search_projects_list(<search data>)
# this uses some of project info
After 2/5 the code goes like this:
git_get_projects_list()
# this fills some of project info; what is filled depends on whether
# $projects_list is a file with list of project or directory to scan
filter_forks_from_projects_list()
# this does not use project info
fill_project_list_info(<search data>)
# this fills the rest of project info required for search on reduced list
search_projects_list(<search data>)
# this uses some of project info
fill_project_list_info()
# this fills all the rest of project info on further reduced list
If @fill_only is empty, it means for fill_project_list_info to fill
all the data, if it is not empty it means that those fields needs to
be filled.
The code of fill_project_list_info goes like this
if (do we need to fill 'age' or 'age_string'?) {
fill 'age' and 'age_string'
}
if (do we need to fill 'desc_long' or 'descr'?) {
fill 'descr_long' and 'descr'
}
if (we are interested in 'ctags' &&
do we need to fill 'ctags'?) {
fill 'ctags'
}
...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 0/3 v2] diff --stat: use the real terminal width
From: Junio C Hamano @ 2012-02-10 18:24 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, pclouds, Michael J Gruber
In-Reply-To: <1328891972-23695-1-git-send-email-zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> - style fixes
I think I still saw at least one malformatted multi-line comments in this
round, though (I stopped looking after I saw one, so there may be others).
> - some tests for git-format-patch added
> - patches 3 and 4 squashed together, since they touch the same lines
> - graph width is limited to 40 columns, even if there's more space
Hmm.
This is what we have in the documentation.
--stat[=<width>[,<name-width>[,<count>]]]::
Generate a diffstat. You can override the default
output width for 80-column terminal by `--stat=<width>`.
The width of the filename part can be controlled by
giving another width to it separated by a comma.
Naïvely, one would expect that a "use the real terminal width" series
would be only to learn the width of the terminal and tweak its hardcoded
default "80" to that width, and change nothing else, leaving the default
for name-width to "50", which still can be overridable if needed.
But the reason somebody wants to have a wider width is more often not
because they want to see longer bars, but because they want to see long
names without truncation, so in retrospect, the order the "--stat=" option
takes its values is inconvenient. Users would more often want to tinker
with name-width than width because the latter can be auto-detected.
Which is a bit unfortunate.
In any case, the above needs to be updated to describe what the updated
logic does. Do you have documentation updates in the series?
Judging from what you wrote in the above, the updated logic is, instead of
the "naïve" version:
- auto-detect, if possible, to set the default "width" to COLUMNS instead
of hardcoded 80; and
- instead of using hardcoded 50, use width-40 as the default as the
default "name-width".
But if that is what is going on, shouldn't your "40" be "30" to retain
backward compatibility for people who work on 80-column terminals?
Or is there something more complex going on that you are not describing
here?
^ permalink raw reply
* Re: 1.7.9, libcharset missing from EXTLIBS
From: Junio C Hamano @ 2012-02-10 18:35 UTC (permalink / raw)
To: Дилян Палаузов
Cc: Ævar Arnfjörð Bjarmason, git
In-Reply-To: <4F34EF9D.8030509@aegee.org>
Дилян Палаузов <dilyan.palauzov@aegee.org> writes:
>>> What I am wondering is there are systems that need to include the header,
>>> but locale_charset() does not live in /lib/libcharset.a, in which case we
>>> cannot make HAVE_LIBCHARSET_H imply use of -lcharset.
>
> I do not understand this. If you want to use a function from
> libcharset, you have to use both #include <libcharset.h> and
> -lcharset.
You are mistaken.
The only constraint is that you have to "#include <libcharset.h>" and need
to link with the library that has locale_charset() defined. Does everybody
has that function in -lcharset, or a system you do not know have it in some
other library?
For example, Msysgit part defines HAVE_LIBCHARSET_H but it apparently does
not need -lcharset. It could be that the port is incomplete, but another
possibility is that perhaps the function is in part of libc and does not
even need -lcharset passed to the linker.
If you look at our Makefile, you see "On this platform foo() can be
obtained by linking with -lfoo, but on this other platform you need to
link with -lbar" gotchas around some libraries (e.g. ssl/crypto), and I am
wondering if this function has a similar issue.
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Konstantin Ryabitsev @ 2012-02-10 18:55 UTC (permalink / raw)
To: Theodore Tso
Cc: Matthieu Moy, Junio C Hamano, Clemens Buchacher, ftpadmin,
Petr Onderka, git
In-Reply-To: <FC56A942-EE70-48B7-A2D3-CF53A189A55E@mit.edu>
[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]
On Fri, 2012-02-10 at 13:00 -0500, Theodore Tso wrote:
> This would satisfy the security concerns, and it wouldn't be hard, but it would
> require some implementation work. Anyone have some perl hacking time to
> take a look at:
>
> git://git.kernel.org/pub/scm/utils/kup/kup.git
>
> … and add a "UNPACK pathanme" to the kup-server file, and work with the
> sysadmins at kernel.org to get it reviewed and accepted?
I have a few comments off the top of my head:
1. "kup rm" will need to be modified, as it currently only allows
deleting things that have a matching signature. The alternative
is for UNPACK to create a foo.tar.manifest file that will be
consulted upon "kup rm" to clean up any unpacked contents upon
the deletion of the source archive. Note, that there are many,
many gotchas with this solution -- e.g. .manifest should
probably contain checksums, too, as there are bound to be
conditions when two tarballs reference the same files, and you
want to make sure that you delete files matching the contents of
the old tarball, not the newer one, etc.
2. I would suggest that UNPACK ignores any directory structure in
the archive, and only copies over files matching a restricted
set of extensions (.html, .txt, .jpg, .png) into the same dir as
the original tarball. Basically, untar into a temporary
directory, then find any files matching the above set of
extensions, copy them into another temporary location, force
permissions to 0644, and then move them into the final "live"
location in the same dir with the tarball (with the
corresponding .manifest, if that solution used). There should be
logic to make sure that we never overwrite any files that have a
matching .sign file.
3. There should be some support to ensure that the unpack process
is terminated if unpacked content size reaches a certain limit,
or if it is taking too long to complete.
Best regards,
--
Konstantin Ryabitsev
Systems Administrator, Kernel.org
Montréal, Québec
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 665 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] tag: make list exclude !<pattern>
From: Tom Grennan @ 2012-02-10 18:55 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, gitster, peff
In-Reply-To: <CACsJy8DVXCLb50Vd0fTU+yNP2q7Gkcr88muHuzxq1jhfJW5Q9w@mail.gmail.com>
On Fri, Feb 10, 2012 at 01:34:26PM +0700, Nguyen Thai Ngoc Duy wrote:
>On Fri, Feb 10, 2012 at 2:43 AM, Tom Grennan <tmgrennan@gmail.com> wrote:
>> Please see the following patch which filters the tag list of "!" prefaced
>> patterns. If this is deemed desirable and correct, I'll resubmit with updated
>> documentation and unit tests.
>
>git-branch, git-tag and git-for-each-ref are in the same family. I
>think it's good to that all three commands share things, like this
>pattern matching.
Yes, git-branch and git-tag could now use a common match_patterns() but
git-for-each-ref needs some rearranging; as will: git-describe,
git-replace, git-ls-remote, git-name-rev, and git-show-branch.
If we pursue this, it may be best to first add match_patterns() to ./refs.[ch]
then incrementally modify these builtin commands to use it.
>About the '!' for exclusion, maybe it's better to move from fnmatch()
>as matching machinery to pathspec. Then when git learns negative
>pathspec [1], we have this feature for free.
>
>[1] http://thread.gmane.org/gmane.comp.version-control.git/189645/focus=190072
I have to study this more. I'm not sure that --exclude has precedence
over matches. It also looks like this would require a lot more change to
the above.
Thanks,
TomG
^ permalink raw reply
* Re: [PATCH] Remove empty ref directories while reading loose refs
From: Junio C Hamano @ 2012-02-10 19:09 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Michael Haggerty
In-Reply-To: <1328891127-17150-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> I don't think the a few extra rmdir()s from time to time at startup
> are going to cause any problems. Making delete_ref() delete empty
> directories takes more effort and probably not worth it.
That reads as a very poorly phrased excuse for not solving the problem at
the right location. Compared to all the codepaths that want to resolve
ref, delete_ref() is run much less often, and it is where the problem you
are solving (i.e. directories that have just become unnecessary are not
removed) originates, no?
Wouldn't it be just the matter of replacing two unlink_or_warn() calls in
delete_ref(), one for cleaning refs/ hierarchy and the other for cleaning
logs/ hierarcy, with a new helper that calls unlink_or_warn() and then
tries rmdir going upwards until it hits the limit, perhaps using a helper
function that refactors dir.c::remove_path() that takes an extra parameter
telling it where to stop?
^ permalink raw reply
* Re: [RFD] Rewriting safety - warn before/when rewriting published history
From: Jakub Narebski @ 2012-02-10 19:38 UTC (permalink / raw)
To: Johan Herland; +Cc: Philip Oakley, git
In-Reply-To: <CALKQrge821x7OoSekkWw7vUjP642jhbE0D9oWPcCxuuTXOqQHA@mail.gmail.com>
On Tue, 7 Feb 2012, Johan Herland wrote:
> (we are pretty much in violent agreement, so I will only comment where
> I find it necessary)
So now comes the hard part: actually implementing (well, designing and
implementing) prototypes for 'secret' trait and 'public' trait...
> On Tue, Feb 7, 2012 at 15:31, Jakub Narebski <jnareb@gmail.com> wrote:
> > Also, when thinking about different scenarios of why one would like to
> > mark commit as 'secret', we might want to be able to mark commit as
> > secret / unpublishable with respect to _subset_ of remotes, so e.g.
> > I am prevented from accidentally publishing commits marked as 'secret'
> > to public repository, or to CI/QA repository, but I can push (perhaps
> > with warning) to group repository, together with 'secret'-ness state
> > of said commit...
> >
> > ... though it wouldn't be as much 'secret' as 'confidential' ;-)
>
> Another way to achieve this would be to have a config flag to control
> whether Git checks for the 'secret' flag before pushing. This config
> flag could be set at the system/user level (to enable/disable the
> feature as a whole), at the repo level (to enable/disable it in a
> given repo), at the remote level (to enable/disable it on a given
> repo), and finally at the branch level (to enable-disable it for a
> given branch (and its upstream)). Thus you could have a .git/config
> that looked like this:
>
> [core]
> refusePushSecret = true
>
> [remote "foo"]
> refusePushSecret = false
> url = ...
> fetch = ...
>
> [branch "baz"]
> remote = foo
> merge = refs/heads/baz
> refusePushSecret = true
>
> This config would:
>
> - refuse to push 'secret' commits from branch 'baz'
> (branch.baz.refusePushSecret == true)
>
> - but allow to push other branches with 'secret' commits to remote
> 'foo' (remote.foo.refusePushSecret == false)
>
> - but refuse to push 'secret' commits to other remotes
> (core.refusePushSecret == true)
>
> (The order of precedence would be: branch config > remote config >
> repo config > user config > system config > default when unset)
You read my mind.
> I am unsure whether the 'secret'-ness of a commit should follow across
> the push, but if you do (assuming we store the 'secret' flag using
> git-notes) this is simply a matter of synchronizing the
> refs/notes/secret to the same remote.
I think it should, so that 'secret' commit would not escape by accident
via a group secret repository.
What makes it hard (I think) is that we would prefer to transfer
'secret'-ness only for pushed commits. That might be problem for notes
based implementation of 'secret' annotation and 'secret'-ness transfer...
though I guess knowing that there exist 'secret' commit with given SHA1
which we do not have and should not have is not much breach of
confidentiality. Still...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: how to determine oldest supported version of git
From: Junio C Hamano @ 2012-02-10 19:42 UTC (permalink / raw)
To: git; +Cc: Neal Kreitzinger
In-Reply-To: <7v8vkktt6y.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Neal Kreitzinger" <neal@rsss.com> writes:
>
>> What is the best way for me (a git user) to determine what is currently
>> the oldest supported version of git (the oldest version still getting
>> bugfixes)? IOW, when can I tell that my version of git is no longer
>> supported?
>
> "A note from the maintainer" only promises that the latest major release
> (as of this writing, 1.7.9) gets regular maintenance releases until the
> next major release happens.
>
> When queuing a fix to an old bug, however, I try to build a topic branch
> for that fix from as old an release as practical, in order to make sure
> that older maintenance tracks could benefit, and I do give updates for
> older maintenance tracks when able (but no promises).
> ...
> One cycle of major release development is expected to last between 8 to 10
> weeks, so keeping two stale maintenance tracks in addition to the latest
> maintenance track alive would roughly translate to 6 months shelf life for
> an ancient release.
Having said all that, I am starting to doubt what the point of all
this is.
Maybe I am being slow to come to this realization after having done this
for all these years, but Git is not like the Linux kernel, where hundreds
of companies maintain their own internal forks, e.g. out of tree drivers,
filesystem tweaks or scheduler tweaks, all tied to a specific version of
the internal API that is a rapidly moving target and cannot afford to
adjust to the bleeding edge. Also our strict no regression policy means
that it is not like an option --foo in one version of Git changes its
meaning from X to Y across version boundaries, and even if on rare
occasions we need to introduce incompatibilities to improve the system, we
give enough advance warning and execute careful migration plans to ensure
that third-parties can keep up, and the "fix at the oldest branch and
merge upwards" policy means fixes to important bugs will be in all the
maintenance tracks, including the 'master' version.
So in practical terms, once 1.7.9 is out, there is *no* practical reason
for anybody to use 1.7.8.x or anything older. The only two things people
are gaining by sticking to an older version are that (1) they do not have
a way to use new features, and that (2) they get fixes that are less
rigorously tested, because the testing happens mostly in the context of
the 'next' branch and then subsequently in the 'master' branch, and fixes
cooked in these two contexts may have unintended consequences that will
never be discovered until they are merged down to the older maintenance
tracks.
If we only released the feature releases without _any_ maintenance
releases, distros no longer have an excuse to stick to older maintenance
tracks ("For the upcoming Zesty Zebra LTS, Git will stay at 1.7.7.x and
never updated to any newer major version.") This in turn removes the need
for the third-party tools that support wider Git ecosystem to worry about
their users who are kept on very stale versions of Git by distros, because
any reasonably maintained distro will not pin their users to an ancient
version of Git. If we can change the distro's idea of what constitutes a
release of Git that is on a single maintenance track from the current
"1.7.7.3 and newer, but not anything that does not begin with 1.7.7." to
"1.7.9 and newer, but not anything that does not begin with 1.7.", that
would be a major win, I would imagine.
And dropping the maintenance tracks for older major releases may be a good
first step in that right direction.
With that in mind, the real answer to the original question in this thread
may be "the oldest supported version is the current one. stay at the
latest major release, in other words, do not even ask that question".
Thoughts?
^ permalink raw reply
* Re: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Junio C Hamano @ 2012-02-10 19:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201202101917.52908.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> If @fill_only is empty, it means for fill_project_list_info to fill
> all the data, if it is not empty it means that those fields needs to
> be filled.
That is exactly what I am questioning. Do you need "I need all these
fields to be present" and "I will fill these other fields" (which is what
@fill_only is about, no?) that is different from the former?
> The code of fill_project_list_info goes like this
>
> if (do we need to fill 'age' or 'age_string'?) {
> fill 'age' and 'age_string'
> }
> if (do we need to fill 'desc_long' or 'descr'?) {
> fill 'descr_long' and 'descr'
> }
> if (we are interested in 'ctags' &&
> do we need to fill 'ctags'?) {
> fill 'ctags'
> }
> ...
Exactly. Why do you need @fill_only at all? If you are interested in
ctags and you want to make sure ctags is available, the question you want
to ask the helper function is "Does the project structure already have
ctags field?". Why does the helper function needs to know anything else?
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Junio C Hamano @ 2012-02-10 19:51 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Clemens Buchacher, ftpadmin, Petr Onderka, git
In-Reply-To: <vpqbop6tyj6.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Clemens Buchacher <drizzd@aon.at> writes:
>>
>>> Please restore access to the following files when possible. Some sites
>>> are referencing those, including kernel.org itself:
>>>
>>> http://www.kernel.org/pub/software/scm/git/docs/git.html
>>
>> The pages reachable from this used to be living documents in that every
>> time the 'master' branch was updated at k.org, automatically a server side
>> hook script generated a new set of HTML pages and updated them.
>
> Is it possible to have the static HTML uploaded from another machine,
> not necessarily for each push, but e.g. for every release?
It would probably be possible, but I do not have that much time and
patience to sign 600+ files in the preformatted HTML tree one-by-one and
upload them using kup.
^ permalink raw reply
* Re: 1.7.9, libcharset missing from EXTLIBS
From: Dilyan Palauzov @ 2012-02-10 19:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vipjer0yn.fsf@alter.siamese.dyndns.org>
Hello,
on my system locale_charset is included in libiconv as local symbol
and thus linking with -liconv is not sufficient.
nm /usr/lib64/libiconv.so.2.5.1 | grep locale
0000000000012694 t locale_charset
whereas in libcharset the symbol is global:
nm /usr/lib64/libcharset.so.1 |grep locale
0000000000000c50 T locale_charset
looking at libiconv-1.4/lib/Makefile.in there is written
SOURCES = $(srcdir)/iconv.c $(srcdir)/../libcharset/lib/localcharset.c
$(srcdir)/relocatable.c
OBJECTS = iconv.lo localcharset.lo relocatable.lo
$(OBJECTS_EXP_@WOE32DLL@) $(OBJECTS_RES_@WOE32@)
libiconv.la : $(OBJECTS)
$(LIBTOOL_LINK) $(CC) $(LDFLAGS) $(CFLAGS) -o libiconv.la
-rpath $(libdir) -version-info $(LIBICONV_VERSION_INFO) -no-undefined
$(OBJECTS)
this means, that libiconv.la includes $(OBJECTS) and thus
libiconv-1.4/libcharset/lib/localecharset.c .
In libiconv-1.4/libcharset/lib/localecharset.c is written
#ifdef STATIC
STATIC
#endif
const char *
locale_charset (void) { ...}
and the preliminary localcharset.o still has locale_charset as global symbol:
libiconv-1.14/lib/.libs # nm localcharset.o |grep locale
0000000000000000 T locale_charset
Digging further, in libiconv-1.4/include/iconv.h some functions are
prefixed with LIBICONV_DLL_EXPORTED , which is the same as
#define LIBICONV_DLL_EXPORTED
__attribute__((__visibility__("default"))) , all the rest including
locale_charset is compiled with
__attribute__((__visibility__("hidden"))), and hence locale_charset is
not exported from libiconv.
Greetings
Dilian
----- Message from Дилян Палаузов <dilyan.palauzov@aegee.org> ---------
Date: Fri, 10 Feb 2012 02:29:24 +0100
From: Дилян Палаузов <dilyan.palauzov@aegee.org>
Subject: 1.7.9, libcharset missing from EXTLIBS
To: git@vger.kernel.org
> Hello,
>
> git 1.7.9 makes use of libcharset and /Makefile contains:
>
> ifdef HAVE_LIBCHARSET_H
> BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
> endif
>
> when building git-daemon., the compiler reports
> make V=1
> cc -I. -DUSE_LIBPCRE -pthread -DHAVE_PATHS_H -DHAVE_LIBCHARSET_H
> -DHAVE_DEV_TTY -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o
> git-daemon -L/usr/lib64 -L/lib64 daemon.o libgit.a xdiff/lib.a
> -lpcre -lz -liconv -lcrypto -pthread
> /tmp/ccvPEthi.ltrans0.ltrans.o: In function `main':
> ccvPEthi.ltrans0.o:(.text.startup+0x59): undefined reference to
> `locale_charset'
> collect2: ld returned 1 exit status
> make: *** [git-daemon] Error 1
>
>
> and the problem is, that libcharset is not used when linking. To
> solve this, please replace the above extract from /Makefile with
>
> ifdef HAVE_LIBCHARSET_H
> BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
> EXTLIBS += -lcharset
> endif
>
> Със здраве
> Дилян
----- End message from Дилян Палаузов <dilyan.palauzov@aegee.org> -----
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Ted Ts'o @ 2012-02-10 19:57 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Matthieu Moy, Junio C Hamano, Clemens Buchacher, ftpadmin,
Petr Onderka, git
In-Reply-To: <1328900154.3171.27.camel@i5.mricon.com>
How about this as something *way* simpler? Define a way of marking
the top of a particular directory hierarchy as a tree. Then the
*only* way of updating that tree is all or nothing. That is, someone
submits a signed tarball; then after the signed tarball has its
signature checked, it gets unpacked into a dir.new, and then we rename
dir to dir.old, rename dir.new to dir, and then dir.old gets removed.
That way there's no conflicts between directories that are managed via
the kup-servers PUT and DELETE commands, and those where they get
uploaded as a single tarball to create or replace a specific directory
hierarcy, or which can be deleted only as a entire directory hierarcy.
What do you think?
- Ted
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Jeff King @ 2012-02-10 20:01 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Theodore Tso, Matthieu Moy, Junio C Hamano, Clemens Buchacher,
ftpadmin, Petr Onderka, git
In-Reply-To: <1328900154.3171.27.camel@i5.mricon.com>
On Fri, Feb 10, 2012 at 01:55:54PM -0500, Konstantin Ryabitsev wrote:
> I have a few comments off the top of my head:
>
> 1. "kup rm" will need to be modified, as it currently only allows
> deleting things that have a matching signature. The alternative
> is for UNPACK to create a foo.tar.manifest file that will be
> consulted upon "kup rm" to clean up any unpacked contents upon
> the deletion of the source archive. Note, that there are many,
> many gotchas with this solution -- e.g. .manifest should
> probably contain checksums, too, as there are bound to be
> conditions when two tarballs reference the same files, and you
> want to make sure that you delete files matching the contents of
> the old tarball, not the newer one, etc.
For this particular use case, I don't know if that would be necessary.
According to Junio, previously:
The k.org site kept these files under /pub/software/scm/git/docs/. The
in-development "master" version of pages were placed directly
underneath that directory, and the documentation pages for older
versions were kept in vX.Y.Z subdirectory of that directory.
If we tweak that slightly to "all versions are kept in vX.Y.Z
subdirectory, and the root version is simply a symlink or redirect to
the latest vX.Y.Z", then there is no deletion required. The pusher is
always adding new versions, and updating a link[1].
But even if it would be sufficient for this use case, kup developers
may not want such a half-implemented scheme in their protocol.
-Peff
[1] There is a slight complication that the subdirectories live _inside_
of the root directory, so it is not implementable with a single
symlink. You could get around that with a few clever http redirects.
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Jeff King @ 2012-02-10 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Clemens Buchacher, ftpadmin, Petr Onderka, git
In-Reply-To: <7vmx8rtu3e.fsf@alter.siamese.dyndns.org>
On Thu, Feb 09, 2012 at 04:23:01PM -0800, Junio C Hamano wrote:
> It might be a workable short term workaround to redirect
>
> http://www.kernel.org/pub/software/scm/git/docs/$anything
>
> to
>
> http://schacon.github.com/git/$anything
>
> although that would not give you an access to the list of documentations
> for older releases, e.g.
>
> http://www.kernel.org/pub/software/scm/git/docs/v1.6.0/git.html
If there is interest in this, we would be happy to host the
documentation. Let me know if that is the case, and we can give it a
much better URL than schacon.github.com. However, I tend to think that
since the project is hosted[1] at kernel.org, the official documentation
site should be there as well.
-Peff
[1] Of course, git being git, it is not really hosted _anywhere_ in
particular. But convention thus far has said that the kernel.org
repository is the official one.
^ permalink raw reply
* Re: 1.7.9, libcharset missing from EXTLIBS
From: Erik Faye-Lund @ 2012-02-10 20:10 UTC (permalink / raw)
To: Dilyan Palauzov; +Cc: git
In-Reply-To: <20120210205242.Horde.Ip6kLu3yGeFPNXWKXsdW3wA@webmail.aegee.org>
2012/2/10 Dilyan Palauzov <Dilyan.Palauzov@aegee.org>:
> Hello,
>
> on my system locale_charset is included in libiconv as local symbol and thus
> linking with -liconv is not sufficient.
>
> nm /usr/lib64/libiconv.so.2.5.1 | grep locale
> 0000000000012694 t locale_charset
>
> whereas in libcharset the symbol is global:
>
> nm /usr/lib64/libcharset.so.1 |grep locale
> 0000000000000c50 T locale_charset
>
This is from the import library for libiconv we use for Git for Windows:
$ nm /mingw/lib/libiconv.dll.a | grep locale_charset
00000000 I __imp__locale_charset
00000000 T _locale_charset
Looks pretty defined to me.
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Junio C Hamano @ 2012-02-10 20:18 UTC (permalink / raw)
To: Ted Ts'o
Cc: Konstantin Ryabitsev, Matthieu Moy, Junio C Hamano,
Clemens Buchacher, ftpadmin, Petr Onderka, git
In-Reply-To: <20120210195736.GA5381@thunk.org>
Ted Ts'o <tytso@mit.edu> writes:
> How about this as something *way* simpler? Define a way of marking
> the top of a particular directory hierarchy as a tree. Then the
> *only* way of updating that tree is all or nothing. That is, someone
> submits a signed tarball; then after the signed tarball has its
> signature checked, it gets unpacked into a dir.new, and then we rename
> dir to dir.old, rename dir.new to dir, and then dir.old gets removed.
>
> That way there's no conflicts between directories that are managed via
> the kup-servers PUT and DELETE commands, and those where they get
> uploaded as a single tarball to create or replace a specific directory
> hierarcy, or which can be deleted only as a entire directory hierarcy.
>
> What do you think?
That would not work very well without changing the historical directory
structure (which I think was the point of this discussion "please keep
these stale links alive").
The toplevel index.html in the pub/software/scm/git/docs/ directory and
its pointees were the set of docs for the latest version, and older
versions were rooted at pub/software/scm/git/docs/vX.Y.Z/. Links that
point at software/scm/git/docs/git-cat-file.html still need to work, and
the path needs to be updatable without having to include the preformatted
documentation for all the historical versions in the same tarball.
^ permalink raw reply
* Re: [RFD] Rewriting safety - warn before/when rewriting published history
From: Philip Oakley @ 2012-02-10 20:19 UTC (permalink / raw)
To: Jakub Narebski, Johan Herland; +Cc: git
In-Reply-To: <201202102038.55710.jnareb@gmail.com>
From: "Jakub Narebski" <jnareb@gmail.com> Sent: Friday, February 10, 2012
7:38 PM
> On Tue, 7 Feb 2012, Johan Herland wrote:
>
>> (we are pretty much in violent agreement, so I will only comment where
>> I find it necessary)
>
> So now comes the hard part: actually implementing (well, designing and
> implementing) prototypes for 'secret' trait and 'public' trait...
It all sounds very sensible.
The one additional implemenation idea I'd like is to have, which is somewhat
at a tangent to the secrecy issue, is having some record of what was pushed
(made Public). For the sub-module case this is so that its super project can
know if its submodules are public or not. A public super project that has
'secret' sub-modules is awkward to say the least.
That's my thought anyway...
>
>> On Tue, Feb 7, 2012 at 15:31, Jakub Narebski <jnareb@gmail.com> wrote:
>
>> > Also, when thinking about different scenarios of why one would like to
>> > mark commit as 'secret', we might want to be able to mark commit as
>> > secret / unpublishable with respect to _subset_ of remotes, so e.g.
>> > I am prevented from accidentally publishing commits marked as 'secret'
>> > to public repository, or to CI/QA repository, but I can push (perhaps
>> > with warning) to group repository, together with 'secret'-ness state
>> > of said commit...
>> >
>> > ... though it wouldn't be as much 'secret' as 'confidential' ;-)
>>
>> Another way to achieve this would be to have a config flag to control
>> whether Git checks for the 'secret' flag before pushing. This config
>> flag could be set at the system/user level (to enable/disable the
>> feature as a whole), at the repo level (to enable/disable it in a
>> given repo), at the remote level (to enable/disable it on a given
>> repo), and finally at the branch level (to enable-disable it for a
>> given branch (and its upstream)). Thus you could have a .git/config
>> that looked like this:
>>
>> [core]
>> refusePushSecret = true
>>
>> [remote "foo"]
>> refusePushSecret = false
>> url = ...
>> fetch = ...
>>
>> [branch "baz"]
>> remote = foo
>> merge = refs/heads/baz
>> refusePushSecret = true
>>
>> This config would:
>>
>> - refuse to push 'secret' commits from branch 'baz'
>> (branch.baz.refusePushSecret == true)
>>
>> - but allow to push other branches with 'secret' commits to remote
>> 'foo' (remote.foo.refusePushSecret == false)
>>
>> - but refuse to push 'secret' commits to other remotes
>> (core.refusePushSecret == true)
>>
>> (The order of precedence would be: branch config > remote config >
>> repo config > user config > system config > default when unset)
>
> You read my mind.
>
>> I am unsure whether the 'secret'-ness of a commit should follow across
>> the push, but if you do (assuming we store the 'secret' flag using
>> git-notes) this is simply a matter of synchronizing the
>> refs/notes/secret to the same remote.
>
> I think it should, so that 'secret' commit would not escape by accident
> via a group secret repository.
>
> What makes it hard (I think) is that we would prefer to transfer
> 'secret'-ness only for pushed commits. That might be problem for notes
> based implementation of 'secret' annotation and 'secret'-ness transfer...
> though I guess knowing that there exist 'secret' commit with given SHA1
> which we do not have and should not have is not much breach of
> confidentiality. Still...
>
> --
> Jakub Narebski
> Poland
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2112/4801 - Release Date: 02/10/12
>
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Jeff King @ 2012-02-10 20:20 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git
In-Reply-To: <1328865494-24415-7-git-send-email-michal.kiedrowicz@gmail.com>
On Fri, Feb 10, 2012 at 10:18:12AM +0100, Michał Kiedrowicz wrote:
> The code that comares lines is based on
> contrib/diff-highlight/diff-highlight, except that it works with
> multiline changes too. It also won't highlight lines that are
> completely different because that would only make the output unreadable.
> Combined diffs are not supported but a following commit will change it.
Have you considered contributing back the enhancements to
contrib/diff-highlight? I took a look at handling multi-line changes
when I originally wrote it, but I was worried too much about failing to
match up lines properly, and ending up with too much noise in the diff.
Maybe your "don't highlight lines that are completely different" rule
helps that, though.
Do you have any examples handy? (I was hoping not to need to get a
running gitweb installation in order to see the output).
-Peff
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Jeff King @ 2012-02-10 20:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Michał Kiedrowicz, git
In-Reply-To: <201202101555.20163.jnareb@gmail.com>
On Fri, Feb 10, 2012 at 03:55:19PM +0100, Jakub Narebski wrote:
> > I think highlighting inline and side-by-side diff outputs is
> > something different from "git diff --word-diff". I find it useful for
> > people who are used to these diff formats (i.e. me :).
>
> I was thinking about *using* "git diff --word-diff" for diff refinement
> highlighting of inline (unified) and side-by-side diff...
Yeah, you might be able to get better results out of a real diff engine
(i.e., having "git diff" do the color by doing a real LCS-match) than
out of diff-highlight (which is really just a couple of simple
heuristics). OTOH, the heuristics sometimes make the result "less noisy"
because they don't find little bits of commonality, and instead
highlight only a single chunk per line.
So if somebody wanted to work on that, I'd be really curious to see if
they could get better results. It's not high enough priority for me
personally, as I find diff-highlight is "good enough".
-Peff
^ permalink raw reply
* Re: 1.7.9, libcharset missing from EXTLIBS
From: Junio C Hamano @ 2012-02-10 20:25 UTC (permalink / raw)
To: git; +Cc: dilyan.palauzov, Ævar Arnfjörð Bjarmason
In-Reply-To: <7vipjer0yn.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Дилян Палаузов <dilyan.palauzov@aegee.org> writes:
>
>>>> What I am wondering is there are systems that need to include the header,
>>>> but locale_charset() does not live in /lib/libcharset.a, in which case we
>>>> cannot make HAVE_LIBCHARSET_H imply use of -lcharset.
>>
>> I do not understand this. If you want to use a function from
>> libcharset, you have to use both #include <libcharset.h> and
>> -lcharset.
>
> You are mistaken.
>
> The only constraint is that you have to "#include <libcharset.h>" and need
> to link with the library that has locale_charset() defined.
I think the follow-ups in this thread already demonstrated why it is an
insufficient solution to make HAVE_LIBCHARSET_H imply -lcharset.
We would instead need:
ifeq ($(uname_S),MyHomeBrewLinux)
HAVE_LIBCHARSET_H = YesPlease
EXTLIBS += -lcharset
endif
or
# Define NEEDS_CHARSETLIB if you use HAVE_LIBCHARSET_H and
# need to link with -lcharset
NEEDS_CHARSETLIB =
ifeq ($(uname_S),MyHomeBrewLinux)
HAVE_LIBCHARSET_H = YesPlease
NEEDS_CHARSETLIB = YesPlease
endif
ifdef NEEDS_CHARSETLIB
EXTLIBS += -lcharset
endif
or something like that, I guess.
^ 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