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

81–90 of 100 posts

Re: Highlights from Git 2.34

#81

Post by IshKebab »

martinvonz wrote: post #69
kadoban wrote: post #49

Earlier quoted context omitted.

I keep checking in on that. In my case what I need to start seriously using it is two-way git interop. I need to be able to work in pijul locally and "publish" somehow to git. So far that still doesn't seem to exist.

If the Pijul feature you care most about is "first-class conflicts", you may want to check out my VCS: https://github.com/martinvonz/jj . It has git interop.

That looks very cool, and very wise to use git as the actual storage system. Means you have a chance of people actually using it.

I have one question: how do changes to files in the working copy automatically update the current commit hash? Do you just calculate it on demand, and then actually make the commit when some command would move to different commit (`jj switch someotherbranch` or whatever)?

Re: Highlights from Git 2.34

#82

Post by avar »

btschaegg wrote: post #80
avar wrote: post #78

Earlier quoted context omitted.

You can "git commit --fixup ", but that creates a commit whose subject is the subject line of the commit to be fixed up, so that if you run one rebase and the hashes change you can still run --autosquash and the like (and of course, manually move them around). Do you mean that you've got commit subject that are ambiguous within the series you're rebasing, so --autosquash won't correctly attribute them?

Not exactly. My goal is mainly that I'd like to avoid running git log and manually deciding the starting commit (and copying its hash around) before rewriting local branch histories. What I want to achieve is that I can run my script (i.e. `git autosquash`), and it will automatically start the appropriate interactive rebase for me. That means I still get the rebase description I can check by eye in Vim (and have the…

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 rebase -i
It's the same as doing:

    git rebase -i @{u}
That's probably not exactly what you're asking for, i.e. if you've got a history since master of:

    A foo
    B bar
    C !fixup bar
    D !fixup bar
You'd open an editor with A..D with that, whereas you perhaps only want B..D?

Re: Highlights from Git 2.34

#83

Post by kadoban »

pmeunier wrote: post #79
kadoban wrote: post #49

Earlier quoted context omitted.

I keep checking in on that. In my case what I need to start seriously using it is two-way git interop. I need to be able to work in pijul locally and "publish" somehow to git. So far that still doesn't seem to exist.

First, you can easily import Git repos into Pijul. One issue with two-way interop is that while importing a commit into a patch is easy, doing the opposite is more complicated. Indeed, since Pijul is patch-based, there is no way to map patches onto commits in a unique way , since a single patch is quite independent from the context (other patches around it), which is what makes Pijul easy to use. Also, if Alice and B…

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?

Re: Highlights from Git 2.34

#84

Post by ethomson »

avar wrote: post #63
beermonster wrote: post #58

Earlier quoted context omitted.

Do you know what github does differently when performing a merge? I’ve noticed sometimes github says there’s a merge conflict yet when i do the merge locally using the default recursive strategy it often just merges without any conflicts. I know there are cases it can’t handle when there are conflicts, but it seems odd that it cannot merge when there are no merge conflicts.

