{"thread":{"id":"18951","subject":"[EGIT PATCH] Add support for writing/appending .gitignore file","startedAt":"2009-04-19T13:09:32Z","lastAt":"2009-04-20T17:09:38Z","messageCount":6,"participants":["Alex Blewitt","Robin Rosenberg"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"111641","messageId":"AFFAB806-28F7-4D48-B603-B7B96052B0F3@gmail.com","threadId":"18951","inReplyTo":null,"subject":"[EGIT PATCH] Add support for writing/appending .gitignore file","fromName":"Alex Blewitt","fromEmail":"alex.blewitt@gmail.com","sentAt":"2009-04-19T13:09:32Z","receivedAt":"2009-04-19T13:09:32Z","isPatch":true,"sender":{"key":"alex.blewitt@gmail.com","avatar":"https://gravatar.com/avatar/fb95a3b593b290f03a8d3b022c20b2825205702c5651f731f65d33512dfe6ab2?d=mp&s=160"},"body":"This is in addition to the other patches mailed earlier and attached \nwith issue 64\n\n From 34fd7fc8cd721c4f44b5b31d3d5960f89b59bf8b Mon Sep 17 00:00:00 2001\nFrom: Alex Blewitt \nDate: Sun, 19 Apr 2009 14:03:46 +0100\nSubject: [PATCH] Added support for writing/appending .gitignore file\n\n---\n .../egit/ui/internal/actions/IgnoreAction.java | 48 +++++++++++ \n++++++---\n 1 files changed, 42 insertions(+), 6 deletions(-)\n\ndiff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/ \nactions/IgnoreAction.java b/org.spearce.egit.ui/src/org/spearce/egit/ \nui/internal/actions/IgnoreAction.java\nindex 1215823..832b098 100644\n--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/actions/ \nIgnoreAction.java\n+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/actions/ \nIgnoreAction.java\n@@ -7,7 +7,17 @@\n \n*******************************************************************************/\n package org.spearce.egit.ui.internal.actions;\n\n+import java.io.ByteArrayInputStream;\n+import java.io.ByteArrayOutputStream;\n+import java.io.IOException;\n+import java.io.UnsupportedEncodingException;\n+\n+import org.eclipse.core.resources.IContainer;\n+import org.eclipse.core.resources.IFile;\n import org.eclipse.core.resources.IResource;\n+import org.eclipse.core.runtime.CoreException;\n+import org.eclipse.core.runtime.NullProgressMonitor;\n+import org.eclipse.core.runtime.Path;\n import org.eclipse.jface.action.IAction;\n import org.eclipse.team.core.Team;\n\n@@ -17,17 +27,43 @@\n */\n public class IgnoreAction extends RepositoryAction {\n \t\n+\tprivate static final String GITIGNORE_ENCODING = \"UTF-8\";\n+\tprivate static final String GITIGNORE = \".gitignore\";\n+\n \t@SuppressWarnings(\"restriction\")\n \t@Override\n \tpublic void run(IAction action) {\n-\n+\t\tNullProgressMonitor m = new NullProgressMonitor();\n \t\tIResource[] resources = getSelectedResources();\n-\t\tfor (IResource resource : resources) {\n-\t\t\t// NB This does the same thing in DecoratableResourceAdapter, but \nneither currently consult .gitignore\n-\t\t\tif (!Team.isIgnoredHint(resource))\n-\t\t\t{\n-\t\t\t\t// TODO Actually add to .gitignore here\n+\t\ttry {\n+\t\t\tfor (IResource resource : resources) {\n+\t\t\t\t// TODO This is pretty inefficient; multiple ignores in the same \ndirectory cause multiple writes.\n+\t\t\t\t// NB This does the same thing in DecoratableResourceAdapter, but \nneither currently consult .gitignore\n+\t\t\t\tif (!Team.isIgnoredHint(resource)) {\n+\t\t\t\t\tIContainer container = resource.getParent();\n+\t\t\t\t\tIFile gitignore = container.getFile(new Path(GITIGNORE));\n+\t\t\t\t\tString entry = \"/\" + resource.getName() + \"\\n\"; //$NON-NLS-1$ // \n$NON-NLS-2$\n+\t\t\t\t\t// TODO What is the character set and new-line convention?\n+\t\t\t\t\tif(gitignore.exists()) {\n+\t\t\t\t\t\t// This is ugly. CVS uses an internal representation of \nthe .gitignore to re-write/overwrite each time.\n+\t\t\t\t\t\tByteArrayOutputStream out = new ByteArrayOutputStream(2048);\n+\t\t\t\t\t\tout.write(entry.getBytes(GITIGNORE_ENCODING)); // TODO Default \nencoding?\n+\t\t\t\t\t\tgitignore.appendContents(new \nByteArrayInputStream(out.toByteArray()),true,true,m);\n+\t\t\t\t\t} else {\n+\t\t\t\t\t\tByteArrayInputStream bais = new \nByteArrayInputStream( entry.getBytes(GITIGNORE_ENCODING) ); //$NON- \nNLS-1$\n+\t\t\t\t\t\tgitignore.create( bais,true,m);\t\t\t\t\t\n+\t\t\t\t\t}\n+\t\t\t\t}\n \t\t\t}\n+\t\t} catch (UnsupportedEncodingException e) {\n+\t\t\t// TODO Auto-generated catch block\n+\t\t\te.printStackTrace();\n+\t\t} catch (CoreException e) {\n+\t\t\t// TODO Auto-generated catch block\n+\t\t\te.printStackTrace();\n+\t\t} catch (IOException e) {\n+\t\t\t// TODO Auto-generated catch block\n+\t\t\te.printStackTrace();\n \t\t}\n \t\treturn;\n \t}\n-- \n1.6.2.2\n"},{"id":"111661","messageId":"200904192350.56348.robin.rosenberg.lists@dewire.com","threadId":"18951","inReplyTo":"AFFAB806-28F7-4D48-B603-B7B96052B0F3@gmail.com","subject":"Re: [EGIT PATCH] Add support for writing/appending .gitignore file","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-04-19T21:50:55Z","receivedAt":"2009-04-19T21:50:55Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"\nFirst, Ferry Huberts is also working on a solution for ignore See \nhttp://thread.gmane.org/gmane.comp.version-control.git/114825 though you \nfocus on different aspects.\n\nsöndag 19 april 2009 15:09:32 skrev Alex Blewitt :\n> This is in addition to the other patches mailed earlier and attached \n> with issue 64\n\nThis patch is whitespace damaged. Pasting into gmail won't work. Gmail\nhas authenticated SMTP on port 25 and 465 (SSL) so git-send-email should work that way.\n\n> +\tprivate static final String GITIGNORE_ENCODING = \"UTF-8\";\n\nFor the time being we use Constants.CHARACTER_ENCODING (which\nis UTF-8). There are some problems with that too. We read an\ninterpret (by guessing) (using RawParseUtils.decode) and write UTF-8 (always).\nThis is one of git's weak spots; it doesn't define encoding of stuff. For\nJGit we do (it's perfectly valid since it's not defined). Our internal\nencoding is UTF-8, with fallbacks for accepting other encodings if\nit doesn't look like UTF-8. See RawParseUtils.decode() for details.\n\nYou may also want to look at msysgit's list of encoding related bug reports.\n\n> +\tprivate static final String GITIGNORE = \".gitignore\";\n> +\n> \t@SuppressWarnings(\"restriction\")\n> \t@Override\n> \tpublic void run(IAction action) {\n> -\n> +\t\tNullProgressMonitor m = new NullProgressMonitor();\nI guess this method should execute fairly fast, but in general we should run\nwith a real progress monitor. See an action, like Track (maybe we should\nrename to TrackAction...).\n\n\tgetTargetPart().getSite().getWorkbenchWindow().run\n\n> \t\tIResource[] resources = getSelectedResources();\n> -\t\tfor (IResource resource : resources) {\n> -\t\t\t// NB This does the same thing in DecoratableResourceAdapter, but \n> neither currently consult .gitignore\n> -\t\t\tif (!Team.isIgnoredHint(resource))\n> -\t\t\t{\n> -\t\t\t\t// TODO Actually add to .gitignore here\n\nI think this series should be one patch only.\n\n> +\t\ttry {\n> +\t\t\tfor (IResource resource : resources) {\n> +\t\t\t\t// TODO This is pretty inefficient; multiple ignores in the same \n> directory cause multiple writes.\n> +\t\t\t\t// NB This does the same thing in DecoratableResourceAdapter, but \n> neither currently consult .gitignore\n> +\t\t\t\tif (!Team.isIgnoredHint(resource)) {\n> +\t\t\t\t\tIContainer container = resource.getParent();\n> +\t\t\t\t\tIFile gitignore = container.getFile(new Path(GITIGNORE));\n> +\t\t\t\t\tString entry = \"/\" + resource.getName() + \"\\n\"; //$NON-NLS-1$ // \n> $NON-NLS-2$\n> +\t\t\t\t\t// TODO What is the character set and new-line convention?\n> +\t\t\t\t\tif(gitignore.exists()) {\n> +\t\t\t\t\t\t// This is ugly. CVS uses an internal representation of \n> the .gitignore to re-write/overwrite each time.\n> +\t\t\t\t\t\tByteArrayOutputStream out = new ByteArrayOutputStream(2048);\n> +\t\t\t\t\t\tout.write(entry.getBytes(GITIGNORE_ENCODING)); // TODO Default \n> encoding?\n> +\t\t\t\t\t\tgitignore.appendContents(new \n> ByteArrayInputStream(out.toByteArray()),true,true,m);\n> +\t\t\t\t\t} else {\n> +\t\t\t\t\t\tByteArrayInputStream bais = new \n> ByteArrayInputStream( entry.getBytes(GITIGNORE_ENCODING) ); //$NON- \n> NLS-1$\n> +\t\t\t\t\t\tgitignore.create( bais,true,m);\t\t\t\t\t\n> +\t\t\t\t\t}\nThe character encoding issues, I think, should be interpreted such that we rewrite the whole\nfile in the same encoding, should it actually change.\n\n> +\t\t\t\t}\n> \t\t\t}\n> +\t\t} catch (UnsupportedEncodingException e) {\n> +\t\t\t// TODO Auto-generated catch block\n> +\t\t\te.printStackTrace();\n> +\t\t} catch (CoreException e) {\n> +\t\t\t// TODO Auto-generated catch block\n> +\t\t\te.printStackTrace();\n> +\t\t} catch (IOException e) {\n> +\t\t\t// TODO Auto-generated catch block\n> +\t\t\te.printStackTrace();\n\nSome actual error logging would be nice. Activator.logError for just logging and MessageDialog.openError\nfor posting an error message to the user.\n\n> \t\t}\n> \t\treturn;\n> \t}\n\n-- robin\n"},{"id":"111676","messageId":"636fd28e0904191940t3476b016qc76c0e1e624f7b37@mail.gmail.com","threadId":"18951","inReplyTo":"200904192350.56348.robin.rosenberg.lists@dewire.com","subject":"Re: [EGIT PATCH] Add support for writing/appending .gitignore file","fromName":"Alex Blewitt","fromEmail":"alex.blewitt@gmail.com","sentAt":"2009-04-20T02:40:42Z","receivedAt":"2009-04-20T02:40:42Z","isPatch":true,"sender":{"key":"alex.blewitt@gmail.com","avatar":"https://gravatar.com/avatar/fb95a3b593b290f03a8d3b022c20b2825205702c5651f731f65d33512dfe6ab2?d=mp&s=160"},"body":"On Sun, Apr 19, 2009 at 10:50 PM, Robin Rosenberg\n wrote:\n>\n> First, Ferry Huberts is also working on a solution for ignore See\n> http://thread.gmane.org/gmane.comp.version-control.git/114825 though you\n> focus on different aspects.\n\nYup, saw the issue 32. I'll keep an eye on that and hopefully I can\nleverage what that does when it's ready.\n\n> This patch is whitespace damaged.  Pasting into gmail won't work. Gmail\n> has authenticated SMTP on port 25 and 465 (SSL) so git-send-email should work that way.\n\nOne advantage of attaching issues is you don't have MUA problems :-)\nI'll try and get a patch to work via git-send-email later.\n\n>> +     private static final String GITIGNORE_ENCODING = \"UTF-8\";\n>\n> For the time being we use Constants.CHARACTER_ENCODING\n\nGreat, thought there'd be something already. Will use that.\n\n>> +             NullProgressMonitor m = new NullProgressMonitor();\n> I guess this method should execute fairly fast, but in general we should run\n> with a real progress monitor. See an action, like Track (maybe we should\n> rename to TrackAction...).\n\nOK, will put in a real one.\n\n> I think this series should be one patch only.\n\nI've been incrementally committing to my local git copy. Whenever I do\ngit format-patch it spews out individual patchettes. How can I\nuse git to generate one patch? I could git diff , but that's\nnot following the SUBMITTING_PATCHES, is it?\n\n> Some actual error logging would be nice. Activator.logError for just logging and MessageDialog.openError\n> for posting an error message to the user.\n\nRighto, next on the list.\n\nAlex\n"},{"id":"111689","messageId":"200904200832.28361.robin.rosenberg.lists@dewire.com","threadId":"18951","inReplyTo":"636fd28e0904191940t3476b016qc76c0e1e624f7b37@mail.gmail.com","subject":"Re: [EGIT PATCH] Add support for writing/appending .gitignore file","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-04-20T06:32:27Z","receivedAt":"2009-04-20T06:32:27Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"måndag 20 april 2009 04:40:42 skrev Alex Blewitt :\n> On Sun, Apr 19, 2009 at 10:50 PM, Robin Rosenberg\n> wrote:\n> >\n> > First, Ferry Huberts is also working on a solution for ignore See\n> > http://thread.gmane.org/gmane.comp.version-control.git/114825 though you\n> > focus on different aspects.\n> \n> Yup, saw the issue 32. I'll keep an eye on that and hopefully I can\n> leverage what that does when it's ready.\n> \n> > This patch is whitespace damaged. Â Pasting into gmail won't work. Gmail\n> > has authenticated SMTP on port 25 and 465 (SSL) so git-send-email should work that way.\n> \n> One advantage of attaching issues is you don't have MUA problems :-)\n> I'll try and get a patch to work via git-send-email later.\n\nThe problem is review. With e-mail I can just hit reply and comment on your\npatch. Did your try the SMTP interface to gmail? I think e-mailing inlined patches is\na nearly perfect. Inline-attachment is ok with me. That makes it possible to\ncomment on them like any email in my mail program.\n\n> I've been incrementally committing to my local git copy. Whenever I do\n> git format-patch it spews out individual patchettes. How can I\n> use git to generate one patch? I could git diff , but that's\n> not following the SUBMITTING_PATCHES, is it?\n\nOften, after a long session, you end up with a \"mess\" of commits, many which\ndon't make sense to anyone but you. For this you use rebase -i to clean up.\nIt allows you to reorder, squash and edit commits. You'll end up with an entirely\nnew version of your branch. Retest to make sure it's ok and submit. \n\n-- robin\n"},{"id":"111690","messageId":"4D1840C4-B04C-4D75-9A01-BDCDC40D0A29@gmail.com","threadId":"18951","inReplyTo":"200904200832.28361.robin.rosenberg.lists@dewire.com","subject":"Re: [EGIT PATCH] Add support for writing/appending .gitignore file","fromName":"Alex Blewitt","fromEmail":"alex.blewitt@gmail.com","sentAt":"2009-04-20T07:55:54Z","receivedAt":"2009-04-20T07:55:54Z","isPatch":true,"sender":{"key":"alex.blewitt@gmail.com","avatar":"https://gravatar.com/avatar/fb95a3b593b290f03a8d3b022c20b2825205702c5651f731f65d33512dfe6ab2?d=mp&s=160"},"body":"\nOn 20 Apr 2009, at 07:32, Robin Rosenberg wrote:\n\n> måndag 20 april 2009 04:40:42 skrev Alex Blewitt >:\n>> On Sun, Apr 19, 2009 at 10:50 PM, Robin Rosenberg\n>> wrote:\n>> One advantage of attaching issues is you don't have MUA problems :-)\n>> I'll try and get a patch to work via git-send-email later.\n>\n> The problem is review. With e-mail I can just hit reply and comment \n> on your\n> patch. Did your try the SMTP interface to gmail? I think e-mailing \n> inlined patches is\n> a nearly perfect. Inline-attachment is ok with me. That makes it \n> possible to\n> comment on them like any email in my mail program.\n\nRight, but the same approach is possible in a bug tracking system - \njust comment. And people get a notification that a change has \noccurred, too. Except instead of one giant inbox of a collection of \npatches, all the discussion/feedback/comments are limited to the right \nscope (i.e. just that bug/patch). In fact, quite a lot of review goes \non outside of the mail client and directly inside the editor e.g. via \nMylyn or internal web browser to the issue.\n\nIt also allows others - who might not be on the original 'to' list - \nto subscribe to a bug (or star it, in Google's terms) to receive \nnotifications and see specific updates.\n\n>> I've been incrementally committing to my local git copy. Whenever I \n>> do\n>> git format-patch it spews out individual patchettes. How \n>> can I\n>> use git to generate one patch? I could git diff , but that's\n>> not following the SUBMITTING_PATCHES, is it?\n>\n> Often, after a long session, you end up with a \"mess\" of commits, \n> many which\n> don't make sense to anyone but you. For this you use rebase -i to \n> clean up.\n\nGreat, that's useful to know. Unfortunately, I get an error when I try \nthis:\n\napple:egit alex$ git status\n# On branch master\n# Your branch is ahead of 'origin/master' by 9 commits.\n#\nnothing to commit (working directory clean)\n\napple:egit alex$ git rebase -i origin/master\nWorking tree is dirty\napple:egit alex$ git rebase -i d0fd6f96b9311b972c6bffa8680544607d7e3c56\nWorking tree is dirty\napple:egit alex$\n\nI'm probably doing something obviously wrong here, but I don't know \nhow to understand the difference between 'working tree is dirty' and \n'working directory clean', especially since git status (or git commit - \na) doesn't show any differences.\n\nPlease excuse me whilst I figure out how to get comfortable working \nwith git ...\n\nAlex\n\t\n"},{"id":"111759","messageId":"200904201909.38766.robin.rosenberg.lists@dewire.com","threadId":"18951","inReplyTo":"4D1840C4-B04C-4D75-9A01-BDCDC40D0A29@gmail.com","subject":"Re: [EGIT PATCH] Add support for writing/appending .gitignore file","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-04-20T17:09:38Z","receivedAt":"2009-04-20T17:09:38Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"måndag 20 april 2009 09:55:54 skrev Alex Blewitt :\n> \n> On 20 Apr 2009, at 07:32, Robin Rosenberg wrote:\n> \n> > måndag 20 april 2009 04:40:42 skrev Alex Blewitt > >:\n> >> On Sun, Apr 19, 2009 at 10:50 PM, Robin Rosenberg\n> >> wrote:\n> >> One advantage of attaching issues is you don't have MUA problems :-)\n> >> I'll try and get a patch to work via git-send-email later.\n> >\n> > The problem is review. With e-mail I can just hit reply and comment \n> > on your\n> > patch. Did your try the SMTP interface to gmail? I think e-mailing \n> > inlined patches is\n> > a nearly perfect. Inline-attachment is ok with me. That makes it \n> > possible to\n> > comment on them like any email in my mail program.\n> \n> Right, but the same approach is possible in a bug tracking system - \n> just comment. And people get a notification that a change has \nI haven't seen that. Obviously a bugtracker could cite the patch, but\nI don't know any that do.\n\n> apple:egit alex$ git status\n> # On branch master\n> # Your branch is ahead of 'origin/master' by 9 commits.\n> #\n> nothing to commit (working directory clean)\n> \n> apple:egit alex$ git rebase -i origin/master\n> Working tree is dirty\n> apple:egit alex$ git rebase -i d0fd6f96b9311b972c6bffa8680544607d7e3c56\n> Working tree is dirty\n> apple:egit alex$\n> \n> I'm probably doing something obviously wrong here, but I don't know \n> how to understand the difference between 'working tree is dirty' and \n> 'working directory clean', especially since git status (or git commit - \n> a) doesn't show any differences.\n\n\"obviously\" isn't the right word here, or status and rebase would agree\non the cleanliness. If you are using bash I strong suggest you enable\nthe nice bash prompt with some status information. It's in /contrib/completion\nif you have the Git source. In a packaged version you can probably can\nsource /etc/bash_completion. It will tell you what branch you are on and\nstate-information, like whether a rebase is in progress or not (you would\nget a different message from rebase/status if that was the case).\n\n> Please excuse me whilst I figure out how to get comfortable working \n> with git ...\n\nIt took me only ten minutes to find a bug the first time I used git :)\n\n-- robin\n"}]}