Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What's the worst piece of software you use everyday?
537 points by guu on July 11, 2020 | hide | past | favorite | 1500 comments
Subversion was created because the authors were frustrated with problems in CVS[0].

What's a piece of software you find essential that you wish you could replace or rewrite?

[0]: http://svnbook.red-bean.com/en/1.7/svn.intro.whatis.html#svn...

Sorry, but everything listed here is rank amateur stuff when compared to Blackboard Learn (https://en.wikipedia.org/wiki/Blackboard_Learn).

First, the user interface is designed as if the programmers were incentivized to maximize the number of clicks required to get anywhere.

Second, it has the responsiveness of continental drift.

Third, editing and formatting text is an exercise in torture. When I want to delete text that I am writing, half of the time, the delete key won't work (I'm exaggerating, but not joking). Formatting of text is quasi-random. Want red-colored text? That works about 90% of the time for me. The other 10% will give me gray text (This time, not exaggerating). If you are brave, you can edit your text as raw HTML, but, my God, you'd better bring the anti-hypertension pills, because the HTML will blast you with a tsunami of <span> elements. Sometimes the <span> elements (unnecessarily) surround individual characters, sometimes they surround _parts_ of words.

Third, it is nigh impossible to set useful defaults. Why can't the due dates for assignments be defaulted to the end of the day instead of the current hour and minute? Do you honestly think that I would ever want my assignment to be due at 4:33 PM?

Fourth, it tries to do too many things. I already have email. I don't need Blackboard's email functionality getting in the way.

I could go on (for a while), but it's time for those blood pressure meds.

There was an enlightening tweetstorm last year from a Princeton prof about the institutional reasons why Blackboard is so widely used despite being so bad: https://twitter.com/random_walker/status/1182637292869115904

IIRC Blackboard is also pretty aggressive about acquiring and/or enforcing patents against competitors.

What patents do they have?

A patent for a black chalkboard?


Successfully enforced against Desire2Learn.

Wikipedia claims it was invalidated on appeal.

Oh my god. WTF has the US Patent Office done to itself?

They must have been asleep at the wheel, and granted them this patent. They must have gotten starry eyed with all the wizardry of a web browser back in 2000, that they thought, this was a new and compelling technology.

The description of this patent, is just for a web site application, that will distribute assignments to students. The idea behind it is really not any more different than the GUI programs that were written on Windows 95 like the AOL program. They just splashed some fancy new words like "Uniform Resource Locator" and "World Wide Web".

This is another valid reason why software patents should be abolished. This is pure insanity. This is government and bureaucratic corruption of the highest order.

I think the patent office has absolved itself from all responsibility and shifted it to the courts. This mostly hurts small businesses that want to avoid court as much as possible.

A blackboard with rounded corners!

You'd think more people in leadership positions would try getting end-users involved in acquisition decisions. There seems to be a significant bias against doing that sort of thing in large organizations.

Why? As in, how would their lives be better if they did?

In general, if an organization runs more efficiently, it reflects well on the leadership of the organization. Exactly how that benefits a given leader in an organization varies greatly, but if the leader's incentives aren't aligned with the organization's goals, that tends to lead to an unsuccessful organization.

An organization that gets its workers good tools that improve their productivity rather than wasting their time will get more done with the same resources. It will also have an easier time with hiring and retention. Even if there aren't direct pay bonuses or similar incentives, this will likely make life easier for the leadership.

And that's not even getting in to the basic human decency that you should care about other people.

I was lucky to meet a guy who is running a company that id working on an extremely polished alternative, called Edubase. (I’m not affiliated.)

It seems both the students and the teachers love it. And I can see why. He demoed it to me and for example for Math exams it supported equivalent form solutions. That’s definitely not the trivial kind of stuff. And the list went on, both the capabilities were off the chart and the user experience was top polished. It’s already used on universities and in some private companies. Definitely check it out if you need a solution from the space.


Thanks! EduBase is both a complete LMS and a pluggable exam/quizzing tool for existing LMSes (like Canvas). EduBase Quiz features automatic scoring, grading and reports with lots of question types, including matrices and mathematical expressions, LaTeX support, easier, centralized content management with access control and cheating prevention tools. This makes it even perfect for STEM subjects (but not limited to them)! Our engine also supports question parameters (always changing numbers in texts and formulas), taking practicing and examining to the next level.

We have a webpage describing the power of EduBase Quiz at https://www.edubasequiz.com/en/ but you can even get started with the EduBase experience for free today on https://www.edubase.net/

Thanks for sharing, and I just want to say I love Edubase! As an adjunct frustrated with Blackboard, I basically went rogue and started using Edubase for my courses, converting a few faculty along the way.

My favorite part of Quiz is how easy it is to set up special answer types, such as matrices, equation editors, etc. And the editor is a dream compared to Blackboard.

The Blackboard -> Edubase Classroom switch resulted in 80% fewer student support requests (like trouble turning in assignments, questions about grade details, etc.). And with competitive pricing to Blackboard, it was a no-brainer.

Wow, you'all at Edubase going hard with posting positive reviews on the internet! Dunno if HN is the target audience for your product though.

> Fourth, it tries to do too many things.

My institution, unfortunately, uses Blackboard. Clicking on "Course Tools", I get the following, presented as one long list:

Accessibility Report, Achievements, Announcements, Attendance, Basic LTI Tools, Blackboard Collaborate Ultra, Blogs, Cengage Learning Mindlinks (TM), Contacts, Content Market Tools, Course Calendar, Course Health Check, Course Messages, Course Portfolios, ...

And that's just the first three letters of the alphabet.

"Second, it has the responsiveness of continental drift."

That's just poetry. Well written and I can only fully agree on Blackboard. Any usability of this software comes from the consumer remembering how to get to places likes it's a GTA cheat code. Just a random sequence that you can only find if you know.

Canvas is for sure much better, but has its own issues. It marketed itself as the anti Blackboard, but it's begun sagging under its own bloat, and feature development slowed way down. It doesn't help that Instructure just got bought by a private equity firm, and fired a bunch of their employees.

Piling on the Blackboard is horrible train, my kids school system uses Blackboard, Fairfax County, VA, FCPS. Its true awfulness was on full display when the school system tried to switch to FT remote schooling back in the Spring. Parents, students, and teachers all clamored to not use Blackboard. Administration did not listen. It did not go well. From the time schools shut down until the end of the school year it was essentially no school. The Director of IT for the FCPS took the fall, but Blackboard was at root the problem. Blackboard tried to shunt all blame onto FCPS. I suppose in a sense FCPS was at fault, in that they bought the steaming pile of crap in the first place.

https://wjla.com/news/local/technical-issues-latest-on-virtu... https://www.washingtonpost.com/local/education/fairfax-schoo... https://www.tysonsreporter.com/2020/04/21/fcps-dropping-blac...

> Director of IT for the FCPS took the fall, but Blackboard was at root the problem

Rightly so. The Director of IT should have known better than to push a flawed product hard on parents/teachers, for months. I'm wondering what Blackboard's sales practices are like that they can get school's IT people on their side!

I wonder if Blackboard is any better since 2016 when Bill Ballhaus took over as CEO. I met him when I was an intern at SRA International and was beyond impressed in my brief time there. Besides his obviously impressive technical and management credentials, this was a titan of industry who remembered my name and always initiated conversation whenever I ran into him. We also had the same car (a GMC Yukon), although his was older.

I suppose I could just have been subject to his charm and I suppose this could be a ridiculous heuristic, but I definitely have a lot more confidence in a company (and its software) when the CEO drives a practical car and is kind to the interns. Hope Blackboard gets better under him just because it’s so deeply engrained in educational institutions.

My university has been a Blackboard customer for awhile, and so I've used it since 2011. My sense is that the software has gotten marginally better in some ways, marginally worse in others, and overall still sucks.

They redesigned it, in what is apparently an attempt to make the software more usable from a mobile phone. So (on a laptop), less stuff appears on the screen at once. This was billed, as usual, as an "improvement".

Also -- and quite frankly, this is ridiculous -- when I need to merge two sections of my course, I need to ask IT to do it for me. (Example: a big calculus lecture, which is broken up into multiple TA sections that have different course numbers.) It used to be that I could just do it myself, no problem. Then the option silently went away. I was informed that we used a plug-in (??) made by a third-party vendor (????) that enabled individual instructors to merge sections, but the third-party vendor went out of business and so this is no longer possible.

Makes me speculate that the codebase is a giant pile of spaghetti.

A giant pile of spaghetti, and every institutions spaghetti totally different.

Even more is that many schools were suddenly served a huge plate of spaghetti– or a metaphorically similar type of grain– and in a time crunch to understand how to dish it out to their students.

I worked at SRA for many years and Bill destroyed what was once the best corporate culture I had ever experienced. Among his accomplishments was introducing stacked ranking. Under his management SRA became just another body shop.

I guess I can't blame him too much. That is exactly what Providence Equity brought him in to do.

