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

Re: tracking a tree that doesn't progress linearly

From
Martin Langhoff <martin.langhoff@gmail.com>
Date
Nov 11, 2005, 04:58 UTC
Message-ID
<46a038f90511102058p6536b17crc7c9f7ce93167934@mail.gmail.com>
In-Reply-To
<17268.3463.252020.591687@cargo.ozlabs.ibm.com>
On 11/11/05, Paul Mackerras <paulus@samba.org> wrote:
> I want to be able to publish a git tree for others to follow but I
> also want to be retain the freedom to remove commits and/or rebase
> commits in the tree.

I sometimes want that too, but git doesn't have a 'rewind' semantics, and probably for a good reason. The approach I am studying is to create a thousand throaway short-lived branches. It is safe to publish them as long as people following your branches _know_ that they'll be orphaned, and that any commits they have on top of them they'll have to rebase.

So you could publish your tree with devel-<datestamp> heads, and announce when you're moving to a newer one. People tracking your branches can tend register & checkout the new branches, and do a git-merge to rebase their patches to your new branch, or replay them with git-format-patch and git-am.

On the other hand, if StGIT grows better support for sharing patches, it could make all this look like the stone age.

cheers,
martin
Previous: Paul MackerrasNext: Catalin Marinas
Message 2 of 4 in “tracking a tree that doesn't progress linearly”
  1. Paul MackerrasNov 11, 2005
  2. Martin LanghoffNov 11, 2005
  3. Catalin MarinasNov 11, 2005
  4. Petr BaudisNov 11, 2005

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.