{"id":600411,"date":"2023-01-23T06:49:43","date_gmt":"2023-01-23T12:49:43","guid":{"rendered":"https:\/\/news.sellorbuyhomefast.com\/index.php\/2023\/01\/23\/git-commands-you-probably-do-not-need\/"},"modified":"2023-01-23T06:49:43","modified_gmt":"2023-01-23T12:49:43","slug":"git-commands-you-probably-do-not-need","status":"publish","type":"post","link":"https:\/\/newsycanuse.com\/index.php\/2023\/01\/23\/git-commands-you-probably-do-not-need\/","title":{"rendered":"Git Commands You Probably Do Not Need"},"content":{"rendered":"
\n

Ah, git<\/a>! Love it, hate it. Few things are as central to the modern software
\ndevelopment workflow as source-control management (SCM) tools. Although there
\nhave been and still are plenty of alternatives to git<\/code> in the world of SCMs,
\nnone other seem quite as prevalent both in open-source and the enterprise.<\/p>\n

Regardless of how central git<\/code> has grown to be for many (most?) software
\ndevelopers, I frequently get the impression that people have a tendency to shy
\naway from anything beyond the relatively basic functionality it provides.<\/p>\n

Since its very inception git<\/code> has been notorious for its often unfriendly,
\ninconsistent and occasionally hostile command line interface:<\/p>\n

\"Git<\/p>\n

In this post I\u2019ll present a few git<\/code> commands and operations I run or have run
\non occasion, in no particular order, that the majority of git<\/code> users out there
\nmight not ever need.<\/p>\n

The empty commit \u2205<\/h2>\n

git<\/code> is designed to track content and changes to that content over time, so
\ncreating empty<\/em> commits doesn\u2019t sound like a very productive or sensible thing
\nto do. Not adding<\/em> any content might seem like a waste.<\/p>\n

Yet, I know off the top of my mind at least two occasions where creating an
\nempty commit can make quite a bit of sense:<\/p>\n

    \n
  1. Initializing new repositories.<\/li>\n
  2. Triggering continuous deployment pipelines.<\/li>\n<\/ol>\n

    1. Initializing a new repository<\/h3>\n

    My main reason for using the --allow-empty<\/code> flag to git<\/code> is to create an
    \ninitial commit in a repository before<\/em> I have any content for it.<\/p>\n

    Why?<\/p>\n

    Primary reason for me is that git rebase<\/code> is somewhat troublesome when wanting
    \nto rewrite the first commit of a repository. The rebase<\/code> command centers around
    \nworking against an <\/code> commit    1<\/sup><\/a>, and by definition the first commit
    \nof a branch has no upstream. In later versions of git<\/code> the --root<\/code> option has
    \nbeen added to remedy this, but I still like to use the opportunity to start any
    \nnew line of history with an empty commit:<\/p>\n

    \u276f git commit --allow-empty -m \"Initial commit\"\n\u276f git show --stat 592f9dd06d1013e4b5300311e6c1b7033c17ab9b\ncommit 592f9dd06d1013e4b5300311e6c1b7033c17ab9b\nAuthor: Martin \u00d8in\u00e6s Myrseth <my*****<\/span>@***<\/span>il.com<\/span>>\nDate:   Thu Dec 21 21:25:24 2017 +0100\n\n    Initial commit\n<\/code><\/pre>\n
    Observe that the typical diff<\/em> of the git show<\/code> command is missing. There was
    \nno content in this commit.<\/p>\n
    2. Trigger a build<\/h3>\n
    Depending on your continuous integration\/deployment setup chances are that
    \nautomated work is scheduled based on updates to some git<\/code> repository. Alas,
    \nflaky network and computation resources, tests and dependency management often
    \ncome in the way of a flawless pipeline execution.<\/p>\n
    Creating empty git<\/code> commits and pushing them to a PR might be all you need to
    \nscratch that \u201clet\u2019s just try it once more, without changing<\/em> anything\u201d itch.<\/p>\n
    Pushing locally ????<\/h2>\n
    It\u2019s hard to use git<\/code> for long without encountering git push<\/code>, the git<\/code>
    \nsub-command for transferring (copying) stuff from your local repository to some
    \nother<\/em>, remote git<\/code> repository. The format of the command I\u2019m sure most people
    \nare familiar with is:<\/p>\n
    git push \n<\/code><\/pre>\n
    Or for the more adventurous:<\/p>\n
    git push  \n<\/code><\/pre>\n
    Now what if I told you it\u2019s possible to push a remote<\/em> reference to your
    \nlocal<\/em> repository, effectively reversing the direction of the push operation?<\/p>\n
    git push . origin\/main:main\n<\/code><\/pre>\n
    The dot (.<\/code>) in the command above is what tells git<\/code> that the destination
    \nrepository is the current directory. It\u2019s equivalent to .\/<\/code> or the absolute
    \npath of the repository (i.e. $(pwd)<\/code>).<\/p>\n
    \n
    Why on earth would you ever want to do this? Haven\u2019t you heard of git pull?<\/p>\n<\/blockquote>\n
    Well, first off git pull<\/code> is a combination of two<\/em> git<\/code> operations: git
    \nfetch<\/code> followed by either a git merge<\/code> or a git rebase<\/code> depending on user
    \nconfiguration.<\/p>\n
    Truthfully, a git fetch<\/code> does the opposite of a typical git push<\/code>, which is to
    \nupdate the remote-tracking branches locally, including retrieving all objects
    \nrequired to complete the history of the newfound remote commits. Then \u2013 in the
    \ngit pull<\/code> case \u2013 git merge<\/code> or git rebase<\/code> are invoked to update the
    \ncurrently checked out ref<\/code> to whichever commit is pointed to by the
    \nremote-tracking branch defined as the \u201cupstream\u201d of the current local branch
    \n(pheeew<\/em>).<\/p>\n
    The main issue with git pull<\/code> in this scenario is the second step, as both git
    \nmerge<\/code> and git rebase<\/code> require the ref<\/code> about to be updated to also be checked
    \nout. This is because any potential conflicts must be resolved \u201con the branch\u201d.<\/p>\n
    In fact, in order to properly \u201cpush to the local repository\u201d it\u2019s necessary<\/em> to
    \ninvoke a git fetch<\/code> first to ensure that the remote tracking branches are
    \nupdated.<\/p>\n
    Remote-tracking branches are git<\/code> references (refs<\/code>) typically stored in
    \n.git\/refs\/remotes\/\/<\/code> which keep track of the branch
    \nstate of a remote repository. For the most part the remote-name<\/code> and branch<\/code>
    \ncombinations are unambiguous allowing references to remote-tracking branches to
    \nbe abbreviated like origin\/main<\/code>. These references are managed by the git
    \nfetch<\/code> command primarily. It\u2019s important to be aware that git<\/code> does not<\/em> hit
    \nthe network to check for updates when simply referring to refs<\/code> like
    \norigin\/main<\/code>.<\/p>\n
    Let\u2019s say that you have been working for a long-ish period of time on a feature
    \nbranch, leaving your local copy of the project\u2019s main<\/code> branch significantly out
    \nof date. For whatever reason (diffing, cherry-picking, etc) you want to update
    \nmain<\/code> with the latest upstream changes, but you don\u2019t want to navigate off<\/em>
    \nyour feature branch    2<\/sup><\/a>. One reason might be to avoid invalidating much of a
    \nslow-running incremental build.<\/p>\n
    Instead of using e.g. the worktree<\/code> functionality to create and checkout a
    \nwhole new working tree, we can use the \u201cpush to local\u201d to update whichever
    \npassive<\/em>    3<\/sup><\/a> head<\/code> that we wish.<\/p>\n
    git<\/code> provides the same branch protection rules as when pushing to remote
    \nrepositories. Which is to say that it denies non-fast-forward pushes by default,
    \nbut allows overrides through +:<\/code> refspecs, or the --force<\/code> and
    \n--force-with-lease<\/code> command line options.<\/p>\n
    Keep in mind that using these overrides are destructive and may lead to
    \ndataloss. Always create a backup branch with something like git branch
    \n <\/code> if you\u2019re not 100% certain you\u2019re in
    \ncontrol of what\u2019s going to get pushed.<\/p>\n
    Commit ranking ????<\/h2>\n
    Perhaps in need for something to serve as the year-end bonus rounds tie-breaker?
    \nWhat better way to settle the implicit battle between your peers of \u201cwho\u2019s
    \nproviding most value\u201d than by having a \u201cgit commit count\u201d showdown?<\/p>\n
    \n
    No, that\u2019s a horrible idea \u2026<\/p>\n<\/blockquote>\n
    Yes, yes it is. Any sensible developer knows that nothing good ever comes out of
    \nplacing merit in lines of code changed or number of commits committed.<\/p>\n
    But should you<\/em>, God forbid, ever be in need to know (for the sake of
    \ncuriosity) who\u2019s been committing the most to a repository, here\u2019s git rank<\/code>:<\/p>\n
    git shortlog -s -n --no-merges\n<\/code><\/pre>\n
    Configure it as an alias in ~\/.config\/git\/config<\/code> with:<\/p>\n
    [alias]\n  rank = \"shortlog -s -n --no-merges\"\n<\/code><\/pre>\n
    and simply run:<\/p>\n
    git rank\n<\/code><\/pre>\n
    As a quick example, behold, here\u2019s the horrendous output from my own dotfiles<\/code>
    \nrepository, where I\u2019ve been able to make commits under different names and
    \nidentities:<\/p>\n
    \u276f git shortlog -nse\n   567  Martin \u00d8in\u00e6s Myrseth <my*****<\/span>@***<\/span>il.com<\/span>>\n   322  Martin \u00d8in\u00e6s Myrseth <mm******<\/span>@***<\/span>co.com<\/span>>\n   142  Martin Myrseth <**<\/span>@**<\/span>me.no<\/span>>\n    14  Martin Myrseth <my*****<\/span>@***<\/span>il.com<\/span>>\n     4  Martin \u00d8in\u00e6s Myrseth <**<\/span>@**<\/span>me.no<\/span>>\n     3  Martin Myrseth \n     2  Martin \u00d8in\u00e6s Myrseth <my**<\/span>@***<\/span>le.localdomain<\/span>>\n     2  Martin \u00d8in\u00e6s Myrseth <my**<\/span>@*<\/span>ap.localdomain<\/span>>\n<\/code><\/pre>\n
    Cat file ????<\/h2>\n
    This is more of a git<\/code> party trick than anything to actually make much use of.
    \nBut I should say I have made use of git cat-file -p<\/code> on a couple of occasions
    \nto help people visualize<\/em> and actually grok git<\/code>\u2019s data model.<\/p>\n
    As the name hints at, the cat-file<\/code> command outputs information about git<\/code>
    \nobjects. I\u2019ve personally only used cat-file<\/code> with the -p<\/code> (pretty-print) flag,
    \nwhich first determines the type of the object before printing it out. Let\u2019s
    \nstart off with inspecting the HEAD<\/code> commit:<\/p>\n
    $ git cat-file -p HEAD\ntree 9491ada70010d722646b674d2e2a26521628df94\nparent 9d7e5a6490c9f560f54fee9e1af5d72429bb26c7\nauthor Martin Myrseth <**<\/span>@**<\/span>me.no<\/span>> 1665439490 +0200\ncommitter Martin Myrseth <**<\/span>@**<\/span>me.no<\/span>> 1665439490 +0200\n\nDelete Docker deploy action\n<\/code><\/pre>\n
    We see the main metadata that git associates with a commit: the repository file
    \nstructure (tree<\/code>), a parent commit SHA1<\/code> reference, author information and
    \nfinally the commit message after a blank line. Let\u2019s dig further by passing the
    \nSHA1<\/code> (9491ad..94<\/code>) of the tree<\/code> associated with the HEAD<\/code> commit:<\/p>\n
    $ git cat-file -p 9491ada70010d722646b674d2e2a26521628df94\n040000 tree 6d71faa5d70085c5d07228d8fa522fb712253b6d    .github\n100644 blob e09fe0dc282fdcaff06bcc6a9bbf57cbfc845eb4    .gitignore\n100644 blob da7e7945524871726071f919690c9c9f6c1e173d    README.md\n100644 blob e6be557357c3fe2e3cce6f1b7b9b3c9c55981a16    default.nix\n040000 tree 4f69a79c432cde80b4a1c486974b03cab84b45b9    docker\n100644 blob 2f8aacd9efa3cfdf9e5f2860fa7226b510ed83bc    feed-cors.conf\n100644 blob 14b9e2dd0a41aa932c1f4bb5938519547f37f82c    flake.lock\n100644 blob eeae336837db94ca62255a7e5fa7f32ae3363716    flake.nix\n100644 blob f1f8ef836b3b9b9ea011a43972a28ffaa713c868    image.nix\n040000 tree 5cad033d973f19ece938c33c3bb912eb63dc3305    site\n040000 tree 49dc35d8e519f02f6f1a647f437226af198d225a    ssg\n100644 blob 60dede4bba8cd9479b0bec49048da1397e14f352    todo.org\n<\/code><\/pre>\n
    The result of printing a tree<\/code> is what looks like a directory listing of the
    \ncontents of that \u201ctree\u201d directory. Each directory entry is represented as some
    \nmode bits, an object type, the SHA1<\/code> of the object and the name of the entry.
    \nTrees may contain other tree<\/code> objects to create a directory structure, or
    \nblob<\/code> objects which contain file contents.<\/p>\n
    Finally, let\u2019s inspect one of the blob<\/code> in the output, like .gitignore<\/code>
    \n(e09fe0..b4<\/code>):<\/p>\n
    $ git cat-file -p e09fe0dc282fdcaff06bcc6a9bbf57cbfc845eb4\n.stack-work\n_cache\npublic\ndist-newstyle\n.ghc.environment.*\n\n# nix-build\nresult\n<\/code><\/pre>\n
    Which prints out the actual content of .gitignore<\/code> the way it was committed
    \ninto the current HEAD<\/code> commit.<\/p>\n
    \n
    Wait? What? So everything is just text<\/em> files?<\/p>\n<\/blockquote>\n
    Conceptually, yes. However, modern git<\/code> does a lot more to optimize storage
    \n(re)usage and whatnot to ensure that a repository stays as small as possible.
    \nThere are other, scarier objects lurking under .git\/objects<\/code> in a git<\/code>
    \nrepository.<\/p>\n
    The git parable<\/h3>\n
    \n  
    As I said in the beginning of this section, I\u2019ve used cat-file<\/code> to help myself
    \nand others understand the git<\/code> object model. Learning all the details of that
    \nmodel isn\u2019t the purpose of this section (or post) though. However, if reading
    \nthis ignited some form of curiosity on your part I would gladly recommend the
    \ntalk \u201cThe Git Parable\u201d which dives deeper into the git<\/code> object model, as
    \npresented by my good friend     Johan Herland<\/a>:<\/p>\n
    It\u2019s painful to read, I know. Try to imagine the pain and embarrassment it is
    \nfor me to share it. And have you been unfortunate or careless enough to get
    \nyourself into a similar situation, please read on. I\u2019ll revisit this problem in
    \nthe     filter branch<\/a> section below.<\/p>\n