If I were sampling perceptions of Bill's effect on the company, I'd obviously place a higher value on your experience than my own short time at SRA. Didn't know about the stacked ranking thing; I'm not a fan of it (and I'm glad people have started to believe Jack Welch's implementation of stacked ranking at GE wasn't such a brilliant move that should be copied elsewhere).

But if I were CEO of a big company one day, I'd definitely want to interact with the rank-and-file the same way Bill interacted with me.

Gradefinity (https://gradefinity.com) is a kind of Blackboard + Scantron LMS alternative that is really targeted in terms of what problems it intends to solve (in-person and online tests, gradebooks, and communication).

Full disclosure: I built it-- I'm very receptive to feedback and feature suggestions though and am looking for pilot schools if anyone is interested in shaping the platform/knows someone who might be.

Some questions: does Gradefinity have the ability for teachers to publish learning modules for collaboration purposes? And orchestrate tasks among themselves? For example two teachers both writing up 200 vocabulary words to make a 400 vocabulary words quiz - can that be merged? Sharing content both between teachers and between classes is extremely important and seems to be underserved by Blackboard. Also do you model classes as being able to span terms, i.e. a two-semester class is a single entity?

In its current form, no-- but the content collaboration and task management you're describing seem reasonably straightforward to implement.

Courses as they exist now are unaware of semesters or terms, and are only tied to the students enrolled. So if the students enrolled in a particular class don't change (or change very little) between two semesters, you could continue use the same course for a 2nd semester if you wanted, or you could import your students into a new class and name the new class "Class Semester 2" for example.

I'm happy to work on features to fit your use case if you're interested in offering suggestions or are looking for a better solution than your current one; my email is brad [at] gradefinity [dot] com and I'm generally pretty available to talk about features/suggestions/demo stuff, etc.

I just moved to a new university that uses Canvas, and while it is not perfect, it actually does not cause physical pain when entering data.

We use Moodle since we can not afford the privilege of paying a lot of money for such a crappy experience. I notice a lot of other schools went with Canvas for the same reason.

Here in Germany, Moodle seems to be the defacto standard (100% at n=4). It surely does have some rougher edges, but overall I like it a lot.

Its also very well supported by course provider companies. I have installed four plug-ins to handle using outside company tests and courses.

Ugh, this brings back terrible memories from grad school. It was horrible as a student, horrendous as a TA, and that one time I filled in for my advisor, it was a nightmare!

Wow, surprised to find this and I totally agree. I've had to deal with it for a remote math course I've been meandering through. It's so unpleasant, and the materials are not very mobile, with nested iframes and such. I figured it would be a more obscure reference.

It's by no means pretty, but my university is using it and from a students perspective it's working decently well, and better than the systems from other universities I've attended. It also handled the increased load from the online semester quite well. Not sure how much customization they did on top of it, and judging from the screenshots on the official website it's definitely not the latest version.

We're building Eduflow (https://www.eduflow.com) – a light-weight LMS born out of some of the same frustration aired in this thread: LMSs are to enterprisey and seem to be designed with somebody else than the actual end-user in mind.

(Plus, we were in YC batch S17 with the predecessor to Eduflow – Peergrade)

It truly was horrendous.

Anything Atlasssian. Jira, Bitbucket, confluence. Just frustrating to use, poor UX, and slow. Business types love them however.

AWS. It’s UI is honestly baffling, it feels and looks like someone made it in a rush with jQuery and Bootstrap years ago. It’s login and identity and resource management is confusing, and apparently you need a chrome extension which adds a bunch of complicated options I don’t really understand just to be able to change roles. It is literally years behind Azure.

Git. It’s purposely archaic commands and syntax leads to too many accidents far too often. I recently started using Gitkraken which allows you to pull changes WITHOUT needing to commit locally first because it uses stashes. It basically does the same option. Why can’t git be smart like that?

Linux. It’s great, but it’s so easy to run into configuration problems or poor documentation.

Docker. Again it’s great but for whatever reason it just works poorly on ARM and the whole ecosystem is geared to x86 and it just goes and pulls the x86 images and then fails to run them. Come on.

Don’t agree with you about git at all, I find it’s one of the few tools I work with that behaves expectedly and gets out of my way, if you want that workflow of stash, pull and reapply a stash why not make an alias for it?

    git config pull.rebase true
    git config rebase.autoStash true
I think these should have been the defaults but they weren't implemented until later and it's hard to change defaults.

Setting rebase to true by default is not a good idea if you push your code to your dev branch regularly (rather than just committing).

I think that's a bit of an exaggeration; "pull.rebase=true" should be fine as long as you don't have local merge commits that need to be rebased on top of someone else's changes. With ordinary commits, it shouldn't really matter how frequently you (or others) push.

"git rebase" has --preserve-merges (apparently renamed to --rebase-merges a few years ago) to recreate those local merge commits, maybe it can be set somehow for this as well?

Exactly. That’s the default I use. You can set it via:

    git config --global pull.rebase merges

Great to know about these. I still think the current default is better: for a new user, it might be scary for your uncommitted changes to "vanish" into a stash.

The stash is popped before the command finishes, so your changes don't appear to vanish. Unless there's a conflict while rebasing a prior commit. Actually I'm not sure if aborting the rebase at that point would pop the autostash, but it should.

Got it. In that case I agree.

TIL. Thank you for this!

The functionality of git is great. Mostly. (I think the whold concept of stage/index/cache is completely unnecessary though) I find the UI to be inconsistent and confusing. Why would I ever want to make a branch without checking it out? It's literally never happened, yet it's the default.

> Why would I ever want to make a branch without checking it out? It's literally never happened, yet it's the default.

  git checkout -b new-branch
I fairly often make a branch as a sort of named undo point, and only check it out if need to undo to that point. Tags could work for that purpose too, but the branch approach seems safer in my usual work situation.

> I fairly often make a branch as a sort of named undo point

Could you say more about this? I use

  git checkout -b new-branch
all the time, but that checks it out. What does "using an un-checked-out branch as an undo point" mean? Don't you have to check it out to commit changes to it? I suppose I could read the docs but the git docs are awful.

It creates the branch immediately for your last commit on your current branch. Therefore you have just named an undo point you could use later.

Occasionally I find it handy to tentatively do a rebase or similar, where I'm confident that the rebase itself will succeed but not so confident that the result will be something that I want to keep. In that case, making a branch at the current commit (using "git branch new-undo-point") will leave an easy way to return to the current state as if the rebase never happened.

Recently, in explaining this to a colleague who's relatively new to git, I think the "aha" moment came in realising that if you rewrite the history leading to commit X, you're really making new commit Y in addition to the old commit X - you're not changing X in to Y. Leaving a branch pointing at X is enough that git will keep it around after the history rewriting, in case you decide to do something with it later.

Ah. I get it. You're talking about using a new branch name as a tag for an existing commit. Thanks.

Wow, I’d never thought of using it like this. Thanks for sharing, I just added something new to my workflow!

It's actually an answer to a standard interview question. I've met it more than once.

Funny thing, nowadays it's going to be deprecated in favor of:

    git switch -c newbranch

Which is similarly terrible; it should be a flag on the `branch` command, not `switch`.

I actually popped on the git development irc channel a few months ago to make this suggestion. The two people I talked to (at least one of whom seemed to be a core developer, although I did not verify this) did not see how, if you're going to conflate the actions of creating a branch and checking it out, it makes more sense to do this as a flag on the primary action, branch creation.

They were nice enough to have an in-depth conversion with a complete newcomer, though, so it was not a negative experience overall. Maybe someone else could convince them :)

Maybe this depends on your mental model of what a git checkout is? To me, "git checkout X" means: update the working directory to reflect X and update HEAD to point at X. (edit: and HEAD means "the branch to update when a new commit is made"). I use "git checkout" a lot more often than "git branch" and "git checkout -b" combined. So, to me, the fact that X is a to-be-created branch is secondary to the primary "checkout" operation.

That said, I do vaguely recall this seeming weird at first.

I'm going to discuss mental models in a separate comment because they're actually more interesting and this comment is getting too long.

---Succinct argument---

What happens if you remove the flag? Put differently, how much does the flag change the semantics?

`git branch newbranch` will gracefully fall back to creating a new branch at HEAD.

`git checkout newbranch` will fail (error: pathspec 'newbranch' did not match any file(s) known to git), because the regular version of the command involves operating on something that already exists.

---Less succinct further argument---

checkout's `-B` variant. Here's how the man page explains it:

> If -B is given, <new_branch> is created if it doesn’t exist; otherwise, it is reset. This is the transactional equivalent of > > $ git branch -f <branch> [<start point>] > $ git checkout <branch>

If it were a flag on branch, you wouldn't need a separate flag, just `git branch -fs newbranch` (-s for --switch).

Actually, looking through the man page for `checkout` now, I see 4 other options I didn't know about (-t|--track, --no-track, --guess, --no-guess), apparently for the sole purpose of being used with -b.


I don't think I thought of this argument when I originally chatted in #git-devel, maybe I'll give it another try.

> HEAD means "the branch to update when a new commit is made

Thank you for the edit; this is where our mental models diverge. Yours is the technically correct version, but when I'm working, I introduce a small abstraction on top. I've never written this particular part out explicitly, so please bear with me and feel free to suggest better names or phrasing.

I'll call it, "the checked-out branch" (or other <tree-ish>, but let's leave out detached HEAD for simplicity). It's like your model, but also includes the state of the repo at that commit. This is a really subtle difference, but the key is that checkout is one atomic operation.

I think the easiest way to explain is by analogy[0] to editing a regular text file. You've got the file on disk, and the version in your editor's buffer (working tree), and every time you save, you're making a commit (with `--amend`, on most filesystems). When you decide to edit a different file, and open it, technically there's two independent operations -- switch which file handle you're writing to, and replace the contents of the buffer with the contents of the new file -- but I seldom think of it this way (and I can't think of an editor that separates them).

This is also why I don't like overloading with `git checkout <commit> -- <files>...`, which does not update the HEAD. It shatters the "open file" analogy; it's like changing the contents of your buffer without changing which file you're writing to. In my mind, that's a totally separate function (typically accomplished by opening the other file separately and then copying its contents into the buffer, an inefficient operation that I'm grateful git provides a better alternative to).

Aside, I also prefer to think of each branch (not commit!) as having its own persistent working tree and staging area; I'd prefer not to have to push and pop a stash each time I check out a new branch if I already had some work in progress. `git worktree` comes close, but lacks the ability to navigate between worktrees but stay in the same directory relative to the root, like `checkout` does. Also you have to initialize other worktrees with a different root, which pollutes the file system or forces you to use an extra level of nesting.

It's been on my list of projects for a while to write a git porcelain that works the way I'd like, but it's pretty low priority (despite my complaints, git works pretty well for me), so I doubt I'll get to it for a few years.

[0] Come to think of it, maybe "analogy" is not the best word. It's more like, I prefer to view git as an extension of my filesystem, so I want a consistent mental model across the whole thing.

Thanks for the post! I should mention that I'm not a git expert by any stretch, just a git user who's recently been herding some folks at work from perforce to git (so have brushed up on git explanations/internals).

It seems like the conflict is that there actually are some separate things going on "under the hood", and you're not satisfied with the way that git has combined them? To be explicit, some distinct steps we're discussing are:

1) Update the working tree to match the tree-ish

2) Create a new branch

3) Update HEAD to point at the branch (or other tree-ish)

As is currently implemented, "git checkout somebranch" does 1 and 3, "git checkout somebranch -- <files>" does just 1, "git branch somebranch" does just 2, and "git checkout -b newbranch" does 2 and 3. AFAIK, there's not a "git branch" argument that causes it to update HEAD, but the standard version of "git checkout" does exactly that. From the perspective of a new git user, maybe "git branch" is the obvious command to look at for making and using a new branch, but I think "git checkout" is the obvious command for using a branch.

So, perhaps "checkout" could have a better name; maybe "use" or "work" instead?

I must admit that I don't understand what you mean by "state of the repo at that commit" - is that related to the idea of each branch having a persistent working tree and staging area? When I run in to a situation where the second would be relevant, I tend to do "git commit -am WIP" then on return to that branch, "git reset HEAD~1". It very rarely happens that I'm in the middle of composing a commit (staging things) but need to switch to a different branch in the same project, so it doesn't really matter that the staging area and working directory all got munged together.

I've been quite busy; hopefully you'll see this. Like above, I agree that you're technically correct.

First, I would like to re-order those steps (and I am curious whether you intended the order to be meaningful). Then, I'll try to explain how they, while technically correct (again) to the best of my knowledge, don't match my mental model (particularly "update working tree", which is not part of "checkout" in smichel17-land). Yes — this is related to the "persistent working tree" (or maybe "working tree as a concept that doesn't exist in my mental model" would be better phrasing — but I'm getting ahead of myself).


Note that without flags, you'd have to "git branch" first, then "git checkout". Also, it's easier for me to think about if each command only performs consecutive steps, in order. Fortunately, we can achieve that:

1) Create a new branch

