sreevisakh

You should assume that developers, especially interns know nothing about any technology until they had a thorough introduction. And you should anticipate any confusion they may have in the process.

Once, I had to introduce most of the employees of a company to git and git hosting. They were trained from scratch to use git reasonably on the first day. Use of code hosts were taught only on the second day. They were taught hands-on on our internal host and on public server. None of them had any confusion over differences among git and different git hosts. While they did make some mistakes afterwards, none of those were based on total misconceptions.

Just to add a point here - lazygit (mentioned in the question), gitui etc all allow easy interactive partial staging that you suggest. It's great that these tools gives interactive staging the importance it deserves.

I prefer magit because it is well integrated into the editor itself, while mimicking the command line git as closely as possible. Magit allows me to use git from a GUI/TUI without the fear of forgetting the command line tool.

Meanwhile, there is another tool that deserves special mention for interactive staging - (neo)vim's fugitive. It treats the working copy and the index as two buffers and opens them in diff mode. You can compare the two versions directly as plain text, instead of as formatted diffs like in case of magit. Staging as simple as using diffput, diffget, etc.

> I think the underlying model is fantastic

The well-documented underlying model used to confuse me a lot - especially for operations like merging, rebasing (squash, reorder, ...), cherry picking, etc. They started to make sense only when I realized that git uses diffs/patches to propagate changes between unrelated commits. While the on-disk format is purely snapshot-based, the tool itself is a hybrid. As far as I can tell, this trips up a lot of others too.

> Some operations lend themselves well to a graphical interface, such as partial staging and interactive rebasing

I can't emphasize how pleasant those operations are in magit. I'm not sure if it (TUI) would be considered as textual or graphical. However, the interface model should lend well to a fully graphical implementation.

I'm someone who has started enjoying rebasing workflow after using branch-merge workflow for more than a decade. So perhaps, my experience may be useful since you can compare the same person using both of them. The first thing to realize is that branch-merge and rebase workflows try to achieve different goals. Branch-merge tries to preserve history of the code, with every wart and quirk included. Rebase tries to achieve a clean history where every commit is an entire fully functional (without known errors) feature with complete explanation in the commit message. People fight over them, but I find both goals to be meaningful and the choice depends on your priorities. In fact, I do both- publish a clean history in the master and the original messy history as a separate branch.

> I'd really like to know what mess people make when they don't rebase.

As a developer, we have the expectation that git will allow us to experiment with features, make mistakes, correct them, roll them back and improve. That stage is also so messy that you'd leave short commit messages that would make sense only to you. This is fine while developing. But this leaves many commits that are functionally broken, partial or rolled back later. That, along with vague commit messages and illogical commit order make it really hard for someone else to pick up a working commit from your branch and continue. Heck! I find it hard to choose a commit even from my own older repositories. That isn't the case with good projects like the kernel. You can pick any commit on the master and it will compile and work with all the features advertised up to that commit message. It makes a users' life easier.

> I've found that using merge gives a readable trail of when something was merged, whether that be from a branch's original branch, or if you're merging into another branch.

This is true. It's harder to achieve with rebasing. But it's possible with some work. I usually leave the original messy feature branch intact, and mark the rebased HEAD with a similar-worded tag or branch.

> Rebasing just seems to cause a lot more headache when something doesn't go perfectly correct in between commits.

Don't take any offense, but those are beginner blues. It happens in the early stage of learning rebases when you don't have a full grasp of what is going on. People evolve different strategies to overcome this once they are a bit more comfortable. My strategy is to create a temporary branch for rebasing (at the same commit as the feature branch) and do multiple rebases on it. I do only one or maximum two operations during each rebase. The result of each rebase is reviewed before doing the next round of rebase on the same branch. The original feature branch is left intact in case something goes wrong - though I never needed it.

Other people do rebasing occasionally while developing the branch. They do this after every two or three commits. They end up with a clean history to merge (fast-forward) to master, by the time they finish the branch. All of these operations can be simplified using helper tools like git-revise [1].

My absolute favourite method is to not use rebase at all. Craft the perfect commits as you develop. This can be achieved with a patch stack tool like quilt or stacked-git [2]. It allows you to move your changes to a patch (commit) of your choice. This is like having multiple staging indexes available. You can also split, combine or reorder patches. The patch stack evolves as you develop, but you end up with a perfect history to merge (fast-forward) at the end.

[1] https://github.com/mystor/git-revise/

[2] https://stacked-git.github.io/

