librelist archives

« back to archive

Roadmap?

Roadmap?

From:
Pontus Munck
Date:
2012-04-07 @ 08:01
Hi,

First of all, thanks for all the work you guys have put in to make
libgit2 come to life. The code is really clean and easy to understand
so kudos for that. It's also nice to see that you are using unit
testing!

I was wondering if there is some kind of roadmap anywhere to see the
general implementation plan and what needs to be done next? I see a
lot of things are still missing and it would be nice to know what is
being worked on and what needs to be done. Some features depend on
other things being implemented first etc. The issue list on GitHub
does not give a very good overview of what is going on really...

/Pontus

Re: [libgit2] Roadmap?

From:
Vicent Marti
Date:
2012-04-07 @ 19:07
Hey Pontus,

On Sat, Apr 7, 2012 at 10:01 AM, Pontus Munck <pontus.munck@gmail.com> wrote:
> Hi,
>
> First of all, thanks for all the work you guys have put in to make
> libgit2 come to life. The code is really clean and easy to understand
> so kudos for that. It's also nice to see that you are using unit
> testing!

Thanks for the kind words!

>
> I was wondering if there is some kind of roadmap anywhere to see the
> general implementation plan and what needs to be done next? I see a
> lot of things are still missing and it would be nice to know what is
> being worked on and what needs to be done. Some features depend on
> other things being implemented first etc. The issue list on GitHub
> does not give a very good overview of what is going on really...

We don't have a laid down roadmap at the moment, but we're nearing an
1.0 release. The only big stumping block before that is network push
support, which we're hoping to complete this summer as part of the
Summer of Code project.

I should probably get started on writing down a roadmap for 1.0
**and** a styleguide for the project. Haha.

Cheers,
Vicent

Re: [libgit2] Roadmap?

From:
Pontus Munck
Date:
2012-04-09 @ 09:11
Ok, maybe I'm missing something but there seems to be more things to
do before a 1.0 release. I don't see any API for doing merge, rebase
or checkout? There is no way to see diffs? Support for submodules? How
do I perform fetch and clone?

Maybe all of these things are being worked on but if not it would be
great to know if you need any help. :)

/Pontus



On Sat, Apr 7, 2012 at 9:07 PM, Vicent Marti <vicent@github.com> wrote:
> Hey Pontus,
>
> On Sat, Apr 7, 2012 at 10:01 AM, Pontus Munck <pontus.munck@gmail.com> wrote:
>> Hi,
>>
>> First of all, thanks for all the work you guys have put in to make
>> libgit2 come to life. The code is really clean and easy to understand
>> so kudos for that. It's also nice to see that you are using unit
>> testing!
>
> Thanks for the kind words!
>
>>
>> I was wondering if there is some kind of roadmap anywhere to see the
>> general implementation plan and what needs to be done next? I see a
>> lot of things are still missing and it would be nice to know what is
>> being worked on and what needs to be done. Some features depend on
>> other things being implemented first etc. The issue list on GitHub
>> does not give a very good overview of what is going on really...
>
> We don't have a laid down roadmap at the moment, but we're nearing an
> 1.0 release. The only big stumping block before that is network push
> support, which we're hoping to complete this summer as part of the
> Summer of Code project.
>
> I should probably get started on writing down a roadmap for 1.0
> **and** a styleguide for the project. Haha.
>
> Cheers,
> Vicent

Re: [libgit2] Roadmap?

From:
Charlie Sharpsteen
Date:
2012-04-09 @ 13:13
On Mon, Apr 9, 2012 at 2:11 AM, Pontus Munck <pontus.munck@gmail.com> wrote:

> Ok, maybe I'm missing something but there seems to be more things to
> do before a 1.0 release. I don't see any API for doing merge, rebase
> or checkout? There is no way to see diffs? Support for submodules? How
> do I perform fetch and clone?
>
> Maybe all of these things are being worked on but if not it would be
> great to know if you need any help. :)
>
> /Pontus


Most of those things: rebase and merge tools and diff viewers, are things
that would be built on top of libgit2. I.E. the libgit2 project only aims
to provide the core library---not all the command line tools that the git
project has. But with the core library, one could create the command line
tools as a separate project.

-Charlie

Re: [libgit2] Roadmap?

From:
Pontus Munck
Date:
2012-04-09 @ 15:33
Sorry but I am not talking about tools here. I meant the actual
algorithms for those operations.

For example, to perform a merge between two branches you need to
compare what has changed between them. This is done by taking the two
commits that the branches point to as well as their common ancestor in
the commit tree and performing a 3-way merge. For each file and each
directory you need to make an intelligent decision of what to do. If a
file or directory cannot be merged automatically you get a conflict.

The automatic merging is one of the key features of Git. It makes no
sense that everyone should have to implement the logic for that on
their own. That is why I believe those things belong in libgit2.

/Pontus



On Mon, Apr 9, 2012 at 3:13 PM, Charlie Sharpsteen <chuck@sharpsteen.net> wrote:
> On Mon, Apr 9, 2012 at 2:11 AM, Pontus Munck <pontus.munck@gmail.com> wrote:
>>
>> Ok, maybe I'm missing something but there seems to be more things to
>> do before a 1.0 release. I don't see any API for doing merge, rebase
>> or checkout? There is no way to see diffs? Support for submodules? How
>> do I perform fetch and clone?
>>
>> Maybe all of these things are being worked on but if not it would be
>> great to know if you need any help. :)
>>
>> /Pontus
>
>
> Most of those things: rebase and merge tools and diff viewers, are things
> that would be built on top of libgit2. I.E. the libgit2 project only aims to
> provide the core library---not all the command line tools that the git
> project has. But with the core library, one could create the command line
> tools as a separate project.
>
> -Charlie

