From: Alex Blewitt Date: Mon, 20 Apr 2009 07:55:54 GMT Subject: Re: [EGIT PATCH] Add support for writing/appending .gitignore file Message-ID: <4D1840C4-B04C-4D75-9A01-BDCDC40D0A29@gmail.com> In-Reply-To: <200904200832.28361.robin.rosenberg.lists@dewire.com> On 20 Apr 2009, at 07:32, Robin Rosenberg wrote: > måndag 20 april 2009 04:40:42 skrev Alex Blewitt >: >> On Sun, Apr 19, 2009 at 10:50 PM, Robin Rosenberg >> 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 it spews out individual patchettes. How >> can I >> use git to generate one patch? I could git diff , 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