git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Yann Droneaud <ydroneaud@opteya.com>
Cc: git@vger.kernel.org
Subject: Re: Tracking vendor release with Git
Date: Tue, 11 Jun 2013 20:27:32 +0200	[thread overview]
Message-ID: <51B76C14.3060907@kdbg.org> (raw)
In-Reply-To: <1370970410-7935-1-git-send-email-ydroneaud@opteya.com>

Am 11.06.2013 19:06, schrieb Yann Droneaud:
> Hi,
> 
> I'm trying to setup a workflow to track vendor releases (upstream).
> Each new release are provided as an archive of source code, data,
> documentation, etc.
> 
> For each vendor releases, fixes need to be applied before making them
> available to users (downstream).
> 
> Seems to be a rather common use case, applied by most Linux distribution
> for decades.
> 
> In my case, on top of each releases, a common set of patches will be applied,
> the biggest, the most intrusive one, being converting CRLF to LF using dos2unix,
> the others being small portability fixes. In this case, fixes are not going to
> be applied by upstream.
> 
> I'm trying to "design" (copy ;) a workflow with following properties,
> in order of importance:
> 
> 1- I wish to keep a branch with each new vendor release as a commit.
>    This branch's history is only about vendor releases,
>    so it's easy to read the "changelog" of the vendor releases
>    with command such as git log <vendor-release-branch>
> 
> 2- I'd like to ease the process of applying our patches on top
>    of each new vendor release, eg. reduces the likeliness of conflicts.
> 
> 3- I wish to keep a branch with each new fixed vendor release as a commit.
>    Just like the upstream <vendor-release-branch>, only one commit
>    per release, so it's easy to read the "changelog" of the vendor releases
>    with command such as git log <patched-release-branch>

I suggest you aim for the following history (time flows from left to right):

  U---V-----W          <-- upstream branch
   \   \     \
    C---D-----E        <-- CRLF conversion branch
     \   \     \
      K---L--M--N--O   <-- downstream branch

U, V, W are the upstream releases.

C is the initial CRLF->LF conversion. D merges the second upstream
release into the CRLF branch, E the third upstream release. These merges
very likely create tons of conflicts. But that does not matter, because
you know that the only change in "our" side is CRLF conversion. The
commits on this branch can easily be automated. That's the primary
motivation for this scheme.

K is your first small bugfix and also your first downstream release.

After merging L, the second, CRLF-converted, upstream release, you make
your second small change, M, which is also your second downstream release.

Rinse and repeat with N and O for the third release.

-- Hannes

  parent reply	other threads:[~2013-06-11 18:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-11 17:06 Tracking vendor release with Git Yann Droneaud
2013-06-11 17:29 ` Greg Troxel
2013-06-11 18:27 ` Johannes Sixt [this message]
2013-06-11 18:43 ` Philip Oakley
2013-06-12  8:17 ` Carsten Fuchs
  -- strict thread matches above, loose matches on Subject: below --
2013-06-11 16:59 Yann Droneaud

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=51B76C14.3060907@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=git@vger.kernel.org \
    --cc=ydroneaud@opteya.com \
    /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).