@FaheemMitha a classmate at college used a variable number of spaces to sort the reference list in his editor how he wanted it. More spaces pushed it up to the top.
@FaheemMitha In addition to the fig: convention, I have to admit it was pretty to look at.
@FaheemMitha Because branches are what I use on a day-to-day for my own personal development. I try out ideas, work out different solutions. It's like having the abstract solution to your problem run in multiple different threads and you get to access and work out all of them.
@SeanAllred Oh, I see. I was confused by your terminology. I don't think that is true, but I've actually never used bookmarks. And mercurial has a separate tag concept.
@FaheemMitha Yes, as you've said, but I still think 'bookmarks' is a bad name :) but names are ultimately unimportant. What's the difference between a bookmark and a branch in hg?
@SeanAllred What makes you think they aren't in mercurial? Mercurial is actually very simple to use, and actually has a sane user interface. Which git doesn't.
@FaheemMitha And I'll give hg another look. It has been a few years, though I fear I'm a bit entrenched :) (even seeing as a few interop services are around these days)
@FaheemMitha something like hg uncommit is attractive, but it's ultimately a moot point with a git alias. you could make exactly the same command do the same thing.
@SeanAllred um, there is no such thing as hg uncommit. Actually, there is in evolve, but that is almost certainly not what you are referring to. Also, uncommit means history rewriting.
@FaheemMitha Oh, ok then :) Yeah, git does something similar. You just point HEAD to a different commit. The commit will still exist until the tree is 'pruned' – unneeded commits are removed from the repo then
@FaheemMitha "no other vcs" is a very broad (and very inaccurate) statement
@SeanAllred Yes, I'm aware of that. It's that index thing. It's along the lines of the same idea, but mercurial has a proper implementation. Or it will.
In practice they are a big part of mercurial's functionality. Including basically all the "unsafe" stuff. With mercurial in it's default setting. It's very hard to trash your repos. I'm sure it is possible if you try enough.
@FaheemMitha Oh, no. Think about it this way: If all the examples I ever saw of LaTeX were things like {\Large\bfseries 1. Section One}\normalsize In the beginning…, this would still make it wrong.
Similarly, some people using git use it improperly. Rewriting is an important part of git, but it's not something we really like.
In the end, git is a Build Your Own DVCS in the same way that Emacs is a Build Your Own Editor: it gives you everything you need to create your ideal workflow and then gets out of the way.
@FaheemMitha Of course; mercurial has a very set way of doing things and if what you want to do isn't in that set, it's very hard (or nigh impossible) to get it to actually do what you want to do
@FaheemMitha I'd expect any professional tool to be :)
The extensions have quite extensive functionality. You can do all sorts of things with them. Including things the Mercurial project doesn't recommend. E.g [defaults].
@SeanAllred Yes, that's half of Mercurial's history.
Oh no, I make similar mistakes all the time. I rarely mistype keys, but I'll very often mistype entire words.
Strange phenomenon
And then I stumble upon this piece of gold: vvv
SCM tools are there to help me do my job, not punish me for failing to meditate long enough before pressing return. Besides, if you never make mistakes, presumably you don't need one in the first place. — UselessJan 16 '13 at 18:05
@FaheemMitha I don't need backups because I never make mistakes; I don't need to try different changes because I always make the right choice the first time.
Keeping a record, as I've said, is ultimately useless sans these points.
@SeanAllred backups don't have much to do with mistakes. If a flaming meteorite hit your house, you didn't make a mistake, but your computer will go up in smoke none the same.
@SeanAllred Doing it wrong isn't the issue. It's about incremental development. There will be a period when the feature isn't working completely. You probably want to work on it separately to avoid clashing with other stuff.
@FaheemMitha But that history is extremely sensitive information. You can't apply that logic to proprietary code (and God rest your soul if you try it with classified/secret/top-secret/TS-SCI anything. That will get you in some interrogation room.)
@SeanAllred Sure, take out the bit that is sensitive. If your code is so sensitive that you don't want to keep any history at all, that's way outside my experience, so I can't say anything.
@FaheemMitha It's not that you don't want to keep history of the project, but there are certain parts that absolutely cannot be put on most networks, for instance, and to do so would be a serious breach of security. Keep the history of the code, but leave out the sensitive information. (We often worked with 'dummy data'.)
@SeanAllred Why does history exist? In part, to help people understand the present. Have you ever read a history book? Did you think to yourself - I'm not going to be able to change this history, so I don't want to know about it?
Actually, Americans aren't all that keen on history, come to think of it. For example. They tend to think it's something that started 20 years ago.
@FaheemMitha History is useful for understanding the present, but in software, we have all sorts of supporting documentation to explain the current state of software. Design documents, architectures, SRS, SDS, SSS, (seriously, they get obnoxious), … all of these support understanding what is and why decisions were made.
@FaheemMitha In any case, I don't go around mocking other nations :P
Except France, but I think that's a holdover from being a part of England.
@FaheemMitha Anyways, if there is so much supporting documentation out there in the real world, there isn't need for the version history to be an educational tool. It's interesting to look at it from a metrics perspective, but that data can be transient if that was the only use.
@FaheemMitha And as an aside, a good deal of code does make it into our design documents, but whether I think that's a good thing or a bad thing…
@FaheemMitha as have I.
@FaheemMitha to be perfectly honest I'm not sure where I was going with that one XD
I haven't eaten yet.
…at all today, actually…I'll be back shortly; going to get some groceries :)
I'd be interested in keeping this discussion going, but I think out of deference to the others in this room, we should move it to email if you'd like :) my email can be found in the termmenu documentation.
@SeanAllred Ok, but I'm not really sure where we were going with it. And SE chat isn't a bad place for this kind of interaction. One can use a different room. I'd probably not be able to sustain such an interaction over email.
Analândia seems to be about twice larger than the village I grew up in Southern France :-)
I mean in terms of population. In area it’s considerably larger, of course ;-)
I now understand better how you could see a capybara while going to the university this morning; when you said that earlier, I imagined you saw one in a city park from a town bus, I was a little surprised.
@Alenanno well that's a different thing that isn't a font family with light medium and bold weights (ie one more than usual) it is just different font families whose "medium" weight is visually different
@DavidCarlisle not github, really, but I must admit I have a bias :) there are plenty of other svn hosts out there that won't blatantly monetize your work
@SeanAllred Google Code is evil, GitHub is evil, BitBucket is evil, Atalassian is evil, SourceForge is evil, StackExchange is evil, CodePlex is evil, Gitorious was less evil but now it's eviler thanks to GitLab. :)
@SeanAllred In my case, it's some sort of duck sense, I somehow feel the evilness flowing into their evil veins of their evil systems for... evil reasons. :) I think it boils down to the fine print no one reads and the fact of having so much sensitive information on their side. :) But I'm a paranoid duck, I guess. :) Still, I use evil, they have biscuits. :)
@DavidCarlisle Oh yes, we can print on all kinds of paper :) My dad had a printer that would actually print on a continuous sheet – like an oversized receipt printer.
@DavidCarlisle -- "list should have been called general display environment with a mechanism like $$ for controlling indentation or not if used mid paragrah [sic] but list is a shorter name." hmmmph. that's an even weaker reason for using it for things like theorems and proofs. the hassle one must go through to accommodate a long "optional header" is ridiculous. it's just bad design.
@FaheemMitha -- if using variable numbers of spaces in an argument makes one a freak, then there are lots more of us out there. this is a quite reasonable technique to get things into proper order in an index. not words or strings that begin with numbers, but it's excellent for arranging a few symbols that don't sort into an order that's logical to human readers.
@FriendlyGhost different authors, and it's hard to be completely general so you just need to see which you prefer, sometimes one works better than the other
@SeanAllred -- (sorry to butt into this discussion with what may be an irrelevant observation.) working for a publisher that sometimes has to resurrect files for old documents, and reprocess them, it's fairly often necessary to use the version of a package with which the document was originally processed in order to match the output, or even sometimes to get rid of error messages. sometimes the "compiled" version of the package has gotten lost, and it has to be recreated. (cont)
(cont} in that case, the source code in a vcs will save one's neck.