git config pull.rebase true
    git config rebase.autoStash true

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.

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.

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.

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

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

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.

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

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

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.

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

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

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.

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

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.

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.

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

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

https://twitter.com/random_walker/status/1182635589604171776

Notion is great for marketing teams though.

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.

instead, it just makes my current line h1.

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!