[MonoDevelop] Git add-in
"Andrés G. Aragoneses"
knocte at gmail.com
Wed Jul 28 19:04:47 EDT 2010
Agreed in general with all opinions from Lluis. Just a couple of
El 28/07/10 20:07, Lluis Sanchez Gual escribió:
> El dc 28 de 07 de 2010 a les 10:41 -0400, en/na Dale Ragan va escriure:
>>> So the Git add-in can be used pretty much like the Subversion add-in.
>> The only big difference is that changes have to be explicitly pushed to
>> the remote repository using the Push command. Feedback about how to
>> improve this workflow is welcome.
>> I see you are finding the issues that I was faced with when I started on
>> this venture. I'm glad you're back, so we can work on this together.
>> Here are some ideas that I came up with while thinking about this feature
>> over the last month:
>> Since we will be shipping two version control systems out of the box now,
>> I think it would be beneficial to set a setting on which Version Control
>> System MonoDevelop should use by default.
> This is not necessary because MD already detects which project is using
> which version control system. Options shown in the context menu can be
> specific to the version control of the project.
> If you are concerned about the Checkout command, which has a special
> meaning in git, we can change the name and use something more explicit
> like "Get Project from Repository" or something like that.
>> Then when opening existing
>> projects we can scan for the system being used and set this value. This
>> will simplify and allow segregation of the commands and not present
>> options that are not valid based on the system being used. This will also
>> allow us to add configuration settings for the Version Control System that
>> the user can set. For instance, one feature I had in mind, which looks
>> like you implemented an early version of, is to display the current branch
>> beside the solution name. A configuration setting could actually
>> customize the output of that string. This would also be a good place to
>> set globally the files to ignore automatically when creating a new
> This can be done without having to set a default VC system. Specific VCS
> can extend the solution pad and customize it however they want, just
> like I did with the branch label in the solution node.
>> The commands available in the context menu should be in sync with the
>> command line options. This helps with uniformity and makes going back and
>> forth a lot easier. It will also enhance the workflow by presenting
>> commands in a way that are already familiar with the command line and vice
> I disagree with that point of view. The goal of an IDE is to simplify
> the development process. If we replicate every single git command, we
> are not simplifying, we are exposing all the complexity of git.
> As a user I don't want to have to deal with the complexity of git every
> day. There are only a few commands I need to use in everyday work
> (review changes, commit changes, update from repo). I want MD to take
> the correct decisions for me in order to perform those operations with
> git. In case I need to do more advanced git operations, I can always
> open a console and use the git command.
>> Here's a list of commands that I think should be implemented:
>> File Menu
>> Initialize - Create a new git repository
> We can create a new "Create repository" command, which can also be
> implemented for SVN.
>> Clone - Clone an existing git repository
> It is the Checkout command, which can be renamed to "Get Project from
> Repository", shared with SVN.
>> Project Context Menu
>> Commit - Commit changed files to local repository allowing the user to
>> check which changes to stage for the commit
> This is the current Review Changes view and the Commit command.
>> Push - Push changes to remote repository
> This command is new and specific to Git. Ok to add it.
You could also create a new generic DistributedVersionControl class
outside of the Git addin that adds a Push abstract operation, so other
addins that inherit from it can define their own Push behavior.
>> Pull - Pull changes from remote repository
>> Fetch - Fetch changes from remote repository
> Pull and Fetch are implemented by the "Update" command, so there is no
> need to have them as separate commands.
>> Create Branch - Create a new branch
>> Checkout Branch - Checkout an existing branch
>> Merge - Merge changes from one branch to another
> We can have a branch manager for doing those operations.
>> Create Tag - Create a new Tag
> We can add this command.
>> Log - View commit log
> That's the existing Log command.
>> Reset HEAD - Revert changes to last commit
> There is a Revert command in the SVN add-in which can be generalized.
>> Stash - Stash changes and reverting to last commit
>> UnStash - Unstash a stash object
> I'm not sure we need those. MD can automatically use stash for the most
> common operations, such as when pulling or when switching branches.
>> Add - Add changes files to staging
> I don't think the concept of "stagging" is really useful in the IDE.
> Stagging is useful in the command line because it allows you to select
> what do you want to commit. But the IDE already has a GUI for selecting
> what to commit (the review changes view), so this command is not
>> Ignore - Add file to .gitignore
>> Apply Patch - Apply a patch to current branch
> We don't have those commands, but it might be useful to have them for
> both SVN and Git.
>> Create Patch - Create a patch based on last commit
> Already exists.
For this one, it would be useful to place it in another place because
now with DVCS there's another use case: you commit, and then you want to
create the patch of an already-committed-locally changeset so other
person can review it before pushing it.
>> A pad for the history view showing the commits for the current branch.
>> This feature will present the commits in a nice and readable format. The
>> user will then be allowed to view changes for a commit and compare.
> This is the Log command. This command, when executed on a directory,
> used to show the commit history, but this seems to be broken in trunk.
>> A pad for managing Git repositories. This feature will present the .git
>> directory in an easy to read and presentable way allowing management of
>> remotes and branches for instance.
> Ok, although it would be a dialog, not a pad.
>> Of course this isn't everything probably, but just a short list of
>> features that I planned on doing. Any other thoughts?
> That's all!
My 2 cents!
More information about the Monodevelop-list