We make shitty software [1995] - <AUTHOR> http://scripting.com/davenet/1995/09/03/wemakeshittysoftware.html

<comment><USER2> I like the sentiment, after all, it's true. Ship or sink.

However, even though Dave Winer has historically been a great power both in writing and software development, I wonder whether the WMSS mantra as written really helped once applied in the context of what was effectively Agile philosophy in mid 1990s at UserLand.

AutoWeb and Clay Basket that came out in 1995 were in public beta, but never released. Then in 1996 Clay Basket was abandoned. It was four years later in 1999 that Manilla came out, which was the first product I remember the name of from that period.

UserLand may have been pushing the "run it in beta" thing long before Google and others made it so popular in 2004. But it's important to note, like anything else, you want to make something that isn't shitty to the user; if the process is shitty and it has bugs, fine, as long as the user uses it and keeps using it and the snowball of usage starts. It's great that WMSS worked at Living Videotext, though. Selling the company to Symantec and making a bundle wasn't too shabby either.

<comment><AUTHOR> Interesting history :). Didn't know any of that before I posted this - I was still 7 back then, and nowhere near a computer ;). Just found it cool that this is a post from '95 talking about what is essentially Agile.</comment></comment>


Every Company Is Becoming Software - <AUTHOR> https://www.confluent.io/blog/every-company-is-becoming-software <comment><USER2> It starts out with that title trying to piggyback on Marc Andressen's famous article. Then by 1/3 of the way through, it's full on "Apache Kafka® and its uses".

I feel cheated. I was ready to defend the non-software companies of the world, but the article has very little to do with the title. It seems like just an ad.

<comment><USER3> Agreed. There should be law that forces all advertising to be within a dedicated HTML tag called <marketing> so that anyone can just opt in to a plugin that deletes all marketing tags.

Would that clean up the Web or what!

<comment><USER4> But then ad companies wouldn't be software anymore!

<comment><USER3> Win-win!

</comment></comment></comment></comment><comment><USER5> > That is, the core processes a business executes—from how it produces a > product, to how it interacts with customers, to how it delivers services—are > increasingly specified, monitored, and executed in software.

When I think of businesses I think of the local auto repair shop, the restaurant around the corner, the paving company working on the roads, the local HVAC company around the corner from me, and the local gyms.

The core products at the boot camp workout place across the street from me don't need to be specified, monitored, or executed in software.

Somehow this reminded me that empathy is decreasing in society (you can search on it). Putting more computers between businesses and people isn't necessarily going to be better for people or the way we interact with each other.

<comment><USER6> The sad thing, or at minimum odd thing, is that we're few years away from the positive differentiation factor being "you'll be talking to a human".

In fact it should be made illegal to have people who's livelihood depend on a platform to be left at the hands of shit auto replies. If large scale comes at the cost of injustice, maybe large scale shouldn't be a thing.

Youtube, Amazon Seller Central, and many others are terrible examples of what future holds for a lot of people.

<comment><USER7> That's already the case in many industries - for many SaaS and telecom businesses the differentiator for expensive B2B plans is "24/7 support with a real human being", big IT companies like IBM and Oracle rely on "There's a human to blame when things go wrong" as their sole value prop, high-end retail like Nordstroms differentiates themselves from low-end retail like Walmart by the availability of personal sales assistants, and waiter-service restaurants differentiate themselves from McDonald's by the existence of a human who takes your order. The difference between Uber and a car service is whether the driver's waiting for you at baggage claim, greets you politely, and makes small talk on your way home.

Personally I like it - I usually pick the self-checkouts, kiosks, and apps over talking with a real human being, who frequently acts like a robot anyway and tends to be slower and make mistakes more often.

Also, I wonder if folks who say "if large scale comes at the cost of injustice, maybe large scale shouldn't be a thing" have really thought through the implications of this. I remember talking to a classmate in high school about Native American tribes, industrialization, American history, and how we really fucked over this idea of a tribe or village or community and the world was a lot less richer because of it. (This was pre-Internet - if only we could've guessed what the next 25 years would bring.) I agreed with all of his points, but then pointed out that the carrying capacity of the earth before modern agriculture, modern medicine, fossil fuels, etc. was roughly 1/20th what it is today, and did he really want to kill 95% of the people alive today? He responded, "Man, I feel shitty now." That's the nature of the scale vs. justice dilemma: you can't critically analyze scale & progress without also acknowledging the huge injustices it's created, but at the same time, reversing scale literally means death & suffering.

<comment><USER6> > I wonder if folks who say "if large scale comes at the cost of injustice, > maybe large scale shouldn't be a thing" have really thought through the > implications of this.

I'm saying companies should be accountable for the loss they cause - if you're a Amazon Seller and you get your listing removed, you get an auto-reply and you try to talk to a human just to find a stream of auto-replies pasted together, because is in the sake of scale and progress the it's ok?

Same goes for copyright claims on Youtube. You end up talking to auto-replies.

Why should people livelihood be the cost to pay for scale? Why can't Google or Amazon pay people to supervise these replies and make amendments when the help is not only requested but required?

I don't buy that "cost of progress" argument. I'm pro progress, I'm just against half baked solutions that seem to be progress but end up being cost saving measures.

Why can't a user who got wrongfully harmed be compensated? Is that against scaling? Or shouldn't that be a cost of scale?

Currently in my opinion it's irresponsibility. Irresponsibility disguised as Policy & Terms Agreements.

At least in the EU Amazon is being pressured to cut this bullshit and act properly.

</comment></comment></comment></comment><comment><USER8> Literally all of vsyu's posts are submission links to either confluent or buzzsprout talking about Apache Kafka. No comments, just banal advertisement.

<comment><USER9> Content Manager at Confluent: [https://github.com/vsyu](https://github.com/vsyu), [https://www.linkedin.com/in/victoriayu/](https://www.linkedin.com/in/victoriayu/)

</comment></comment><comment><USER10> They say software but then the article is about databases, event streams, and networked communication.

But they leave out the other big part of running a company, which is getting the low-paid worker drones to show up on time and make the company money.

</comment><comment><USER11> While I mostly agree with Jay Kreps, I believe that the upfront costs of event sourcing systems are way higher than traditional ones.

Kafka itself seems to have minimum hardware requirements way above something like a single-node Mongo or Postgres installation, let alone the infrastructure to create projections.

</comment><comment><USER12> Cringy mental gymnastics of turning "Why Software is Eating the World" into "pay Confluent for something you get for free".

<comment><USER13> Yeah, I actually flagged the post originally because it is so spammy and a dumb ad.

</comment></comment><comment><USER14> 2020 Every Company Is Becoming Software

2030 Every Company Is Becoming Smart Contract

</comment><comment><USER15> I am tempted to add "Every Software is becoming crappy". There will of course be exceptions but I feel general trend seems true.

</comment><comment><USER16> True for a lot of industries. Unfortunately, there are two corporate responses to this: 1) Software is a strategic competitive advantage and market differentiator and 2) Software is a cheap commodity that can be outsourced and cobbled together from lowest-bidder parts.

Not only do both attitudes exist at different companies but, in my experience, a single company can flip between "software is our secret sauce!" to "let's focus on our core strengths and outsource the rest!" in a heartbeat depending on what the venture capitalists say that week.

Using some SAAS is often smart and useful but if you're outsourcing your core business processes and new development for the sake of short-term efficiency, you're handing the keys of innovation for your company over to somebody else.

</comment><comment><USER17> This will be useful for future AI "employees".

</comment><comment><USER18> I'm two paragraphs in, it feel like this dude wants to sell me something. Edit: Yeah it was a pitch, sneaky sneaky ;)

<comment><USER19> The HackerNews crowd will not be taken in by this copy; however, it will doubtless work on enterprise folks.</comment></comment>


Gitless: a version control system - <AUTHOR> http://gitless.com/ <comment><USER2> Git is, like many professional tools, something you simply got to learn.

But like with many professinal tools, you don't need to know everything to get to work.

I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less.

With these commands you can already start your own repo and work on it locally:

        git init // crate new repo

        git status // show which files are changed and which of them are staged

        git add -p // add "chunks" of changed files to the stage

        git commit -m "<commit_msg>" // commit everything added to the stage with a commit message

        git log // show a list of commits

        git checkout <file> // throw away all changes since the last commit (one file)

        git reset --hard // throw away all changes since the last commit (all files)

