gitclipse-devel — Gitclipse development issues

[Gitclipse-devel] Git Project updates after git checkout

[Han C. <dev...@gm...>]

hi Guys, I've implemented the Git Checkout Action in repository view.  The
last thing I need is to force a project update, I am just looking for a
couple quick pointers from you guys about how to obtain the current projects
in the workspace, and do updates on them.  Any ideas would be great.
I need to persist the data in the Git repository view so that they won't get
lost when Eclipse restarts, and if time permits, I can go ahead and
implement other git branch related action.  That is why I am asking for some
quick helps. :)

-- 
Han Chiu

[Gitclipse-devel] GitFileStatus changes

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

Paul,

Why did you change all uses of GitFileStatus to GitResourceStatus? You asked in a code review if there was a reason why I didn't use it and I answered you. If you weren't satisfied with the answer you could have discussed it further rather than taking it upon yourself to replace uses of one with the other. You didn't even create a code review for that changeset, so I didn't get a chance to give you feedback, like for example to tell you that your changes broke the commit dialog's status display.

I may add more fields to that enum. I don't have the time to change all of the commit dialog's uses of GitResourceStatus back to GitFileStatus, so if I do need to add fields I'm going to make the getParentTransition method throw exceptions for them, because I doubt that the method will make sense in the context of how I'm planning on using the enum.

Michelle

Re: [Gitclipse-devel] [osp_2008] Gitclipse project data migration

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

By the way.  When migrating our documentation over to the new wiki I 
merged some of the documentation.
   "Pat's notes on eclipse" merged into "Eclipse API notes"
   "Configuring your Eclipse target" merged into "Eclipse API notes"
   "Paul's Notes on Subclipse" moved into "General Notes"

I didn't migrate the milestones becuase I figured if you're interested you 
can submit those as bug/feature items on sourceforge and these should 
probably be managed from there from here on out.

I think that about sums it up.

--
Drew


On Sat, 2 Aug 2008, Andrew Case wrote:

> Yes it's also important that only people who we want to have admin access
> to things end up with gitclipse shell access.  I think only "Admin"
> members get shell access to the group by default.  So as long as
> permissions stay only user/group readable it should be fine.
>
> I struggled with the wiki idea, but I ended up thinking the the ease of
> gitclipse members/users to be able to contribute outweighed the extra work
> to manage it.  It might be over doing it for gitclipse, but we'll see.
>
> Speaking of documentation...
>
> Gitclipsers,
>
> At some point we need to write some proper help, install, build, tutorial,
> contribute documentation for the plug-in.  Of course the code
> functionality is currently more crucial so we have some working software,
> but proper documentation is also critical for a projects success.  Maybe
> if each of us volunteer to take on one of these topics, we'll have at
> least decent documentation for our alpha release.
>
> I'd like to volunteer for the contribution documentation, otherwise it
> seems like it would make sense for the following users to work on these
> documentation parts (in my mind at least):
>   Build - Michelle (since you managed CC you have the most experience)
>   Install - Patrick (since you're setting up the update-site)
>   Help (accessed from inside eclipse) - Paul or Han?
>   Tutorial (something simple, just how to checkout/init/import a project
> modify and then commit it) - Paul or Han?
>
> If someone doesn't think they can manage it with their current work load,
> this shouldn't be a problem, but please let us (gitclipse-devel) know.
> Since obviously some documentation is more important than others so we
> might need to shuffle ownership to make sure the more important ones get
> done.
>
> Thanks!
>
> --
> Drew
>
>
> On Fri, 1 Aug 2008, James Linder wrote:
>
>> Hey Andrew,
>>
>> I like that idea.  So long as we are careful to make the README user
>> and group readable, it works nicely.
>>
>> All,
>>
>> I'm working on doing a similar migration for javagit notes.
>>
>> The file 'shell.sourceforge.net:/home/groups/j/ja/javagit/README' now
>> contains the resource information.  It is accessible only to users in
>> the javagit members granted shell access to the javagit group.
>>
>> I've added a number of feature requests and bugs from the information
>> in the wiki.  I don't plan on creating a JavaGit wiki at the moment;
>> perhaps we'll do that a little later.  For now, I'll move the
>> appropriate information into the website pages.
>>
>> Cheers,
>>
>> James
>>
>>
>> On Aug 1, 2008, at 4:27 PM, Andrew Case wrote:
>>
>>> In an effort to move our project into public space I'm migrating
>>> more things over to sourceforge.
>>>
>>> The most important of which is probably the info from the "Project
>>> Resoures" wiki page.  The new location for this documentation is
>>> available through ssh at 'shell.sourceforge.net:/home/groups/g/gi/
>>> gitclipse/README' and is accessible only to gitclipse shell access
>>> granted team members. It includes the admin user/passwords for the
>>> project resources that we manage.  Future project resource changes
>>> should go in that file.
>>>
>>> I've added a wiki to our sourceforge page and I think I've migrated
>>> most of the things over from our class site.  Updates to that
>>> documentation should probably be on the sourceforge wiki.
>>>  http://gitclipse.org/wiki
>>>
>>> --
>>> Drew
>>
>> _______________________________________________
>> G22_3033_003_su08 mailing list
>> G22...@cs...
>> http://www.cs.nyu.edu/mailman/listinfo/g22_3033_003_su08
>>
> _______________________________________________
> G22_3033_003_su08 mailing list
> G22...@cs...
> http://www.cs.nyu.edu/mailman/listinfo/g22_3033_003_su08
>

Re: [Gitclipse-devel] Changing Working Directory in Java

[<pm...@ny...>]

But if you fork a process with a process builder, it can run in a separate directory, and if that process is say git-status, then the paths it returns will not be correct if addressed relative to the parent process. 

And from gitclipse, relative paths are always relative to the 'project root', yet I don't believe it is guaranteed that the 'user.dir' will be the same, as it will be the 'workspace'.

(I will test this out over the weekend)

-PB


------Original Message------
From: James Linder
Sender: 
To: javagit-devel
Cc: git...@li...
Sent: Aug 1, 2008 11:25 PM
Subject: [Gitclipse-devel] Changing Working Directory in Java

Hi All,

I found some insightful threads about how java handles changing the
working directory of a Java program.  They are:

  http://forums.sun.com/thread.jspa?threadID=665110&messageID=3894504
  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4045688

In short, there is no way to change the working directory of a running
Java program.

So, this means that there is almost no reason for JavaGit to be using
File.getAbsolutePath() in any of its code because the "user.dir"
system almost never be the correct location to resolve a relative
reference against.  Thus, File.getPath() is sufficient for all places
where we get the path from a File instance.

Cheers,

James

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


Sent via BlackBerry

[Gitclipse-devel] Changing Working Directory in Java

[James L. <jam...@gm...>]

Hi All,

I found some insightful threads about how java handles changing the
working directory of a Java program.  They are:

  http://forums.sun.com/thread.jspa?threadID=665110&messageID=3894504
  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4045688

In short, there is no way to change the working directory of a running
Java program.

So, this means that there is almost no reason for JavaGit to be using
File.getAbsolutePath() in any of its code because the "user.dir"
system almost never be the correct location to resolve a relative
reference against.  Thus, File.getPath() is sufficient for all places
where we get the path from a File instance.

Cheers,

James

Re: [Gitclipse-devel] [Javagit-users] [Javagit-devel] Build on Windows Vista

[Paul M. B. <pm...@ny...>]

[Gitclipsers I am including you on this, as we have some additional install instructions. ]

Scratch part of my previous.

javagit builds fine under Cygwin.  (with the same 4 stray directories)
I had a shell with a wacky environment.  When I started a new cygwin terminal, everything was fine.

So I guess you guys are 

The problem is that depending on your cygwin install, git may have problems with the '\r\n' that eclipse uses for newlines (Windows sucks).

So - I/gitclipse, will need to warn our users that to use a cygwin install, they need to install the version that does windows newlines, not unix.  (or if they want unix-cygwin as I do to share files back and forth with a real *nix install, then they have to install mysysgit.



----- Original Message -----
From: Paul Munson Bethe <pm...@ny...>
Date: Friday, August 1, 2008 10:17 am
Subject: Re: [Javagit-users] [Javagit-devel] Build on Windows Vista
To: James Linder <jam...@gm...>
Cc: jav...@li...


> If I put mvn and mysysgit on my Path, and the in a command-window (not 
> cygwin), go to the javagit directory and run mvn package, all 90 tests 
> run.
> Due to conflicts between various commands, I don't think it is 
> possible to build this under cygwin (I have tried most of them).
> 
> However, I still have 4 stray GitStatusTestRepository directories 
> being created.  (low priority bug on that one entered yesterday).  But 
> these are now in c:\Temp so I don't mind so much.
> 
> With the Path this way, I have gitclipse running quite well (or at 
> least calling javagit/git successfully)
> 
> 
> -Paul
> 
> 
> 
> ----- Original Message -----
> From: James Linder <jam...@gm...>
> Date: Friday, August 1, 2008 8:49 am
> Subject: Re: [Javagit-users] [Javagit-devel] Build on Windows Vista
> To: jav...@li...
> 
> 
> > Hey Paul,
> > 
> > I though this was going to the javagit-users list originally, but it
> > went to javagit-devel.  Do you have any further information regarding
> > my questions below?
> > 
> > Thanks,
> > 
> > James
> > 
> > 
> > On Thu, Jul 31, 2008 at 9:38 PM, James Linder 
> > <jam...@gm...> wrote:
> > > Hey Gurdeep,
> > >
> > > Excellent.  That is great news!  :-)
> > >
> > > Could you also test using msysgit instead of cygwin+git.  (It may 
> be
> > > beneficial to review one of Pauls previous emails about needing to
> > > uninstall git from cygwin).  Also, since we are targeting Java 1.5,
> > > how do the tests run with Java 1.5?
> > >
> > >
> > > Paul,
> > >
> > > How does this stack up to what you are seeing?  Do our tests run with
> > > cygwin+git?  How about with msysgit?
> > >
> > >
> > > Cheers,
> > >
> > > James
> > >
> > >
> > > On Thu, Jul 31, 2008 at 9:28 PM, GD <gu...@op...> wrote:
> > >>
> > >> I have a good news. I had been testing our build on my Windows Vista
> > >> machine and till yesterday night, we had few failures, but now after
> > >> downloading latest update from svn, **all tests are passing on my
> > >> Windows machine now and also able to build the javagit build successfully.
> > >>
> > >> Details -
> > >>
> > >> java version "1.6.0_01"
> > >> Java(TM) SE Runtime Environment (build 1.6.0_01-b07)
> > >> Java HotSpot(TM) Client VM (build 1.6.0_01-b07, mixed mode, sharing)
> > >>
> > >> Windows Vista Home edistoin, ( OS 64 Bit ) running Cygwin, with Git
> > >> version 1.5.6
> > >>
> > >>
> > >> thanks
> > >> Gurdeep
> > >>
> > >
> > 
> > -------------------------------------------------------------------------
> > 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=/
> > _______________________________________________
> > Javagit-users mailing list
> > Jav...@li...
> > https://lists.sourceforge.net/lists/listinfo/javagit-users

Re: [Gitclipse-devel] Auto Refresh Provider

[<pm...@ny...>]

I monitor .git/objects for commit changes.

Sent via BlackBerry

-----Original Message-----
From: Andrew Case <ac...@co...>

Date: Thu, 31 Jul 2008 17:32:00 
To: Paul Munson Bethe<pm...@ny...>
Cc: Patrick Winters<pat...@ny...>; gitclipse-devel<git...@li...>
Subject: Re: [Gitclipse-devel] Auto Refresh Provider


.git/HEAD doesn't change unless you switch your branch right?  If you want 
to monitor for commit changes I think you need to poll .git/refs/[branch]. 
I'm not sure about this though.

--
Drew

On Thu, 31 Jul 2008, Paul Munson Bethe wrote:

> I am not polling the whole tree...  just the .git/HEAD and objects files.
> I am letting the standard eclipse stuff poll the tree.
>
> As I mentioned below, I don't think '.git' has an IResource associated.
>
> ----- Original Message -----
> From: Patrick Winters <pat...@ny...>
> Date: Thursday, July 31, 2008 5:08 pm
> Subject: Re: Auto Refresh Provider
> To: Paul Munson Bethe <pm...@ny...>
> Cc: gitclipse-devel <git...@li...>
>
>
>> Still, if we need to detect user operations outside eclipse can't we
>> offer a RefreshProvider for the .git resources?  Do we still need to
>> poll the entire project tree?
>>
>> On Thu, 2008-07-31 at 16:58 -0400, Paul Munson Bethe wrote:
>>> OK - but we would still need this or similar to detect user
>> operations outside eclipse.
>>>
>>>
>>> ----- Original Message -----
>>> From: Patrick Winters <pat...@ny...>
>>> Date: Thursday, July 31, 2008 4:56 pm
>>> Subject: Re: Auto Refresh Provider
>>> To: Paul Munson Bethe <pm...@ny...>
>>> Cc: gitclipse-devel <git...@li...>
>>>
>>>
>>>> But we shouldn't have to poll the filesystem to be aware of a commit.
>>>> All Git operations should notify the workspace or our plugin to refresh
>>>> automatically.  Right?
>>>> --
>>>> Patrick
>>>>
>>>> On Thu, 2008-07-31 at 16:54 -0400, Paul Munson Bethe wrote:
>>>>> I tried using that, but I don't think it does what you think it
>> does
>>>> (that was part of my 2 days).
>>>>>
>>>>> If you can figure out how to use this instead, you are
>> welcome...
>>>>> but I think the idea for it was if you had a better method than
>>
>>>> file-system polling.
>>>>>
>>>>> But you see, when you commit a file, that file does not change.
>> So
>>>> hitting refresh does nothing.
>>>>> And since the .git/ is a meta-file, it is not treated as an IResource...
>>>>> That is why I went the route I did.
>>>>>
>>>>> -P
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: Patrick Winters <pat...@ny...>
>>>>> Date: Thursday, July 31, 2008 4:48 pm
>>>>> Subject: Auto Refresh Provider
>>>>> To: gitclipse-devel <git...@li...>,
>> Paul
>>>> Munson Bethe <pm...@ny...>
>>>>>
>>>>>
>>>>>> Paul,
>>>>>>   I found this just now after I saw your DotGitMonitor.  You
>> can define
>>>>>> a RefreshProvider in the framework that auto-polls resources and
>>>>>> subdirectories and handles changes.
>>>>>>
>>>>>> http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/refresh/RefreshProvider.html
>>>>>> --
>>>>>> Patrick
>>>>>>
>>>>>>
>>>>
>>
>
> -------------------------------------------------------------------------
> 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
>

Re: [Gitclipse-devel] Auto Refresh Provider

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

.git/HEAD doesn't change unless you switch your branch right?  If you want 
to monitor for commit changes I think you need to poll .git/refs/[branch]. 
I'm not sure about this though.

--
Drew

On Thu, 31 Jul 2008, Paul Munson Bethe wrote:

> I am not polling the whole tree...  just the .git/HEAD and objects files.
> I am letting the standard eclipse stuff poll the tree.
>
> As I mentioned below, I don't think '.git' has an IResource associated.
>
> ----- Original Message -----
> From: Patrick Winters <pat...@ny...>
> Date: Thursday, July 31, 2008 5:08 pm
> Subject: Re: Auto Refresh Provider
> To: Paul Munson Bethe <pm...@ny...>
> Cc: gitclipse-devel <git...@li...>
>
>
>> Still, if we need to detect user operations outside eclipse can't we
>> offer a RefreshProvider for the .git resources?  Do we still need to
>> poll the entire project tree?
>>
>> On Thu, 2008-07-31 at 16:58 -0400, Paul Munson Bethe wrote:
>>> OK - but we would still need this or similar to detect user
>> operations outside eclipse.
>>>
>>>
>>> ----- Original Message -----
>>> From: Patrick Winters <pat...@ny...>
>>> Date: Thursday, July 31, 2008 4:56 pm
>>> Subject: Re: Auto Refresh Provider
>>> To: Paul Munson Bethe <pm...@ny...>
>>> Cc: gitclipse-devel <git...@li...>
>>>
>>>
>>>> But we shouldn't have to poll the filesystem to be aware of a commit.
>>>> All Git operations should notify the workspace or our plugin to refresh
>>>> automatically.  Right?
>>>> --
>>>> Patrick
>>>>
>>>> On Thu, 2008-07-31 at 16:54 -0400, Paul Munson Bethe wrote:
>>>>> I tried using that, but I don't think it does what you think it
>> does
>>>> (that was part of my 2 days).
>>>>>
>>>>> If you can figure out how to use this instead, you are
>> welcome...
>>>>> but I think the idea for it was if you had a better method than
>>
>>>> file-system polling.
>>>>>
>>>>> But you see, when you commit a file, that file does not change.
>> So
>>>> hitting refresh does nothing.
>>>>> And since the .git/ is a meta-file, it is not treated as an IResource...
>>>>> That is why I went the route I did.
>>>>>
>>>>> -P
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: Patrick Winters <pat...@ny...>
>>>>> Date: Thursday, July 31, 2008 4:48 pm
>>>>> Subject: Auto Refresh Provider
>>>>> To: gitclipse-devel <git...@li...>,
>> Paul
>>>> Munson Bethe <pm...@ny...>
>>>>>
>>>>>
>>>>>> Paul,
>>>>>>   I found this just now after I saw your DotGitMonitor.  You
>> can define
>>>>>> a RefreshProvider in the framework that auto-polls resources and
>>>>>> subdirectories and handles changes.
>>>>>>
>>>>>> http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/refresh/RefreshProvider.html
>>>>>> --
>>>>>> Patrick
>>>>>>
>>>>>>
>>>>
>>
>
> -------------------------------------------------------------------------
> 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
>

Re: [Gitclipse-devel] Auto Refresh Provider

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

Can't we just poll .git/refs/heads/[branch] (doesn't javagit have an 
option for this)?

