Amate Yolande <yolandeam...@gmail.com> writes:

> .... I would like to
> work on the Unifying git branch -l, git tag -l, and git for-each-ref
> project for GSOC 2015 and I hope I can get more directives on how to
> move on with this project.

Hmm, the description on the ideas page looks somewhat sketchy.

    These three commands are all about selecting a subset of a
    repository's refs, and then printing the result. However, the
    implementations are not shared. Some commands know selection
    options the others do not (e.g., --contains, --merged), and
    others know formatting options the others do not (e.g.,
    for-each-ref's --format).

So, if I were a student to tackle this project, I'd start from:

 - Reading these three commands to understand how they currently
   work.

   For example, when I say "git branch -r --no-merged origin/pu",
   what happens, and how exactly does the codepath that is called by
   cmd_branch() in builtin/branch.c choose which branch to show by
   computing what?  Can a user customize how they are shown?  How
   does the customization specified by the user and what code
   actually allows the output to be customized?

   Do the same for other options "git branch" takes.

   What about "git tag"?  "git tag --contains origin/maint" may be a
   good starting point to think about, for example.

 - After doing the above, it would become clear to you that the
   three have different ways to specify what are chosen to be shown,
   and they have different ways to show their results.  What are the
   overlaps in them?  What is missing from what others that might be
   beneficial?

   Do we want "git for-each-ref --contains maint refs/heads/" to
   work, making "for-each-ref" borrow from "tag", for example?

   Do we want "git branch --format='%(refname:short) %(subject)'"
   to work, making "branch" borrow from "for-each-ref", for example?

   Once we have "git branch --format=..." support, can we express
   existing "branch -v" and "branch -v -v" output formats in terms
   of the new facility?  What, if anything, needs to be added to the
   format specifier you can give to the --format option as an
   argument?

 - Then write out the design based on the above preliminary study.

   How you want your new versions of commands to behave can be
   described by updating their documentation and also by adding
   tests (that would fail until you actually implement them) that
   expects the desired behaviour.

 - And then have fun time to code your design ;-)

The second paragraph on the ideas page reads like this:

    There have been experimental patches to unify the selection
    process, and some discussion on unifying the formatting. Based
    on this previous work, factor out a common library which can
    cleanly handle both selection and formatting, and use it
    consistently in the three commands.

I do not have pointers to these "experimental patches" offhand.  You
would want to dig the list archive and/or ask around to find them,
which would help doing the second step (i.e. after understanding the
current state of these commands, start designing what the unified
result should look like).

Have fun.

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

Reply via email to