6 ms·

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 spe

• Lammy 5y ago
  > 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 :)
  • avar 5y ago
    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.
• henrikeh 5y ago
  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.
  • avar 5y ago
    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.
  • harrisi 5y ago
    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).
• tux3 5y ago
  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 =)
  • IlGrigiore 5y ago
    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.
    • tux3 5y ago
      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 ?
      • avar 5y ago
        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.
• pletnes 5y ago
  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.)
  • ohgodplsno 5y ago
    git config core.filemode false ?
    • pletnes 5y ago
      Interesting. I will have a look.
  • JoshStrobl 5y ago
    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.
• beermonster 5y ago
  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.
  • ethomson 5y ago
    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.
  • harrisi 5y ago
    This might help https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github https://docs.github.com/en/repositories/configuring-branches...
    • beermonster 5y ago
      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.
  • avar 5y ago
    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?
    • ethomson 5y ago
      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/ https://github.blog/2015-12-15-move-fast/
• namrog84 5y ago
  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.
• gravypod 5y ago
  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
• btschaegg 5y ago
  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.
  • avar 5y ago
    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?
    • btschaegg 5y ago
      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 }'
• saurik 5y ago
  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.)