#829 open
elliottcable

Display 'git remote add Username' instead of 'git clone' in the header on repos you have a fork of

Reported by elliottcable | August 13th, 2008 @ 05:04 PM

Woah, long title. Pretty much says it all, though.

when looking at repositories that are forks of one you have a fork of, would it be possible that we could get an entry in the header that says 'git remote add Username git://github.com/Username/project.git' instead of 'git clone git://github.com/Username/project.git'? Because the assumption is that if you have a fork of the project, you surely already have a clone of said project - it makes a lot more sense to add this fork as a remote to your existing clone.

This would apply for projects you own that somebody else forked, projects you forked that they owned, and projects that you both forked from somebody else.

Comments and changes to this ticket

  • Tekkub

    Tekkub August 13th, 2008 @ 06:37 PM

    • → State changed from “new” to “open”
    • → Assigned user changed from “” to “Tom Preston-Werner”

    Actually, why not just provide both the clone command and the add remote command? Both could be useful.

  • elliottcable

    elliottcable August 13th, 2008 @ 06:43 PM

    Good point, tekkub. Sounds good to me (-:

  • Dr Nic
  • Dr Nic

    Dr Nic August 26th, 2008 @ 02:36 PM

    Hmm, I've thought more (perhaps for the worse) - if you have a fork, and you are a viewing a different fork; then you only need the "remote add" message.

    If you are viewing your own fork, you may have created it after already cloning a different fork (I do this all the time). You actually need "remote add " or something diff from "origin" since you've already got an origin.

    What local remote names are ppl using for their forks of other ppl's remotes?

    Typically, if I clone a repo, its "origin". If I then fork it, I'll add my repo as "drnic". I then create a branch in my repo and only work from branches (mostly so that pushing is easier).

    What are other ppl doing?

  • Tekkub

    Tekkub August 26th, 2008 @ 02:51 PM

    I personally use "origin" for my repo (thanks to git-clone), "upstream" for the repo I forked from, and usernames for any other remotes.

  • elliottcable

    elliottcable August 26th, 2008 @ 04:53 PM

    I follow the github gem standards - the primary remote (aka theirs if you don't have a fork, otherwise yours - even if it's a one-off fork) is origin, the rest are the same as their owner's username (even if they're the project maintainer / original repo owner).

  • Dr Nic

    Dr Nic August 26th, 2008 @ 05:00 PM

    So in your own fork, branches are elliottcable/master, elliottcable/somethingelse, etc and master -> root fork/master ? Nic

    On Wed, Aug 27, 2008 at 8:54 AM, Lighthouse support@lighthouseapp.comwrote:

  • elliottcable

    elliottcable August 26th, 2008 @ 05:04 PM

    Might not want to use Mail.app to reply to Lighthouse tickets... hehehe. I almost did, then decided against it.

    As for branches... I don't usually have to deal with remote branches. But it'd be origin/master for my fork, drnic/master for your fork, unless I had no personal fork, then it'd be origin/master for whoever was the project owner, and drnic/master for your fork.

  • Dr Nic

    Dr Nic August 26th, 2008 @ 05:07 PM

    What if you forked my foobar repo? master = mine (origin/master); elliottcable/master = your master; someotherperson/master = etc etc

    Or once you fork, don't you include the original root fork, or do you include it as a drnic/master remote?

  • elliottcable

    elliottcable August 26th, 2008 @ 05:35 PM

    The latter - if I've already cloned, and for some reason decide to fork, I will delete my existing clone, or (if I have local changes I don't want to delete) re-assign all remotes and branches so my upstream is origin/ and yours as the owner of the project that i'm forking is drnic/

  • Dr Nic

    Dr Nic August 26th, 2008 @ 05:51 PM

    ok; I was leaving "origin" for the root fork, since that is where all the good stuff is likely to be; and then using a sake task to refresh/re-pull into that, and then merge/rebase into my current branch. Because its consistent across all projects, I could use the same sake task. As a bonus, I didn't have to hack into my existing clone that I'd probably started committing to prior to realising I needed a fork etc.

    Its interesting the diff ways this can be all done.

    I started using github gem to pull down forker's commits; a nice simplifier.

Please Login or create a free account to add a new comment.

You can update this ticket by sending an email to from your email client. (help)

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Shared Ticket Bins