GitHub (which I'm not affiliated with) does some (all?) of their server-side merging with libgit2, not git itself, although I know they're considering moving to git with the "ort" work. So perhaps it's one of the cases where libgit2's behavior differs?

That's certainly possible, but libgit2 carries an _exhaustive_ test corpus around merge as we aim to be bug-for-bug compatible with git-merge-recursive. This was also proved out by A/B testing the two at scale: https://github.blog/2015-12-15-move-fast/

Re: Highlights from Git 2.34

#85

Post by martinvonz »

IshKebab wrote: post #81
martinvonz wrote: post #69

Earlier quoted context omitted.

If the Pijul feature you care most about is "first-class conflicts", you may want to check out my VCS: https://github.com/martinvonz/jj . It has git interop.

That looks very cool, and very wise to use git as the actual storage system. Means you have a chance of people actually using it. I have one question: how do changes to files in the working copy automatically update the current commit hash? Do you just calculate it on demand, and then actually make the commit when some command would move to different commit (`jj switch someotherbranch` or whatever)?

Any command that depends on the working copy commit will first check if it needs to create a new commit from the working copy contents. So when you run e.g. `jj status`, it will amend the current working copy commit if there are changes.

In case you're thinking that that seems slow, it's not really significant at least up to git.git scale. For larger repos, I plan to rely on something like watchman.

Re: Highlights from Git 2.34

#86

Post by pmeunier »

kadoban wrote: post #83
pmeunier wrote: post #79

Earlier quoted context omitted.

First, you can easily import Git repos into Pijul. One issue with two-way interop is that while importing a commit into a patch is easy, doing the opposite is more complicated. Indeed, since Pijul is patch-based, there is no way to map patches onto commits in a unique way , since a single patch is quite independent from the context (other patches around it), which is what makes Pijul easy to use. Also, if Alice and B…

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 can totally implement them after beta. Git export is a common request we get, though. I'm just scared of how people will react when they export and then reimport their patches elsewhere, and get tons of fake conflicts.

Re: Highlights from Git 2.34

#87

Post by ethomson »

beermonster wrote: post #58
avar wrote: post #42

I've got some patches in this release. If anyone's got question that someone who contributes to git might be able to answer I'd love to help. Are there any specific things that git does that you wish were done better? I probably won't be able to help with very generic things like "it's complex", but if there's specific drawbacks in some particular commands I might be able to fix them. Or anything else, I'll monitor t…

Do you know what github does differently when performing a merge? I’ve noticed sometimes github says there’s a merge conflict yet when i do the merge locally using the default recursive strategy it often just merges without any conflicts. I know there are cases it can’t handle when there are conflicts, but it seems odd that it cannot merge when there are no merge conflicts.

GitHub turns off rename detection and turns off recursive base-building when creating merge commits in pull requests. Both of these selections would cause differences in when a merge produces conflicts. This is for backward compatibility with historical mechanisms for merging pull requests, but it seems like something that we might want to revisit.

Re: Highlights from Git 2.34

#88

Post by kazinator »

Too wrote: post #77
kazinator wrote: post #74

Earlier quoted context omitted.

Works fine; I have no issues with old installations that still use it.

If it works fine, why would you need a “bugfix fork”?

There has to be a fork so that the software being used is identified by a formal tag pointing at a specific commit, and this is backed by some sort of project commitment to put out a commit, if necessary.

It works fine in that I'm not running into issues and not missing features, not in the sense that I proved that it's free of defects; I don't require a fork that has any new commits. Surely, bugs have been found between that version and now, some of which can be meaningfully backported.

Programs can break simply because of all the other moving parts in the environments that are out there; it's a fact of life nowadays that software needs to have a maintenance plan to be viable. A compiler, library or kernel upgrade can expose some latent problem in a program.

Re: Highlights from Git 2.34

#89

Post by btschaegg »

avar wrote: post #82
btschaegg wrote: post #80

Earlier quoted context omitted.

Not exactly. My goal is mainly that I'd like to avoid running git log and manually deciding the starting commit (and copying its hash around) before rewriting local branch histories. What I want to achieve is that I can run my script (i.e. `git autosquash`), and it will automatically start the appropriate interactive rebase for me. That means I still get the rebase description I can check by eye in Vim (and have the…

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 most of these will never get pushed onto a git server. However, even in those cases, my scatterbrain often triggers the "gah, that should have been in a previous commit!" reflex.

By the way: Thank you very much for taking your time and reading all this! :)

Edit: I just re-read the upstream-point thing. Wouldn't that cause a `git push` on `thing` to push directly to `origin/master`?

That also wouldn't be compatible with the workflow we have at work (we use GitLab merge requests)…

Re: Highlights from Git 2.34

#90

Post by kadoban »

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…

I think you will get a lot of complaints, which is unfortunate, but many many will understand that it's not going to be perfect. I was there for the period of switching from svn to git, and similar things happened. Really the only way I even learned git itself is because I could use git locally and the rest of my team couldn't tell.

Regardless though, pijul is really cool. I just badly want to be able to use it at my day job :)

Post reply on HN