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

Highlights from Git 2.34

github.blog

Post reply on HN
Print view View original

91–100 of 100 posts

Re: Highlights from Git 2.34

#91

Post by avar »

btschaegg wrote: post #89
avar wrote: post #82

Earlier quoted context omitted.

I understand. Is there any reason you don't (or perhaps you're not aware that you can) use the branch upstream info for this? Whenever I work on a branch called "topic" I do the equivalent of "git branch --set-upstream-to origin/master" on it. That means that all of: git log @{u}.. git diff @{u} git diff @{u}... Will use that upstream point (@{u} or @{upstream}). What does this have to do with rebase? If you do: git…

You're right, I didn't know about @{u}, thanks for the hint! > You'd open an editor with A..D with that, whereas you perhaps only want B..D? That wouldn't be much of an issue for me, but I still tried to implement an option that doesn't rely on my repository having a defined remote. I quite often start a new local git repository whenever I'm about to start a new experiment (or just scripting some one-off task), and m…

You can set "upstream" to another local branch, no remote is required, it's just how it's typically used. Under the hood it's just a way of naming another reference as a divergence point.

I use this extensively with Git(Hub|Lab) (PR|MR)'s. I set the upstream to "master" but push to "topic". The "push.default" docs cover how to have your cake and eat it too there.

Re: Highlights from Git 2.34

#92

Post by renox »

pmeunier wrote: post #86
kadoban wrote: post #83

Earlier quoted context omitted.

I just want to be able to use pijul myself, locally. So I'd want it to just arbitrarily choose a mapping of patches to commits, like by timestamp I guess?

That could work. If your local patches are complex enough you could even rearrange them using patch commutation. At the moment, Pijul is in a state where there is just one remaining feature I want to implement before beta, with a massive expected impact on disk space (and a limited impact on speed as well). For the kind of "smaller (but essential) features" like what you're suggestion, there are tons of those, and we…

And yet given that git is the current "default" VCS, it's very important that this is/will be "as smooth as possible"..

I wonder if it wouldn't be possible to memorize "git order" of patches when importing them in Pijul to be able to re-export them in the same order as they were imported before.

Re: Highlights from Git 2.34

#93

Post by teddyh »

tomnipotent wrote: post #8
teddyh wrote: post #3

They did it again. GitHub “stealing” the Git release announcement, contributing to the Git/GitHub confusion. Comments from the last time: https://news.ycombinator.com/item?id=28207168 For those who don’t know: GitHub is owned by Microsoft, a historical (and current) adversary of all things not Microsoft, particularly Linux¹. Git, the tool, is not made by GitHub; GitHub is a web service which is using Git. Git, the to…

Oh look, the obligatory "Micro$oft is evil" rhetoric based on decades old grievances and very little new evidence. So useful. It's perfectly reasonable for a company, that uses the tool in its name, to have a blog post going over new features. I'm never amazed the distances people will go to distort a boring blog post into some issue or another based on splitting hairs.

> […] based on decades old grievances and very little new evidence.

https://news.ycombinator.com/item?id=29251210

Re: Highlights from Git 2.34

#94

Post by btschaegg »

avar wrote: post #91
btschaegg wrote: post #89

Earlier quoted context omitted.

You're right, I didn't know about @{u}, thanks for the hint! > You'd open an editor with A..D with that, whereas you perhaps only want B..D? That wouldn't be much of an issue for me, but I still tried to implement an option that doesn't rely on my repository having a defined remote. I quite often start a new local git repository whenever I'm about to start a new experiment (or just scripting some one-off task), and m…

You can set "upstream" to another local branch, no remote is required, it's just how it's typically used. Under the hood it's just a way of naming another reference as a divergence point. I use this extensively with Git(Hub|Lab) (PR|MR)'s. I set the upstream to "master" but push to "topic". The "push.default" docs cover how to have your cake and eat it too there.