--
Drew


On Thu, 31 Jul 2008, Patrick Winters wrote:

> Still, if we need to detect user operations outside eclipse can't we
> offer a RefreshProvider for the .git resources?  Do we still need to
> poll the entire project tree?
>
> On Thu, 2008-07-31 at 16:58 -0400, Paul Munson Bethe wrote:
>> OK - but we would still need this or similar to detect user operations outside eclipse.
>>
>>
>> ----- Original Message -----
>> From: Patrick Winters <pat...@ny...>
>> Date: Thursday, July 31, 2008 4:56 pm
>> Subject: Re: Auto Refresh Provider
>> To: Paul Munson Bethe <pm...@ny...>
>> Cc: gitclipse-devel <git...@li...>
>>
>>
>>> But we shouldn't have to poll the filesystem to be aware of a commit.
>>> All Git operations should notify the workspace or our plugin to refresh
>>> automatically.  Right?
>>> --
>>> Patrick
>>>
>>> On Thu, 2008-07-31 at 16:54 -0400, Paul Munson Bethe wrote:
>>>> I tried using that, but I don't think it does what you think it does
>>> (that was part of my 2 days).
>>>>
>>>> If you can figure out how to use this instead, you are welcome...
>>>> but I think the idea for it was if you had a better method than
>>> file-system polling.
>>>>
>>>> But you see, when you commit a file, that file does not change.  So
>>> hitting refresh does nothing.
>>>> And since the .git/ is a meta-file, it is not treated as an IResource...
>>>> That is why I went the route I did.
>>>>
>>>> -P
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: Patrick Winters <pat...@ny...>
>>>> Date: Thursday, July 31, 2008 4:48 pm
>>>> Subject: Auto Refresh Provider
>>>> To: gitclipse-devel <git...@li...>, Paul
>>> Munson Bethe <pm...@ny...>
>>>>
>>>>
>>>>> Paul,
>>>>>   I found this just now after I saw your DotGitMonitor.  You can define
>>>>> a RefreshProvider in the framework that auto-polls resources and
>>>>> subdirectories and handles changes.
>>>>>
>>>>> http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/refresh/RefreshProvider.html
>>>>> --
>>>>> Patrick
>>>>>
>>>>>
>>>
>
>
> -------------------------------------------------------------------------
> 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
>

