On Fri, Oct 26, 2018 at 08:51:44AM -0700, nsjac...@g.ucla.edu wrote:

> Hello git community!


You might have hit a wrong venue to discuss your idea.
This particular community is concentrated on helping newbie Git users
solve the problems they have with _using_ Git.

What you would like to discuss apparently belongs to the developers'
list instead - as the devs do not participate in this community anyway,
and we here have no say in the question of the direction of the

So you might want to read [1] and proceed accordingly.

Still, I'd want to comment a bit on your proposal as stated.

> I wanted to reach out to suggest an idea I had for the git community. 
> Wouldn’t it be great if there was a constrained version of git that you 
> knew would NEVER let you get into those situations? 

I doubt so: to me, it's entirely unclear where you'd draw a line across
the continuum of all possible Git use cases so that all such cases at
the one side of that line are guaranteed to "never" ...

> SOLUTION: The idea I wanted to discuss is to fork git and create a “light” 
> version that constrains the functionality to avoid common pitfalls that I 
> and other users tend to get into (with some tradeoffs on functionality, of 
> course).

Creating a fork, IMO, is entirely unworkable. The reason is simple: even
though Git these days is not an exemplar of what you'd call fast-pased
development, still, it receives a hefty pile of features and bugfixes
during each of its release cycles. This means maintaining a fork will
either be a continuous uphill battle with keeping such a fork properly
tracking the upstream's development (and this includes extensive
regression testing!) or would rather quickly render it obsolete.

Instead, what I'd consider a proper path of the least resistance is
something around these two ideas:

 - Taking into account that all Git commands are grouped into the two
   layers: the "plumbing" commands and the "porcelain" commands.
   The plumbilg commands are the low-level ones, with their CLI "APIs"
   and output formats guaranteed to not change between Git versions
   or, at least, change only long after big red notices issued several
   release cycles prior to actually turning a breaking change on by

   The porcelain commands are what the users most of the time interact
   with. They are always implemented in terms of calling into the
   plumbing layer.

   Hence naturally it's possible to create one's own high-level Git-like
   system using the plumbing layer.

 - It's possible to arrange to "wrap" the porcelain-level commands, too.

   This may be fragile, but supposedly it's still easier to deal with
   than to maintain a true fork.

In both cases the added benefit might be in that the "new upper layer"
may be written in a language other than C.

> The idea would involve two steps to figure out how to best design such a 
> system. 
> Step 1 would be to create an aggressively constrained version that may not 
> be very usable but would completely solve this problem.  We would need to 
> analyze user stories and eliminate all paths to “traps” that people get 
> themselves into.
> Step 2 would be to add certain features back in that were axed when 
> idiot-proofing from Step 1. Only features that are absolutely necessary for 
> the majority of use cases for simple projects with low complexity in terms 
> of collaboration / workflows would be added back in.

Well, that's an interesting idea but I feel like being on the fence about it.

I consider myself to be reasonably experienced in Git, and, I think,
precisely _because of this_ I think that many people value Git exactly
for it being a Swiss Army Knife-type of a VCS. That is, it's possible to
do with it almost everything you could imagine you'd want doing with a
VCS. And that's not a speculative observation: I routinely split and
squash commits, work on detached HEADs and employ fine-grained staging
of the changes before commiting (with patch editing while doing so).

On the other hand, I do understand quite many people can supposedly live
without these tools available, and I may even fathom certain development
organizations may adopt workflows which do not employ them.

One may be tempted to propose for such people and organizations to just
use a different VCS but Git has really become a lingua franca of the
development comminity these days, so this might be a counter-productive
piece of advice.

Then, I'd consider your possible approach to be sound, but then the most
crucial properly of the solution to be implemented must IMO be a full
100% compatibility with "plain" Git. And this I consider to be a much
more interesting and hard problem to attack - rather than the problem of
picking the right set of "safe" features you've presented.

As one example immediately springing to mind is what your prospective
tool would do when, say, some power user rebases a branch and then
force-pushes the result to the central repo which everyone uses for
synchronizing their work? With vanilla Git one (usually) wants to rebase
their local work as well to reconcile their local state with those
changes. This immediately requires familiarity with rebasing and with
_why_ it's needed in this case, and the process of such rebasing might
result in conflicts, which is another great burden for our model
not-too-Git-savvy developers.

May be the solution for the prospective suite for such cases would be
as simple as just bailing out - disableing any further actions and
telling the user to call the local "go-to Git guy" for assistance, -
I dunno.


You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to