In other word, git's great internally... externally it just has a poor UI. But what's new there.
But Git is a whole 'nother layer of awful beyond all of them.
Another one of the "reasons I can't get along with Linux users" is that they see something like Git and just kind of shrug and deal with it instead of getting angry that we have a piece of basically brand new software that was built without even attempting to incorporate any UI concepts we knew about at the time it was written. And since it's a CLI that about a thousand other scripts and tools consume (instead of having proper separation of the human interface from the machine interface), it basically cannot be improved at this point, not without breaking thousands of third-party tools. Sigh.
That's what git reflog is for; and if you're paranoid you can set it up so it doesn't garbage collect as aggressively or at all.
Git does this well if everything is checked into one repo. Submodules are kind of a pain. I wish they were represented better via the CLI.
The big problem with Perl is it requires discipline to prevent creating a mess for your team or eventual successor.
I'm a very competent oo perl developer. I recently wrote a complex large platform in Perl5. It's simply not good enough.
In addition cpan is like walking the dungeons of moria. amazing relics of complexity frozen in time.
That said, both Perls are nice languages. Personally I prefer Perl 5 slightly, but both are fun to use, if confusing at first. (Perl, especially Perl 5, seems extremely arbitrary and nonsensical until you “get it”.)
The mistake was blindly using git rebase. History rewriting (which includes not only rebase but also amend) should be done with care, and never on history which has already been published (with a few special exceptions, but unless you really know what you're doing -- don't).
The correct thing to do, since the commit was already pushed, would have been "git pull" without the --rebase, and then pushing the resulting merge commit. Getting in the habit of doing "git pull --rebase" every time is not a good idea; better have a "dirtier" history full of merges, than have to untangle messes like this one later.
Only after people grok that do I mention "git pull", and only in passing while discouraging its use.
It's faster than manually doing the fetch and then merge/rebase. If it succeeds you're at the newest version, if not you can still decide whether to merge or rebase. This should be the default behavior for git pull in my opinion.
BitKeeper doesn't provide a 'pull --rebase' and instead puts this in separate commands 'bk pull; bk collapse -e@; bk citool'. By default, collapse will refuse to replace an already released cset. Yeah less powerful, but we believe more predictable.
Also, tags are fully revisioned controlled and propagate with every pull. You can move a tag to another revision and that operation becomes its own cset that propagates.
www.bitkeeper.org
Oh, and has bk fast-import so any git project can try it out. And of course has bk fast-export so you can bail out if you don't like it. Incremental fast-import coming.
Until that can be said and news of that disseminated widely, I think many open source projects will consider BitKeeper as simply not having enough of a technical edge over Git to discount the cultural penalties (namely, "bad" reputation withing FLOSS and smaller population of users).
The news was disseminated quite widely:
* https://lwn.net/Articles/686896/ * https://news.ycombinator.com/item?id=11667494
Also have you been on Jenkins recently? It looks and feels like butt.
The obvious and chosen one was to tag a new release and explain to people that the old one isn't accessible because of a muck up.
Would of merging it back in worked? that would of fixed the "<nwc10> the tag is for a commit which is not a parent of nqp master" right?
git does not update local tags when the tag has changed remotely (see "on retagging" in the git tag man-page), so it would have to be a different tag.
Merging it back would be confusing, because you know have the old branch and the new branch in your history. It would cause the tag to be reachable again from master though.
This could have been prevented by using "the cactus model" of git branching (sorry no link to source as am on mobile, Google should find it tho) where releases are branches, not tags.
https://forge.rust-lang.org/release-process.html
For 1.11, we had two things go wrong:
1. stable docs got accidentally deleted, so we had a small amount of downtime before the new ones went up.
2. We recently moved the website to be i18n-able, and there was a subtle bug with Cloudfront invalidation tokens. So the site was updated, but the older version was still being shown for a bit.
We could and maybe will make this 100% automated in the future. There's always so much work to do...
There is this charisma around git that I simply don't understand.
Errors like this are avoidmake. Supporters explain it away as user error.
