Re: [Gitclipse-devel] Commit question

[Andrew C. <ac...@co...>]

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
>>>
>