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

Re: git versus CVS (versus bk)

From
Petr Baudis <pasky@suse.cz>
Date
Nov 1, 2005, 17:35 UTC
Message-ID
<20051101173502.GA16528@pasky.or.cz>
In-Reply-To
<20051101161730.GV11488@ca-server1.us.oracle.com>

Dear diary, on Tue, Nov 01, 2005 at 05:17:30PM CET, I got a letter where Joel Becker <Joel.Becker@oracle.com> told me that...

Show 12 quoted lines
> On Tue, Nov 01, 2005 at 10:15:33AM +0100, Petr Baudis wrote:
> > Personally, from my POV it is the intended mode of development only if
> > you keep strictly topical branches (a single logical change and fixes of
> > it on top of that). Otherwise, this is horrid because it loses the
> > _precious_ history and bundles us different changes to a single commit,
> > which is one of the thing that are wrong on CVS/SVN merging.
> 
> 	Here we have the "precious" history vs the "throwaway" history
> argument again.  You are correct, this does look like CVS/Subversion
> merging.  But I'm quite capable of keeping my patches single-topic.
> Anything that requires multiple patches in a logical separation still
> needs that extra love.

Well, ok, so I assume you are indeed using strictly topical branches. .

Show 5 quoted lines
> > That said, with a big warning, I would be willing to do something like
> > cg-merge -s and cg-update -s (s as squash), with a big warning that this
> 
> 	Wouldn't it be cg-pull?  I guess I'm not conversant enough of
> all ways to merge branches in cogito.
cg-pull just fetches stuff, no merging done.

Ok, in theory you do not actually need to fetch the intermediate history in case you are going to squash (unless you are going to default the final commit message to concatenation of the intermediate ones), but arranging that would not be easy to arrange with the current git tools, I think. And neither feasible. But actually, I would like to do something like this later, support for CVS/SVN-like tracking by always having only the latest tree and no intermediate states, so that people who just want to run the latest and want to do no development are not forced to download anything useless for them.

Show 8 quoted lines
> > is suitable only for topical branches. And I think it'd be still much
> > better to spend the work making StGIT able to track history of changes
> > to a particular patch.
> 
> 	I like quilt for certain work, and what I read from you and
> Caitlin makes me interested in StGIT for those large changes that
> require split-out patches.  But for simple tasks, I just want to use the
> SCM, you know?

Well, if you are already going to deform the history, StGIT (able to track patch history) is just the best tool for that.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
Previous: Joel BeckerNext: Petr Baudis
Message 17 of 61 in “git versus CVS (versus bk)”
  1. waltOct 31, 2005
  2. Martin LanghoffOct 31, 2005
  3. H. Peter AnvinOct 31, 2005
  4. Linus TorvaldsOct 31, 2005
  5. Johannes SchindelinOct 31, 2005
  6. Linus TorvaldsOct 31, 2005
  7. wa1ter@myrealbox.comOct 31, 2005
  8. Randal L. SchwartzOct 31, 2005
  9. waltOct 31, 2005
  10. Daniel BarkalowNov 1, 2005
  11. Linus TorvaldsNov 1, 2005
  12. Joel BeckerOct 31, 2005
  13. Martin LanghoffOct 31, 2005
  14. Joel BeckerOct 31, 2005
  15. Petr BaudisNov 1, 2005
  16. Joel BeckerNov 1, 2005
  17. Petr BaudisNov 1, 2005
  18. Petr BaudisNov 7, 2005
  19. Josef WeidendorferNov 8, 2005
  20. Petr BaudisNov 8, 2005
  21. Randal L. SchwartzNov 1, 2005
  22. Linus TorvaldsNov 1, 2005
  23. Randal L. SchwartzNov 1, 2005
  24. Linus TorvaldsNov 1, 2005
  25. Junio C HamanoNov 1, 2005
  26. Junio C HamanoOct 31, 2005
  27. Joel BeckerOct 31, 2005
  28. Linus TorvaldsOct 31, 2005
  29. Junio C HamanoOct 31, 2005
  30. Joel BeckerOct 31, 2005
  31. Junio C HamanoNov 1, 2005
  32. Joel BeckerNov 1, 2005
  33. Martin LanghoffNov 1, 2005
  34. Joel BeckerNov 1, 2005
  35. Linus TorvaldsNov 1, 2005
  36. Petr BaudisNov 1, 2005
  37. Catalin MarinasNov 1, 2005
  38. Theodore Ts'oNov 1, 2005
  39. hgmq vs. StGITPetr Baudis, Nov 1, 2005
  40. Catalin MarinasNov 1, 2005
  41. Petr BaudisNov 1, 2005
  42. Catalin MarinasNov 1, 2005
  43. Chuck LeverNov 1, 2005
  44. Chris MasonNov 1, 2005
  45. Catalin MarinasNov 1, 2005
  46. Chris MasonNov 1, 2005
  47. Catalin MarinasNov 1, 2005
  48. Chris MasonNov 2, 2005
  49. Catalin MarinasNov 5, 2005
  50. Petr BaudisNov 9, 2005
  51. Pavel MachekNov 10, 2005
  52. Catalin MarinasNov 10, 2005
  53. Chris MasonNov 1, 2005
  54. Linus TorvaldsNov 1, 2005
  55. Catalin MarinasNov 1, 2005
  56. Catalin MarinasNov 1, 2005
  57. Chris MasonNov 1, 2005
  58. Catalin MarinasNov 1, 2005
  59. Daniel BarkalowNov 1, 2005
  60. Linus TorvaldsOct 31, 2005
  61. wa1ter@myrealbox.comOct 31, 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.