Git Flow Integration about gitsavvy HOT 24 CLOSED

👍

from gitsavvy.

This would be indeed very nice.

from gitsavvy.

Any ideas on how this should be implemented UI-wise?

Maybe something similar like the current status view?

from gitsavvy.

@TheHippo Yeah that would be a good way of doing it or commands in the command palette.

from gitsavvy.

@wldcordeiro @TheHippo - a new git: branch dashboard is in master and will be landing in the next release. Do you think this would be an appropriate place to include git-flow features?

from gitsavvy.

@divmain The git branch dashboard looks good. 😊

I think it would be better to have git flow on its own dashboard, because:

• Although git flow is basically just juggling with git branches it is different from using git branches since branches have a certain context (release, feature, etc.)
• Users who don't use git flow probably could become confused having some git flow terms on the branch dashboard.
• The dashboard could be entirely hidden, if git flow is not initialized.

In a addition to the dashboard it would be nice to have some additional command in the Sublime command palette. (e.g.: git flow: start new feature, git flow: finish release)

from gitsavvy.

Alright, so ideally this issue includes:

• git flow: FEATURE OF GITFLOW palette commands
• git flow: dashboard with similar layout to branch view but with flow-specific context and key-bindings

That works alright for me. Since I'm only casually knowledgable of git-flow, if you have ideas specifically wrt what the dashboard might do/look like, I'd find that very useful.

from gitsavvy.

The palette commands would be good for like 90% of the usage.

The dashboard could should a list of all currently started features, releases, hotfixes and support branches. Other than starting and closign these it should be possible to push a single feature/release/etc. (git flow feature publish feature_name) or pull a feature/release/etc from a remote (git flow feature track feature_name)

from gitsavvy.

@TheHippo publish and finish are different from each other. When you start a feature it's local to you, publish will actually create a remote branch to match. Finish will merge into develop and remove the feature branch

from gitsavvy.

Personally, I would like to see git-flow in the git: branch dashboard. I've been thinking of a nice and useful interface for git-flow, and I keep wanting to see a view which would show me where master and develop and other branches are in comparison.

I suggest adding an [F] "git-flow toggle" in the dash, similar to [e] for remote branches. The git-flow toggle will band together the git-flow specific branches (feature/, release/, hotfix/ and so on - the exact naming of these would need to be looked up per repo: a helper command would come in-handy here).

A command to start/finish/publish/track can be run from this dashboard, for each git-flow branch according to context (by location of cursor?). The only thing is that the dash is starting to get a bit crowded with commands.

Here's a dash mockup:

from gitsavvy.

@asfaltboy It may be possible to test for the existence of Git Flow and only show that part of dashboard if it's installed?

from gitsavvy.

Oh yes, absolutely. Since the branch interface is a command, we can simply check for return code of running git flow and if no errors, amend the "git-flow" template to the current template.

I've also looked a bit into git-flow implementation, and it seems the branch structure are stored in git config (after initial run of git flow init), so we can query those settings for the branch prefixes.

And we should probably also add the init command for complete coverage.

So, to conclude, I went over all possible git flow command combinations and here's a checklist with the current features we ought to implement; guys, please tell me if I missed anything or got something wrong:

Interface addition/changes

• Create new interface or conditionally concatinate git-flow interface to template in branch.py (if git-flow installed). Listen to registered key presses and run matching init/workflow/remote commands below; optionally, passing the branch name from cursor location / current branch (need to decide which is more useful).

Management commands

• GSGitFlowSettingCommand: Internal command (i.e does not need to be exposed to user) to check if git-flow installed and fetch it's settings
• GSGitFlowInitCommand: run git flow init -d to initialize settings.GSgitflow with branch prefixes. The -d argument is needed to prevent git flow setup wizard (not sure if can be easily implemented?). We can advise in docs to run git flow init manually if user wants to customize the branch prefixes

Workflow commands

• GSGitFlowFeatureStartCommand: Prompt for feature-name and run `git flow feature start
• GSGitFlowFeatureFinishCommand: Verify we are on feature branch and run git flow feature finish or prompt for optional if we're not
• GSGitFlowReleaseStartCommand: Prompt for release-name and run `git flow release start
• GSGitFlowReleaseFinishCommand: Verify we are on release branch and run git flow release finish or prompt for optional if we're not
• GSGitFlowHotfixStartCommand: Prompt for hotfix-name and run `git flow hotfix start
• GSGitFlowHotfixFinishCommand: Verify we are on hotfix branch and run git flow hotfix finish or prompt for optional if we're not
• GSGitFlowSupportStartCommand: Prompt for support-name and run `git flow support start

