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

Re: Git workflow: how to achieve?

From
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date
Apr 24, 2009, 07:31 UTC
Message-ID
<20090424073122.GA9603@pengutronix.de>
In-Reply-To
<20090424045843.7674.qmail@science.horizon.com>
On Fri, Apr 24, 2009 at 12:58:43AM -0400, George Spelvin wrote:
Show 24 quoted lines
> Here's something I and my co-workers would like to achieve, but are not
> too sure how to arrange.
> 
> I want to be committing to a feature branch, but always be compiling
> and testing a merge of that branch and several others.  (Kind of like
> linux-next.)  I want to be able to switch feature branches easily.
> 
> For example, I may have a background project that I'm working on slowly in
> between short-term fixes.  Or I want to be running the latest kernel.org
> kernel while my patches await approval.
> 
> If it's just my own projects, I can just commit in random order and
> straighten things out later.  Although even that is problematic,
> as I may not remember what line of development a cleanup patch is a
> prerequisite for.  (This is something that darcs is apparently good at.)
> 
> But when I want to be testing something highly volatile like linux-next,
> and ensuring that my work continues to merge with it cleanly, as well
> as helping others with their branches, it becomes a daily pain.
> 
> The best attempt I have so far is to rebase a lot.  But that means that
> I can't do any merging in my development branch lest the rebasing turn
> into a mess.  And forcing everything to be linear makes changing branches
> a pain.  And I can't share half-finished versions with co-workers.

If you develop a topic, say gs/fix_bug_12345, optimally you should base it on the commit introducing the bug. Then you can have several integrating branches, say

	next/gs/fix_bug_12345
	linus/gs/fix_bug_12345
	$company_stable/gs/fix_bug_12345

and in these branches you can regularly merge in the current state of your gs/fix_bug_12345 branch. You might want to take a look on topgit, which can automate the propagation for you.

And/or you might want to look into the linux-tip scripts by Ingo
Molnar[1].
 
> ((Another really simple feature I keep wanting is "git commit -b
> <newbranch>".  I should probably try to write a patch...))
Well currently this can be done in two commands:
	git checkout -b <newbranch>; git commit
AFAIK it even works if you already modified the index.

Best regards Uwe

[1] git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git tip:.tip
-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |
Previous: George SpelvinNext: Andreas Ericsson
Message 2 of 8 in “Git workflow: how to achieve?”
  1. George SpelvinApr 24, 2009
  2. Uwe Kleine-KönigApr 24, 2009
  3. Andreas EricssonApr 24, 2009
  4. George SpelvinApr 27, 2009
  5. Andreas EricssonApr 28, 2009
  6. George SpelvinApr 28, 2009
  7. Andreas EricssonApr 28, 2009
  8. Sitaram ChamartyApr 28, 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.