If you want to work with a repo from somewhere else like Github etc., you need a few extra commands:

        git clone <repo_url> <target_dir> // clone a remote repository locally

        git pull // download and merge new commits in the remote repo that happened since the last clone/pull

        git push // uploading your own changes after a commit to the remote repo

I think these 10 commands are all that is needed to get your own project into Git.

Yes, the more people are working on a project, the more commands you need, like creating a new branch and getting commits from one branch to another, or amending commits because you forgot something etc.

For a professional tool this isn't too much, I think. The 10 commands I mentioned will be remembered in less than a week. Most of the rest isn't needed often (maybe merge/rebase and branch depending on how you intend to use Git), but they shouldn't take too long either.

<comment><USER3>
        git checkout <file> // throw away all changes since the last commit (one file)

        git reset --hard    // throw away all changes since the last commit (all files)

This is a perfect illustration of why git needs a better UI. Two different commands to do exactly the same thing, with the only difference being that one is for one file and the other is for many files? If you _tried_ to design a hard-to-use UI you could hardly do better than that.

[NOTE: these two commands actually don't do quite the same thing, which is part of the problem.]

<comment><USER4> But they don't do "exactly the same thing, with the only difference being..." unless you ignore the index, which is one of the extremely powerful abstractions that sets git apart. Sure, git could expose a simplified lowest- common-denominator interface that plasters over its differences, but the same interface would (and gitless does) plaster over its strengths and encourage people not to learn them.

I agree with TFA: this isn't a UI issue, it's an abstraction issue. Several of git's abstractions only make cost/benefit sense in a distributed environment. Unbundling the cost of learning dVCS abstractions would make git a better fit for the Cathedral and a worse fit for the Bazaar. This might be what you want, but you should at least be able to understand why other people do not want it.

<comment><USER5> They don't do the same thing implementation wise, but they do the same thing ux wise. This difference causes all discussions like the above: it seems as if some people like ux "plaster", while others like bare-metal tools.

<comment><USER4> They do the same thing ux wise _if and only if your mental model has no notion of a staging area._

<comment><USER2> I just stage parts of my changed code before commit. So things I work on are un-staged mkst of the time. Which eliminates the problem, I guess.

</comment></comment></comment></comment></comment></comment><comment><USER6> Git is powerful. While the underlying architecture has beautifully simple aspects arguing that the complexity of the git tool-chain is simple is similar to arguing that TeX is simple as it is written in a simple language. Git is managing trees of file-sets in a distributed manner. It took many generations of configuration management systems to get there.

Git is bottom up. Understand the inner workings and you know what you can do. But coming from a user perspective there is a gap - first one needs to wrap ones head around the tool. Git imho. is more a framework than a tool. On Stackoverflow simple questions yield different answers all yielding results but having various trade-offs. Usability is also about orthogonality and looking from a user perspective (not an implementation perspective) Git offers often quite a number of paths getting to a certain goal.

Individuals, teams and tooling all trying to settle on certain workflows enabled by git effectively deciding to use only a subset. Particularly when it comes to teams agreeing on workflows becomes important. Git as a tool is here helpful in the sense that it enables almost everything. But for a team it takes more than agreeing on using Git. Other tools come with more comprehensive practices.

<comment><USER7> As a tangent, I think calling git a distributed system is misleading. Git is primarily a history manager for a local directory tree that has commands to sync with remote machines. Having to type stuff like

      git remote add mothership ssh://email@example.com
      git push mothership

in order to sync is not what I usually associate with a distributed system. The word distributed conjures something that's more like dropbox, where things sync transparently.

<comment><USER8> "Distributed" means something other than what you think it does. Dropbox is not a distributed system. In fact it is a good example of a centralised system.

<comment><USER9> "Distributed" is, by popular convention, associated with systems that span multiple computers (or even processes on the same computer).

"Decentralized" is associated with systems without a central point of failure or control.

Git qualifies as both, and Dropbox only qualifies as distributed.

</comment></comment></comment></comment><comment><USER10> I'm surprised at how many people are responding negatively to software that improves user experience.

Suppose we had started out with the command UI that gitless has and someone came along and tried to sell us the current git cli UI. It would be completely ridiculed.

The only thing possibly questionable about the gitless interface is that it does away with staging. However, you can always fall back to git for staging functionality if you like, and use gitless for most other commands. I think it is a win.

<comment><USER11> I think the author address that point in the introduction:

> Experts, who are deeply familiar with the product, have learned its many > intricacies, developed complex, customized workflows, and regularly exploit > its most elaborate features, are often defensive and resistant to the > suggestion that the design has flaws.

Having spent dozens, even hundreds, of hours learning the intricacies of the Git command-line, it must be extremely shocking and insulting when you are told that those efforts were in vain, because the original UI was not very good and an alternative can be grokked by people of varying levels of technical competence with only a fraction of the effort you put into the original thing. I think this is what we're seeing here: people will try and defend their time investment by arguing that a professional would learn the hard thing and not lower himself to easy-to-use tools, that the new UI hides some powerful features that are rarely used, etc.

<comment><USER12> Indeed. Also known as "sunk cost fallacy".

<comment><USER13> I think it's a little different from that actually. That's normally about the merits of ongoing financial investment, but I get your analogy and there should be a name for it because you see it all the time from compsci types.

How about "sunk knowledge fallacy" or something like that?

</comment></comment></comment></comment><comment><USER14> Very cool. The idea which I liked most, is the ability to switch between branches, even though you still have uncommitted changes. With git, I'm forced to either make an extraneous commit, just to enable branch switching, or stash all my changes into a stack which I may later forget all about. Both of the solutions above are really cumbersome and prevent easy context switching.

The only feature I noticed missing, is the ability to stash changes. I use this most often to move changes from one branch to another branch, without cluttering history with an extraneous commit. How would this work on gitless?

<comment><USER15> > With git, I'm forced to either make an extraneous commit...

You only need to commit or stash if there are conflicts, and many time there aren't, so you can first try to switch branches without stashing.

> The only feature I noticed missing, is the ability to stash changes. I use > this most often to move changes from one branch to another branch

I started a big ol thread on stash yesterday, but there are a bunch of safer alternatives to stash. You never have to clutter history, you can always move things around and still keep it clean. Problem with stash is it circumvents git's normal systems, so it's a little dangerous (which the stash man page mentions.)

[https://news.ycombinator.com/item?id=12612630](https://news.ycombinator.com/item?id=12612630)

If there are conflicts, you could do this instead:

      $ git checkout -b work
      $ git commit -am "WIP"
      $ git checkout another_branch
      $ git cherry-pick work
      $ git branch -D work

Exact same effect as stash with no clutter left over in the history, and much safer. The advantage here is your changes are put multiple places and referenced by git, so if anything ever goes wrong it's in the recent reflog. With stash, if you have problems, your only option is to use fsck.

Given that the whole point of gitless is to avoid super confusing and intimidating commands like fsck, especially for beginners, it makes sense to me they chose not to include stash.

<comment><USER16> The whole advantage of stash, the way I see it, is that you don't need to type out a whole bunch of commands to stick something into another branch and deal with remembering where you put it and what you called it and so on.

I started out using secondary branches since that was the intuitive way of doing things, and I had issues with stash before, but after a while I went back to using stash again because it's just so much faster to stash my config differences, do all the necessary merges or pulls or switches, and then just stash pop. A large part of the advantage _is_ that stash is a bit orthogonal to the usual workflow, so it goes in a specially defined place in my brain vs being yet another branch, especially if I already have work/dev/backup branches for other purposes.

I agree that I wouldn't recommend using the stash to beginners, though, it does really odd things at times if you are not clean with it. First time I used stash, I lost all my code and nobody could figure out how to get it back. :P

But that the thing - I never stash crucial code, just things like settings that are special to me and not other developers, so they'll probably never be pushed.

<comment><USER15> Stash for you is fine, you obviously know what you're doing, and you use it carefully. And if you're comfortable with fsck, you really don't have to worry.

OTOH, the alternative workflows are really not that hard, it's really not a ton of commands compared to using stash. The single most common use case I've heard so far is switching branches, and for that you can skip stash the majority of the time, many people don't seem to know that.

Your example was stash during a pull, if you do that, your workflow is:

      $ git stash
      $ git pull
      $ git stash pop

The alternative is:

      $ git commit -am "WIP"
      $ git pull
      $ git reset --soft

Not only is it the same number of commands, and safer, it's also less to remember because you don't have to use the stash subsystem at all. Commit, pull, and reset are commands you have to know regardless, you can't avoid them. Stash isn't one you have to know to use git. Stash is adding to the things you have to remember, or taking up space in your head that could be used to learn flexible ways of making temporary commits & branches.

<comment><USER16> I don't know if I really know what I'm doing... feel free to correct me if something feels off.

I'm not following your alternative. Did you mean "git pull --rebase"? Because this will result in there being a WIP commit in the middle. I try to pretty much never do pulls like this, I'm in the "rebase everything to smithereens camp".

I don't want accidental merges. I do not want to have to rebase because I got a commit in the middle and it's named funny. And what I also don't want is having to deal with merge conflicts in the rebase or merge in case incoming changes don't like the changes in the WIP commit.

It's a lot cleaner to just not have the stuff in there at all, pull, and put it back on top. (like the stack that stash presents)

Yes, I am that lazy.

This is not really the way I used to do it. An example is just an example, the situations are many. Maybe I want to pull. Maybe I need to rebase my stuff. Maybe I need to switch to another branch to show something to a coworker.

I'd have to make a special branch, commit to it, and then grab the commit hash and cherry-pick that whenever I needed it. Because I would need it in all sorts of different situations. So part of the issue was keeping track of the hash. But the bigger problem was how much work I'd needed to do if I ever needed to bring those changes up to speed again. With stash, I get a merge conflict and I resolve it, and that's my new stash again, I don't even have to do anything. With a commit or cherry-pick, I have to undo it, fix it, commit it, and now manage a new hash.

I find stash easier to manage in my head specifically because it's a separate thing on the side so it doesn't get mixed up with all my other branching. It's very little headspace at this point, and mostly a decision tree in the form of:

\- is the staging area empty and I want to start doing work? stash pop;

\- is the staging area currently holding my stash changes and I want to do some things with git? stash.

<comment><USER15> > Did you mean "git pull --rebase"?

Yes.

> Because this will result in there being a WIP commit in the middle

No. Your WIP commit will always land at the end. Anything you pull will rebase to before your WIP commit.

Doing a commit+pull+reset will always work exactly as easily as stashing.

It's no less clean to commit & later reset than it is to stash & later pop. The difference is that if you commit you have a bigger safety net than if you stash.

I totally understand that stash _feels_ easier, a lot of people agree with you. But I don't think it's true once you dig down and learn how to not use stash. And stash is more dangerous when something unexpected happens.

<comment><USER16> > No. Your WIP commit will always land at the end. Anything you pull will > rebase to before your WIP commit.

I was talking about the non-rebase version.

You didn't address the rest of my post: there are other cases. This will work for that particular case, but it's not a general-purpose solution.

If I have branch X with config changes, and coworker wants me to switch to branch Y but I still want my config changes, what do I do?

<comment><USER15> Stash is not a general purpose solution. You don't ever _need_ to stash. There is nothing you can do with stashes that you can't do with core git commands, and the reverse is not true. Git could eliminate the stash command tomorrow without any loss of functionality.

What if you already committed your config changes to branch X, and your coworker wants them in Y? What if you you're working along and you have commits, staged changes, unstaged changes, and you need to branch 3 commits ago instead? Stash doesn't help with either of those, and the workflow I'm advocating - just use commits and branches for temporary work - does.

Stash really only helps you if you don't like to commit often, and you spend most of your time with unstaged changes in your working tree. Nothing wrong with that, if that's how you like to work, but I think if you spend some time getting used to committing more frequently you may find it much more flexible and much safer and more forgiving than trying to keep everything straight in the working tree alone.

If you have uncommitted changes in X, and you want in Y instead, then you can:

      $ git checkout Y
      $ git commit -am "config changes"

If you get merge conflicts, or if you want to keep the change in X too, you can:

      $ git commit -am "config changes"
      $ git checkout Y
      $ git cherry-pick X

The first case is fewer steps than stash, the second is just as easy as stash.

Popping a stash and cherry-picking a commit have the same process if there's a merge conflict, except that with a commit, you have undo capability if you merge incorrectly, and you have a safety net if you get lost or screw up in the middle of the resolution. With stash, you're stuck with a bad merge, and if you lose your stash -- and it happens -- you have to hunt for it by searching for dangling blobs.

You made a big deal out of having to create and remember and lookup hashes, and I don't see that as being an issue at all, and it's not a problem in my experience. You're comparing this to stash, after all, and stash only works on uncommitted changes, so there is never a case where you'll need a hash, because the stash equivalent is always at the tip of the branch, you can always use the branch name instead of a hash.

<comment><USER16> I didn't call it a general purpose solution in that context, nor did I call it a general purpose solution for everything. I am saying that I needed a general purpose solution for a situation that occurs often in many variants. For my situation, without stash, that was creating a commit and cherry-picking it places. Stash makes that case a lot easier to manage.

I don't use stash for cases where it doesn't make sense. I use stash for cases where, for me, it makes sense. For a special set of config changes that are never pushed. They're not part of my usual work, they're config changes. In this context, your 2nd paragraph makes no sense. I don't have to arbitrarily choose one or the other "workflow", I use both, and I simply use stash for the general case of reapplying configs on random branches. There are other ways to do it but they all require more headspace and are harder to track than stash and stash pop.

I'm not saying I need to stash or that I can't do it without stash. Have you not seen my earlier post?

It has nothing to do with being comfortable with commits. I'm already comfortable with commits. I've even said, before, that I did it with commits. It's just slower to do it with commits, and it means I have to manage commits for something I'll never, ever push. Every time I make something a commit, that's extra work for me later to make sure I don't push it out. If I make commits after that commit it's extra work for me to rebase it.

I don't put things in my stash where I care about a bad merge with them or that I'm even going to bother searching for the blob, I'll just redo the changes if that ever happens, because they're minor. They're things like: "Point to my database instead of the standard dev database". I just don't want to do them by hand every single time and I don't want to track a hash that changes every time I actually do want to change my configs.

You're the one making a big deal out of something, honestly, and you do not seem to be reading my posts very carefully because you're still making a lot of incorrect assumptions.

<comment><USER15> > You're the one making a big deal out of something, honestly, and you do not > seem to be reading my posts very carefully because you're still making a lot > of incorrect assumptions.

I'm sorry you feel like I wasn't listening to you. I was, and I read all your posts. You're absolutely right, I have made a big deal out of it. Despite the long discussion, I think we're in nearly full agreement, and FWIW, thank you for engaging.

I did misread your pull --rebase comment. I thought that was sorted now, but I'd be happy to address any other bad assumptions I'm making. It wasn't clear to me until just now that your config changes are small changes you never push. If you stated that before, I'm sorry.

Given your use case I agree with you, this is not an either-or proposition. And anyway, it's perfectly fine to leave all of this as my stupid opinion, and I don't want you to feel like you need to defend your use of stash. You clearly understand the issues and know how to use it.

In my mind, the only thing wrong with stash is how it's implemented, not its interface. I wish it had easier ways to recover, and I bet you did too that first time you used it.

Maybe the funniest part of this is I've been avoiding stash completely for years, but the threads for the last two days have convinced me there are some nice uses of stash that I may start adopting. A couple of them even increase safety! I do keep config changes around, and I like to name them with a tag or a branch, but I'm going to try stash and see if I prefer it.

Peace!

<comment><USER16> Well, I said at the very beginning:

> But that the thing - I never stash crucial code, just things like settings > that are special to me and not other developers, so they'll probably never > be pushed.

I don't know if that wasn't very clear.

Nothing wrong with opinions, there's a reason we share them, and I agree that stash could have probably been implemented a better way underneath. I have been recommended to use stash by another developer without any sort of warning, and with the implication that it's really safe and easy to use, which is rather funny in retrospect. Git's documentation page doesn't really talk about the dangers, either.

> Peace!

Indeed!

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> To me the really bad thing about git is its command-line interface.

It has extremely verbose messages (writes out a lot of stuff that you don't need to know) and common use cases often requires multiple steps (ie. add, commit, push if you just want to send a change from your work machine a github repository).

Compare this to subversion which is much less verbose, and in general just have one operation pr. use case.

<comment><USER18> I disagree. It's one of the best command line tools I've seen. It detects errors, gives you suggestions and you can get along with a few basic commands. Yes, there are multiple steps, but that's okay because it can't figure out your intentions.

Look: [http://imgur.com/xY8dKWD](http://imgur.com/xY8dKWD) no verbosity here and this is 99% of my git workflow. Working in a team is more tricky, but you should use and IDE with built in git support.

If you want to see a bad command line tool, try FFMPEG.

<comment><USER19> This is not objective. Git CMD has terrible flaws that are easily spotted as soon as you start teaching git, because you can see people struggling on difficulties purely created by a bad design.

As a professional trainer, here are the most commong problems:

\- git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the option flags.

\- git is context dependant. If you don't know the context, espcially the state your repo is in, you will struggle. And nothing in the tool gives you enough context if you don't explicitly ask for it, which supposes you need to know you need it, and what "it" is.

\- branch switching is a hard. see article.

\- stashing is dangerous. I've seen many students loosing work with a stash pop requiring a merge which ended badly.

\- the whole syntax is impossible to discover, even for very common tasks: git checkout HEAD^ /file/path, git rm --cached, etc.

\- git assumes you know what you are doing. Which means it let you destroy history with rebase, loose stuff with stash pop, create detached head, make force push, and all it all put yourself in many situations a beginer won't understand, and above all won't need.

Now I don't blame git designers for those. They made the tool they wanted to use.

What we need is a good UI on top of that. It can solve 99% of those problems.

The github one is not so bad compared to all the ones I tried (yes I tried yours), but it's still not it. What you need is someone that look at the most done tasks and questions, and provide safe, fast buttons for that.

<comment><USER20> Let me just start by saying that while gitless seems fine, it tries to hide the index and thus encourages bad habits in git users.

The index is by far one of the _best_ features git has in comparison to other VCS, and trying to hide it because it can be confusing to users is doing them a disservice.

EDIT: editing this to expand on why I think the index is essential:

Being able to use the VCS tool to fashion a commit separately from what is in the worktree allows you to create changesets that make sense, instead of them being "this is what happened". Exact history is not interesting, it is the logical progression of the codebase (via changes applied to it) which really matters.

Furthermore, when resolving conflicts, the index is extremely useful because you can work through a conflict (which often can span multiple files) piece- by-piece and easily tell whether you've already fixed everything, run diffs on what's resolved and what isn't, etc. I find myself missing the index whenever I need to do anything nontrivial with other VCS (which is most often Subversion)

I've seen some people argue that they don't want to commit something that has not been tested, but I don't understand this argument. Why would you test something that isn't committed? Committing (or even pushing) something does not mean the code is instantly in production, but it means you have an unambiguous way to refer to what is being tested, instead of whatever state your worktree and system happened to be in. How could you be sure you're really testing what you will be committing?

Certainly, creating separate commits after-the-fact can cause commits where the tests don't pass, but it's up to you to decide whether the _merge points_ are what should be tested, or each individual changeset.

Let's go through that list

\- git checkout does one thing: it updates your worktree to match whatever you want to check out, be that a commit, a branch (which actually is just a named commit) or a file in a branch. Why is this difficult for beginners, and how would you refactor/name the operations so that they make sense?

\- I'm not sure what you mean with context-dependency. Obviously it's context- dependent in that your worktree and repository may be in a state where certain commands do different things eg. because they have the current checked out branch as an implicit parameter. I don't think it's at all different from most other VCS

\- I'm not sure I'm convinced by the article's argument that branch switching is hard, but I guess I'll grant that.

\- Huh. I don't use stash that often, so this is a maybe. Teach people to use stash apply instead?

\- git rm --cached is weird, but mostly because git can't choose just one thing to call the index.

\- You can never accidentally destroy history with a rebase. Nothing short of manually wiping files destroys history in git once something has been committed. I don't really see why detached heads would be a problem (just create a branch?) and if you force push, you're basically telling git "I know what I'm doing, shut up" in which case the tool doesn't assume you're an idiot and will do what you want. You can't call it bad UI when you explicitly have to use a --force flag to do potentially destructive things. Not being able to do it at all is worse.

Really though, other than minor gripes with terminology and maybe sometimes confusing command line switches, what is a good (hypothetical) UI for git that doesn't just ignore all the good things?

<comment><USER21> > The index is by far one of the best features git has in comparison to other > VCS, and trying to hide it because it can be confusing to users is doing > them a disservice.

I can't disagree more. The index is entirely unnecessary, as umpty thousands of happy Mercurial users can testify.

> Being able to use the VCS tool to fashion a commit separately from what is > in the worktree allows you to

... record states which never existed, and haven't been tested. It's an antipattern. If you are doing this a lot, you are doing development wrong. In the rare occasions where you do want to do it, Gitless and Mercurial, like every other source control tool, give you a way to fine-tune the set of files which go into the commit. They don't need an index to do it.

> Furthermore, when resolving conflicts, the index is extremely useful because > you can work through a conflict (which often can span multiple files) piece- > by-piece and easily tell whether you've already fixed everything, run diffs > on what's resolved and what isn't, etc.

Again, you don't need the index for this, you need to track conflict state. As Mercurial does:

[https://www.mercurial-scm.org/wiki/TutorialConflict](https://www.mercurial- scm.org/wiki/TutorialConflict)

> I've seen some people argue that they don't want to commit something that > has not been tested, but I don't understand this argument. Why would you > test something that isn't committed?

This is a very interesting perspective! It doesn't immediately sound immensely practical, though. Say i want to test a fraction of the current working tree's state; i commit, and then ... what? Create a fresh clone of that state somewhere so that i can run tests on it?

<comment><USER20> Sure you can make do without the index, that doesn't mean it's better not to have it.

I personally don't feel comfortable with mercurial, but that may be because I don't understand it. It's been a long time since I last touched it, but I remember thinking that the way it does branches was just needlessly complicated and cumbersome. Why does closing a branch even need to be a thing?

> you don't need the index for this, you need to track conflict state

This is what the index does. You don't need the index in mercurial, because you have something that is like the index, but not called the index.

Maybe the UI is better because "add" is called resolve, but that is really just an alias away.

> and then ... what?

Then you push it to remote somewhere and a CI system runs tests for you. Maybe you can do something productive in the meantime.

If you're just testing locally, then there's little difference, but I would still prefer testing a committed state, knowing it's safe in the repository and I can't clobber it afterwards.

</comment></comment></comment></comment></comment></comment><comment><USER22> See also discussion about the Gitless paper: "Purposes, Concepts, Misfits, and a Redesign of Git"

[https://news.ycombinator.com/item?id=12612333](https://news.ycombinator.com/item?id=12612333) (1 day ago, 106 comments)

<comment><USER23> And it hits the most important point of: Gitless tries to do away with the staging area, thus completely misunderstands Git.

<comment><USER24> I've been using git professionally for a few years, and other distributed version controlling systems for more than a decade. This is the first time I see the phrase "staging area" in relation to VCS. Could you explain why it's an important concept?

<comment><USER8> It's central to git. 'git add' puts changes in the staging area. Then 'git commit' commits the staged changes.

The staging area is also known as the 'index' and the 'cache'.

(Git has a consistency-of-naming problem.)

<comment><USER16> > (Git has a consistency-of-naming problem.)

I wonder how many git usability issues could be solved just by addressing this and this alone.

</comment></comment></comment></comment></comment><comment><USER25> I don't see any improvement over git. Just another set of commands you'll need to learn from scratch. Some ideas seem not very good, like committing all changed files by default. If you find git commands too verbose - try 'tig' \- the ncurses git client, it saves a lot of time and efforts being simple and straightforward at the same time.

<comment><USER26> wildly guessing from the clone to checkout name change, it probably started as a git for subversion users?

<comment><USER27> Removal of the staging area seems like a move in this direction too.

</comment></comment></comment><comment><USER28> In my experience, making "gl commit" equivalent to "git commit -a" seems like a bad idea. When leading a team, especially of newer coders, one of the most effective ways I've found of keeping the git logs and the code base sane more generally, is to force people to review their own code at the time when they commit it. Individually adding each file with "git add -p" achieves this, and "git commit -a" squashes it.

Reading the methodology used to develop gitless yesterday was interesting, but if I recall correctly, I think it left something out. They looked at how often a software design allowed users to complete their intention, but the tool ideally not only should allow users to complete their intention, but should encourage users towards practices that increase the quality of the end product. While people may struggle with staging at first, I think it in the end encourages better software, which is my biggest concern.

</comment><comment><USER29> I am also pleasently surprised by this initiative.

I consider myself an advanced git user so I am not sure I would use it myself, because my brain is hardwired to git's wicked commandline interface now. There is little that surprises me in git nowadays.

I am used to give out simple "the 10 git commands you will ever need" tutorials to people, but it's true that it is confusing for people, even with that. gitless takes out significant confusion out of the daily grind of using git, so much that I may end up recommending it instead of git itself, especialy since they are interoperable.

What I would love to see would be to have those commands percolate back into git itself. git's usability has improved significantly since it started, and while this project shows there's still a lot that can be improved, history has shown us that git _can_ be improved. track, untrack, history, switch, resolve, publish, init's remote argument, all those could be added as commands into git and equivalent commands could be deprecated or just kept for the hardcores like me that don't want to be bothered learning a new simpler interface.

Unfortunately, given the reaction on the mailing list, I am thinking this will not/never happen and gitless will remain a friendly fork: [http://marc.info/?l=git&m=147527432403442&w=2](http://marc.info/?l=git&m=147527432403442&w=2)

</comment><comment><USER30> In this thread, lots of people wanting to demonstrate their deep knowledge of an arcane tool, thus proving the whole point.

<comment><USER31> Posted this upthread, but here's an apt Linus quote:

> The first Git For Dummies and Git Visual Quickstart books are going to be > out in a couple of months, and that is the beginning of the end as far as > I'm concerned. Those books mean the end of git expertise and github > reputation as reliable indicators of geek status. Once a technology is > adopted by the masses the extreme geeks find something more esoteric. Look > at what happened to Ruby on Rails. The people stumbling their way through > Rails to-do list tutorials have never even heard of DHH.

<comment><USER32> That sounds like a very elitist approach. So the technology is good as long as it's arcane, but as soon as it becomes mainstream then it's "the beginning of the end"?

...do we even need a "reliable indicator of geek status"?

</comment></comment></comment><comment><USER15> My criteria for whether an interface to git is truly easier is whether artists can use it. I've worked in games alongside artists, with everyone using Perforce. At some point we switched to Perforce for the art, and git for the programmers, with a big janky glue system in-between.

Git couldn't really handle all the binary assets, and the artists couldn't really handle git, so it made sense. When we switched, it also took a long time before the programmers could really handle git too, fwiw.

I've long said I'd love to see something that's as nice a GUI as p4v, but with git under the hood. I haven't yet seen a git GUI that even approaches now nice p4v is, and git on the command line, once you learn it, is the best interface to git hands down.

I can't tell, but does gitless look like it could make a simpler gui to anyone else? I love the idea of gitless, I'll have to try it, but I get the sense that I'd end up needing to switch to git for some things.

<comment><USER33> As far as version-controlling art, I'd lean towards a system where checking a file out locks it from any other concurrent modifications. Unfortunately, trying to merge concurrent changes into an image file, for instance, is just about impossible.

It's almost as bad trying to work with MS Office file types - I wish I could get people on my team to use something else that is more VCS friendly, like HTML or Markdown, but that's an uphill battle. Even better would be if we actually used the versioning and collaboration features that are built into some of the tools like Office 365 that we pay for, but can't seem to leverage...

<comment><USER34> My wife is a math teacher and trying to figure out a good workflow for her team has been illuminating. Only the one true desktop Word has a good formula editor, so they have to use that... and only SharePoint provides a good "open and save" workflow. So SharePoint it is. Anything to get them off timeshares.

<comment><USER34> Ick, fileshares. Autocorrect.

</comment></comment></comment></comment><comment><USER35> I think there will be a very small subset of developers who are confused by the Command Line Interface of Git, but not confused by the Command Line Interface of this thing.

Sure, there are tons of developers who find Git confusing. But the solution they're looking for is something like Git Extensions that removes the silliness of memorizing and typing a bunch of commands in to a terminal. In terms of Global Confusion Index, this only drops us from 98 to 97.

A simple GUI version of this same concept would seem a much better plan.

</comment><comment><USER36> It does seem in some ways similar to Mercurial, but changes things which both Mercurial and Git share (like having to resolve tracked modified files before switching branches/bookmarks). I think if you want to make a fast and simple interface though, you should go a step further towards gui (like [https://github.com/xixixao/hg-sl-up](https://github.com/xixixao/hg-sl-up) ) and remove the concept of branches/bookmarks altogether (I stopped using bookmarks in mercurial). The repo is just a tree of changes, I already tag it with commit messages, shouldn't need to tag it again with branch/bookmark names. Would love to be able to leave the commits in WIP state though, that would be super convenient (shelving sucks).

<comment><USER37> That sounds a lot like Darcs's model, which is pretty fun to play with (and darcs has a _really nice_ CLI). You may want to take a gander at it.

<comment><USER38> Or pijul.

[https://pijul.org/](https://pijul.org/)

<comment><USER37> While in theory I appreciate what pijul is trying to do, I'm not going to plug it until it at the very least self-hosts. Two years in, still not there.

</comment></comment></comment></comment><comment><USER39> Git needs the parent pointer equivalent of NIL.

Whenever I start a blank new repo nowadays, I do a

      git commit --allow-empty -m "NIL"

See, many git operations require a parent reference! For instance if you want to interactively rebase the top commit, it's actually "git rebase -i HEAD^": rebase back to (but excluding) HEAD's parent. The equivalent "git rebase -i HEAD~1" means the same thing: that ~1 actually spans two commits: it refers to the parent, but since the parent is the excluded delimiting endpoint you can think of that 1 as being the number of commits being rewritten.

If all you have is a single commit with no parent, you _cannot_ rebase it.

If you have NIL there, it takes the HEAD^ reference; no problem.

Essentially, git is a list manipulation system whose use cases fail when operations span the entire list, oops. You can tell it was designed by someone who never took a Lisp or Scheme course (or forgot all of it). Imagine if (remove 3 '(1 2 3)) failed because the suffix (3) has no CDR, haha. "Sorry, you can't "rebase" your (1 2 3) to (1 2) because 3 is the "root commit"! Just scrap the whole thing and build (1 2) in its place."

<comment><USER21> FWIW, Mercurial has this - there's a notional changeset called 'null' whose hash is all zeroes, which is the parent of every changeset which does not have a real parent. As a result, you can rebase a root changset. For example:

      $ hg init
      $ echo silver >colour
      $ hg add colour
      $ hg commit --message 'First commit'
      $ hg checkout null
      0 files updated, 0 files merged, 1 files removed, 0 files unresolved
      $ echo liquid >state
      $ hg add state
      $ hg commit --message 'Second commit'
      created new head
      $ hg log --template '{rev} = {node|short} child of {p1node|short}: "{desc}" @ {date|isodate}\n'
      1 = 99f1472f8a69 child of 000000000000: "Second commit" @ 2016-10-02 17:29 +0100
      0 = 6433a3e95c3d child of 000000000000: "First commit" @ 2016-10-02 17:29 +0100
      $ hg rebase --source 0 --dest 1
      rebasing 0:6433a3e95c3d "First commit"
      saved backup bundle to /path/to/repo/.hg/strip-backup/6433a3e95c3d-331b8224-backup.hg
      $ hg log --template '{rev} = {node|short} child of {p1node|short}: "{desc}" @ {date|isodate}\n'
      1 = b9951882336f child of 99f1472f8a69: "First commit" @ 2016-10-02 17:29 +0100
      0 = 99f1472f8a69 child of 000000000000: "Second commit" @ 2016-10-02 17:29 +0100

<comment><USER39> I was thinking exactly the same thing: why doesn't git use an all-zero hash as a special NIL. I think SHA-1 cannot output all zeros as a valid hash.

</comment></comment></comment><comment><USER40> When people say they don't like git, I lose a little faith in them as a programmer and/or engineer. This is probably due to my own biases of having worked with folks that just don't want to invest the time in learning it. That or they are afraid of branching/merging. To me this indicates intellectual laziness which isn't the kind of laziness that makes a good programmer (as is with the quote from Larry Wall and the kind of laziness he speaks of).

<comment><USER41> I use git all the time and prefer it for all types of workflow as a VCS, but this idea that git is perfect and it's your own fault for not learning it properly is ridiculous.

UX/UI in programs is important. I believe that git has one of the worst, most inconsistent UX's of all time. You can see this by the fractured commands.

Quick examples:

'git reset' vs. 'git revert' and sometime 'git checkout'

'git checkout' vs. 'git clone' vs. 'git pull' vs. 'git fetch' vs. 'git cherrypick'

'git rebase' vs. 'git merge' vs. 'git merge --squash'

Each one of these performs actions on a repo giving you immense power and control to do specific actions, but it's horrible UX. It's very easy to end up in a detached HEAD state, or have accidentally rebased a repo so it's out of alignment with a remote, leaving you with the trouble of dealing with that. It's crap experience, and all I want to do is code. What does it say when resolving these problems the easiest thing is to just reclone the remote repo?

I commend this project for trying to apply some sanity to the entire thing.

<comment><USER42> > What does it say when resolving these problems the easiest thing is to just > reclone the remote repo?

It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. The real reason people struggle with git, and I've seen this in many other programs/places is that they rely on discoverability and just randomly try commands until they work.

Git's simplicity is it's downfall. You don't see people wrapping Angular2 in other frameworks to deal with the warts.

There's a reason people are told to look at man pages all the time, the command line is not the place to play "discoverability". There's already plenty of suggestions and help features built into the tool.

> It's crap experience, and all I want to do is code.

\- every engineer when first experiencing version control

<comment><USER41> > It says the git works really well because the CLI offers a simple way to > "undo" any mistakes you've made.

This let's the design off the hook to easily. Yes, on the one hand this is a great feature, but on the other, you are deleting and restarting your workspace. It's not a great UX, it's just a simple workaround for a bad one.

> \- every engineer when first experiencing version control

no, wrong. git is unique in the amount of information that you need to know just to get started with it.

<comment><USER42> > no, wrong. git is unique in the amount of information that you need to know > just to get started with it.

Have you ever worked with a different VCS? How is setting up subversion or CVS any more difficult than going

git init

git add .

git commit -m "initial commit"

Yes, truly a monumental barrier to entry to get started.

[http://vasc.ri.cmu.edu/old_help/Archiving/Cvs/cvs_tutorial.t...](http://vasc.ri.cmu.edu/old_help/Archiving/Cvs/cvs_tutorial.texinfo.html)

If you think git is unique in the amount of information it takes to get started... I pray you work on nothing that even broaches complex.

<comment><USER41> > Have you ever worked with a different VCS?

Yes, I've worked with RCS, CVS, SVN, SourceSafe, Perforce and some others, though know them less well.

Git is bar none the best of all (of which I've had experience) the VCS' out there. I would pick it over anything else. The issues I'm pointing out are not because I don't use it, don't understand it, or don't appreciate it. I just believe that it's too complex.

If git was literally just the set of commands you listed, that would be great. As a single user experience it's hardly ever an issue. But that doesn't mean that it can't be better! And that's why I like this gitless project (and some of the other similar ones out there), it's trying to create a decent experience that will scale.

Also, your example is about creating a new git repo, I find this to be much more rare than getting involved in an already built and multi-member team, which may have all sorts of rules about proper merges or rebases, and such.

<comment><USER42> It can be though. That's like saying Linux would be better if they only gave you ls, cat and nano because vi, sed and xargs were too complicated.

There is nothing about gitless that provides a decent experience (compared to git) and certainly nothing about gitless that has anything to do with operating at "scale".

The truth is commands like filter-branch, rebase, cherry-pick, etc. which are notoriously difficult to use... you don't even have to use them.

I'm not saying the git experience can't get better, but the way forward is to modify the existing tools and contribute to the project, not make git wrapper number 84 that does nothing special.

<comment><USER43> > That's like saying Linux would be better if they only gave you ls, cat and > nano because vi, sed and xargs were too complicated.

That's a rather condescending thing to say and not accurate or supportive of the view of git you seem to hold.

> The truth is commands like filter-branch, rebase, cherry-pick, etc. which > are notoriously difficult to use... you don't even have to use them.

Until someone on the team _does_ use them and then things can become messed up in ways it takes a git expert to figure out how to fix. I've used git for several years and had never even come across filter-branch, I'd have to chase down the git docs to see what it even does. I never had to filter anything with CVS, Continuus, Perforce, SourceSafe or Subversion.

<comment><USER42> Here in the real world if you fuck up your local repo by running commands you don't understand there isn't a "git expert" to come by and fix it for you, in the same way if you make a VM and fuck up your local machine there isn't going to be a "linux expert" to come in and explain how to fix what you did wrong.

Part of the benefit of the tool is that you _can_ blow everything away and restart. It's distributed, which means you CAN fuck up your local copy and there are no consequences. It's been years since I've had a repository be in an "unrecoverable" state and part of that is actually taking the time to understand what I'm doing as opposed to just crossing my fingers and hoping shit works.

The fact that other version control systems don't even have some of the power features git has is a big reason git is so popular.

Again, if you don't understand the more complicated commands, don't use them (although you should- they are incredibly powerful and worth learning about). If your team is forcing some bizarre workflow on newer developers that involves using filter-branch and cherry-pick all over the place without good reason, that's an organizational issue, not one with git.

<comment><USER43> Your points would be more salient if you could make them without falling back on profanity.

<comment><USER42> They'd also be more salient if I didn't have to make them 10 times in a thread because everyone feels like their opinion on how "git is too hard" is worth sharing. It gets tiring defending git from the uneducated masses and hearing the same stuff trotted out over and over again that has no value whatsoever.

<comment><USER43> If that many people are making the point, maybe they have a point.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER44> More accurate to call it a git client rather than a version control system. It is git.

Then, many clients have tried to hide git complexity under some friendly UI. They might be productive in some cases (e.g: to manage your stage area), but for others at some moment they will end up confused and not knowing what to do.

</comment><comment><USER45> > Gitless is an experiment to see what happens if you put a simple veneer on > an app that changes the underlying concepts.

... changes them _how_ exactly? A big part of what I like about Git is that its underlying concepts are simple and clear and feel like the right building blocks for version control. So I'm curious to know how they believe they can improve on that.

<comment><USER46> It's not a quick answer but they cover this in the Gitless vs. Git section.[0] One main difference seems to be with branching "The main thing to understand is that in Gitless a branch is a completely independent line of development."

[0] [http://gitless.com/#vs](http://gitless.com/#vs)

<comment><USER47> By that, AFAICT they mean "a branch, in addition to being a commit pointer, contains all the files in the working directory".

<comment><USER48> And also the current merge state (though I'm not sure why I'd ever want to context switch away from a merge conflict resolution).

</comment></comment></comment></comment><comment><USER49> The approach of this experiment is interesting. But, as an experienced git user, I think it does not include easy access to very powerful and easy-to- learn features of git like "git * -p" which bring some interactivity in git commands.

<comment><USER50> I assumed all `git` commands would still be available even if one might prefer `gl` for some tasks, am I missing something?

<comment><USER51> No, that's also my understanding.

"Gitless is an experiment to see what happens if you put a simple veneer on an app that changes the underlying concepts. Because Gitless is implemented on top of Git (could be considered what Git pros call a "porcelain" of Git), you can always fall back on Git."

</comment></comment></comment><comment><USER52> The git CLI has gotten a lot better over the past few years. Making simple branch push the default was a good move.

There are some things that could be improved (and any of these can be config options for those who want the old behavior):

* switching branches should auto-stash changes, then auto-apply when switching back (apparently one of the things gitless does) * a rebase should leave a marker in the tree (with the old hashes) so if you force-push other clients can offer more intelligent options (e.g. Looks like these commits were rebased by a_user; rebase your changes skipping duplicate commits or merge?) * git still allows you to create branch names differing only by case which is a problem on macOS and Windows * cherry-pick -x should be the default and tools should do a better job of showing the relationships * tag sync should include the commit and update on pull so rewriting tags isn't such a PITA. Maybe we need movable vs static tags.

</comment><comment><USER53> Auto stashing and restoring when moving branches or in the middle of a rebase seem like nice features. I'll definitely try it for that.

</comment><comment><USER54> I really wish Git came with some simplified version of dependency management, subrepo and subtree just don't cut it.

<comment><USER53> I've seen people recommend npm over submodules. You can give it a git repo as a package and tag/commit as the version so it's not just for JavaScript repositories and also pulls the submodule's own npm dependencies. Although I don't know if you can put it wherever you want or it will always go to the node_modules directory.

</comment></comment><comment><USER55> ITT: People trying to justify all the time they spent becoming experts on git's esoteric interface.

</comment><comment><USER56> Has anyone compared this to legit?

[https://github.com/kennethreitz/legit](https://github.com/kennethreitz/legit)

Both seem to simplify the git workflow.

</comment><comment> loup-vaillant Please please _please_ support "zoom text only".

First time in a while zooming caused a web site to have its text overlap with itself.

</comment><comment><USER57> I wonder why there is no context-aware vcs; e.g. one that understanding the language and resolve diffs at a functional level. Would make change tracking and merging so much easier. Alternative would be to split each function into a separate file, for C# that would mean partials and the compiler just joins them.

<comment><USER58> Possibly because then you'd need a parser for every language someone might use.

But, since you mention C#, see: [https://www.semanticmerge.com](https://www.semanticmerge.com)

</comment></comment><comment><USER59> How is this any different from hub ([https://github.com/github/hub](https://github.com/github/hub)). It provide useful command like aliases. Along with ghi([https://github.com/stephencelis/ghi](https://github.com/stephencelis/ghi)), I can do everything like creating new repo, sending PR, looking/creating/updating/commenting on issues with my command line.

</comment><comment><USER60> I highly recommend GitX-dev, which is a free, open-source GUI for Git on the Mac. [https://rowanj.github.io/gitx/](https://rowanj.github.io/gitx/)

The ability to stage/unstage individual lines using a graphical interface is really nice, and after some years using it I can't think me going without it anymore.

Nowadays I only use the command line when I want to do interactive rebase.

<comment><USER61> I knew that you can already interactively stage individual lines via the command line using _git add -p_ , which is what I use. But you mentioned unstage as well which I've never done before, so I looked it up. Looks like if you want to do that on the command line it's _git reset -p_

</comment></comment><comment><USER16> I don't know if this is not wholly rational, but over time, I became more and more cautious of using any tool for git that wasn't the pure git command line itself. I don't like how the command line was designed, but at least I know what's going on. With other tools (the latest culprit is Visual Studio sync), I often have a reaction of: "You did WHAT?"

</comment><comment><USER62> Do people really consider git hard to use? It's very easy to learn... In fact, if you can't learn git I would not be confident in your ability to learn any other important technology using the internet as your resource. You don't even need to have internet access as long as you have `man`.

</comment><comment><USER63> I see gitless has a bunch of 'gl ____ -c foobar' as well. Why is the -c (create?) needed? Isn't it apparent that if that branch doesn't exist we need to create it? If that remote doesn't exist we need to create it?

Convention over configuration?

<comment><USER64> Yeah but then there's the issue of simple misspellings. Perhaps switching and creating should be separate commands.

<comment><USER65> Exactly. It would be like if `cd pathname` was the equivalent of `mkdir -p pathname && cd pathname`. Even with tab completion, only a tiny minority of users want that behavior. To most, it invites mistakes.

</comment></comment></comment><comment><USER66> Why would I use this over Mercurial, other than being able to collaborate with others using git? You still need a Python interpreter to use it.

</comment><comment><USER67> I think tools like github desktop make this unnecessary. I've given some people a quick introduction to git using the desktop app, and they were up and running in about 20 minutes. Sometimes something goes horribly wrong, but it's a rarity. I think the worst case scenario encountered was: "No one knows what's wrong, so we'll use a comparison tool and manually merge in the changes from this branch with a bad repo state as a commit."

</comment><comment><USER68> Command-line and git aliases will get you most of what this has to offer unless I'm missing something.

</comment><comment><USER69> Seems like a couple of well named aliases would achieve 99% of what gitless does.

</comment><comment><USER70> gitless looks pretty nice, and I'll be installing and using it on my work PC tomorrow to see how I get along the rest of the week with it. I'm curious to see how the experiment goes.

</comment><comment><USER62> git init - create a new repo

git clone - download an existing repo from the internet

git status - show changes made in repository and any pending additions that haven't been committed

git diff - show changes made to file that haven't been committed

git pull - pull changes from remote repository

git push - push changes to remote repository

git log - show log of commits

git mv - move a file while preserving diff

git rm - remove a file

git add - add a file

git checkout - checkout a branch, file, etc

git reset --hard origin/master` - undo all changes, reset to last commit in master

git blame - show who is responsible for what in a specific file

git fetch - download objects from another repo/branch

git merge - merge two branches together

... etc.

</comment><comment><USER71> I like, just that python is slow.

</comment><comment><USER72> It seems inspired by Mercurial?

<comment><USER37> Not really. Mercurial doesn't use `checkout` in that way (it's an alias for `update` which updates the working copy to a specific changeset — or the tip of the current branch, the hg version of TFA's checkout is `revert`), prints a list of revisions with `log` and uses `add` and `remove` to track and untrack files.

It doesn't match Darcs's CLI either.

<comment><USER72> I meant more from the perspective that it wraps a more friendly CLI on top of a DAG of commits. Didn't mean that it's 1:1 copying Mercurial :)

<comment><USER37> Well then it's copying more or less any DVCS which is not git, git(1) is the least friendly DVCS CLI I know of.

<comment><USER72> Indeed.

</comment></comment></comment></comment></comment><comment><USER73> Git just is not my thing. I prefer Fossil SCM. Now that is a sweet little SCM.

<comment><USER74> I like Fossil too, and use it for many small projects. To some extent projects can be converted to/from git, but I haven't done much at all with that and I'm sure there are limits. Nonetheless, Fossil is an option with good usability that doesn't lock users in when there are reasons to convert repositories to other tools.

</comment></comment><comment><USER75> This seems extremely pointless. At worst, this seems like the Gitless team doesn't understand what Git is doing internally, which is a pretty dangerous state to be in when you're trying to "improve" something.

Git as a whole:

* Makes it really hard for you to do something you really shouldn't be doing

* Forces you to stay "clean" and guides you to working well with other repository copies (i.e. the whole point of Git).

* Warns you and makes suggestions when you make a mistake, from silly typos to incorrect command flags.

* Makes it easy to guess how the command _should_ be formatted or how certain structures are formatted based on convention.

They decided to rename certain features that not only give you the wrong idea of what's actually going on, but will no doubt make it extremely hard to research any errors if something goes wrong. A good example of thing is gitless' "fusing" feature. It's just rebasing stuff. Why rename it? Why rename "checkout" with "switch", when this semantic is used throughout git?

And then you have completely brain-damaged concepts such as this:

>(i.e., a file can be untracked on some branch but tracked on another and Gitless will remember this):

Honestly? There was no better way to indicate to me that you're just trying to make git fit some erroneous concepts in your head, and that you don't really understand what you're doing. This combined with the "auto-save" feature seems like a terribly, terribly bad idea and is just begging for a lazy developer who didn't take the time to understand his tools to completely shit on the repository he's working on, locally or remotely.

Take the time to understand your tools. Git is incredibly simple underneath. It's not complicated.

<comment><USER76> You have such a toxic and arrogant attitude about people trying to make the world a better place. It's shameful.

<comment><USER75> Uh, what? You respond to my post with some of the problems with this system in a hyperbolic, confronting manner without contributing anything. They are not "making the world a better place."

Please don't post such non-sense here.

<comment><USER76> Someone makes a project trying to make something easier to learn (so, trying to make the world a better place), and you call it "extremely pointless", you tell them they "don't understand Git", they're "brain-damaged", "erroneous", they should "take the time to understand their tools", because the tools are "not complicated" and "incredibly simple".

Besides your arrogant "I'm right, you're stupid and wrong, and there's no questioning me" attitude, why would you take such a hostile tone towards _anyone 's_ work, _ever_? How could you think that's okay or constructive?

I'm hugely sympathetic to the opinion that Git is needlessly difficult to learn and needless easy to make mistakes in due to huge flaws in the CLI. I'd present that case, but, hey, it's presented a hundred times here and everywhere else. It's clear there's no point arguing that point to you, though, because I'd be stupid and wrong just for disagreeing with you. So instead I'm trying to convey that your arrogance is unacceptable in the community in the hopes that it will not reappear.

<comment><USER75> >Someone makes a project trying to make something easier to learn (so, trying to make the world a better place)

Again, spare me the hyperbolic the "trying to make the world a better place." The principle behind my post, as given in my very first statement is that they basically failed. They are gearing people towards failure. It would have been better to just create a thin layer on top of git with _slightly_ renamed or alias commands -- all while having "release valves" that guide you into the true, underlying community crafted toolset underneath that git has been using for years (and for very good reason). Any errors you're likely to come across while using git have been documented either by the team or in various posts around the internet. It's easy to search for these errors. If your target audience are developers who have a hard time with Git, why would you make it needlessly hard to research errors that are likely to happen (given how new this tooling is). For example: labeling rebasing as "fusing" is basically telling them: "haha, good luck googling what just went wrong!". Good luck hopping on an IRC or Slack channel and getting someone to help you. A decade of community problem solving and documentation just went out the window because the Gitless team decided to play musical semantics with commands.

>why would you take such a hostile tone towards anyone's work, ever?

Leave your ego at the door. We're talking about a toolset.

>Besides your arrogant "I'm right, you're stupid and wrong, and there's no questioning me" attitude

Please do not respond to any of my posts in this thread anymore, especially if that is the basis of this comment chain. That is a ridiculous sentiment and I'm not going to devote any effort into addressing it.

>I'm hugely sympathetic to the opinion that Git is needlessly difficult to learn and needless easy to make mistakes

I would strongly disagree about the "needlessly difficult" part, but I would also claim that the "easy to make mistakes" is demonstrably false with Git. Git makes it extremely difficult again to do something _you should not be doing in the first place_ and then the community over the years has placed plenty of warnings when you do those questionable actions anyways; on top of giving you the ability to revert the mistake and bring your repository to a sane place with one simple command. Checking out branches with conflicting changes is just one of the simpler safety checks and roadblock that Git provides where Gitless decided to just go "Nah, you can actually do that." with seemingly no apology as to why you would ever want to allow such a thing -- other than just for the sake of convenience, but I would label it as laziness as it makes it incredibly easy to pollute your repository at that point. It doesn't even provide any kind of warning mechanism or cleanup tool for this handy "feature."

>So instead I'm trying to convey that your arrogance is unacceptable in the community in the hopes that it will not reappear.

The only thing worse than calling me arrogant is your complete, unconstructive obliviousness towards your own attitude. Not only have you still failed to say anything worthwhile or present any kind of counter to my opinion, but you're being a complete dick about it and trying to label me in a negative light for no reason. Which ends up really at the end of the day making you a troll at worst and a hypocrite at best.

<comment><USER76> I am _not_ talking about a toolset. I'm talking about how I believe you have a "I'm right, you're stupid and wrong" attitude. So I'm not disputing your opinion about Gitless, I'm criticizing how you presented it. I don't think the sentiment is ridiculous, because I think it's correct; clearly if you write it off as ridiculous then we're just talking past each other. Similarly, I don't think I am labeling you in a negative light for "no reason": the reason is that you are acting in a way that I think deserves to be called out negatively, so as to hopefully dissuade you from acting that way.

I do happen to think Gitless is a noble effort that will not change the world or be adopted by much of anyone, as with many interesting projects that are posted here, but I _still_ think you should be non-hostile towards it, and sympathetic instead of dismissive towards the problem it is trying to solve (since clearly there are heaps of people who feel the same way, as evidenced by these and many other comment threads).</comment></comment></comment></comment></comment></comment>


Police dash cam of Meteor over Edmonton, Canada (YouTube Video) - <AUTHOR> http://www.youtube.com/watch?v=e_2aX-784sw

<comment><USER2> I saw something similar recently. I posted about it on HN here: <http://news.ycombinator.com/item?id=373585>

</comment><comment><USER3> am I the only one who would have questioned if it was the end ?

</comment><comment><USER4> Awesome!</comment>


15 ways to make small budget content marketing work - <AUTHOR> http://searchenginewatch.com/article/2232313/15-Ways-to-Make-Small-Budget-Content-Creation-Marketing-Work

<comment><AUTHOR> Scrappy content marketing for small companies (also relevant for startups).

Pretty basic, straightforward recommendations but also covers a wide variety of areas. Good 101.

Key point here is that SEO and content marketing are colliding/merging. Especially true in the US but true generally.</comment>


Why iPhone Apps Are Too Cheap - <AUTHOR> http://20bits.com/articles/the-099-app-store/

<comment><USER2> The proposed iPhone API for in-app charges may finally start to change this. And the extra costs will not reduce an app's popularity.

Before, your _entire_ app revenue was locked up in that initial download. You either convinced people to try your app, or not.

But now, it's more sensible: if you have logical ways to extend your app, or improve it, there will be a way to let customers pay you for those enhancements.

And customers can use this to reward you for making an App That Doesn't Suck. You may (eventually) pay $20 for something in $.99 upgrades, but only if you use it for a long time. If you download an app that you end up hating, you've spent only $.99 instead of $20.

Then there's the fact that people seem to like incremental costs, even though they'd often balk at the equivalent cost up front. $59, or 3 easy payments of $19.95? $600 for World of Warcraft, or $15/month all these years?</comment>


Ask HN: What value has going to tech conferences provided for you? - <AUTHOR> I've been wondering if I should start going to more in my city or not.
I've tried going before and I felt like it was mostly a lot of people there who just wanted to feel part of the industry and network. I did not meet a lot of people working on interesting projects or attempting new things. This is fine, this is good for inclusivity. I'm just not sure if being there was a good use of hard-earned money and limited time when I have work to do and projects I want to work on.
I've met a girl recently who graduated from General Assembly said 'yeah, he's so and so from Google and he follows me on Twitter' after they briefly met at a conference. She was bothered that I didn't find it a big deal, that I wasn't impressed by it. Is this really a big deal if a person follows you on social media anymore? Especially if you are not building stuff and/or posting interesting content?
I'm not Elon Musk or Steve Jobs or _____ myself. I'm pretty ordinary compared to them, i'm a n00b in the HN world too. I'm not ashamed of that, I'm trying to learn more all the time from people a lot more experienced than me.
I'm rambling. Please enlighten me if I am missing out on big opportunities for learning and expansion. <comment> core-questions > I'm just not sure if being there was a good use of hard-earned money and > limited time when I have work to do and projects I want to work on.

If you already know what you want/need to do, and how, and have a customer for it (or an employer), then there's not much value. It's more if you want to find new solutions, consulting services, or hawk such things; or to look for new employment.

<comment><AUTHOR> > It's more if you want to find new solutions, consulting services, or hawk > such things; or to look for new employment.

Consulting services - what do you mean by that? To build connections for your business?

I can understand the employment part for sure. Also, seeing lectures/talks but I can watch things on YouTube and discuss it with friends in the industry or here.

I think going to a MeetUp would be best since it's free, about learning by doing, there is networking, free food sometimes. Would meet my 'tribe' there more than anywhere else I think.

<comment> core-questions > Consulting services - what do you mean by that? To build connections for > your business?

More like to find local consultants in your area to hire, if that's something you want.</comment></comment></comment>


How I Made Over 100% YoY Profit Investing - <AUTHOR> https://austingwalters.com/how-i-made-over-100-yoy-profit-investing/ <comment><USER2> Nice writeup. I have been using your project piglet for the news suggestions; I should have invested :-)

<comment><AUTHOR> Perhaps I should have invested more than my tax return ;)

</comment></comment><comment><USER3> That drawdown is brutal

<comment><USER4> That pullback was brutal but making profits in 2018 was a good thing. We tested 2017 levels on SPY.

I'd be curious how this works with options, specifically under 45 DTE options. I wanted to sign up a while ago when you posted just haven't had time to try other tools as I have been busy.

<comment><AUTHOR> Do note: I don't give access to my asset management software. The site at the moment is just when to enter and leave a given asset, not cross asset.

That being said, haven't tested myself. Given the advantage we're using (a method called ExpertRank), we recommend holding for at least one quarter. So I expect it wont work as well for that short, but maybe

</comment></comment></comment><comment><USER5> This is the real ycombinator isn't it, I can't believe this is up on here, is it April first already?

<comment><USER2> The guy who wrote this works on the machine learning team that I manage. This is his side (personal) project, and the project is real. He has been working on this for years. Not a April first joke.</comment></comment>