From: Paul M. B. <pm...@ny...> - 2008-07-31 15:58:31
|
Or three? Scenario - right click on a package which is not the project route: Commit staged (only staged, but committed even if above this directory) Commit (like commit . all files from this directory and down, whether staged or not) Commit all (like -a all files) These three behaviors mimic git, so should be supported. btw - I have added a related bug for commit to the tracker -Paul ----- Original Message ----- From: Andrew Case <ac...@co...> Date: Thursday, July 31, 2008 9:11 am Subject: Re: [Gitclipse-devel] Commit question To: Michelle S Osborne <ms...@ny...> Cc: gitclipse-devel <git...@li...> > Would it be easier and make more sense to users if we provide two > different commit menu options. One being a "commit staged" and one > being > "commit all"? I would think the actual commit wizard itself could > just > have a checkbox that a user could select "commit all unstaged changes" > > which would basically switch between the two options. When you select > > "commit staged" or "commit all" from the popup-menu it would > select/unselect that checkbox as appropriate. Would that work? > > The "add to revision" popup menu option would do the staging (maybe > the > menu could read "add to revision" on untracked files and "stage > changes" > on tracked files but would be doing the same thing (git-add) in both > instances. > > -- > Drew > > > On Wed, 30 Jul 2008, Michelle S Osborne wrote: > > > Whether or not the unstaged modifications get committed along with > the file addition depends on what kind of commit you do. If you do a > plain commit without -a and without explicit pathnames, the unstaged > modifications won't be committed. The same holds for files that are > not newly added - if you modify a file, stage it, and modify it again, > there are two different sets of changes that could be committed, based > on your options to git commit. > > > > So this is a more general problem of what to display when a file > differs between head, stage, and working directory. We could put a > precedence on statuses, so added or modified would supersede modified > [unstaged]. Unless you're explicitly committing only what's in your > index, that's probably all you care about. I think that's basically > what you said, right? > > > > This made me realize a bigger problem with the dialog. Committing > with the 'staged only' option should really do the equivalent of a > commit with no options and no explicit paths, since that's the only > way to commit just the staged modifications. This means that you > *can't* mess with the selections in the staged-only list. > > > > In addition, perhaps we should consider adding a new decorator icon > to indicate files that differ from their contents in stage. In svn or > cvs the concept of 'dirty' just means different from the repository, > but in git there are really two kinds of dirty.. dirty with respect to > the repo and dirty with respect to stage. I think it would be helpful > to indicate both of them differently. > > > > Michelle > > > > > > > > ----- Original Message ----- > > From: Andrew Case <ac...@co...> > > Date: Wednesday, July 30, 2008 9:53 pm > > Subject: Re: [Gitclipse-devel] Commit question > > To: Michelle S Osborne <ms...@ny...> > > Cc: git...@li... > > > >> When you commit a file managed by git after it has been "added with > >> unstaged modifications" it just commits it as a standard add > >> (including > >> the modifications). If we treat files that show up in both "added > >> (staged)" and "unstaged modifications" as if the file was simply in > >> "added > >> (and staged)" is this a problem? > >> > >> -- > >> Drew > >> > >> > >> On Wed, 30 Jul 2008, Michelle S Osborne wrote: > >> > >>> Hey guys, > >>> > >>> Paul posted a bug which turns out to be interesting because I'm not > >> sure > >>> what the desired functionality is. The bug is that if you add a file > >> and > >>> then further modify it before committing, it will turn up in the > >> list of > >>> files to commit twice, once as added and once as modified/unstaged. > >> The > >>> reason for this is because javagit returns the file as both added > >> and > >>> modified/unstaged, which in turn is because git status lists the > >> file > >>> twice in the same fashion. > >>> > >>> One solution would be to list the file as 'added with unstaged > >>> modifications' or something like that. The thing that's slightly > >> weird > >>> about that is that you'd see the file listed with a different status > >> > >>> depending on which radio button was selected - the 'staged only' > >> button > >>> would show the file only as added, because if you're only committing > >> > >>> staged changes you won't commit the modification. The 'all changes' > >> and > >>> 'selected' radio buttons would show it as 'added with unstaged > >>> modifications'. > >>> > >>> Another option is to leave it as is, so that the 'staged only' > >> button > >>> would just list the file as 'added', while the other two buttons > >> would > >>> show two files with different statuses. That's also slightly weird > >> in > >>> that it would probably appear to be a bug, except maybe to people > >> who > >>> are very familiar with git command line responses. Perhaps there's > >> some > >>> description that could be put into the table header or somewhere > >> else in > >>> the dialog that would make it clear why there were duplicate files > >>> listed? > >>> > >>> I'm not sure if there are better options that I'm missing. Any > >>> suggestions? > >>> > >>> Michelle > >>> > >>> ------------------------------------------------------------------------- > >>> This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > >>> Build the coolest Linux based applications with Moblin SDK & win > >> great prizes > >>> Grand prize is a trip for two to an Open Source event anywhere in > >> the world > >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >>> _______________________________________________ > >>> Gitclipse-devel mailing list > >>> Git...@li... > >>> https://lists.sourceforge.net/lists/listinfo/gitclipse-devel > >>> > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gitclipse-devel mailing list > Git...@li... > https://lists.sourceforge.net/lists/listinfo/gitclipse-devel |