* [EGIT PATCH] Add support for writing/appending .gitignore file
@ 2009-04-19 13:09 Alex Blewitt
2009-04-19 21:50 ` Robin Rosenberg
0 siblings, 1 reply; 6+ messages in thread
From: Alex Blewitt @ 2009-04-19 13:09 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [EGIT PATCH] Add support for writing/appending .gitignore file
2009-04-19 13:09 [EGIT PATCH] Add support for writing/appending .gitignore file Alex Blewitt
@ 2009-04-19 21:50 ` Robin Rosenberg
2009-04-20 2:40 ` Alex Blewitt
0 siblings, 1 reply; 6+ messages in thread
From: Robin Rosenberg @ 2009-04-19 21:50 UTC (permalink / raw)
To: Alex Blewitt, Ferry Huberts; +Cc: Shawn O. Pearce, git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [EGIT PATCH] Add support for writing/appending .gitignore file
2009-04-19 21:50 ` Robin Rosenberg
@ 2009-04-20 2:40 ` Alex Blewitt
2009-04-20 6:32 ` Robin Rosenberg
0 siblings, 1 reply; 6+ messages in thread
From: Alex Blewitt @ 2009-04-20 2:40 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Ferry Huberts, Shawn O. Pearce, git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [EGIT PATCH] Add support for writing/appending .gitignore file
2009-04-20 2:40 ` Alex Blewitt
@ 2009-04-20 6:32 ` Robin Rosenberg
2009-04-20 7:55 ` Alex Blewitt
0 siblings, 1 reply; 6+ messages in thread
From: Robin Rosenberg @ 2009-04-20 6:32 UTC (permalink / raw)
To: Alex Blewitt; +Cc: Ferry Huberts, Shawn O. Pearce, git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [EGIT PATCH] Add support for writing/appending .gitignore file
2009-04-20 6:32 ` Robin Rosenberg
@ 2009-04-20 7:55 ` Alex Blewitt
2009-04-20 17:09 ` Robin Rosenberg
0 siblings, 1 reply; 6+ messages in thread
From: Alex Blewitt @ 2009-04-20 7:55 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Ferry Huberts, Shawn O. Pearce, git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [EGIT PATCH] Add support for writing/appending .gitignore file
2009-04-20 7:55 ` Alex Blewitt
@ 2009-04-20 17:09 ` Robin Rosenberg
0 siblings, 0 replies; 6+ messages in thread
From: Robin Rosenberg @ 2009-04-20 17:09 UTC (permalink / raw)
To: Alex Blewitt; +Cc: Ferry Huberts, Shawn O. Pearce, git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-04-20 17:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-19 13:09 [EGIT PATCH] Add support for writing/appending .gitignore file Alex Blewitt
2009-04-19 21:50 ` Robin Rosenberg
2009-04-20 2:40 ` Alex Blewitt
2009-04-20 6:32 ` Robin Rosenberg
2009-04-20 7:55 ` Alex Blewitt
2009-04-20 17:09 ` Robin Rosenberg
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.