Re: [EGIT RFC] Commit behaviour

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



lördagen den 14 juni 2008 00.07.59 skrev Marek Zawirski:
> Robin Rosenberg wrote:
> > I got annoyed about having change my selection to a project to be able
> > to commit. This tentative feature allows me to hit the commit button
> > when any resource is selected and figure out which resources have been
> > modified. This makes it much easier to commit. Only the toolbar commit
> > is affected for now.
> 
> That's a nice idea! I also thought about that one day, as such feature 
> already exists in (e.g.) Subclipse that I was used to.
> 
> > 
> > Another twist would be to list all changed resources, but only enable
> > the selected ones, or only the ones in in the same projects as the selected
> > resources. Comments?
> 
> I think that only selected && changed ones should be listed. When user 
> selects explicitly some resources, he/she is probably interested only in 
> these ones. And he/she probably did it for easier selection than from 
> list of all changed resources, isn't it?

Selection is often implicit, i.e. if you link editor and selection, which I do, the selection
change every time you switch editor. 

> > Code is not efficient either. This is question about the user interface.
> 
> Theses patches don't work for me however :/ When I introduce some change 
> to a resource/file, even add it to index and click commit (toolbar or 
> menu), commit action does nothing. It is - nothing happens. Can you 
> reproduce this problem, or should I debug it on my instance? Or do I use 
> it in some wrong way?
It it's too hard to use properly it's wrong. Anyway I could reproduce it. Not sure
why it works sometimes though. I found this in the workspace log. Please 
check if you see it too, so I know we're chasing the same bug.

java.lang.ArrayIndexOutOfBoundsException: 0
        at org.spearce.egit.ui.internal.actions.CommitAction.loadPreviousCommit(CommitAction.java:127)


> > Then we could ask ourselved, should we do something similar for Checkout
> > and reset too? I think that is not as important as those operations are
> > much less frequent.
> > 
> > -- robin
> 
> Well, I think that checkout (maybe reset too) would be useful too - to 
> revert some file quickly.

We do not have a per-file checout/reset yet. What we have checks out all files in the repository.

-- robin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux