The Scott Chacon Gitbutler blog posts are consistently great.
I always use git commit -v to write commit messages- it’s in my muscle memory. However, I’m noticing that a lot of people use git commit -m '...', and therefore use an IMHO inferior way of writing commit messages. Just like I recommend everyone teaching Git to newbies to use the “new style” commands (e.g. switch instead of checkout), discouraging the use of git commit -m seems to me one of the better recommendations for newbies.
The “global ignore file” is the other part of this post that I would highlight. It should help reduce many discussions and make your life nicer.
(I’m a big believer that repo gitignore files should be leaner and some of the stuff I find there should be moved to users’ global ignore files.)
Just like I recommend everyone teaching Git to newbies to use the “new style” commands (e.g. switch instead of checkout),
Man, I remember first learning git about a decade ago and being so confused why checkout was so poorly named. It also felt like checkout was being used for everything (change branch, discarding unstaged changes, getting files from a ref, etc).
Newbies these days have it easy… or easier at least :)
I use -m so that the message is saved in my shell history and I don’t have to type it all out again on the occasion that I need to nuke my personal feature branch.
I don’t really get that one… why are you making a commit if you don’t already know what’s staged? Wanting a reminder of what you’re committing after invoking git commit feels odd. Obviously it’s not doing any harm but like I think it would be useless for 99% of the commits I make, where I finished interactively staging the changes in the commit literally seconds before.
Now if in addition to just seeing the diff, you could delete hunks in order to unstage them, I could see that being cool. But I guess at that point you should probably just be using one of the fancy git GUIs or magit or something
Normally, I work for a while, then make a single commit.
Sometimes I make multiple commits in one go, with git add -p. But that’s infrequent.
When I make a single commit, I tend to use git add . (after checking with git status), then git commit -v has two purposes. Doublechecking the diff looks good is not the main one; the main one is composing a complete commit message.
Normally I have a fair idea of what’s in the commit, of course, but being able to review everything helps me not forget anything in the commit message.
having the diff on the screen also helps if you want to mention some technical details that are clearly visible in the diff, e.g. the name of a function that had its behaviour changed and you’re explaining why. in some editors it’s even possible to get autocomplete using all ‘words’ (such as identifiers) in the currently open file, so having the diff on screen can help avoid typos and silly mistakes.
git commit -v is interesting, I do something similar - I use git commit on the command line, my $EDITOR set to vim, and with the tpope/fugitive plugin and autocmd FileType gitcommit silent execute "vert Git diff --cached | wincmd x" in my vimrc to open the diff in a vertical split on the right so I can write my commit message on the left…
Oh, that looks nice. As an Emacs user, I should use Magit (which I expect to do something similar)… but I kinda like to get the “basic” Git experience to be able to give more “entry-level” advice.
I’m old enough to remember when the “Hot New Thing” were all these other stacks that weren’t perl or PHP - now I guess we’re stuck in a cycle where the “Hot New Thing” is perpetually a new JS framework.
This feels like the worst Javascript job interview ever and like beating a dead horse.
Everyone drags out this “Made In 10 days” line, even Eich himself, but he made a working prototype in 10 days 26 years and 12 ECMA versions ago, and somehow it’s the core of every single argument against Javascript - by this standard, you can discount the entire World Wide Web by the time it took Tim Berner’s Lee to make the first prototype web browser. Heck, you can summarize the entire history of the Web as “prototype released into the wild” and nab all the problems of modern computing as “weird edge cases that still exist for historical reasons” but for some bizarre reason, people only ever bring this up when it comes to Javascript.
JavaScript has a strong commitment to backwards compatibility and that makes the 10 day prototype more significant IMO. Many things that get built quickly can be refactored down the line. JavaScript won’t.
Open up the console in your browser and try out print("Hello World!") … this would’ve printed Hello World in 1995 on Eich’s 10 day prototype “Mocha” - it doesn’t do that anymore. It’s not completely backward-compatible.
That seems like a minor form of backwards incompatibility. I don’t think we’ll ever see a breaking change like python 2 to 3, which is a good thing, but it means that the underlying design is even more important.
The p2 to p3 break is one of the worst things they could do, for negligible actual “improvement”.
My wife is now stuck perpetually having to fight p2 vs p3 software issues, and will be for all time as there are some very hefty bioinformatics packages that aren’t going to be rewritten any time soon.
Print has been (surprisingly) bringing up a print dialog for pretty much every version of JS other than maybe the first betas when there was no backwards compatibility problem.
Heck, you can summarize the entire history of the Web as “prototype released into the wild” and nab all the problems of modern computing as “weird edge cases that still exist for historical reasons”
Great, let’s do it. And go back to native software running on machines users actually control.
“Theseus himself is much too small to even contain a small computing machine” …. 70 years later: RasPi Pico, which is about the size of 3 pennies end-to-end, and you could probably stack 3 of them (with headers) in that space…
Matrix has two forms of IRC bridging; one that is enabled on a per-user basis and one that is enabled on a per-room basis. They are both quite awkward to set up, but I’ve been using the room-based bridging in a few freenode channels I administer, and it’s worked seamlessly for almost a year now.
But I agree that the user-level IRC bridging is not that great. If you want to use Matrix to talk to freenode folks, please consider asking the channel ops to set up “plumbed rooms” that are much more reliable.
If your branch is already named “master,” there’s literally nobody going to force you to change it.
Git changed a default; if you profoundly need to call your branch “master” have at it, but there’s really no need to write a 3000-some word diatribe about the decline of western civilization or whatever this is simply because of a default name changing. All your “cons” are resolved by a simple sed command, which seems to have already been run at git hq
Took a minute to find the code examples and the documentation, looks interesting, but this site seems more directed towards the business side than the code side.
Beautifully simple solution - I have a pair of power-banks that I love but are aging out. Yesterday I became curious as to whether they always wobbled a little on a flat surface or not, and I’ve started looking for a source for replacement batteries in case mine had started bulging.
This is probably going to become a bit of a free for all, but in my opinion:
I guess I could use some clarification: should I stop posting stories about anything not explicitly technical here?
Yes, but so should everyone. There are many outlets for non-technical and technical-adjacent stuff. HN, for example, is good for hiring/firing/financial stuff related to tech. Part of what has make lobsters good in the past is a relatively tight focus on technical articles.
I hope that we don’t become a muddy mish-mash of whatever people find “interesting” that’s not strictly technical. I understand that the culture and practices tag have both attracted attention for perhaps not being useful because of the implications they hold as tech-adjacent, rather than technical tags for posting things that don’t otherwise fit.
I’ve had a link removed that was I thought a good piece (by someone else) about designing software for better social interactions. Sometimes I’m pretty baffled about what the focus is supposed to be, exactly, if software design isn’t on the table. Maybe we aren’t supposed to post about people-centric design decisions, but only performance/correctness stuff?
I don’t really care about that one story, but the overall uncertainty is offputting.
Perhaps an analysis of how the design and implementation of Unix was informed by the culture of Bell Labs and any ringing effects that has today?
I don’t think I have ever, or will ever, post under such a tag because tbh I just don’t see how it’s that useful, but other people disagree and find that it is - which is fine, we’re a community and we are allowed to disagree.
DNS doesn’t actually convert it, as mentioned in the post. It’s the normalization process that does, it uses a map found on unicode.org.
I made a small script that only outputs valid ones. There’s also the unorm javascript library, which is the equivalent of libidn in js.
Quite a few programming languages also work similarly, using a specific (but not IDNA) method of normalizing identifiers. For example, here’s some valid Python.
If you know your way around the different Unicode equivalence types and normalization forms, you can have a lot of fun (for varying definitions of “fun”) with this.
That’s awesome, thanks for the info.
Actually, that reminds me that in URLs upper and lower cases are equivalent, I had forgotten upper cases in my script. That adds another whole range of equivalent glyphs.
The Scott Chacon Gitbutler blog posts are consistently great.
I always use
git commit -vto write commit messages- it’s in my muscle memory. However, I’m noticing that a lot of people usegit commit -m '...', and therefore use an IMHO inferior way of writing commit messages. Just like I recommend everyone teaching Git to newbies to use the “new style” commands (e.g.switchinstead ofcheckout), discouraging the use ofgit commit -mseems to me one of the better recommendations for newbies.The “global ignore file” is the other part of this post that I would highlight. It should help reduce many discussions and make your life nicer.
(I’m a big believer that repo gitignore files should be leaner and some of the stuff I find there should be moved to users’ global ignore files.)
edit: well, started yet another small advice text on my personal repo.
Man, I remember first learning git about a decade ago and being so confused why
checkoutwas so poorly named. It also felt likecheckoutwas being used for everything (change branch, discarding unstaged changes, getting files from a ref, etc).Newbies these days have it easy… or easier at least :)
I use -m so that the message is saved in my shell history and I don’t have to type it all out again on the occasion that I need to nuke my personal feature branch.
You can rescue old commit messages from the reflog
I’m sure, but that sounds a lot more complicated than typing:
git co<Up>I don’t really get that one… why are you making a commit if you don’t already know what’s staged? Wanting a reminder of what you’re committing after invoking
git commitfeels odd. Obviously it’s not doing any harm but like I think it would be useless for 99% of the commits I make, where I finished interactively staging the changes in the commit literally seconds before.Now if in addition to just seeing the diff, you could delete hunks in order to unstage them, I could see that being cool. But I guess at that point you should probably just be using one of the fancy git GUIs or magit or something
Normally, I work for a while, then make a single commit.
Sometimes I make multiple commits in one go, with
git add -p. But that’s infrequent.When I make a single commit, I tend to use
git add .(after checking withgit status), thengit commit -vhas two purposes. Doublechecking the diff looks good is not the main one; the main one is composing a complete commit message.Normally I have a fair idea of what’s in the commit, of course, but being able to review everything helps me not forget anything in the commit message.
having the diff on the screen also helps if you want to mention some technical details that are clearly visible in the diff, e.g. the name of a function that had its behaviour changed and you’re explaining why. in some editors it’s even possible to get autocomplete using all ‘words’ (such as identifiers) in the currently open file, so having the diff on screen can help avoid typos and silly mistakes.
git commit -vis interesting, I do something similar - I usegit commiton the command line, my $EDITOR set to vim, and with the tpope/fugitive plugin andautocmd FileType gitcommit silent execute "vert Git diff --cached | wincmd x"in my vimrc to open the diff in a vertical split on the right so I can write my commit message on the left…Oh, that looks nice. As an Emacs user, I should use Magit (which I expect to do something similar)… but I kinda like to get the “basic” Git experience to be able to give more “entry-level” advice.
Magit does exactly that by default (split, and show commit buffer and diff side by side)
I like to use
git guifor writing commit messages… I find it nice to be able to scroll through the individual files I changedI found a vim plugin that did most of this, and then improved it to do more & better … I should get back into it and figure out a good way to do the misused phrases…
My simple version of this (and my attempt to learn some vimscript) was this: https://github.com/jjasghar/vim-wrong-words-oss.
Admittedly the first plugin you found is so much more complete then my little highlighter.
I’m mostly the same - keeping it to vim… but I use vim’s built-in completions for filenames & other variables in the current document.
I’m old enough to remember when the “Hot New Thing” were all these other stacks that weren’t perl or PHP - now I guess we’re stuck in a cycle where the “Hot New Thing” is perpetually a new JS framework.
This feels like the worst Javascript job interview ever and like beating a dead horse.
Everyone drags out this “Made In 10 days” line, even Eich himself, but he made a working prototype in 10 days 26 years and 12 ECMA versions ago, and somehow it’s the core of every single argument against Javascript - by this standard, you can discount the entire World Wide Web by the time it took Tim Berner’s Lee to make the first prototype web browser. Heck, you can summarize the entire history of the Web as “prototype released into the wild” and nab all the problems of modern computing as “weird edge cases that still exist for historical reasons” but for some bizarre reason, people only ever bring this up when it comes to Javascript.
JavaScript has a strong commitment to backwards compatibility and that makes the 10 day prototype more significant IMO. Many things that get built quickly can be refactored down the line. JavaScript won’t.
Open up the console in your browser and try out
print("Hello World!")… this would’ve printedHello Worldin 1995 on Eich’s 10 day prototype “Mocha” - it doesn’t do that anymore. It’s not completely backward-compatible.That seems like a minor form of backwards incompatibility. I don’t think we’ll ever see a breaking change like python 2 to 3, which is a good thing, but it means that the underlying design is even more important.
The p2 to p3 break is one of the worst things they could do, for negligible actual “improvement”.
My wife is now stuck perpetually having to fight p2 vs p3 software issues, and will be for all time as there are some very hefty bioinformatics packages that aren’t going to be rewritten any time soon.
Print has been (surprisingly) bringing up a print dialog for pretty much every version of JS other than maybe the first betas when there was no backwards compatibility problem.
So he actually made it even worse.
Great, let’s do it. And go back to native software running on machines users actually control.
It’s always the simple things that are the most trouble.
Awesome! I was planning to look for solutions on how to manage microKorg patches from linux, this looks like it fits the bill.
“Theseus himself is much too small to even contain a small computing machine” …. 70 years later: RasPi Pico, which is about the size of 3 pennies end-to-end, and you could probably stack 3 of them (with headers) in that space…
Matrix’s IRC bridge is awkward, Gitter’s IRC bridge is much better - I wonder if they’re going to switch and give IRC diehards a hard time.
Matrix has two forms of IRC bridging; one that is enabled on a per-user basis and one that is enabled on a per-room basis. They are both quite awkward to set up, but I’ve been using the room-based bridging in a few freenode channels I administer, and it’s worked seamlessly for almost a year now.
But I agree that the user-level IRC bridging is not that great. If you want to use Matrix to talk to freenode folks, please consider asking the channel ops to set up “plumbed rooms” that are much more reliable.
this looks like a really neat project, I love seeing technology designed to live up to its full potential.
If your branch is already named “master,” there’s literally nobody going to force you to change it. Git changed a default; if you profoundly need to call your branch “master” have at it, but there’s really no need to write a 3000-some word diatribe about the decline of western civilization or whatever this is simply because of a default name changing. All your “cons” are resolved by a simple sed command, which seems to have already been run at git hq
It’s time for NaNoGenMo 2020, so I’m going to be working towards making a generative novel or two…
I can’t wait to see what you come up with.
Took a minute to find the code examples and the documentation, looks interesting, but this site seems more directed towards the business side than the code side.
The frontpage literally has a link to the docs in the first paragraph…
Maybe I would’ve seen it if it said “click here” instead of just “here.”
I love the obligatory link to XKCD right up front, although I think the buried lede here is that Word Perfect for DOS still requires a license. I don’t think there’s going to be many fresh installs, but I find it interesting that this is still available; maybe GRR Martin’s love of WordStar 4 will sway people to trying the old ways.
Betteridge’s law says “no”, but I’m certain somebody out there is making the switch.
Here’s my site, if anyone cares to critique or not.
https://jkirchartz.com/
Beautifully simple solution - I have a pair of power-banks that I love but are aging out. Yesterday I became curious as to whether they always wobbled a little on a flat surface or not, and I’ve started looking for a source for replacement batteries in case mine had started bulging.
This is probably going to become a bit of a free for all, but in my opinion:
Yes, but so should everyone. There are many outlets for non-technical and technical-adjacent stuff. HN, for example, is good for hiring/firing/financial stuff related to tech. Part of what has make lobsters good in the past is a relatively tight focus on technical articles.
I hope that we don’t become a muddy mish-mash of whatever people find “interesting” that’s not strictly technical. I understand that the culture and practices tag have both attracted attention for perhaps not being useful because of the implications they hold as tech-adjacent, rather than technical tags for posting things that don’t otherwise fit.
I’ve had a link removed that was I thought a good piece (by someone else) about designing software for better social interactions. Sometimes I’m pretty baffled about what the focus is supposed to be, exactly, if software design isn’t on the table. Maybe we aren’t supposed to post about people-centric design decisions, but only performance/correctness stuff?
I don’t really care about that one story, but the overall uncertainty is offputting.
What technical topics could/should be posted to the “culture” tag?
Perhaps an analysis of how the design and implementation of Unix was informed by the culture of Bell Labs and any ringing effects that has today?
I don’t think I have ever, or will ever, post under such a tag because tbh I just don’t see how it’s that useful, but other people disagree and find that it is - which is fine, we’re a community and we are allowed to disagree.
This is fun… https://𝔩𝔬𝔟𝔰𝔱𝔢.𝔯𝔰/s/sfgoya/why_resolves_nixers_net … I wonder how many of these “styles” work … and why screenreader’s can’t convert this like DNS does…
DNS doesn’t actually convert it, as mentioned in the post. It’s the normalization process that does, it uses a map found on unicode.org. I made a small script that only outputs valid ones. There’s also the unorm javascript library, which is the equivalent of libidn in js.
Quite a few programming languages also work similarly, using a specific (but not IDNA) method of normalizing identifiers. For example, here’s some valid Python.
If you know your way around the different Unicode equivalence types and normalization forms, you can have a lot of fun (for varying definitions of “fun”) with this.
That’s awesome, thanks for the info.
Actually, that reminds me that in URLs upper and lower cases are equivalent, I had forgotten upper cases in my script. That adds another whole range of equivalent glyphs.