WTF NPM
-
which eventually makes svn the most fitting solution for most corporate use-case instead of git.
Besides, there is git-svn if people prefer to use git on their end. Personally, I quite like that setup (svn backend, git frontend).
We used git-svn at previous workplace. It works reasonably well, as long as absolutely everyone in the project always uses git-svn and never raw SVN (it wasn't true for my project, and it was a constant source of problems.)
Actually, I used git-svn (and later git-tfs) as the only one, as one of a few, and then as a tool for gradual migration from svn to git where some still used svn and some already switched to git. However in all those cases there was one synchronized mainline and branches from that were managed always with just one of the systems. I wouldn't trust that merges done on branches imported from svn with git would work back in svn.
-
All the decisions like tracking renames, unique revision identifiers and semi-sequential revision numbers look like good ideas, but they turn out to mainly complicate the model.
AFAIK Git also tracks renames?
No, Git detects renames at merge-time, but it, very intentionally, does not have any concept of file identity.
Back then (some time around 2007 IIRC) people were prodding Linus to add rename tracking to Git and he insisted that it is a stupid idea and crappy design. And then he came up with this idea of guessing instead—if the file does not exist, look for similar content under different name and run the 3-way merge with that. It turned out to work well. If the file is similar enough, it will find it and if not, well, the 3-way merge wouldn't work anyway.
Also, I never used Bazaar, but I use Mercurial, which also has sequential revision numbers - and yes, they are quite useless.
They are differently useless in each. In mercurial they are simply order in which the revisions were added to the local repository, so they cannot be shared. In bazaar instead they are numbered along the history, so they actually only change for a merged branch, and are otherwise the same between repositories. On the other hand the stable identifiers are much longer there.
But I like explicit branch management (branch name isn't just an ever-moving tag, but an actual part of commit data - so you always know which branch a particular commit came from even if the branch was already deleted), so for me, Hg > Git.
I don't like that. Being able to just commit stuff under
testandtmpand similar and give it a proper name later is what often makes things easier in git—because you are not distracted by thinking about names when you just need to quickly juggle some changes around.
-
Fossil is just as distributed… hm, interesting, it seems to still keep all the data locally, but can automatically synchronize them with the central repository.
Basically, it's a true DVCS but it synchronizes all (non-private) branches frequently so there's little drift. It also doesn't throw a strop if there's a divergence (e.g., because two people commit at the same time); sure you need to fix it, but the system makes that not too difficult.
-
@dkf By the way, some IDE integrations somewhat do it as well, e.g. Code. There is still the distinction between remote-tracking and local branches though; I am not sure whether Fossil does it differently.
It could probably be generalized. You need a persistent process for it, but on Windows either Cheetah or Tortoise will have one anyway and on Linux everything is Systemd these days and that supports user services.
-
I am not sure whether Fossil does it differently.
Branches default to being coupled to the remote repositories you've set up. You can make private branches if you want, but it's not how things operate if you just use everything in the most obvious way. (It's because its using a usage workflow that's designed to be for small teams, whereas git's default workflow is for very large teams.)
-
whereas git's default workflow is for very large teams
I wouldn't say very large teams as much as hierarchical teams. That is ones where only small subgroup does the integration into the mainline. Which is not how most companies work, of course.
-
No, Git detects renames at merge-time, but it, very intentionally, does not have any concept of file identity.
As a side remark, Linus calls git the stupid content tracker (or see the README in git's first commit).
But I like explicit branch management (branch name isn't just an ever-moving tag, but an actual part of commit data - so you always know which branch a particular commit came from even if the branch was already deleted), so for me, Hg > Git.
I don't like that. Being able to just commit stuff under test and tmp and similar and give it a proper name later is what often makes things easier in git—because you are not distracted by thinking about names when you just need to quickly juggle some changes around.
It's interesting that git is so damn good at "forgetting" stuff. While that obviously holds real danger for the inexperienced user ("danger", as in "bear trap"), it does make some stuff like this have less friction.
-
All the decisions like tracking renames, unique revision identifiers and semi-sequential revision numbers look like good ideas, but they turn out to mainly complicate the model.
AFAIK Git also tracks renames?
No, Git detects renames at merge-time, but it, very intentionally, does not have any concept of file identity.
Back then (some time around 2007 IIRC) people were prodding Linus to add rename tracking to Git and he insisted that it is a stupid idea and crappy design. And then he came up with this idea of guessing instead—if the file does not exist, look for similar content under different name and run the 3-way merge with that. It turned out to work well.
Not that well in my experience. I've eventually developed a habit of always doing renames in separate commit that doesn't contain any other changes, and doing actual changes later.
-
It's interesting that git is so damn good at "forgetting" stuff.
The article has a list of “What's missing?” and it complains how the tools are not perfect, but most of them are still hugely superior to other systems that don't have anything similar at all.
Not that well in my experience. I've eventually developed a habit of always doing renames in separate commit that doesn't contain any other changes, and doing actual changes later.
It makes no difference beyond maybe showing it differently in log, because on merge the detection is done between the local head, remote head and most recent common ancestor without paying any attention to the intermediate states anyway.
-
Not that well in my experience. I've eventually developed a habit of always doing renames in separate commit that doesn't contain any other changes, and doing actual changes later.
It makes no difference beyond maybe showing it differently in log, because on merge the detection is done between the local head, remote head and most recent common ancestor without paying any attention to the intermediate states anyway.
I'm absolutely sure it did work at least in Git version 2.0.0. Several times I've had a situation where I've done move and change in one go, and it lost the history for some files, then I've undone the commit with reset, made only the moves, committed, made the content changes, committed again, and now the content of repo was identical to the undone commit but the history of all files was preserved.
If they've broken that as well in the meantime, I'll be seriously pissed.
-
@Gąska That's the log case (
log -fgoes commit-by-commit; also affectsblame). They didn't break that.I don't see much use for that though. If I'm looking for where some code came from, there is pickaxe and that looks across files.
-
@Bulb In my first software development job, back in 1996, we didn't have any of this high-tech source control. The company did actually care about it, just didn't have any technical solution. The code was written in COBOL, and was over 20 years old at that point (25 years IIRC). Instead, we were required to print out a diff for every change we made and a date-stamp written in the comments. These print-outs were kept in a stack in our development office (only 2 developers, so not as bad as it sounds). Once a year, this stack was 'archived' into a long-term storage cupboard, along with a full copy of the current source code on removable media.
This caused an amusing afternoon at one time. The boss considered it important to discover precisely when a bug was introduced. I was working on a ticket one afternoon, and when I tracked down the bug the code in question had no time-stamp on the comments. I went back through the records for 20 years, the offending code was still there. We actually had to dig out an ancient 8-inch floppy and get the hardware guys to build us a machine out of ancient parts that could actually read the damned thing. Ultimate conclusion was that the bug had existed right from the start, it just took such an unusual set of circumstances to invoke it that nobody had reported it in 25 years.
-
@Seppen thhat's quite a dedication to good practices. I think I'd like to work there.
-
@Gąska It was a good place to work right up until the founder and CEO decided to retire. Our first intimation of this was when he brought in a 'business analyst' to analyse our working practices. As this guy knew absolutely nothing about IT the whole process was a complete wast of time. Then, 6 months later, the founder retired and this 'business analyst' became the new CEO. Things went rapidly downhill from there, and I quit within 6 months. It was getting impossible to actually do my job with all the crap this guy was introducing. The last straw was when I was stuck with a really complicated bit of code. As per my usual practice, I stood up from my desk and paced a little. I'd have gone for a cigarette while I thought, but I'd done that 10 minutes earlier so I just paced a small area around my desk while I thought. The new CEO came into the office, saw this, and dragged me into his office for a 'bollocking'. He completely refused to contemplate the idea that my actions were designed to improve my work rate, instead insisting that I sit at my desk at all times except for officially designated break periods. The next morning I reported him to the H&S authorities (this requirement was against H&S rules at the time) and handed in my notice. The CEO tried to get me to work out my notice, rather than using my owed holiday period. I flat out refused, informed him that I had already reported him to the H&S authorities, and told him straight out that if he forced me to work my month's notice I would make life impossible for him by reporting every single breach of regulations (making me stay at my desk was the least of it). He backed down very quickly.
Was once a brilliant place to work. I don't think it even exists any more.
-
Reason #705 to hate npm:
https://npm.community/t/npm-6-9-1-is-broken-due-to-git-folder-in-published-tarball/8454/15
Better refrain from upgrading because it will happily make and publish packages which cannot be installed.
Apparently asking to include a file "index.js" went looking for all files named "index", in this case
.git/index:
Do not include `.git/index` when the `main` field in package.json is set to `index` · Issue #35 · npm/npm-packlist
When the "main" field in package.json is set to index instead of index.js it will attempt to include all files called index in the tarball when running npm pack This includes .git/index w...
-
you’ll likely need to uninstall npm manually (or at least rimraf the .git directory inside it)
A
rm -rfutil for nodejsOf course.
-
@JBert bonus Discourse bug:
This thread will be closed automatically after fuck knows how many minutes.
-
@Gąska 3 Discominutes.
-
@loopback0 said in WTF NPM:
@Gąska 3 Discominutes.
And if you try to bump it every 2 months, they'll close it manually anyway.
In short, if they don't want to fix it, they'll find ways not to.
-
In short, if they don't want to fix it, they'll find ways not to.
Not to excuse NPM, but this is true for almost any project.
