pushing patches to an imap folder

pushing patches to an imap folder

[Mike McCormack]

Hi,

I hacked up git-format-patch and isync to create a program to push 
patches from git into an imap folder.  This improve my workflow with git 
quite a bit.

It's pretty Wine specific at the moment, but I'd be happy to try and 
create a patch for git if I had a little advice on where to store the 
configuration... an imap server (host/port/name/pass or ssh command) 
with a mail header/template thrown in.

http://mandoo.dyndns.org/mm-send-patch-0.1.tar.gz

Comments and flames welcome :)

Mike

Re: pushing patches to an imap folder

[Junio C Hamano]

Mike McCormack <mike@codeweavers.com> writes:

> I hacked up git-format-patch and isync to create a program to push 
> patches from git into an imap folder.  This improve my workflow with git 
> quite a bit.

Hmph.  How well does the rest of git help your workflow, working
with the Wine community?  Especially, how are you keeping track
of and interoperating with their main CVS repository?  Do you
have to do anything special when your patches are accepted by
the upstream and echoed back to you when you 'cvs update' from
them next time?

Re: pushing patches to an imap folder

[Mike McCormack]

Junio C Hamano wrote:

> Hmph.  How well does the rest of git help your workflow, working
> with the Wine community?  Especially, how are you keeping track
> of and interoperating with their main CVS repository? 

We have a (semi-experimental) wine.git tree, which is updated at the 
same time as the Wine CVS, by the project maintainer:

http://source.winehq.org/git/wine.git

It will probably be maintained in parallel with the Wine CVS for a 
while, unless somebody writes a GIT->CVS gateway.

I find git-rebase to be particularly useful.  When I used CVS, sending a 
series of patches was a pain. I'd contemplated using quilt, but never 
got round to trying it.

Pushing patches from git into a drafts folder means I don't have to 
manually generate a diff, open a mail, type the mailing list address, 
attach the patch and write/copy-paste a ChangeLog entry.

> Do you
> have to do anything special when your patches are accepted by
> the upstream and echoed back to you when you 'cvs update' from
> them next time?

"git pull" is usually sufficient.

Mike

Re: pushing patches to an imap folder

[Johannes Schindelin]

Hi,

On Tue, 15 Nov 2005, Mike McCormack wrote:

> Junio C Hamano wrote:
> 
> > Hmph.  How well does the rest of git help your workflow, working with 
> > the Wine community?  Especially, how are you keeping track of and 
> > interoperating with their main CVS repository?
> 
> We have a (semi-experimental) wine.git tree, which is updated at the 
> same time as the Wine CVS, by the project maintainer:
> 
> http://source.winehq.org/git/wine.git

This is cool! I used to track wine with "git-cvsimport -i".

My work flow was like this (not with wine, since I did not have enough 
time to hack on it in the last months, but with other CVS managed 
projects):

"git-cvsimport -i" every once in a while, followed by "git pull . origin" 
(my working branch is always master).

