On 20 Apr 2009, at 07:32, Robin Rosenberg wrote:
måndag 20 april 2009 04:40:42 skrev Alex Blewitt <alex.blewitt@xxxxxxxxx
>:
On Sun, Apr 19, 2009 at 10:50 PM, Robin Rosenberg
<robin.rosenberg.lists@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html