1. 40
  1. 5

    For the ‘transfer repo’ use case, you can just tgz the repo (which will include the .git dir and thus the whole history).

    I didn’t know you could use a bundle to package changesets though - that’s really useful.

    1. 1

      There used to be a bunch of explosions if you did that to a repository with submodules, iirc; have those been fixed?

      1. 2

        Sorry, I don’t know. Can you recall anything more about the problem case?

        Tarring up a dir in one place and untarring it somewhere else is functionally just a copy (or move if you don’t use the old one) i.e. it’s the same as ‘mv repo new_repo’.

        I can’t see how that can break unless it is related to the per-user settings? (e.g. someone using ssh based remotes and the new user not having ssh creds).

        So yes - I can see how copying the repo as I described doesn’t remove any remotes (including submodules), which could cause some confusion.

        1. 2

          Should have done some research on my own before I asked, sorry! Looks like the last time this bit me I was really unlucky; it’s a problem that only affected two minor versions of git.

    2. 3

      I asked an applicant to a job posting I had open to complete a short 30-minute coding exercise when they didn’t have any public code available. Really, they had no Internet presence except for a barebones LinkedIn profile.

      They provided their code test result as a git bundle and specifically called attention to their commit history. I was thoroughly impressed. It was like they’d memorized Deliberate Git, my favorite talk about git etiquette. Their code was great and the story the commit messages told was enlightening. They got an interview.

      1. 1

        They got an interview.

        Typo?

        1. 2

          Why? Singular they is a thing.

          1. 1

            When you don’t know their identity (see what I did?). “Whoever broke in cleaned their tracks”.

            It causes confusion when used in cases like this.