[MonoDevelop] Git add-in

[Dale Ragan]

Comments are inline...

> 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.

OK, as long as there is a way to segregate the commands.  I think changing
the checkout command will be beneficial and will cause less confusion.

>>   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
>> snip
> 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.

I agree in simplifying the workflow with Git, but at the same time we need
to stay uniform with the naming in some way.  I have yet to see an IDE
that supports Git not do the same thing.

>>
>> 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.

I'm fine with leaving it named Checkout while under SVN, but under Git to
keep uniform, I really would like to see Clone.  I'm sure we can figure
something out to distinguish which VCS we are using and change
accordingly.

>>
>>   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.
>
>>     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.
>

As other's have noted, I think we need to have both.  When I have a fork
and I want to update my fork to latest from the repository I forked from,
I like to fetch first and then do a merge.  It makes life easier when
conflicts are found.

>>     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.

Well Checkout branch is already started with the Switch to Branch command.
 I agree they could also be in the branch manager, but I think we should
keep Create Branch for speed.  I create branches all the time and I really
don't want to have to switch to the dialog every time, I rather just right
click the project and click Create Branch which will perform a "git
checkout -b branchname" for me.

>>     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.

What if you don't need to pull or switch branches and you're working on
something and all of a sudden you need to stop to fix some critical bug?

>>     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
> necessary.

Agree, this can be integrated with the review changes view allowing the
user to add and remove files for the commit.

>>     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.
>
>>
>> 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!
> Lluis.
>
>
>