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

Re: git pull opinion

From
Pierre Habouzit <madcoder@debian.org>
Date
Nov 6, 2007, 08:31 UTC
Message-ID
<20071106083144.GA4435@artemis.corp>
In-Reply-To
<20071106073841.GB3021@steel.home>
On Tue, Nov 06, 2007 at 07:38:41AM +0000, Alex Riesen wrote:
Show 28 quoted lines
> 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
Previous: Alex RiesenNext: Andreas Ericsson
Message 13 of 43 in “git pull opinion”
  1. AghilesNov 5, 2007
  2. Jakub NarebskiNov 5, 2007
  3. Johannes SchindelinNov 6, 2007
  4. AghilesNov 6, 2007
  5. Johannes SchindelinNov 6, 2007
  6. Junio C HamanoNov 6, 2007
  7. Johannes SchindelinNov 6, 2007
  8. Alex RiesenNov 5, 2007
  9. Junio C HamanoNov 5, 2007
  10. Bill LearNov 6, 2007
  11. Pierre HabouzitNov 6, 2007
  12. Alex RiesenNov 6, 2007
  13. Pierre HabouzitNov 6, 2007
  14. Andreas EricssonNov 6, 2007
  15. Johannes SchindelinNov 6, 2007
  16. Andreas EricssonNov 6, 2007
  17. Johannes SchindelinNov 6, 2007
  18. Andreas EricssonNov 6, 2007
  19. AghilesNov 6, 2007
  20. Alex RiesenNov 6, 2007
  21. Linus TorvaldsNov 6, 2007
  22. AghilesNov 7, 2007
  23. Johannes SchindelinNov 8, 2007
  24. Linus TorvaldsNov 10, 2007
  25. Steven GrimmNov 6, 2007
  26. AghilesNov 6, 2007
  27. Miklos VajnaNov 5, 2007
  28. AghilesNov 6, 2007
  29. Benoit SigoureNov 6, 2007
  30. Ralf WildenhuesNov 6, 2007
  31. Johannes SchindelinNov 6, 2007
  32. Ralf WildenhuesNov 6, 2007
  33. AghilesNov 6, 2007
  34. Pierre HabouzitNov 6, 2007
  35. Mark 'git stash [message...]' as deprecatedBrian Downing, Nov 7, 2007
  36. Disable implicit 'save' argument for 'git stash'Brian Downing, Nov 7, 2007
  37. Johannes SixtNov 7, 2007
  38. Wincent ColaiutaNov 7, 2007
  39. Junio C HamanoNov 7, 2007
  40. Pierre HabouzitNov 7, 2007
  41. Pascal ObryNov 6, 2007
  42. Uwe Kleine-KönigNov 7, 2007
  43. Pascal ObryNov 7, 2007

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.