[PATCH] [GSoC 2014]diff: Imported dir.h and renamed read_directory()
this was done in order to implement the GSoC
Micro project for diff-no-index.c this is the
first patch importing dir.h, for the use of
is_dot_or_dotdot(), and renaming
read_directory() to read_directory_contents()
in order to deal with the conflicting function
in dir.h
Signed-off-by: Brian Bourn
---
I plan on applying to GSoC 2014
diff-no-index.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 8e10bff..ba915af 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -10,13 +10,14 @@
#include "blob.h"
#include "tag.h"
#include "diff.h"
+#include "dir.h"
#include "diffcore.h"
#include "revision.h"
#include "log-tree.h"
#include "builtin.h"
#include "string-list.h"
-static int read_directory(const char *path, struct string_list *list)
+static int read_directory_contents(const char *path, struct string_list *list)
{
DIR *dir;
struct dirent *e;
@@ -107,9 +108,9 @@ static int queue_diff(struct diff_options *o,
int i1, i2, ret = 0;
size_t len1 = 0, len2 = 0;
- if (name1 && read_directory(name1, &p1))
+ if (name1 && read_directory_contents(name1, &p1))
return -1;
- if (name2 && read_directory(name2, &p2)) {
+ if (name2 && read_directory_contents(name2, &p2)) {
string_list_clear(&p1, 0);
return -1;
}
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] [GSoC] diff: rename read_directory()
From: Brian Bourn
It is desirable to replace manual checking of "." or ".."
in diff-no-index.c with is_dot_or_dotdot(), which is defined
in dir.h. However, dir.h declares a read_directory which conflicts
with a (different) static read_directory() defined in
in diff-no-index.c. As a preparatory step, rename the local
read_directory() to avoid the collision
Signed-off-by: Brian Bourn
---
Part 1 of my GSoC submission
diff-no-index.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 8e10bff..ec51106 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -16,7 +16,7 @@
#include "builtin.h"
#include "string-list.h"
-static int read_directory(const char *path, struct string_list *list)
+static int read_directory_contents(const char *path, struct string_list *list)
{
DIR *dir;
struct dirent *e;
@@ -107,9 +107,9 @@ static int queue_diff(struct diff_options *o,
int i1, i2, ret = 0;
size_t len1 = 0, len2 = 0;
- if (name1 && read_directory(name1, &p1))
+ if (name1 && read_directory_contents(name1, &p1))
return -1;
- if (name2 && read_directory(name2, &p2)) {
+ if (name2 && read_directory_contents(name2, &p2)) {
string_list_clear(&p1, 0);
return -1;
}
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] [GSoC] diff:use is_dot_or_dotdot() in code
From: Brian Bourn
Subject: replace manual "."/".." check with is_dot_or_dotdot()
Signed-off-by: Brian Bourn
---
Part 2 of my GSoC submission where the actual change is made
diff-no-index.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index ec51106..c554691 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -15,6 +15,7 @@
#include "log-tree.h"
#include "builtin.h"
#include "string-list.h"
+#include "dir.h"
static int read_directory_contents(const char *path, struct string_list *list)
{
@@ -25,7 +26,7 @@ static int read_directory_contents(const char *path, struct
string_list *list)
return error("Could not open directory %s", path);
while ((e = readdir(dir)))
- if (strcmp(".", e->d_name) && strcmp("..", e->d_name))
+ if (!is_dot_or_dotdot(e->d_name))
string_list_insert(list, e->d_name);
closedir(dir);
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2][GSoC] diff-no-index: rename read_directory()
It would be desirable to replace manual checking of "." or ".."
in diff-no-index.c with is_dot_or_dotdot(), which is defined
in dir.h, however, dir.h declares a read_directory() which conflicts
with a (different) static read_directory() defined
in diff-no-index.c. As a preparatory step, rename the local
read_directory() to avoid the collision.
Signed-off-by: Brian Bourn
---
Part 1 of my submission for GSoC
diff-no-index.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 8e10bff..ec51106 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -16,7 +16,7 @@
#include "builtin.h"
#include "string-list.h"
-static int read_directory(const char *path, struct string_list *list)
+static int read_directory_contents(const char *path, struct string_list *list)
{
DIR *dir;
struct dirent *e;
@@ -107,9 +107,9 @@ static int queue_diff(struct diff_options *o,
int i1, i2, ret = 0;
size_t len1 = 0, len2 = 0;
- if (name1 && read_directory(name1, &p1))
+ if (name1 && read_directory_contents(name1, &p1))
return -1;
- if (name2 && read_directory(name2, &p2)) {
+ if (name2 && read_directory_contents(name2, &p2)) {
string_list_clear(&p1, 0);
return -1;
}
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2][GSoC] diff-no-index: replace manual "."/".." check with is_dot_or_dotdot()
Signed-off-by: Brian Bourn
---
Part 2 of my submission for GSoC
diff-no-index.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index ec51106..c554691 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -15,6 +15,7 @@
#include "log-tree.h"
#include "builtin.h"
#include "string-list.h"
+#include "dir.h"
static int read_directory_contents(const char *path, struct string_list *list)
{
@@ -25,7 +26,7 @@ static int read_directory_contents(const char *path, struct
string_list *list)
return error("Could not open directory %s", path);
while ((e = readdir(dir)))
- if (strcmp(".", e->d_name) && strcmp("..", e->d_name))
+ if (!is_dot_or_dotdot(e->d_name))
string_list_insert(list, e->d_name);
closedir(dir);
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GSoC] Choosing a Project Proposal
Hi all, I'm Currently trying to decide on a project to work on in for Google Summer of Code, I'm stuck choosing between three which I find really interesting and I was wondering if any of them are particularly more pressing then the others. I would also love some comments on each of these three if possible expanding on them. the three projects I'm considering are, 1. Unifying git branch -l, git tag -l, and git for-each-ref 2. Refactor tempfile handling 3. Improve triangular workflow support Once again, I would appreciate all feedback on which of these are most important. Thanks for the Help, Brian Bourn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [GSoC] Draft of Proposal for GSoC
Hi all, This is a first draft of my Proposal for GSoC, I'd love feedback about what I might be missing and any other files I should read regarding this, so far I have read most of tag.c, branch.c, builtin/for-each-ref.c, parse-options.c. once again I hope I can get the same amount of helpful feedback as when I submitted my Microproject. My name is Brian Bourn, I'm currently a computer engineering student at Columbia university in the city of New York. I've used git since my freshman year however this past week has been my first time attempting to contribute to the project, and I loved it. I'd particularly like to tackle Unifying git branch -l, git tag -l, and git for-each-ref. This functionality seems like an important update to me as it will simplify usage of git throughout three different commands, a noble pursuit which is not contained in any other project. Going through the annals of the listserve thus far I've found a few discussions which provide some insight towards this process as well as some experimental patches that never seem to have made it through[1][2][3][4] I would start by beginning a deprecation plan for git branch -l very similar to the one Junio presents in [5], moving -create-reflog to -g, Following this I would begin the real work of the project which would involve moving the following flag operations into a standard library say 'list-options.h' --contains [6] --merged [7] --no-merged[8] --format This Library would build these options for later interpretation by parse_options Next I would implement these flags in the three files so that they are uniform and the same formatting and list capabilities can be used on all three. The formatting option will be especially useful for branch and tag as it will allow users to better understand what is in each ref that they grab. For the most part I haven't finalized my weekly schedule but a basic breakdown would be Start-Midterm Begin deprecation of -l Spend some time reading *.c files even deeper Build Library(dedicate Minimum one week per function moved) Midterm-finish Implement the list flags Implement the format flags (if time is left over, add some formatting) Additionally I am thinking about adding some more formatting tools such as numbering outputs. What do you all think of this? [1]http://git.661346.n2.nabble.com/More-formatting-with-git-tag-l-tt6739049.html [2]http://git.661346.n2.nabble.com/RFC-branch-list-branches-by-single-remote-tt6645679.html#a6725483 [3]http://git.661346.n2.nabble.com/RFC-PATCH-tag-make-list-exclude-lt-pattern-gt-tt7270451.html#a7338712 [4]http://git.661346.n2.nabble.com/RFC-branch-list-branches-by-single-remote-tt6645679.html#a6728878 [5]http://git.661346.n2.nabble.com/RFC-PATCH-0-2-RFC-POC-patterns-for-branch-list-tt6309233.html [6]https://github.com/git/git/blob/master/builtin/branch.c#L817 [7] https://github.com/git/git/blob/master/builtin/branch.c#L849 [8] https://github.com/git/git/blob/master/builtin/branch.c#L843 Regards, Brian Bourn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [GSoC] Draft of Proposal for GSoC
Hello again, Please it would be very helpful for me to get some comments on this proposal I would be very grateful towards anyone who could take some time to look at it, even if it's just the wording. Regards, Brian Bourn On Thu, Mar 20, 2014 at 2:15 PM, Brian Bourn wrote: > Hi all, > > This is a first draft of my Proposal for GSoC, I'd love feedback about > what I might be missing and any other files I should read regarding > this, so far I have read most of tag.c, branch.c, > builtin/for-each-ref.c, parse-options.c. once again I hope I can get > the same amount of helpful feedback as when I submitted my > Microproject. > > My name is Brian Bourn, I'm currently a computer engineering student > at Columbia university in the city of New York. I've used git since > my freshman year however this past week has been my first time > attempting to contribute to the project, and I loved it. I'd > particularly like to tackle Unifying git branch -l, git tag -l, and > git for-each-ref. This functionality seems like an important update > to me as it will simplify usage of git throughout three different > commands, a noble pursuit which is not contained in any other project. > > Going through the annals of the listserve thus far I've found a few > discussions which provide some insight towards this process as well as > some experimental patches that never seem to have made it > through[1][2][3][4] > > I would start by beginning a deprecation plan for git branch -l very > similar to the one Junio presents in [5], moving -create-reflog to -g, > > Following this I would begin the real work of the project which would > involve moving the following flag operations into a standard library > say 'list-options.h' > > --contains [6] > --merged [7] > --no-merged[8] > --format > This Library would build these options for later interpretation by > parse_options > > Next I would implement these flags in the three files so that they are > uniform and the same formatting and list capabilities can be used on > all three. The formatting option will be especially useful for branch > and tag as it will allow users to better understand what is in each > ref that they grab. > > For the most part I haven't finalized my weekly schedule but a basic > breakdown would be > > Start-Midterm > Begin deprecation of -l > Spend some time reading *.c files even deeper > Build Library(dedicate Minimum one week per function moved) > > Midterm-finish > Implement the list flags > Implement the format flags > (if time is left over, add some formatting) > > Additionally I am thinking about adding some more formatting tools > such as numbering outputs. What do you all think of this? > > > [1]http://git.661346.n2.nabble.com/More-formatting-with-git-tag-l-tt6739049.html > > [2]http://git.661346.n2.nabble.com/RFC-branch-list-branches-by-single-remote-tt6645679.html#a6725483 > > [3]http://git.661346.n2.nabble.com/RFC-PATCH-tag-make-list-exclude-lt-pattern-gt-tt7270451.html#a7338712 > > > [4]http://git.661346.n2.nabble.com/RFC-branch-list-branches-by-single-remote-tt6645679.html#a6728878 > > [5]http://git.661346.n2.nabble.com/RFC-PATCH-0-2-RFC-POC-patterns-for-branch-list-tt6309233.html > > [6]https://github.com/git/git/blob/master/builtin/branch.c#L817 > > [7] https://github.com/git/git/blob/master/builtin/branch.c#L849 > > [8] https://github.com/git/git/blob/master/builtin/branch.c#L843 > > Regards, > Brian Bourn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [GSoC] Draft of Proposal for GSoC
Parts of v2, once again, i'd love some more comments on what I've rewritten On Fri, Mar 21, 2014 at 1:42 AM, Jeff King wrote: > On Thu, Mar 20, 2014 at 02:15:29PM -0400, Brian Bourn wrote: > >> Going through the annals of the listserve thus far I've found a few >> discussions which provide some insight towards this process as well as >> some experimental patches that never seem to have made it >> through[1][2][3][4] > > Reading the past work in this area is a good way to get familiar with > it. It looks like most of the features discussed in the threads you link > have been implemented. The one exception seems to be negative patterns. > I think that would be a good feature to build on top of the unified > implementation, once all three commands are using it. > >> I would start by beginning a deprecation plan for git branch -l very >> similar to the one Junio presents in [5], moving -create-reflog to -g, > > That makes sense. I hadn't really considered "-l" as another point of > inconsistency between the commands, but it definitely is. > >> Following this I would begin the real work of the project which would >> involve moving the following flag operations into a standard library >> say 'list-options.h' >> >> --contains [6] >> --merged [7] >> --no-merged[8] >> --format >> This Library would build these options for later interpretation by >> parse_options > Can you sketch out what the API would look like for this unified > library? What calls would the 3 programs need to make into it? > Something like this? Sample api calls Add_Opt_Group() Parse_with_contains() Parse_with_merged() Parse_with_no_merged() Parse_with_formatting() (each of the 4 calls above may have internal calls within the library in order to parse the option for each of the different function which may call these functions) >> For the most part I haven't finalized my weekly schedule but a basic >> breakdown would be > > Can you go into more detail here? Remember that writing code is only one > part of the project. You'll need to be submitting your work, getting > review and feedback, and iterating on it. > > One problem that students have is queuing up a large amount of work to > send to the list. Then they twiddle their thumbs waiting for review to > come back (which takes a long time, because they just dumped a large > body of work on the reviewers). If you want to make effective use of > your time, it helps to try to break tasks down into smaller chunks, and > think about the dependencies between the chunks. When one chunk is in > review, you can be designing and coding on another. This one I can absolutely understand, I tried to break this part down into very managable parts and give myself a little time at the end of each coding period to clean up each previous section. this slop time also allows for me to hopefully add some of the extra features that have been thought of. I'm thinking something like this makes it a little better, Weekly Schedule Start-Midterm Week 1- Begin deprecation of -l in git branch/establish exactly how long each stage of the deprecation should take. Spend some time reading *.c files even deeper while getting to know any current patches occurring in any area near my work files. Lastly, this week will be spent going through the Mailing-list finding previous work done in this area and any other experimental patches Week 2- Move Opt_Group callbacks for the functions into Library Week 3-Make a Contains Function in the library which will work for all three functions Week 4-Add Merge function in library Week 5-Add a No Merge function in library Weeks 7-8 spend time polishing the library and cleaning up the patches for final submission of library to the project Deliverables for midterm- Library finished pending polish and acceptance into the git repository Midterm Week 9- refactor all files to use the contains flag from the file. Week 10- use Merge from library in all relevant files Week 11-use no-merge from library in all relevant files Week 11-12- implement the format flags in all relevant files (this will be slightly harder as I think this might involve calling for-each-ref in the code for tag and branch. Ultimately there is a chance that part of the code for doing for-each-ref will end up in this library as well), additionally add in the code for formatting the relevant opt_Groups into the necessary files. Week 13-14 Polish patches via mailing-list and clean up all the refactoring of the files that has occurred.(optionally, add more formatting changes such as negative patterns and numbering each output into the library). Deliverables for Final- working library hopefully added into the code, and all of the relevant patches for using the library mostly
Re: [RFC] [GSoC] Draft of Proposal for GSoC
On Fri, Mar 21, 2014 at 1:45 PM, Junio C Hamano wrote: > Brian Bourn writes: > >> Something like this? >> >> Sample api calls >> Add_Opt_Group() >> Parse_with_contains() >> Parse_with_merged() >> Parse_with_no_merged() >> Parse_with_formatting() >> (each of the 4 calls above may have internal calls within the library >> in order to parse the option for each of the different function which >> may call these functions) > > This list is a bit too sketchy to be called "sample api calls", at > least to me. Can you elaborate a bit more? > > What do they do, what does the caller expect to see (do they get > something as return values? do they expect some side effects?)? so something like this would be better I'm assuming? Some basic sample API calls are found below, each of these would hold code to complete parsing and/or formatting the flags. Add_Opt_Group() - returns an OPT_CALLBACK with contains, merged, no-merged, or formatting which can be used in a commands options list. Execute_list()-the main call into the library and would pass into the library all of the necessary flags and arguments for parsing the request and executing it. This would accept the flags like -contain, with arguments such as the commit or pattern that is being searched for. The next four commands would be called by execute_list() to execute the original command with respect to the flags that are passed into this library. Parse_with_contains() Parse_with_merged() Parse_with_no_merged() Parse_with_formatting() -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [GSoC] Draft of Proposal for GSoC
On Fri, Mar 21, 2014 at 2:07 PM, Jeff King wrote: > On Fri, Mar 21, 2014 at 02:03:41PM -0400, Brian Bourn wrote: > >> > What do they do, what does the caller expect to see (do they get >> > something as return values? do they expect some side effects?)? >> >> so something like this would be better I'm assuming? >> >> Some basic sample API calls are found below, each of these would hold >> code to complete parsing and/or formatting the flags. >> Add_Opt_Group() - returns an OPT_CALLBACK with contains, merged, >> no-merged, or formatting which can be used in a commands options list. >> >> Execute_list()-the main call into the library and would pass into the >> library all of the necessary flags and arguments for parsing the >> request and executing it. This would accept the flags like >> -contain, with arguments such as the commit or pattern that is being >> searched for. >> >> The next four commands would be called by execute_list() to execute >> the original command with respect to the flags that are passed into >> this library. >> Parse_with_contains() >> Parse_with_merged() >> Parse_with_no_merged() >> Parse_with_formatting() > > Think about how the callers would use them. Will git-branch just call > Parse_with_contains? If so, where would that call go? What arguments > would it take, and what would it do? > > I don't think those calls are enough. We probably need: > > 1. Some structure to represent a "list of refs" and store its > intermediate state. > > 2. Some mechanism for telling that structure about the various > filters, sorters, and formatters we want to use (and this needs to > be hooked into the option-parsing somehow). > > 3. Some mechanism for getting the listed refs out of that structure, > formatting them, etc. keeping some of my function calls to do the actual work I think I settled on this A possible API is given below, each of these would hold code to complete parsing and/or formatting the flags. There will be a struct in the library called refs_list() which when initialized will iterate through all the refs in a repository and add them to this list. there would be a function which would retrieve ref structs from that function. Get_ref_from_list()- which would return a single ref from the list. Add_Opt_Group() - returns an OPT_CALLBACK with contains, merged, no-merged, or formatting which can be used in a commands options list. Execute_list()-the main call into the library and would pass into the library all of the necessary flags and arguments for parsing the request and executing it. This would accept the flags like contain, with arguments such as the commit or pattern that is being searched for. This will then parse the refs_list using the four commands below to make, sort, filter, and format an output list which will then be printed or returned by this function. Any Call into the API from an outside source would call one of the previous two functions, all other commands in the API would be for internal use only, in order to simplify the process of calling into this library. The next four commands would be called by execute_list() to further format the refs_list with respect to the flags that are passed into this library. These would also take the additional arguments from execute_list() such as patterns to parse or which commit to filter out. these calls would modify the refs_list for eventual printing. Parse_list _with_contains() Parse_list_with_merged() Parse_list_with_no_merged() Format_list() of course this would still depend on deciding whether or not we want to return to the original command to print or if printing can be handled by the library itself. > -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
