threads / patch / 18951

patchAdd support for writing/appending .gitignore file

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

## tl;dr

6 messages between Apr 19, 2009 and Apr 20, 2009. Diffs are folded; open one to read it.

replies: 5people: 2as markdown or json

Alex Blewitt· Apr 19, 2009, 13:09 UTC · lore

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(-)
Show changes to 2 files +42 −6

org.spearce.egit.ui/src/org/spearce/egit/ui/internal/, org.spearce.egit.ui/src/org/spearce/egit/ui/internal/actions/

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
Robin Rosenberg· Apr 19, 2009, 21:50 UTC · re: Alex Blewitt · lore

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

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.
Show 7 quoted lines
> +	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
Show 7 quoted lines
>   		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.
Show 26 quoted lines
> +		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.

Show 11 quoted lines
> +				}
>   			}
> +		} 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
Alex Blewitt· Apr 20, 2009, 02:40 UTC · re: Robin Rosenberg · lore

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

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
Robin Rosenberg· Apr 20, 2009, 06:32 UTC · re: Alex Blewitt · lore

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

måndag 20 april 2009 04:40:42 skrev Alex Blewitt <alex.blewitt@gmail.com>:
Show 15 quoted lines
> 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
Alex Blewitt· Apr 20, 2009, 07:55 UTC · re: Robin Rosenberg · lore

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

On 20 Apr 2009, at 07:32, Robin Rosenberg wrote:
Show 14 quoted lines
> 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.

Show 11 quoted lines
>> 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
Robin Rosenberg· Apr 20, 2009, 17:09 UTC · re: Alex Blewitt · lore

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

måndag 20 april 2009 09:55:54 skrev Alex Blewitt <alex.blewitt@gmail.com>:
Show 20 quoted lines
> 
> 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.

Show 16 quoted lines
> 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

← back to recent threads