#27 feature
Aparajita

push/pull support

Reported by Aparajita | November 17th, 2008 @ 05:16 PM | in 0.8

It would be really nice if we could push/pull a branch, for example to synchronize with github.

Comments and changes to this ticket

  • Pieter de Bie

    Pieter de Bie November 18th, 2008 @ 02:50 PM

    • State changed from “new” to “open”
    • Assigned user set to “Pieter de Bie”

    I would very much like to implement this, but it will be a lot of work. I'm not sure when I'll be able to start working on it.

    You can help me out by making some sort of mockup on how you'd like pushing and pulling to work. If I have a clear concept of the GUI, the rest is somewhat easier :)

    For example, also take a look at http://github.com/pieter/gitx/wi...

  • Si

    Si November 18th, 2008 @ 06:01 PM

    I'd be happy with initial push / pull using the default remote only, since I'm probably using Git in a less decentralised way than most.

    I had a play with the UI as is, trying to get a feel for where I might expect to find push/pull, and think perhaps that the "History" view is best.

    It doesn't fit well with the current view naming, but I sense that it's best to have the overview of the repository to hand, rather than taking the git-gui approach of push functionality in the commit view.

    Might push / pull menu options work where there is currently "Delete remote branch" upon right clicking a branch "tag"?

    Default push / pull buttons in the toolbar would be nice for me personally. Perhaps these might work beside a drop down list giving available branches, so an alternate default could be chosen.

  • Aparajita

    Aparajita November 18th, 2008 @ 06:09 PM

    Assuming the sidebar is implemented, if a local branch is dragged to a remote, it would be a push. If a remote branch is dragged to a local branch, display a dialog asking if it's a fetch or pull.

    If you want to be a real hero, then you look in the config file to see if a remote branch is configured for a given local branch, then right-clicking on the local branch would display in the contextual menu, "Pull from " and "Push to ".

  • Joshua Emmons

    Joshua Emmons December 17th, 2008 @ 05:28 AM

    • Tag set to branch, fetch, pull, push, remote

    This may expose my flawed understanding of git, but wouldn't it make sense to initiate a push by dragging a (blue) remote branch? As I understand it, remote-tracking branches are supposed to be "read only" and always point to the state of the remote repository. If I were to drag a remote tag to a new commit I've just made locally, couldn't one assume that I want to send that commit to the remote?

    For that matter, couldn't a fetch be initiated by right-clicking on one of those remote branches and selecting "fetch" or "pull" or some such?

  • Pieter de Bie

    Pieter de Bie December 17th, 2008 @ 10:24 AM

    The problem with providing 'fetch / pull' options in that context menu is that you don't fetch only a single branch -- you usually fetch a complete remote.

    In the same way, you usually want to pull a default branch, rather than pulling a specific branch, which would be somewhat similar to a merge.

    If you support pushing by using drag and drop, you don't get any benefits of the default push rules -- pushing all similar named branches, which is what users expect, rather than having to figure out themselves which branches to advance and how.

    I think for push/pull support that isn't confusing, you pretty much will need some kid of explicit support of remotes in GitX.

  • Joshua Davey

    Joshua Davey March 13th, 2009 @ 10:57 PM

    Aparajita had an interesting point here. No matter the UI, a sidebar seems almost necessary.

    Another UI idiom that could be useful would by the "sync", a la iPod/iTunes. If used in conjunction with the sidebar, the remote branch views would include a config page or pane for setting which local branches should sync to which remote branch. It is most common for branches to be named the same on the local and remote repositories, i.e. master and origin/master, develop and origin/develop.

    The whole concept of a OSX GUI assumes an easy-to-use, if not simplified, use of Git. Only allowing a local master branch to be "synced" with a tracked remote branch of the same name would be user-friendly.

    Clearly the "sync" metaphor breaks down, as two repositories hardly ever have the same history/commits/objects, but it may be one dead-simple way to add push/pull support.

    Again, if that doesn't work, menu items "Push to..." and "Pull from..." would be great.

  • Taylor luk

    Taylor luk April 27th, 2009 @ 08:18 AM

    Looking forward to see this implemented, even if it only supports the default origin and incrementally supports multiple branch/origin

  • mudx

    mudx May 1st, 2009 @ 03:06 AM

    I would like to get this feature added quickly... I would be willing to pay $150 for whoever implements this feature into the next version. Contact me if you want to take me up on the offer.

    I'm going to be looking for a gitx alternative in the mean time.

  • Pieter de Bie

    Pieter de Bie May 1st, 2009 @ 11:27 AM

    If you want to go that route, I'd suggest specifying a bit more clearly what you want for you money.. Only pushing / pulling the default branch? How about only the current branch? Does it have to have a nice GUI, or some options?

    Also, you might want to put your offer up on Twitter or somewhere. I'd still like to do this, but I don't have the time.

  • Tony Guntharp

    Tony Guntharp May 14th, 2009 @ 10:48 PM

    I'll second the notion about paying for push/pull support even if it's just for the current branch. I understand the Sidebar questions and I believe that Versionsapp is a good reference to go off of.

  • Johannes Gilger

    Johannes Gilger June 2nd, 2009 @ 12:05 AM

    Just wanted to see if there is still interest in this feature, and if so how to do it best.

    Right now I have the following working:

    GitX Push

    It supports pushing of branches to "origin" and can only detect if the push failed or not (i.e.: has no debug output). I could easily add a button for "fetch origin" or something like, but there are so many ways to do this wrong that I'd thought I'd ask again. The button in the toolbar pushed to the currently-selected branch in the dropdown.

    And no, the commit is not yet in my public branches, because it still needs cleaning up.

  • Johannes Gilger

    Johannes Gilger June 2nd, 2009 @ 05:26 PM

    I've written a second patch which is a step into the direction of fetch-support. It enables you to select a ref and click "forward the currently checked out branch to this ref if the resulting merge is a fast-foward merge". Unfortunately git merge doesn't have --ff-only yet, which is why I have to check this manually.

    GitX ff (Here you can see me trying to fast-forward the current branch "master" to branch "test", which would work).

    These two patches however would enable the following workflow:

    1. Push if the push is fast-forward
    2. Fetch "origin"
    3. Manually fast-forward local branches to certain tags/branches

    Not quite sure what's most important next ;)

  • Tass

    Tass June 4th, 2009 @ 02:25 AM

    This would be more than just useful to me, it would complete my developing environment, leaving me with two good tools for two different purposes;

    vi - My text editor of choice for programming
    GitX - For handling my GIT repository/ies

    I'm stoked to try this feature out as soon as you release it in whatever form you choose!

  • Johannes Gilger

    Johannes Gilger June 4th, 2009 @ 06:36 PM

    Yeah, well, I know it's needed in order to work without the console (to some degree, but never completely), but what I want to know is how to do this best:

    1. Does the remote "origin" suffice for the beginning?
    2. Can I expect users to set push/fetch refspecs in their config? (Especially the push-case is important)

    Unless you only use "pull" to track a branch and never commit anything yourself you'll be fine, but as soon as it comes to merging (non-ff-merges) you'll have to use the terminal anyway.

  • Tass

    Tass June 4th, 2009 @ 06:43 PM

    I don't mind having to do work-arounds, I'm used to having to use the console exclusively as a former Linux-only user for the I don't know how many years until I got my mac. So to answer your questions:

    1. Yes, origin is perfectly fine to start out with, I don't use any other repositories right now even, so it works very well.
    2. As I said, if I need to do workarounds, that's 100% fine by me, it's not a lot of work from my side to edit some config files.

    Those are the two most essential features, and I think it will get people good to go in a lot of cases, and for the more advanced tasks, the terminal always works, and moving away from the terminal is perhaps a long-term goal for this, and something one can develop in the future.

    Cheers!

  • Si

    Si June 4th, 2009 @ 07:34 PM

    From my perspective

    1) Yes
    2) You could expect me to!

    Exciting to have progress on this. Great stuff.

  • Johannes Gilger

    Johannes Gilger June 4th, 2009 @ 10:59 PM

    Hi guys, I'm getting to the point where I might release a testing-build or at least let Pieter have a look at my progress without being completely embarrassed. Two screenshots and a few words about them:

    GitX

    The two buttons in the toolbar will execute a "git push origin" and "git fetch origin" without any arguments. Right-clicking on a local branch/tag and using "Push branch" will issue "git push origin <branch>".

    GitX

    Right-click on a remote-branch enables to issue a "git fetch <remote>" and "git push <remote>"

    Updating local heads to match those newly-pulled changes can be done by dragging-and-dropping of the local tags (I just found that out myself), so we should have covered the most basic use-cases.

    Comments?

  • Johannes Gilger

    Johannes Gilger June 4th, 2009 @ 11:22 PM

    • Milestone set to 0.8
    • Assigned user changed from “Pieter de Bie” to “Johannes Gilger”
  • halbtuerke

    halbtuerke June 5th, 2009 @ 12:06 PM

    Looks great! I will happily provide feedback when there are test-builds available.

  • Tass

    Tass June 6th, 2009 @ 07:19 PM

    Exceeds my hopes, looking forward to try it out!

  • Pieter de Bie

    Pieter de Bie June 7th, 2009 @ 02:49 PM

    Just a few pointers:

    You can take a look at man git-parse-remote, and the script itself for
    some pointers for refspecs. Reading the script itself might also give
    you insights. I guess the correct way to do this is to call
    git-send/receive-pack ourselves. git-pull is just a shell script, so
    you can get some info from there on how to call it.

    There's also git-for-each ref's %(upstream) in newer git's, which
    should give you a clue what you're merging exactly. I think that only
    works with git v1.6.3, and we can't really expect everyone to have
    that. If you want, you can limit push/pull support to v1.6.3 or higher
    only.

  • Johannes Gilger

    Johannes Gilger June 11th, 2009 @ 10:54 AM

    I can understand the need to use plumbing where possible, but I'm getting the feeling that this gets really messy when fetching/pushing. For example:

    "git fetch" first parses the remote, parses the refspec, calls fetch-pack with the remote refs, and then after the new packfile has been downloaded forwards the first part of the refspec to matching commits in the new pack (it got the output for that from git fetch-pack). And that's just fetch, no merging with local branches yet. All the important output of these commands goes to STDERR, which is why the Pipe would have to be rewritten/extended.

    Now, the second "big" problem UI-wise is to make fetch/push threaded, so it doesn't block the whole application.

    Don't expect anything soon, the state this is in now is not worth releasing IMHO. And please don't reply by telling me that you'd be happy to try it out...

  • Frank Dekervel

    Frank Dekervel June 16th, 2009 @ 11:43 AM

    fyi qgit (http://digilander.libero.it/mcostalba/) has a very low-tech approach to this, which works rather well for me: it is possible to define "external commands" (which are actually just shell scripts). in addition from pushing and pulling to/from the default remote, i can preconfigure qgit so that it has some very usecase-specific actions.

  • Lucas Neves Martins

    Lucas Neves Martins July 27th, 2009 @ 10:37 PM

    Is there any kind of "mail me" when done by ticket?

    I really want to try out stuff when its out, but it's kinda boring checking out the lighthouse every page and every day.

  • vlovich

    vlovich October 4th, 2009 @ 01:27 AM

    Here's my take of how I would like the UI:

    gitx push pull mockup

    The idea is that if you want to push, you drag the local repository the remote one. If you want to pull, you drag the remote repository onto the local one. If you want to rebase, you hold down shift while doing the drag.

    If you drag a particular commit onto a branch, that cherry-picks that commit into the branch.

    Thanks

  • vlovich

    vlovich October 4th, 2009 @ 01:31 AM

    Sorry to clarify - when you select the branch in the side bar it shows the commit history from that branch (the drop down can probably be removed).

  • Morgan Schweers

    Morgan Schweers October 26th, 2009 @ 01:20 AM

    Greetings,

    I have nothing to do with the sidebar stuff as it's not in the gitx branch on github, but I've implemented push, pull (via rebase, but this should probably be configurable), and fetch. They are implemented as toolbar icons and operate on the currently selected branch, or all branches if the currently selected branch doesn't have a remote.

    I added a few basic push/pull operations to the context menu of branches that have remotes.

    I also made a rudimentary clone operation in the File menu. (Rudimentary because there's no progress bar, or anything, while the clone is happening. :( )

    http://github.com/cyberfox/gitx

    It's probably not the way other folks would implement it, but I had an immediate (like tomorrow) need to give a non-developer pull/commit/push access to a git repository, and they NEEDED a GUI tool, being fundamentally command-line phobic.

    I used some nice icons from a GPLed project, and stuff like that. Check it out; it's a quick solution to the problem. If you're in need of GitX supporting push/pull, give my version a try. It might just be good enough.

    -- Morgan Schweers, CyberFOX!

  • Morgan Schweers

    Morgan Schweers October 26th, 2009 @ 07:57 AM

    Greetings,
    Just took the time to read through the comments in detail. Heh, @mudx & @Tony, I'd love a few bucks for implementing it. :)

    So, a few things. When pulling up the context menu on branches that are tracking a remote, it shows push, pull (i.e. with merge), and rebase. It doesn't show fetch because I wasn't thinking about that when I did the first pass changes. If you pull up the context menu on branches that AREN'T tracking a remote (I check config:branch.{branchName}.remote to be non-nil), they are grayed out. (My recollection of the Mac UI guidelines suggests that menu entries shouldn't appear and disappear based on the underlying data, they should be disabled; it allows for muscle memory as to where menu items are.)

    The toolbar icons use the currently selected branch (in the drop-down), and look for the appropriate remote to do their work on. If there isn't a remote, as in the case of 'all branches', it behaves as if you gave a global operation ('git push', 'git pull --rebase', or 'git fetch'). This will fail for pure-local repos, which I suppose should be handled by disabling the toolbar icons.

    Still, this is really nice for git fetch, since if you have 'All branches' visible, git fetch will show where your origin moved to. You can peruse the changes, and then do the rebase.

    I picked rebase as the default operation in the toolbar because it's what I'm going to have the non-developer use; itch:scratched. They're never likely to be in a situation where rebase is the wrong choice. I should add another toolbar entry which is just 'Pull' with the assumption it does a merge (like the one in the context menu), and make it one you can configure your toolbar with. I just ran out of time this weekend.

    I'm a really crappy Objective C programmer. I usually work in Java, Ruby, C++, etc., so if I'm abusing coding standards, or other stuff, please feel free to let me know.

    I've never touched GitX before Friday, so if I'm abusing some UI expectations of the application, also please let me know.

    I don't have a good answer for user experience doing long-running processes like clone. For the toolbar operations, I disable them while the operation is going on (checking that in, in a few minutes). This gives some feedback, at least. I was thinking about throwing up a dialog box with an indeterminate progress bar to show that something's going on, since PBEasyPipe isn't asynchronous. Ooh, maybe with a sound effect on completion! ;)

    I'm sure there are folks who are working on making GitX a lot more powerful; I just want it to be easy for the graphic designers to use, so keep that in mind when judging the Q&D nature of my code.

    Hope this helps,

    -- Morgan Schweers, CyberFOX!

  • halbtuerke

    halbtuerke October 26th, 2009 @ 08:27 AM

    Hi Morgan,

    I just tried to build your fork but it fails with these error messages:

    @@@ The following build commands failed: GitX:

    Ld /Users/patrick/Coding/Xcode3.2/gitx-cyberfox/build/GitX.build/Release/GitX.build/Objects-normal/ppc/GitX normal ppc
    Ld /Users/patrick/Coding/Xcode3.2/gitx-cyberfox/build/GitX.build/Release/GitX.build/Objects-normal/i386/GitX normal i386
    

    (2 failures)"

    Undefined symbols:
    "_git_oid_allocfmt", referenced from:

      -[PBGitCommit parents] in PBGitCommit.o
      -[PBGitCommit realSha] in PBGitCommit.o
    

    ld: symbol(s) not found
    collect2: ld returned 1 exit status @@@

  • Morgan Schweers

    Morgan Schweers October 26th, 2009 @ 08:59 AM

    Greetings,
    I'm using a more recent libgit2 which I imported into the app; for whatever reason the submodule didn't work for me. (Again: crappy Objective C developer. :) ) Let me see if I can't figure out how to fix that...Okay, I think I've updated the submodule to use the real libgit2 repo.

    For what it's worth, the only two changes pieter has in his repo that are different than the base repo aren't relevant. (Specifically, a hex conversion routine which has been adapted (and my changes use the adapted version), and a thread-local-storage fix which appears to not be relevant for Mac OS X.)

    So I think it's best to use the actual libgit2 repo...

    Pull and build again, and let me know!

    -- Morgan Schweers, CyberFOX!

  • Morgan Schweers

    Morgan Schweers October 26th, 2009 @ 09:10 AM

    Greetings,

    Specifically I'd clone into a fresh directory, open GitX.xcodeproj, and try and build (I just did that, and it worked); I really have no idea what happens to git if you swap out a submodule repository when the submodule is cloned already into the directory. I'd like to believe it does something sane, but it's not something most people probably do.

    -- Morgan Schweers, CyberFOX!

  • halbtuerke

    halbtuerke October 26th, 2009 @ 09:37 AM

    Thank you very much for fixing this so fast. Now it worked as expected.

  • brotherbard

    brotherbard November 19th, 2009 @ 08:32 PM

    • Tag cleared.

    I've been working on adding some features that are based on Morgan Schweers code.

    Checkout, Fetch, Pull, Rebase, Push, and Cherry Pick are working (I'll be adding Merge soon). These are in the main menu, toolbar items with drop down menus, and the contextual menus (both on ref and on commits) as appropriate for the command.

    The toolbar items work on the default remote if you click on them once, if you click and hold a menu will drop down to allow you to select a particular branch/remote/tag for that command.

    I ended up basing my fork on André Berg's which has a bunch of 10.6 stuff added, so this currently only works in 10.6. But I will be putting it into a mainstream branch in the next few weeks.

    It's at: http://github.com/brotherbard/gitx

    I just found this ticket, and after reading through it I think I need to make a few changes (commands that work with remotes only current only offer selection of individual branches, should allow selecting all branches).

    Let me know if you have any comments/suggestions/bug reports.

    --Nathan Kinsinger (brotherbard)

  • brotherbard

    brotherbard November 19th, 2009 @ 08:38 PM

    • Tag set to branch, fetch, pull, push, remote
  • brotherbard

    brotherbard November 19th, 2009 @ 11:01 PM

    Here is a screenshot of my additions.
    alt text

  • Dave Grijalva

    Dave Grijalva March 13th, 2010 @ 02:27 PM

    • State changed from “open” to “feature”
  • brotherbard

    brotherbard March 17th, 2010 @ 02:16 AM

    I have an updated branch with nicer push/pull support along with many other features at: http://github.com/brotherbard/gitx

    Look on the wiki page http://wiki.github.com/brotherbard/gitx/ for an updated screenshot.

    If you have the time this branch could use some testing and feedback.

  • Pieter de Bie

    Pieter de Bie March 17th, 2010 @ 08:33 PM

    [I'm CC'ing the list on this so that everybody is notified of this branch's existence]

  • danmurphy

    danmurphy October 2nd, 2017 @ 05:50 PM

    Westnet, a subsidiary of iiNet Limited, was founded in the city of Geraldton, Western Australia in 1994, with a simple goal - provide no-nonsense and good-value ...

    iinet

  • Jennifer Brownz

    Jennifer Brownz February 18th, 2018 @ 10:54 AM

    Those keys are used a lot in OS X, for example for jumping to the start/end of a line, so I'm not going to change them :)
    I might change the command-1/2/3 that are currently used in the History view to switch the history/commit views instead. I think that's a more common case than switching the history-specific case.
    download soundcloud to mp3 320kbps

  • Robertams

    Robertams April 12th, 2018 @ 01:05 AM

    Very healthy discussion on Pull/push support project. We can read the complete outline of the project as above. Some friends has suggested good direction to make this project successful. However, I need review writing service but there is good information about different projects in this website.

  • Dany L
  • McManis147

    McManis147 August 10th, 2018 @ 07:30 AM

    Push the currently checked out branch by clicking Push in the main toolbar, or by right clicking on the branch, and selecting Push. Pushing attempts to upload any new commits to the remote branch, then fast-forward the remote to bring it up to date with the local repo. MYBKExperience

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

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

GitX is the nice-looking gitk clone for OS X

Pages