Re: [Gitclipse-devel] Commit question

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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