Re: [Gitclipse-devel] Auto Refresh Provider

[Paul M. B. <pm...@ny...>]

I am not polling the whole tree...  just the .git/HEAD and objects files.  
I am letting the standard eclipse stuff poll the tree.

As I mentioned below, I don't think '.git' has an IResource associated.

----- Original Message -----
From: Patrick Winters <pat...@ny...>
Date: Thursday, July 31, 2008 5:08 pm
Subject: Re: Auto Refresh Provider
To: Paul Munson Bethe <pm...@ny...>
Cc: gitclipse-devel <git...@li...>


> Still, if we need to detect user operations outside eclipse can't we
> offer a RefreshProvider for the .git resources?  Do we still need to
> poll the entire project tree?
> 
> On Thu, 2008-07-31 at 16:58 -0400, Paul Munson Bethe wrote:
> > OK - but we would still need this or similar to detect user 
> operations outside eclipse.
> > 
> > 
> > ----- Original Message -----
> > From: Patrick Winters <pat...@ny...>
> > Date: Thursday, July 31, 2008 4:56 pm
> > Subject: Re: Auto Refresh Provider
> > To: Paul Munson Bethe <pm...@ny...>
> > Cc: gitclipse-devel <git...@li...>
> > 
> > 
> > > But we shouldn't have to poll the filesystem to be aware of a commit.
> > > All Git operations should notify the workspace or our plugin to refresh
> > > automatically.  Right?
> > > --
> > > Patrick
> > > 
> > > On Thu, 2008-07-31 at 16:54 -0400, Paul Munson Bethe wrote:
> > > > I tried using that, but I don't think it does what you think it 
> does 
> > > (that was part of my 2 days).
> > > > 
> > > > If you can figure out how to use this instead, you are 
> welcome...  
> > > > but I think the idea for it was if you had a better method than 
> 
> > > file-system polling.
> > > > 
> > > > But you see, when you commit a file, that file does not change.  
> So 
> > > hitting refresh does nothing.
> > > > And since the .git/ is a meta-file, it is not treated as an IResource...
> > > > That is why I went the route I did.
> > > > 
> > > > -P
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > From: Patrick Winters <pat...@ny...>
> > > > Date: Thursday, July 31, 2008 4:48 pm
> > > > Subject: Auto Refresh Provider
> > > > To: gitclipse-devel <git...@li...>, 
> Paul 
> > > Munson Bethe <pm...@ny...>
> > > > 
> > > > 
> > > > > Paul,
> > > > >   I found this just now after I saw your DotGitMonitor.  You 
> can define
> > > > > a RefreshProvider in the framework that auto-polls resources and
> > > > > subdirectories and handles changes.
> > > > > 
> > > > > http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/refresh/RefreshProvider.html
> > > > > --
> > > > > Patrick
> > > > > 
> > > > > 
> > > 
> 