I have similar experience as the person you are answering to. Unlike them, I got into rebasing only recently. It isn't really a hand-wave of saying 'you don't know it well enough'. This paradox is caused by a quirk in git's design. Git uses a hybrid model for dealing with versions. It uses snapshots for storing them, as well as for operations like fetch, clone, etc. But that mental model causes a lot of confusion for operations like merges, pulls etc. Git uses the diff-patch model for those operations. Even weirder, much of git is actually designed to use the diff-patch model. The first time I ever got a grip on those operations was when I did rebasing. I found git much easier to understand when I could attribute each operation to the model git uses behind the scenes.

> It's much harder to admit that maybe the tool is just difficult to use in the first place.

That is unfortunately true. Git feels like a tool with several parts that were bolted on to solve problems its users (developers) faced. I didn't have that same difficulty with mercurial. I get this feeling that a pure patch based tool like pijul would match their workflow well and still be easy to learn.

Andrew Tridgell maintains that he didn't violate the terms of BK license. The story of his 'reverse engineering' of BK is necessary to understand the context: https://lwn.net/Articles/132938/

Reading the rest of the comments, I was wondering if I missed something. I use awesome-rss firefox extension [1] to discover RSS feeds on firefox. I maintain a list of feeds using elfeed-org and follow them using elfeed on Emacs. It's clean and extremely fast - especially while searching. Granted that it isn't really beginner friendly. But there are nice beginner-friendly alternatives like liferea too. Here are somethings that confuse me while reading these sorts of articles and discussions:

1. I don't see why they say browsers killed RSS/atom feeds. The only casualty was the discoverability of those feeds (like the discontinued live bookmarks on Firefox). But it is easy enough to restore it using extensions like awesome-rss, if you care enough. And I find a lot of dedicated feed reader applications catering to all sorts of users.

2. I don't understand how twitter and firefox killed RSS/Atom feeds. I find it extremely tedious to search for meaningful information with them. These sites are full of material designed to hold your attention captive while frustrating your efforts at finding worthwhile material. In contrast, RSS/Atom is information dense, easy to search, narrow and archive.

3. There is no dearth of RSS/Atom feeds on the web. Every good news website news site seems to host one. Almost all the blog engines and static site generators automatically generate them without any configuration or intervention. I find my feedlist growing very large overtime.

4. It also appears like many people associate RSS/Atom feeds with an online service like feedreader or (the dead) Google reader. My understanding is that you don't need an online service to aggregate feeds. An intermittently online desktop/mobile client can do it just the same. I haven't noticed an RSS/Atom client ever failing to aggregate a feed. The only thing I found missing was an automatic way to share and synchronize the feed list itself - though it's easy enough to implement with something like syncthing. Am I missing something here?

For me, twitter, FB etc are inferior to RSS/Atom feeds in every conceivable way - with the exception of lack of a discussion forum. I too find the death proclamation of RSS/Atom a bit of an overstatement.

[1] https://github.com/shgysk8zer0/awesome-rss

[2] https://lzone.de/liferea/

Notmuch was inspired by sup, not based on it. The common component for sup, notmuch and mu is xapian.

Perhaps it's worth mentioning XCA [1] at this point. It's a GUI based on openssl that provides an intuitive UI for managing keys, certs (root CA, intermediate CA, server and client) and CSR. It existed before acme and mkcert. What I liked in XCA was that it made it easy to review all parameters related to the operations it managed.

[1] https://hohnstaedt.de/xca/index.php

Why isn't it invalidated by prior art? How does it work anyway?

I know it's a bit late to raise this, but you may find it relevant.

> Pull-requests don't have to be proprietary. We just need a standard format.

A standard format for pull requests actually exists - that too as part of git itself [1]. Github decided to just redefine the term like they did with 'forking'. Torvalds was pretty annoyed with this [2]:

> Git comes with a nice pull-request generation module, but github > instead decided to replace it with their own totally inferior version. > As a result, I consider github useless for these kinds of things.

While git's PR is designed primarily for email, it can be shared on any medium of text communication. Git's PR can also be made from any random git host, as long as the changes are hosted there. This makes it immediately usable for almost every hosted git repo - especially for sourcehut. No registration required.

> I'm not opposed to using email, but right now the UX/UI looks far too lacking.

Again, a problem with current solutions. Most email clients, especially web clients like gmail are terrible for text mails, threaded views, proper quoting, etc - all of which are necessary for a clean email-based workflow. You have to use something like mutt or astroid, and email workflow becomes immediately more enjoyable. While that's what we have now, it doesn't have to end there. Someone could come up with flashy GUI or web interface that's as pleasing as Github's and email workflow will actually become more attractive than Github's.

> Perhaps Sourcehut could also release an email client specifically for viewing pull requests

Sourcehut is actually working on an email client suited for email workflows, called aerc [3].

> but until then I think it will be difficult to adopt

