Menu
▾
▴
gitclipse-devel
|
From: Michelle S O. <ms...@ny...> - 2008-07-31 01:24:41
|
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 |
|
From: Andrew C. <ac...@co...> - 2008-07-31 01:52:50
|
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 > |
|
From: Andrew C. <ac...@co...> - 2008-07-31 02:07:48
|
Nope, I'm wrong. I must have run commit -a. We have the same problem after a git-mv and then modified. -- Drew On Wed, 30 Jul 2008, Andrew Case wrote: > 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 >> > |
|
From: Andrew C. <ac...@co...> - 2008-07-31 02:11:04
|
You can even have a modified staged and modified unstaged at the same time which gets even more confusing for the user. # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: src/edu/nyu/cs/hello/Hello.java # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: src/edu/nyu/cs/hello/Hello.java # -- Drew On Wed, 30 Jul 2008, Andrew Case wrote: > Nope, I'm wrong. I must have run commit -a. We have the same problem > after a git-mv and then modified. > > -- > Drew > > > On Wed, 30 Jul 2008, Andrew Case wrote: > >> 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 > |
|
From: Michelle S O. <ms...@ny...> - 2008-07-31 02:27:47
|
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 > > |
|
From: Andrew C. <ac...@co...> - 2008-07-31 13:10:59
|
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 >>> > |
|
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 |
|
From: Michelle S O. <ms...@ny...> - 2008-07-31 16:38:29
|
Okay I'm confused... Paul, the behavior you're describing is exactly what the commit dialog does right now, with the exception of the bug that I thought of last night with 'staged only'. What is it that you'd like to see that isn't happening already? I can't test this out until I get home, but I believe the new bug you reported is not actually a bug, but that the folder you've selected doesn't contain any files to commit so that one list is empty. It's possible that your selection in the navigator won't have any committable files, but the 'all' list will still have files. If there are no modified files at all in the repository, then you should see a 'no files to commit' message. To make this seem less buggy, perhaps the default list to view should be 'all' so that there will always be files displayed when the dialog first appears. Any comments on the decorator idea? Michelle ----- Original Message ----- From: Paul Munson Bethe <pm...@ny...> Date: Thursday, July 31, 2008 11:58 am Subject: Re: [Gitclipse-devel] Commit question To: Andrew Case <ac...@co...> Cc: Michelle S Osborne <ms...@ny...>, gitclipse-devel <git...@li...> > 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 |
|
From: Paul M. B. <pm...@ny...> - 2008-07-31 16:58:48
|
You are right -- I was just expounding on Andrew's idea of having
Team -> Commit -> Staged
-> All
-> This (maybe a better word? 'Dot', ?)
etc. rather than having radio buttons on the commit GUI -- but for now I don't think I care.
SO - the bug I submitted was really thinking about that.
So under the current scheme it is not really a bug. I will remark it.
----- Original Message -----
From: Michelle S Osborne <ms...@ny...>
Date: Thursday, July 31, 2008 12:38 pm
Subject: Re: [Gitclipse-devel] Commit question
To: Paul Munson Bethe <pm...@ny...>
Cc: Andrew Case <ac...@co...>, gitclipse-devel <git...@li...>
> Okay I'm confused... Paul, the behavior you're describing is exactly
> what the commit dialog does right now, with the exception of the bug
> that I thought of last night with 'staged only'. What is it that you'd
> like to see that isn't happening already?
>
> I can't test this out until I get home, but I believe the new bug you
> reported is not actually a bug, but that the folder you've selected
> doesn't contain any files to commit so that one list is empty. It's
> possible that your selection in the navigator won't have any
> committable files, but the 'all' list will still have files. If there
> are no modified files at all in the repository, then you should see a
> 'no files to commit' message. To make this seem less buggy, perhaps
> the default list to view should be 'all' so that there will always be
> files displayed when the dialog first appears.
>
> Any comments on the decorator idea?
>
> Michelle
>
> ----- Original Message -----
> From: Paul Munson Bethe <pm...@ny...>
> Date: Thursday, July 31, 2008 11:58 am
> Subject: Re: [Gitclipse-devel] Commit question
> To: Andrew Case <ac...@co...>
> Cc: Michelle S Osborne <ms...@ny...>, gitclipse-devel <git...@li...>
>
>
> > 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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X