All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Habouzit <madcoder@debian.org>
To: Alex Riesen <raa.lkml@gmail.com>
Cc: Bill Lear <rael@zopyra.com>, Junio C Hamano <gitster@pobox.com>,
	Aghiles <aghilesk@gmail.com>,
	git@vger.kernel.org
Subject: Re: git pull opinion
Date: Tue, 06 Nov 2007 09:31:44 +0100	[thread overview]
Message-ID: <20071106083144.GA4435@artemis.corp> (raw)
In-Reply-To: <20071106073841.GB3021@steel.home>

[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]

On Tue, Nov 06, 2007 at 07:38:41AM +0000, Alex Riesen wrote:
> Pierre Habouzit, Tue, Nov 06, 2007 01:46:01 +0100:
> > On Tue, Nov 06, 2007 at 12:36:16AM +0000, Bill Lear wrote:
> > > On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:
> > > > Stop thinking like "I need to integrate the changes from upstream
> > > > into my WIP to keep up to date."
> > > >
> > > > [...]
> > > >
> > > > Once you get used to that, you would not have "a dirty directory"
> > > > problem.
> > > 
> > > I respectfully beg to differ.  I think it is entirely reasonable, and
> > > not a sign of "centralized" mindset, to want to pull changes others
> > > have made into your dirty repository with a single command.
> > 
> >   I agree, I have such needs at work.  Here is how we (very informally)
> > work: people push things that they believe could help other (a new
> > helper function, a new module, a bug fix) in our master ASAP, but
> > develop big complex feature in their repository and merge into master
> > when it's ready.
> > 
> >   Very often we discuss some bugfix that is impeding people, or a
> > most-wanted-API. Someone does the work, commits, I often want to merge
> > master _directly_ into my current work-branch, because I want the
> > fix/new-API/... whatever.
> 
> How about merging just that "fix/new-API/... whatever" thing and not
> the whole master, which should be a complete mess by now?

  No master only holds simple patches (few of them, typically half a
dozen a day), or long-lived branches that are tested and ready to merge.

> The way you explained it it looks like typical centralized workflow.

  Well I disagree, it's /part/ centralized. We have a two speed devel
method, one that works the old-centralized way for quick fixes, and a
more decentralized approach for big changes. It's a rather nice and
useful middle ground for a company where all programmers are within
earshot.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-11-06  8:32 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-05 21:52 git pull opinion Aghiles
2007-11-05 22:28 ` Jakub Narebski
2007-11-06  0:08   ` Johannes Schindelin
2007-11-06  4:22     ` Aghiles
2007-11-06 12:02       ` Johannes Schindelin
2007-11-06 18:13         ` Junio C Hamano
2007-11-06 18:28           ` Johannes Schindelin
2007-11-05 22:49 ` Alex Riesen
2007-11-05 23:33 ` Junio C Hamano
2007-11-06  0:36   ` Bill Lear
2007-11-06  0:46     ` Pierre Habouzit
2007-11-06  7:38       ` Alex Riesen
2007-11-06  8:31         ` Pierre Habouzit [this message]
2007-11-06  0:54     ` Andreas Ericsson
2007-11-06  1:16       ` Johannes Schindelin
2007-11-06  8:59         ` Andreas Ericsson
2007-11-06 12:05           ` Johannes Schindelin
2007-11-06 12:08             ` Andreas Ericsson
2007-11-06  6:30     ` Aghiles
2007-11-06  7:40       ` Alex Riesen
2007-11-06 16:36       ` Linus Torvalds
2007-11-07 21:25         ` Aghiles
2007-11-08 15:27           ` Johannes Schindelin
2007-11-10  0:36           ` Linus Torvalds
2007-11-06  0:37   ` Steven Grimm
2007-11-06  4:04   ` Aghiles
2007-11-05 23:40 ` Miklos Vajna
2007-11-06  4:16   ` Aghiles
2007-11-06  5:29     ` Benoit Sigoure
2007-11-06  7:34       ` Ralf Wildenhues
2007-11-06 11:59         ` Johannes Schindelin
2007-11-06 20:22           ` Ralf Wildenhues
2007-11-06  7:45       ` Aghiles
2007-11-06  8:51       ` Pierre Habouzit
2007-11-07  0:26         ` [PATCH] Mark 'git stash [message...]' as deprecated Brian Downing
2007-11-07  0:26           ` [PATCH] Disable implicit 'save' argument for 'git stash' Brian Downing
2007-11-07  8:00           ` [PATCH] Mark 'git stash [message...]' as deprecated Johannes Sixt
2007-11-07  8:12             ` Wincent Colaiuta
2007-11-07  8:02           ` Junio C Hamano
2007-11-07  8:23           ` Pierre Habouzit
2007-11-06 18:07 ` git pull opinion Pascal Obry
2007-11-07  7:06   ` Uwe Kleine-König
2007-11-07  7:40     ` Pascal Obry

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=20071106083144.GA4435@artemis.corp \
    --to=madcoder@debian.org \
    --cc=aghilesk@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=raa.lkml@gmail.com \
    --cc=rael@zopyra.com \
    /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.