Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding Push, Pull, and Remotes- A Roadmap #234

Closed
5 tasks done
tgeorgeux opened this issue Oct 9, 2018 · 12 comments
Closed
5 tasks done

Adding Push, Pull, and Remotes- A Roadmap #234

tgeorgeux opened this issue Oct 9, 2018 · 12 comments

Comments

@tgeorgeux
Copy link
Contributor

tgeorgeux commented Oct 9, 2018

This post is to explore the implementation of the push and pull functionality, as well as the implications that functionality has for remotes. In the interest of keeping this extension as simple as possible, we're looking at implementing

Stage 1 - Introduce Push/Pull functionality

  • Add 'Push,' Default (Origin unless otherwise changed)
  • Add 'Pull,' Default (Origin unless otherwise changed)

Stage 2 - Introduce remotes

  • Add 'Pull from,' existing remotes (manage remotes in the command line)

Stage 3 - Allow pushing to remotes and

  • Add 'Push to,' (Allow users to specify which remote to push to)
  • Add UI functionality to add/remove remotes.
@tgeorgeux
Copy link
Contributor Author

tgeorgeux commented Oct 9, 2018

@weihwang @Jaipreet We're thinking about where to place the Push and Pull buttons. This conversation surfaced the fact that when you checkout another branch, that also defaults to exposing which remote that branch is 'pointed' to. Is it going to be possible to even have the notion of pushing and pulling without the notion of which remote you are pointing to?

I ask because it seems like if somebody had a repo (with remotes) set up on their hard drive, and they linked the Git extension, it may immediately break. There's also an issue of credentials associated with this.

Let me know what you think!

@dhirschfeld
Copy link
Member

I'm a bit agnostic to GUI interfaces for operations such as push/pull etc as the terminal's available and is more powerful/flexible.

The value for me in a GUI git interface is knowing exactly what has changed. In this respect the VSCode diff-view is pretty close to perfect IMHO. All files which have changed are listed and clicking on any of them brings up a great diff view which you can edit. From the listing you can choose what to stage, including highlighting particular lines from a file and only staging them.

Sorry, this is a bit OT for this issue. I guess my point is there are higher value-add improvements than putting a huge effort into what can already be accomplished in the terminal. Some effort and basic functionality sure - that would also be useful for my git-inexperienced users.

@tgeorgeux
Copy link
Contributor Author

@jaipreet-s If you want to weigh in on what your priority will be in this issue I'll update the checklist for easy reference.

@jaipreet-s
Copy link
Member

I think one thing that I'd like to be listed out in all the stages is what branch we'll be pushing/pulling from

@weihwang
Copy link

weihwang commented Oct 11, 2018

https://www.figma.com/file/UyNpeQNuTj6Uv74MoEJDh3ji/Git-extension?node-id=507%3A1156

@tgeorgeux I have few proposals in the mockup above I'd like to get feedback on.

Issues I am trying to address:

  • Surface both current and target branches for push/pull actions
  • A settings gear icon to add remotes if needed and change targets.
  • simplify access to history as another section called "commits" that avoids the need to toggle across history, and a smoother transition to "view more" history in the terminal.
  • Testing a top-down organization that moves changes through staging to commit to history.
  • A fly-out proposal for viewing more details of the commits if needed, or to have the action to view diff of the commit.

@ellisonbg
Copy link
Contributor

Can we add the points here to the roadmap?

@ellisonbg
Copy link
Contributor

@weihwang thanks for posting these mockups! I will start to review them on Figma. In the future, could you:

  • Open a separate issue for each mockup.
  • Post screenshots in the GtiHub issue to make it easy for people to review (if they aren't on Figma)
  • As you have done provide a link to the Figma file.
  • It will also be important to have a written description of the design, to help people understand the goals.

See this issue for a description of these things:

#233

@weihwang
Copy link

@ellisonbg thanks for the feedback. I will move the comment updates above into separate issues.

@tgeorgeux
Copy link
Contributor Author

This roadmap is a bit dated, @jaipreet-s @weihwang you guys want me to update to what you're doing or close this issue as it seems to be tracked elsewhere?

@weihwang
Copy link

The issues handle individual features, which may or may not be dependent on each other. I try to call it out when it's relevant. I think we still need a larger story tracked somewhere.

@jaipreet-s
Copy link
Member

I'm tagging this to the 0.5 milestone. We'll likely break this down to remove the stuff immediately out of scope.

@fcollonval
Copy link
Member

Solved by #1146

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants