From: Alex Blewitt <hidden> Date: 2016-06-15 22:46:37
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 <redacted>
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(-)
@@ -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
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.
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.
quoted
+ 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.
quoted
+ 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.
Yup, saw the issue 32. I'll keep an eye on that and hopefully I can
leverage what that does when it's ready.
quoted
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
From: Alex Blewitt <hidden> Date: 2016-06-15 22:46:37
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
quoted
:
On Sun, Apr 19, 2009 at 10:50 PM, Robin Rosenberg
[off-list ref] 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.
quoted
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
From: Robin Rosenberg <hidden> Date: 2016-06-15 22:46:37
måndag 20 april 2009 09:55:54 skrev Alex Blewitt [off-list ref]:
On 20 Apr 2009, at 07:32, Robin Rosenberg wrote:
quoted
måndag 20 april 2009 04:40:42 skrev Alex Blewitt <alex.blewitt@gmail.com
quoted
:
On Sun, Apr 19, 2009 at 10:50 PM, Robin Rosenberg
[off-list ref] 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