Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Highlights from Git 2.28

github.blog

Post reply on HN
Print view View original

111–120 of 147 posts

Re: Highlights from Git 2.28

#111

Post by isaachier »

voltagex_ wrote: post #92
sixstringtheory wrote: post #51

Earlier quoted context omitted.

I love having idempotent makefile tasks that can do this kind of thing. And as far as "pages of instructions in various states of decay," couldn't agree more that those aren't a good solution. I usually observe those instructions containing lots of terminal commands. I'd rather have those in an executable format, with commenting if explanation is needed. Then it's (usually, hopefully) pretty obvious where something b…

How do you make sure your makefile tasks are idempotent?

A simple way is to use output files to indicate if a command has been run.

Example:

git-setup.out: touch $@

Re: Highlights from Git 2.28

#112

Post by shaklee3 »

voltagex_ wrote: post #92
sixstringtheory wrote: post #51

Earlier quoted context omitted.

I love having idempotent makefile tasks that can do this kind of thing. And as far as "pages of instructions in various states of decay," couldn't agree more that those aren't a good solution. I usually observe those instructions containing lots of terminal commands. I'd rather have those in an executable format, with commenting if explanation is needed. Then it's (usually, hopefully) pretty obvious where something b…

How do you make sure your makefile tasks are idempotent?

Drop "done" files indicating a large step is done.

Re: Highlights from Git 2.28

#115

Post by sharken »

war1025 wrote: post #104
DangitBobby wrote: post #97

Earlier quoted context omitted.

Though in the context of git, master is not intended to be a reference to master/slave [1], it is ostensibly widely mis-identified as such. The change therefore is being made by many as an attempt to be more inclusive. I pulled this [2] Bitbucket blog entry from the original article if you want to read what they have to say. 1. https://twitter.com/xpasky/status/1271477451756056577?s=20 2. https://bitbucket.org/blog/m…

I feel like on the one hand my opinion is "this is stupid and doesn't matter", which makes me think the change was not needed. But also my opinion is "this is stupid and doesn't matter", which makes me not really care that they did I guess.

I care if stuff breaks for no good reason and this is one of them.

But Microsoft is establishing a history of being political correct instead of doing the sensible thing.

Calling the default branch master is a design choice and nothing more, if you think otherwise the problem is yours.

Re: Highlights from Git 2.28

#116

Post by e28eta »

jayd16 wrote: post #98
setpatchaddress wrote: post #87

Earlier quoted context omitted.

git worktree. Godsend if you regularly need to work on multiple branches simultaneously.

What does worktree provide that a fresh local clone doesn't?

Maybe too obvious, but if you’re not pushing everything to the remote, local-only content is available in both worktrees.

Re: Highlights from Git 2.28

#117

Post by iad »

MarkSweep wrote: post #107
jayd16 wrote: post #98

Earlier quoted context omitted.

What does worktree provide that a fresh local clone doesn't?

If it's a multi-gigabyte repo that you are cloning over a slow VPN, it speeds things up quite a bit.

The `--reference` and `--dissociate` flags to `git clone` can be used to avoid the majority of the network transfer while still creating an independent local repository.

Re: Highlights from Git 2.28

#118

Post by gempir »

war1025 wrote: post #104
DangitBobby wrote: post #97

Earlier quoted context omitted.

Though in the context of git, master is not intended to be a reference to master/slave [1], it is ostensibly widely mis-identified as such. The change therefore is being made by many as an attempt to be more inclusive. I pulled this [2] Bitbucket blog entry from the original article if you want to read what they have to say. 1. https://twitter.com/xpasky/status/1271477451756056577?s=20 2. https://bitbucket.org/blog/m…

I feel like on the one hand my opinion is "this is stupid and doesn't matter", which makes me think the change was not needed. But also my opinion is "this is stupid and doesn't matter", which makes me not really care that they did I guess.

This change isn't done because master is super offensive or racist in the context of git. It's done to show some kind of support to the movement.

Might not much very much, but I think showing you care is something.

If it breaks a bit of shitty tooling that relies on hardcoded values, then I think we can live through that.

Re: Highlights from Git 2.28

#119

Post by square_usual »

mklein994 wrote: post #96
neves wrote: post #61

I'm a somewhat advanced user of Git. My coworkers use me as a reference when they have a problem of a difficult merge to solve. I don't follow each Git release, but I also didn't notice a great productivity enhancement for a long time. Sure it is a sign of a mature project, but I'd like to know: What's the somewhat recent Git feature that you really improved your productivity?

git diff --color-moved This makes git diff highlight reindented or moved lines differently. I use it to get diffs similar to when you pass -w, but with a bit more context. It takes a bit of experimenting to keep it from looking like a fruit salad, but sometimes you get interesting results. https://git-scm.com/docs/git-diff#Documentation/git-diff.txt...

If you use git diffs frequently, I recommend setting up delta: https://github.com/dandavison/delta
Post reply on HN