[MonoDevelop] Git add-in

[Lluis Sanchez Gual]

El dt 27 de 07 de 2010 a les 18:40 +0200, en/na "Andrés G. Aragoneses"
va escriure: 
> El 27/07/10 17:49, Lluis Sanchez Gual escribió:
> > Hi!
> > 
> > I just committed an improved Git add-in which supports the basic Git
> 
> Great!!
> 
> 
> > operations integrated in MonoDevelop. This add-in does the work by
> > invoking the git command and parsing the output it generates. This
> > solution is not very efficient, but it does the job. The plan is to
> > incrementally replace those git invocations by calls to the GitSharp
> > library.
> > 
> > I still have to figure out what's the best way of integrating the Git
> > workflow into the MD version control system. The existing version
> > control operations are implemented in this way:
> > 
> >       * The Review Changes view shows files that have been added (new
> >         files registered with git add), removed (files removed with git
> 
> Then the user has to git add/rm the files manually??

This works like the SVN add-in. In most cases, MD will git-add or git-rm
the files for you. For example, when you add to or delete a file from
project.

> If yes, why not
> improving this to make the commit actually do a pre-commit (pursuing git
> add and git rm in the files that have been marked in the checkbox) just
> before the commit in the same atomic MonoDevelop-operation? This way the
> ReviewChanges operation would show *any* change in the local repository.

You can only get a list of files added/removed if the files have been
git-added and git-removed. That's why it has to be done before showing
the status view (just like SVN).

> 
> 
> >         rm) or modified (all modified files, staged and non-staged).
> 
> I believe you also have to 'git add' modified files.

Yes, but that can be done when committing. Git will report modified
files even if they are not stagged, so they can be shown in the status
view without having to do a git-add on them.

> 
> 
> >       * A commit operation commits the selected files to the current
> >         branch. It does not push.
> >       * The Update command does a "pull --rebase --ff" of the current
> >         branch.
> >       * The Revert command does a "git checkout" of the selected files.
> >       * The Show Annotations, Revert Revision and Revert to Revision
> >         commands are not yet implemented.
> > 
> > The Git add-in provides two additional commands available in the context
> > menu:
> > 
> >       * The new Push command shows all changes done wrt a remote branch
> >         and then pushes the changes. The remote repo and branch can be
> >         selected in a dialog.
> >       * The new "Switch to Branch" command, allows switching the working
> 
> Can a warning be implemented in case there are local uncommitted changes
> when pursuing this operation (because I'm assuming you lose them??)?

Yes, I have to take a look a this. When switching branches, local
changes seem to be kept, but there may be issues in case of conflicting
changes.

> 
> >         tree to a branch (git checkout). Once a branch is selected, all
> >         operations (including commit, push, pull) are done only for that
> >         branch.
> 
> I would add a very emphasized label then prior to the Push operation so
> the user can visually spot which branch he's targetting.

That's in the push dialog, but I can emphasize it a bit more :)

I'm also toying with the idea of having a branch selector in the toolbar
(similar to the configuration selector).

> 
> 
> > 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.
> > 
> > Thanks,
> > Lluis.
> 
> Keep up the good work!
> 
>   Andres
>