From: Andreas Ericsson <ae@op5.se>
To: Theodore Tso <tytso@mit.edu>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Steffen Prohaska <prohaska@zib.de>,
Peter Baumann <waste.manager@gmx.de>,
"J. Bruce Fields" <bfields@fieldses.org>,
Jakub Narebski <jnareb@gmail.com>,
Federico Mena Quintero <federico@novell.com>,
git@vger.kernel.org
Subject: Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
Date: Thu, 25 Oct 2007 16:58:13 +0200 [thread overview]
Message-ID: <4720AF05.3050308@op5.se> (raw)
In-Reply-To: <20071025132401.GA22103@thunk.org>
Theodore Tso wrote:
> On Thu, Oct 25, 2007 at 12:33:09PM +0200, Andreas Ericsson wrote:
>> Because it's convenient, ofcourse. Don't you have 'maint', 'next'
>> and 'master' in your clone of git.git? I'm guessing at least 99% of
>> the people on this list have those branches lying around in their
>> clones, even if they only ever use 'next' and/or 'master'.
>
> I find it just as easy to say: "git checkout origin/maint" or "git
> checkout origin/next" when I want to examine some other branch.
>
> If I want to make a change against maint, then I follow up "git
> checkout origin/maint" with a "git checkout -b <topic-name>". Part of
Except that <topic-name> in this case will always be maint, since
only small bugfixes go on that branch. We tried using different-named
branches earlier, but the "git push <local-branch>" behaviour was
much too common, and we ended up with far too many randomly named
branches on the mothership repository.
>
> You're using a diferent workflow, and with users who aren't interested
> in learning the fine points of git. But main issue is that git isn't
> optimized for what you want to do.
Correct. I'm working on optimizing it right now though :)
> So I can suggest a couple of
> different approaches. One is to simply do things the 'hg' way.
> Explicitly set up different repos for the different branches. It's
> more inefficient, but it does work.
That makes diffing harder to do, and for those few long-living topics
that get pushed to mothership, there's no logical way for the user to
get only that branch. With the *:refs/remotes/foo/* config thing, this
works seemlessly today.
>
> Another would be to set up a wrapper script for "git-clone" that
> creates a separate local working directory for each branch. So for
> example, it might do something like this:
>
> #!/bin/sh
> # Usage: get-repo <URL> [dir]
> URL=$1
> dir=$2
> branches=`git-ls-remote --heads $URL | sed -e 's;.*/;;'`
> if [ "$dir"x = "x" ]; then dir=`basename $URL`; fi
> git clone $URL .temp-repo
> mkdir $dir
> cd $dir
> for i in $branches; do
> mkdir $i
> cd $i
> git init
> git remote add -t $i origin $URL
> echo ref: refs/heads/$i > .git/HEAD
> git fetch ../../.temp-repo refs/remotes/origin/$i:refs/remotes/origin/$i
> # do it a second time to get the tags (bug in fetch?)
> git fetch ../../.temp-repo refs/remotes/origin/$i:refs/remotes/origin/$i
> git merge origin/$i
> git config remote.origin.push $i:$i
> cd ..
> done
> cd ..
> rm -rf .temp-repo
>
> For bonus points, this script could be made smarter so that each of
> the branches shared a common git object database, and some error
> checking would be nice, but hopefully this gets the basic idea across.
>
> This way, the "basic git users" get a separate working directory for
> each branch, where "git pull" updates that particular branch, and "git
> push" updates changes to the remote branch.
>
> Does this do what you want?
>
Not really, I'm afraid. Apart from missing out on the auto-download of
new repos you get with "fetch = refs/heads/*:refs/remotes/origin/*",
it seems inelegant.
> - Ted
>
> P.S. Note by the way that if you are having everyone own access to
> push into a single central repository, having a "next" branch probably
> doesn't make seense. You're probably way better off just simply
> having "master" (which would be your devel branch), and "maint" for
> bug fixes.
>
We have
maint = maintenance code. some repos have several maint-branches
master = integration-tested code that will end up in next release
testing = unit-tested features, ready for integration testing
We can't really do without them, but perhaps I can do what Dscho
suggested in another email and force everyone to delete their
locally-modifiable branches once they're done making changes to
them. It'll end up being more commands to run for a single fix,
but at least it's not error-prone.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2007-10-25 14:58 UTC|newest]
Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-08 20:55 Git User's Survey 2007 unfinished summary continued Jakub Narebski
2007-10-12 22:08 ` Jakub Narebski
2007-10-12 23:36 ` Frank Lichtenheld
2007-10-13 0:46 ` Johannes Schindelin
2007-10-13 2:13 ` J. Bruce Fields
2007-10-13 2:53 ` Shawn O. Pearce
2007-10-13 12:58 ` Frank Lichtenheld
2007-10-13 13:04 ` Johannes Schindelin
2007-10-13 18:00 ` Andreas Ericsson
2007-10-13 19:59 ` David Kastrup
2007-10-13 20:27 ` J. Bruce Fields
2007-10-13 20:57 ` David Kastrup
2007-10-14 0:36 ` Johannes Schindelin
2007-10-14 1:13 ` Linus Torvalds
2007-10-14 1:44 ` Shawn O. Pearce
2007-10-14 3:15 ` Linus Torvalds
2007-10-14 3:43 ` david
2007-10-14 3:55 ` Linus Torvalds
2007-10-14 10:20 ` Reece Dunn
2007-10-14 18:12 ` Steven Grimm
2007-10-14 18:40 ` J. Bruce Fields
2007-10-14 19:25 ` Steven Grimm
2007-10-14 19:50 ` Andreas Ericsson
2007-10-14 20:18 ` Johannes Schindelin
2007-10-14 20:22 ` Andreas Ericsson
2007-10-14 20:24 ` J. Bruce Fields
2007-10-14 19:44 ` Nicolas Pitre
2007-10-15 23:20 ` Shawn O. Pearce
2007-10-16 2:48 ` Nicolas Pitre
2007-10-16 10:51 ` Johannes Schindelin
2007-10-14 2:06 ` Johannes Schindelin
2007-10-14 8:45 ` Andreas Ericsson
2007-10-14 9:21 ` David Kastrup
2007-10-14 21:49 ` Jakub Narebski
2007-10-14 22:08 ` Johannes Schindelin
2007-10-14 22:17 ` David Kastrup
2007-10-14 22:12 ` David Kastrup
2007-10-14 22:15 ` Jakub Narebski
2007-10-14 22:23 ` Matthew Andrews
2007-10-14 22:30 ` David Kastrup
2007-10-14 21:10 ` David Tweed
2007-10-19 20:57 ` Federico Mena Quintero
2007-10-19 23:27 ` Jakub Narebski
2007-10-19 23:37 ` Johannes Schindelin
2007-10-22 14:28 ` Federico Mena Quintero
2007-10-20 8:03 ` Andreas Ericsson
2007-10-20 10:19 ` Steffen Prohaska
2007-10-20 11:29 ` Andreas Ericsson
2007-10-21 6:08 ` Dmitry Potapov
2007-10-20 23:06 ` Jakub Narebski
2007-10-20 23:33 ` Johannes Schindelin
2007-10-21 7:17 ` Andreas Ericsson
2007-10-21 22:15 ` Johannes Schindelin
2007-10-22 7:59 ` Andreas Ericsson
2007-10-22 11:04 ` best git practices, was " Johannes Schindelin
2007-10-22 12:44 ` Andreas Ericsson
2007-10-22 13:48 ` Johannes Schindelin
2007-10-22 14:31 ` Andreas Ericsson
2007-10-22 15:00 ` Johannes Schindelin
2007-10-22 15:16 ` Andreas Ericsson
2007-10-22 15:42 ` Steffen Prohaska
2007-10-22 19:36 ` Federico Mena Quintero
2007-10-22 23:21 ` Johannes Schindelin
2007-10-25 19:04 ` Carl Worth
2007-10-22 23:35 ` Jakub Narebski
2007-10-23 5:38 ` Steffen Prohaska
2007-10-23 10:58 ` Johannes Schindelin
2007-10-24 18:48 ` Steffen Prohaska
2007-10-24 19:20 ` J. Bruce Fields
2007-10-24 19:41 ` Andreas Ericsson
2007-10-24 19:48 ` J. Bruce Fields
2007-10-24 20:12 ` Steffen Prohaska
2007-10-24 20:33 ` J. Bruce Fields
2007-10-24 21:06 ` Andreas Ericsson
2007-10-24 21:20 ` J. Bruce Fields
2007-10-24 21:28 ` Peter Baumann
2007-10-24 21:47 ` Steffen Prohaska
2007-10-24 22:14 ` Johannes Schindelin
2007-10-24 22:33 ` Steffen Prohaska
2007-10-24 22:38 ` J. Bruce Fields
2007-10-24 22:51 ` Steffen Prohaska
2007-10-24 23:28 ` Johannes Schindelin
2007-10-25 6:02 ` Steffen Prohaska
2007-10-25 10:27 ` Johannes Schindelin
2007-10-25 12:04 ` Steffen Prohaska
2007-10-25 7:15 ` Andreas Ericsson
2007-10-25 7:31 ` Peter Baumann
2007-10-25 7:57 ` Andreas Ericsson
2007-10-25 8:25 ` Steffen Prohaska
2007-10-25 10:17 ` Johannes Schindelin
2007-10-25 10:33 ` Andreas Ericsson
2007-10-25 12:09 ` Steffen Prohaska
2007-10-25 12:58 ` Johannes Schindelin
2007-10-25 13:24 ` Theodore Tso
2007-10-25 14:58 ` Andreas Ericsson [this message]
2007-10-25 15:21 ` Theodore Tso
2007-10-25 17:05 ` Andreas Ericsson
2007-10-25 18:33 ` Junio C Hamano
2007-10-25 20:18 ` Andreas Ericsson
2007-10-26 6:18 ` Steffen Prohaska
2007-10-26 7:53 ` Andreas Ericsson
2007-10-25 18:02 ` best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued Federico Mena Quintero
2007-10-25 18:04 ` Mike Hommey
2007-10-25 18:18 ` J. Bruce Fields
2007-10-25 18:23 ` Theodore Tso
2007-10-25 20:08 ` Andreas Ericsson
2007-10-26 20:01 ` David Kastrup
2007-10-25 16:06 ` Federico Mena Quintero
2007-10-25 16:38 ` J. Bruce Fields
2007-10-25 18:06 ` Federico Mena Quintero
2007-10-25 18:16 ` J. Bruce Fields
2007-10-25 20:19 ` Andreas Ericsson
2007-10-25 20:27 ` J. Bruce Fields
2007-10-26 9:17 ` David Kastrup
2007-10-26 4:41 ` [PATCH] Make rebase smarter Steven Walter
2007-10-26 7:42 ` Andreas Ericsson
2007-10-26 9:57 ` Johannes Schindelin
2007-10-26 21:02 ` Junio C Hamano
2007-10-26 23:13 ` Johannes Schindelin
2007-10-26 23:29 ` Junio C Hamano
2007-10-24 21:54 ` best git practices, was Re: Git User's Survey 2007 unfinished summary continued Andreas Ericsson
2007-10-24 22:17 ` Johannes Schindelin
2007-10-25 8:07 ` Andreas Ericsson
2007-10-25 10:12 ` Johannes Schindelin
2007-10-25 10:24 ` Andreas Ericsson
2007-10-25 11:39 ` Johannes Schindelin
2007-10-25 12:46 ` Andreas Ericsson
2007-10-25 14:51 ` Karl Hasselström
2007-10-25 17:10 ` Andreas Ericsson
2007-10-25 7:26 ` Peter Baumann
2007-10-24 21:16 ` Steffen Prohaska
2007-10-24 20:13 ` Andreas Ericsson
2007-10-24 23:48 ` Jakub Narebski
2007-10-25 7:42 ` Andreas Ericsson
2007-10-25 10:07 ` Johannes Schindelin
2007-10-25 10:39 ` Steffen Prohaska
2007-10-25 16:16 ` Federico Mena Quintero
2007-10-23 7:24 ` Andreas Ericsson
2007-10-22 18:06 ` Daniel Barkalow
2007-10-22 13:17 ` Wincent Colaiuta
2007-10-22 13:33 ` David Symonds
2007-10-22 13:38 ` Johannes Schindelin
2007-10-22 17:48 ` Robin Rosenberg
2007-10-23 22:13 ` Alex Riesen
2007-10-22 13:36 ` Nguyen Thai Ngoc Duy
2007-10-22 15:24 ` best git practices, was Re: Git User's Survey 2007 unfinished summarycontinued Federico Mena Quintero
2007-10-24 2:06 ` best git practices, was Re: Git User's Survey 2007 unfinished summary continued Jakub Narebski
2007-10-24 10:29 ` Karl Hasselström
2007-10-24 11:04 ` Jakub Narebski
2007-10-24 11:31 ` Karl Hasselström
2007-10-24 23:27 ` Jakub Narebski
2007-10-25 6:10 ` Karl Hasselström
2007-10-24 13:15 ` Catalin Marinas
2007-10-22 12:26 ` Jakub Narebski
2007-10-22 13:45 ` Johannes Schindelin
2007-10-22 14:29 ` Andreas Ericsson
2007-10-22 14:53 ` Federico Mena Quintero
2007-10-22 23:27 ` Jakub Narebski
2007-10-22 22:53 ` Steven Grimm
2007-10-21 22:12 ` J. Bruce Fields
2007-10-13 3:04 ` Shawn O. Pearce
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=4720AF05.3050308@op5.se \
--to=ae@op5.se \
--cc=Johannes.Schindelin@gmx.de \
--cc=bfields@fieldses.org \
--cc=federico@novell.com \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=prohaska@zib.de \
--cc=tytso@mit.edu \
--cc=waste.manager@gmx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.