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
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
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
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
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
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
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 > > >