git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Rebasing local patches

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Mar 7, 2009, 11:41 UTC
Message-ID
<alpine.DEB.1.00.0903071229220.10279@pacific.mpi-cbg.de>
In-Reply-To
<49B237E2.3080606@morey-chaisemartin.com>
Hi,
On Sat, 7 Mar 2009, Nicolas Morey-Chaisemartin wrote:
Show 8 quoted lines
> On one of our project, we depend on an external source which uses git. 
> On our side of the project, we create some patches (this part is not the 
> problem), but only some of them are intended to be pushed (ie pulled by) 
> the external source. So basically, we have a set of patches on local 
> branch that we rebase every so and then against master to keep our 
> version up-to-date with the external one.
> 
> Is this the right way to do it?
Looks sane.
Show 9 quoted lines
> Then, internally we have a centralized repository and many personal 
> ones. When the need to go to the next version, one of the developper 
> rebases the company patches branch afaisnt master and push it into the 
> centralized repo.
>
> What is the best way for the other developpers to get up-to-date with 
> the rebased branch?
>
> git pull --rebase seems to me like a good way to keep local modifications.
Indeed.

You could also work from release branches, i.e. whenever you rebase your company-specific changes onto the upstream, you could start a new branch.

Or even better: you could "merge -s ours" the pre-rebase commit. The history would then look something like this:

           new UPSTREAM - A' - B' - C' - M
                                        /
old UPSTREAM - A - B - C --------------'

The ' commits are the rewritten versions of the original company-specific ones, made by the rebase.

If you do it that way, not only will you not lose the history of your project, but your users can happily continue to merge instead of having to rebase.

Show 9 quoted lines
> I noticed that when the branch was rebased on the centralized and repo 
> and origin/our_patches is up-to-date in mine.
>
> If I checkout another branch and then ckecout our_branches, I got a 
> message telling my our_patches and the one from the server have diverged 
> (or you are two commits behind...).
>
> How can you get this info directly without leaving/rejoining your 
> branch?
It is also part of "git status"' output.

Ciao, Dscho

Previous: Nicolas Morey-ChaisemartinNext: Nicolas Morey-Chaisemartin
Message 2 of 4 in “Rebasing local patches”
  1. Nicolas Morey-ChaisemartinMar 7, 2009
  2. Johannes SchindelinMar 7, 2009
  3. Nicolas Morey-ChaisemartinMar 13, 2009
  4. Johannes SchindelinMar 18, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.