{"thread":{"id":"11787","subject":"simple cvs-like git wrapper","startedAt":"2008-01-29T20:40:48Z","lastAt":"2008-02-01T15:35:36Z","messageCount":15,"participants":["Ed S. Peschko","Jakub Narebski","Shawn O. Pearce","Daniel Barkalow","Junio C Hamano","Uwe Kleine-König","Kate Rhodes","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"66855","messageId":"20080129204048.GA9612@venus","threadId":"11787","inReplyTo":null,"subject":"simple cvs-like git wrapper","fromName":"Ed S. Peschko","fromEmail":"esp5@pge.com","sentAt":"2008-01-29T20:40:48Z","receivedAt":"2008-01-29T20:40:48Z","isPatch":false,"sender":{"key":"esp5@pge.com","avatar":null},"body":"hey all,\n\nWe've been trying out git here for a while now, and we've noticed two\nthings that we both like and dislike: git's flexibility, and git's\nflexibility.\n\n\nGit's flexibility is great in the sense that power users can basically\nbend git to their will, but its' flexibility is also causing workflow\nissues in our environment, where beginning users can get lost in all \nthe options that it has, and this is causing communication issues for \nthese folks with the rest of our team.\n\n\nHence, I was hoping that people could suggest ways of \nsimplifying git, making a cvs-like frontend for people to use. \n\nI was thinking of something like this:\n\ngvs branch <branch name>: \n\n\tcreates a branch for people to start making edits on in their\n\tlocalized copy.\n\ngvs commit:\n\n\tcommits that branch to a centralized git repository.\n\ngvs update:\n\n    Takes the latest changes, from all branches, that everyone \n\telse has committed into the centralized git repository, and merges \n\tthem onto the current branch. \n\ngvs list:\n\n\tlists all the branches that have been merged into the current\n\tworkspace.\n\n\nIn other words, what I'm looking for is sort of 'cvs+'.  Instead of\nworking on one, synchronized branch as per cvs, we want to work on several,\nparallel, branches that synchronize on intervals.\n\nWe basically want this for managing related changesets - we want \nto be able to switch from one patch branch to another and commit them\nseparately - but we don't want to sacrifice the automatic integration\nthat you get from cvs by doing:\n\n\tcvs update\n\non a given branch.\n\nAnyways, hope this makes sense. I'm not sure how feasible the above is - \nit's meant to be as simple it can be, with as much DWIM-ness as possible.  \nAny feedback is appreciated.\n\n\nEd\n\n(\nps - We could just use CVS of course, but that's just too simple, \nwith no easy way of managing which change goes along with which \nfeature request... \n)\n"},{"id":"66863","messageId":"m3hcgw8dz7.fsf@localhost.localdomain","threadId":"11787","inReplyTo":"20080129204048.GA9612@venus","subject":"Re: simple cvs-like git wrapper","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-01-29T22:28:02Z","receivedAt":"2008-01-29T22:28:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Ed S. Peschko\" <esp5@pge.com> writes:\n\n> We've been trying out git here for a while now, and we've noticed two\n> things that we both like and dislike: git's flexibility, and git's\n> flexibility.\n> \n> \n> Git's flexibility is great in the sense that power users can basically\n> bend git to their will, but its' flexibility is also causing workflow\n> issues in our environment, where beginning users can get lost in all \n> the options that it has, and this is causing communication issues for \n> these folks with the rest of our team.\n[...]\n> gvs update:\n> \n>     Takes the latest changes, from all branches, that everyone \n> \telse has committed into the centralized git repository, and merges \n> \tthem onto the current branch. \n[...]\n> We basically want this for managing related changesets - we want \n> to be able to switch from one patch branch to another and commit them\n> separately - but we don't want to sacrifice the automatic integration\n> that you get from cvs by doing:\n> \n> \tcvs update\n> \n> on a given branch.\n\nOne thing (besides horrible branching and even worse merging)  which I\nhated in multi-user CVS is the \"cvs update\", namely the fact that if\nyou want to commit changes, you _have_ to rebase them on top of\ncurrent work. So when you are ready to commit, when you have tested\neverything, you are sometimes forced to resolve a merge to be able to\ncommit... and have to test resolved merge... and perhaps again, and\nagain.\n\nWorking on branches is much nicer IMVHO. And it allows to separate\nchanges into series of small, incremental commits[*1*]. If you want to\nwork in centralized or semi-centralized way, you probably would want\nto use rebase based workflow, with \"git pull --rebase\" (which just got\nimplemented).\n\nFootonotes:\n===========\n[*1*] I'd like to point to LKML post about creating perfect patch\n*series*, but I have forgot to bookmark it, and canot find it again\n(IIRC somebody posted link some time ago here on git mailing list).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"66876","messageId":"20080130021050.GB9612@venus","threadId":"11787","inReplyTo":"m3hcgw8dz7.fsf@localhost.localdomain","subject":"Re: simple cvs-like git wrapper","fromName":"Ed S. Peschko","fromEmail":"esp5@pge.com","sentAt":"2008-01-30T02:10:50Z","receivedAt":"2008-01-30T02:10:50Z","isPatch":false,"sender":{"key":"esp5@pge.com","avatar":null},"body":"> One thing (besides horrible branching and even worse merging)  which I\n> hated in multi-user CVS is the \"cvs update\", namely the fact that if\n> you want to commit changes, you _have_ to rebase them on top of\n> current work. So when you are ready to commit, when you have tested\n> everything, you are sometimes forced to resolve a merge to be able to\n> commit... and have to test resolved merge... and perhaps again, and\n> again.\n\nYeah, I realize that it's not exactly the best solution for every\nproject, but for projects tied to a piece of hardware (ie: a database, a\nparticular box, etc), its much more important to be in sync, to have \n'one true view' of the world rather than to have the freedom to have \nmultiple views.\n\nIn our case, our code is tied to a database and a database instance. An\nenvironment equals attachment to a given oracle SID. If someone is out of sync\nwith other people's changes, then that person's environment is wrong.\n\n\n> Working on branches is much nicer IMVHO. And it allows to separate\n> changes into series of small, incremental commits[*1*]. If you want to\n> work in centralized or semi-centralized way, you probably would want\n> to use rebase based workflow, with \"git pull --rebase\" (which just got\n> implemented).\n\n\nI agree with you, however, with the working on branches. We need the \nability to do the small incremental commits, and then tie them back to\nSOX requirements (bleah). \n\nHence the hope for the automatic merging along with a given branch - that, \nwhen you do an 'gvs update', it takes all the outstanding deltas on all the\nbranches that have been uploaded into the central repository, and applies \nthem, one by one, to your local repository, and keeps the branch intact.\n\nThat it basically does the perfect patch series functionality you are\ntalking about, but in an automatic way..\n\n\nA couple of questions:\n\n\t1. How do you get a list - on a shared, remote, repository - of all the \n       branches that a shared repository contains, from the point of\n\t   view of a client? ie: git-branch shows local branches..\n\n    2. Could the above 'gvs update' be implemented in terms of a series \n\t   of 'git pull --rebase' or even 'git pull' merges from the\n\t   centralized repository based on the output from the command \n       above?\n\nAnyways, I wouldn't mind it if 'gvs update' paused at the end of\neach merge - that you'd do a 'gvs update', it would show you exactly what\nwas going to merge before it did it (maybe even via a vimdiff of old and \nnew side by side), and would allow you to do a regression test after\neach patchset was applied..\n\nAfter all, it's my wrapper so I'll implement it the way I like it.. ;-)\n\nThanks,\n\nEd\n\n\n> \n> Footonotes:\n> ===========\n> [*1*] I'd like to point to LKML post about creating perfect patch\n> *series*, but I have forgot to bookmark it, and canot find it again\n> (IIRC somebody posted link some time ago here on git mailing list).\n> \n> -- \n> Jakub Narebski\n> Poland\n> ShadeHawk on #git\n"},{"id":"66877","messageId":"20080130040002.GM24004@spearce.org","threadId":"11787","inReplyTo":"20080130021050.GB9612@venus","subject":"Re: simple cvs-like git wrapper","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-01-30T04:00:02Z","receivedAt":"2008-01-30T04:00:02Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Ed S. Peschko\" <esp5@pge.com> wrote:\n> In our case, our code is tied to a database and a database instance. An\n> environment equals attachment to a given oracle SID. If someone is out of sync\n> with other people's changes, then that person's environment is wrong.\n\nSurely not every single code change impacts the database schema\nand meaning of column values?  If that were truely the case then\nI'd say you have bigger issues to tackle.\n\nThere's perfectly valid reasons a user (or several users) may go\noff on a branch for a little while.  Like maybe they are working\ntogether to refactor a chunk of front end user interface, to better\nhandle result sets >100 rows, something that wasn't anticipated\nwould ever happen when the system was first built.  It happens.\nThere may not be any database changes involved on that but it may\nbe distrubtive enough that you don't want to see their changes\nuntil its mostly done.\n\nI've been there, done that with Oracle and CVS.  Having Git makes\nit a whole lot easier to go off on a side branch when refactoring\na chunk of UI, as you don't have to impact all of your coworkers\nright away.\n \n> I agree with you, however, with the working on branches. We need the \n> ability to do the small incremental commits, and then tie them back to\n> SOX requirements (bleah). \n\nSo, uh, mention the requirement using some sort of unique requirement\nidentifier in each commit message, and use a commit-msg hook to\nmake sure you didn't forget to include the requirement number.\nWe make links like that in our issue tracking system with \"lpmNNNN\"\nkeywords, where NNNN is the issue tracker number.\n\nIf you ever want to know what changes were done for a particular\nrequirement, pop open gitk and search for contains \"soxNNNN\", or use\n`git log --grep=soxNNN`, and there's your list.\n \n> Hence the hope for the automatic merging along with a given branch - that, \n> when you do an 'gvs update', it takes all the outstanding deltas on all the\n> branches that have been uploaded into the central repository, and applies \n> them, one by one, to your local repository, and keeps the branch intact.\n\nI don't think you fully understand what git-merge does.  It retains\nthe full history of every individual change made along that branch,\nas well as who performed the merge, and when.  Git also tracks if\nthe merge makes changes that weren't on either parent branch, and\ncorrectly blames such changes to the individual who did the merge.\nMost older SCMs are simply not able to do such detailed reporting.\nHeck, some modern SCMs also can't do it.\n\n> That it basically does the perfect patch series functionality you are\n> talking about, but in an automatic way..\n\nYea, git-merge is totally freaking automatic.  Except when there is\na conflict.  Then you have to fix up a few things.  But Git isn't\na mind reader (yet) so there will always be cases where it doesn't\nquite do what you wanted it to without a little additional guidence.\n \n> A couple of questions:\n> \n> \t1. How do you get a list - on a shared, remote, repository - of all the \n>        branches that a shared repository contains, from the point of\n> \t   view of a client? ie: git-branch shows local branches..\n\nI think you are talking about `git ls-remote --heads url`.\n \n>     2. Could the above 'gvs update' be implemented in terms of a series \n> \t   of 'git pull --rebase' or even 'git pull' merges from the\n> \t   centralized repository based on the output from the command \n>        above?\n\nYes, but why are you merging all of the available branches?\nWhy aren't you merging a single specific branch?  It seems very odd\nto me that you want to merge every branch available.  I just cannot\nsee how that gives you any benefit over just having a single branch\ncalled \"master\" that you rebase your changes onto before pushing\nthem, thus enforcing a mostly linear history.\n\nOnly linear history has its downsides.  It doesn't really quite show\nyou what the commits were developed against.  So it may be possible\nthat after a rebase the end result compiles and works, but an\nearlier commit that used to work now doesn't, due to other changes.\n\nIf you are really worried about SOX requirements, I'd imagine you\nare also worried about SOX auditing.  In which case I would think\nthat for most changes that are going to be part of your permenant\nhistory don't want to use rebase, but instead merge, to show the\noriginal history of every change.\n\n> Anyways, I wouldn't mind it if 'gvs update' paused at the end of\n> each merge - that you'd do a 'gvs update', it would show you exactly what\n> was going to merge before it did it (maybe even via a vimdiff of old and \n> new side by side), and would allow you to do a regression test after\n> each patchset was applied..\n\nOne of my favorite ways to regression test every commit in a series\nduring a rebase is to use git-rebase -i:\n\n\t$ git rebase -i\n\t... editor opens ... which is vi ...\n\t:%s/^pick /edit /\n\t:wq\n\n\t... so now it stops between every patch ...\n\t$ while test -d .git/.dotest-merge; do \\\n\tmake clean test && git-rebase --continue || break; done\n\nIf anything breaks, you are right there on the broken change and\nyou can use `git show` to see it, `git commit --amend` to fix it up,\nyou can test the fix, and finally then continue the rebase to move\nonto the next change.\n\nI've got a 67 patch series I'm in the middle of doing at day-job\nusing that exact process.  Takes a few minutes per commit as our\nbuild cycle is slow, but it works darn well.  I'm letting it run\novernight as I expect it to get about 70% through before it finds\na problem, if it is going to find one.\n\n-- \nShawn.\n"},{"id":"66920","messageId":"alpine.LNX.1.00.0801301439070.13593@iabervon.org","threadId":"11787","inReplyTo":"20080130021050.GB9612@venus","subject":"Re: simple cvs-like git wrapper","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-01-30T19:49:53Z","receivedAt":"2008-01-30T19:49:53Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 29 Jan 2008, Ed S. Peschko wrote:\n\n> > One thing (besides horrible branching and even worse merging)  which I\n> > hated in multi-user CVS is the \"cvs update\", namely the fact that if\n> > you want to commit changes, you _have_ to rebase them on top of\n> > current work. So when you are ready to commit, when you have tested\n> > everything, you are sometimes forced to resolve a merge to be able to\n> > commit... and have to test resolved merge... and perhaps again, and\n> > again.\n> \n> Yeah, I realize that it's not exactly the best solution for every\n> project, but for projects tied to a piece of hardware (ie: a database, a\n> particular box, etc), its much more important to be in sync, to have \n> 'one true view' of the world rather than to have the freedom to have \n> multiple views.\n\nActually, it's a simpler concern: with CVS (and most version control \nsystems), you can't make a permanent record of your state without \nresolving conflicts. With git, you make the permanent record first, and \nthen resolve conflicts in order to get a state that includes your changes \nand can be pushed to the shared location. With git, you can still have \n\"one true view\" of the world; it's just that git really really doesn't \nwant to lose your work, so it refuses to overwrite your files unless \nyou've put them in its storage, where it can give them back if it does \nsomething wrong with your working tree.\n\nOf course, your \"gvs update\" could do a local git commit of the current \nstate, fetch the remote changes, and rebase the local commit onto them, so \nit's not necessarily a workflow change. But note that, if the user fails \nto do a manual merge, the user can try again, or try working on a \ndifferent branch, or fork at that point, depending on how hopeless the \nsituation is.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"66933","messageId":"20080130225254.GC9612@venus","threadId":"11787","inReplyTo":"20080130040002.GM24004@spearce.org","subject":"Re: simple cvs-like git wrapper","fromName":"Ed S. Peschko","fromEmail":"esp5@pge.com","sentAt":"2008-01-30T22:52:54Z","receivedAt":"2008-01-30T22:52:54Z","isPatch":false,"sender":{"key":"esp5@pge.com","avatar":null},"body":"On Tue, Jan 29, 2008 at 11:00:02PM -0500, Shawn O. Pearce wrote:\n> \"Ed S. Peschko\" <esp5@pge.com> wrote:\n> > In our case, our code is tied to a database and a database instance. An\n> > environment equals attachment to a given oracle SID. If someone is out of sync\n> > with other people's changes, then that person's environment is wrong.\n> \n> Surely not every single code change impacts the database schema\n> and meaning of column values?  If that were truely the case then\n> I'd say you have bigger issues to tackle.\n\nwell, no, but I'd say 80-90% of the changes we have are ones that we\nwant to instantly share with everybody. I was thinking that ones that\nwe didn't would be prefixed, as in:\n\n\tgit-branch exp-<change_name>\n\nand those would need to be renamed explicitly to become 'mainline'\nbranches before they were merged..\n\nYou've got some good points, and my original intent was to\nanswer them point-by-point, but suffice to say:\n\n\t1. I was hoping to make each branch correspond to a work request,\n\t   that would be tracked for SOX. We also need to track the changes\n\t   in mercury interactive, not git, so I've got some challenges\n\t   there in making a wrapper to handle this.\n\n\n\t2. A single, linear history on the remote end wouldn't be easy for\n\t   reporting purposes.\n\n    3. A single linear history on the remote end wouldn't support \n\t   the rare cases where I *do* want a single change.\n\n\nI guess my scheme's workability depends on how effective git is at \ndoing merges from branch to branch, and how good it is at fixing\nconflicts in a way that is simple for the user. In CVS, I get: \n\n    >>>>>\n    ...\n    =====\n    ...\n    <<<<<\n\n\nwhen a conflict occurs, and you need to resolve that conflict before\nre-committing again. Does git do a similar thing?\n\nAlso, with git-ls-remote - is there a way to see more information \nabout the remote branch rather than just its name, ie: can you say:\n\n    git-ls-remote -l --heads origin\n\nto get a list of changes in the order they were made? And is there a \ncommand that does what I want, ie:\n\n\tgit pull origin --all \n\nWhich pulls all branches from origin and merges them into the current\nbranch in an intelligent way, ie: by order in which the branches were \ncommitted, or even:\n\n\tgit pull origin --re: '^(?!exp)'\n\nwhich pulls in all branches matching a given regular expression (in this\ncase, not matching 'exp' at the beginning..\n\nEd\n"},{"id":"66956","messageId":"20080131040839.GW24004@spearce.org","threadId":"11787","inReplyTo":"20080130225254.GC9612@venus","subject":"Re: simple cvs-like git wrapper","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-01-31T04:08:39Z","receivedAt":"2008-01-31T04:08:39Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Ed S. Peschko\" <esp5@pge.com> wrote:\n> On Tue, Jan 29, 2008 at 11:00:02PM -0500, Shawn O. Pearce wrote:\n> \n> well, no, but I'd say 80-90% of the changes we have are ones that we\n> want to instantly share with everybody. I was thinking that ones that\n> we didn't would be prefixed, as in:\n> \n> \tgit-branch exp-<change_name>\n> \n> and those would need to be renamed explicitly to become 'mainline'\n> branches before they were merged..\n\nOK, that's sensible.\n \n> You've got some good points, and my original intent was to\n> answer them point-by-point, but suffice to say:\n> \n> \t1. I was hoping to make each branch correspond to a work request,\n> \t   that would be tracked for SOX. We also need to track the changes\n> \t   in mercury interactive, not git, so I've got some challenges\n> \t   there in making a wrapper to handle this.\n\nYea, that's not a bad idea, because then if a dev wants to make\nmultiple small changes before saying they are finished with a\nparticular request they can.\n\nI've got a script I use at final \"intergration\" point between\ndevelopers and the testing team that scans through all of the commit\nmessages for all changes since the last integration and updates\nour issue database automatically to mark those items in some way.\nRather short Perl script, except for the 1300 lines of hideous C\ncode to speak to the vendor's tracking software.  We find it works\nwell to hold off on updating external non-git records until near\nthe very end.\n\nYou do realize that in Git once a branch has been merged you can\ndelete that branch, and the history of all of those changes remains?\nGit itself has probably been built from thousands of individual\nbranches over the years, yet I'm positive Junio only has a small\nhandful (25-30) in his working repository that he uses to maintain\nGit.  This branches are only the \"live\" ones that are still being\nactively worked on and aren't ready for release.\n\nYup, there were 1,756 branches that lead up to v1.5.4-rc5:\n\n\t$ git rev-list --parents v1.5.4-rc5 \\\n\t  | perl -ne 'print if /.* .* .*/' \\\n\t  | wc -l\n    1756\n\nthat of course was since the beginning of time.  Since v1.5.3 we\nhave had about 240:\n\n\t$ git rev-list --parents v1.5.3..v1.5.4-rc5 \\\n\t  | perl -ne 'print if /.* .* .*/' \\\n\t  | wc -l\n    1756\n\n> \t2. A single, linear history on the remote end wouldn't be easy for\n> \t   reporting purposes.\n>   3. A single linear history on the remote end wouldn't support \n> \t   the rare cases where I *do* want a single change.\n\nSo by this it sounds like you don't want to ever use rebase?\nAnd instead encourage your team to always use git-merge or\ngit-pull (without its rebase flag).\n\n> I guess my scheme's workability depends on how effective git is at \n> doing merges from branch to branch, and how good it is at fixing\n> conflicts in a way that is simple for the user. In CVS, I get: \n> \n>     >>>>>\n>     ...\n>     =====\n>     ...\n>     <<<<<\n> \n> when a conflict occurs, and you need to resolve that conflict before\n> re-committing again. Does git do a similar thing?\n\nYes.  Git also tries harder to keep you from committing a file that\nhas an unresolved conflict in it.  Git's merging is a lot smarter\nthan CVS's ever was, as Git does automatic merge base detection\nduring each merge, so you don't have to keep track of this yourself.\n\n> Also, with git-ls-remote - is there a way to see more information \n> about the remote branch rather than just its name, ie: can you say:\n> \n>     git-ls-remote -l --heads origin\n> \n> to get a list of changes in the order they were made? And is there a \n> command that does what I want, ie:\n\nNope.  To really see anything further you need access to the objects.\nThat means either executing a tool like git-log directly on the\nserver, using gitweb through your webbrowser, or fetching the\nobjects down to your local repository with git-fetch, where you\ncan then browse them with any git log viewing tool (git-log, gitk,\nrev-list, etc.).\n\n> \tgit pull origin --all \n> \n> Which pulls all branches from origin and merges them into the current\n> branch in an intelligent way, ie: by order in which the branches were \n> committed, or even:\n\nMerging all branches on the remote named \"origin\" is simply not an\nintelligent thing to do.  Nobody blindly merges everything available\nfrom a remote, and nobody has ever asked for such a function before\nin Git.  I still think its nuts, but I don't know all details of\nyour situation so I'll just shut up now and hope you know what you\nare really asking for.\n \n> \tgit pull origin --re: '^(?!exp)'\n> \n> which pulls in all branches matching a given regular expression (in this\n> case, not matching 'exp' at the beginning..\n\nYou can do something like this, but I *really* think this is a\nhorribly bad idea:\n\n\t#!/bin/sh\n\n\t# Download all new branches, remove any now deleted branches.\n\t#\n\tgit fetch || exit\n\tgit remote prune origin || exit\n\n\t# Loop through all non-exp branches and merge them\n\t#\n\tfor b in $(git for-each-ref --format=%(refname) refs/remotes/origin)\n\tdo\n\t\tcase $b in\n\t\trefs/remotes/origin/exp-*)\n\t\t\t: do not merge\n\t\t\t;;\n\t\t*)\n\t\t\techo \"==> Merging ${b##refs/remotes/origin/} ...\"\n\t\t\tif git merge $b\n\t\t\tthen\n\t\t\t\t: good merge\n\t\t\telse\n\t\t\t\techo >&2\n\t\t\t\techo >&2 error: Fix conflicts, commit, rerun $0\n\t\t\t\texit 1\n\t\t\tfi\n\t\tesac\n\tdone\n\nThis is going to be slow as you are running git-merge for each\nand every branch available to you.  You can do a lot better by\nloading the branch DAG into memory in Perl/C/Python and doing a\ngraph coloring algorithm to see if a merge is necessary or not,\nas if you are merging everything all of the time almost everything\nis going to be always merged to everything else.  Which as I said\nearlier is nuts.\n\n-- \nShawn.\n"},{"id":"66958","messageId":"20080131054124.GG9612@venus","threadId":"11787","inReplyTo":"20080131040839.GW24004@spearce.org","subject":"Re: simple cvs-like git wrapper","fromName":"Ed S. Peschko","fromEmail":"esp5@pge.com","sentAt":"2008-01-31T05:41:24Z","receivedAt":"2008-01-31T05:41:24Z","isPatch":false,"sender":{"key":"esp5@pge.com","avatar":null},"body":"> Merging all branches on the remote named \"origin\" is simply not an\n> intelligent thing to do.  Nobody blindly merges everything available\n> from a remote, and nobody has ever asked for such a function before\n> in Git.  I still think its nuts, but I don't know all details of\n> your situation so I'll just shut up now and hope you know what you\n> are really asking for.\n\nOk, I'm not going to belabor the point, but for the most part, the\nrequests in our particular domain are separate. A developer for the\nmost part works only on files that other developers are not working on.\n\nThere are exceptions to this, but for the most part this is true..\nHence, most of the time there will be no conflicts.\n\nAnyways, I'll try to improve on your script, but it looks like what I\nwant to do.\n\n> This is going to be slow as you are running git-merge for each\n> and every branch available to you.  You can do a lot better by\n> loading the branch DAG into memory in Perl/C/Python and doing a\n> graph coloring algorithm to see if a merge is necessary or not,\n> as if you are merging everything all of the time almost everything\n> is going to be always merged to everything else.  Which as I said\n> earlier is nuts.\n\nhmm. Is there a simple method to get this graph? I'm assuming that you\nwould have to get all the local commits and compare them to the remote\ncommits, and only merge the branches that have commits not yet \nmerged..\n\nEd\n\n> -- \n> Shawn.\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"66960","messageId":"20080131060136.GZ24004@spearce.org","threadId":"11787","inReplyTo":"20080131054124.GG9612@venus","subject":"Re: simple cvs-like git wrapper","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-01-31T06:01:37Z","receivedAt":"2008-01-31T06:01:37Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Ed S. Peschko\" <esp5@pge.com> wrote:\n> > This is going to be slow as you are running git-merge for each\n> > and every branch available to you.  You can do a lot better by\n> > loading the branch DAG into memory in Perl/C/Python and doing a\n> > graph coloring algorithm to see if a merge is necessary or not,\n> > as if you are merging everything all of the time almost everything\n> > is going to be always merged to everything else.  Which as I said\n> > earlier is nuts.\n> \n> hmm. Is there a simple method to get this graph? I'm assuming that you\n> would have to get all the local commits and compare them to the remote\n> commits, and only merge the branches that have commits not yet \n> merged..\n\nSomething along these lines:\n\n\t%remotes = \\\n\t\tgit for-each-ref \\\n\t\t--format='%(objname) %(refname)' \\\n\t\trefs/remotes/origin;\n\n\t@lines = \\\n\t\tgit rev-list \\\n\t\tkeys %remotes \\\n\t\t--not HEAD\n\n\tforeach $line in @lines {\n\t\tif $remotes contains $line\n\t\t\tgit merge $remotes{$line}\n\t}\n\nThat gets you the graph.  The %(objname) string coming back from\nfor-each-ref is in $line in the loop.  If you see $line inside that\nmap you built from for-each-ref then that commit isn't yet in the\ncurrent branch.  So you'd then want to merge that commit.\n\n-- \nShawn.\n"},{"id":"66961","messageId":"7v63xafrit.fsf@gitster.siamese.dyndns.org","threadId":"11787","inReplyTo":"20080131040839.GW24004@spearce.org","subject":"Re: simple cvs-like git wrapper","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-31T06:17:14Z","receivedAt":"2008-01-31T06:17:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> writes:\n\n> This is going to be slow as you are running git-merge for each\n> and every branch available to you.  You can do a lot better by\n> loading the branch DAG into memory in Perl/C/Python and doing a\n> graph coloring algorithm to see if a merge is necessary or not,\n> as if you are merging everything all of the time almost everything\n> is going to be always merged to everything else.  Which as I said\n> earlier is nuts.\n\nI guess you can ask \"show-branch --independent\" to cull branches\nthat are pure subset of other branches.\n\nBut no matter how you do this, the resulting history would be\nless efficient to bisect if you make Octopus.\n\nAs you can ask \"git log --no-merges\" to omit merges from the\nlisting, I am not sure if it is worth it to avoid two-side\nmerges and insist on making an Octopus these days.\n"},{"id":"67012","messageId":"20080201072935.GA941@informatik.uni-freiburg.de","threadId":"11787","inReplyTo":"m3hcgw8dz7.fsf@localhost.localdomain","subject":"Re: simple cvs-like git wrapper","fromName":"Uwe Kleine-König","fromEmail":"ukleinek@informatik.uni-freiburg.de","sentAt":"2008-02-01T07:29:35Z","receivedAt":"2008-02-01T07:29:35Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello,\n\n> Footonotes:\n> ===========\n> [*1*] I'd like to point to LKML post about creating perfect patch\n> *series*, but I have forgot to bookmark it, and canot find it again\n> (IIRC somebody posted link some time ago here on git mailing list).\nI remember:\n\n\thttp://groups.google.com/group/linux.kernel/browse_thread/thread/26f1247fd4a2acbf/ac9743b603e53bae?lnk=gst&q=perfect+patch#ac9743b603e53bae\n\n.  Do you mean that?\n\nBest regards\nUwe\n\n-- \nUwe Kleine-König\n"},{"id":"67019","messageId":"200802011058.59464.jnareb@gmail.com","threadId":"11787","inReplyTo":"20080201072935.GA941@informatik.uni-freiburg.de","subject":"Re: simple cvs-like git wrapper","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-01T09:58:57Z","receivedAt":"2008-02-01T09:58:57Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Uwe Kleine-König wrote:\n> \n> > Footonotes:\n> > ===========\n> > [*1*] I'd like to point to LKML post about creating perfect patch\n> > *series*, but I have forgot to bookmark it, and canot find it again\n> > (IIRC somebody posted link some time ago here on git mailing list).\n>\n> I remember:\n> \n> \thttp://groups.google.com/group/linux.kernel/browse_thread/thread/26f1247fd4a2acbf/ac9743b603e53bae?lnk=gst&q=perfect+patch#ac9743b603e53bae\n> \n> .  Do you mean that?\n\nThanks a lot, but it is not what I was searching for. This is interesting\narticle about what to put and what to not put in the cover letter [0/n],\nwhile I am trying to find post about how to divide/split change into\nseries of commits implementing one separate part, so the whole is easy\nto understand and bisectable.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"67026","messageId":"1201871157.D6625E4@ea26.dngr.org","threadId":"11787","inReplyTo":"20080130021050.GB9612@venus","subject":"Re: simple cvs-like git wrapper","fromName":"Kate Rhodes","fromEmail":"masukomi@gmail.com","sentAt":"2008-02-01T13:05:56Z","receivedAt":"2008-02-01T13:05:56Z","isPatch":false,"sender":{"key":"masukomi@gmail.com","avatar":null},"body":"I'm leaning towards agreement with Shawn that you're a little confused \nas to how syncing works or you're not adequately expressing what you're \nreally hoping for and why git isn't doing it and we're misunderstanding \nyou.\n\nRegardless, if you're looking for something that will pull down all the \nupdates from a central branch, merge them in, and then rebase your \ncurrent changes on top of it you should check out how git-p4 does it in \norder to get the basic mechanics for your script.\n\n~kate = masukomi\nhttp://weblog.masukomi.org\n"},{"id":"67030","messageId":"alpine.LSU.1.00.0802011318590.7372@racer.site","threadId":"11787","inReplyTo":"1201871157.D6625E4@ea26.dngr.org","subject":"Re: simple cvs-like git wrapper","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-01T13:25:07Z","receivedAt":"2008-02-01T13:25:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 1 Feb 2008, Kate Rhodes wrote:\n\n> I'm leaning towards agreement with Shawn that you're a little confused \n> as to how syncing works or you're not adequately expressing what you're \n> really hoping for and why git isn't doing it and we're misunderstanding \n> you.\n\nWell, the thing is: git (plumbing) does not really care about syncing and \nhow that works.  The core of git is \"just\" a very clever object database, \ngeared towards revision control.\n\nSo in theory, Ed could just go and write a porcelain for git, which does \n_exactly_ what he wants, yet would be mostly interoperable with other git \nporcelains.\n\nI imagine that the \"cvsish update\" would boil down to fetching upstream, \nupdating the index with what the user has in the working directory \n(something like \"git add -u\"), then write out a tree from that, and call \nmerge-recursive on that tree and the upstream's current tree.  Force fast \nforward master, but keep the index, keeping the error output of \nmerge-recursive.  Done.\n\nHowever, you need to understand the internals of git enough to do that.  \nEspecially the conflict management, and its relation with the index.\n\nAnd I cannot see how that understanding would not lead to abandoning that \nwork-flow as suboptimal.  But hey, that's just my private opinion.\n\nCiao,\nDscho\n"},{"id":"67034","messageId":"200802011635.37255.jnareb@gmail.com","threadId":"11787","inReplyTo":"20080130021050.GB9612@venus","subject":"Re: simple cvs-like git wrapper","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-01T15:35:36Z","receivedAt":"2008-02-01T15:35:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 30 Jan 2008, Ed S. Peschko wrote:\n> Jakub narebski wrote:   <-- re added\n\nPlease try to not remove attributions. TIA.\n\n>> One thing (besides horrible branching and even worse merging)  which I\n>> hated in multi-user CVS is the \"cvs update\", namely the fact that if\n>> you want to commit changes, you _have_ to rebase them on top of\n>> current work. So when you are ready to commit, when you have tested\n>> everything, you are sometimes forced to resolve a merge to be able to\n>> commit... and have to test resolved merge... and perhaps again, and\n>> again.\n> \n> Yeah, I realize that it's not exactly the best solution for every\n> project, but for projects tied to a piece of hardware (ie: a database, a\n> particular box, etc), its much more important to be in sync, to have \n> 'one true view' of the world rather than to have the freedom to have \n> multiple views.\n> \n> In our case, our code is tied to a database and a database instance. An\n> environment equals attachment to a given oracle SID. If someone is out of sync\n> with other people's changes, then that person's environment is wrong.\n\nErr, if it is as bad as you say, and it is not possible to change\nenvironment to what is saved in commit [message] on git-checkout\nand on git-reset this just removes any possibility of parallel\ndevelopment. Not that CVS-like centralized development would do\nmuch better in such case...\n\nIt would be nice to save environment state somehow in the commit,\nor in worktree / commit tree. Versioning databases (or is it just\ndatabase schema) is PITA, and I don't know any good solution. phpBB\nmodules which need to modify database have some kind of diff-like\nthing, but...\n\n[cut]\n----\nBelow there is description of \"cvs update\" workflow and how it can\nbe implemented in git, rebase based workflow which is very similar\nbut allows to generate small incremental commits while retaining\nlinear history, and default merge based workflow.\n\n(Perhaps something like that should be added to cvs-migration.txt?)\n\nLet's assume that time, or rather parentage/sequence of commits flow\nfrom left to right, so \"A---B\" means that B is child of commit A (is\nlater revision), and that A is parent of commit B.  Let us mark\nuncommited changes by '*'.\n\n1. First, how 'cvs commit' and 'cvs update' works.\n1.1. The case where there were no changes in the central (origin)\n     repository\n\n     before \"cvs commit\"\n\n       A---B---C---* \n\n     after \"cvs commit\"\n\n       A---B---C---D\n\n1.2. The case where there were changes in the origin repo\n     (\"cvs commit\" says: need to update, or something like that)\n\n     before \"cvs commit\", and \"cvs update\"\n\n       A---B---C---*\n\n     after \"cvs update\"\n\n       A---B---C---d---e---*'\n\n     where *' means that the state might be modified wrt. *; you might\n     have to resolve conflicts, while still not having you work saved\n     under version control anywhere\n\n     after \"cvs commit\" (and after resolving conficts, if there were any)\n\n\n       A---B---C---d---e---F \n\nYou can implement such workflow in git by stashing your changes, doing\nfasfforward-only pull (or fetch), then unstashing changes, resolving\nconflicts if there are any, and finally commiting changes. You would\nhave to implement \"needs update\" pre-commit hook if you want to follow\nCVS workflow fully.\n\nNOTE that while you are working on '*' somobody might have changed\nenvironment!\n\n\n2. Rebase based workflow; the \"git pull --rebase\" needs new enough git\n   version\n\n   before your work (common base both on your local repository, and\n   in the origin / central / distribution point one)\n\n     A---B---C\n\n   you create a few commits, splitting your work into small, self\n   contained, easy to understand, bisectable commits\n\n     A---B---C---1---2\n\n   now you want to be up to date wrt central repository, to send your\n   changes (push, publish) to central repo, via \"git pull --rebase\"\n\n\n     A---B---C---1---2\n              \\\n               \\-d---e\n\n     A---B---C---1---2\n              \\\n               \\-d---e---1'---2'\n\n     A---B---C---d---e---1'---2'\n\n   where 1' and 2' are your commits modified by the presence of\n   'd' and 'e' in the commit chain. Note that in the process of moving\n   (copying) your changes on top of fetched changes from central repo\n   there can be conflicts.\n\n\n3. Merge based workflow; ordinary \"git pull\"\n\n   before your work (common base both on your local repository, and\n   in the origin / central / distribution point one)\n\n     A---B---C\n\n   you create a few commits, splitting your work into small, self\n   contained, easy to understand, bisectable commits\n\n     A---B---C---1---2\n\n   now you want to be up to date wrt central repository, to send your\n   changes (push, publish) to central repo, via \"git pull\"\n\n\n     A---B---C---1---2\n              \\\n               \\-d---e\n\n     A---B---C---1---2---M\n              \\         /\n               \\-d---e-/\n\n   where M is a merge commit; you might have to resolve conflicts here.\n\n-- \nJakub Narebski\nPoland\n"}]}