0

I'd like to always try to perform a pull before git add runs so that any remote changes can be synced before the local commit is made, assuming no conflicts.

Is there any way to do this besides to use an aliased command? Is there a hook I could use?

The rationale for this is to avoid annoying commits that only exist to merge two divergent branches.

Slbox
  • 10,957
  • 15
  • 54
  • 106
  • 1
    No, there's nothing built in to Git for this. You wouldn't want to do it in the middle of something anyway: e.g., suppose you're halfway through something, and you have `git add`-ed some files successfully, and you get pulled away (family emergency) and then come back. You don't want to `git pull` into your partial work: that makes a big mess. – torek Jun 15 '22 at 10:01
  • In general, if you have *unpublished* commits, you can use `git rebase` to handle this. If you have *published* commits, you can still use rebase: you just need to have everyone else who is making use of the published commits *agree* that rebasing happens, before you start rebasing stuff out from under their feet. (The general rule is "all parties must agree". This applies for unpublished commits, it's just that here, you're all the parties, and you need only agree with yourself.) – torek Jun 15 '22 at 10:02
  • Thanks for your reply @torek. `rebase` rewrites the commit history though, which I'm not a fan of. Your first comment is a sensible reason not to want to do this in a team environment, but as a solo developer, the only changes I could ever be pulling would be my own, made from some other machine, so that would never be an issue, and the `pull` would fail if any of the local files conflicted, so I still think this would be valuable, I just see no way to do it. – Slbox Jun 15 '22 at 23:05
  • Mostly just curiosity, but: what's your objection to rewriting the history? If it's "I might step on myself" there's a solution for that: keep the original sequence of commits, doing the rewrite as a new "branch". I put "branch" in quotes here because the word *branch* in Git is ambiguous in the first place: is it a branch *name*, or is it the tip commit, or is it every commit reachable from the tip commit, or is it a selected subset of commits reachable from the tip commit? The answer to those four questions is usually "yes". – torek Jun 16 '22 at 05:27
  • 1
    If you name your development sequence "experiment 1", the rewrite as "experiment 2", the rewrite of the rewrite as "experiment 3", and so on, and *keep every experiment*, you have never rewritten history: you keep the entire history. But then you choose the *succeeding* experiment to go into the main line. Voila, no rewritten history, in spite of rewriting history. – torek Jun 16 '22 at 05:28
  • That's an interesting approach but keeping multiple machines synced better is my goal, so creating a bunch of new branches seems contrary to my aims, but maybe I'm not fully understanding what you mean when you say "doing the rewrite as a new branch?" – Slbox Jun 16 '22 at 19:48
  • Well: first, define *branch* for me. (See also [What exactly do we mean by "branch"?](https://stackoverflow.com/q/25068543/1256452)) – torek Jun 16 '22 at 19:54

0 Answers0