My favourite recent addition to Git Rev News is the developer spotlight interviews.
This edition's spotlight on Matthieu Moy is really interesting, as he talks about some of the changes he has helped implement in git, particularly in the user interface.
Q: How did you start getting involved with Git?
A: My first non-trivial contribution to free software was on version-control, before Git existed. I got involved in GNU Arch, then its fork Bazaar 1.x. And then GNU Arch and Bazaar 1.x died, and I moved on to something else. At the same time, I started teaching version-control, hated centralized systems enough to migrate to Git. Teaching Git in 2009 was a funny experience: the tool was starting to get a decent user-interface, but was lacking a lot of polishing. One of my favorite examples is what happens when you push to a remote that has commits that you don't have locally. Initially, users were getting a message like:
! [rejected] master -> master (non-fast-forward)
I wrote a rather straightforward patch to change it to:
! [rejected] master -> master (non-fast-forward)
To prevent you from losing history, non-fast-forward updates were rejected.
Merge the remote changes before pushing again.
See 'non-fast forward' section of 'git push --help' for details.
The students went from "Huh?" to "Wow, a 3-lines long message, that's long. What shall I do now (given that reading the actual doc is not an option)?". Then, I added an explicit mention of "git pull" in the message, and the situation became manageable for most students. Many of my contributions to Git follow this principle: see what users have difficulties with, and try to improve the tool to help them. In many cases, a staightforward patch to improve the error message was sufficient: in case of error, explain what's going on to the user, and give the way out ("did you mean: ...?" or "use ... to ...").
1 comment
[ 2.6 ms ] story [ 14.2 ms ] threadThis edition's spotlight on Matthieu Moy is really interesting, as he talks about some of the changes he has helped implement in git, particularly in the user interface.
Q: How did you start getting involved with Git?
A: My first non-trivial contribution to free software was on version-control, before Git existed. I got involved in GNU Arch, then its fork Bazaar 1.x. And then GNU Arch and Bazaar 1.x died, and I moved on to something else. At the same time, I started teaching version-control, hated centralized systems enough to migrate to Git. Teaching Git in 2009 was a funny experience: the tool was starting to get a decent user-interface, but was lacking a lot of polishing. One of my favorite examples is what happens when you push to a remote that has commits that you don't have locally. Initially, users were getting a message like:
I wrote a rather straightforward patch to change it to: The students went from "Huh?" to "Wow, a 3-lines long message, that's long. What shall I do now (given that reading the actual doc is not an option)?". Then, I added an explicit mention of "git pull" in the message, and the situation became manageable for most students. Many of my contributions to Git follow this principle: see what users have difficulties with, and try to improve the tool to help them. In many cases, a staightforward patch to improve the error message was sufficient: in case of error, explain what's going on to the user, and give the way out ("did you mean: ...?" or "use ... to ...").