From personal experience, I find adopting email workflow with neomutt or aerc much easier than adopting git itself. Though rebasing is not a strict requirement for email workflow, email patches look janky without it. Learning rebasing is the hard part, not mailing and applying the patches. But the skill to rebase makes your contributions immediately better everywhere - not just for email patches.

[1] https://www.git-scm.com/docs/git-request-pull

[2] https://github.com/torvalds/linux/pull/17#issuecomment-56546...

[3] https://aerc-mail.org/

That is a very poor argument to backup your claim. Not is it just anecdotal, why do you even assume that everyone else has the same experience as you do? Reports and statistics are much more believable. I cited a report. Do you have anything of equal stature to counter it?

It isn't exactly suspicious. I have noticed old news being posted again when it's related/similar to a currently trending news item. Let's just assume that it's an unfortunate coincidence that the people responsible for both fiasco were Indians.

However, these incidents do raise some important issues for both Github and India. This indicates that there is a prevailing situation in India that encourages young novice developers to come up with such low quality contributions to get a foot in the door in the industry.

Either that is lack of awareness or a misrepresentation. Please have a look at this: https://theprint.in/opinion/brahmins-on-india-campuses-study... . There were lots of anecdotes about this going around. But it's documented news these days.

"If Hindus migrate to other regions on earth, Indian caste would become a world problem." - Dr. B R Ambedkar said this in 1916 [1]. The surprising incident in US was predicted more than a century ago.

For more context, Dr. B R Ambedkar was the main architect of the constitution of India. He also formulated the affirmative action for Dalit representation, called the reservation system. He was one of the so called Dalits who faced extreme caste discrimination in India despite his brilliance and all his achievements. There are documented instances where upper caste government officers refused to touch files that he signed. The discrimination was so bad that he and 500K of his followers converted to Buddhism.

These days, some sections treat him like an ideological revolutionary (sort of like marxism or leninism). Many are openly calling for replacing his ideas with those from manusmriti - an ancient text that is a huge source of racism and misogyny in India. Hope this gives you some insight into the problem.

[1] http://www.columbia.edu/itc/mealac/pritchett/00ambedkar/txt_...

It varies from place to place. For example, people are segregated by caste in many places. In other cases, it's easy to identify from surname. But there is one method that you should be aware of - it's more relevant to silicon valley. There are a lot of cases where it's not immediately possible to distinguish caste from name or looks. People from all castes look more or less similar. In such cases, the caste believers would do covert background research. That might be from your social media profile, public and political connections or even professional service records. There are also cases where they make the determination based on subtle differences in traditions (like marriage ceremonies or celebrations, clothing styles etc). And then there are some obnoxious methods like patting someone on their back to see if they wear a 'sacred thread' under their shirt.

It's more like insecurity through obscurity. Caste discrimination among educated circles is viciously covert. You may not know your caste or your colleague's caste. But the ones who are interested will definitely know it and discriminate on its basis. The discrimination and harassment will make no sense to you, unless something or someone tips you off. It's not like discrimination based on color or gender, where the difference is immediately apparent. You can't distinguish people of various castes unless you go actively looking for it. It's better to be aware of possible avenues of exploitation than be negligent and vulnerable to it.

That is the definition of dedication actively peddled in corporate culture. But of course, the best professionals are the ones who are dedicated to their profession, not to one company - especially one that throws hurdles in the way of their productivity and well being. Endorsing that narrative doesn't achieve anything other than enriching some insanely rich people. It's just exploitative.

It's known to be used for testing new engines and launching rockets [1]. But I don't understand what they mean by 'pod'. Can't figure out if they are referring to the hard point, pylon or the engine nacelle.

[1] https://simpleflying.com/boeing-747-5-engines/

I agree about the nose loading part. Meanwhile, how does an engine with its nacelle compare to a marine container in terms of dimensions? Would it be easier or harder to load through the fuselage doors? I also assume that they will need a fixture or container for the engine if it was to be loaded into the cargo hold.

It was the biggest incident of aviation terrorism prior to 9-11. World was very different back then - not a surprise it sounds improbable today.

It isn't experimental or unique even if it's rare. It has been done before. I'm not sure why this instance alone got such attention.

Regarding the cargo hold problem, the aircraft wasn't carrying just the engine core. The 'pod' is most likely the engine nacelle itself. I wonder if the entire thing would fit through the cargo door (mere speculation). While it's true that the 747 was originally meant as a cargo carrier, most of it was meant to be loaded through the nose of the aircraft. The nose could be opened for this purpose and the cockpit was above the cargo area to accommodate this.

The ill-fated Boeing 747 flight AI182 (Kanishka) was carrying an extra engine just like this, when it was destroyed over Atlantic ocean by a terrorist bomb attack in June 1985. The presence of the extra engine was investigated as a possible cause of the disaster before conclusive evidence of a bomb explosion was found. (That and another explosion on the ground at Narita, Japan in a container destined for another Air India flight).

