[EGIT PATCH] Add support for writing/appending .gitignore file

[EGIT PATCH] Add support for writing/appending .gitignore file

[Alex Blewitt]

This is in addition to the other patches mailed earlier and attached  
with issue 64

 From 34fd7fc8cd721c4f44b5b31d3d5960f89b59bf8b Mon Sep 17 00:00:00 2001
From: Alex Blewitt <alex.blewitt@gmail.com>
Date: Sun, 19 Apr 2009 14:03:46 +0100
Subject: [PATCH] Added support for writing/appending .gitignore file

---
  .../egit/ui/internal/actions/IgnoreAction.java     |   48 +++++++++++ 
++++++---
  1 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/ 
actions/IgnoreAction.java b/org.spearce.egit.ui/src/org/spearce/egit/ 
ui/internal/actions/IgnoreAction.java
index 1215823..832b098 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/actions/ 
IgnoreAction.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/actions/ 
IgnoreAction.java
@@ -7,7 +7,17 @@
    
*******************************************************************************/
  package org.spearce.egit.ui.internal.actions;

+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+import java.io.UnsupportedEncodingException;
+
+import org.eclipse.core.resources.IContainer;
+import org.eclipse.core.resources.IFile;
  import org.eclipse.core.resources.IResource;
+import org.eclipse.core.runtime.CoreException;
+import org.eclipse.core.runtime.NullProgressMonitor;
+import org.eclipse.core.runtime.Path;
  import org.eclipse.jface.action.IAction;
  import org.eclipse.team.core.Team;

