On Tue, Mar 28, 2017 at 07:52:42AM +0200, Christian Couder wrote: > Hi, > > On Tue, Mar 28, 2017 at 12:17 AM, Devin Lehmacher <lehma...@gmail.com> wrote: > > Hello everyone, > > > > I am a student studying Computer Science at Cornell University. I > > already completed a microproject, Move ~/.git-credential-cache/socket to > > $XDG_CACHE_HOME/credential/socket a week and a half ago or so. > > Nice. It would be better though if you could provide a link to the > thread where your microproject was discussed. If it has been merged to > master, you could also provide the merge commit. Otherwise please tell > what is its branch name and current status in the last "What's cooking > in git.git" email from Junio.
Here is the merge commit into master: 78cf8efec34c419ecea86bc8d1fe47ec0b51ba37 > > I am interested in 2 different projects and would like some advice on > > them, to help me decide which one to submit a proposal for. > > > > 1. `git rebase -i` conversion. > > I was initially the most interested in this project but realize that > > after having a very busy week last week that Ivan Tham started > > [discussion][1] about this project. Would it be appropriate to submit > > a proposal for a project that someone else also wants to work on? > > Yes, it is ok. Obviously only one student/proposal can be selected for > a given project, but as anyway the main constraint for us is usually > the number of available mentors, there is a low chance that this would > prevent us from selecting one more student than we could otherwise > select. > > You could also submit 2 proposals if you have time to work on more than one. Ok! I think I will post rough drafts of both proposals sometime tomorrow or maybe later today if I have time. > > 2. formatting tool improvements. > > There are four different git commands mentioned [here][2] as possible > > tools to improve as can be seen in the email. Of those I think it > > would make the most sense to extend `git name-rev`. It seems best > > suited to the desired behavior. It would need to be extended to > > understand rev's that refer to objects rather than just a commit-ish > > and also add formatting support similar to the information that log > > and for-each-ref can output. Since this doesn't seem like much work, > > would it be feasible to generalize and somewhat standardize all of > > the formatting commands? > > Yeah, I think it would be good. It might involve a lot of discussion > though and this could slow your project. > So if you really want to do it, my advice is to try to start the > discussion as soon as possible, that is now. > > To do that you could for example Cc people involved in the email > discussions, and try to come up with concrete proposals about how to > generalize and standardize the formatting commands. I will try to send out an email later this afternoon with a preliminary plan and to start discussion about how best to rework formatting commands. Thanks, Devin