Re: [libgit2] Roadmap?

From:
Carlos Martín Nieto
Date:
2012-04-09 @ 17:02
On Mon, 2012-04-09 at 17:33 +0200, Pontus Munck wrote:
> Sorry but I am not talking about tools here. I meant the actual
> algorithms for those operations.

The merge algo does belong in the library, though how much it should do
by itself can probably be argued.

The largest things that are missing such as merge and pack-objects
should be a relatively straight port from git. Merge does need
merge-base calculation to be merged in, but that's waiting in a PR and
shouldn't take long to make it upstream.

As for the other things you mentioned: rebase is a loop for a 2-way
merge. Checkout can mean many things in git. checkout-index (what you do
when you run 'git checkout -- file') should be trivial to implement,
same as 'git checkout somehash -- file' and whether the library adds a
wrapper shouldn't be that big a deal. What we do need to add in the
library is the 'read-tree -m otherbranch' that happens when you switch
branches. Part of that we can do already, some of it needs the merge
algo.

   cmn

> 
> For example, to perform a merge between two branches you need to
> compare what has changed between them. This is done by taking the two
> commits that the branches point to as well as their common ancestor in
> the commit tree and performing a 3-way merge. For each file and each
> directory you need to make an intelligent decision of what to do. If a
> file or directory cannot be merged automatically you get a conflict.
> 
> The automatic merging is one of the key features of Git. It makes no
> sense that everyone should have to implement the logic for that on
> their own. That is why I believe those things belong in libgit2.
> 
> /Pontus
> 
> 
> 
> On Mon, Apr 9, 2012 at 3:13 PM, Charlie Sharpsteen <chuck@sharpsteen.net> wrote:
> > On Mon, Apr 9, 2012 at 2:11 AM, Pontus Munck <pontus.munck@gmail.com> wrote:
> >>
> >> Ok, maybe I'm missing something but there seems to be more things to
> >> do before a 1.0 release. I don't see any API for doing merge, rebase
> >> or checkout? There is no way to see diffs? Support for submodules? How
> >> do I perform fetch and clone?
> >>
> >> Maybe all of these things are being worked on but if not it would be
> >> great to know if you need any help. :)
> >>
> >> /Pontus
> >
> >
> > Most of those things: rebase and merge tools and diff viewers, are things
> > that would be built on top of libgit2. I.E. the libgit2 project only aims to
> > provide the core library---not all the command line tools that the git
> > project has. But with the core library, one could create the command line
> > tools as a separate project.
> >
> > -Charlie


Re: [libgit2] Roadmap?

From:
Pontus Munck
Date:
2012-04-09 @ 19:09
That's great news. I actually looked at the "master" branch of the lib
and now that I look in the "development" branch I see that a lot more
stuff is there such as diff and fetch... Looks great, I'll be waiting
for the merge feature to show up then. :)

/Pontus



On Mon, Apr 9, 2012 at 7:02 PM, Carlos Martín Nieto <carlos@cmartin.tk> wrote:
> On Mon, 2012-04-09 at 17:33 +0200, Pontus Munck wrote:
>> Sorry but I am not talking about tools here. I meant the actual
>> algorithms for those operations.
>
> The merge algo does belong in the library, though how much it should do
> by itself can probably be argued.
>
> The largest things that are missing such as merge and pack-objects
> should be a relatively straight port from git. Merge does need
> merge-base calculation to be merged in, but that's waiting in a PR and
> shouldn't take long to make it upstream.
>
> As for the other things you mentioned: rebase is a loop for a 2-way
> merge. Checkout can mean many things in git. checkout-index (what you do
> when you run 'git checkout -- file') should be trivial to implement,
> same as 'git checkout somehash -- file' and whether the library adds a
> wrapper shouldn't be that big a deal. What we do need to add in the
> library is the 'read-tree -m otherbranch' that happens when you switch
> branches. Part of that we can do already, some of it needs the merge
> algo.
>
>   cmn
>
>>
>> For example, to perform a merge between two branches you need to
>> compare what has changed between them. This is done by taking the two
>> commits that the branches point to as well as their common ancestor in
>> the commit tree and performing a 3-way merge. For each file and each
>> directory you need to make an intelligent decision of what to do. If a
>> file or directory cannot be merged automatically you get a conflict.
>>
>> The automatic merging is one of the key features of Git. It makes no
>> sense that everyone should have to implement the logic for that on
>> their own. That is why I believe those things belong in libgit2.
>>
>> /Pontus
>>
>>
>>
>> On Mon, Apr 9, 2012 at 3:13 PM, Charlie Sharpsteen 
<chuck@sharpsteen.net> wrote:
>> > On Mon, Apr 9, 2012 at 2:11 AM, Pontus Munck <pontus.munck@gmail.com> wrote:
>> >>
>> >> Ok, maybe I'm missing something but there seems to be more things to
>> >> do before a 1.0 release. I don't see any API for doing merge, rebase
>> >> or checkout? There is no way to see diffs? Support for submodules? How
>> >> do I perform fetch and clone?
>> >>
>> >> Maybe all of these things are being worked on but if not it would be
>> >> great to know if you need any help. :)
>> >>
>> >> /Pontus
>> >
>> >
>> > Most of those things: rebase and merge tools and diff viewers, are things
>> > that would be built on top of libgit2. I.E. the libgit2 project only aims to
>> > provide the core library---not all the command line tools that the git
>> > project has. But with the core library, one could create the command line
>> > tools as a separate project.
>> >
>> > -Charlie
>
>
>