The EGit 1.0 will be officially released in upcoming days, but I’ve already started to working on version 1.1. Today I would like to demonstrate you a feature that I was recently working on. To be honest the main idea of this functionality comes from my GSoC 2010 proposal, but I didn’t manage to implement it … until now ;), so what it is?
The post title should told you everything about it … but (if not) I’ve also prepared a screencast that is embedded above where you can clearly see how it works in real environment.
I know that in version 1.0 the Staging view was introduced, to be honest, I don’t think that separate view for staging is really needed. But I don’t have anything against it, it looks cool and works properly ;). Also I don’t see anything bad with having this functionality doubled in Git Change Set model and give users possibility to choose between both of them.
I’ve pushed this feature (and all dependent changes) yesterday. This is quite huge change so I think that we’ll iterate few times with it before it will be merged into master, but I hope it will be included in 1.1.
As always feel free to share any ideas and comments!
Pingback: Dariusz Luksza: Drag-and-Drop staging/un-staging in Git Change Set model
Masbe the staging view was not necessary if the commit view would sort by the check boxes (if the represent the staging) or split the list to staged and unstaged files. It is much easier to see what you commit if you have the candidate files together.
@Jacek Kołodziejczyk
Commit dialog is already complicated for git newcomers (there is an ‘amend’, ‘sign by’, ‘change id’ options and select/deselect all. IMO adding another “complication” for splitting staged and unstaged changes will raise lots of discussions “why it is so complicated?” and “why I should really bother with git index?”
We need to remember that, apart from, git-power-users there is lots of users that use to cvs/svn workflow and they don’t want to change/learn new one.