[1] https://aviation-safety.net/database/record.php?id=19850623-...

This a consistent trend on threads that are critical of Google and Apple.

Why do the threads about FairMail contain so much misinformation? It wasn't uploading the contacts to any server. It was fetching favicons from the domains of each contact. That too was opt-in. It feels like there is an effort to discredit Fairmail here.

Gases escape if their molecular velocity exceeds the escape velocity of the planetary body. That's why smaller and hotter objects lack an atmosphere.

That makes it even more scary. In an aircraft, you usually get a few minutes to determine the problem, disengage autopilot and correct it manually. Autopilot is also disengaged during periods of uncertainty like takeoff or landing (unless it's very well proven). In case of a car, you get mere seconds to react. And that reaction should come from your intuition or mental model of the autopilot. That implies that you should have faced a similar dangerous situation before hand, so that you know what may go wrong.

Another way I read it, it's like you being a standby driver ready to take over when the inexperienced driver makes a mistake. I've been in a similar situation with a driving instructor before. While nothing bad happened, the time it took for him to react convinced me that humans are bad at this. The only reason I find autopilot justifiable is if it's quantitatively better than the human driver.

Theoretically, we could build a plugin that does all automatic setup like COC, but then uses the built-in LSP to do the actual work. nvim-lspconfig already does part of this job - configuring the LSP, as long as the server is already installed. Personally, I prefer the system package manager taking care of the servers, rather than yet another package maintenance system.

The primary goal of free software is software freedom and an open code base is only a means to achieve that. Open source movement in many ways was an attempt to deemphasize the freedom part. Any attempt today to reemphasize software freedom is silenced with accusations of purism, zealotry and cultism - that is evident even in this discussion. I have a strong feeling that this is a result of carefully crafted and deliberate narrative rather than of independent opinion.

Until about a decade ago, I used to believe that free vs proprietary model was just a developer preference. But last decade has consistently proven this to be completely wrong. I wouldn't mind per-deployment price for software as long as it treats me with respect and not as cattle to be milked. But time and again, we see proprietary software abuse the obscurity provided by binary-only-distribution to hide all sorts of anti-user code - anywhere from subtle nudging using confusing interfaces, to outright backdoors and malware. Yes, there are still proprietary software that operate ethically. But the threat is far too great that it emphasizes the need for completely open code bases.

That may vindicate open source software. In fact, I believed that open source and free software were practically identical due to the similarity in ways they operate and the licences they use. Here again, big tech has proven that it can push anti-user software as open source. Chrome is a great example - open, but still manages to send your every search letter-by-letter to the server. It also automatically logs you in at the first chance it gets. But chrome is far from being the only offender in this category. Almost all big OSS projects hide many such dark patterns.

Again, I often get shutdown when I mention this. The argument is that the code is open and so I should modify anything I don't like. Yet, it's a fact that such projects exist despite the thousands of developers who hate it. Here is the reason why being open is simply not enough. Software emphasizing freedom tend to be composable, simple and often easily modifiable (eg: emacs, suckless). Many OSS projects take away that freedom by making the codebase too bloated and complicated to be practically forked and maintained by even small to mid size teams. Development of many of them are dictated by one or two big companies that often unilaterally push designs that are hugely unpopular with the community. Another similar dark pattern is to hide bug reports and resolutions behind paywalls. The number of ways in which large OSS projects hurt user freedom is way too many - I will need an entire article to list just the ones I know. Essentially they achieve proprietary level of abuse in a free-looking package. It's difficult to use them in any way different from what its developer intended. People seem to miss the fact that such projects nudge you to part with your coins and that they exfiltrate enough data to implement an ad-hoc social credit system (eg: Don't be surprised if your health insurance premium is influenced by your search history).

> but they tend to switch to proprietary, partly-proprietary, corporate controlled open source, when there's convenience to be had.

This is an important point. Users - at least technically capable ones - must decide if the convenience they get is worth the risks they take with these software. In addition, it isn't as if free software can't be made convenient (the evolution of Blender is a good example). But it takes effort. And that isn't coming due to less money involved.

> Is free software a lost cause? > Are we building a bad future for software by not fighting for something like the Free Software movement?

Free software is a philosophy more than a movement. I believe that there are enough people with awareness to keep it going. There are enough pieces present out there to implement any level of software freedom - from chip designs to whole application suites. The missing part is the awareness, ability and willingness to deploy them. There is great cost in terms of money (free systems are costlier because they don't sell your data), time and effort. But considering the dystopia we're already in, it may be well worth investing in them.