On Fri, Oct 26, 2018 at 08:51:44AM -0700, [email protected] wrote: > Hello git community!
Hi! 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 development. 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 default. 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. 1. https://gist.github.com/tfnico/4441562#writing-an-email-to-the-developers-list -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
