Fell over this issue with #Mercurial today at work AGAIN. So annoying.
If you add program foo.rb to the default branch (say) by merging it from another branch -- then ´hg log foo.rb´ will not show the merge commit. Finding the record of when (or if!) it was merged is rather hard.
Wie geil ist das denn? Der Chaos Computer Club Essen hat das Grundgesetz nicht nur bei GitHub hochgeladen, sondern so aufbereitet, dass alle Änderungen durch Git Commits dargestellt sind und die Git Kommentare alle wesentlichen Infos enthalten.
Und natürlich haben die Bundespräsidenten mit korrektem Datum committed!
@anotherdaniel dafür müsste Git selbst aber pull-requests abbilden können.
Vielleicht wäre es über merges möglich: kein rebase, sondern immer nur mergen. Leider gehen dabei die Branch-Informationen verloren.
Das named-branch-modell von #Mercurial könnte das sauberer: Lobbyisten-Eingaben gehen erst als named sub-branches ein und werden später in den Gesetzprozess-Branch gemerged, der schlussendlich von Bundespräsidenten in den default-branch gemerged wird. @murphy@markuswerle
So now I'm researching version control software because of an idea for a startup. Need to start getting this out of my skull and into notes so I can concentrate on other things today.
I had an idea for maybe making things better for game/media development using not-proprietary software by rent seekers.
Any companies still using #Mercurial? It was used at one of my first employers, but #Git had already won the battle for mainstream adoption by then. I didn’t mind using it, but I remember encountering some errors that Google would return zero results for. Made it feel like we were the only ones using it, even if that obviously wasn’t the case. Although git was worse in some ways, any error message you got would return hundreds of results when searched, easily getting you unblocked.
When it became clear that Bitbucket had jumped the shark - dropped #Mercurial support, went #git only, developed a smarmy, corporate feel - I sighed, switched SotW to git, moved everything to #GitHub. And now GitHub's front page advertises itself as "the world's leading AI-powered developer platform", and I feel it starting again. I'm tired. Life is short. I want to write code and make things, myself.
@b0rk also, now I'm very curious about a similar version with "git merge: what can go wrong?". As I tend to avoid using "git merge" I guess I could learn a lot from that other side.
And I'm also very curious about that side as #Mercurial seems to emphasize/optimize a lot more on merged history compared to #Git? (at least that's what I had heard)
today I'm thinking about the tradeoffs of using git rebase a bit. I think the goal of rebase is to have a nice linear commit history, which is something I like.
but what are the costs of using rebase? what problems has it caused for you in practice? I'm really only interested in specific bad experiences you've had here -- not opinions or general statements like “rewriting history is bad”
I don't like Git. I don't like Git.
I don't like Git. I don't like Git.
I don't like Git. I don't like Git.
I don't like Git. I don't like Git.
I don't like Git. I don't like Git.
I don't like Git. I don't like Git.
I don't like Git. I don't like Git.
@queue -- #Git does have a competitor that is technologically equivalent if not better: #Mercurial. Mercurial never developed the mindshare that Git has, possibly because Git was chosen for the Linux kernel, and possibly because of the dominating position that GitHub came to enjoy. Nevertheless, Mercurial is a good alternative for those who are annoyed by Git's foibles.
Yes, dear #brew package manager, I definitely did want to upgrade my #hg installation when I’m rebuilding my #Emacs package. You know, the #Mercurial package I had to downgrade every time I tried to update a completely unrelated package.
Does anybody have a recommendation for a #macOS#PackageManager that is less “helpful” and instead simply does what one asks it to do? #HomeBrew’s approach of “oh, this looks a bit outdated so let me ‘help’ you with this” is starting to get on my nerves.
@davidbures thank you - I didn't know that you could pin the package. That's pretty much all I need, at least until the hg-git plugin works with newer versions of #Mercurial again.
I confessed my love.
You thought it was a #mercurial mind's
unforseen turn,
blowing hot&cold,
like a rough weather
pattern to withstand. #Hobnobbing with
the crème de la crème,
you laugh with disbelief.
How can I convince you?
#Lividly running in circles, my words lose their luster.
Pity has no place in a lover's heart
Is anyone using #got / #gameoftrees from #openbsd on their #git repos? Thoughts? I use git now a days but I always had hoped #mercurial would have won, or had their github equivalent.
I've been using #Mercurial instead of Git on my last project. I've gotta say, it's nice.
I like not having a staging area. I like the built-in command aliases like hg st. I think I like the distinction between bookmarks and branches, but I'm still a little confused about the "multiple heads on a branch" concept.
Really, the biggest downside is that the whole software industry assumes that everyone is using Git and GitHub nowadays. (ripgrep doesn't handle .hgignore files.)
#NotOnGitHub: Tell us about your favourite #OpenSource / #FreeSoftware projects that are not available on mainstream platforms, whether on a self-hosted cgit or available as an archive download only.
I'm still a #mercurial fan despite its increasignly marginal status. I asked the Bing AI chatbot to cheer me up by giving me some reasons to keep using Mercurial. It offered me several strong arguments I agreed with... all drawn from a 2012 blog post from Atlassian. (The same Atlassian that dropped Mercurial support from Bitbucket 8 years later, in case the irony is not apparent.)