git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [EGIT RFC] Commit behaviour

From
Robin Rosenberg <robin.rosenberg@dewire.com>
Date
Jun 14, 2008, 09:08 UTC
Message-ID
<200806141108.17854.robin.rosenberg@dewire.com>
In-Reply-To
<4852EFBF.6000406@gmail.com>
lördagen den 14 juni 2008 00.07.59 skrev Marek Zawirski:
Show 19 quoted lines
> 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.

Show 7 quoted lines
> > 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)
Show 8 quoted lines
> > 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
Previous: Robin RosenbergNext: Robin Rosenberg
Message 8 of 11 in “[EGIT RFC] Commit behaviour”
  1. Robin RosenbergJun 12, 2008
  2. [EGIT RFC] Add utilities for figuring out repositories for selected resourcesRobin Rosenberg, Jun 12, 2008
  3. [EGIT RFC] Enable commit for any resource in a Git-shared projectRobin Rosenberg, Jun 12, 2008
  4. Marek ZawirskiJun 13, 2008
  5. Marek ZawirskiJun 13, 2008
  6. Robin RosenbergJun 14, 2008
  7. Robin RosenbergJun 14, 2008
  8. Robin RosenbergJun 14, 2008
  9. Robin RosenbergJun 14, 2008
  10. Marek ZawirskiJun 15, 2008
  11. Shawn O. PearceJun 16, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.