* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Junio C Hamano @ 2008-07-28 20:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0807282008470.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Well, I have to say that the workflow is a bit backwards if the person who
> _publishes_ the thing is the one saying "Ooops, my version no goodie,
> other version please, but so that pull still works".
>
> I would have expected the one who has the good version to make the choice.
That reminds me of:
http://thread.gmane.org/gmane.comp.version-control.git/89178
to one of whose messages I sent a response today.
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Sverre Rabbelier @ 2008-07-28 20:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jeff King, Git Mailinglist, Miklos Vajna
In-Reply-To: <7vproxrcvu.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 22:07, Junio C Hamano <gitster@pobox.com> wrote:
> That reminds me of:
>
> http://thread.gmane.org/gmane.comp.version-control.git/89178
>
> to one of whose messages I sent a response today.
Mhhh, but the proposed strategy there was in response to the 'insane'
git-merge-theirs version, not to the 'exact opposite of
git-merge-ours' that I refer to now, yes? Do you have any particular
feelings wrt to that?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Junio C Hamano @ 2008-07-28 20:20 UTC (permalink / raw)
To: sverre
Cc: Junio C Hamano, Johannes Schindelin, Jeff King, Git Mailinglist,
Miklos Vajna
In-Reply-To: <bd6139dc0807281310j16b4ef5alf9738ec0f3270ba0@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> On Mon, Jul 28, 2008 at 22:07, Junio C Hamano <gitster@pobox.com> wrote:
>> That reminds me of:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/89178
>>
>> to one of whose messages I sent a response today.
>
> Mhhh, but the proposed strategy there was in response to the 'insane'
> git-merge-theirs version, not to the 'exact opposite of
> git-merge-ours' that I refer to now, yes?
No.
^ permalink raw reply
* Re: git submodules
From: Nigel Magnay @ 2008-07-28 20:23 UTC (permalink / raw)
To: Pierre Habouzit, Git ML
In-Reply-To: <20080728162003.GA4584@artemis.madism.org>
>
> While trying to sum up some things I'd like submodules to do, and things
> like that, I came to ask myself why the heck we were doing things the
> way we currently do wrt submodules.
>
> This question is related to the `.git` directories of submodules. I
> wonder why we didn't chose to use a new reference namespace
> (refs/submodules/$path/$remote/$branch).
>
I'm maybe being a bit slow - what would be the contents of (say)
refs/submodules/moduleA/remotes/origin/master ? The ref
that's currently in moduleA/.git/refs/remotes/origin/master ?
> This would have the net benefit that most of the plumbing tasks would be
> easier if they have to deal with submodules, because they aren't in this
> uncomfortable situation where they have to recurse into another git
> directory to know what to do.
>
> It also has the absolutely nice property to share objects, so that
> projects that replaced a subdirectory with a submodule don't see their
> checkouts grow too large.
>
Ah.. are you meaning that the top-level repository contains all the
commits in all the submodules?
> We probably still want submodules to act like plain independant git
> repositories, but one can still *fake* that this way: submodules have
> only a .git/config file (also probably an index and a couple of things
> like that, but that's almost a different issue for what I'm considering
> now) that has the setting:
>
> [core]
> submodule = true
>
> This could make all the builtins look for the real $GIT_DIR up, which in
> turn gives the submodule "name". Then, for this submodule, every
> reference, remote name, ... would be virtualized using the
> "remote/$submodule_name" prefix. IOW, in a submodule "some/sub/module"
> the branch "origin/my/topic/branch" is under:
> refs/submodules/some/sub/module/origin/my/topic/branch
> <-- submod. --><-- submod. --><-- --><-- branch -->
> namespace path/name remote
> Note that this doesn't mean that we must rip out .gitmodules, because
> it's needed to help splitting the previous reference name properly, and
> for bootstrapping purposes.
>
I was thinking a bit about submodules (because of the earlier
discussions about submodule update only pulling from origin, and the
associated difficulties) and started wondering if the best place for
the git repository for (say) submoduleA was really
<...>/submoduleA/.git/<> and not (say) something like
.git/submodules/submoduleA/<>. This would be nicer for people trying
to pull revisions from you because they could easily find submodule
repositories regardless or not of whether they currently exist in your
WC.
I got as far as looking at discussions around .gitlink but ran out of
avaiable time.
>
> Having that, one can probably extend most of the porcelains in _very_
> straightforward ways. For example, a local topic branch `topic` would be
> the union of the supermodule `topic` branch, and all the
> `refs/submodules/$names/topic` ones.
>
> Most importantly, it would help implementing that tries to make your
> submodules stay _on branch_. One irritating problem with submodules, is
> that when someone else commited, and that you git submodule update,
> you're on a detached head. Absolutely horrible. If you see your current
> branch (assume it's master), then when you do that, you would update
> your `refs/submodules/$name/master` references instead and keep the
> submodule HEADs `on branch`. Of course we can _probably_ hack something
> together along those lines with the current setup, but it would be _so_
> much more convenient this way...
>
For me, if I'm on heads/blah in the superproject, I probably want to
be on heads/blah in *all* submodules. But that's maybe just me.
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Sverre Rabbelier @ 2008-07-28 20:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jeff King, Git Mailinglist, Miklos Vajna
In-Reply-To: <7vljzlrca9.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 22:20, Junio C Hamano <gitster@pobox.com> wrote:
> "Sverre Rabbelier" <alturin@gmail.com> writes:
>> Mhhh, but the proposed strategy there was in response to the 'insane'
>> git-merge-theirs version, not to the 'exact opposite of
>> git-merge-ours' that I refer to now, yes?
>
> No.
Nanako Shiraishi's patch was not in response to the "git-merge-theirs"
thread, or I am missing something here....?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: gitk crashes when quitting gitk while it is is reading commits (was Re: gitk crashing on Windows.)
From: Eric Raible @ 2008-07-28 20:31 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, paulus
In-Reply-To: <E7C7B8BA-6050-40DE-917C-200EAE9CA6E8@zib.de>
On Mon, Jul 28, 2008 at 12:18 PM, Steffen Prohaska <prohaska@zib.de> wrote:
> I don't think so. The error Jurko reported might be the same error
> that was reported earlier and filed as issue 125:
>
> http://code.google.com/p/msysgit/issues/detail?id=125
I agree - sounds the same.
> I don't think the problem is Windows-specific. At least on Mac I am
> seeing similar problems. When I hit CTRL-q while gitk is still reading
> the commits, it crashes with as segfault.
>
> Steffen
I also agree that it easily could be a generic problem.
But the fact remains that it used to reliably crash on me,
and no longer does with more recent source.
But I still can't find a relevant commit, which makes me
feel like I'm a) still a complete git newbie, or b) imagining
the whole thing.
- Eric
^ permalink raw reply
* Re: [Fundamental problem with relative system paths] [PATCH 2/2] run-command (Windows): Run dashless "git <cmd>"
From: Johannes Sixt @ 2008-07-28 20:37 UTC (permalink / raw)
To: Steffen Prohaska
Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <1217224228-31303-2-git-send-email-prohaska@zib.de>
Zitat von Steffen Prohaska <prohaska@zib.de>:
> This might solve a fundamental problem we have with the
> computation of system directories based on relative paths
> in combination with the new gitexecpath 'libexec/git-core'.
> The problem is that the program 'git' is hardlinked to
> directories with different depth. It is either used as
> 'bin/git' (1 directory) or as 'libexec/git-core/git-*'
> (2 directories). Thus, using the same relative path
> in system_path() yields different results when starting from the
> two locations. I recognized the problem because /etc/gitconfig
> is no longer be read.
>
> The patch below might fix the problem by always calling 'bin/git'
> for builtin commands. The computation in system_path() would
> always start from 'bin' and thus yields predictable results. I
> am not sure however if it fully solves the problem because other
> code paths might run the dashed forms directly.
This paragraph should go into the commit message.
> I think the only way to verify correctness would be to stop
> installing the dashed forms for builtins. If they were not
> installed they could not be called. The only entry point for all
> builtins would be 'bin/git'. I don't think we want to stop
> installing the dashed forms right away.
>
> So what shall we do?
Your patches make a lot of sense.
> -- 8< --
> We prefer running the dashless form, so we should use it in
> MinGW's start_command(), too.
>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
-- Hannes
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-28 20:55 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git ML
In-Reply-To: <320075ff0807281323l51bb6478j30e3e4c490974a70@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4157 bytes --]
On Mon, Jul 28, 2008 at 08:23:39PM +0000, Nigel Magnay wrote:
> >
> > While trying to sum up some things I'd like submodules to do, and things
> > like that, I came to ask myself why the heck we were doing things the
> > way we currently do wrt submodules.
> >
> > This question is related to the `.git` directories of submodules. I
> > wonder why we didn't chose to use a new reference namespace
> > (refs/submodules/$path/$remote/$branch).
> >
> I'm maybe being a bit slow - what would be the contents of (say)
> refs/submodules/moduleA/remotes/origin/master ? The ref
> that's currently in moduleA/.git/refs/remotes/origin/master ?
Yes.
> > It also has the absolutely nice property to share objects, so that
> > projects that replaced a subdirectory with a submodule don't see their
> > checkouts grow too large.
> >
>
> Ah.. are you meaning that the top-level repository contains all the
> commits in all the submodules?
Yes. My suggestion is to share all the references, prefixing the
submodules ones with a distinct prefix (namely
refs/submodules/$name-of-the-submodule) to avoid any conflict, and share
the object store. You get coherent reflogs and stuff like that for free
on top.
> I was thinking a bit about submodules (because of the earlier
> discussions about submodule update only pulling from origin, and the
> associated difficulties) and started wondering if the best place for
> the git repository for (say) submoduleA was really
> <...>/submoduleA/.git/<> and not (say) something like
> ..git/submodules/submoduleA/<>. This would be nicer for people trying
> to pull revisions from you because they could easily find submodule
> repositories regardless or not of whether they currently exist in your
> WC.
That too indeed (the "easier to clone" bit). OTOH, I don't like the
.git/submodules idea a lot, if you mean to put a usual $GIT_DIR layout
inside of it. With what I propose, you find objects for all your
super/sub-modules in the usual store, which eases many things.
Especially, I believe that when you replace a subdirectory of a project
with a submodule, git-blame could benefit quite a lot from this to be
able to glue history back through the submodule limits, without having
to refactor a _lot_ of code: it would merely have to dereference so
called "gitlinks" to the commit then tree, hence twice, and just do its
usual work, with your proposal, we still rely on having to recurse in
subdirectories which requires more boilerplate code.
> I got as far as looking at discussions around .gitlink but ran out of
> avaiable time.
I shall say I never followed them, as I was uninterested with such
subjects before, (but now is as I use them at work). But I don't recall
such an idea to have been discussed at all, so...
> > Having that, one can probably extend most of the porcelains in _very_
> > straightforward ways. For example, a local topic branch `topic` would be
> > the union of the supermodule `topic` branch, and all the
> > `refs/submodules/$names/topic` ones.
> >
> > Most importantly, it would help implementing that tries to make your
> > submodules stay _on branch_. One irritating problem with submodules, is
> > that when someone else commited, and that you git submodule update,
> > you're on a detached head. Absolutely horrible. If you see your current
> > branch (assume it's master), then when you do that, you would update
> > your `refs/submodules/$name/master` references instead and keep the
> > submodule HEADs `on branch`. Of course we can _probably_ hack something
> > together along those lines with the current setup, but it would be _so_
> > much more convenient this way...
> >
>
> For me, if I'm on heads/blah in the superproject, I probably want to
> be on heads/blah in *all* submodules. But that's maybe just me.
Yes, that's what I tried to say, so if it wasn't clear, it's exactly
what I would like to do/have.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-28 20:59 UTC (permalink / raw)
To: Nigel Magnay, Git ML
In-Reply-To: <20080728205545.GB10409@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]
On Mon, Jul 28, 2008 at 08:55:45PM +0000, Pierre Habouzit wrote:
> On Mon, Jul 28, 2008 at 08:23:39PM +0000, Nigel Magnay wrote:
> That too indeed (the "easier to clone" bit). OTOH, I don't like the
> .git/submodules idea a lot, if you mean to put a usual $GIT_DIR layout
> inside of it. With what I propose, you find objects for all your
> super/sub-modules in the usual store, which eases many things.
> Especially, I believe that when you replace a subdirectory of a project
> with a submodule, git-blame could benefit quite a lot from this to be
> able to glue history back through the submodule limits, without having
> to refactor a _lot_ of code: it would merely have to dereference so
> called "gitlinks" to the commit then tree, hence twice, and just do its
> usual work, with your proposal, we still rely on having to recurse in
> subdirectories which requires more boilerplate code.
And of _course_ this is also true for git-log, which is like 10x as
important for me (like I don't remember if I used git-blame this year,
whereas I used git-log in the last 10 minutes ;p)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [ANN] ditz 0.4 released
From: William Morgan @ 2008-07-28 20:26 UTC (permalink / raw)
To: Git Mailing List
Ditz version 0.4 has been released! This release features improved git
integration.
http://ditz.rubyforge.org
Ditz is a simple, light-weight distributed issue tracker designed to work with
distributed version control systems like git, darcs, Mercurial, and Bazaar. It
can also be used with centralized systems like SVN.
Ditz maintains an issue database directory on disk, with files written in a
line-based and human-editable format. This directory can be kept under version
control, alongside project code.
Ditz provides a simple, console-based interface for creating and updating the
issue database file, and some rudimentary HTML generation capabilities for
producing world-readable status pages. It currently offers no central public
method of bug submission.
Synopsis:
# set up project. creates the bugs.yaml file.
1. ditz init
2. ditz add-release
# add an issue
3. ditz add
# where am i?
4. ditz status
5. ditz todo (or simply "ditz")
# do work
6. write code
7. ditz close <issue-id>
8. commit
9. goto 3
# finished!
10. ditz release <release-name>
Changes:
## 0.4 / 2008-07-27
* bugfix: HOME environment variable now correctly detected on windows
* hooks loaded from both home directory and project directory
* added bash shell completion
* plugin architecture for tighter SCM integration, etc
* 'ditz grep' should also grep against comments, log messages, etc
* added man page
* removed ditz-convert-from-monolith
* lots of HTML output tweaking
--
William <wmorgan-git@masanjin.net>
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Junio C Hamano @ 2008-07-28 21:16 UTC (permalink / raw)
To: sverre
Cc: Junio C Hamano, Johannes Schindelin, Jeff King, Git Mailinglist,
Miklos Vajna
In-Reply-To: <bd6139dc0807281324k38198fffwd3b586394b354ed2@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> On Mon, Jul 28, 2008 at 22:20, Junio C Hamano <gitster@pobox.com> wrote:
>> "Sverre Rabbelier" <alturin@gmail.com> writes:
>>> Mhhh, but the proposed strategy there was in response to the 'insane'
>>> git-merge-theirs version, not to the 'exact opposite of
>>> git-merge-ours' that I refer to now, yes?
>>
>> No.
>
> Nanako Shiraishi's patch was not in response to the "git-merge-theirs"
> thread, or I am missing something here....?
The quoted sentence by me in that message was after I explained why "per
hunk theirs" aka "-Xtheirs" was not such a great idea I further went on to
say "by the way, '-s theirs' is even worse and here is why".
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Junio C Hamano @ 2008-07-28 21:35 UTC (permalink / raw)
To: sverre
Cc: Junio C Hamano, Johannes Schindelin, Jeff King, Git Mailinglist,
Miklos Vajna
In-Reply-To: <7vvdyppv4c.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Sverre Rabbelier" <alturin@gmail.com> writes:
>
>> On Mon, Jul 28, 2008 at 22:20, Junio C Hamano <gitster@pobox.com> wrote:
>>> "Sverre Rabbelier" <alturin@gmail.com> writes:
>>>> Mhhh, but the proposed strategy there was in response to the 'insane'
>>>> git-merge-theirs version, not to the 'exact opposite of
>>>> git-merge-ours' that I refer to now, yes?
>>>
>>> No.
>>
>> Nanako Shiraishi's patch was not in response to the "git-merge-theirs"
>> thread, or I am missing something here....?
>
> The quoted sentence by me in that message was after I explained why "per
> hunk theirs" aka "-Xtheirs" was not such a great idea I further went on to
> say "by the way, '-s theirs' is even worse and here is why".
Heh, I ended up doing the "digging" myself. The quote came from this:
http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89024
and "tried not to sound too negative" there refers to:
http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89021
which _was_ about the "-Xtheirs", not "-s theirs".
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Sverre Rabbelier @ 2008-07-28 21:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jeff King, Git Mailinglist, Miklos Vajna
In-Reply-To: <7vr69dpu9i.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 23:35, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>> The quoted sentence by me in that message was after I explained why "per
>> hunk theirs" aka "-Xtheirs" was not such a great idea I further went on to
>> say "by the way, '-s theirs' is even worse and here is why".
Aaah, ok, now I see where my confusion came from. Thank you for
clarifying that. Then remains the question, what to tell those that
want '-s theirs' not to keep track of their changes, but to keep a
fast-forwardable master?
> Heh, I ended up doing the "digging" myself. The quote came from this:
>
> http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89024
>
> and "tried not to sound too negative" there refers to:
>
> http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89021
>
> which _was_ about the "-Xtheirs", not "-s theirs".
Understood, it makes sense now.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git submodules
From: Avery Pennarun @ 2008-07-28 21:40 UTC (permalink / raw)
To: Pierre Habouzit, Nigel Magnay, Git ML
In-Reply-To: <20080728205923.GC10409@artemis.madism.org>
On 7/28/08, Pierre Habouzit <madcoder@debian.org> wrote:
> On Mon, Jul 28, 2008 at 08:55:45PM +0000, Pierre Habouzit wrote:
> > That too indeed (the "easier to clone" bit). OTOH, I don't like the
> > .git/submodules idea a lot, if you mean to put a usual $GIT_DIR layout
> > inside of it. With what I propose, you find objects for all your
> > super/sub-modules in the usual store, which eases many things.
> > Especially, I believe that when you replace a subdirectory of a project
> > with a submodule, git-blame could benefit quite a lot from this to be
> > able to glue history back through the submodule limits, without having
> > to refactor a _lot_ of code: it would merely have to dereference so
> > called "gitlinks" to the commit then tree, hence twice, and just do its
> > usual work, with your proposal, we still rely on having to recurse in
> > subdirectories which requires more boilerplate code.
>
> And of _course_ this is also true for git-log, which is like 10x as
> important for me (like I don't remember if I used git-blame this year,
> whereas I used git-log in the last 10 minutes ;p)
I don't think you're going to get away with *not* having a separate
.git directory for each submodule. You'll just plain lose almost all
the features of submodules if you try to do that.
Most importantly in my case, my submodules (libraries shared between
apps) have a very different branching structure than my supermodules.
It wouldn't be particularly meaningful to force them to use the same
branch names.
Further, if you don't have a separate .git directory for each
submodule, you can't *switch* branches on the submodule independently
of the supermodule in any obvious way. This is also useful; I might
want to test updating to the latest master of my submodule, see if it
still works with my supermodule, and if so, commit the new gitlink in
the supermodule. This is a very common workflow for me.
On the other hand, your thought about combining the "git log" messages
is quite interesting. That *is* something I'd benefit from, along
with being able to git-bisect across submodules. If I'm in the
supermodule, I want to see *all* the commits that might have changed
in my application, not just the ones in the supermodule itself. I
suspect this isn't simple at all to implement, however, as you'd have
to look inside the file tree of a given commit in order to find
whether any submodule links have changed in that commit. It's
unfortunate that submodules involve a commit->tree->commit link
structure.
> One irritating problem with submodules, is
> that when someone else commited, and that you git submodule update,
> you're on a detached head. Absolutely horrible.
I think that roughly everyone agrees with the above statement by now.
It would also be trivial to fix it, if only we knew what "fix" means.
So far, I haven't seen any good suggestions for what branch name to
use automatically in a submodule, and believe me, I've been looking
for one :)
Have fun,
Avery
^ permalink raw reply
* Re: git-scm.com
From: Junio C Hamano @ 2008-07-28 21:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tom Werner, git
In-Reply-To: <alpine.DEB.1.00.0807281201350.2725@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 27 Jul 2008, Tom Werner wrote:
>
>> I find it a bit confusing that some here seem to have a strong dislike
>> for GitHub. It's true that we haven't been active on the developer list
>> or in the #git channel on freenode, but we are constantly in #github and
>> have answered a *great* many questions from developers that are new to
>> git.
>
> Speaking for myself, I will probably direct some users from #git to
> #github, then.
I saw more than several times that people asked github specific questions
on #git; when they were lucky, there was somebody who knew github and they
got necessary help. Otherwise the answer was "eh, sorry, that's a closed
service and we cannot help diagnosing the problem you are having". It
would have been the right way to help them to refer to the #github support
channel.
If a company can fund somebody to help new users with git problems on #git
while helping people with github problems on #github, that would be a good
gesture towards the git community, I'd suppose.
> Also note that one of the major gripe with you making money off of Git
> could be the following: we have over 500 contributors, and most of them --
> first and foremost of all, the two major contributors, Junio and Shawn --
> cannot make money from Git. Envy is wrong, but it is real.
I do not talk for Shawn, but I think that comment misses the mark by a
large margin, at least for me.
I haven't been in this for money. The original motivation of my
involvement was to help sending Linus back to the kernel as quickly as
possible, but now I primarily do this for fun. Doing it for money would
risk removing the fun factor.
What I personally lack right now is time and mental bandwidth.
Active contributers of all kinds, ranging from "C coders", "scripters", to
"Documentation people" and "dropped patch naggers", have been helping me
quite a lot. Corporate sponsors that can pay back in money but not in
patches may be able to find other ways to help us, but I do not offhand
know what's the most effective way for them to do so if they wanted to.
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-28 22:03 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Nigel Magnay, Git ML
In-Reply-To: <32541b130807281440v64f3cb9ci50cf6d16be4f2f82@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5928 bytes --]
On Mon, Jul 28, 2008 at 09:40:22PM +0000, Avery Pennarun wrote:
> On 7/28/08, Pierre Habouzit <madcoder@debian.org> wrote:
> > On Mon, Jul 28, 2008 at 08:55:45PM +0000, Pierre Habouzit wrote:
> > > That too indeed (the "easier to clone" bit). OTOH, I don't like the
> > > .git/submodules idea a lot, if you mean to put a usual $GIT_DIR layout
> > > inside of it. With what I propose, you find objects for all your
> > > super/sub-modules in the usual store, which eases many things.
> > > Especially, I believe that when you replace a subdirectory of a project
> > > with a submodule, git-blame could benefit quite a lot from this to be
> > > able to glue history back through the submodule limits, without having
> > > to refactor a _lot_ of code: it would merely have to dereference so
> > > called "gitlinks" to the commit then tree, hence twice, and just do its
> > > usual work, with your proposal, we still rely on having to recurse in
> > > subdirectories which requires more boilerplate code.
> >
> > And of _course_ this is also true for git-log, which is like 10x as
> > important for me (like I don't remember if I used git-blame this year,
> > whereas I used git-log in the last 10 minutes ;p)
>
> I don't think you're going to get away with *not* having a separate
> ..git directory for each submodule. You'll just plain lose almost all
> the features of submodules if you try to do that.
>
> Most importantly in my case, my submodules (libraries shared between
> apps) have a very different branching structure than my supermodules.
> It wouldn't be particularly meaningful to force them to use the same
> branch names.
Why not ? We're talking local branches, that can track whatever you like
on the remote side. Of course, the globing refspec are probably going to
be too simple for you if your branching scheme is _that_ different, but
if you can deal with that by hand _now_, I can't see why writing the
adequate tracking maps by hand would be any harder.
> Further, if you don't have a separate .git directory for each
> submodule, you can't *switch* branches on the submodule independently
> of the supermodule in any obvious way.
Yes you can, in what I propose you have a dummy .git in each submodule,
with probably an index, a HEAD and a config file (maybe some other
things along) to allow that especially.
> This is also useful; I might want to test updating to the latest
> master of my submodule, see if it still works with my supermodule, and
> if so, commit the new gitlink in the supermodule. This is a very
> common workflow for me.
I agree.
> It's unfortunate that submodules involve a commit->tree->commit link
> structure.
Actually it's not a big problem, you just have to "dereference" twice
instead of one, and be prepared to the fact that the second dereference
may fail (because you miss some objects). I instead believe that
gitlinks are a good idea.
> > One irritating problem with submodules, is
> > that when someone else commited, and that you git submodule update,
> > you're on a detached head. Absolutely horrible.
>
> I think that roughly everyone agrees with the above statement by now.
> It would also be trivial to fix it, if only we knew what "fix" means.
> So far, I haven't seen any good suggestions for what branch name to
> use automatically in a submodule, and believe me, I've been looking
> for one :)
Well, using the same as the supermodule is probably the less confusing
way. Of course, not being in the "same" branch as the supermodule would
clearly be a case of your tree being "dirty", and it would prevent a
"git checkout" to work in the very same way that git checkout doesn't
work if you have locally modified files.
If your submodule branching layout uses the same names as the
supermodule branches then yes, it's going to hurt, but I believe it to
be unlikely (else you would become insane just trying to remember what
you are doing ;p). So even if say your work in `master` in your
supermodule, but for some reason use what is on the remote
`release/10.2` branch for a given submodule, nothing prevents you to
have a local `master` branch in that submodule as well that tracks
`release/10.2`. It's actually a quite sensible thing to do I believe.
It doesn't prevent you from switching your submodule to the `devel`
branch to perform some tests, or even make it the new state of the
submodule inside your supermodule. This operation would just then move
what is `master` in your submodule to track `devel` instead of
`release/10.2`[0].
I fail to see which current submodules features you would lose with this
scheme. In fact, said differently, I more or less propose that when you
commit your supermodule state (providing some checks hold see [0]) it
updates the 'associated' branch in the submodule. The goal here, is that
you're always on a branch, set up to track a given remote branch, that
we can check against so that we can:
(1) avoid the usual caveats of git-submodules (one can check when
pushing the supermodule that all submodules are indeed pushed in
the remote branch they track);
(2) user can commit and don't bother resetting branches and doing
tricks to be "on branch again".
I don't think it prevents you from e.g. having topic branches in your
submodules, provided that before commiting a new submodule change, you
somehow merge those in the "matching" branch that was set up for you.
[0] of course we probably want to refuse such a thing if `devel` isn't
a fast-forward from release/10.2. But that's not the point of the
explanation so I skipped this bit for clarity of my point.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git submodules
From: Jakub Narebski @ 2008-07-28 22:26 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Avery Pennarun, Nigel Magnay, Git ML
In-Reply-To: <20080728220308.GF10409@artemis.madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> On Mon, Jul 28, 2008 at 09:40:22PM +0000, Avery Pennarun wrote:
> > Further, if you don't have a separate .git directory for each
> > submodule, you can't *switch* branches on the submodule independently
> > of the supermodule in any obvious way.
>
> Yes you can, in what I propose you have a dummy .git in each submodule,
> with probably an index, a HEAD and a config file (maybe some other
> things along) to allow that especially.
What you are (re)inventing here is something called gitlink (.git which
is a file, or .gitlink file); not to be confused with 'sumbodule'/'commit'
entry in a tree which is sometimes called gitlink. Alternate idea was
'unionfs' like "shadowing" .git, with 'core.gitdir' in .git/config
(which would contain .git/HEAD and .git/index, and all missing files
and config would be taken from `core.gitdir').
There was even some preliminary implementation IIRC, but AFAIR it
was abandoned because of no "real usage".
See
http://permalink.gmane.org/gmane.comp.version-control.msysgit/1868
http://permalink.gmane.org/gmane.comp.version-control.git/72449
http://permalink.gmane.org/gmane.comp.version-control.git/72457
http://permalink.gmane.org/gmane.comp.version-control.git/72296
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: GTP/0.1 terminology 101: commit reels and references
From: Johannes Schindelin @ 2008-07-28 22:30 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, Joshua Roys, gittorrent, git, Jonas Fonseca
In-Reply-To: <1217273166.25690.20.camel@maia.lan>
Hi,
On Tue, 29 Jul 2008, Sam Vilain wrote:
> On Mon, 2008-07-28 at 14:01 +0200, Johannes Schindelin wrote:
> > > - the reel has a defined object order (which as I hoped to
> > > demonstrate in the test cases, is just a refinement of rev-list
> > > --date-order)
> >
> > Do you mean that the commit reel is a list pointing to bundles that
> > can be sorted topologically by their contained commits?
>
> Yes, but it is more defined than that. There are still ambiguities with
> topological sort, so the gittorrent spec specified exactly how all ties
> are broken. They happen to be a further refinement of --date-order,
> with respect to the ordering of commits.
But does that not mean that any new ref branching off of an ancient commit
changes all the pack boundaries?
I'd rather have an intelligent incremental updater, and keep most of the
existing bundles immutable. That way, a new ref, or a changed one, can be
mostly served from peers, not exclusively from the seeders.
> > > - deltas always point in one direction, to objects "earlier" on
> > > the reel, so that slices of the reel sent on the network can be
> > > made thin without resulting in unresolvable deltas (which should
> > > be possible to do on commit boundaries using rev-list
> > > --objects-edge)
> >
> > That is exactly what bundles do. They are thin, as they assume that a
> > few "preconditions", i.e. refs, are present.
>
> Ok. I think there are also some other trivial differences such as
> bundles containing refs (which in the context of gittorrent will be
> useless).
Yeah, I think that bundles themselves are pretty useless in gitorrent.
But what they _contain_ is pretty much what you need as blocks.
> > > - the behaviour at the beginning of the reel is precisely defined
> > > (although as I said, I think that the decision might be worth
> > > revisiting - perhaps getting just the latest reel is a useful
> > > 'shallow clone')
> >
> > If you want to allow shallow clones, you must make the bundles
> > non-thin. That would be a major bandwidth penalty.
> >
> > I'd rather not allow shallow clones with Gitorrent.
>
> By "Shallow" I think I mean a different thing to you. I mean something
> akin to just the last pack's worth of commits.
That _is_ a shallow clone. And that is exactly what I meant. If you want
to have all objects of the commits in the same pack, then you are
basically making fat packs. Which come with a hefty bandwidth penalty.
That is why I would suggest not allowing shallow clones; if you want to
allow them, I have to ask myself why bother with a torrent at all... It
is not like the shallow clones are large, or that the people fetching them
will stay around long to seed anything, and the packs would change
frequently, making the whole torrent business pretty inefficient.
> > > It's the lack of guarantees which is the issue, really.
> >
> > It should not be too difficult to provide a rev-list option (which is
> > inherited by git-bundle, then) to pay an extra time to make sure that
> > the bundle is minimal.
>
> Ok. But from the current implementation's perspective, this is not yet
> needed, we are just using the existing API.
Why make it hard? We have a lively community with brilliant people, and
they frequently have fun solving puzzles like this: what is the best
strategy to make equally sized, rarely (or maybe never?) changing packs
from a set of given refs.
> Actually what would be useful would be for the thin pack generation to
> also allow any object to be specified as its input list, not just
> commits... then we wouldn't have to break blocks on commit boundaries
> (see http://gittorrent.utsl.gen.nz/rfc.html#org-blocks).
That should be easy, but I think that it would be _even better_ if we ask
pack-objects to generate several packs from the needed objects. Ooops.
That already exists:
$ git pack-objects --max-pack-size=<n>
Storing the packs in a second GIT_OBJECT_DIRECTORY that has the
original as an alternate, together with the --local flag, should help even
further: You can mark the last pack (which does not reach max-pack-size,
most likely), remove it and just rerun the packing.
Of course, this needs some thought when large chunks of the object
database become stale when a long branch was just deleted. Not a major
obstacle, though.
Ciao,
Dscho
^ permalink raw reply
* Re: git submodules
From: Avery Pennarun @ 2008-07-28 22:32 UTC (permalink / raw)
To: Pierre Habouzit, Avery Pennarun, Nigel Magnay, Git ML
In-Reply-To: <20080728220308.GF10409@artemis.madism.org>
On 7/28/08, Pierre Habouzit <madcoder@debian.org> wrote:
> > It's unfortunate that submodules involve a commit->tree->commit link
> > structure.
>
> Actually it's not a big problem, you just have to "dereference" twice
> instead of one, and be prepared to the fact that the second dereference
> may fail (because you miss some objects). I instead believe that
> gitlinks are a good idea.
It's actually complicated to generate the log, however. To be 100%
accurate in creating a combined log of the supermodule and submodule,
you'd have to check *for each supermodule commit* whether there were
any changes in gitlinks. And gitlinks might move around between
revisions, so you can't just look up a particular path in each
revision; you have to traverse the entire tree. And you can't just
look at the start and end supermodule commits to see if the gitlinks
changed; they might have changed and then changed back, which is quite
relevant to log messages.
Probably it's more useful to just commit the git-shortlog of the
submodule whenever you update the gitlink. It won't work with bisect,
exactly, but that's less important than generally having an idea of
what happened by reading the log. ISTR somenoe submitted a
git-submodule patch for that already somewhere, but I've been known to
imagine things.
> Well, using the same [branch] as the supermodule is probably the less confusing
> way. Of course, not being in the "same" branch as the supermodule would
> clearly be a case of your tree being "dirty", and it would prevent a
> "git checkout" to work in the very same way that git checkout doesn't
> work if you have locally modified files.
>
> If your submodule branching layout uses the same names as the
> supermodule branches then yes, it's going to hurt, but I believe it to
> be unlikely (else you would become insane just trying to remember what
> you are doing ;p).
I think this is much more common than you think. An easy example is
that I'm developing a new version of my application in the
supermodule's "master", but it relies on a released version of my
submodule, definitely not the experimental "master" version. Using
your logic, the local branch of the submodule would be called master,
but wouldn't correspond at all to the remote submodule's master.
I believe such a situation would be even worse than no branch at all.
It could lead to people pushing/pulling all sorts of bad things from
the wrong places. At least right now, people become confused and ask
for help instead of becoming confused and making a mess.
Have fun,
Avery
^ permalink raw reply
* Re: git-scm.com
From: Martin Langhoff @ 2008-07-28 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Tom Werner, git
In-Reply-To: <7vk5f5ptwu.fsf@gitster.siamese.dyndns.org>
On Tue, Jul 29, 2008 at 9:42 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Active contributers of all kinds, ranging from "C coders", "scripters", to
> "Documentation people" and "dropped patch naggers", have been helping me
> quite a lot. Corporate sponsors that can pay back in money but not in
> patches may be able to find other ways to help us, but I do not offhand
> know what's the most effective way for them to do so if they wanted to.
FWIW - not much probably - anything that pushes towards
"gui-completeness" is a good step.
We have fantastic gui tools that complement the awesome cli UI, and we
have some complete-ish GUIs, but the git-cheetah and Eclipse tracks
are lacking. Work on those is needed - whether money can help I do not
know. However, not many people work on polishing smooth UIs for love
and fun.
cheers,
martin
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: git submodules
From: Junio C Hamano @ 2008-07-28 22:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Pierre Habouzit, Avery Pennarun, Nigel Magnay, Git ML
In-Reply-To: <m3r69dtzm9.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Pierre Habouzit <madcoder@debian.org> writes:
>> On Mon, Jul 28, 2008 at 09:40:22PM +0000, Avery Pennarun wrote:
>
>> > Further, if you don't have a separate .git directory for each
>> > submodule, you can't *switch* branches on the submodule independently
>> > of the supermodule in any obvious way.
>>
>> Yes you can, in what I propose you have a dummy .git in each submodule,
>> with probably an index, a HEAD and a config file (maybe some other
>> things along) to allow that especially.
>
> What you are (re)inventing here is something called gitlink (.git which
> is a file, or .gitlink file); not to be confused with 'sumbodule'/'commit'
> entry in a tree which is sometimes called gitlink....
> ...
> There was even some preliminary implementation IIRC, but AFAIR it
> was abandoned because of no "real usage".
I am afraid you are confused. I think you are talking about "gitfile",
not "gitlink".
It is not abandoned; see e.g. read_gitfile_gently() in setup.c.
I suspect the use of it may help the use case Pierre proposes, but its
main attractiveness as I understood it back when we discussed the facility
was that you could switch branches between 'maint' that did not have a
submodule at "path" back then, and 'master' that does have one now,
without losing the submodule repository. When checking out 'master' (and
that would probably mean you would update 'git-submodule init' and
'git-submodule update' implementation), you would instanciate subdirectory
"path", create "path/.git" that is such a regular file that that points at
somewhere inside the $GIT_DIR of superproject (say ".git/submodules/foo").
By storing refs and object store are all safely away in the superproject
$GIT_DIR, you can now safely switch back to 'maint', which would involve
making sure there is no local change that will be lost and then removing
the "path" and everything underneath it.
^ permalink raw reply
* Showing changes about to be commited via git svn dcommit
From: Lee Marlow @ 2008-07-28 22:54 UTC (permalink / raw)
To: git
git-svners,
I often like to look at the diff of what I'm about to commit before
taking the plunge. I'd really like an easy way to see a 'git log -p'
output of what would be committed to the central svn repository with a
dcommit. I found --dry-run and finally made a "one-liner" that
outputs what I want, but it seems like a lot of work for something I
do quite often. The one-liner I used is:
$> git svn dcommit --dry-run | grep -E '^diff-tree ' | cut -b 11- |
git diff-tree --stdin -p -v
Is this the real way to do it? Do others do something similar?
Curious and looking for a better way.
-Lee
^ permalink raw reply
* Re: [PATCH 1/9] Makefile: Do not install a copy of 'git' in $(gitexecdir)
From: A Large Angry SCM @ 2008-07-28 23:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7v63qqv7ex.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>> This new action needs to be in a conditional to keep it from removing
>>> the ONLY git executable when bindir and execdir are the same dir.
>> Heh, I love bug reports that come immediately after I tag the tip of
>> 'master' as -rc1.
>
> This should do, but to be very honest, I really hate the output from the
> foreach that precedes this section.
>
> Makefile | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 798a2f2..92df61c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1362,7 +1362,10 @@ endif
> cp "$$bindir/git$X" "$$execdir/git$X"; \
> fi && \
> { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
> - $(RM) "$$execdir/git$X" && \
> + if test "z$$bindir" != "z$$execdir"; \
> + then \
> + $(RM) "$$execdir/git$X"; \
> + fi && \
> ./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
>
> install-doc:
>
Tested by: A Large Angry SCM <gitzilla@gmail.com>
^ permalink raw reply
* Re: git-scm.com
From: Pieter de Bie @ 2008-07-28 22:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Tom Werner, git
In-Reply-To: <7vk5f5ptwu.fsf@gitster.siamese.dyndns.org>
On 28 jul 2008, at 23:42, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Sun, 27 Jul 2008, Tom Werner wrote:
>>
>>> I find it a bit confusing that some here seem to have a strong
>>> dislike
>>> for GitHub. It's true that we haven't been active on the developer
>>> list
>>> or in the #git channel on freenode, but we are constantly in
>>> #github and
>>> have answered a *great* many questions from developers that are
>>> new to
>>> git.
>>
>> Speaking for myself, I will probably direct some users from #git to
>> #github, then.
>
> I saw more than several times that people asked github specific
> questions
> on #git; when they were lucky, there was somebody who knew github
> and they
> got necessary help. Otherwise the answer was "eh, sorry, that's a
> closed
> service and we cannot help diagnosing the problem you are having". It
> would have been the right way to help them to refer to the #github
> support
> channel.
For what it's worth, I regularly redirect people from #git to #github,
so at
least they aren't always left in the dark ;)
- Pieter
^ permalink raw reply
* [PATCH 3/6] builtin-help: make it possible to exclude some commands in list_commands()
From: Miklos Vajna @ 2008-07-28 23:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr69ex00x.fsf@gitster.siamese.dyndns.org>
The supposed method is to build a list of commands to be excluded using
add_cmdname(), then pass the list as the new exclude parameter. If no
exclude is needed, NULL should be used.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Sun, Jul 27, 2008 at 06:36:30PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > + struct cmdname {
> > + size_t len;
> > + char name[1];
> > + } **names;
> > +};
>
> I thought we do this kind of thing using FLEX_ARRAY macro. Is there
> any
> reason its use is not appropriate here?
Now I'm using it. :-)
Note that FLEX_ARRAY would be a drop-in replacement only in case it
would be name[0], so I needed
- struct cmdname *ent = xmalloc(sizeof(*ent) + len);
+ struct cmdname *ent = xmalloc(sizeof(*ent) + len + 1);
later in add_cmdname().
help.c | 26 +++++++++++---------------
help.h | 14 +++++++++++++-
2 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/help.c b/help.c
index 7a42517..858f76a 100644
--- a/help.c
+++ b/help.c
@@ -9,6 +9,7 @@
#include "common-cmds.h"
#include "parse-options.h"
#include "run-command.h"
+#include "help.h"
static struct man_viewer_list {
struct man_viewer_list *next;
@@ -300,18 +301,11 @@ static inline void mput_char(char c, unsigned int num)
putchar(c);
}
-static struct cmdnames {
- int alloc;
- int cnt;
- struct cmdname {
- size_t len;
- char name[1];
- } **names;
-} main_cmds, other_cmds;
+struct cmdnames main_cmds, other_cmds;
-static void add_cmdname(struct cmdnames *cmds, const char *name, int len)
+void add_cmdname(struct cmdnames *cmds, const char *name, int len)
{
- struct cmdname *ent = xmalloc(sizeof(*ent) + len);
+ struct cmdname *ent = xmalloc(sizeof(*ent) + len + 1);
ent->len = len;
memcpy(ent->name, name, len);
@@ -463,7 +457,7 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
return longest;
}
-static unsigned int load_command_list(const char *prefix)
+static unsigned int load_command_list(const char *prefix, struct cmdnames *exclude)
{
unsigned int longest = 0;
unsigned int len;
@@ -502,13 +496,15 @@ static unsigned int load_command_list(const char *prefix)
sizeof(*other_cmds.names), cmdname_compare);
uniq(&other_cmds);
exclude_cmds(&other_cmds, &main_cmds);
+ if (exclude)
+ exclude_cmds(&main_cmds, exclude);
return longest;
}
-void list_commands(const char *prefix, const char *title)
+void list_commands(const char *prefix, const char *title, struct cmdnames *exclude)
{
- unsigned int longest = load_command_list(prefix);
+ unsigned int longest = load_command_list(prefix, exclude);
const char *exec_path = git_exec_path();
if (main_cmds.cnt) {
@@ -558,7 +554,7 @@ static int is_in_cmdlist(struct cmdnames *c, const char *s)
int is_git_command(const char *s, const char *prefix)
{
- load_command_list(prefix);
+ load_command_list(prefix, NULL);
return is_in_cmdlist(&main_cmds, s) ||
is_in_cmdlist(&other_cmds, s);
}
@@ -704,7 +700,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (show_all) {
printf("usage: %s\n\n", git_usage_string);
- list_commands("git-", "git commands");
+ list_commands("git-", "git commands", NULL);
printf("%s\n", git_more_info_string);
return 0;
}
diff --git a/help.h b/help.h
index 0741662..3eb8cfb 100644
--- a/help.h
+++ b/help.h
@@ -1,7 +1,19 @@
#ifndef HELP_H
#define HELP_H
+struct cmdnames {
+ int alloc;
+ int cnt;
+ struct cmdname {
+ size_t len;
+ char name[FLEX_ARRAY];
+ } **names;
+};
+
int is_git_command(const char *s, const char *prefix);
-void list_commands(const char *prefix, const char *title);
+void list_commands(const char *prefix, const char *title, struct cmdnames *exclude);
+void add_cmdname(struct cmdnames *cmds, const char *name, int len);
+
+extern struct cmdnames main_cmds, other_cmds;
#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
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