git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Erik Faye-Lund <kusmabite@gmail.com>
Cc: Karsten Blees <karsten.blees@gmail.com>,
	Marat Radchenko <marat@slonopotamus.org>,
	GIT Mailing-list <git@vger.kernel.org>,
	Felipe Contreras <felipe.contreras@gmail.com>
Subject: Re: [PATCH 08/12] MINGW: fix main() signature in http-fetch.c and remote-curl.c
Date: Wed, 30 Apr 2014 11:38:39 -0500	[thread overview]
Message-ID: <5361270f70fed_1404fdd3102e@nysa.notmuch> (raw)
In-Reply-To: <alpine.DEB.1.00.1404301424590.14982@s15462909.onlinehome-server.info>

Johannes Schindelin wrote:
> On Wed, 30 Apr 2014, Erik Faye-Lund wrote:
> 
> > While it's certainly a good point, I think this is *our* fault for not
> > upstreaming our changes, and the responsibility of cleaning up merges
> > should lie on our shoulders. We've diverged a lot. Sure, Dscho does a
> > great job making the divergence less painful, but IMO we should try to
> > reduce the delta as well.
> 
> Just for historical context: we *did* try to get our changes upstream. In
> fact, that was in large part everything Steffen Prohaska did while he was
> maintaining Git for Windows. The going has been tough, though, to the
> point that we were losing contributors who were not *quite* willing to put
> up with such a detailed vetting process as the Git mailing list requires.
> 
> I have to admit that it is really, really hard even for someone like me,
> who is used to the ways of the Git mailing list, because just a simple
> thing like this curl-config issue already eats up several days of my Git
> time budget.
> 
> So while I am sympathetic to the point of view that the Git for Windows
> project failed to upstream its changes, I am *equally* sympathetic to the
> point of view that it is an undue burden to have to go through the process
> of getting patches included by upstream Git. I, for one, simply ain't got
> the time, man.

As a maintainer of another friendly fork of Git (or downstream), because
of very similar reaons, I symphathize.

It's something that has to be done though, otherwise the burden of
maintaining the friendly fork becomse unberable.

The trick is to only send the trivial patches upstream, and also to
constantly keep track of what is missing from upstream.

In oder to do this I've found invaluable to have an integration branch,
which I constnatly regenerate with `git reintegrate`[1]. IIRC you do a
similar kind of reintegration for each new release of msysgit, and it
appears to me that you do it by hand, which must be tedious.

I'm planning to write a blog post about the subject, but basically I
have a bunch of branches that are direct descendants of an upstream
version, I tell `git reintegrate` to merge them on top of certain
upstream release, the result must match *exactly* what my main master
branch has. The descendant branches I constanly keep rebasing, and the
main master branch always mergering and cherry-picking, never rebasing.

[1] https://github.com/felipec/git-reintegrate

-- 
Felipe Contreras

  reply	other threads:[~2014-04-30 16:49 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-29  9:11 [PATCH v2] MinGW(-W64) cross-compilation Marat Radchenko
2014-04-29  9:11 ` [PATCH 01/12] MINGW: compat/mingw.h: do not attempt to redefine lseek on mingw-w64 Marat Radchenko
2014-04-29  9:11 ` [PATCH 02/12] MSVC: config.mak.uname: drop -D__USE_MINGW_ACCESS from CFLAGS Marat Radchenko
2014-04-29  9:11 ` [PATCH 03/12] MINGW: compat/mingw.h: drop fork() definition Marat Radchenko
2014-04-29  9:11 ` [PATCH 04/12] MINGW: do not fail at redefining pid_t on MinGW-W64 Marat Radchenko
2014-04-29  9:11 ` [PATCH 05/12] MINGW: config.mak.uname: allow using cURL for non-msysGit builds Marat Radchenko
2014-04-29  9:12 ` [PATCH 06/12] MINGW: git-compat-util.h: use inttypes.h for printf macros Marat Radchenko
2014-04-29  9:12 ` [PATCH 07/12] MINGW: config.mak.uname: reorganize MINGW settings Marat Radchenko
2014-04-29  9:12 ` [PATCH 08/12] MINGW: fix main() signature in http-fetch.c and remote-curl.c Marat Radchenko
2014-04-30  8:35   ` Karsten Blees
2014-04-30  8:56     ` Erik Faye-Lund
2014-04-30 12:31       ` Johannes Schindelin
2014-04-30 16:38         ` Felipe Contreras [this message]
2014-04-30 22:17     ` Stepan Kasal
2014-04-30 22:28       ` [PATCH] Win32: move main macro to a function Stepan Kasal
2014-05-03  7:43     ` [PATCH 08/12] MINGW: fix main() signature in http-fetch.c and remote-curl.c Marat Radchenko
2014-04-29  9:12 ` [PATCH 09/12] Makefile: introduce CROSS_COMPILE variable Marat Radchenko
2014-04-29  9:12 ` [PATCH 10/12] MINGW: compat/poll/poll.c: undef NOGDI Marat Radchenko
2014-04-30 11:41   ` Stepan Kasal
2014-05-03  7:00     ` Marat Radchenko
2014-05-04 18:52       ` Stepan Kasal
2014-05-04 20:55         ` Marat Radchenko
2014-05-04 21:46           ` '502304919' via msysGit
2014-05-05  7:35           ` Stepan Kasal
2014-05-05  7:32             ` Felipe Contreras
2014-05-05 12:15               ` [msysGit] " Stepan Kasal
2014-05-04 20:14       ` Felipe Contreras
2014-04-29  9:12 ` [PATCH 11/12] compat/nedmalloc/malloc.c.h: fix compilation under MinGW-W64 Marat Radchenko
2014-04-29  9:12 ` [PATCH 12/12] MINGW: config.mak.uname: add explicit way to request MinGW-build Marat Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5361270f70fed_1404fdd3102e@nysa.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=karsten.blees@gmail.com \
    --cc=kusmabite@gmail.com \
    --cc=marat@slonopotamus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).