This is the root of the author's issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: https://news.ycombinator.com/item?id=25002318) is the complete opposite: a system that knows it's connected to other people, where changes are instantly propagated and easily visible, where the differentiator between "branches" is not "what computer does it reside on" but "who did it". That's the model behind GitHub, after all.
git is complex because it's working with a very complicated model that is not in line with what most people expect today. As I said in my other comment it seems that fossil works with that flow, but I haven't tried it. However what is sure is that it doesn't make sense to ask git to become what it fundamentally is not.
EDIT: There might be a solution with wrappers. When you look at git-annex assistant (https://git-annex.branchable.com/assistant/) you can see that the right amount of abstraction can provide something closer to what we expect... but at this point it's not git anymore, so we might as well start from scratch.
>Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it?
Is a Github problem, not a git problem. You might as well ask how to unsend an email. If you don't know what git push means, you shouldn't be using it and are playing with intellectual property fire.
The conflation of Github with git is responsible for a lot of confusion. Having Github be your first interaction with git is a disaster.
Regardless, there's no shortage of blog posts complaining about git being hard. But there is a shortage of effective, popular competitors. I think that, actually, many-chefs many-branch differential version control is just a hard problem and creating a simple model for it is much harder than complaining about git.
I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. The whole point of computers is to do things for people.
With physical messages, unsending has at least partial support. Before the mailman picks up from my porch, I can grab a sent message any time. If you FedEx the envelope, you can cancel before delivery. With a university's mail system, you can get the receiving department's admin to return something even later in the chain. And of course, you can always tell a recipient, "Hey, I sent you the wrong box, just send that back."
The reason email doesn't support unsending is not some essential property of messaging. It's just that at the time our email protocol was defined, both our hardware and software was pretty primitive, so we locked in a very primitive model of messaging. But note that more modern systems, like Slack and Facebook Messenger, happily let you unsend things. And consequently, they're effectively replacing email for most users.
I think you're twisting the problem statement a little here.
Asking "How do I unsend an email" is just as unreasonable as asking "Hey, give me that gift I gave you back".
The problem is that, regardless of your intent, you've given something to someone and they own it now.
You can't undo that without involving the 3rd party (Or breaking the law and stealing it, digitally for the email).
And I want to be clear upfront - THIS IS A GOOD THING.
I don't want Amazon to be able to "unsend" my receipts. I don't want Google to be able to "unsend" my support chat log. I don't want my boss to be able to "unsend" his approval for my time off.
This system is designed explicitly to put the USER first. But it treats each side of the exchange as user, and values them equally - If they disagree, it's not the system's job to resolve that, they have to talk it out.
Slack and Messenger (and a lot of other modern chat) have an arbiter - They don't require users to agree because they own the content, not the users. In a company slack, I haven't given you anything when I message you. I've just pinned something to the company message board. I can take it down, and so can anyone else who has the key. It's not mine and it's not yours - It is very clearly owned by the company.
That can work great in a well structured environment, but I have to laugh when you say its replacing email. It's not a replacement, it's a complement - They are not the same things.
Just like an oral promise with no witnesses is NOT the same as a signed receipt. Use each as needed.
I think you're missing the forest for the trees here. The point of version control systems is to make developing software easier. It's a tool that exists for the convenience of its users. It's reasonable for people developing software to ask for the ability undo a change or restore a repository to the way it was a second ago. Telling a team of people using Git "it doesn't work like that" is unhelpful because it's not impossible for a version control system to work like that and the point of any software is to help them do what they're trying to do.
This doesn't mean that Git has to accept any feature under the sun and it might be that Git isn't most appropriate tool for teams that want such a feature. But there's nothing holy or fundamental about an implementation detail of how Git does things that makes their use-case hard.
> But there's nothing holy or fundamental about an implementation detail of how Git does things that makes their use-case hard.
Yes, yes there is.
I've worked in systems like you're describing (CVS, SVN) - The problem is that they ALL require locking.
Locking freaking sucks. It sucks SO INCREDIBLY MUCH more than dealing with the complexity of a real distributed system that git won, even though its cli interface is a god-damned nightmare.
You clearly haven't had a co-worker lock a file you need to edit and then go on vacation.
VCS exist to make it possible to organize and track changes to project source code. Convenience of the user is a secondary goal to clear organization and code management.
A VCS shouldn't be unnecessarily difficult to use, but the fact that this conversation around Git's UX is endlessly rehashed is proof that version control is a hard problem.
If there was an easy and obvious 10x improvement over Git it would have replaced Git by now. Or to put it differently, when someone makes an easy 10x improvement over Git, it will see widespread adoption.
I don't think that last bit is necessarily true. Git has strong network effects, and people are generally very conservative about tools like source control. Git also has the benefit that there are a lot of people used to its quirks, and that skill investment makes them feel fond of it.
The same was true with the switch to WYSIWYG OSes and word processing tools; they were generally liked by people new to computing, but people who were steeped in the old ways, many switched only reluctantly.
> I have to laugh when you say its replacing email.
Laugh all you like, but kids and the interns I've chatted with see email as something akin to how I feel about fax machines: not something they'd use by choice, but necessary for historical reasons. When I've been at organizations during a Slack adoption, email volume drops hugely; 50-80%, I'd guess. I've closed most of the mailing lists I used to run because they shifted to mediums better suited. Just this morning I had to FB message a few friends to get their current email addresses, which tells me a lot about who's winning.
Yes, I agree there are times you don't want things unsent. And there are times you do. There are a variety of ways to balance these concerns. But exactly none of them involves saying, "Lo it was handed down to us by Postel the Wise, and none shall tamper with His choices."
Asking to unsend an email is a reasonable request. The answer could be yes or no given the circumstances, but it's only an absurd question to people who have taken a 1980s technological choice and treat it as some sort of unalterable gospel. It reminds me of this Douglas Adams quote:
"I've come up with a set of rules that describe our reactions to technologies: 1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. 2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. 3. Anything invented after you're thirty-five is against the natural order of things."
Sure, I get that a lot of people were born after RFC 822, so it seems like the natural order. But the people who wrote the early RFCs weren't thinking that way, and neither should we.
I have no problem with using Slack or Hangouts or Discord or some other chat solution while at work. I also tend to use discord/steam for throw-away conversation with friends.
At no point did I appeal to authority or history in my argument above, so drop the shit around
> "Lo it was handed down to us by Postel the Wise, and none shall tamper with His choices."
---
If you think Chat apps are winning, let me know when you can buy an item online without an account linked to an Email. I'd love to see an example.
You jumped into a discussion. The person I replied to was treating the email we happen to have as some sort of unchangeable given. That's what I am objecting to. If you are disavowing that side of his argument, feel free to say so, but it looks to me like you lean pretty heavily on it.
> let me know when you can buy an item online without an account linked to an Email. I'd love to see an example.
You mean aside from the billion or so users of WeChat Pay?
> [Chat apps] can work great in a well structured environment
> Use each as needed
> I also tend to use discord/steam for throw-away conversation with friends
Yes, clearly I'm only advocating for the use of email in its current form for all communication, see me lean so hard above?
---
Wechat might as well be the Chinese government, and it requires a Chinese/Hong Kong bank account to use Wechat Pay. If the government won't honor your transaction record, keeping a copy yourself isn't very useful...
Ok, this one is entirely fair, but also I'd argue the circumstances around it are a little different.
Given how tightly integrated wechat is with the chinese government, and the restriction of wechat pay to use with folks who have a Chinese/Hong Kong bank account, we're talking about different levels of utility around preserving the record.
If the government chooses not to honor your transaction record, it doesn't really matter if you have a copy yourself.
> The reason email doesn't support unsending is not some essential property of messaging. It's just that at the time our email protocol was defined,
email supports unsending in exactly the same ways you described for packages. It most definitely is a property of messaging.
Your fron porch is called "outbox". works the same - you can delete from outbox before sending.
If both you and your recipient are on a properly configured Microsoft Exchange server, you can unsend a message, which is similar to the university department.
And if you aren't, you can still send a message saying "hey, please don't open the last email", and it's up to the other side if they do or don't.
For better and worse, email has a lot of similarity to real mail, down to the distinction between content and envelope.
The main difference is the speed of delivery - you would not expect any of the ways you suggested to work 3 months after you've sent your package -- and yet, compared to the 500ms or so that it takes the email to reach the recipient, that's what attempting to unsend after one minute is.
You can’t unsend an email because you can’t force someone else to delete something. Emails end up as files on someone else’s server. Claiming this is a UX issue is intentionally missing the point. If this is legitimately a foreign concept to you, an afternoon setting up postfix and playing around with it might be worth your time. Email is a protocol, not a program. A “delete” request would be just that, a request.
You can “unsend” on those platforms because the GUI does not display files saved locally, it always fetches them from the server. If you could “unsend” on a version control platform, then it would cease to be distributed version control. The code would have to live inside the VCS app (the same way messages are in memory in slack), or you’d have to give a network daemon delete privileges on your file system.
Imagine if youtube-dl used the model you’re proposing. Letting the git equivalent of “unsend” propagate through the system takes you from a redundant system to, not a system with a single point of failure, but even worse, a system with many points of failure.
Git is for helping develop open source projects, where sometimes a random gal who will never show up again fixes a small thing and sends the maintainer the diff through email. If you want a tool for the high trust environment of your individual team, git will never be what you want. It literally wouldn’t work for its intended workflow if it did what you want.
> Emails end up as files on someone else’s server.
When I use my Gmail account to send an email to another Gmail user, this is obviously not the case. Many adults in their twenties have never used a desktop email application - at my company the younger new hires need some time to figure out how to use Outlook, and they're engineers. They've grown up with the cloud as a given, local storage as the exception, and centralized messaging apps as the default method of communication.
I'm not going to argue about whether way of thinking about computing is any better or worse, but undeniably convenient, and it's definitely the direction we're headed.
Thanks for the explanation, but I ran mail servers for ~25 years. I am familiar with the technology, and in the mid-90s even wrote a chapter of a book explaining email. And I've been using version control even longer. Maybe try rereading what I wrote without the assumption that it comes from ignorance.
I think your comments are coming from ignorance, though.
Without trying to be snarky - All your comments directly ignore that what you're proposing values one stakeholder more highly than another.
People keep pointing out that there are two users involved in this exchange, and they both weigh equally, and you dismiss them and talk about running mail servers 25 years ago (who cares?).
You keep saying "I should be able to unsend my email". Let me rephrase your question - Why should you be allowed to delete my email?
I have in fact never said "I should be able to unsend my email". Once. In my life. Please try to argue with my actual points; I don't have time for straw men.
>Asking to unsend an email is a reasonable request. The answer could be yes or no given the circumstances, but it's only an absurd question to people who have taken a 1980s technological choice and treat it as some sort of unalterable gospel.
---
We're here answering affirmatively that "No" is the right answer for a LOT more reasons than an appeal to authority and history, and you accuse me of a strawman?
Yes, I am indeed accusing you of a strawman. You seem very much in the discussion to win it, whatever that means to you. I can only hope that, having decided you are victorious, you'll now leave me alone, because none of your comments seem particularly productive to me.
>I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer.
You don't understand because you think you're fighting computers but you're actually at odds with other human's desires.
If I pull your code, even if it was a mistake I don't want you to later rip the rug out from me and force me to figure out what happened from the history you deleted.
You can easily change the history technologically. You just force push what you want. The issue is that is usually disabled because it causes a lot of problems for everyone else on the team.
That's a plausible reason, but it's definitely not what the person I was responding to said. "There are user reasons that won't work," is a very different answer than scoffing that the person asking the question just doesn't understand the underlying technology.
I also don't think what you said is necessarily true. If person A has pushed and nobody else has pulled, then for most situations there's no reason to prevent A from un-pushing. Even if person B has pulled, a propagating un-push might well be what they want. I generally would. There are certainly some cases where B might not want that, but given that undoability is a has become a strong user expectation, I don't have particular reason to believe that balancing users needs would come out in favor of the current behavior.
>I don't have particular reason to believe that balancing users needs would come out in favor of the current behavior.
Gitlab and Github (rightfully imo) came to this behavior. It was not random and is not the default git behavior which is to just allow the force push and all the chaos afterward. If you don't like it, mark your master branches as unprotected. However, there's clear reasons for the current defaults.
Technically, I think their problem is assuming that it's acceptable for there to be such a entity, not that one necessarily exists. And then misinterpreting/misrepresenting git's semi-intentional exclusion of such a entity as a bug when in fact it's a feature.
I'm not sure that that such an entity is truly necessary to get a lot of the functionality. However, in the case of git, I'd guess 95% or more of users in effect do have a such an entity. Github is $7.5 billion worth of proof that most people are cool with effectively centralized source code management.
> I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. The whole point of computers is to do things for people.
If you try to do that too hard you run into the task automation problem:
I don't see what it's got to do with github. I had the same need, and the same confusion solving it, before I had ever used github, when I used a locally hosted git server of some kind for my team.
Do you mean it's a problem only if you are "git push'ing" to a remote shared by those working on a software project?
OK, maybe. Even before github, most projects I knew of using git used that method. You can suggest nobody should, and try to educate people in a completely distributed workflow if you want, I suppose. That's not about github really.
They're complaining about git and the very first thing they discuss is how git interacts with a completely separate piece of software. Push doesn't have to be to Github, it can also mean sending an email. Obviously you can't undo that.
The Github-first problem is viewing git merely as an interface to Github, where the home of the work is and where all things are collected and operated on. From this it follows that git push is a fundamental operation like add or commit. And from this follow complaints that git commit isn't something that sends your changes to the One True Repo.
If you push then you should give up any expectation of control or ownership over the code that's sent over the communications protocol of choice. Purging a file is nice for you but in action would be a force-pushed rebase that you have to ask people very nicely to use instead of the initial branch. Controlling what branch other people use is completely out of scope for a local VCS.
The blog continues on to say that the distributed nature gets in the way of the mental model.:
>they have never even considered that there’s such a thing, because why would they? A branch is just a single concept in our head that is made complicated by the inherent distributed nature of Git.
And that's just the wrong model to have, inspired by understanding git through the lens of Github. If you're using git and you're unaware that you're operating on your local copy, not a shared workspace, then you can't place much stock in whatever mental model you come up with.
OK, I understand you think the way most actual use of git I have observed takes place is "the wrong model to have". That is an opinion you can have, and you can try to convince people of it; to be succesful at doing that, you probably want to understand what motivations and pressures lead to this style of use in the first place; why do you think so many (from my view, the majority of git users), choose to use git in this "wrong" way?
It still has nothing to do with github specifically. It is also true of people using gitlab. Before github existed, I (and many other teams I know) used a variety of other ways of hosting a remote git server shared by the team, including various open source software with web UI, as well as no web UI at all, remote git accessed via ssh (`ssh:` git urls) with no other UI.
The issue applies to all of them. And again most teams I knew were doing this before github existed. It applies to teams using gitlab or bitbucket or other in similar ways now too.
I still don't thinkit makes sense to blame github specifically , as I believe you are doing, for the way most teams choose to use git -- since before github existed, and still now using a variety of software choices in addition to github.
It's not specifically github, but I believe this wrong mental model was greatly popularized by it. Until GitHub rose to fame a project had reasonable chances to pick mercurial, or sometimes SVN; today the default is git on GitHub. That is the issue: when you choose a tool not because it's the best at what you want to do, but for other (very good) reasons: it's popular so you'll find help easily, more people will interact with you, etc...
So, no, GitHub didn't create this, but it made it default
sure, but that 30s timer is an incredibly useful feature, when you misclick, when your cat walks on your keyboard, when you remember that you forgot $RANDOM_THING, etc etc
This only works because you can configure gmail to send email on a timer instead of immediately.
Also, may I kindly suggest that you aren't putting enough thought into your emails? That may be fine for single-recipient emails (depending on your environment), but when your email is received by many people it's an unkind act that shows disregard for the recipient's time and attention.
If you were before the github, you would not expect an ability to un-push changes. If you were doing development back then, you are likely familiar with "ftp" (or maybe "sftp") and using it to upload files. Or maybe with CSV or SVN.
Question from the blogpost: "I git pushed and I want to undo it"
Compare with: "I uploaded the file on the server with FTP, overriding previous version. How do I undo this?"
Or: "I did 'svn commit', how do I undo this?"
Or: "I have sent an email. How do I un-send it?"
I am not sure where does the original author's expectation that you can undo any action comes from. "thrwyoilarticle" seems to says this is because they started from "github" interface which has nice friendly UI which warns you about actions which cannot be undone. This sounds reasonable to me.
Right, it's also because github guides people into a history-only flow instead of rebase / force-push. Casual github users know they should follow the tree with pull and don't know what fetch is.
With history if you make a vcs mistake, or realize iteratively after pushing that corrections are needed, your worthless threshing around trying to fix it becomes part of your project log forever, instead of just pushing the corrected tree with just the one corrected patch.
I spoke to a person that didn't like rebasing who said that the threshing didn't matter because nobody reads the history. But for me it's one of the first tools I reach for when I find a bug or confusing code, trying to understand the intent. I see that as a fundamental difference in how the problem space is viewed and that they're stuck with a Github-first point-of-view. To me, even with merge commits, the history should be a statement of intent and treated as a first-class citizen, or even the primary output. Pushing a branch with threshing is like sending an email with visible backspaces.
Completely agree, a change is an atomic change and should be contained in a single commit, I don't need to know the sub-steps it took to arrive at the final solution when I'm trying to blame or log the reason it changed 6 months from now. It also encourages bad commit messages which further confuse change history and motivation when you're creating separate commits just to fix formatting and such in your real change.
I have been using git for years, and have never rebased once. I'm kind of scared to try, perhaps irrationally. Rebasing seems to change commit relationships in a way that seems like it may be difficult to untangle if it later differs with someone else's clone.
I would also like the ability to see a nicely curated set of changes. This mostly exists in the diff tabs of a pull request. If this were to be a first-class feature in git, it seems appropriate to be in some layer other than commits, but alas, that doesn't exist.
Is there a reliable way to know whether any of the involved commits have been pushed anywhere? I would probably usually know off the top of my head, but not always.
> I spoke to a person that didn't like rebasing who said that the threshing didn't matter because nobody reads the history. But for me it's one of the first tools I reach for when I find a bug or confusing code, trying to understand the intent.
If it's rebased then you're not reading the history; you're reading an artificial modification of what actually happened, performed by someone (possibly past-you) who thinks they know more about what you're trying to do.
I don't rebase precisely because I want to read the history to see what happened.
It's not about the object database, it's about what you see with git log.
History flow will show all the meandering around forever, but rebase will remove it and just put the most recent version of the commit on top of the tree. Ie, your log looks like you pushed just the perfect patches each time, every time, and the junk is gone.
Mercurial has solved this quite elegantly. The Evolve extension is basically standard functionality and all changesets (commits) have a state: secret, draft, public. You can share the changesets and you can "prune" them, which basically tells the world that if they have a changeset with that hash to delete it.
> If you don't know what git push means, you shouldn't be using it and are playing with intellectual property fire.
Whether you realize it or not, that's gatekeeping. The point of UX is to remove artificial gates. When people apologize for the gates instead of fixing them, well... That's tantamount to threatening people's livelihood. It's a lot easier to do that when you don't think of it that way, and it probably shouldn't be easy. "I understand it, you shouldn't work here if you don't" is literally, "Fuck you, I got mine," with different words.
> about git being hard. But there is a shortage of effective, popular competitors
There is only so much oxygen in a room. There is not space for a million solutions to every problem, and once the Hype Train has left the station all you have left is to make the fiction true, or try to accelerate the Trough of Disillusionment so we can get on with fixing the problems instead of deflecting.
And I say this as the only person on a large team fit to do anything approaching surgery on screwed up git repositories. There is frequently a degree of turf protection via "he's a bastard, but he's our bastard". No, he's just a bastard. I don't claim any responsibility, I just have to interact with him.
Not just Github. Having any GUI be your first interaction with Git is a disaster. Right now the only way to learn Git is via book or man page, and command line. All the decent GUIs I have used assume you already know Git. They are great and powerful, but they don't help at all with the onboarding process. If you know of one, please share. I had to stop using GUIs completely and learn with Git command line. Then the GUIs made sense.
Rather than a problem with GitHub, I think it's more just a problem of dominance. Git was originally designed for a work environment where people weren't on the same network, or any network at all when making code edits. At the same time, everyone wanted a copy of the history that they could change themselves to mirror their work. So we needed a tool which could be distributed, not require a regular network connection, and still enable people to share changes and view the entire history of a project.
Git was primarily adopted because it solved those issues which were important ones at the time, people discovering git needed those tools and when discovering git would naturally come across and understand the trade-offs. IE: "I can't easily undo a change once it's on someone else's machine, instead I would need to issue a new change reverting it. But that's ok, because it means I can do as I like on my machine without screwing up the history for other people and only send a patch of specific changes when I'm ready."
The issue people now face is git has become so popular, because of those initial reasons, and we're dealing with a new set of problems which git never cared about.
"Project X is in a git repository, and I want to contribute a change".
This is a fundamentally different problem to the original problems git tried to solve. We're now in this weird space where most people using git are only using it because: it's what they already know, or the project they want to work on already uses git.
Requests like "I just pushed a change and didn't really want to" don't make much sense and don't matter much in the original use cases. Now many git projects use centralised hosting and a lot of people don't really care about git, just getting their work done, we now have this UX issue. The UX issue isn't a result of poor design or implementation in git, it's due to the motivations of users being fundamentally different now.
Sure you could argue that git should change or be easier, but then it would stop serving the original purpose. If people want a centralised source control with the ability to easily retract changes and have branches be the same across all nodes then really they just don't need what Git sets out to solve.
The issue is git is now dominant, and that forces people to use it even if they don't have the problems that git is really attempting to solve. That means they're stuck in a place of using a tool so they can collaborate, without getting any of the benefits of it. That's enough to drive anyone insane! It's like pushing a boat across land to get to another village when a boat is really to get to another continent, but no one makes cars because everyone's already boats.
We don't need "better" UX for git, we just need people to know about all the options, and part of that may include encouraging some people to choose more centralised options when it's a better fit for them.
My previous and current company use perforce but many people (often those who recently join) are decrying that perforce is less elegant than git, but, realistically and based on your own criteria it would be "better" for the connected case.
I'm personally a big fan of 'offline/local-first' being a thing, but I'm a sysadmin not a developer.
I use Perforce everyday since it aligns better to the needs of the games industry.
I have my problems with it, but once you understand it I find the workflow quite simple.
If you don't really need the decentralization I think it aligns quite well with how people expect version control to work. You make edits to your data, once you're done, you send them to the server to be shared with other people.
I’ve had to use perforce before and was not a fan. Granted, I didn’t have to use it full time and can’t claim to be an expert, but I hated the notion of locking files, change lists, yuck. All of it felt so clunky compared to git.
Funny - I used P4 for about 7 years before switching to Git 2 years ago, and Change Lists are what I miss most from P4. For me it is extremely common to work on multiple changes in parallel, on the same branch or different branches, and organizing my changes in different change lists was the best way to handle it.
I also find git's default of rewriting your worktree when you switch to a different branch extremely annoying compared to simply having each branch be a different directory in the FS. Fortunately, digging around I recently discovered git worktree and I'm much happier on this front at least.
The file locking was always a relatively obscure workflow, so I'm surprised that you even had to see it if you didn't use P4 a lot. I've only seen it in 3 occasions: working with binary files, the error message when I didn't actually have write access, and when someone intentionally locked some files to make sure they don't have any merge conflicts while they finish up a huge commit.
Locking files is critical when you are editing binary data which can't be merged - which in the games industry, is generally how the majority of the dev team works.
I’m not sure locking files is as important as all that. You “check out” files, but nothing prevents anyone else “checking them out” (which is perforce parlance for: “make editable”) - conflicts can be resolved.
There is locking but it’s seldom used- handy in the gaming industry for code which depends on data.
As cecilpl2 commented - it's the typically the binary art assets (occasionally other files) which are unmergeable which need the exclusive lock turned on. And of course you want to avoid branching those too in many cases.
Never used it but I had to use ClearCase at work even though I was already proficient in git.
Ugh. The centralized model is better for companies, but ClearCase really makes its best to make your life miserable:
- You have to think twice before modifying a file, because the steps to be able to modify a file can take from 30 seconds (if you already created the activity) to a few minutes (if you have to create it)
- Activities are supposed to be like branches, summing up all the changes. But there is no way to see all changes in one go. It's click everywhere, waiting for the server to reply on each click.
- Because there is no way to display the branch content in any way other than envisioned by IBM, there is no way to discuss a changeset. No pull requests, no exchange, nothing.
- Horrible UI/UX all around. It's slow, it's unreadable, random bugs happen all the time where the only fix is to restart the service, .... and it's expensive.
I'm not advocating for a system that only works when online (although the fully integrated system of Google does sound good), just that it be architectured around a point of centralization. This is the way I'd like to use git:
- A branch created locally will be synhcronized and visible to everyone by default
- A branch that I manually tag as private won't, but it will still be saved on the server
- A branch that has a conflict between me and someone else will be marked locally in some way (maybe a second branch ?)
- Bonus: my working repo and staging area are also synhcronized to the server
At my current job, I had to create a command-line tool just to be able to checkout things from perforce. It is ridiculous how difficult the UX is for this. And companies are still paying for it!
Not just that, they seem to suggest Github created Git...
> the quality of the tech that is Git is a testament to GitHub being able to make it this far in the tech space
But in reality, Github makes Git more complex, because now you have to understand the concept of forks. Not only is there your local copy and an origin, there is a 3rd repository in play.
What other structures would work for having a public forum for PRs?
I'm having trouble coming up with many that would be compelling enough to make that change, especially once you consider bad-faith actors in there (eg, I can't flood your git repo with my nonsense, because my code doesn't exist in your repository until the PR is merged)
I spend too much time doing archaeology to support squashed PRs, which eliminates a few alternatives I might otherwise suggest.
They could have added namespaces to branch names. Right now branch names are just a free-for-all. Instead, if they insisted that branch names are always prefixed with "username/", then you wouldn't need forks and anybody could freely submit code to any project. PRs would become MRs.
I believe this is how most Git repos are managed within organizations. I'm not sure why public repos need to require users to fork things to propose changes.
I think we're all still dancing around a blind spot, where we want eventual, Pareto Principle consistency (where a consensus is formed around 10% of edit histories, many others require only a consensus of 2, and the rest are backups that require a consensus of 1)
We're trying to assemble this from different pieces, without a clear idea if we can even get there from here, given all of the roadblocks Information and other Theories throw in the way.
I hope someday we meet in the middle with systems that can handle code and incidentally a bunch of other problem domains we also care about.
> a system that knows it's connected to other people, where changes are instantly propagated and easily visible
We have this already. It's called collaborative desktops over VNC ...
> the differentiator between "branches" is not "what computer does it reside on" but "who did it"
So you're into collaboration, but not on branches? I would have said branches related to specific units of functionality, streams of development or specific issues.
Definition of branches aside, this is the way old-style centralised VCS like CVS, Subversion actually work - and you can still use SVN if you want to ... or you can use git in that manner and never have to worry about it's more complex details.
The whole point of Git is that it addresses the specific problem that once you are disconnected you de facto have a branch. Once you push to remote its more like that ideal you're reaching for.
> at this point it's not git anymore, so we might as well start from scratch.
I'm sorry this is really quite hilarious. Go! Stop whinging and go do it!
I don't understand the negativity. I'm not saying that git is bad, or that git sucks. It is what it is, and not wat most of the people really want.
> We have this already. It's called collaborative desktops over VNC ...
We still want a revision control system, things like commits and all.
> So you're into collaboration, but not on branches? I would have said branches related to specific units of functionality, streams of development or specific issues.
Depends on the workflow. Many people have long-lived branches, introducing big features/refactorings. Many other prefer short-lived branches, where one branch typically is used by a single person. I still think branches should be focused on topics, but the topic (and thus the branch) must be the same on all computers, instead of having one version locally, another one that is mapped to it but potentially has different content on the server, and 1 different branch per other user. How many times have we had to "oh you pushed on your branch, I have to get it first"
> Definition of branches aside, this is the way old-style centralised VCS like CVS, Subversion actually work - and you can still use SVN if you want to ... or you can use git in that manner and never have to worry about it's more complex details.
Yep, that's the model: one place where people synchronize. The issue with those was not the centralization (look at GitHub), it was the lock mechanism. I can use git to replicate it, or I can use the folder.bak and folder.v1.final on a NAS method. It's not because it's possible that it's desirable
> I'm sorry this is really quite hilarious. Go! Stop whinging and go do it!
Ah, so it's not possible to criticize work until we have developed a complete alternative ?
The negativity, I feel is on the part of this whole critique. A bunch of guys came up with a tool for themselves and it turned out to be so good that it not only took the software development world by storm, but it pretty much killed all competitors stone dead.
Now it seems as though you’ve got a few moaners who have basically decided that this amazing and free technology isn’t good enough and they can imagine what they want but wouldn’t even begin to know where to begin implementing it.
If you can’t use Git, it’s probably not for you. Other alternatives do exist but they will never match git for features or community activity.
Most of what these people want could be achieved as you suggest, with a simple NFS share and system of folder numbering. Once you go away from the domain of text based code Git becomes a bit pointless ...
This is the root of the author's issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: https://news.ycombinator.com/item?id=25002318) is the complete opposite: a system that knows it's connected to other people, where changes are instantly propagated and easily visible, where the differentiator between "branches" is not "what computer does it reside on" but "who did it". That's the model behind GitHub, after all.
git is complex because it's working with a very complicated model that is not in line with what most people expect today. As I said in my other comment it seems that fossil works with that flow, but I haven't tried it. However what is sure is that it doesn't make sense to ask git to become what it fundamentally is not.
EDIT: There might be a solution with wrappers. When you look at git-annex assistant (https://git-annex.branchable.com/assistant/) you can see that the right amount of abstraction can provide something closer to what we expect... but at this point it's not git anymore, so we might as well start from scratch.