Re: [Gitclipse-devel] Commit question

[Michelle S O. <ms...@ny...>]

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