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

71–80 of 100 posts

Re: Highlights from Git 2.34

#71

Post by saurik »

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…

OK: I have a large number of large git submodules that I never edit, but they make every other command that just incidentally creates a diff output slow. I have found command line options for things like git status/diff (--ignore-submodules=dirty) and git commit (--no-status) to avoid this penalty, but I use git rebase -i constantly and wany to use git stash a lot, but the cost of these commands is somewhat brutal when they sometimes cause incidental status reports. What I really want is a setting that like "avoid incidental status" that disables status reports from any command except git status (as I do want to be able to see this status), as I simply don't ever need the noise (such as in the git commit default message) and it really is a pretty annoying delay when rapidly throwing around commands to edit history to have one which suddenly decides to take forever. If nothing else, though, a --no-status for git stash/rebase (I use all these commands through aliases anyway) would be very helpful. (I would be happy to be more specific if this sounds interesting but isn't enough to know what I mean, but I figure it might either be something you wouldn't get behind anyway and I also really want to take a nap and so want to leave a message earlier ;P. I also happen to be saurik@saurik.com and @saurik on Twitter.)

Re: Highlights from Git 2.34

#76

Post by kazinator »

mhio wrote: post #75
kazinator wrote: post #74

Earlier quoted context omitted.

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

Is it the other side then? Do you have issues with 2.x releases? btw rhel maintains a 1.8.x release.

> Do you have issues with 2.x releases?

Possibly; I've been hearing disturbing things about developments like different hash algorithms, and repositories being generated that older versions of git cannot read.

I'm nervous about creating a new central repository with newer git.

Re: Highlights from Git 2.34

#78

Post by avar »

btschaegg wrote: post #68
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…

Something that has been nagging me for my workflow is how Git handles --autosquash. I really like the idea, and wrote my personal little `git autosquash` command that tries to figure out the oldest commit it has to run `git rebase -ir --autosquash` on in order to merge all current "fixup! …" commits into their counterparts. However, doing this in a simple shell script is rather dodgy if you run into more generic comm…

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?

Re: Highlights from Git 2.34

#79

Post by pmeunier »

kadoban wrote: post #49
childintime wrote: post #24

Related: it's been a year since Pijul ( https://pijul.org ) began working towards 1.0 ( https://news.ycombinator.com/item?id=25032956 ). Seems to be coming along nicely, they're in alpha now and it's showing.

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 Bob work on a common Pijul server in parallel with their Git server, they'll get artificial conflicts in Pijul, even though they have the same contents.

Re: Highlights from Git 2.34

#80

Post by btschaegg »

avar wrote: post #78
btschaegg wrote: post #68

Earlier quoted context omitted.

Something that has been nagging me for my workflow is how Git handles --autosquash. I really like the idea, and wrote my personal little `git autosquash` command that tries to figure out the oldest commit it has to run `git rebase -ir --autosquash` on in order to merge all current "fixup! …" commits into their counterparts. However, doing this in a simple shell script is rather dodgy if you run into more generic comm…

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 option of aborting by emptying the buffer before quitting it).

I usually use this to clean up the history of a private local branch, so I won't trigger anything like `git rebase master`. This means that I have to specify the commit where Git is supposed to start the interactive rebase (i.e. the oldest commit that won't be included). And finding that by looking for the subject line after "fixup!" is rather finnicky (especially if the subject line also matches those of other commits), whereas the simple commit hash would be nice and explicit (and finding the starting point would be a simple `git merge-base --octopus` of all fixup! hashes).

So, my problem isn't the autosquash resolution built into Git, but that I have to reimplement it in a script in order to find the proper rebase starting point. That, and all backward searches for commit messages I know of are either really fuzzy or needlessly convoluted.

The best exact matching search I could come up with is something akin to

  git log --pretty=$'%H\x1F%s' "$fixup_commit_hash" | awk -F $'\x1F' -v "subject=$query" '$2 == subject { print $1; exit }'
Post reply on HN