Re: [Gitclipse-devel] Modifying GitStatusAdapter

[Patrick W. <pat...@ny...>]

Okay.  External projects that are somewhere down the repository tree are
auto-associating.  I make a call to GitStatus to determine their
eligibility.  But our commands aren't working because of the way we use
IResource and javagit requires absolute paths.

I'll try and take a look at it.  Are we going to stick with only a
project status cache?  I feel like we need two classes.
GitStatusAdapter and GitStatusAdapterResponse.  We should construct the
adapter on a project, which will handle absolute/relative problems with
projects and accept IResources; and then the adapter response should
spit back only project relative IResources.

If you wanted a full project cache you should do something like:
status = new GitStatusAdapter(IProject project);
status.getProjectStatus()

and have this available as well.
status.getStatus(IResource);

We're going to run into problems, like what I'm seeing in commit now
unless we provide adapters for all javagit commands to seamlessly handle
externally resolved projects and files.  We can hack it for now, but it
requires a lot of annoyance.  The short term option is employing some
utility to extract absolute java.io.File from all IResources and using
this exclusively.


On Thu, 2008-07-31 at 16:17 -0400, Paul Munson Bethe wrote:
> Hmmm....  probably true.
> 
> Have a look then and try to improve it!
> 
> 
> ----- Original Message -----
> From: Patrick Winters <pat...@ny...>
> Date: Thursday, July 31, 2008 4:11 pm
> Subject: Re: [Gitclipse-devel] Modifying GitStatusAdapter
> To: Paul Munson Bethe <pm...@ny...>
> Cc: git...@li...
> 
> 
> > Ok cool, sorry I missed that.  But this still isn't dealing with
> > external projects right?
> > 
> > On Thu, 2008-07-31 at 16:07 -0400, Paul Munson Bethe wrote:
> > > Already done...
> > > 
> > > look at GitStatusAdapter.getStatus
> > > 
> > > -PB
> > > 
> > > ----- Original Message -----
> > > From: Patrick Winters <pat...@ny...>
> > > Date: Thursday, July 31, 2008 4:00 pm
> > > Subject: [Gitclipse-devel] Modifying GitStatusAdapter
> > > To: git...@li...
> > > 
> > > 
> > > > Hey everyone,
> > > >   I think it a good idea to modify GitStatusAdapter a bit.  We 
> > need to
> > > > be able to get the status of files and directories individually.  
> > We
> > > > should have GitStatusAdapter instantiate a GitStatus object on
> > > > construction, and have methods to get IProject/IFile/IFolder status.
> > > >   When we import external projects into Eclipse (which I started testing
> > > > but haven't committed), the IResource paths are relative to the project
> > > > root.  To get the absolute file, we have to do some magic.  Having 
> > a
> > > > GitStatusAdapter automatically translate from relative to absolute 
> > is 
> > > > a
> > > > big time saver.
> > > >   Is everyone game or should I branch and do a code review?
> > > > --
> > > > Patrick
> > > > 
> > > > 
> > > > 
> > > > -------------------------------------------------------------------------
> > > > 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
> > 

Re: [Gitclipse-devel] Auto Refresh Provider

[Patrick W. <pat...@ny...>]

Still, if we need to detect user operations outside eclipse can't we
offer a RefreshProvider for the .git resources?  Do we still need to
poll the entire project tree?

On Thu, 2008-07-31 at 16:58 -0400, Paul Munson Bethe wrote:
> OK - but we would still need this or similar to detect user operations outside eclipse.
> 
> 
> ----- Original Message -----
> From: Patrick Winters <pat...@ny...>
> Date: Thursday, July 31, 2008 4:56 pm
> Subject: Re: Auto Refresh Provider
> To: Paul Munson Bethe <pm...@ny...>
> Cc: gitclipse-devel <git...@li...>
> 
> 
> > But we shouldn't have to poll the filesystem to be aware of a commit.
> > All Git operations should notify the workspace or our plugin to refresh
> > automatically.  Right?
> > --
> > Patrick
> > 
> > On Thu, 2008-07-31 at 16:54 -0400, Paul Munson Bethe wrote:
> > > I tried using that, but I don't think it does what you think it does 
> > (that was part of my 2 days).
> > > 
> > > If you can figure out how to use this instead, you are welcome...  
> > > but I think the idea for it was if you had a better method than 
> > file-system polling.
> > > 
> > > But you see, when you commit a file, that file does not change.  So 
> > hitting refresh does nothing.
> > > And since the .git/ is a meta-file, it is not treated as an IResource...
> > > That is why I went the route I did.
> > > 
> > > -P
> > > 
> > > 
> > > ----- Original Message -----
> > > From: Patrick Winters <pat...@ny...>
> > > Date: Thursday, July 31, 2008 4:48 pm
> > > Subject: Auto Refresh Provider
> > > To: gitclipse-devel <git...@li...>, Paul 
> > Munson Bethe <pm...@ny...>
> > > 
> > > 
> > > > Paul,
> > > >   I found this just now after I saw your DotGitMonitor.  You can define
> > > > a RefreshProvider in the framework that auto-polls resources and
> > > > subdirectories and handles changes.
> > > > 
> > > > http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/refresh/RefreshProvider.html
> > > > --
> > > > Patrick
> > > > 
> > > > 
> > 

Re: [Gitclipse-devel] Auto Refresh Provider

[Paul M. B. <pm...@ny...>]

OK - but we would still need this or similar to detect user operations outside eclipse.


----- Original Message -----
From: Patrick Winters <pat...@ny...>
Date: Thursday, July 31, 2008 4:56 pm
Subject: Re: Auto Refresh Provider
To: Paul Munson Bethe <pm...@ny...>
Cc: gitclipse-devel <git...@li...>


> But we shouldn't have to poll the filesystem to be aware of a commit.
> All Git operations should notify the workspace or our plugin to refresh
> automatically.  Right?
> --
> Patrick
> 
> On Thu, 2008-07-31 at 16:54 -0400, Paul Munson Bethe wrote:
> > I tried using that, but I don't think it does what you think it does 
> (that was part of my 2 days).
> > 
> > If you can figure out how to use this instead, you are welcome...  
> > but I think the idea for it was if you had a better method than 
> file-system polling.
> > 
> > But you see, when you commit a file, that file does not change.  So 
> hitting refresh does nothing.
> > And since the .git/ is a meta-file, it is not treated as an IResource...
> > That is why I went the route I did.
> > 
> > -P
> > 
> > 
> > ----- Original Message -----
> > From: Patrick Winters <pat...@ny...>
> > Date: Thursday, July 31, 2008 4:48 pm
> > Subject: Auto Refresh Provider
> > To: gitclipse-devel <git...@li...>, Paul 
> Munson Bethe <pm...@ny...>
> > 
> > 
> > > Paul,
> > >   I found this just now after I saw your DotGitMonitor.  You can define
> > > a RefreshProvider in the framework that auto-polls resources and
> > > subdirectories and handles changes.
> > > 
> > > http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/refresh/RefreshProvider.html
> > > --
> > > Patrick
> > > 
> > > 
> 

Re: [Gitclipse-devel] Auto Refresh Provider

[Patrick W. <pat...@ny...>]

But we shouldn't have to poll the filesystem to be aware of a commit.
All Git operations should notify the workspace or our plugin to refresh
automatically.  Right?
--
Patrick

On Thu, 2008-07-31 at 16:54 -0400, Paul Munson Bethe wrote:
> I tried using that, but I don't think it does what you think it does (that was part of my 2 days).
> 
> If you can figure out how to use this instead, you are welcome...  
> but I think the idea for it was if you had a better method than file-system polling.
> 
> But you see, when you commit a file, that file does not change.  So hitting refresh does nothing.
> And since the .git/ is a meta-file, it is not treated as an IResource...
> That is why I went the route I did.
> 
> -P
> 
> 
> ----- Original Message -----
> From: Patrick Winters <pat...@ny...>
> Date: Thursday, July 31, 2008 4:48 pm
> Subject: Auto Refresh Provider
> To: gitclipse-devel <git...@li...>, Paul Munson Bethe <pm...@ny...>
> 
> 
> > Paul,
> >   I found this just now after I saw your DotGitMonitor.  You can define
> > a RefreshProvider in the framework that auto-polls resources and
> > subdirectories and handles changes.
> > 
> > http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/refresh/RefreshProvider.html
> > --
> > Patrick
> > 
> > 

Re: [Gitclipse-devel] Auto Refresh Provider

[Paul M. B. <pm...@ny...>]

I tried using that, but I don't think it does what you think it does (that was part of my 2 days).

If you can figure out how to use this instead, you are welcome...  
but I think the idea for it was if you had a better method than file-system polling.

But you see, when you commit a file, that file does not change.  So hitting refresh does nothing.
And since the .git/ is a meta-file, it is not treated as an IResource...
That is why I went the route I did.

-P


----- Original Message -----
From: Patrick Winters <pat...@ny...>
Date: Thursday, July 31, 2008 4:48 pm
Subject: Auto Refresh Provider
To: gitclipse-devel <git...@li...>, Paul Munson Bethe <pm...@ny...>


> Paul,
>   I found this just now after I saw your DotGitMonitor.  You can define
> a RefreshProvider in the framework that auto-polls resources and
> subdirectories and handles changes.
> 
> http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/refresh/RefreshProvider.html
> --
> Patrick
> 
> 

[Gitclipse-devel] dotGit changes

[Paul M. B. <pm...@ny...>]

Folks,

I have added a very crude monitor thread which checks for changes to the .git environment.

* It is clunky, and does not use much of the framework, as 2 days of work did not yield how to put it inside
* So I run a thread every 5 seconds and check the timestamps of the .git/HEAD and .git/objects for changes
** This is b/c every time you run git-status, it modifies the .git/index file.  (so simply checking for changes to .git/ does not work)
* If I detect a change -- which will occur if you do a git operation both inside AND outside the framework -- I touch all of the project IResources and force a refresh.  I wish I could touch fewer, but I am not aware of an easy way to detect what to touch.  FYI - that touch is only to the eclipse IResource (not the File in the system).  The refresh handles redecoration and the branch name on the project.
* This works for both projects with .git in root and projects whose .git file is up some # of levels > 0
* currently, there is a thread for each project.  That could get ugly if a user had hundreds of projects open, but I am trying to do the simplest thing that works correctly for Tuesday's alpha.

I have added a code-review Gitclipse-15

-Paul

[Gitclipse-devel] Auto Refresh Provider

[Patrick W. <pat...@ny...>]

Paul,
  I found this just now after I saw your DotGitMonitor.  You can define
a RefreshProvider in the framework that auto-polls resources and
subdirectories and handles changes.

http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/refresh/RefreshProvider.html
--
Patrick

Re: [Gitclipse-devel] Modifying GitStatusAdapter

[Paul M. B. <pm...@ny...>]

Hmmm....  probably true.

Have a look then and try to improve it!


----- Original Message -----
From: Patrick Winters <pat...@ny...>
Date: Thursday, July 31, 2008 4:11 pm
Subject: Re: [Gitclipse-devel] Modifying GitStatusAdapter
To: Paul Munson Bethe <pm...@ny...>
Cc: git...@li...


> Ok cool, sorry I missed that.  But this still isn't dealing with
> external projects right?
> 
> On Thu, 2008-07-31 at 16:07 -0400, Paul Munson Bethe wrote:
> > Already done...
> > 
> > look at GitStatusAdapter.getStatus
> > 
> > -PB
> > 
> > ----- Original Message -----
> > From: Patrick Winters <pat...@ny...>
> > Date: Thursday, July 31, 2008 4:00 pm
> > Subject: [Gitclipse-devel] Modifying GitStatusAdapter
> > To: git...@li...
> > 
> > 
> > > Hey everyone,
> > >   I think it a good idea to modify GitStatusAdapter a bit.  We 
> need to
> > > be able to get the status of files and directories individually.  
> We
> > > should have GitStatusAdapter instantiate a GitStatus object on
> > > construction, and have methods to get IProject/IFile/IFolder status.
> > >   When we import external projects into Eclipse (which I started testing
> > > but haven't committed), the IResource paths are relative to the project
> > > root.  To get the absolute file, we have to do some magic.  Having 
> a
> > > GitStatusAdapter automatically translate from relative to absolute 
> is 
> > > a
> > > big time saver.
> > >   Is everyone game or should I branch and do a code review?
> > > --
> > > Patrick
> > > 
> > > 
> > > 
> > > -------------------------------------------------------------------------
> > > 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
> 

Re: [Gitclipse-devel] Modifying GitStatusAdapter

[Patrick W. <pat...@ny...>]

Ok cool, sorry I missed that.  But this still isn't dealing with
external projects right?

On Thu, 2008-07-31 at 16:07 -0400, Paul Munson Bethe wrote:
> Already done...
> 
> look at GitStatusAdapter.getStatus
> 
> -PB
> 
> ----- Original Message -----
> From: Patrick Winters <pat...@ny...>
> Date: Thursday, July 31, 2008 4:00 pm
> Subject: [Gitclipse-devel] Modifying GitStatusAdapter
> To: git...@li...
> 
> 
> > Hey everyone,
> >   I think it a good idea to modify GitStatusAdapter a bit.  We need to
> > be able to get the status of files and directories individually.  We
> > should have GitStatusAdapter instantiate a GitStatus object on
> > construction, and have methods to get IProject/IFile/IFolder status.
> >   When we import external projects into Eclipse (which I started testing
> > but haven't committed), the IResource paths are relative to the project
> > root.  To get the absolute file, we have to do some magic.  Having a
> > GitStatusAdapter automatically translate from relative to absolute is 
> > a
> > big time saver.
> >   Is everyone game or should I branch and do a code review?
> > --
> > Patrick
> > 
> > 
> > 
> > -------------------------------------------------------------------------
> > 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

Re: [Gitclipse-devel] Modifying GitStatusAdapter

[Paul M. B. <pm...@ny...>]

Already done...

look at GitStatusAdapter.getStatus

-PB

----- Original Message -----
From: Patrick Winters <pat...@ny...>
Date: Thursday, July 31, 2008 4:00 pm
Subject: [Gitclipse-devel] Modifying GitStatusAdapter
To: git...@li...


> Hey everyone,
>   I think it a good idea to modify GitStatusAdapter a bit.  We need to
> be able to get the status of files and directories individually.  We
> should have GitStatusAdapter instantiate a GitStatus object on
> construction, and have methods to get IProject/IFile/IFolder status.
>   When we import external projects into Eclipse (which I started testing
> but haven't committed), the IResource paths are relative to the project
> root.  To get the absolute file, we have to do some magic.  Having a
> GitStatusAdapter automatically translate from relative to absolute is 
> a
> big time saver.
>   Is everyone game or should I branch and do a code review?
> --
> Patrick
> 
> 
> 
> -------------------------------------------------------------------------
> 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

[Gitclipse-devel] Modifying GitStatusAdapter

[Patrick W. <pat...@ny...>]

Hey everyone,
  I think it a good idea to modify GitStatusAdapter a bit.  We need to
be able to get the status of files and directories individually.  We
should have GitStatusAdapter instantiate a GitStatus object on
construction, and have methods to get IProject/IFile/IFolder status.
  When we import external projects into Eclipse (which I started testing
but haven't committed), the IResource paths are relative to the project
root.  To get the absolute file, we have to do some magic.  Having a
GitStatusAdapter automatically translate from relative to absolute is a
big time saver.
  Is everyone game or should I branch and do a code review?
--
Patrick

Re: [Gitclipse-devel] Commit question

[Paul M. B. <pm...@ny...>]

You are right -- I was just expounding on Andrew's idea of having

Team -> Commit -> Staged 
                         -> All
                         -> This   (maybe a better word?  'Dot', ?) 

etc. rather than having radio buttons on the commit GUI -- but for now I don't think I care.

SO - the bug I submitted was really thinking about that.

So under the current scheme it is not really a bug.  I will remark it.


----- Original Message -----
From: Michelle S Osborne <ms...@ny...>
Date: Thursday, July 31, 2008 12:38 pm
Subject: Re: [Gitclipse-devel] Commit question
To: Paul Munson Bethe <pm...@ny...>
Cc: Andrew Case <ac...@co...>, gitclipse-devel <git...@li...>


> 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

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

Re: [Gitclipse-devel] Commit question

[Paul M. B. <pm...@ny...>]

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

Re: [Gitclipse-devel] Eclipse Undo

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

Should have read:

Can you put the final stopper bugs you're working on up....

Thanks,

--
Drew

> Gitclipsers:
>
> Can put the final "stopper" bugs they're working on up on the sourceforge 
> bug-tracker (to make us look like we're an active project).
>
> Thanks,
>
> --
> Drew
>
>
> On Thu, 31 Jul 2008, Patrick Winters wrote:
>
>> I would inspect the Subclipse codebase.
>> Just so you're aware there's an IUndoableOperation interface ...
>> http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.doc.isv
>> /reference/api/org/eclipse/core/commands/operations/IUndoableOperation.html
>> 
>> I believe there's different types of operation histories too, so good luck.
>> 
>>> -----Original Message-----
>>> From: git...@li... [mailto:gitclipse-
>>> dev...@li...] On Behalf Of Andrew Case
>>> Sent: Thursday, July 31, 2008 12:29 AM
>>> To: gitclipse-devel
>>> Subject: [Gitclipse-devel] Eclipse Undo
>>> 
>>> So now that GitMoveDeleteHook is working, I was wondering if anyone
>>> knows
>>> how to hook into Undo or where to start looking for this?  Currently if
>>> I
>>> delete a file, and then undo it, git still thinks the file is staged
>>> for
>>> deletion and that there is a new untracked file in it's place.
>>> 
>>> --
>>> Drew
>>> 
>>> -----------------------------------------------------------------------
>>> --
>>> 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
>> 
>> 
>