Jeff King [off-list ref] writes:
quoted
* Be nicer to the user on tracked/untracked merge conflicts
[...]
Sounds OK to me, though I agree the merging of untracked files is a
little controversial.
Yes. To me, part of the project is to identify cases where this is
actually not controversial (OTOH, it's a bit frustrating when I do a
trivial pull and Git complains because I already have the file).
quoted
+### Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git
+
+Most of git dotfiles can be located, at the user's option, in
+~/.<file> or in ~/.config/git/<file>, following the [XDG
+standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).
+~/.git-credentials and ~/.git-credential-cache are still hardcoded as
+~/.<file>, and should allow using the XDG directory layout too
+(~/.git-credentials could be allowed as ~/.config/git/credential and
+~/.git-credential-cache could be allowed as ~/.cache/git/credential,
+possibly modified by $XDG_CONFIG_HOME and $XDG_CACHE_HOME).
+
+Each of these files can be a microproject of its own. The suggested
+approach is:
+
+* See how XDG was implemented for other files (run "git log --grep
+ XDG" in Git's source code) and read the XDG specification.
+
+* Implement and test the new behavior, without breaking compatibility
+ with the old behavior.
+
+* Update the documentation
I think these might be getting a little larger than "micro".
The ~/.git-credential-cache may be a bit harder, but the case of
~/.git-credentials should follow the same pattern as files for which
this is already done. So, doing it by mimicking existing code shouldn't
be too hard.
But maybe that's me being optimistic ;-).
quoted
+### Add configuration options for some commonly used command-line options
+
+This includes:
+
+* git am -3
+
+* git am -c
+
+Some people always run the command with these options, and would
+prefer to be able to activate them by default in ~/.gitconfig.
The direction here seems reasonable, though I think we have
mailinfo.scissors already, so "-c" may not be a good example.
Ah, indeed. The documentation makes it a bit hard to find, but I'll send
a patch.
quoted
+### Add more builtin patterns for userdiff
+
+"git diff" shows the function name corresponding to each hunk after
+the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...),
+the way to find the function name is built-in Git's source code as
+regular expressions (see userdiff.c). A few languages are common
+enough to deserve a built-in driver, but are not yet recognized. For
+example, CSS, shell.
I am not sure that understanding the horrible regexes involved in some
userdiff counts as "micro", but OK. :)
I agree the regexes are horrible, but here also the project is not about
doing something really new, but reproducing what has already been done
for others.
At least, students not fluent with regular expressions have a pointer to
userdiff.c and can quickly see that the microproject is not meant for
them ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
On vr, 2015-02-20 at 11:06 +0100, Matthieu Moy wrote:
The ~/.git-credential-cache may be a bit harder, but the case of
~/.git-credentials should follow the same pattern as files for which
this is already done. So, doing it by mimicking existing code
shouldn't
be too hard.
But maybe that's me being optimistic ;-)
Having just copied that logic to one of my tools, I reaclly would have
fount if useful to have something that, given a config file name tells
you where it should be, maybe in the resident kitchen-sink that is
rev-parse:
$ git rev-parse --config git
/home/dennis/.gitconfig
$ git rev-parse --config gitk
/home/dennis/.gitk
$ git rev-parse --config foobar
/home/dennis/.foobar
Or, when XDG config files are used:
$ git rev-parse --config gitk
/home/dennis/.config/git/gitk
$ git rev-parse --config git
/home/dennis/.config/git/config
$ git rev-parse --config foobar
/home/dennis/.config/git/foobar
So, ~/.$filename or $XDG_CONFIG_HOME/git/filename, with a special case
only for git itself, with consistent selection of which to use
(currently gitk and git are inconsistent).
--
Dennis Kaarsemaker
http://www.kaarsemaker.net
On Fri, Feb 20, 2015 at 5:06 AM, Matthieu Moy
[off-list ref] wrote:
Jeff King [off-list ref] writes:
quoted
I think these might be getting a little larger than "micro".
The ~/.git-credential-cache may be a bit harder, but the case of
~/.git-credentials should follow the same pattern as files for which
this is already done. So, doing it by mimicking existing code shouldn't
be too hard.
But maybe that's me being optimistic ;-).
As a person who did a significant number of GSoC 2014 micro-project
reviews (as well as many actual GSoC reviews), I probably ought to
weigh in and say that this may be too optimistic. In fact, most of the
GSoC 2015 micro-project suggestions[1] seem far too large and
involved.
For 2014, most of the GSoC micro-projects were extremely simple, of
the form "replace starts_with() with skip_prefix()", yet most
applicants still required three or four (or more) attempts to get it
right (and some never did), even with extremely detailed hand-holding
reviews at each step. (And, such reviews are quite time-consuming. I
was allocating six to eight hours each day to those reviews, yet I
couldn't keep up with all the submissions.)
Although quite simple, many of the 2014 micro-projects[2]
(particularly from Michael Haggerty) had a bit of a twist (or trick
question) thrown in, requiring a tad more thought and effort than mere
mechanical search-and-replace. That was useful because it helped
identify potentially acceptable candidates more easily, however, that
added twist was probably a good upper limit on difficulty for
micro-projects.
Another important aspect of 2014's micro-projects was that they could
be accomplished with only very localized knowledge: that is, a student
could read the logic of the one function being touched and learn
enough to be successful. The micro-projects did not require global
knowledge of Git internals or hours of research.
The attitude in 2014 was that it was important for students to get a
taste of what it is like working on the Git project and what would be
expected of them as submitters, and for GSoC administrators and
mentors to get a feel for the applicants by how they interacted with
reviewers. By going through the review process on a project with high
engineering standards, it also was hope that students would learn and
benefit from the experience even if not selected. Extremely simple
micro-projects (possibly with a twist) in the style of 2014's were
more than sufficient to satisfy these goals, and were more than enough
to consume significant reviewer time. The suggested 2015's
micro-projects seem far in excess.
[1]: http://git.github.io/SoC-2015-Microprojects.html
[2]: http://git.github.io/SoC-2014-Microprojects.html