@@ -17,17 +27,43 @@
   */
  public class IgnoreAction extends RepositoryAction {
  	
+	private static final String GITIGNORE_ENCODING = "UTF-8";
+	private static final String GITIGNORE = ".gitignore";
+
  	@SuppressWarnings("restriction")
  	@Override
  	public void run(IAction action) {
-
+		NullProgressMonitor m = new NullProgressMonitor();
  		IResource[] resources = getSelectedResources();
-		for (IResource resource : resources) {
-			// NB This does the same thing in DecoratableResourceAdapter, but  
neither currently consult .gitignore
-			if (!Team.isIgnoredHint(resource))
-			{
-				// TODO Actually add to .gitignore here
+		try {
+			for (IResource resource : resources) {
+				// TODO This is pretty inefficient; multiple ignores in the same  
directory cause multiple writes.
+				// NB This does the same thing in DecoratableResourceAdapter, but  
neither currently consult .gitignore
+				if (!Team.isIgnoredHint(resource)) {
+					IContainer container = resource.getParent();
+					IFile gitignore = container.getFile(new Path(GITIGNORE));
+					String entry = "/" + resource.getName() + "\n"; //$NON-NLS-1$  // 
$NON-NLS-2$
+					// TODO What is the character set and new-line convention?
+					if(gitignore.exists()) {
+						// This is ugly. CVS uses an internal representation of  
the .gitignore to re-write/overwrite each time.
+						ByteArrayOutputStream out = new ByteArrayOutputStream(2048);
+						out.write(entry.getBytes(GITIGNORE_ENCODING)); // TODO Default  
encoding?
+						gitignore.appendContents(new  
ByteArrayInputStream(out.toByteArray()),true,true,m);
+					} else {
+						ByteArrayInputStream bais = new  
ByteArrayInputStream( entry.getBytes(GITIGNORE_ENCODING) ); //$NON- 
NLS-1$
+						gitignore.create( bais,true,m);					
+					}
+				}
  			}
+		} catch (UnsupportedEncodingException e) {
+			// TODO Auto-generated catch block
+			e.printStackTrace();
+		} catch (CoreException e) {
+			// TODO Auto-generated catch block
+			e.printStackTrace();
+		} catch (IOException e) {
+			// TODO Auto-generated catch block
+			e.printStackTrace();
  		}
  		return;
  	}
-- 
1.6.2.2

Re: [EGIT PATCH] Add support for writing/appending .gitignore file

[Robin Rosenberg]

First, Ferry Huberts is also working on a solution for ignore See 
http://thread.gmane.org/gmane.comp.version-control.git/114825 though you 
focus on different aspects.

söndag 19 april 2009 15:09:32 skrev Alex Blewitt <alex.blewitt@gmail.com>:
> This is in addition to the other patches mailed earlier and attached  
> with issue 64

This patch is whitespace damaged.  Pasting into gmail won't work. Gmail
has authenticated SMTP on port 25 and 465 (SSL) so git-send-email should work that way.

> +	private static final String GITIGNORE_ENCODING = "UTF-8";

For the time being we use Constants.CHARACTER_ENCODING (which
is UTF-8). There are some problems with that too. We read an
interpret (by guessing) (using RawParseUtils.decode) and write UTF-8 (always).
This is one of git's weak spots; it doesn't define encoding of stuff. For
JGit we do (it's perfectly valid since it's not defined). Our internal
encoding is UTF-8, with fallbacks for accepting other encodings if
it doesn't look like UTF-8. See RawParseUtils.decode() for details.

You may also want to look at msysgit's list of encoding related bug reports.

> +	private static final String GITIGNORE = ".gitignore";
> +
>   	@SuppressWarnings("restriction")
>   	@Override
>   	public void run(IAction action) {
> -
> +		NullProgressMonitor m = new NullProgressMonitor();
I guess this method should execute fairly fast, but in general we should run
with a real progress monitor. See an action, like Track (maybe we should
rename to TrackAction...).

	getTargetPart().getSite().getWorkbenchWindow().run

>   		IResource[] resources = getSelectedResources();
> -		for (IResource resource : resources) {
> -			// NB This does the same thing in DecoratableResourceAdapter, but  
> neither currently consult .gitignore
> -			if (!Team.isIgnoredHint(resource))
> -			{
> -				// TODO Actually add to .gitignore here

I think this series should be one patch only.

> +		try {
> +			for (IResource resource : resources) {
> +				// TODO This is pretty inefficient; multiple ignores in the same  
> directory cause multiple writes.
> +				// NB This does the same thing in DecoratableResourceAdapter, but  
> neither currently consult .gitignore
> +				if (!Team.isIgnoredHint(resource)) {
> +					IContainer container = resource.getParent();
> +					IFile gitignore = container.getFile(new Path(GITIGNORE));
> +					String entry = "/" + resource.getName() + "\n"; //$NON-NLS-1$  // 
> $NON-NLS-2$
> +					// TODO What is the character set and new-line convention?
> +					if(gitignore.exists()) {
> +						// This is ugly. CVS uses an internal representation of  
> the .gitignore to re-write/overwrite each time.
> +						ByteArrayOutputStream out = new ByteArrayOutputStream(2048);
> +						out.write(entry.getBytes(GITIGNORE_ENCODING)); // TODO Default  
> encoding?
> +						gitignore.appendContents(new  
> ByteArrayInputStream(out.toByteArray()),true,true,m);
> +					} else {
> +						ByteArrayInputStream bais = new  
> ByteArrayInputStream( entry.getBytes(GITIGNORE_ENCODING) ); //$NON- 
> NLS-1$
> +						gitignore.create( bais,true,m);					
> +					}
The character encoding issues, I think, should be interpreted such that we rewrite the whole
file in the same encoding, should it actually change.

> +				}
>   			}
> +		} catch (UnsupportedEncodingException e) {
> +			// TODO Auto-generated catch block
> +			e.printStackTrace();
> +		} catch (CoreException e) {
> +			// TODO Auto-generated catch block
> +			e.printStackTrace();
> +		} catch (IOException e) {
> +			// TODO Auto-generated catch block
> +			e.printStackTrace();

Some actual error logging would be nice. Activator.logError for just logging and MessageDialog.openError
for posting an error message to the user.

>   		}
>   		return;
>   	}

-- robin

Re: [EGIT PATCH] Add support for writing/appending .gitignore file

[Alex Blewitt]

On Sun, Apr 19, 2009 at 10:50 PM, Robin Rosenberg
<robin.rosenberg.lists@dewire.com> wrote:
>
> First, Ferry Huberts is also working on a solution for ignore See
> http://thread.gmane.org/gmane.comp.version-control.git/114825 though you
> focus on different aspects.

Yup, saw the issue 32. I'll keep an eye on that and hopefully I can
leverage what that does when it's ready.

> This patch is whitespace damaged.  Pasting into gmail won't work. Gmail
> has authenticated SMTP on port 25 and 465 (SSL) so git-send-email should work that way.

One advantage of attaching issues is you don't have MUA problems :-)
I'll try and get a patch to work via git-send-email later.

>> +     private static final String GITIGNORE_ENCODING = "UTF-8";
>
> For the time being we use Constants.CHARACTER_ENCODING

Great, thought there'd be something already. Will use that.

>> +             NullProgressMonitor m = new NullProgressMonitor();
> I guess this method should execute fairly fast, but in general we should run
> with a real progress monitor. See an action, like Track (maybe we should
> rename to TrackAction...).

OK, will put in a real one.

> I think this series should be one patch only.

I've been incrementally committing to my local git copy. Whenever I do
git format-patch <since> it spews out individual patchettes. How can I
use git to generate one patch? I could git diff <since>, but that's
not following the SUBMITTING_PATCHES, is it?

> Some actual error logging would be nice. Activator.logError for just logging and MessageDialog.openError
> for posting an error message to the user.

Righto, next on the list.

Alex

Re: [EGIT PATCH] Add support for writing/appending .gitignore file

[Robin Rosenberg]

måndag 20 april 2009 04:40:42 skrev Alex Blewitt <alex.blewitt@gmail.com>:
> On Sun, Apr 19, 2009 at 10:50 PM, Robin Rosenberg
> <robin.rosenberg.lists@dewire.com> wrote:
> >
> > First, Ferry Huberts is also working on a solution for ignore See
> > http://thread.gmane.org/gmane.comp.version-control.git/114825 though you
> > focus on different aspects.
> 
> Yup, saw the issue 32. I'll keep an eye on that and hopefully I can
> leverage what that does when it's ready.
> 
> > This patch is whitespace damaged. Â Pasting into gmail won't work. Gmail
> > has authenticated SMTP on port 25 and 465 (SSL) so git-send-email should work that way.
> 
> One advantage of attaching issues is you don't have MUA problems :-)
> I'll try and get a patch to work via git-send-email later.

The problem is review. With e-mail I can just hit reply and comment on your
patch. Did your try the SMTP interface to gmail? I think e-mailing inlined patches is
a nearly perfect. Inline-attachment is ok with me. That makes it possible to
comment on them like any email in my mail program.

> I've been incrementally committing to my local git copy. Whenever I do
> git format-patch <since> it spews out individual patchettes. How can I
> use git to generate one patch? I could git diff <since>, but that's
> not following the SUBMITTING_PATCHES, is it?

Often, after a long session, you end up with a "mess" of commits, many which
don't make sense to anyone but you. For this you use rebase -i to clean up.
It allows you to reorder, squash and edit commits. You'll end up with an entirely
new version of your branch. Retest to make sure it's ok and submit. 

-- robin

Re: [EGIT PATCH] Add support for writing/appending .gitignore file

[Alex Blewitt]

On 20 Apr 2009, at 07:32, Robin Rosenberg wrote:

> måndag 20 april 2009 04:40:42 skrev Alex Blewitt <alex.blewitt@gmail.com 
> >:
>> On Sun, Apr 19, 2009 at 10:50 PM, Robin Rosenberg
>> <robin.rosenberg.lists@dewire.com> wrote:
>> One advantage of attaching issues is you don't have MUA problems :-)
>> I'll try and get a patch to work via git-send-email later.
>
> The problem is review. With e-mail I can just hit reply and comment  
> on your
> patch. Did your try the SMTP interface to gmail? I think e-mailing  
> inlined patches is
> a nearly perfect. Inline-attachment is ok with me. That makes it  
> possible to
> comment on them like any email in my mail program.

Right, but the same approach is possible in a bug tracking system -  
just comment. And people get a notification that a change has  
occurred, too. Except instead of one giant inbox of a collection of  
patches, all the discussion/feedback/comments are limited to the right  
scope (i.e. just that bug/patch). In fact, quite a lot of review goes  
on outside of the mail client and directly inside the editor e.g. via  
Mylyn or internal web browser to the issue.

It also allows others - who might not be on the original 'to' list -  
to subscribe to a bug (or star it, in Google's terms) to receive  
notifications and see specific updates.

>> I've been incrementally committing to my local git copy. Whenever I  
>> do
>> git format-patch <since> it spews out individual patchettes. How  
>> can I
>> use git to generate one patch? I could git diff <since>, but that's
>> not following the SUBMITTING_PATCHES, is it?
>
> Often, after a long session, you end up with a "mess" of commits,  
> many which
> don't make sense to anyone but you. For this you use rebase -i to  
> clean up.

Great, that's useful to know. Unfortunately, I get an error when I try  
this:

apple:egit alex$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 9 commits.
#
nothing to commit (working directory clean)

apple:egit alex$ git rebase -i origin/master
Working tree is dirty
apple:egit alex$ git rebase -i d0fd6f96b9311b972c6bffa8680544607d7e3c56
Working tree is dirty
apple:egit alex$

I'm probably doing something obviously wrong here, but I don't know  
how to understand the difference between 'working tree is dirty' and  
'working directory clean', especially since git status (or git commit - 
a) doesn't show any differences.

Please excuse me whilst I figure out how to get comfortable working  
with git ...

Alex
	

Re: [EGIT PATCH] Add support for writing/appending .gitignore file

[Robin Rosenberg]

måndag 20 april 2009 09:55:54 skrev Alex Blewitt <alex.blewitt@gmail.com>:
> 
> On 20 Apr 2009, at 07:32, Robin Rosenberg wrote:
> 
> > måndag 20 april 2009 04:40:42 skrev Alex Blewitt <alex.blewitt@gmail.com 
> > >:
> >> On Sun, Apr 19, 2009 at 10:50 PM, Robin Rosenberg
> >> <robin.rosenberg.lists@dewire.com> wrote:
> >> One advantage of attaching issues is you don't have MUA problems :-)
> >> I'll try and get a patch to work via git-send-email later.
> >
> > The problem is review. With e-mail I can just hit reply and comment  
> > on your
> > patch. Did your try the SMTP interface to gmail? I think e-mailing  
> > inlined patches is
> > a nearly perfect. Inline-attachment is ok with me. That makes it  
> > possible to
> > comment on them like any email in my mail program.
> 
> Right, but the same approach is possible in a bug tracking system -  
> just comment. And people get a notification that a change has  
I haven't seen that. Obviously a bugtracker could cite the patch, but
I don't know any that do.

> apple:egit alex$ git status
> # On branch master
> # Your branch is ahead of 'origin/master' by 9 commits.
> #
> nothing to commit (working directory clean)
> 
> apple:egit alex$ git rebase -i origin/master
> Working tree is dirty
> apple:egit alex$ git rebase -i d0fd6f96b9311b972c6bffa8680544607d7e3c56
> Working tree is dirty
> apple:egit alex$
> 
> I'm probably doing something obviously wrong here, but I don't know  
> how to understand the difference between 'working tree is dirty' and  
> 'working directory clean', especially since git status (or git commit - 
> a) doesn't show any differences.

"obviously" isn't the right word here, or status and rebase would agree
on the cleanliness. If you are using bash I strong suggest you enable
the nice bash prompt with some status information. It's in <gIt>/contrib/completion
if you have the Git source. In a packaged version  you can probably can
source /etc/bash_completion. It will tell you what branch you are on and
state-information, like whether a rebase is in progress or not (you would
get a different message from rebase/status if that was the case).

> Please excuse me whilst I figure out how to get comfortable working  
> with git ...

It took me only ten minutes to find a bug the first time I used git :)

-- robin