Re: [git-users] git with "bumper lanes" for basic users

2018-10-26 Thread Konstantin Khomoutov
[...]
> > 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" ...

Sorry, I wanted to say something like «...guaranteed to never get the
user in trouble».

[...]

-- 
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.


Re: [git-users] git with "bumper lanes" for basic users

2018-10-26 Thread Konstantin Khomoutov
On Fri, Oct 26, 2018 at 08:51:44AM -0700, nsjac...@g.ucla.edu 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 

Re: [git-users] git with "bumper lanes" for basic users

2018-10-26 Thread Rick Umali
Hi Nate,

Check out gitless:

https://gitless.com/

I can't remember if I read about it in this group or in the main Git
mailing list, but it looked intriguing. The intro to gitless says: "Gitless
is a version control system built on top of Git. Many people complain that
Git is hard to use. We think the problem lies deeper than the user
interface, in the concepts underlying Git. Gitless is an experiment to see
what happens if you put a simple veneer on an app that changes the
underlying concepts."

Good luck!

On Fri, Oct 26, 2018 at 11:51 AM  wrote:

> 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
> example.
>
> 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
> know!
>
> Cheers,
> Nate
>
>
> 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.
>


-- 
Rick Umali / www.rickumali.com

-- 
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.