2) Update HEAD to point at the branch (or other tree-ish)

3) Update the working tree to match the tree-ish

"git branch somebranch" does just 1, "git checkout -b newbranch" does 1 and 2, "git checkout somebranch" does 2 and 3, "git checkout somebranch -- <files>" does just 3. I think this helps clarify my issues with both -b and --. They both change which step "checkout" starts on (and "-b" changes the ending, too!).

By analogy: if these commands are like functions, adding a step afterward is like a flag that modifies the output, while adding a step before is a flag that modifies the expected input. Sure, you could organize your code around the outputs it produces, and sometimes we do that (eg, serialization/parsing you have things like JSON.stringify, String.fromInt, different constructors for classes, etc). But typically it makes more sense to group based on what you want to do with a given object/class/data-type — it's nice to be able to answer, "I have an X, what are all the things I can do with it?"

Maybe that's stretching the analogy a little. But it ties in with my original comment mentioning the "primary action", which I guess I could rephrase as "first action in the chain".


What's the primary action of "checkout"? Well, "updating" the HEAD. So here's where we get back to abstractions / mental models — I would say, moving the HEAD. But first, let's take a short detour.

What's a commit? Technically, it's a diff and some metadata (author, parent commit(s), ...) with a deterministic name. But in terms of actual use, it's a snapshot of the repository at a certain point in time. (Or, if you'll permit a little snark, a version, as in "version control".) Zoom out to the whole repository, and you can visualize it as a tree of commits, ordered along the axis of time. Visualization:

    git log --graph --format="%C(yellow)%h%Cgreen%d"
That includes branches, so what about them? Technically, they're tags. But in my mental model, they're boxes which contain mutable state that I might want to commit. They're the buffer in my text editor, where I make changes before saving to disk. As a crude visualization of making a commit, I choose a subset of those changes and put them in the bottom of the box (stage them), then chop the box in half. The bottom becomes the new commit, and the branch remains on top, still holding any unstaged changes.

Finally, back to the HEAD (our detour is over). Technically, it's just another tag. But to me, it's a camera, through which I look at a given box (or snapshot). It's the location where I am. It's $PWD.

To bring it all together:

- Branches sit on top of a commit and stay there.

- When I check out a different branch, they remain on top of the same commit, still holding the unsaved changes in their box. This is what I meant by "persistent working tree".

- Checking out a branch, conceptually, is just moving my view (HEAD) to a different branch. It doesn't involve changing files. It's the equivalent of "cd".

So this is why it barely makes sense for me to talk about "the" working tree. I have a bunch of boxes/folders/"working trees", called branches. That I have to copy them to "the working tree" in order to edit them is an implementation detail. Step 3 above (your 1, "update the working tree") doesn't exist in my mental model. You just move the HEAD. One atomic operation.

"-b" and "--" both break my mental model because they add side effects to an operation that's otherwise just "look around." "-b" isn't quite as bad, because I could imagine a flag on "cd" that makes it run "mkdir -p" first ("Go here, even if it doesn't exist yet."), but it still makes more sense as a flag on "branch" ("Create a new box, and look at it").

> So, perhaps "checkout" could have a better name; maybe "use" or "work" instead?

I think the new "switch" fits pretty well. And, "git branch [-s|--switch]" aren't taken yet :)

Aside, "git reset" is about moving which commit a branch sits on top of, and its various hardness flags are about what to do with the contents of both the box and the commits it was sitting on top of. There used to not be a command for "copy some stuff into my box from a different box or commit", so I had to use checkout, but now there's "git restore".

Thanks! No, there wasn't any reason behind that ordering, as far as I remember.

> What's the primary action of "checkout"? Well, "updating" the HEAD.

This might be where we diverge - I'd say that the primary action of "git checkout" is to update the working tree, secondary action is to update HEAD.

> What's a commit? Technically, it's a diff and some metadata (author, parent commit(s), ...) with a deterministic name. But in terms of actual use, it's a snapshot of the repository at a certain point in time.

This isn't actually the case; git commits contain a "tree", which is not a diff. The tree is a table of file paths, attributes, and hashes that each identify a "blob" - the (compressed) contents of a file. The commit represents a state of the committed files (and links); to me "snapshot of the repository" would include things like the state of the branches in the repo, HEAD, and commits that are present but outside the history of the commit in question.


Thanks for the explanation, I think I understand what you mean and like the idea. Maybe this is what you alluded to a few posts up, but it seems like a new subcommand could roll up the working directory and staging area in to a temporary commit or two, do the normal "git checkout otherbranch", then unroll any temporary commit(s) that were present in otherbranch.

At a previous employer, I used mercurial including a feature (perhaps provided by an extension, I can't find it at the moment) that allowed a commit to be marked as local-only, so it wouldn't be pushed. Something like this could probably be done with git hooks to prevent the temporary working/staging commits being shared unintentionally.

There's an interview question about some behaviour of git that people don't rely on very often? Wow. Asking anything about VCS seems a bit off in general if the person has any experience under their belt developing software...

> Asking anything about VCS seems a bit off in general if the person has any experience under their belt developing software...

Why so? We don't go into great depth, but every hiring committee I've been on I make sure that we ask something about source control.

You can learn a lot about a developer's process by finding out if and how they use source control. (Red flag, for me, is if an apparent senior dev doesn't use a VCS.)

Isn't there a difference between knowing/understanding VCS and git flag trivia? Seems needlessly pendantic?

Not GP, but if I were, to me 'I can never remember the flags, so I made aliases' is a good answer. (Problem-solving, learning to use tools in a way that works for them, etc.)


Red flag = warning sign, not anything related to Git flags.

OJFord is basically correct, though. It's 2020, so if you're interviewing for a developer/programming position, you should at least know something about the various VCS options.

If it helps, during our last set of interviews the question was "What is your strategy when using source control?"

Before that was the two part question of "Describe your preferred development environment, both physical and technical. What is one thing in your development process that you can’t live without?" (I always tell the candidate that my answer to this is some sort of VCS.)

