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
