pyratelog

personal blog
git clone git://git.pyratebeard.net/pyratelog.git
Log | Files | Refs | README

20240611-up_git_stream.md (1449B)


      1 Unlike most people (I imagine) I rarely, if ever, run `git pull` when refreshing my local Git repositories.
      2 
      3 Instead, over the years I have grown accustomed to running `git fetch` and `git merge` separately (a `pull` does both of these in one command).
      4 
      5 The reason for this is so that I can review the log and any changes before merging the remote code into my local repo.
      6 
      7 I would try to remember to run `git log` after fetching the remote code, which by default would show the entire log history of the repo.  Then I read about the dotted range notation and `@` construct for specifying [revisions][1] in Git.
      8 
      9 Using `@` on is own is equal to `HEAD`.  Combine it in `git log` with `{upstream}` or `{u}` to only show commit logs for the upstream branch
     10 
     11 ```
     12 git log @{u}
     13 ```
     14 
     15 The two-dot notation is shorthand for all commits in a range.  Therefore to show only the commits from the remote upstream that have yet to be merged in my local branch I would incant
     16 ```
     17 git log HEAD..@{u}
     18 ```
     19 
     20 This can be made even easier by omitting `HEAD`, as leaving one end of the range blank defaults to `HEAD`
     21 ```
     22 git log ..@{u}
     23 ```
     24 
     25 With this newfound knowledge I updated my [`gf` alias][2] to run both commands, automatically showing me the commits I have fetched and need to review
     26 ```
     27 alias gf="git fetch && git log ..@{u}"
     28 ```
     29 
     30 [1]: https://www.git-scm.com/docs/gitrevisions
     31 [2]: https://git.pyratebeard.net/dotfiles/file/zsh/.config/zsh/aliases.zsh.html#l91