(These were both for the second, in-person, interview. There's not necessarily a wrong answer. It's not like we're asking them to name as many differences between Git and TFS as they can. :) )

Who asks interview questions about git syntax? I’ve never encountered this (in 20 years) and hope I never do.

I seem to make tracking branches just as often.

  git checkout -t remote-branch

I like staging my changes with `git add -p` before I commit as a way of reviewing what I did. I often catch mistakes or unnecessary changes this way. I suppose you could build the same workflow with stashes, but it seems quite awkward that way.

git add -p is extremely useful if I encounter a typo or something while doing some other change. Then I can commit this small unrelated change in its own commit without mixing with actual changes and without losing my context (of course this should be trivial stuff only, as it might be mixed up in the feature branch of current work)

I just review the diff before I commit.

I do the same thing for small commits. Anything larger than ~25 lines (to the point where the whole diff doesn't fit on screen at once) becomes a lot of wasted time finding where I left off. Adding things incrementally means I don't need to look at them twice.

I rarely use git add (basically only for new files or non-text files) and instead always use commit --patch.

What do you do when you come across lines that you want to commit, but edit beforehand? I always run into syntax errors when I use `e` to edit a diff during `git add -p`, and it doesn't update the file in the working tree, which I also want. Skip it and then `commit --amend`?

A tiny change like a typo in a comment I would just edit in both the git commit --patch `e` editor and in the working tree copy. Anything bigger I'd either abort or skip and edit/test normally and then amend. My main use for `e` are not really edits to the final code but rather for splitting up changes that affect the same line.

I only had problems with errors from `e` on Windows - I'm guessing due to wrong line endings.

TIL about this. I was using `git add -i` and using the patch function.

> I think the whold concept of stage/index/cache is completely unnecessary though

I was thinking the same for many years. But lately started to use VSCode for some projects. To see how staging is integrated there was almost an enlightening experience to be honest. All it takes to make staging an extremely useful feature, compared to all the other IDEs, is a slight change in how diffs are presented: In VSCode line-change markers indicate only a diff between working tree and cache (and not working tree and HEAD, like "everywhere" else). After staging a file in VSCode all inline diff markers disappear and the file looks like it would be unmodified. Than, new changes on top of the staged stuff will result in line change markers and inline diffs (showing only the unstaged changes). This way one can track "changes on top of changes" without having to commit the intermediate steps. This makes building up even big commits quite convenient as one can do it in small steps, having a (directly visible) diff of manageable size at any time in this process.

You don't need an extra cache level for that. If what you want is to accumulate "adds" one at a time into the cache to create one combined commit, you could just accumulate small commits until you had what you wanted, then merge the commits into one combined commit before pushing to the server.

Sure. And I was doing this.

But it requires a lot of additional ceremony—alone naming the intermediate steps… ◔_◔

Or just one commit and keep amending it.

This approach doesn't allow you to easily revert parts of your last change-set. Actually you can't even distinguish in the diff your last changes form all the other accumulated changes once the recent change-set was commited.

I don't follow. You could totally implement a staging area workflow by making a commit with the message "Staging Area", repeatedly amending it, and then finally giving it a real message when you're ready to commit "for real". The main thing you lose that way is the ability to push safely.

Counter anecdote: I don't know how to create a branch without checking it out.

`git branch {foo}`

For once, it's a git command that seems to be clear about what it does, but it just doesn't check out.

Not all git repositories have working trees. On a bare one a checkout doesn't work.

If you want to change from a git-lover to a git-hater, just join a project that uses submodules.

That happened to me few months ago when a new submodule was added that gets updated regularly (old ones are some legacy libs just lying there). I literally had to beg some colleagues to not forget to commit the changed submodule ref to host/main project. None of them even understood why it was needed since "it would anyway be solved by `git submodule update --init --recursive` anyway".

Also, of late I have turned to "a lover of git GUI apps" form a full "git in cli is the best evangelist". But that has happened for most other tools as well. I guess I am kind of done with cli.

Similar here, but without learning the CLI first, I would not be comfortable with the GUIs.

Lol... Don't want to go down that rabbit hole. So many tools have been written to help with submodules. Such a shame. I feel like the only success path for submodules in any project is for anyone working on the project is to understand them completely.

I've been using git for a decade, and I still have to Google simple tasks. The answers rarely make sense.

My history with git is shorter, but ditto to the web search for simple tasks. Before git, I used svn, and most things there made sense (not everything, I admit).

git mv foo.bar <SomeNewDirectory>/

It loses all history of foo.bar. I guess if you pull up a version before the mv, you can still see it, but as far as git is concerned, foo.bar in the new location has no relationship to foo.bar in the old location.

Many people have complained about this over the years, but it's still that way. Because (they say) Linus likes it that way.

    git log --follow

Disagree strongly on git. On the surface the syntax is ugly, but the data model is brilliant.

Once you wrap your mind around what commits, heads and remotes are and learn to rebase you get an incredibly simple and fine-grained control. I never use stash because it's trivial to create a WIP commit and rebase later into the chunks I want to ship to permanent history.

Git is like a chef's knife: extremely powerful tool that's dangerous in untrained hands.

> On the surface the syntax is ugly, but the data model is brilliant.

It's beyond ugly, it's needlessly incoherent. I use it because I have to and hate it. I've heard people say "the data model is a work of beauty". And I suppose that's true, but why have such a fucked up and confusing set of commands? Doesn't a "brilliant data model" deserve an equally brilliant command line?

The thing that saves git is that it works, and by some miracle, it is popular. People just memorize what they need to do for their workflows and that's mostly fine. Sometimes there's a screw-up and you blow time googling around or looking up fixes.

People won't publicly admit it but a lot of work gets trashed because finagling git intricacies is more painful than throwing away some work and starting over.

> by some miracle, it is popular

Probably because Linus Torvalds wrote it, and also because GitHub was actually quite a significant improvement over SourceForge. I know some people "love to hate" GitHub, but they made some really good "developer-first" UX improvements that many copied for good reasons. And lastly, Linus Torvalds wrote it.

I still maintain that Mercurial is far better for most uses. Every time I mention this I get a flurry of technical replies about stuff most people don't even know about (HN is strongly biased like that, which is not a bad thing, just something to be aware of), but most people just want to commit, push, pull, and some related stuff like that. Git makes a lot of simple common stuff arcane to make the complex stuff easier, whereas mercurial makes the simple common stuff easy and keeps the complex stuff arcane. This strikes me as a much better design philosophy.

Git and Mercurial are a tool designed to facilitate writing code (which is also a tool designed to solve problems). If you need to spend significant time to "get your head around it" then IMHO something, somewhere, has gone wrong.

I still use git because it's just the pragmatical thing to do at this point in time, and to be fair there have been active efforts by the git team to make the common/simple stuff easier in recent times, but yeah, I'm not a fan.

> Probably because Linus Torvalds wrote it, and also because GitHub was actually quite a significant improvement over SourceForge.

I'd say it was because GitHub created a solid community that worked. And yes, Sourceforge was a huge piece of garbage with it's awful clickbait, misleading "download" buttons, and scammy crapware foisting.

That Torvalds wrote git doesn't automatically make me want to use it, I think most people feel the same.

Yes! I love Mercurial, it feels like someone designed a proper interface, instead of just exposing the internal api calls

I use git a lot, and I like the speed and decentralized nature. But I do think there's much to be improved.

Named branches don't really exist in git: there's only a moving target name that refers to a leaf node. This means there's no "history" associated to a branch except for the parent commits. But in merge commits with several parents all parents are considered equal, and the system does not contain info about which commit belonged to the "main branch" and which was imported in. This information can be valuable in some cases. This leads to a lot of rebasing just to keep the commit log clean, but this actually rewrites history and destroys information.

Also, there's no support for keeping two parallel views of the same repository (for example, an internal view with lots of subcommits, and a cleaner public view with more detailed messages, and perhaps fewer privacy-compromising names/timestamps).

Finally, handling merge conflicts is still a PITA, especially on LaTeX documents.

> But in merge commits with several parents all parents are considered equal, and the system does not contain info about which commit belonged to the "main branch" and which was imported in.

I thought that merge commits stored an ordered list of parents, and the first parent is generally the main branch, and second parent is a side branch.

It does! I'm not sure what that person is referring to. git log can even use ASCII art to depict the relationship. Most modern git web frontends depict the relationship. Sourcetree, gitkraken depict the parent relationships. I wonder if we're misinterpreting? But the parents are distinct from one another, the hierarchy is not lost on merge. Part of the reason I prefer merge commits rather than rebasing.

Note: they don't have to be exclusive. You can rebase a branch so the history is linear, then merge --no-ff and create a merge commit for it. This gets you something like the best and worst of both worlds.

What about a “git init-lite” option?

So many times I want to VC a directory but don’t care about commit messages, branching, or other jazz more suited to collaborative work.

With init-lite, all the power of Git is still there - and you can use any commit or command you want, but it’s default would be to simply VC for every file save. In other words, a file save IS a message-less commit.

This exists: it's the git-annex assistant! You just have to configure the "annex.largefiles", because by default git-annex doesn't actually commit the content of the files, since it's designed to handle large binary files.

But if you set that option and run the Assistant, it'll auto-commit files when they change, and can even auto-sync them with other computers, cloud storage, Android devices, etc.


Sine decades I wish this would be a std. OS or FS feature!

Back in the stone age I worked at a place that used a VCS called ClearCase. It supported exactly this, you'd be able to append things like @revision or @branchname or @timestamp to file and directory names to access them.

Unfortunately, it required (IIRC) three full time people to administer the server. As for the client (my workstation), it required a proprietary kernel module which would panic about once a week. I'm told our license cost $1m/year (2001 dollars).

Indeed. I still miss VMS because of its automatic versioning, with version numbers being an explicit field of the pathname.

It's something that exists in macOS, but as far as I know applications have to explicitly choose to use it. Most applications that support it have a "File > Revert To > Browse All Versions..." command available. BBEdit -- as often the case -- has a more useful variant of it, which brings up a diff window with "Search > Find Differences > Compare Against Previous Version". (It actually lets you choose any recorded previous version.)

The good news is that git is extensible enough to support this use-case. You would need to wrap git with a tool/script that watches for file changes

> This leads to a lot of rebasing just to keep the commit log clean, but this actually rewrites history and destroys information.

Completely agree. I think rebasing is misguided. The objective is to keep history clean and linear. The proper way to solve that problem is with smart log analysis for different customers, not fictionally rewriting the log itself.

I think the best argument against git is to use mercurial for a few months. It has exactly the same functionality but a nicer and more streamlined interface, especially when it comes to branch management.

I think this point can be concisely summarized with:

  $ git help commit | wc -l

  $ hg help commit | wc -l

  $ hg help commit -v | wc -l
Also, git currently has 169 subcommands by default, vs. mercurial's 50 (more available as extensions though).

Yeah, when dvcs started becoming all the rage I tried mercurial first for some toy projects and really liked it. When I finally had to start using git I was absolutely baffled that it had won. I feel like git needs something that sits on top and does most the normal configuration and wraps the api. It reminds me of the problem with emacs, there is so much it’s just overwhelming to people.

Technically this already exists; git commands are divided into two groups, plumbing and porcelain. Plumbing commands have stable interfaces and are intended for building alternative interfaces with; porcelain commands are intended to sit on top and be the actual user interface. They're what you're used to using.

I love mercurial but since I've gotten used to git I miss the lack of the staging area and stash in mercurial. I have to grudgingly admit they're very useful.

In some cases (all my usecases, but perhaps yours are different) the staging area can be replaced by some combination of "hg commit --amend" and "hg commit --interactive" - or in older versions "hg rollback" and "hg record".

You can get the "git stash" with the shelve extension: https://www.mercurial-scm.org/wiki/ShelveExtension

Do you think mercurial has a better data model, or could git reach parity with just a better interface?

I don't know anything about mercurial's internal data model, so it's hard to say. In particular, it makes some fundamentally different choices (e.g. no staging area, the ability to use unnamed branches). I certainly think git could do a lot better with its interface though.

I understand Git, but for my rebase-based workflow, I don't like how Git doesn't understand commit identity when you rebase. Git doesn't know the old and new commits with the same name and contents mean the same thing, though rebase tries to skip commits it thinks match.

When you rebase one branch, it doesn't move other branches and tags pointing along the history.

You can't rewrite a repository and change your username in past commits, without completely rewriting all of history, creating two parallel histories, and merge conflicts.

Git's mental model makes "moving a branch onto a different commit" (git branch -f) a natural operation. But no graphical tool I've used allows you to do that on a branch you're not checked out on.

> Git's mental model makes "moving a branch onto a different commit" (git branch -f) a natural operation. But no graphical tool I've used allows you to do that on a branch you're not checked out on.

This is trivial in SmartGit, I do it all the time.

Simply drag the branch marker to the commit you want it on. It doesn't matter if it's the checked-out branch or not.

I've tried a few Git GUIs, but SmartGit continues to be my favorite. Pretty much every one of the recipes on https://ohshitgit.com/ is just a simple drag and drop or menu command in SmartGit.

One of my favorite things is the way it handles the reflog. Just click the Recyclable Commits checkbox and every reflog commit becomes visible in the normal log view. You can see the commit's file contents without having to check it out, you can diff two reflog or normal commits, etc.


Rebasing breaks a lot of what's good in git.

I agree on these points, however many developers don't care enough to use it well, so you get screwed up shared histories, bad commits, mis-merged branches. I know that the nature of a shared tool, but it definitely negates a lot of the potential benefits of doing everything The Right Way if nobody else puts in the same effort.

How about putting some tought into not naming operations so that `pull` is not the opposite of `push`.

Don't you think the merge histories of all the repos throughout the globe would be greatly improved if people didn't need to learn the hard way that if your colleague does `push` you need to `fetch`?

Also, rm is not the opposite of add, `restore` is (and previously `checkout` was).

> Once you wrap your mind around what commits, heads and remotes are and learn to rebase you get an incredibly simple and fine-grained control.

> Git is like a chef's knife: extremely powerful tool that's dangerous in untrained hands.

Although, this is all part of the problem with Git. The problem is that it exposes this fine-grained control and knife's edge to the user by default. There isn't some simpler model that people can work with.

I cut my teeth on source-code control with Perforce. Of course, Perforce has many complex features, including stuff like workspaces, which as far as I can tell, Git doesn't have something like that. Anyway, despite its complex feature set, Perforce can be explained in a few minutes. You have some code in the repository. If you want to work on it, you check it out and it gets added to a changelist. If you want exclusive change rights, you can lock it to prevent others. If you want others to see what you're working on, you can shelve your changes without submitting so that they can inspect. When you're done, you submit your changelist. All of this can be done via excellent visual tooling or the command line. I highlighted things with italics because these are the right words for the actions in how Perforce calls them. It's intuitive.

For Git, it isn't that simple. You must first explain a wide swath of concepts. I've explained Git to people, even using the GitHub Desktop app. It is very confusing and intimidating to people, and rightfully so. It confuses me, and I did some pretty advanced things with Perforce (and thus source-code control) before. And there's no default visual tooling. Git also has many names for things that are confusing. Also, Git was invented for a very specific purpose: Linux kernel development. The vast majority of development does not need the same complexity that such a niche development process needs.

When I recently wanted to do something in Git, I just could not figure it out. Probably simple for a Git expert, which is something I am not, but after searching many forum posts, I gave up because every answer was different and caveated in different ways and wasn't working for me. I installed GitKraken and solved my problem in seconds via a single right-click. Maybe I'm an idiot and I don't understand Git that well; both are likely true. But I am able to understand other complex things, so something is amiss. I think the primary issue is that Git requires me to study it just to use it in basic ways. I have an allergy to overly complex things, and so it's just a constant struggle for me. I tend to use visual tools for merging, diffing, managing commits, etc. so that I stay away from the Git CLI, which exposes the complexity in a non-usable way.

Lastly, Git is very narrow minded when it comes to things it controls. It assumes everything should be text.

Absolutely agree! Coming from P4 to Git, Git is just constantly getting in the way.

I need to make more decisions because of its limitations (single repo or one repo per module? Or maybe use submodules somehow? With P4, we had a single repo with all of the code of the entire organization).

Should I rebase or merge? Or squash commits? Should I cherry pick onto a new branch?

If I want to checkout a new branch while I have work in progress, do I commit it and later amend or revert, or do I stash it? Or do I rely on autostash?

Do I push directly to main, or do I rely on pull requests? Should those merge or squash commits?

I understand that all of these options and concepts make sense for distributed orgs, like the Linux kernel dev community and many other opensource projects. But I don't understand why so many traditional organizations are adopting Git. Its model is way too complex for the way normal orgs work (1 centralized server as the source of truth for the whole project), and it has serious limitations for anything which isn't pure code and isn't carefully curated.

>Should I rebase or merge? Or squash commits? Should I cherry pick onto a new branch?

From my perspective, these are policy decisions that need to be made by some "management-ish" level. Git provides the mechanism to do all of them. It's up to you/your organization to decide how to work.

In the open source project that I run (20 years, 75+ developers over time, 400-500k LOC) we all have a clear understanding of (e.g.) whether to merge or rebase. On the odd occasions that there's a lack of clarity, it's normally a great sign that it doesn't matter.

The fact the you would be asking those questions suggests to me that the necessary policy-level decisions have not been made (or have not been made clear).

I'm not saying this is a decision every dev has to make. I am complaining about having to make these decisions as a team or team lead. Having choices is only nice if there are important use cases where each choice is useful, and if the difference is big enough. Otherwise, the choices are just adding complexity and buyer's remorse.

For most unitary organizations, some of the options that git gives you make no sense at all. That doesn't mean git should change, it means that it's not a great tool for unitary organizations.

Note that some of the choices (e.g. stash vs commit) are choices that each dev has to make individually, and some are pure incidental complexity.

So git gives you too much freedom, that’s what your complain is about? I find it hilarious.

This is not 'freedom' it is excessive complexity.

`ls` wouldn't be better if I had to pass a flag to see the output as today, and another flag to print one character per line, and another flag to print each character in a different color etc. (even though that would give me 'more freedom').

I don’t think that git forces you to use all these bells and whistles. Also I am not sure if ls would be better with additional flags, but it won’t be worse because of that, that’s for sure.

There is a difference between "too much freedom" and "not enough direction."

Sure there is - the difference is so huge that I don’t see any similarities. Though professional software should not direct you, thus limiting you in choices. Your expertise should do that. And if your expertise is not enough to make an educated choice it’s not a problem of the software.

Those are hard decisions to make in organically developed organizations like companies.

Part of the problem is that Git, to make it manageable, requires all of these types of concerns and decisions to be addressed, and secondly, it has somehow become the only standard that people have even heard of. There isn't even a decision about which system to use anymore.

Having used both, I still prefer Perforce over Git. And if it were up to me, I would take a step back and investigate other offerings like Plastic SCM. But trying to make these decisions is nearly impossible now that Git is treated as a given.

I seriously disagree. Branching models are one of the few things that can be decided upon at short notice. It shouldn't be changed every day, but going from merge commits to rebasing is not going to prevent anyone from working. The VCS history will just look confusing temporarily.

Coming from p4 to git, I thanked the heavens for not having to use this piece of garbage anymore! File locks? Multiple changelists? God forbid that one colleague who checked out some file went on vacation, neverending fun talking to admins of the server to do something about that! Rebasing commits? Own branches? Own repos? Nope!

I miss multiple changelists so much! I very often am working on a longer feature when I also get some small bug, and it's so nice to organize that into a separate changelist.

Also, file locks are awesome if you're working with binary files (a thing that P4, unlike Git, can actually do), or even when doing a big refactoring that you know will cause conflicts with any other change. Otherwise, at least on our server, we very rarely used them (ignoring the temporary lock just as you're submitting code).

I'm not sure what you mean about rebasing. The basic P4 workflow is equivalent to `git pull --rebase`. In fact, it's pretty hard NOT to rebase in P4.

Also, why is your own branch useful actually? Nevermind your own repo? You can always just keep multiple copies of the code if you really want to.

Also, with P4 you don't have to cleanup your whole working set just to switch branch - it's just a `cd` away!

Of course, different strokes for different folks and all that.

I feel like I'm back in the aughties reading this post :-) These arguments were all made back in the day, substituting in CVS or Subversion or what have you for Perforce. And yet time marched on and millions of people found that, yes, they could indeed use git. Especially with all the UIs that have sprung up around it. That's the thing really–you don't need to be an expert git CLI user to get value from git. You just need to find one or more UIs that do what you need.

Agree. I always hated git and thought it was so arbitrary and unhelpful. Then I sat down for 1-2 hours and read about how it works. It's not that complicated of a model that it operates on. Once you learn the model, the rest of the commands and how it works start making intuitive sense.

I’ve yet to find a good intro doc that explains how git works conceptually. There are too few visual examples with authors assuming that users already understand the basic concepts like commits. To people who are completely new to version control, git can appear nonsensical.

Funnily enough I think Atlassian/Bitbucket comes close to a good intro doc to git on their site complete with a visual guide. I still found it inaccessible to people totally new to the basic concepts though.

I've found the git branching game to be quite helpful in building a visual mental model https://learngitbranching.js.org/

No, this one is good (I'd say I regard it as canonical!), but only if you know how commit works on a conceptual level. It is not targeted at absolute beginners.

I found this one to be pretty good:


Agree with everything in this post except I find stash extremely useful when a pull would disrupt my current working directory. "If I only had a VCS to temporarily hang on to my local changes while I merge the team's."

Stash, pull, stash pop. Done.

(I don't use rebase because I like my history to tell the truth rather than be fictional. Maybe stash is less necessary with rebase; IDK.)

You don't need stash for that though, you can just create a branch.

git branch my_stash git commit -am WIP # instead of stash save git pull git cherry-pick -n WIP git branch -D my_stash

You don’t need to create a branch for that though, you can just use stash.

And how is that better?

You have to remember a second command with its own peculiar syntax and semantics, but don't gain any functionality.

Stash is a superfluous misfeature.

99% of the time when I use stash, it’s ”stash” or ”stash pop”, usually with ten seconds or so between the two. It’s very easy to remember.

Your alternative, on the other hand, uses an obscure flag to cherry-pick. What scenario would you use that flag for, except this particular one? How is remembering that flag any simpler?

Also, I don’t think your sequence of commands is correct. First, ”git branch” doesn’t switch to the newly created branch, so ”WIP” would be committed on your original branch. Second, the argument to cherry-pick should be a reference to the commit rather than the commit message. I believe a correct version would be:

  git switch -c my_stash
  git commit -am WIP
  git switch -
  git pull
  git cherry-pick -n my_stash
  git branch -D my_stash

You are right of course, that my commands weren't correct. Yours are, I'm pretty sure, but I think the following way is better anyway: What I actually do when I want to pull and reapply my local changes is simply `git commit -am WIP && git pull --rebase`. That's it.

I'm don't know now, why I suggested the convoluted temporary branch strategy. Probably because I assumed the GP didn't want the WIP commit, but I guess you could just get rid of it with `git reset HEAD^`. Personally I think WIP commits are way better than having uncommitted changes lying around, and what better time to create one than when you're at the terminal pulling and rebasing anyway? Anyhow.

Now when the rebase fails I can just abort it and be in a very easy to understand state: I have a tracking branch that has diverged from the remote, as `git status` would put it. I find this much better than "my tracking branch says 'up-to-date' but only because my actual changes are in a temporary branch somewhere, or heaven forbid, a stash."

> obscure flag to cherry-pick

Sorry, I'm having a little trouble with this one. What flags aren't obscure then? It's one of the elite 0.01% or so of git command-line options deemed worthy of a short option, so I think it stands to reason that it's rather frequently used.

Personally I used it a lot when I first started using git, before I got the hang of amending and squashing. Almost exactly the same way as I used to use stash, before I realized it was adding negative value. :)

Have you never been in the situation where you pop your stash, have a conflict, fix and commit it and then forget to drop the stash? (pop only drops it automatically if there were no conflicts.)

What if you want to save resolving the conflict for later? Do you just leave it in your stash to have to dig for later (amongst all the redundant leftovers from the preceding paragraph)? Or do you remember to run `git stash branch` at this point, and hopefully don't get interrupted before you can do so? Better, IMO, to just use branches in the first place, instead of this weird out-of-band thing where things are kind of like commits, but not really, and live in a separate place I have to remember to check.

Sorry about the length.

Behind the scenes, stashes _are_ branches! It's just UI on top of them, optimized for specific use case. You don't have to use it if you don't like it.

Now staging (aka index) is special behind the scenes, making the model more complex for Al users.

For me personally I find git to be relatively painless (after years of svn and P4). But working with people in less technical roles (PM/UX) who for whatever reason need to touch git occasion, I’m exposed to how inaccessible it is for the uninitiated. Not saying that’s a good reason to change the tool but maybe there’s room in the market for a more accessible tool.

I couldn't agree more. The fundamental design it's absolutely brilliant. The UI does take some getting used to.

I frequently use Git as an interview question, but only when the candidate lists Git among the skill set. Specifically, I ask how does Git figure out when you've renamed a file. If you don't grok it, don't list it.

Almost everyone would agree that listing 'git' as a skill implies knowing the operation of using git, not the specifics of how it works under the hood...

Why ask such a gotcha question?

I don't think there's anything 'gotcha' about the question. If you understand that git uses SHA1 for the objects it stores, the answer is pretty obvious. If you don't, you really don't know git.

I would say that listing anything as a skill implies knowing of how it works under the hood, until stated otherwise. It’s a resume, not a list of random TIL facts.

> how does Git figure out when you've renamed a file. If you don't grok it, don't list it.

How does git figure it out?

Percent similarity on display, not on commit.

That second part is actually important from the user's perspective, not as details on the internals: every single new hire we've gotten who is still learning version control expects svn to detect automatically, and has to be told about "svn mv".

The ui doesn’t take any getting used to if you don’t use it ;)

That is so true. A lot of people use git as write only repository. Still better than nothing, or copying directories. Maybe at some point they'll figure out how to retrieve a previous version.

You are so right about Atlassian tools. I cannot stand Jira. Very often, it's easier and faster to fix a bug, then to update the status in Jira. It's clutterware.

Every few weeks someone at work will ask about some basic functionality missing from Jira and we just link this as an explanation: https://jira.atlassian.com/browse/JRA-9091

That's amazing. Soon there will be people using JIRA, waiting for a feature that was requested before they were born.

This comment thread is so funny to me because Jira is actually the least unpleasant of all the enterprise software I'm forced to use at my job (lots of Microsoft stuff) so by comparison it's actually fine.

When we were forced to start use Jira a year ago it was kinda maybe acceptable, but every week someone in the organization adds a new custom field to issues, so it's growing scarier than bugzilla...

Back when I used Jira I actually quite liked it. Not that it was the best thing out there, but honestly with a little bit of config we could set up our (mandated by law) process quite easily and follow it.

Speed isn't the best, but it was either that, use Redmine with a massive config or wrap the shop up.

Why is JIRA so slow?

My understanding is that JIRA was originally built as an on-premises solution, so request latency wasn't an issue.

Then they moved everything to a cloud hosted solution, but the assumption of requests being effectively zero latency was still built-in, so now firing hundreds of requests with high latency makes everything feel super sluggish.

I'm working on my own issue tracker [0] that stores everything locally, which means no network latency. Eventually I'd like to build a sync backend for it so you can share it with a team, but for now everything runs locally.

[0] https://twigtask.com/

Oh, that would explain why I had no problem with JIRA.

My company had paid for the locally hosted version of JIRA for security policy reasons.

We use an on prem Jira and it is still shit. Would not recommend at all.

Yeah, our on-prem Atlassian installation is utter crap performance wise, opening a Confluence page often takes 30 seconds or more. I also get pissed off every time we try to upgrade our SolidWorks installation because they share a DB server. Atlassian doesn't support the most recent versions of Microsoft SQL Server, but SolidWorks only supports the latest couple revisions of Microsoft SQL Server so every time it is a pain to ensure that both systems are compatible and my IT refuses to move SolidWorks to a new server.

I think the opposite, but yeah.

The cloud is the original code base and the on premise is a FORK! Can you believe it? It's not even the same code and the on premise solution is so far behind.

Because it's a SPA trying to make 200 requests to get a ticket...and I'm barely exaggerating.

JIRA is not doing the SPA cause any favours :P.

My rage builds even just trying to use the search bar on JIRA. Keys don't get captured and get registered as page hot keys, or some keys are registered and others aren't. Crazy, just give me a dumb static search bar if you're not going to make life better. /Rant

JIRA was not always an SPA and it was still slow back when it was multi page.

> AWS. ... apparently you need a chrome extension which adds a bunch of complicated options I don’t really understand just to be able to change roles

I strongly agree with the rest of your characterization of the AWS console, but that one isn't true: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_us... -- we use IAM Roles extensively at $DAYJOB and have not yet experienced anything that would require a Chrome extension to work around like you describe

Their login screen, however, continues to drive everyone crazy since the URL you visit depends greatly on which account, and at what level, you wish to authenticate to the console. With any setup containing a non-trivial number of AWS accounts, it's just "oh, what account am I logged into" waiting to happen

The AWS web UI shows an MRU (most recently used) list of the last 5 roles only. So if my job calls for me to switch between multiple accounts (7 accounts in my case), and I can't have all 7 in my history. There is a Chrome extension that extends that MRU list. See https://chrome.google.com/webstore/detail/aws-extend-switch-...

I would disagree regarding AWS IAM roles. You can't live without "AWS Extended Switch Roles"[1] if you have more of them. What AWS provides by default is quite a joke.

[1] https://github.com/tilfin/aws-extend-switch-roles

Switching roles breaks any existing tabs/windows using the previous role.

To avoid this I use Firefox container tabs, creating a container for each role. Which will get around the UI's 7 role limit too.

My personal issue right now is that I have multiple accounts with MFA and there’s no easy way to differentiate them besides this generated account ID in the auth app. This means I have to create some type of mapping table between the ID and the account, or try to remember what’s available

We have a very funny situation in our org, where AWS auth is setup using our MS domain, with app push-based MFA. However, the AWS MFA workflow seems to not know about push based notifications, so it asks for a verification code which can literally be anything. After you provide some code and click Verify, only then does it send the push notification, and the UI just freezes until you either accept the auth request or some timeout happens.

Not to mention, we actually have to provide the Domain password in the AWS UI, which seems to go against any kind of security I know...

If you already have an MS domain you could set up SAML login with ADFS (tried this, works fairly well) or AWS SSO if you have a managed AD in AWS (may not be available in your region). Also works very well with AzureAD as the provider, if you use that synced to your on-prem AD.

Every MFA app I've used has the ability to rename the entry, since the MFA key and the text that are displayed to the user are 100% unrelated to one another. And I recognize that you might not have the correct privilege level to carry it out, but AWS does allow you to create account aliases, which helpfully shows up in the console login URL

Exactly what I was about to say. For reference account aliases are documented at: https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-...

Fully agree on Jira. Disliked it enough to start a company to compete with it [0].

Also agree on AWS. Their UI is so terrible and confusing that it makes writing CloudFormation yaml files feel alright in comparison. Been using GCP lately and the UI is somewhat better though still confusing and weird at times.

0: https://kitemaker.co

Looks nice! An suggestion: you might want to consider renaming "theme" to "topic" (or "epic").

Also, what about sprints? As of now, kitemaker is solely usable for Kanban, right?

Just as a quick feedback, your main hero gif is a bit too low res.

This, so much this. The main hero image is a tad pixelated to me and while not a huge deal, could be cutting into conversions.

GP, to simplify the main hero consider making it a png. I know as a user seeing a slightly pixelated gif screams out “unpolished” engineering and design.

Every gif on the web should be a video. It would weigh less and still be supported by all browsers.

Thanks! We'll look into swapping this out with something that looks better. We've admittedly spent quite a bit more time on the product than the landing page ;-) We're going to keep polishing it up though!

