41–50 of 59 posts
Earlier quoted context omitted.
Perl is a great language. I haven't had an op to use 6 yet but 5 is great for small programs. The big problem with Perl is it requires discipline to prevent creating a mess for your team or eventual successor.
It's not like Python or Ruby are much better in this regard.
Earlier quoted context omitted.
I don't even like the habit of using "git pull". When training folks I start by introducing them to "git fetch" and manually merging or rebasing on the remote tracking branch so they're fully in control of the process while understanding what's going on. Only after people grok that do I mention "git pull", and only in passing while discouraging its use.
So basically you want them each time to do the job that git pull does right 99.999% of the time?
Earlier quoted context omitted.
It's not like Python or Ruby are much better in this regard.
Except they are.
All three languages implement the same programming paradigm and neither of them enforce (or even suggests) any structure whatsoever, so you easily end up with the same mess/spaghetti, no matter the language.
Of course Perl adds some idioms of its own on top of it, but (a) not that many as most people like to attribute to Perl, (b) most of the idioms are syntax sugar, and (c) most of the mess comes from program structure, not from superficial things like syntax.
Maybe it's just me, but I've worked with a handful of source control systems over the years, and none of them (not even git) has done a terrific job of encapsulating the #1 scenario, which is "I copied some stuff locally and changed it and now I want to put it back on the server so other people can get my stuff (and of course I want undo in case I mess up and merge in case we both change the same file)" without inven…
Git has done a terrific job of it. It just doesn't do a great job at communicating what it does, how it does it, why it does it that way and how to achieve those results. In other word, git's great internally... externally it just has a poor UI. But what's new there.
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
This is where I have to point out that this would have been unlikely to happen with BitKeeper. :) 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.…
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).
This is where I have to point out that this would have been unlikely to happen with BitKeeper. :) 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.…
Maybe so, but have the licensing and philosophical reasons that led Torvalds to move the kernel away from BitKeeper been resolved? 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).
This is where I have to point out that this would have been unlikely to happen with BitKeeper. :) 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.…
Maybe so, but have the licensing and philosophical reasons that led Torvalds to move the kernel away from BitKeeper been resolved? 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
> I run my gr alias for git pull --rebase to bring in the new changes 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 b…
I don't even like the habit of using "git pull". When training folks I start by introducing them to "git fetch" and manually merging or rebasing on the remote tracking branch so they're fully in control of the process while understanding what's going on. 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.
Learning question: so the tag was on an orphaned commit? What ways could this be resolved? 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 " 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.