Re: [git-users] git with "bumper lanes" for basic users
[...] > > 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
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
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.
[git-users] git with "bumper lanes" for basic users
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.
[git-users] Recovery git from the crash HDD with local .git folder data
Hi The HDD crashed before which I had installed gitlab under container in QNAP. I try to recovery all git data (modification record and .git) from the local folder in my computer I had download. Now I have the problem to recovery the data. So far, I had bought new HDD and re-setup gitlab environment. In my opinion, I could just create a new git project and override the .git folder which should contained index and log. But the log only displayed the final changed after override .git folder, that is no log in new repository. Is any one can give me suggestion or keyword? Google always showed recovery from reset or delete but no similar case like me. Please give advice. Thank you very much. -- 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.