The reference to the `push.default` config key clarified a lot of things for me. Thank you very much! :)

Re: Highlights from Git 2.34

#95

Post by pletnes »

ohgodplsno wrote: post #48
pletnes wrote: post #46

Earlier quoted context omitted.

Sometimes I almost lose my mind over these situations where git on windows reports a permissions change (git status claims a diff) but there is no way to commit nor revert. This happens maybe once per year and I’ve no idea what a proper fix is. Typically blocks rebasing etc but revert and commit can’t fix it. (Apologies for the poor and ranty bug report.)

git config core.filemode false ?

Interesting. I will have a look.

Re: Highlights from Git 2.34

#96

Post by joconde »

thriftwy wrote: post #62
jakub_g wrote: post #45

Major: A new default merge strategy > In Git 2.34, ort is now the default merge strategy, so you should notice faster merges with fewer bugs just by upgrading > a rewrite allowed Git to implement a merge strategy that doesn’t operate on the index

Git is awesome but it would really be great if they sunsetted merge instead of putting lipstick on it. Merge of two good commits will silently produce bad commit. Merges are not repeatable and can't be reasoned about. Merges get in a way of git bisect. Merge makes simple "git log" not contain all the log. Good luck cherry-picking a merge commit. Merge makes a commit which has important changes not apply to any specif…

How else could we take two diverging branches and mix them back into one?

Re: Highlights from Git 2.34

#97

Post by kasabali »

joconde wrote: post #96
thriftwy wrote: post #62

Earlier quoted context omitted.

Git is awesome but it would really be great if they sunsetted merge instead of putting lipstick on it. Merge of two good commits will silently produce bad commit. Merges are not repeatable and can't be reasoned about. Merges get in a way of git bisect. Merge makes simple "git log" not contain all the log. Good luck cherry-picking a merge commit. Merge makes a commit which has important changes not apply to any specif…

How else could we take two diverging branches and mix them back into one?

by pushing all the shit to master branch and letting your users deal with the breakage, obviously

Re: Highlights from Git 2.34

#98

Post by joconde »

kasabali wrote: post #97
joconde wrote: post #96

Earlier quoted context omitted.

How else could we take two diverging branches and mix them back into one?

by pushing all the shit to master branch and letting your users deal with the breakage, obviously

Yeah but how can I merge all the breakages into one commit, so I can break the most things for my users? I couldn't even do that without merge.

Re: Highlights from Git 2.34

#99

Post by [deleted] »

teddyh wrote: post #93
tomnipotent wrote: post #8

Earlier quoted context omitted.

Oh look, the obligatory "Micro$oft is evil" rhetoric based on decades old grievances and very little new evidence. So useful. It's perfectly reasonable for a company, that uses the tool in its name, to have a blog post going over new features. I'm never amazed the distances people will go to distort a boring blog post into some issue or another based on splitting hairs.

> […] based on decades old grievances and very little new evidence. https://news.ycombinator.com/item?id=29251210

[deleted]

Re: Highlights from Git 2.34

#100

Post by teddyh »

tomnipotent wrote: post #8
teddyh wrote: post #3

They did it again. GitHub “stealing” the Git release announcement, contributing to the Git/GitHub confusion. Comments from the last time: https://news.ycombinator.com/item?id=28207168 For those who don’t know: GitHub is owned by Microsoft, a historical (and current) adversary of all things not Microsoft, particularly Linux¹. Git, the tool, is not made by GitHub; GitHub is a web service which is using Git. Git, the to…

Oh look, the obligatory "Micro$oft is evil" rhetoric based on decades old grievances and very little new evidence. So useful. It's perfectly reasonable for a company, that uses the tool in its name, to have a blog post going over new features. I'm never amazed the distances people will go to distort a boring blog post into some issue or another based on splitting hairs.

> […] based on decades old grievances and very little new evidence.

https://news.ycombinator.com/item?id=29288052

Post reply on HN