Remote commands

• GSGitFlowPublishCommand: run git flow <btype> publish <name>; where is one of feature/release/hotfix and name is optional if we're currently on a supported branch.
• GSGitFlowPullCommand: run git flow feature pull <feature-name>; where name is optional if we're currently on a feature branch.
• GSGitFlowTrackCommand: run git flow <btype> track <name>; where is one of feature/release and name may optional if we're currently on a feature/release branch.
• GSGitFlowCheckoutCommand: run git flow feature checkout <name> where name may optional if we're currently on a feature branch.
• GSGitFlowDiffCommand: run git flow feature diff <name> where name may optional if we're currently on a feature branch.
• GSGitFlowRebaseCommand: run git flow feature rebase <name> where name may optional if we're currently on a feature branch.

from gitsavvy.

I am a bit concerned that the branch dashboard will get too cluttered with this. Is there any reason why this couldn't become its own git-flow dashboard? There could be a hotkey to open the branch dashboard, in case the user wanted to take non-standard action (from the git-flow perspective).

As a slightly pedantic implementation detail, the commands should be namespaced and prepended with GsGitFlow... or GsFlow.... It is more verbose, but Sublime doesn't have any mechanism to avoid command name collisions between plugins.

from gitsavvy.

Agree on both points.

1. A separate command is nice, default status can also display head of master/develop.
2. Avoiding command name collisions is smart (updated commands in todo list above).

from gitsavvy.

I think it is better to have a separate view/interface for git flow and create some easy way to open the other views. We could create short-cuts like
super+g, f -> Git Flow
super+g, s -> Git Status
super+g, b -> Git Branch
super+g, r -> Git Rebase

from gitsavvy.

@stoivo separate view it is!

There's also a "tags" view .. and by the way shortcuts like those you mention can easily be added to your sublime-keymap. In case you didn't yet, here's how:

[
  //  ... other shortcuts
  {"keys": ["super+ctrl+g","super+ctrl+s"], "command": "gs_show_status"},
  {"keys": ["super+ctrl+g","super+ctrl+b"], "command": "gs_show_branch"},
  {"keys": ["super+ctrl+g","super+ctrl+t"], "command": "gs_show_tags"},
  {"keys": ["super+ctrl+g","super+ctrl+r"], "command": "gs_show_rebase"},
  // and in the future -> {"keys": ["super+ctrl+g","super+ctrl+g"], "command": "gs_show_flow"}
]

from gitsavvy.

I'd like to stick with the command palette for opening new dashboards. There are enough plugins and enough possible key-bindings collisions that I want to keep those to a minimum, except in cases where we are offering an interface to the user. Folks can add their own custom bindings to suit their needs, as they'll know what other plugins are installed and what might conflict.

from gitsavvy.

Agreed with that @divmain there's already way too many key-binding collisions out there a dashboard like the mockup @asfaltboy made would be wonderful.

from gitsavvy.

@asfaltboy, is this something you'd like to try adding yourself? It seems you have an idea for how to split it up, and so far I have no objections to your design decisions.

from gitsavvy.

Definitely would like to dive in, trying to squeeze it in my agenda.

from gitsavvy.

Apologize for dawdling, I've just made a bit of progress on the required commands, but the pull-request is not yet done. Details on progress in the PR.

from gitsavvy.

I feel like the feature commands checkout, diff and rebase are pretty much useless since they can as easily be done without git-flow (and have a good implementation in GitSavvy)...
@wldcordeiro @bobbyrenwick @TheHippo @stoivo do any of you use these and can provide a use case?

from gitsavvy.

@asfaltboy I don't use any of those commands! I think you're probably right about them being easy to do outside of git-flow. Maybe that could be said about git-flow in total though.

from gitsavvy.

Yeh you're right, it's basically just adding prefixes and renaming builtin commands (with a tiny bit of constraint logic thrown in). Well, if no one uses these I won't bother implementing for now.

from gitsavvy.