When I have something interesting, I make a topic branch from origin ("git 
checkout -b eyes_apple origin"), and pick the interesting commits from 
master ("git cherry-pick SHA1").

Sometimes I pick multiple commits with the "-n" flag, so that I can hide 
my shortcomings, committing with the message of the first commit ("git 
commit -C SHA1").

Then, I use git-format-patch to generate the patches, which I hand-edit to 
make sure there is no typo, and no unwanted changes slipped in. Then, I 
send the message(s).

> It will probably be maintained in parallel with the Wine CVS for a while,
> unless somebody writes a GIT->CVS gateway.

It would be cool to have something like git-cvs-daemon, which simulates a 
CVS server.

Ciao,
Dscho

Re: pushing patches to an imap folder

[Matthias Urlichs]

Hi, Johannes Schindelin wrote:

> It would be cool to have something like git-cvs-daemon, which simulates a 
> CVS server.

read-only would not be that difficult. You'd have to cache CVS version
numbers for individual files and decide on a branch ordering, but those
are basically non-problems.

Don't even *think* about committing.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Conscience is what hurts when everything else feels so good.

Re: pushing patches to an imap folder

[Junio C Hamano]

Mike McCormack <mike@codeweavers.com> writes:

> We have a (semi-experimental) wine.git tree, which is updated at the 
> same time as the Wine CVS, by the project maintainer:
>
> http://source.winehq.org/git/wine.git

Wow.  How is the acceptance by wine community?  Favorable, I
hope.

It would be nice before 1.0 happens to have a list of publicly
visible projects and people who use git as part of the workflow;
the degree would vary per project, from using it as the primary
repository (the kernel, I guess) to merely accessible with git.

> It will probably be maintained in parallel with the Wine CVS for a 
> while, unless somebody writes a GIT->CVS gateway.

git-cvsexportcommit?  I haven't had a chance to use it myself,
although I have to interoperate with CVS in some projects.
Martin, do you want to do a plug (or brag) here?

> I find git-rebase to be particularly useful.

It is handy, especially for simple things like rebasing topic
branches, when the things are of managable size without using
quilt or StGIT.  Do you manage binary files?

> Pushing patches from git into a drafts folder means I don't have to 
> manually generate a diff, open a mail, type the mailing list address, 
> attach the patch and write/copy-paste a ChangeLog entry.

Yes, I saw that value there.  Maybe adding hooks to format-patch
so that it can do form-letter-ish things you had to add there
without patching might help?  I dunno.

Re: pushing patches to an imap folder

[Mike McCormack]

Junio C Hamano wrote:

> Wow.  How is the acceptance by wine community?  Favorable, I
> hope.

wine.git hasn't been announced on any of the wine mailing lists yet.  As 
long as we don't get rid of CVS entirely, I don't think there'll be too 
many complaints.  Hopefully when it's announced, we'll have a few GIT 
users who can tell people why it's good to use.

> git-cvsexportcommit?  I haven't had a chance to use it myself,
> although I have to interoperate with CVS in some projects.
> Martin, do you want to do a plug (or brag) here?

git-cvsexportcommit looks nice.  I guess Alexandre is using something 
like that now.  I was thinking more ambitiously... something like a 
git-cvsd.  That would be a pretty awesome migration tool :)

> It is handy, especially for simple things like rebasing topic
> branches, when the things are of managable size without using
> quilt or StGIT.  Do you manage binary files?

No, there's no binary files in the Wine CVS (or symlinks ;).

> Yes, I saw that value there.  Maybe adding hooks to format-patch
> so that it can do form-letter-ish things you had to add there
> without patching might help?  I dunno.

I'll have a go at integrating my code with format-patch.  Hooks for a 
template would be helpful.

Mike

Re: pushing patches to an imap folder

[Junio C Hamano]

Mike McCormack <mike@codeweavers.com> writes:

> No, there's no binary files in the Wine CVS (or symlinks ;).

Hmph.  Kinda surprised.  You guys do not do icons?

Re: pushing patches to an imap folder

[Mike McCormack]

Junio C Hamano wrote:

> Hmph.  Kinda surprised.  You guys do not do icons?

We do, but we have a tool called bin2res that converts them to text and 
stores them in a comment in the .rc file that they're associated with:

http://cvs.winehq.org/cvsweb/~checkout~/wine/dlls/shell32/shres.rc?rev=1.42&content-type=text/plain

This was done because of trouble with binary files in CVS.

Re: pushing patches to an imap folder

[Martin Langhoff]

On 11/15/05, Mike McCormack <mike@codeweavers.com> wrote:
> It will probably be maintained in parallel with the Wine CVS for a
> while, unless somebody writes a GIT->CVS gateway.

The missing 'git-cvsexport' command should be the missing part for the
gateway. I am not hacking on it right now, but Kevin seemed to be
getting started in that direction. If not, I'll probably hack
something together eventually.

I don't have any project currently migrating to GIT... yet ;-)



martin