Neat. You made Trello.

While maybe not the nicest way to phrase it (and I think you know that), I'll take the bait and tell you how I think we differ from Trello:

- Crazy amounts of hotkeys. You can do everything in Kitemaker without using the mouse. It feels pretty awesome to move issues around the board, assign them, etc. all with hotkeys. Also like many modern products we have a command center (ctrl+K or cmd+K) where you can do everything.

- Our issue screen is quite a lot more powerful than Trello's card view. We've talked to many teams who use Trello and they rarely have much content in their cards. In our issue screen, you get a rich document part (feels quite like Notion, with a lot of things you can drop into the issue like images, Figma designs, etc.) and an activity part (with threaded comments, a history of what's happened with the issues, updates on relevant information from integrations, etc.)

- Better GitHub integration. Our issues actually have issue numbers, so you can do things like "Fix ABC-123" in your GitHub commits and our automation feature will move the issue around the board accordingly (you can set up different rules for if such a message appears in a PR, a commit in master...er main, etc.). We show any activity in GitHub related to the issue right in the issue's activity feed as well.

- Better slack integration. Mentioning issues in Slack automatically attaches the conversation to the issue and also provides useful info about the issue in Slack

- List view. You can see issues in a list instead of a board if that's your thing. Nice for use cases like backlog grooming.

And we're moving fast and adding more useful stuff all the time without becoming too complex or unpleasant to use.

So yes, we have a pretty board and pretty boards tend to look like Trello. But there's a lot more to it than that.

That app looks considerably more powerful that trello. Why so dismissive?

Well, it is neat and it does look like Trello. And Trello is now part of Atlassian.

If you haven't noticed the chorus of trashing Jira for the sake trashing Jira in this forum you aren't reading it. It borders on the hysterical. A large part of this crowd believes they have an objective handle on cognitive bias yet most of the Jira commentary seems to come from the subjective experiences of developers who simply don't like having their work organized or fixing bugs. Jira is the most extensible, best platform of its type for workflow management & I would argue (without at all being linked to Atlassian in any way other way than having seen it succeed in numerous disparate use cases) that bad experiences with it are the direct result of not having any idea how to use or configure it correctly to model the work being done.

That's all well and good, but being a foot soldier engineer in a big company, I don't have any influence in either how it is configured or how the work is being modeled. I just know that the page loads took multiple seconds and converted a sub-minute task of updating status or checking information into a multiple minute task.

I tend to track my personal workload in a text file at a more granular level. When my team's project was approaching a deadline and a crunch and I needed to stay synchronized with the developers working closely with me, I transcribed this list to Trello. I showed it to the PM as a curiosity and the next day all of the cards had been printed out and affixed to the wall with masking tape. That's the type of environment a lot of us are working in.

The problem with JIRA is the culture that it encodes and enables. It's rooted in the belief that programmers are factory line workers who aren't smart or organised enough to keep track of their own work, so invariably control of it gets assigned to a "project manager" who then spends far, far too much time engaged in busywork. You end up with hard-coded workflows that don't match how people actually work and the people who need to actually use the workflow get frustrated.

Fundamentally JIRA is an over-grown bug tracker. A bug tracker should be designed, built, administered and used by programmers and only programmers. Project managers should not even have access to it, in my view, let alone try to use it to create reports or control the team.

Typical problem I face in my JIRA shop: there'll be no way to move a task straight from "to do" to "done". You have to move it to "in progress" then "in review" then "in qa" then "done", even if in fact, the ticket just tracked the need to do a quick code cleanup that happened to get done as part of some other task. There's no justification for this type of thing beyond over-empowered project managers.

You believe that Jira has "encoded" that culture in your company, not that your company has encoded it's crappy culture in your Jira implementation? Please see: https://en.wikipedia.org/wiki/Conway's_law

Yes, "encoded and enabled".

I saw how that culture evolved over time as the company got bigger. It didn't start out that way. JIRA was once a bug tracker for us. It became a some sort of flowchart madhouse with horrifically convoluted processes around it. Partly yes, because the company felt a need to hire project managers, and partly because the tool existed and therefore there was something for them to fiddle with all day. If they didn't have the tools to create over-engineered processes, it would be less likely to occur.

At some level, yes, JIRA just enables problems, it doesn't directly create them. On another level, its whole structure encourages that way of thinking.

The main criticism I have been seeing is its performance, not that people don't like how it's being used.

Part of the reason people complain about jira is because their own company has tweaked it so much it became slower than a turtle and is riddled with all those random fields their upper management requires to make some meaningless reports.

>>A large part of this crowd believes they have an objective handle on cognitive bias yet most of the

Yet you claim because YOU've seen it work, everyone else must be wrong?? ironic ?

Jira Server is really hindered by the centralization of its workflow management administration tools. You cannot have "workflow admins" that can change issue type schemes and stuff like that for a subset of projects without giving them full admin rights.

Imagine having a guy in Dev that can fix your workflow so that "Start working" is not hidden in the dropdown menu.

I don't have to imagine it. This is a textbook example of a Jira implementation failure not a Jira failure: "not having any idea how to use or configure it correctly to model the work being done."

Personally I am quite familiar with configuring JIRA - and I agree it is very customisable... but, as many have said - it is far too slow.

i am completely fascinated by this response. it is literally so dense with self-parody and hacker-news-ness that any attempt to quote it, analyze, refute, or satirize it in any way would only dilute the message.

If you are talking about my response, I would really love it if you would try to do any of the things you've implied.

Jira is a good product, and developers don't like it because it is designed to keep them honest. What is complicated about that?

I think if you need a tool to "keep them honest" you may have a major culture problem in your company. We started our company to make a tool where people collaborate to get stuff done together, not to be a place where managers keep tabs on their people.

That being said, despite that I personally don't love Jira I do think there are some cases where you need particularly complex workflows (e.g. compliance use cases) where Jira's complexity is fully justified.

And we know our tool is not for everyone. If your team is happy using Jira, power to you. But I think it really is important that the team is happy with it, not just the bosses.

> I think if you need a tool to "keep them honest" you may have a major culture problem in your company.

What kind of organization doesn't have real OKR's or performance metrics? Do you draw a pretty picture with sunshine and rainbows and report that to investors?

You said developers don't like Jira because it's there to "keep them honest". I don't think micro managing your people via an issue tracker leads to better performance on OKRs.

I report actually meaningful numbers to my investors in terms of value delivered to users, not number of tickets churned through.

> feels and looks like someone made it in a rush with jQuery and Bootstrap years ago.

Unnecessary dig at Bootstrap and jQuery.

There are plenty of websites with great UI built using bootstrap. I don't understand how using jQuery has anything to do with the UI though. It's just a wrapper around JavaScript.

It's just using name brands for describing legacy-jank-by-noobs - not really a dig at those specific tools

Fully this and I think they knew this as well but couldn’t resist pretending to be offended. There’s always one.

Ok boomer

Jira is such a pain to work with. For example, there seem to be two different ways to create a new issue. If you get to the one that uses a modal, the text input is in Textile format. Whereas the other page uses Markdown. It's insane that anyone thought that was a good idea

They’re apparently trying to switch from using something like confluence markup to using the markdown that just about everyone expects now... https://support.atlassian.com/jira-core-cloud/docs/markdown-...

But like everything Jira, they can never seem to find the energy to redo everything all at once, so they do it one screen or one section at a time instead... reminds me of how Office apps never improve all at the same time, just a bit at a time... in one app... if you’re running the Cloud version...

It's what passes for Agile these days, ie. push half-cooked changes upon your users.

Is that what it is? I thought it was our own misconfiguration because it’s so hard to configure screens / easy to misconfigure them.

I think so, I haven't seen a way to configure it and it seems to happen by default in new projects

> I recently started using Gitkraken which allows you to pull changes WITHOUT needing to commit locally first because it uses stashes. It basically does the same option. Why can’t git be smart like that?

This is not being smart, this is trying to be too clever for one's own good. Git does what it does because it wants you to know what might happen and to decide explicitly.

If I do a 'git pull' without remembering that I was doing something and that just goes through and stash my changes automatically then I have lost the exact state I was working in and I need to work to recover it. Now, on the other hand if git stops and tell me that I have changes pending then I can think and decide. It only takes a few seconds.

Trying to automate too much can be a false economy.

Ok I agree that yes you might be worried about current state but generally that’s not something I ever experience whether that’s a solo repo or a team repo. Making some basically fake WIP commit just to keep in sync with the changes is ridiculous to me.

Hmm, I think (Atlassian) Confluence is quite awesome. While you can still replicate the mess you'd naturally have in Google-Docs or OneNote or other places, at least with Confluence if you have a coherent vision for how your organize your information you can create a very useful body of work. I've never seen a Google-Docs, OneNote, SharePoint, or other unstructured-info solution that doesn't devolve into turds-in-gelatin.

I'll add as well (Atlassian) SourceTree (git UI). I don't want to be a git jockey and I can do 90% of what I need in the SourceTree UI -- it's saved me tons of time, and I especially like the chunk-stage/unstage/reset functionality (you can stage/unstage/undo fragments of files in the UI) -- this feature alone is gold. SourceTree performance has improved greatly. I only wish there were a Linux version, but fortunately I do most development on macOS.

EDIT: SourceTree

The bar for Confluence isn't Google Docs or OneNote. It's Notion or Coda. After using Notion I can't go back to Confluence, for the same reason I can't go back to any Atlassian product - it's way too slow and the UX is too convoluted.

Two things bother me about Notion as a documentation platform: no “plain” tables, and the potential for infinite unnecessary complexity with its databases.

I love notion, but as a company-scale doc platform I don’t think it’s there yet.

No matter what I’ve tried, nothing beats google docs for me (in a mixed discipline work environment). It has the familiarity of a folder structure, good collaboration features and version history that works well for non technical users. It works well enough that few users fall back on v2_final-edit naming nonsense. Other tools have a slight edge for organizing information, but no good way to keep both files and Documents together. Which means people use files locally and don’t keep them up to date on the system.

It had 3 pain points for me that are resolved recently. First, they got rid of the desktop clients so users can’t move stuff to their desktop without understanding this is removing files for others. Second, team drives resolve the mess that was shared folders. Third, it can now edit office documents directly, avoiding the confusion of google doc copies appearing.

I use confluence a lot and I never trust that files on it are up to date. It doesn’t quite have enough features to make “native” documents, so it ends up with a lot of content stored as attachments, which inevitably get updated and passed around by email. It’s not convenient for storing files so all of the miscellaneous small files never make it there. If you use a lot of addins, it becomes usable to make documents but since it’s atrocious at outputting files, eventually a final version of something needs to be edited in word and now it’s even worse, you have what looks like an up to date document but the latest version is a word file, which is either hidden as an attachment or not even uploaded. I can see it working well in a team of only software engineers, however.

> (you can stage/unstage/undo fragments of files in the UI)

To be fair, this has nothing to do with SourceTree. You can do this with any git tool, since it’s a feature of git.

I started using Clubhouse (https://clubhouse.io) for my personal projects and like it a lot for a light-weight alternative to Jira, yet more powerful than Trello. Not sure how it scales for big teams though.

We use it at work. Many teams of 5-8 people. We love it.

Clubhouse is great for large teams, but every project manager who starts will spend their first month bitching that it isn’t Jira.

Thanks, we started using Clubhouse about 7 months ago and have very few complaints. The main thing being it doesn’t have multi-second Lang after creating new issues.

Clubhouse is the first Jira replacement we’ve tried that the devs actually like using. Doesn’t have the laundry list of features Jira has, but meets our needs (team of 20).

I first read Atlassian and could potentially get on board (they have made tons of QoL changes, which I love and actually like. Their API still isn't that great, though). And same with AWS. At first it's confusing for sure. A lot of their offerings are wrappers around OSS that is much more intuitive. But comparatively to Azure and GCF, they're all confusing at first.

But then I read git, Docker, and Linux. Now I'm concerned about your approach to any of these tools.

For example Linux. There is _a lot_ of documentation out there. Man pages and arch Linux wiki just to name two that have a massive knowledge base.

Git. I mean holy smokes, I'm going to assume you've never used any other VCS because everything else before it was hell on earth (in my opinion, people have things to say about this). I would focus on learning some git commands and I think you'll really like it. Going straight into a GUI you might be confused when you have to fix a problem via CLI when GUI messes it up.

Docker - yeah, I see your point. It's not as apparent when you're trying to pull different architecture images. Kind of a shame. Maybe Rust WASM/WASI will replace it one day (kind of joking here).

I love git, but the command-line interface feels like it was grown over some time (which it was). It's just very ad-hoc in what commands are used to accomplish something.

The underlying architecture of git is awesome, but even if I know exactly what I want to do based on my understanding on the architecture, it's not obvious which command and which switches to use to achieve this. And I use the command-line all day, and I am good at remembering switches.

But still, for git I've written myself a list on what combinations to what, and when I need to do something more exotic, I look it up in that list. A more consistent CLI would allow me to do what I want without lookup.

This is exactly what I meant, but I guess people were more interested in ad-hominem attacks because I questioned their favourite tools. I also have a list of magic combinations that I know do the thing I need. But I don’t really use them now because I use a GUI.

I’ve used a few source control solutions and Git objectively has the worst syntax. At least the various GUIs help prevent you shooting yourself in the foot.

As for Linux my point still stands. I don’t use Arch Linux because I don’t want to waste time compiling everything all the time. The documentation is still poor.

Jira with a dozen plugins is a death sentence for productivity. Oh Atlassian finally fixed that bug you reported a decade ago? It might have to wait a few months because none of your plugins are compatible with the new Jira release.

> AWS... It is literally years behind Azure.

I’m going to have to disagree with you here, AWS has some quirks, but the UI is being actively worked on and improved but Azure is an outright dumpster fire.

Who thought scrolling sideways was a great idea? Why does the x close _everything_ and take you back to the dashboard and not just close the current pane?

Why is everything about permissions and auth so hard to find?

> Why does the x close _everything_ and take you back to the dashboard and not just close the current pane?

Well, at least if it did that /consistently/ it would be an improved. It sometimes just closes the current pane as expected.

More generally speaking, to me Azure feels very jarring. There are panes that are logically pretty much the same but have wildly different behaviours (I'm thinking of AzureAD 'subpanes', some of which take over and there's no way of going back to the main AzureAD pane even by scrolling).

There's also the issue of the interface not being updated after changes and of having to switch panes for the change to be effective or even to reload (reboot?) the whole page (I'm thinking of setting up auto-provisioning in AzureAD apps).

Who likes Azure interface? It's Windows 95 on the web. Unless you know how to navigate having remembered all the maze structure with years of operation, I can't for the sake find what costed what in the last month.

UI is a total joke. It's like a machine built it literally just listing everything instead of by a human mind.

It's not just the UI either, have you seen the REST API for Azure Blob Storage? It's Kafkaesque.

And Cosmos DB? 'Request Units'? W. T. F.

Oh god their units!

Provisioning disks comes with the caveat that on AKS, Kubernetes sees things one way, but Azure bills you in some bizarre, Azure specific unit of disk space and speed and then there’s whatever the hell goes on with the pricing / units on the SQL Server instances...

Ah, you'd be talking about DTUs! Those are fun. Blended measures of CPU, IO and some other Magic(TM) factor. Impossible to predict how your workload maps to DTUs until you try it and see.

Enterprise software are like baby outfits you get as baby shower gifts.

They are cute, but they have lots of buttons or they have some decoration that makes them hard to wash, making them impractical to use. While no parent would buy these, every parent has them, because someone else made the decision to buy them.

Yes! And also the experience of a recent baby shower.

Confluence is trash. It's slow, buggy, has a terrible UI which is always being messed with (or in Atlassian speak: "improved") and is constantly finding new ways to be unhelpful. Example: if you're trying open a template you don't have access to there's no way of requesting access to it. Confluence instead tells you to ask the person who created it to grant you access. Who?

Totally agree with Atlassian/AWS. Two senior devs should not have to pour over dozens of pages of documentation to figure out how to add a role to a user using SAML.

Git and Linux are great though. Git is well understood and, if you don't do bad things in the first place, easy to use. It's explicit. Linux itself works great and is straightforward.

Docker is hit or miss for me.

I feel your pain on the AWS SAML config. Actually anything with Cognito is this way too, circular documentation links that never actually lead you to your destination. It's like being in a labyrinth.

It's fair to call out Atlassian & Jira here. But I want to give them some credit. They recently rolled out a Jira change that was a huge step in the right direction (navbar at the top that can take you directly to projects and commonly used filters, among other things). It is a HUGE improvement. So it seems they may have finally figured out how to listen and improve UX. This is no small task for software that's used by so many different orgs for as many different purposes.

But really what holds it back still is sluggishness. I'd take a few extra clicks in exchange for instantaneous responses to each click.

Interesting perspective about AWS. I like it. It is boring and functional. It’s not pretty but it doesn’t need to be.

If anything I wish they would just change it even less than they do.

It does have its buggy areas though, which could be a lot better.

Another thought, I think I like it for the same reasons many here like Windows 2000...

Docker most definitely has ARM and multi-architecture support. That is, assuming the particular image you are attempting to pull has been published using the Manifest V2 spec and has ARM images published. The issue you mention is an issue with the image publisher/maintainer not Docker itself.

I maintain a number of Docker images that have multiarch support (as seen in the Tags view on DockerHub:

https://hub.docker.com/r/jmb12686/socat/ https://hub.docker.com/r/jmb12686/unifi https://hub.docker.com/r/jmb12686/elasticsearch/ https://hub.docker.com/r/jmb12686/kibana/ https://hub.docker.com/r/jmb12686/filebeat/ https://hub.docker.com/r/jmb12686/cadvisor/

Yeah you are right but I find so many images that aren’t published correctly

My company wanted me and the rest of the marketing team on Jira. Immediately I was like wtf is this. We were back on Trello after just a few weeks.

Yeah don’t let that happen. Same thing was tried with me a few years ago and I noped out quickly.

Notion is great for marketing teams though.

I cannot get with Notion. It is a jack of all trades master of none. It dives me crazy just trying to organize things and link it all together, it is more work than it is worth at this time. Maybe the API will change that.

If it’s for marketing and you need a hand setting it up, shoot me an email through my profile and I’d be happy to share an overview of setups I’ve used.

It took me a bit for it to click also, but now that it has I can’t imagine using any other tool for our marketing team.

I love it. A list where I disagree on everything you listed up. Then again, I understand where you're coming from, I simply don't agree.

What’s wrong with Confluence? We have a recently-acquired team at work that uses it for everything, and loves it. I’ve used it a bit, and I think it looks awesome, and the pricing is super reasonable.

Confluence looks better than everything else I’ve tried/used as a doc platform: Notion, Nuclino, Coda, Sharepoint, OneNote, Azure DevOps wiki, Microsoft Teams wiki...

My experience with confluence is that it just becomes a landfill of articles that are never read or cared about after 1-2 days they're created.

Confluence is where documentation goes to die. And then rot.

Any suggestions for platforms that help fight against that tendency?

Robust search.

Sorry - not the platform, but capability.

Where to begin? A better question is what's not wrong with Confluence?

When I log in, it shows me a shit ton of articles that I have no interest in. It's like a Facebook feed, or something, where every document everyone in my (1,000+ people) org has written in the last 24 hours is sorted reverse-chronologically. Since I only need to interface with about 10 people normally, this is worse than useless. It actually make finding stuff harder.

But never mind that, how do I find just what I've written? Somewhere there's a list of "recently worked on" things, and that's sometimes useful, but I usually need to edit something I haven't touched in months. I end up having to search all of our Confluence instead of just being able to search only my own articles. It often brings up completely unrelated things and I have to do more work to figure out which are relevant.

When editing, their editor steals OS keys that are used for every app, like Cmd-F for find. Instead of bringing up Safari's find panel, which is 100% always what I want, it brings up their own home-grown find that doesn't actually search the entire page. It only searches the text I'm editing and often does a poor job of it. Other command-keys are also highjacked meaning I can't do normal things like create a new window when editing text. It's bonkers bad.

The calendar section becomes unusable once you have more than about 3 people adding stuff to it. The list goes on and on. I'm actually shocked that anyone here is defending it.

Any suggests for better platforms?

It doesn't help that the Markdown flavour is not standard, and is different again from most other Atlassian products.

And you can only use it to compose and not edit.

Try finding stuff. In a large org, even with as much careful organisation and attempting to make things searchable, it just gets impossible. That doesn't mean Confluence is bad of course - it may just be a hard problem.

the one confluence thing that gets me is that when editing, it intercepts the command + 1 keypresses when im trying to switch tabs.

instead, it just makes my current line h1.

>>and slow

Enterprise Atlassian is so slow, I have to often click a link, and go do something else and come back. Sometimes I even forget why I even clicked on a Jira link, having lost the thought trail.

> AWS. It’s UI is honestly baffling

Haha I used to have the same thought before I joined. But I've since understood that AWS is a set of APIs which is the default interface and everything is able to be called programmatically - the UI only tracks the API. It's not the default mode of use nor is it meant to be.

Accurate. 95% of my AWS usage is over APIs / SDK now so I don't mind the UI so much.

Shameless chiming in about AWS: I am working on a alternative web console for AWS, https://daintree.app, to have a better UX.

It's still in its early days, so not many resources are supported, but I work over it every weekend. It has multi region support (so you can have a fast overview without changing page), fast role switching, it's completely client side (so you don't have to share your credentials with a third-party) and of course it's opensource: https://github.com/rpadovani/daintree

Glad to hear someone feels the same way about Git. I understand why some people love it, but I think it’s overly complex for most workflows.

Yeah, I've used a lot of different version control systems (RCS, CVS, SourceSafe, Perforce, svn, git), and by far the most confusing and infuriating is git with it's made-up words, bizarre naming, and the extra work it makes you do. Terrible to use. It does the thing it was designed to do, but good luck not screwing up because of its byzantine commands.

Fully agreed. My comment about how it doesn’t stash by default for example. Gitkraken seems to do the same default.

I can say many things about BitBucket but it isn't slow. In fact it's significantly more reactive than GitHub and GitLab in my experience.

Also your posts are hard to read if you systematically writes it's when you mean its.

Atlassian does not seem to have an interest in listening to their users. My workflow would be so much better if they implemented browser or desktop notifications, but they only support email or extensions/add-ons if you self-host. Our company uses cloud though, so despite all the countless threads asking for native functionality, they insist it is not important for users.

Like every business focused company that got large enough, they stopped making it for the users ages ago and now make it for the influencers in the middle management chain and above that decide on IT purchase decisions. And most of that is about putting CYA far above usability.

Atlassian does not seem to have an interest in listening to their users.

But they do. Their users are project managers. The genius of Atlassian is how they’ve managed to convince so many programmers that it’s for them. It never was!

At first I found it hard to use AWS because some services are a combination of other services and it was confusing but after dedicating time to learning what each service does then everything just clicked. Obviously the UX is still terrible for beginners because there’s a lot of assumptions but I found it to be pretty manageable after learning the fundamentals of AWS.

You aren't really supposed to be using the AWS Console... the whole point of AWS is automation, not bespoke one-off configuration via a GUI: when they launched it it didn't even have a UI, and the command line tooling was more of a demo set of wrappers for the API to help you debug calls and do some simple shell script automation.

And you think that's how the majority of the users use it? It needs decent UI. I'll never consider using Azure if the choice is on me because... crazy UI.

You can't mention UX in Atlasssian without mentioning bamboo. It's the pinnacle of random placed ui elements. It's faster to navigate by remembering URLs and typing in the browser address bar

> Atlassian [...] Git

Try TFS (especially TFSVC) for a few hours. At least Atlassian fails at attempts to write software for developers/engineers. TFS is written for managers: to hell with your productivity.

Anything Atlassian is often better than anything I have tried in a corporate environment, including MSFT pile of dog poo. It might be slow as a dead dog, ugly as hell, and cumbersome to configure, but it just somehow works. I still don't like it and rate it poorly every time the feedback box comes up, but you never know how good you have it until you have to use something worse.

As for Git, try to go back to SVN ....

I’m not by any means an advanced git user but find it to be well-designed and elegant. And, being constantly refined.

> Linux. It’s great, but it’s so easy to run into configuration problems or poor documentation.

Linux? Are you serious? You mean some app that you're using on top of Linux. Can't believe you dismiss one of the best open source project with a few baseless lines.

I can’t believe you dismissed my argument in a few baseless lines either.

I used to think I hated Jira until I had to use WorkFront. God awful.

We switched from Jira to Rally about a year ago. Our company just did a survey about which tool they'd rather use and Jira won by over 95%. We actually joked about having a party for using Jira.

Jira is a pain, but at least it's a known pain and a semi useful skill you can take with you when you leave that company.

If you have a mac, look into GitUp. It's a great git-client and it creates a timelined snapshot-backup after every action, so you can undo whatever you did.

I tried GitUp, but I found Fork (https://fork.dev/home) to be user friendly (IMHO, YMMV)

Haven't checked it out yet, but is that just git reflog with extra steps?

As for the AWS UI: I completely agree. I'm in the early access beta for a product being built that solves almost all of its problems and felt you might want to see it: https://vantage.sh/

Pretty sure they said they're launching in July so should be live soon.

Unless this is a Chrome extension to redress the existing console there is an approximately 0% chance that I'm handing keys over or giving some unknown entity cross account access for a better UX.

The git safety net against accidental resets is at https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278

Agree 100% with everything except for Linux and Git.


I don’t understand how someone can say “this is the worst software I use daily” and then you say “you are wrong.” Maybe you use worse software than them? Also, you seem to implicitly default to comparing each piece of software to others in it's class; you’re grading on a curve. The parent comment is saying “of all software, these are the worst”, and you are saying “but other PM/VC/OS software is worse” which is different.

For example, git is the best version control software; it is also a disaster of a UX.

Your appraisal of Docker is also too generous, I honestly can’t tell if it’s sarcasm

When you don’t know what to say, better say nothing or I don’t know.

Instead it proceeds to list the best software in class used by the developers. It just sounds stupid to me.

Regarding Docker, I have this opinion because Docker was the trend for a few years, at every conference there was a hipster making a presentation about docker. So I think Docker made containers the cool topic and a lot of people started using containers because of that. And because a lot of people used it, new services/software started appearing around it.

Yes, Docker uses the existing kernel apis for containerization, but the value it added was publicity, ease of use and adoption for containers, not the core features

What did I miss? It was deleted

Someone listed confluence, jira, linux, git, docker as the worst software he worked with

I could not disagree more with Atlassian. They are among the best software i have ever used. Especially bitbucket is superb. Confluence is by far the best wiki I have ever used. Jira is 10x better than any alternative I'm aware of.

Bitbucket is an acquisition that was decent before the takeover. Jira: How hard can we make it to manage bugs? Jama: How hard can we make it to navigate the document tree?

I think Confluence and Bitbucket work well enough. I hate Jira with a passion though.

That doesn't mean the tools are not terrible, which they undoubtedly are.

No, it does mean exactly this for me. For me they are not only undoubtedly great, but among the best software i have ever used.

But then again, I also love git. Maybe we have different ideas how software should and shouldn't be.

/edit: For clarity: Microsoft Office and SAP are how I think enterprise software should not be. And Atlassian is kind of the opposite.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact