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.

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/

Aha, that’s useful to know. Thanks!

This might help https://docs.github.com/en/repositories/configuring-branches...

That page details squashing and rebasing strategies. It doesn’t talk about different merge points being used in a merge when done on GH compared to when the same merge is performed locally on the command line.

I'm not always very happy with the conflicts git rebase gives me.

For example when I try to bring an old feature branch forward, or when I have two private branches with a common history that I've touched on one side and want rebase to apply my history change onto the other branch, I'm often made to resolve a lot more conflict that seems necessary.

There are scripts like git-imerge that give some much nicer conflicts. imerge may not be perfect, but I think it shows there's room for a more clever algorithm.

I'd happily have a git rebase --full-resolver --wuauctl option that consumes a mysteriously large amounts of CPU time, if it saves me some manual conflict resolution =)

They have shipped a new default merging strategy, 'ort', that is supposedly better than the previous default strategy at resolving this kind of issue. You should probably try and see if it makes any difference.

My understanding was that `merge -sort` is generally faster and has less buggy edge cases, but does it resolve conflict any differently than -s recursive ?

That's correct, there may be some very obscure edge cases where it has different behavior (known merge-recursive bugs), but in the general case if you've got UX problems with rebase or merge it won't help.

Unless that UX problem is helped by it being much, much faster, but that's usually only going to be matter for larger repositories.

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 commit messages. Personally, I'd love it if git allowed me to create "fixup! <commit hash>" commits instead. I mean -- it's a fixup. It's not supposed to be readable anyway.

You can "git commit --fixup <commit>", 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 }'

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?

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)…

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! :)

I have two wishes for git:

1. A consistent cross-language API for reading and writing from a bare/remote git repo in ways that would make sense to an average programmer. Something like `git.stat("/file.txt", commit=...)`, `git.open("/file.txt", branch=...)` `git.list_commits(since=...)`, `git.create_commit(parrent_commits=[], branch="", ...)`

2. A good story, better than LFS, for storing large binaries over time.

For #2 I want to reproducibly build a debian image from vendored packages or recompile gcc from source so I need to check in a pre-built compiler. etc

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 [email protected] and @saurik on Twitter.)

I really enjoy git way more than others but working in unreal engine and with binary assets. I've always felt like git filr locks were an area that still needs more attention.

I know file locks are almost an antipattern for git. But there are definitely good use cases and arguments for better git support and related tooling support around them, especially for binary heavier areas.

The other thing I saw other day was sparse index or something. At work we have a monorepo and I wish that was more control or granularity over checking out a subset of a repo somehow. Our clones even with shallow fetch and lfs can be 5+ minutes for an area that should only take 3 seconds. But no good subset checkout.

> Are there any specific things that git does that you wish were done better?

I wish `git-log`'s `--follow` wasn't optional so GitHub et al would show the complete history for files I `git mv`. Mercurial got this one right :)

Yeah, me to. I think that was always the plan, but nobody's had the time to go back, re-visit it, and make it so.

I'd say that most of the work of driving features forward in git is hunting down those various edge cases, taking the time to understand them, and explaining them to others. So if anyone's interested in flipping that particular switch it's very open to first-time contributions.

Well, since you ask. `git add -i` has different "escape"/"exit" semantics for different actions.

If I want to quit/escape adding a patch in the interactive mode I type `q` and then enter.

If I want to quit/escape the interactive add subcommand I type `q` and then enter.

But if I want to quit the `update`, `untracked` etc. I have to enter nothing and then press enter. It would be such a wonderful thing if it also accepted `q` so my muscle "memory" is correct.

I looked into changing this once, but it is written in shell and Perl, which I don't know enough about to figure out.

I actually just ran into this yesterday and completely agree! I ended up just C-c-ing out and used -p.

The other thing that was frustrating with that was that the help text for what commands do is printed before everything, so if your window is small and there's a lot of output, it's not obvious that the ? you typed did anything other than re-print the hunk. It seems odd to not print the help information at the end so you will always see it (unless your window is less than one row tall, but.. you're probably here for dragons anyway in that situation).

Aside from the UX question you've got, which I haven't had time to look at (sorry). We've shipped a pure C version of "add -i" that's been on if you've enabled feature.experimental=true since v2.29.0.

It looks like the ball may have been dropped on opting users in to it by default, but in any case there's numerous bugs in "git add -p" and "git add -i" that got fixed along the way, and fixing existing ones should be a lot easier now.

Note: I've also worked on the perl compiler/interpreter in a past life, so it's not that I'm afraid of hacking on Perl, but doing so in the context of the Git project is and was always particularly painful. If something's written in C you could use all the APIs git had internally, but anything in .sh or .perl was usually stuck parsing text, or reinventing the wheel.

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.)

I ended up putting this in my .gitconfig (global)

    [alias]
        permission-reset = "!git diff -p | grep -E \"^(diff|old mode|new mode)\" | sed -e \"s/^old/NEW/;s/^new/old/;s/^NEW/new/\" | git apply"

So when I run git permission-reset, it sorts it out.

git config core.filemode false ?

Interesting. I will have a look.