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

Re: [doc]playing with git, and netdev/libata-dev trees

From
JGJeff Garzik <jgarzik@pobox.com>
Date
Jun 4, 2005, 10:26 UTC
Message-ID
<42A181C1.3010902@pobox.com>
In-Reply-To
<21d7e99705060401405cfd5a11@mail.gmail.com>
Dave Airlie wrote:
Show 18 quoted lines
>>When I merge a patch for drivers/net/forcedeth.c, I merge it into a
>>brand new 'forcedeth' repository, a peer to the 40+ other such
>>repository.  Under BitKeeper, I made these repositories available merged
>>together into one big "netdev-2.6" repository because it was too time
>>consuming to make the individual 50+ trees publicly available.  With
>>git, developers have direct access to the individual trees.
>>
>>I thought I would write up a quick guide describing how to mess around
>>with the netdev and libata-dev trees, and with git in general.
>>
> 
> 
> Thanks for this, I'm starting to get up to speed on git now...
> 
> Two questions,
> 
> 1. when you want to publish your tree what do you do? just rsync it
> onto kernel.org?

Basically. I copy the attached script into each repo, customize the script for the upload destination.

When I publish the tree, I just cd to the toplevel dir on my local workstation, and run "./push"

> 2. When you are taking things from your queue for Linus do you create
> another tree and merge your branches into it or what?
Not quite sure what you're asking, but I'll attempt to answer anyway :)

When I prepare a submission for Linus, I will pull several branches into a single 'for-linus' conglomeration branch. I do this with the following incantation, for each branch I am pushing upstream:

git-resolve-script $(cat .git/HEAD) $(cat .git/refs/heads/$branch) \
	`pwd` $branch

(Note that I modified my git-resolve-script to take an additional $4 argument, which causes the string " branch $4" to be added to the merge cset's commit msg)

After I take care of all the merge conflicts[1] from the git-resolve-script run, I give the big pile of mush a final build and test, and then run "./push".

For the "please pull" email, I use diffstat, git-diff-tree, git-changes-script and the newly written git-shortlog.

	Jeff

[1] I'm still scared of conflicts in the merge process. Simple and automatic merging works just fine, like it did under BitKeeper. But if there are conflicts that cause git-pull-script/git-resolve-script to bail, then I bail as well: I export a patch, run patch(1), and then handle the merge the Old Fashioned Way(tm) by looking at .rej files.

I really wish somebody would write a merge helper for git that places the conflicts side-by-side in the code [in the working dir]. BitKeeper and CVS both presented conflicts to you in this manner.

The "I resolved this conflict, now let's continue where we left off" process is still quite raw in git. I suppose this is something that is left for others to script, above the plumbing, but hey...

#!/bin/sh
rsync -e ssh --verbose --delete --stats --progress -az .git/ master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git
Previous: Dave AirlieNext: Dave Airlie
Message 5 of 7 in “[doc][git] playing with git, and netdev/libata-dev trees”
  1. Jeff GarzikMay 26, 2005
  2. Frank SorensonMay 26, 2005
  3. James PurserMay 26, 2005
  4. Dave AirlieJun 4, 2005
  5. Jeff GarzikJun 4, 2005
  6. Dave AirlieJun 4, 2005
  7. Jeff GarzikJun 4, 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.