* Re: linking libgit.a in C++ projects
From: Petr Baudis @ 2008-07-31 11:14 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: cte, git
In-Reply-To: <20080731105727.GF7008@dpotapov.dyndns.org>
On Thu, Jul 31, 2008 at 02:57:27PM +0400, Dmitry Potapov wrote:
> On Thu, Jul 31, 2008 at 02:53:37AM -0700, cte wrote:
> > I'm writing a git gui for OS X using cocoa/Objective-C++, and rather
> > than being lame and parsing the output the various git commands, I'm
> > using libgit.a to provide all of the needed functionality for my app.
>
> Don't do that! libgit.a is an internal library used solely to build
> git binaries. It means that its interface can be cahnged at any time.
I don't think this is that big a problem; there are applications that
are doing this already, e.g. cgit, and if you tie your application to
a particular git version by for example making git a submodule of your
source, this is pretty safe; it will just mean that you will have to
do some non-trivial porting of your code to the new interface each time
you update - but I think large changes in the interface are pretty rare
in practice by now, and there shouldn't be much on the horizon either(?).
> > However, the git source uses a few reserved C++ keywords; namely
> > 'typename', and 'new'.
>
> Because this source code are meant to be compiled by C and not by C++!
> Even if we will have real git library for other applications to use,
> it still be compiled only by C. Thus, C++ keywords are not issue.
What would be the reason to disallow C++ users? The costs aren't that
high, and (modulo, say, extern "C" { }) there should be no C-C++
compatibility issues, right?
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Pedro Melo @ 2008-07-31 11:16 UTC (permalink / raw)
To: cte; +Cc: Dmitry Potapov, git
In-Reply-To: <ac9f0f090807310410u461f5584ved74769d8452c539@mail.gmail.com>
On Jul 31, 2008, at 12:10 PM, cte wrote:
> On Thu, Jul 31, 2008 at 3:57 AM, Dmitry Potapov <dpotapov@gmail.com>
> wrote:
>> On Thu, Jul 31, 2008 at 02:53:37AM -0700, cte wrote:
>>> However, the git source uses a few reserved C++ keywords; namely
>>> 'typename', and 'new'.
>>
>> Because this source code are meant to be compiled by C and not by C+
>> +!
>> Even if we will have real git library for other applications to use,
>> it still be compiled only by C. Thus, C++ keywords are not issue.
>
[...]
> Fortunately, g++ can compile C programs and link static libraries that
> were compiled by C compilers, unless of course, they use C++ keywords.
> I don't think it is unreasonable to rename the _very few_ C++ keywords
> in git's source in the interest of allowing C++ projects to leverage
> libgit.
I think the point Dmitry was trying to make is that you should compile
libgit as C, using gcc, and then link it with your C++/Objective C code.
No patch is required to git, only to your makefile/xcode project file.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: cte @ 2008-07-31 11:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: Dmitry Potapov, git
In-Reply-To: <20080731111446.GO32184@machine.or.cz>
> What would be the reason to disallow C++ users? The costs aren't that
> high, and (modulo, say, extern "C" { }) there should be no C-C++
> compatibility issues, right?
Exactly. It works just great for me in XCode 3.1 on OS X.
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Petr Baudis @ 2008-07-31 11:20 UTC (permalink / raw)
To: Pedro Melo; +Cc: cte, Dmitry Potapov, git
In-Reply-To: <0EC13CCC-0F7B-41A0-BEB2-67E6EC8D5E37@simplicidade.org>
On Thu, Jul 31, 2008 at 12:16:45PM +0100, Pedro Melo wrote:
> I think the point Dmitry was trying to make is that you should compile
> libgit as C, using gcc, and then link it with your C++/Objective C code.
>
> No patch is required to git, only to your makefile/xcode project file.
libgit has a certain (albeit currently unofficial and non-settled) API
and the API is defined in header files that must be eatable by C++
compilers in order to do this.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: cte @ 2008-07-31 11:20 UTC (permalink / raw)
To: Pedro Melo; +Cc: Dmitry Potapov, git
In-Reply-To: <0EC13CCC-0F7B-41A0-BEB2-67E6EC8D5E37@simplicidade.org>
>> Fortunately, g++ can compile C programs and link static libraries that
>> were compiled by C compilers, unless of course, they use C++ keywords.
>> I don't think it is unreasonable to rename the _very few_ C++ keywords
>> in git's source in the interest of allowing C++ projects to leverage
>> libgit.
>
> I think the point Dmitry was trying to make is that you should compile
> libgit as C, using gcc, and then link it with your C++/Objective C code.
>
> No patch is required to git, only to your makefile/xcode project file.
The git .h files must be in your include path, and must not contain
C++ keywords in order to link against libgit.a.
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Abdelrazak Younes @ 2008-07-31 11:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Julian Phillips, Scott Chacon, Petr Baudis,
git list
In-Reply-To: <7vy73j418t.fsf@gitster.siamese.dyndns.org>
Hello,
Sorry for this irruption on this list. I am just a git user and casual
reader of this list. I thought I could share my thoughts about this as I
know a bit about document creation. Please ignore if this is not
appropriate.
Disclaimer: I am involved in LyX development, so anything I said will be
biased :-)
Junio C Hamano wrote:
> As I am not in "graphics and screencast" camp, I may probably not be able
> to offer much help improving his book, and I suspect some people on this
> list might feel the same way. But that's is Ok --- we are not dumping the
> User Manual.
IMHO, documentation is best written by users, not developer. So, again
IMHO, anything that could accommodate the _user_ for document writing
should be done. An enthusiastic user is more likely to spend time
writing documentation than a developer. For example, within the LyX
project, most writers and translator are not developer.
Asciidoc or Markdown are tools that accommodate the _developer_, not the
user. I understand that these markup language are ideally suited for in
source documentation (thought I personally much prefer Doxygen). I also
understand that launching a different application just to modify a line
or two in the user manual seems cumbersome for the developer but IMHO,
if you're serious about working on the documentation, you are not going
to change a line or two and launching an external application is no big
deal.
Now, about my shameless plug: LyX is ideally suited for structured
documentation writing :-)
Abdel.
^ permalink raw reply
* Re: [PATCH (GITK) 5/6] gitk: Fixed automatic row selection during load.
From: Paul Mackerras @ 2008-07-31 11:25 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200807271021.46661.angavrilov@gmail.com>
Alexander Gavrilov writes:
> - Switching views now actually preserves the selected commit.
> - Reloading (also Edit View) preserves the currently selected commit.
> - Initial selection does not produce weird scrolling.
>
> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
I need a more detailed explanation of the rationale for the specific
changes you have made in the changelog.
As for the patch, it mostly looks good, but I have a few comments
below.
> +proc getcommits {selid} {
> global canv curview need_redisplay viewactive
>
> initlayout
> if {[start_rev_list $curview]} {
> + reset_pending_select $selid
Is there any significance to having the call to reset_pending_select
after the start_rev_list call (other than not setting pending_select
if start_rev_list fails)? I couldn't see any. If there is then it
should be noted in a comment and/or the patch description.
> @@ -503,7 +511,7 @@ proc updatecommits {} {
> filerun $fd [list getcommitlines $fd $i $view 1]
> incr viewactive($view)
> set viewcomplete($view) 0
> - set pending_select $mainheadid
> + reset_pending_select {}
This doesn't actually change anything, right? If so then I'd prefer
the simple, direct assignment to calling a procedure that does the
assignment.
> @@ -4036,6 +4042,7 @@ proc layoutmore {} {
> }
> if {[info exists pending_select] &&
> [commitinview $pending_select $curview]} {
> + update
> selectline [rowofcommit $pending_select] 1
What does that update do? Would update idletasks be better?
Thanks,
Paul.
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Dmitry Potapov @ 2008-07-31 12:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: cte, git
In-Reply-To: <20080731111446.GO32184@machine.or.cz>
On Thu, Jul 31, 2008 at 01:14:46PM +0200, Petr Baudis wrote:
>
> I don't think this is that big a problem; there are applications that
> are doing this already, e.g. cgit, and if you tie your application to
> a particular git version by for example making git a submodule of your
> source, this is pretty safe; it will just mean that you will have to
> do some non-trivial porting of your code to the new interface each time
> you update - but I think large changes in the interface are pretty rare
> in practice by now, and there shouldn't be much on the horizon either(?).
What you see as large changes depend on how well you know git internals.
Git develops very quickly and if someone who is trying to use libgit.a
does not follow git development closely, it may happen pretty soon that
even not so big changes will become a huge problem to accomadate them.
As result, the program may stick with an old Git version, and that puts
users of this program in the situation where they cannot use their
favorite frontend with new repositories.
> What would be the reason to disallow C++ users? The costs aren't that
> high, and (modulo, say, extern "C" { }) there should be no C-C++
> compatibility issues, right?
I mean that putting extern "C" { } around should be sufficient to use
this library in C++. But I see now some current headers contains some
C++ keywords and that causes the problem. So, yes, those headers should
be corrected if they become part of external available API. I am not
sure whether it makes sense to correct them now, but there are only
three places where C++ keywords are used:
diff.h:135:extern int diff_tree_sha1(const unsigned char *old, const
diff.h:137:extern int diff_root_tree_sha1(const unsigned char *new,
object.h:38:extern const char *typename(unsigned int type);
So, the patch should not be large, and it is up to Junio to decide
what to do about it.
Dmitry
^ permalink raw reply
* Re: Merging submodules
From: H.Merijn Brand @ 2008-07-31 12:39 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Lars Noschinski
In-Reply-To: <20080731092104.1a6ce8bd@pc09.procura.nl>
On Thu, 31 Jul 2008 09:21:04 +0200, "H.Merijn Brand"
<h.m.brand@xs4all.nl> wrote:
> I will now be playing with the results a bit. I have attached the
> script, in case you might want to use it in documentation or examples.
> For now, all the mods are hardcoded. No arguments and so on.
>
> Again, Thanks!
There is a slight problem with this merging approach. The path names
are as they are/were in the submodules. In module_a, foo.pl was without
a leading module_a/ path, and now after integration, it still is. Is it
possible to rethink this whole process that integrates/merges the
several git repo's in subfolders into the current folder, as-if they
would have been in this folder in the first place?
Short summary: History made me have the current situation
4gl
4gl/fnc
4gl/fnc/.git
4gl/foo
4gl/foo/.git
:
:
4gl/zlork
4gl/zlork/.git
Where I want
4gl
4gl/.git
4gl/fnc
4gl/foo
:
4gl/zlork
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: git sequencer prototype
From: Stephan Beyer @ 2008-07-31 12:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <alpine.LSU.1.00.0807301607070.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Wed, 30 Jul 2008, Stephan Beyer wrote:
> > Johannes Schindelin wrote:
> > >
> > > > In the last patchset I mentioned the issue, that the prototype is
> > > > slow as hell. I know some bottlenecks, but I have not even tried to
> > > > change that, because this is no issue for the builtin.
> > >
> > > Why is it no issue for the builtin? Is it so much different from the
> > > prototype?
> >
> > As Sverre pointed out and as my "experiments" tried to show: the builtin
> > is just fast ;-)
>
> So why is it just so fast? Does it do things completely different than
> the shell prototype you presented?
Ah, that's the point of your question ;)
No, it's different in some minor parts, of course, but the important thing
is: it is C, not sh. That's what makes it faster.
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH (GITK) 5/6] gitk: Fixed automatic row selection during load.
From: Alexander Gavrilov @ 2008-07-31 12:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18577.41259.758690.635991@cargo.ozlabs.ibm.com>
On Thu, Jul 31, 2008 at 3:25 PM, Paul Mackerras <paulus@samba.org> wrote:
> Alexander Gavrilov writes:
>
>> - Switching views now actually preserves the selected commit.
>> - Reloading (also Edit View) preserves the currently selected commit.
>> - Initial selection does not produce weird scrolling.
>>
>> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
>
> I need a more detailed explanation of the rationale for the specific
> changes you have made in the changelog.
The rationale is that preserving the currently selected commit is more
intelligent behavior than always resetting to a preset position, and
it makes the UI feel more smooth. Also, although it is possible to
restore selection by clicking the 'back' button, it is not immediately
obvious; in fact I realized it only after reading the code.
Gitk already tried to preserve the commit in many cases, but failed
because of a conflicting change that made it select the head. Such
behavior is clearly a bug.
The Reload case is arguable, but I think that Edit View should
preserve the selection, and it uses Reload internally. It can be
resolved by adding a parameter to the function implementing Reload.
> As for the patch, it mostly looks good, but I have a few comments
> below.
>
>> +proc getcommits {selid} {
>> global canv curview need_redisplay viewactive
>>
>> initlayout
>> if {[start_rev_list $curview]} {
>> + reset_pending_select $selid
>
> Is there any significance to having the call to reset_pending_select
> after the start_rev_list call (other than not setting pending_select
> if start_rev_list fails)? I couldn't see any. If there is then it
> should be noted in a comment and/or the patch description.
It simply tries to preserve the original behavior.
>> @@ -503,7 +511,7 @@ proc updatecommits {} {
>> filerun $fd [list getcommitlines $fd $i $view 1]
>> incr viewactive($view)
>> set viewcomplete($view) 0
>> - set pending_select $mainheadid
>> + reset_pending_select {}
>
> This doesn't actually change anything, right? If so then I'd prefer
> the simple, direct assignment to calling a procedure that does the
> assignment.
I have a patch WIP that allows specifying a commit on the command line
to select instead of the head (I need it to enhance the git gui blame
UI). It makes the function somewhat more intelligent. I'll submit it
as soon as this series is sorted out.
>> @@ -4036,6 +4042,7 @@ proc layoutmore {} {
>> }
>> if {[info exists pending_select] &&
>> [commitinview $pending_select $curview]} {
>> + update
>> selectline [rowofcommit $pending_select] 1
>
> What does that update do? Would update idletasks be better?
That update forces Tk to recompute the widget dimensions. Otherwise
selectline sometimes gets all zeroes from yview, which makes it
compute really weird scrolling settings. Git-gui always does an update
before scrolling computations.
Alexander
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-31 12:48 UTC (permalink / raw)
To: git
In-Reply-To: <200807230325.04184.jnareb@gmail.com>
I will be AFK for about a week, so I don't think I'd have Git User's
Survey 2008 ready for 1.6.0 (August 10).
--
Jakub Narebski
Poland
^ permalink raw reply
* [StGIT PATCH] Do not insert an empty line before the diffstat info
From: Samuel Tardieu @ 2008-07-31 12:50 UTC (permalink / raw)
To: git; +Cc: Catalin Marinas
To make the format of stg output closer to the plain git one, do
not insert an empty line between the "---" separator and the
diffstat information.
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
---
templates/mailattch.tmpl | 1 -
templates/patchexport.tmpl | 1 -
templates/patchmail.tmpl | 1 -
3 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/templates/mailattch.tmpl b/templates/mailattch.tmpl
index 430b341..70d2df0 100644
--- a/templates/mailattch.tmpl
+++ b/templates/mailattch.tmpl
@@ -11,7 +11,6 @@ Content-Disposition: inline
%(fromauth)s%(longdescr)s
---
-
%(diffstat)s
--MIMEBOUNDARY
Content-Type: text/plain; name=%(patch)s.patch
diff --git a/templates/patchexport.tmpl b/templates/patchexport.tmpl
index e7f3481..11f2075 100644
--- a/templates/patchexport.tmpl
+++ b/templates/patchexport.tmpl
@@ -4,6 +4,5 @@ From: %(authname)s <%(authemail)s>
%(longdescr)s
---
-
%(diffstat)s
diff --git a/templates/patchmail.tmpl b/templates/patchmail.tmpl
index f5c35c2..7d4022a 100644
--- a/templates/patchmail.tmpl
+++ b/templates/patchmail.tmpl
@@ -3,6 +3,5 @@ Subject: [%(prefix)sPATCH%(version)s%(number)s] %(shortdescr)s
%(fromauth)s%(longdescr)s
---
-
%(diffstat)s
%(diff)s
^ permalink raw reply related
* [StGIT PATCH] Do not mess-up with commit message formatting when sending email
From: Samuel Tardieu @ 2008-07-31 12:50 UTC (permalink / raw)
To: git; +Cc: Catalin Marinas
The short description, which will be used as the email subject,
gets its leading and trailing whitespaces removed.
The long description only gets its trailing whitespaces removed
to preserve commit message formatting, e.g. in the case of a
ChangeLog-style commit message, as well as empty leading lines.
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
---
stgit/commands/mail.py | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index a833efc..bdc3fcc 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -401,8 +401,8 @@ def __build_message(tmpl, patch, patch_nr, total_nr, msg_id, ref_id, options):
options.edit_patches = True
descr_lines = descr.split('\n')
- short_descr = descr_lines[0].rstrip()
- long_descr = '\n'.join(descr_lines[1:]).lstrip()
+ short_descr = descr_lines[0].strip()
+ long_descr = '\n'.join([l.rstrip() for l in descr_lines[1:]]).lstrip('\n')
authname = p.get_authname();
authemail = p.get_authemail();
^ permalink raw reply related
* Re: [PATCH 2/5] Add git-sequencer documentation
From: Stephan Beyer @ 2008-07-31 12:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <alpine.LSU.1.00.0807301556140.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Hi,
Johannes Schindelin wrote:
> > > > +--onto=<base>::
> > > > + Checkout given commit or branch before sequencing.
> > > > + If you provide a branch, sequencer will make the provided
> > > > + changes on the branch, i.e. the branch will be changed.
> > >
> > > Whoa, does that mean that
> > >
> > > $ git checkout my-private-branch
> > > $ git sequencer --onto=master
> > >
> > > will change _master_?
> >
> > Exactly.
>
> /me does not like that. I could see a new porcelain doing that, but not
> the thing that will be called by rebase.
$ git sequencer --onto=master todofile
is equal to:
$ git checkout $(git rev-parse master) # detached HEAD
$ git sequencer todofile
And when successfully finished:
$ git update-ref refs/heads/master HEAD # reattach branch
Yet this seemed to be useful.
(But perhaps the name --onto is wrong...)
> > > > + --include-merges;;
> > > > + Sanity check does not fail if you have merges
> > > > + between HEAD and <mark>.
> > >
> > > It may be a commit, too, right? And why does it make sense to check that
> > > there are no merges? I mean, it is just as if I did two cherry-picks, the
> > > second with -n, and then commit --amend it. Can make tons of sense...
> >
> > I think I mean something different. With "merges" I am talking about
> > commits having more than one parent.
>
> Yes, I read "merges" the same way. My comment still stands.
If you really mean that it's the same as doing two cherry-picks and
squashing the second into the first, I don't get what your comment has
in common with merges.
If you mean squashing a merge and some cherry-picks on top of that merge
into one merge commit: that is possible. It's only checked that no merges
are *in between* currently.
In graphics: squashing
..--M--X--Y- ..-A--M--X--Y
/ /
..- ..-
is allowed is only allowed with
--include-merges
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Stephan Beyer @ 2008-07-31 13:01 UTC (permalink / raw)
To: Abdelrazak Younes
Cc: git, Johannes Schindelin, Julian Phillips, Scott Chacon,
Petr Baudis
In-Reply-To: <4891A0D0.6060503@lyx.org>
Hi,
Abdelrazak Younes wrote:
> Please ignore if this is not appropriate.
Well, so I should've ignored, but I think this is worth some correction.
> Asciidoc or Markdown are tools that accommodate the _developer_, not the
> user. I understand that these markup language are ideally suited for in
> source documentation (thought I personally much prefer Doxygen).
http://www.methods.co.nz/asciidoc/ says
``AsciiDoc is a text document format for writing short documents,
articles, books and UNIX man pages. AsciiDoc files can be translated to
HTML and DocBook markups using the asciidoc(1) command.''
http://daringfireball.net/projects/markdown/ says
``Markdown is a text-to-HTML conversion tool for web writers. Markdown
allows you to write using an easy-to-read, easy-to-write plain text
format, then convert it to structurally valid XHTML (or HTML).''
So those are not suited for in-source documentation.
They're "lightweight" markup for documentation, very easy to read and somehow
easy to write for non-developers.
The user manual can give you an impression:
http://repo.or.cz/w/git.git?a=blob;f=Documentation/user-manual.txt
I think, this is easier than LyX for users and developers..
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Boaz Harrosh @ 2008-07-31 13:04 UTC (permalink / raw)
To: cte; +Cc: git
In-Reply-To: <ac9f0f090807310253v1d97e2a1n4ddf34aa4fdc79f0@mail.gmail.com>
cte wrote:
> I'm writing a git gui for OS X using cocoa/Objective-C++, and rather
> than being lame and parsing the output the various git commands, I'm
> using libgit.a to provide all of the needed functionality for my app.
> However, the git source uses a few reserved C++ keywords; namely
> 'typename', and 'new'. So, I was wondering if it is worth submitting a
> patch to fix these issues... I'm asking because I'm new to the whole
> open source thing, and I don't want to get yelled at by the git
> maintainers for submitting stupid patches that no one in their right
> mind would accept :)
>
> Thanks!
> --
The practice of avoiding C++ keywords from public C headers is
very welcome. You should send a patch and try to push it.
That said the problem can be easily avoided.
Produce a C file and header that defines some stable API to your
GUI application, that does not expose any git internal headers.
Then compile that, say git_api.c, with C compiler in Makefile
and extern "C" link that file to your C++ application. This will
completely insulate you from any git code.
This could also solve the other problem of API changing, only
the git_api.c need change, your outer GUI code stays the same.
And if you do all that maybe you can submit it for inclusion
as a: somewhat stable high-level library, for developers.
Ala git-dev
Cheers
Boaz
^ permalink raw reply
* Re: Merging submodules
From: Petr Baudis @ 2008-07-31 13:06 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <20080731143955.034f0577@pc09.procura.nl>
On Thu, Jul 31, 2008 at 02:39:55PM +0200, H.Merijn Brand wrote:
> On Thu, 31 Jul 2008 09:21:04 +0200, "H.Merijn Brand"
> <h.m.brand@xs4all.nl> wrote:
>
> > I will now be playing with the results a bit. I have attached the
> > script, in case you might want to use it in documentation or examples.
> > For now, all the mods are hardcoded. No arguments and so on.
> >
> > Again, Thanks!
>
> There is a slight problem with this merging approach. The path names
> are as they are/were in the submodules. In module_a, foo.pl was without
> a leading module_a/ path, and now after integration, it still is. Is it
> possible to rethink this whole process that integrates/merges the
> several git repo's in subfolders into the current folder, as-if they
> would have been in this folder in the first place?
I would suggest re-reading Santi's suggestions:
> You have, basically, two possibilities:
>
> 1) Add the module_# as submodules:
> http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
> http://git.or.cz/gitwiki/GitSubmoduleTutorial
> 2) Add the submodules as subtrees (as gitk and git-gui in git.git)
> http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
I think the latter is specifically what you want.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: Merging submodules
From: Santi Béjar @ 2008-07-31 13:17 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <20080731143955.034f0577@pc09.procura.nl>
On Thu, Jul 31, 2008 at 14:39, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
>
> There is a slight problem with this merging approach. The path names
> are as they are/were in the submodules. In module_a, foo.pl was without
> a leading module_a/ path, and now after integration, it still is. Is it
> possible to rethink this whole process that integrates/merges the
> several git repo's in subfolders into the current folder, as-if they
> would have been in this folder in the first place?
If you want to have module_a/foo.pl in the old commits you will need
to rewrite the history, either with "git filter-branch" or
fast-export/import, or importing again.
For the new commits it depends on how you would do them. If you modify
and commit without these module subfolders (without the module_a/.git
as your git-merge-mods does) then the new commits will have
module_a/foo.pl. So at the end you will have a merge of all the mods
(using the subtree strategy), and after that you will have a single
project.
All depends in a few factors, if you have published the history (for
the rewriting), if you want to have the module_# as independent
projects (this way you can merge them in other projects),...
Santi
^ permalink raw reply
* [PATCH] git-name-rev: allow --name-only in combination with --stdin
From: Pieter de Bie @ 2008-07-31 13:20 UTC (permalink / raw)
To: Git Mailinglist, Johannes Schindelin; +Cc: Pieter de Bie
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
---
Or was there a specific reason not to allow this?
Documentation/git-name-rev.txt | 3 +--
builtin-name-rev.c | 10 ++++++++--
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index 6e77ab1..c8a72dd 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation/git-name-rev.txt
@@ -38,8 +38,7 @@ OPTIONS
Instead of printing both the SHA-1 and the name, print only
the name. If given with --tags the usual tag prefix of
"tags/" is also omitted from the name, matching the output
- of 'git-describe' more closely. This option
- cannot be combined with --stdin.
+ of 'git-describe' more closely.
--no-undefined::
Die with error code != 0 when a reference is undefined,
diff --git a/builtin-name-rev.c b/builtin-name-rev.c
index 85612c4..0536af4 100644
--- a/builtin-name-rev.c
+++ b/builtin-name-rev.c
@@ -266,8 +266,14 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
if (!name)
continue;
- fwrite(p_start, p - p_start + 1, 1, stdout);
- printf(" (%s)", name);
+ if (data.name_only) {
+ fwrite(p_start, p - p_start + 1 - 40, 1, stdout);
+ printf(name);
+ }
+ else {
+ fwrite(p_start, p - p_start + 1, 1, stdout);
+ printf(" (%s)", name);
+ }
p_start = p + 1;
}
}
--
1.6.0.rc1.163.gc85c5.dirty
^ permalink raw reply related
* Re: markdown 2 man, was Re: Git Community Book
From: Abdelrazak Younes @ 2008-07-31 14:13 UTC (permalink / raw)
To: Stephan Beyer
Cc: git, Johannes Schindelin, Julian Phillips, Scott Chacon,
Petr Baudis
In-Reply-To: <20080731130101.GC18106@leksak.fem-net>
Stephan Beyer wrote:
> Hi,
>
> Abdelrazak Younes wrote:
>
>> Please ignore if this is not appropriate.
>>
>
> Well, so I should've ignored, but I think this is worth some correction.
>
Thanks for the corrections :-)
> They're "lightweight" markup for documentation, very easy to read and somehow
> easy to write for non-developers.
> The user manual can give you an impression:
> http://repo.or.cz/w/git.git?a=blob;f=Documentation/user-manual.txt
>
> I think, this is easier than LyX for users and developers..
>
Well, easier for short document writing maybe, better suited I don't
think so, at least if you want to keep track of contents, structure,
links, references, citations, etc. Bug again this is IMHO.
Abdel.
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Abdelrazak Younes @ 2008-07-31 14:33 UTC (permalink / raw)
To: git; +Cc: git, Johannes Schindelin, Julian Phillips, Scott Chacon,
Petr Baudis
In-Reply-To: <20080731130101.GC18106@leksak.fem-net>
Stephan Beyer wrote:
> They're "lightweight" markup for documentation, very easy to read and somehow
> easy to write for non-developers.
> The user manual can give you an impression:
> http://repo.or.cz/w/git.git?a=blob;f=Documentation/user-manual.txt
>
> I think, this is easier than LyX for users and developers..
I just had a look at the user manual and, well unless you have a special
emacs mode or whatever that can automate the markup tag insertion, I
wonder how can anybody think that writing with this markup language is
easier than within LyX, really (genuine question, not sarcasm).
Abdel.
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Dmitry Potapov @ 2008-07-31 14:44 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: cte, git
In-Reply-To: <4891B872.3040707@panasas.com>
On Thu, Jul 31, 2008 at 04:04:50PM +0300, Boaz Harrosh wrote:
>
> Produce a C file and header that defines some stable API to your
> GUI application, that does not expose any git internal headers.
> Then compile that, say git_api.c, with C compiler in Makefile
> and extern "C" link that file to your C++ application. This will
> completely insulate you from any git code.
While the idea of creating of such a wrapper makes sense, it may not
easy to implement properly in all cases, because some git functions
do not free allocated memory as they rely on this memory being free
at exit. There is a problem with die() as it is not enough to longjmp
from it, you have to free all resources that were allocated (such as
open files, memory). Thus writing a full functional library, which
will not leak resources, is not an easy task. Of course, some of Git
function can be used easily without risk that your application will
leak resources.
Dmitry
^ permalink raw reply
* Re: Merging submodules
From: H.Merijn Brand @ 2008-07-31 15:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <20080731130626.GQ32184@machine.or.cz>
On Thu, 31 Jul 2008 15:06:26 +0200, Petr Baudis <pasky@suse.cz> wrote:
> On Thu, Jul 31, 2008 at 02:39:55PM +0200, H.Merijn Brand wrote:
> > On Thu, 31 Jul 2008 09:21:04 +0200, "H.Merijn Brand"
> > <h.m.brand@xs4all.nl> wrote:
> >
> > > I will now be playing with the results a bit. I have attached the
> > > script, in case you might want to use it in documentation or examples.
> > > For now, all the mods are hardcoded. No arguments and so on.
> > >
> > > Again, Thanks!
> >
> > There is a slight problem with this merging approach. The path names
> > are as they are/were in the submodules. In module_a, foo.pl was without
> > a leading module_a/ path, and now after integration, it still is. Is it
> > possible to rethink this whole process that integrates/merges the
> > several git repo's in subfolders into the current folder, as-if they
> > would have been in this folder in the first place?
>
> I would suggest re-reading Santi's suggestions:
>
> > You have, basically, two possibilities:
> >
> > 1) Add the module_# as submodules:
> > http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
> > http://git.or.cz/gitwiki/GitSubmoduleTutorial
> > 2) Add the submodules as subtrees (as gitk and git-gui in git.git)
> > http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
>
> I think the latter is specifically what you want.
I got stuck in that process, as the new repo thinks all the files from
the sub-folders belong to the top-folder: After this process, there are
a lot of files from subfolder include in the "new" top-level folder.
--8<--- git-join.sh
#!/bin/sh
export MODS
MODS="include fnc"
MODS="$MODS i00f000 i99f000"
MODS="$MODS l00m000 l01f000 l02f000 l03f000 l06f000 l90z000"
MODS="$MODS rpt"
MODS="$MODS leerpl mutbev prtabel tabellen zoomen"
echo "Creating merge environment"
rm -rf new
mkdir new
cd new
echo "Recovering original repo's"
tbz -s -x ../lep4gl-git
echo "Initializing new repo"
git init
for mod in $MODS ; do
echo "Merging $mod ..."
git remote add -f B$mod $mod
git merge -s ours --no-commit B$mod/master
git read-tree --prefix=$mod/ -u B$mod/master
git commit -m "Merge $mod as our subdirectory"
git pull -s subtree B$mod master
done
echo Done
-->8---
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Miklos Vajna @ 2008-07-31 15:09 UTC (permalink / raw)
To: Abdelrazak Younes
Cc: git, Johannes Schindelin, Julian Phillips, Scott Chacon,
Petr Baudis
In-Reply-To: <4891CD34.1070308@lyx.org>
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
On Thu, Jul 31, 2008 at 04:33:24PM +0200, Abdelrazak Younes <younes@lyx.org> wrote:
> I just had a look at the user manual and, well unless you have a special
> emacs mode or whatever that can automate the markup tag insertion, I wonder
> how can anybody think that writing with this markup language is easier than
> within LyX, really (genuine question, not sarcasm).
People usually find it easy to contribute to a wiki, due to its easy
markup language.
asciidoc's markup is configurable, but the default one is really similar
to a wiki syntax, so at the end, people find it easy, including myself.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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