How do you send code review requests with git when devs do not have public work repositories?

Normally in Git, each developer will clone from the origin into a personal tracking repo, make some changes, then send a fetch request to the manager referencing his personal machine which has a git-daemon, or web server, or allows the manager to connect to it with ssh.

For some changes its alright for the dev to check in stuff himself. For larger ones, other people like to look at it before it gets checked into master. So the dev does have the privilege to check into the repository.

  • Handling outdated dependencies in Gerrit
  • Git diff tool over several commits with other's commit inbetween
  • ReviewBoard with git. “There don't seem to be any diffs!” but there are
  • Git, Code Reviews, and Bug Tracking
  • How do you find who merged a git commit into a branch?
  • How to do code review for google cloud git repo
  • But what if the manager couldn’t connect to other devs work machines, and only had access to the origin git repo, or email? What is the best way to send the diffs to him for review?

    We could send patches in an email or the dev could push his branch out to origin and tell the manager to git fetch origin; git diff master..case223. Or is there another better way?

  • Pull request to julia package
  • Way to modify git pack files?
  • Separate branches or git projects?
  • gitignore not ignoring file
  • Tell git to ignore my RSA public key
  • how to interact with two beaglebone black connected to one computer
  • 5 Solutions collect form web for “How do you send code review requests with git when devs do not have public work repositories?”

    I would use

    git format-patch <branch-to-compare-against> --cover-letter -o patches/
    

    which will essentially create the appropriate patches for your commits
    and then

    git send-email --to <receiver@example.com> --annotate patches/*
    

    Check the man pages:

    • format-patch
    • send-email and the example section

    Git bundle

    git bundle create myproposal.git origin/sharedbranch..HEAD
    

    You can receive it as if it were a repo:

    cd myworktree
    git pull /tmp/myproposal.git
    

    Incidentally, git bundle is also the most effective way to backup your entire repo, e.g.

    git bundle create /tmp/backup.git --all --tags --remotes
    

    Allow the devs to push to certain branches on the same repo. Use gitolite to administer who has what kind of access to what branch. No need to email stuff back and forth.

    UPDATE: since then, I’ve written this article: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

    Hope this helps.

    Shameless advertisement: I suggest you also to consider Gerrit.

    We use it for our code reviews, and it’s an amazing tool (especially the possibilities for access rights). With that, every developer here can push his changes into the review branches (and only there), and the other developers can review the changes (they are also automatically built and tested by Jenkins and get verified if the tests were successful).

    In your case you would have the right for the manager to submit a change into the repository, we enabled it also for the developers and made only a workflow restriction, that two developers have to review a change to submit it.

    Note: in addition of git send-email, you can use the git contacts contrib script, to list potential contacts interested by your email.

    With Git 2.14.x/2.15, that script also detects the “Reported-by” section.

    See commit 09ac673 (21 Jul 2017) by Eric Blake (BlakeEric).
    (Merged by Junio C Hamano — gitster — in commit 6d2b8a3, 11 Aug 2017)

    git contacts” (in contrib/) now lists the address on the “Reported-by:” trailer to its output, in addition to those on S-o-b: and other trailers, to make it easier to notify (and thank) the original bug reporter.

    git-contacts: also recognise “Reported-by:

    It’s nice to cc someone that reported a bug, in order to let them know that a fix is being considered, and possibly even get their help in reviewing/testing the patch.

    Of course…

    • S-o-b: means Signed-off-by:
    • trailers, formalized in 2014 are the other part of the commit (Signed-off-by|Reviewed-by|Acked-by|Cc)
    Git Baby is a git and github fan, let's start git clone.