rn-71: add interview with Sergey Organov

Author: sivaraam

rev_news/drafts/edition-71.md

@@ -29,9 +29,118 @@ This edition covers what happened during the month of December 2020.
 ### Support
 -->
 
-<!---
-## Developer Spotlight:
--->
+## Developer Spotlight: Sergey Organov
+
+* Who are you and what do you do?
+
+ I'm a software engineer and system architect at JAVAD GNSS, working in its
+ Moscow Research Center, in Russia. We design (and manufacture) high-end
+ GNSS receivers, both hardware and software. Design and implementation of
+ receivers firmware is my primary job for about 25 years already. I'm
+ also responsible for the development tools our team is using, and that's
+ where GNU/Linux and then Git come to the picture.
+
+ Graduated from "Moscow Engineering Physics Institute" back in 1989 and
+ qualified in "Experimental Methods in Nuclear Physics", I was always
+ interested in computing. I then worked for about 10 years in "Kurchatov
+ Institute" in the field of computer modeling of nuclear radiation and
+ detectors, as well as in advanced processing of experimental results.
+ Then a few years later started to work for JAVAD as well, in parallel.
+ Then, a few more years later, left Kurchatov and entirely focused on
+ working for JAVAD full-time which is my current job.
+
+ Real-time embedded applications, also using Linux on the targets, is my
+ primary field of expertise nowadays.
+
+* What would you name your most important contribution to Git?
+
+ I didn't contribute much. I'd name the method of rebasing of merge
+ commits, that has been [covered in the Git Rev News](https://git.github.io/rev_news/2018/04/18/edition-38#general)
+ some time ago, as the most important one.
+
+* What are you doing on the Git project these days, and why?
+
+ Right now I'm working on `--diff-merges` options for `git log`. The
+ original stimulus was very surprising output of `git log -p -m` that
+ made me mad the first time I encountered it. After finishing initial
+ implementation of the `--diff-merges` options, I now aim at finally giving
+`git log -m` natural meaning of printing the diff for merge commits with
+ respect to the first parent only.
+
+* If you could get a team of expert developers to work full time on
+ something in Git for a full year, what would it be?
+
+ Actually, I have 2 favorites:
+
+1. Designing support for explicit commits grouping, somewhat similar to
+ grouping objects in graphical editors, likely implemented as a container
+ commit capturing particular part of the DAG. It'd be then seen as a
+ single commit by default, unless user specifically asks to look inside.
+ If we had it, our typical history would be more linear, feature branches
+ essentially becoming single (group) commits, that'd make history simpler
+ to traverse and to reason about.
+
+ Right now the only poor-man estimate for that is a branch that is merged
+ back to its origin (the true-non-evil merge, as I call it), that brings
+ history that looks like a sequence of bubbles, but it lacks direct
+ support that specific grouping feature would have.
+
+2. Designing new history editor that will aim at being ultimate
+ replacement for both `git rebase` and `git cherry-pick` that are
+ essentially the same thing at fundamental level. As useful as these
+ existing features are, they have wide opportunities for improvements
+ that apparently don't fit into the current design, and their history of
+ incremental adaptations to different needs made quite a mess of them.
+
+ Covering all the functionality of rebase and cherry-pick, the two most
+ important new features I'd like to see are:
+
+- Ensuring, by design, one of the primary features of any reasonable
+ editing tool: carefully preserve the content if no actual editing has
+ been made or requested. This should be ensured even if the tool is
+ forced to do the full job of re-creating the history according to the
+ instructions. I.e., the cycle: load/mark-as-modified/save should bring
+ the original result by default.
+
+- Better replacement for todo lists. Carefully designed format for
+ describing DAG in a text form convenient for humans and for editing with
+ text editor, with simple yet strictly defined syntax and semantics,
+ preferably supporting generic programming language features. For
+ example, it could be based on some existing language, say, Tcl. Yet it
+ should take the best features of the current format and look familiar
+ enough to be immediately useful without significant learning cycle.
+
+[That said, do we need two teams of expert developers for that, or one
+ would suffice, I wonder?]
+
+* If you could remove something from Git without worrying about
+ backwards compatibility, what would it be?
+
+ Support for octopus merges. Multiple (back) references could then be
+ reused for more useful things, like keeping history of rebasing, and/or
+ for commits grouping (see above).
+
+* If you could add something to Git without worrying about
+ backwards compatibility, what would it be?
+
+ I'd add a simple model behind Git command-line options, so that their
+ design came from the model rather than entirely from the use-cases, as
+ it happens to be now. It'd play similar positive role in UI design as
+ Git core data model plays in the features design.
+
+ Then, I sometimes think about addition of single NULL-commit, the
+ ultimate parent of all the Git commits all over the world. I'm not sure
+ it has enough value in simplifying corner cases in git implementation,
+ but it fits so nice into the elegant Git data model!
+
+* What is your favorite Git-related tool/library, outside of Git
+ itself?
+
+ Emacs and the Magit, its interface to Git, in particular, as well as a
+ few parts of Emacs generic VC interface that features Git among others.
+ The Magit got to the point already where I rarely find myself using Git
+ command-line directly, and then mostly for some batch-processing, or on
+ hosts where Emacs is not readily available.
 
 ## Releases