Hello git community!

I wanted to reach out to suggest an idea I had for the git community. 
Apologies if this has already been discussed or this is not the right place 
for this discussion.  Quick background- I am a intermediate level developer 
mostly on web and python that has been using git for 2-3 years on projects 
with only 1-3 developers collaborating.

PROBLEM:  I understand that if you do everything correctly in git and 
follow all the norms everything works fine. But, even after 2-3 years using 
git I still sometimes take a wrong step and find myself in a situation that 
would be so complex to get back to where I was a few minutes ago, that I 
end up just deleting the entire repo and recloning from GitHub. This seems 
absolutely crazy to me.  I also hear more experienced developers doing the 
same thing, so I don’t think I’m alone here. I understand that “simpler” 
version-control systems have their own issues and that git's complexity is 
not frivolous. However… 

Wouldn’t it be great if there was a constrained version of git that you 
knew would NEVER let you get into those situations? 

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). 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. Then, we would eliminate all paths that led to those 
“traps” regardless of how much it crippled the actual usefulness of git 
(don’t worry, we’ll add it back in later). An extreme option for this first 
step would be to not let anyone checkout any other branches or commits, for 

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. Furthermore, we would 
not add them back in fully. We would develop new workflows that would be 
more constrained and only allow a more narrow set of user experience flows 
with low likelihood of landing in high complexity situations. For example, 
perhaps you could checkout previous commits but you were not allowed to 
change anything, or any changes were by default ignored and thrown away 
when you switch back to head. I know most people find it difficult to 
remove features and functionality, but this is a situation where the 
existence of too many features and options is making the product unusable 
for a specific set of users (newbies, low complexity situations, etc.). 

If anyone else has similar thoughts or would also like to see something 
like this (or if you know of someone that has already done this) let me 


Nate Jacobs
Mobile Platform Manager
Office of Information Technology, UCLA

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