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

Re: [EGIT PATCH 1/2] Add utilities for figuring out repositories for selected resources

From
Shawn O. Pearce <spearce@spearce.org>
Date
Sep 2, 2008, 19:00 UTC
Message-ID
<20080902190046.GE28704@spearce.org>
In-Reply-To
<200809022053.35419.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
Show 8 quoted lines
> tisdagen den 2 september 2008 17.03.23 skrev Shawn O. Pearce:
> > 
> > Hmm.  So if any one of the selected projects doesn't have a Git
> > repository at its top level we just plain fail and pretend none of
> > them have a Git repository?
> 
> That is the way everything in Eclipse work. For an operation to be applicable
> to a selection, it must be applicable to eache element.
OK.  Good reason then.
Show 15 quoted lines
> > But I also wonder if that really makes sense when a project could
> > have a linked resource under it that points to the repository's
> > working directory.  In such cases we want operations on that project
> > to potentially impact the inner repository as maybe the project
> > repository does not have a repository itself.  IOW I'm questioning
> > the idea of getRepositoriesFor(getProjectsForSelectedResources()).
> 
> Ouch for linked resources. I really think we should ignore the link as much
> as we can. It's a trap! I any way it needs more fixing that this and not
> only here. A patch does not have to solve all problems in the world :)
> 
> I have no experience with linked resources, other that I found them enough
> awkward to use to prevent from doing that. How useful and portable is
> a C:\foo on my system? I don't mind anyone solving the problem, but it is
> very low on my personal agenda.

Linked resources are useful (sometimes), especially if the project files are automatically generated for you from your build system. My prior day-job had a really nice build system that did this. My current day-job also has a build system that can generate Eclipse project files for you.

In both cases the project files aren't considered part of the source as they can be rebuilt at any time and they both used linked resources to point to the actual place where the source was stored, which typically was outside of your workspace directory, while the project was within the workspace directory.

Anyway, I wasn't trying to suggest solving the worlds problems. But RepositoryMapping is smarter now and can (mostly) handle a linked resource just fine. Its the higher level GUI actions that run into trouble.

I guess we should stick this series in as-is then.
-- 
Shawn.
Previous: Robin Rosenberg
Message 6 of 6 in “Select all changes in repository for commit by default”
  1. Select all changes in repository for commit by defaultRobin Rosenberg, Aug 31, 2008
  2. 1/2 Add utilities for figuring out repositories for selected resourcesRobin Rosenberg, Aug 31, 2008
  3. 2/2 Enable commit for any resource in a Git-shared projectRobin Rosenberg, Aug 31, 2008
  4. Shawn O. PearceSep 2, 2008
  5. Robin RosenbergSep 2, 2008
  6. Shawn O. PearceSep 2, 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.