Week 1: Unification of 'for-each-ref', 'tag -l' and 'branch -l'
Hello All,
As part of GSoC I'm working on the Unification of 'for-each-ref', 'tag -l' and 'branch -l'. I will update the list on my weekly progress in an effort to keep everyone updated.
Current Progress:
Currently I have been working on moving all code from 'for-each-ref' to an independent library called 'ref-filter' which would serve as a common library for the unification process. 'for-each-ref' supports printing the commits in a specified format and also various sorting optins. This would serve as a good base for porting over these options for 'tag -l' and 'branch -l'. I have sent v4 of my patch to the list and it can be found here:
http://article.gmane.org/gmane.comp.version-control.git/270293
I have been working on this after suggested changes, will post the next version soon.
Work In progress:
You can follow my current progress on Github:
https://github.com/KarthikNayak/git
For now I got the '--points-at' option (prints only refs pointing to given commit) and also '--merged' option (prints only refs whose heads are reachable from the given commit). These shall be forwarded to the list soon.
What to do next:
Implement '--contains' option, but the problem to be faced here is that both 'tag -l' and 'branch -l' have different implementations of the '--contains' options. Matthieu Moy suggested that I work on the unification of these commands let both the implementations stay where the user can select the implementation to be used and that I may work on unification of these two algorithms after the main objective of GSoC is met.
Any suggestion/changes are welcome.
Signature · 2 lines
Regards, Karthik
Quoted 3 lines · Karthik Nayak
Matthieu Moy suggested that I work on the unification of these commands let both the implementations stay where the user can select the implementation to be used
Just to be clear: my advice is the above with "user" = "caller of the API", not "human being using Git". In other words, "git branch --contains" and "git tag --contains" would still be using two different algorithms, but the user wouldn't notice (except for performance).
Signature · 2 lines
Matthieu Moy http://www-verimag.imag.fr/~moy/
Quoted 11 lines · Matthieu Moy
Quoted 3 lines · Karthik Nayak
Matthieu Moy suggested that I work on the unification of these commands let both the implementations stay where the user can select the implementation to be used
Just to be clear: my advice is the above with "user" = "caller of the API", not "human being using Git". In other words, "git branch --contains" and "git tag --contains" would still be using two different algorithms, but the user wouldn't notice (except for performance).
Thanks for clearing that out, I should have said "caller of the API."
Signature · 2 lines
Regards, Karthik
Quoted 10 lines · Matthieu Moy
Quoted 3 lines · Karthik Nayak
Matthieu Moy suggested that I work on the unification of these commands let both the implementations stay where the user can select the implementation to be used
Just to be clear: my advice is the above with "user" = "caller of the API", not "human being using Git". In other words, "git branch --contains" and "git tag --contains" would still be using two different algorithms, but the user wouldn't notice (except for performance).
Yeah, I think that is sensible. It should be a "feature" of the ref-filter that can hopefully go away one day (when we have a sensible implementation that works for both; this is something I've been meaning to push forward, but Karthik should not have to wait on me).
-Peff
Quoted 13 lines · Jeff King
Quoted 10 lines · Matthieu Moy
Quoted 3 lines · Karthik Nayak
Matthieu Moy suggested that I work on the unification of these commands let both the implementations stay where the user can select the implementation to be used
Just to be clear: my advice is the above with "user" = "caller of the API", not "human being using Git". In other words, "git branch --contains" and "git tag --contains" would still be using two different algorithms, but the user wouldn't notice (except for performance).
Quoted 7 lines
Yeah, I think that is sensible. It should be a "feature" of the ref-filter that can hopefully go away one day (when we have a sensible implementation that works for both; this is something I've been meaning to push forward, but Karthik should not have to wait on me).
-Peff
Sounds good, Thanks Jeff.
Signature · 2 lines
Regards, Karthik