{"thread":{"id":"5228","subject":"[RFC] git-publish","startedAt":"2006-08-13T16:34:49Z","lastAt":"2006-09-24T12:06:34Z","messageCount":14,"participants":["Daniel Barkalow","Junio C Hamano","Johannes Schindelin","Sam Ravnborg","Fredrik Kuivinen","Martin Langhoff","Shawn Pearce","Alex Riesen","Jeff King","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"25185","messageId":"Pine.LNX.4.64.0608131158500.9789@iabervon.org","threadId":"5228","inReplyTo":null,"subject":"[RFC] git-publish","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-08-13T16:34:49Z","receivedAt":"2006-08-13T16:34:49Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"Like how \"pull\" is \"fetch\" + \"merge\", I think it would be useful to have a \n\"commit\" + \"push\". I have the general feeling that this is more like what \nusers of other version control systems expect to have happen, and it's \neasy, when working on a non-network-accessible workstation, to commit and \nforget to do anything with the commit before leaving. So I'm considering a \n\"git-publish\" which is the trivial \"git commit $* && git push\".\n\nMy suspicion is that most people who run commit directly and have a \ndefault push location tend to want to push after every commit (or, at \nleast, be fine with that, and really want to have pushed after the last of \na batch). (Of course, there are plenty of users who don't want to push so \noften, but I bet they either mostly generate commits with git apply, git \nam, or such, or they don't have a push line and publicize their changes \nwith format-patch.)\n\nActually, I'm also curious as to how other people generate the series of \ncommits for a patch series, when they've actually got a working directory \nthat contains the end result. I doubt that people actually do their \nmodifications in patch order, committing each time, without writing \nand testing the end result.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"25187","messageId":"7vzme8lg28.fsf@assigned-by-dhcp.cox.net","threadId":"5228","inReplyTo":"Pine.LNX.4.64.0608131158500.9789@iabervon.org","subject":"Re: [RFC] git-publish","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-13T17:07:59Z","receivedAt":"2006-08-13T17:07:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> My suspicion is that most people who run commit directly and have a \n> default push location tend to want to push after every commit (or, at \n> least, be fine with that, and really want to have pushed after the last of \n> a batch).\n\nI for one would be horrified ;-) but that's probably just me.\n\nSome people seem to like 'commit -o' (which now is the default),\nand worse yet (from 'discipline' point of view) there are even\npeople who want to be able to edit the patch preview in place in\n'commit -v' buffer. Commits by these people are by definition\nnot even compile tested in isolation. I suspect those are the\nvery people who would want to push immediately after they make\ncommits.\n\nChilly.\n\nDon't get me wrong -- I am not opposed to \"git-commit && git-push\".\nIt may be handy if you are pushing into some alternate (backup)\nlocation. But \"publish\" (implying \"public consumption\") is too\nmuch for my taste, and I am hesitant to endorse such a workflow.\n"},{"id":"25189","messageId":"Pine.LNX.4.63.0608132017090.10541@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5228","inReplyTo":"Pine.LNX.4.64.0608131158500.9789@iabervon.org","subject":"Re: [RFC] git-publish","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-08-13T18:20:43Z","receivedAt":"2006-08-13T18:20:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 13 Aug 2006, Daniel Barkalow wrote:\n\n> Like how \"pull\" is \"fetch\" + \"merge\", I think it would be useful to have \n> a \"commit\" + \"push\".\n\nI found myself the other day, looking for files I committed on a box which \nwas 280 kilometer away, where I forgot to push. So I understand your \nfeeling.\n\nHowever, adding to Junio's arguments, I find it saner to keep them \nseparated: you should commit _often_. Way more often than you would need \nto push. There are many reasons, why small patches are more beautiful than \nbig ones, and git actually encourages you to make small patches.\n\nI'd rather have a command which tells me if I have commits after the last \ntime I pushed.\n\nCiao,\nDscho\n"},{"id":"25190","messageId":"20060813191346.GA21487@mars.ravnborg.org","threadId":"5228","inReplyTo":"Pine.LNX.4.64.0608131158500.9789@iabervon.org","subject":"Re: [RFC] git-publish","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2006-08-13T19:13:46Z","receivedAt":"2006-08-13T19:13:46Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"On Sun, Aug 13, 2006 at 12:34:49PM -0400, Daniel Barkalow wrote:\n> \n> Actually, I'm also curious as to how other people generate the series of \n> commits for a patch series, when they've actually got a working directory \n> that contains the end result. I doubt that people actually do their \n> modifications in patch order, committing each time, without writing \n> and testing the end result.\nhack hack\ngit commit -a\ntest <= ohh crap a trivial bug\ngit format-patch HEAD^..HEAD\ngit reset HEAD^ --hard\npatch -p1 0001*\nhack hack\ngit commit -a <= reading in old changelog from 0001*\n\nThe above is easier if you know git I expect.\nIf I find bugs in older patches I just go back more steps.\n\nI often (twice or more for each kernel release) throw away my kbuild.git\ntree and start all over.\nThat gives me a recent kernel to work with and still providing Linux\nwith a linar history.\n\nI have considered stgit - but have not tried it. The above works pretty\nwell for me (my fingers and my logic i accused to it now) so the\nincentive to shift is small.\n\nBut important note is that publishing is something I defer until some\nlimited test has been done. And when I omit that I have always ended u\npushing some crappy stuff that needs to be dealt with.\n\n\tSam\n"},{"id":"25191","messageId":"20060813194256.GB5205@c165.ib.student.liu.se","threadId":"5228","inReplyTo":"20060813191346.GA21487@mars.ravnborg.org","subject":"Re: [RFC] git-publish","fromName":"Fredrik Kuivinen","fromEmail":"freku045@student.liu.se","sentAt":"2006-08-13T19:42:56Z","receivedAt":"2006-08-13T19:42:56Z","isPatch":false,"sender":{"key":"frekui@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13770967?v=4"},"body":"On Sun, Aug 13, 2006 at 09:13:46PM +0200, Sam Ravnborg wrote:\n> On Sun, Aug 13, 2006 at 12:34:49PM -0400, Daniel Barkalow wrote:\n> > \n> > Actually, I'm also curious as to how other people generate the series of \n> > commits for a patch series, when they've actually got a working directory \n> > that contains the end result. I doubt that people actually do their \n> > modifications in patch order, committing each time, without writing \n> > and testing the end result.\n> hack hack\n> git commit -a\n> test <= ohh crap a trivial bug\n> git format-patch HEAD^..HEAD\n> git reset HEAD^ --hard\n> patch -p1 0001*\n> hack hack\n> git commit -a <= reading in old changelog from 0001*\n> \n> The above is easier if you know git I expect.\n> If I find bugs in older patches I just go back more steps.\n\nIf it is the top commit you want to change it is possible to do so\nwith the '--amend' option to git commit. Instead of the sequence of\ncommands above you can just do:\n\n hack hack\n git commit -a\n test <= trivial bug\n hack hack\n git commit -a --amend\n\nIt wont work if you find bugs in older patches though.\n\n> \n> I often (twice or more for each kernel release) throw away my kbuild.git\n> tree and start all over.\n> That gives me a recent kernel to work with and still providing Linux\n> with a linar history.\n> \n> I have considered stgit - but have not tried it. The above works pretty\n> well for me (my fingers and my logic i accused to it now) so the\n> incentive to shift is small.\n\nI really like stgit. IMHO it is much easier to use stgit when preparing\na patch series compared to git itself. Maybe it is because I never got\nused to the sequence of commands you described above.\n\n\n- Fredrik\n"},{"id":"25193","messageId":"7vmza8l8f1.fsf@assigned-by-dhcp.cox.net","threadId":"5228","inReplyTo":"Pine.LNX.4.63.0608132017090.10541@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] git-publish","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-13T19:53:06Z","receivedAt":"2006-08-13T19:53:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> I'd rather have a command which tells me if I have commits after the last \n> time I pushed.\n\nYes.\n\nHowever, I have not felt the need for \"a command\". In my\nworkflow, I use tracking branches for the push destination.\n\nBefore I rewind / rebase / clean-up, I fetch from my usual push\ndestination with these lines:\n\n\tURL: kernel.org:/pub/scm/git/git.git/\n Pull: master:refs/tags/ko-master\n Pull: next:refs/tags/ko-next\n Pull: +pu:refs/tags/ko-pu\n Pull: maint:refs/tags/ko-maint\n\nand have a script to do this (Meta/KO -- found in \"todo\" branch):\n\n\t#!/bin/sh\n\tgit fetch ko\n for i in master next pu maint\n do\n \tgit show-branch $i ko-$i\n done\n\nI primarily use this to make sure I do not rewind beyond what\nare already pushed out, but I also can use it to see what's\noutstanding to be pushed.\n"},{"id":"25194","messageId":"Pine.LNX.4.64.0608131536590.9789@iabervon.org","threadId":"5228","inReplyTo":"20060813191346.GA21487@mars.ravnborg.org","subject":"Re: [RFC] git-publish","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-08-13T20:11:32Z","receivedAt":"2006-08-13T20:11:32Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 13 Aug 2006, Sam Ravnborg wrote:\n\n> But important note is that publishing is something I defer until some\n> limited test has been done. And when I omit that I have always ended u\n> pushing some crappy stuff that needs to be dealt with.\n\nI also test before publishing. But I test before committing, too, because \nI never get anything right (or even logically complete) the first time. My \ncycle is edit/build/test, and if the test is successful, I commit and \npush. Do other people really commit after editing each time? Or are they \ntesting before the commit, and doing more extensive testing after the \ncommit before the push?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"25196","messageId":"20060813204118.GA21956@mars.ravnborg.org","threadId":"5228","inReplyTo":"Pine.LNX.4.64.0608131536590.9789@iabervon.org","subject":"Re: [RFC] git-publish","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2006-08-13T20:41:18Z","receivedAt":"2006-08-13T20:41:18Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"On Sun, Aug 13, 2006 at 04:11:32PM -0400, Daniel Barkalow wrote:\n> On Sun, 13 Aug 2006, Sam Ravnborg wrote:\n> \n> > But important note is that publishing is something I defer until some\n> > limited test has been done. And when I omit that I have always ended u\n> > pushing some crappy stuff that needs to be dealt with.\n> \n> I also test before publishing. But I test before committing, too, because \n> I never get anything right (or even logically complete) the first time. My \n> cycle is edit/build/test, and if the test is successful, I commit and \n> push.\n\nIt happens that I discover bugs while working on next issue.\nAnd sometime I get my light moments after commiting a patch.\n\nObviously I test before commit.\n\n\tSam\n"},{"id":"25200","messageId":"46a038f90608131653k1a2d0480x411be91bdc3f60ca@mail.gmail.com","threadId":"5228","inReplyTo":"Pine.LNX.4.64.0608131158500.9789@iabervon.org","subject":"Re: [RFC] git-publish","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-08-13T23:53:07Z","receivedAt":"2006-08-13T23:53:07Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 8/14/06, Daniel Barkalow wrote:\n> Like how \"pull\" is \"fetch\" + \"merge\",\n\nSlightly OT... I thought git-publish host:/path/to/repo.git would be\nsomething to automate the initial \"publishing\" actions, which for me\nare:\n\n ssh host 'mkdir path/to/repo.git'\n ssh host 'GIT_DIR=path/to/repo.git git init-db'\n ssh host 'GIT_DIR=path/to/repo.git git repo-config someopts'\n git-push git+ssh://host:/path/to/repo.git\n\nHmmmm. Would this be git publish-repo maybe?\n\ncheers,\n\n\n\nmartin\n"},{"id":"25207","messageId":"20060814015127.GA18667@spearce.org","threadId":"5228","inReplyTo":"Pine.LNX.4.64.0608131536590.9789@iabervon.org","subject":"Re: [RFC] git-publish","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-08-14T01:51:27Z","receivedAt":"2006-08-14T01:51:27Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Daniel Barkalow wrote:\n> On Sun, 13 Aug 2006, Sam Ravnborg wrote:\n> \n> > But important note is that publishing is something I defer until some\n> > limited test has been done. And when I omit that I have always ended u\n> > pushing some crappy stuff that needs to be dealt with.\n> \n> I also test before publishing. But I test before committing, too, because \n> I never get anything right (or even logically complete) the first time. My \n> cycle is edit/build/test, and if the test is successful, I commit and \n> push. Do other people really commit after editing each time? Or are they \n> testing before the commit, and doing more extensive testing after the \n> commit before the push?\n\nI typically edit/commit/test, with a possible commit --amend after\nthe test to fix whatever trivial bug came up during the test.\nBut usually I get the initial edit right, so I don't --amend\nthat often.\n\nWhen building a patch series for core GIT I tend to make heavy use\nof git-format-pach and git-am; e.g. I'll edit/commit/test each change,\nthen go back and do something like:\n\n\tgit format-patch -o .. next\n\tgit reset --hard next\n\tgit am ../0003-*\n\tgit am ../0001-*\n\tgit am ../0002-*\n\nor whatever to clean up my history before doing a final test and\nformat-patch for emailing. The reason I do this is I tend to to\npay attention to \"patch size\" when writing a change but I try to\nminimize the number of changed lines before submitting so the patch\nis cleaner. :-)\n\nWhen I'm not hacking on core GIT I'm typically using `git push`\nto publish my changes to a common repository. In this case I\nstill tend to commit before I test so I'd definately _not_ use a\n`git commit && git push` style of operation.\n\n\nAlthough other SCMs (e.g. SVN or CVS) would encourage you to commit\nand push to the remote immediately this is actually a pretty bad\nidea in GIT.\n\nIf the remote is ahead of you then the push would automatically fail.\nIf you are working on a team where everyone is doing `git commit &&\ngit push` then you will probably find that every other commit the\nremote is ahead of you, requiring you to pull first. But with CVS\nand SVN you usually don't run into that issue unless you touched the\nsame files, and typically in that type of workflow users only edit\n\"their\" files so conflicts like that tend not to happen very often.\n\nBut even worse this style of workflow will generate a very messy\nhistory. Almost every commit will have been done in isolation,\nwith yet another merge commit to connect it to the commit that\nbeat it into the shared repository. This is not going to look very\npretty in gitk.\n\n\nSo in my humble opinion I think this is not really a workflow style\nthat should be encouraged with GIT. But perhaps tools to show you\nwhat would happen if you pushed right now (e.g. a shortlog of the\ncommits that would upload or that must be downloaded and merged)\nwould be useful.\n\n-- \nShawn.\n"},{"id":"25208","messageId":"7virkwgimb.fsf@assigned-by-dhcp.cox.net","threadId":"5228","inReplyTo":"20060814015127.GA18667@spearce.org","subject":"Re: [RFC] git-publish","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-14T02:23:56Z","receivedAt":"2006-08-14T02:23:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Although other SCMs (e.g. SVN or CVS) would encourage you to commit\n> and push to the remote immediately this is actually a pretty bad\n> idea in GIT.\n\nWell, non-distributed SCM is totally a different story. For\nthem, committing is to propagating the change to the central\nrepository to be consumed by others.\n\nYou can use git in that way as well, but you do not have to, and\nthat is an improvement;-).\n"},{"id":"25234","messageId":"81b0412b0608140201x364ec92ifdd3bfa71baa4f4e@mail.gmail.com","threadId":"5228","inReplyTo":"20060813204118.GA21956@mars.ravnborg.org","subject":"Re: [RFC] git-publish","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-08-14T09:01:22Z","receivedAt":"2006-08-14T09:01:22Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 8/13/06, Sam Ravnborg wrote:\n> On Sun, Aug 13, 2006 at 04:11:32PM -0400, Daniel Barkalow wrote:\n> > On Sun, 13 Aug 2006, Sam Ravnborg wrote:\n> >\n> > > But important note is that publishing is something I defer until some\n> > > limited test has been done. And when I omit that I have always ended u\n> > > pushing some crappy stuff that needs to be dealt with.\n> >\n> > I also test before publishing. But I test before committing, too, because\n> > I never get anything right (or even logically complete) the first time. My\n> > cycle is edit/build/test, and if the test is successful, I commit and\n> > push.\n>\n> It happens that I discover bugs while working on next issue.\n> And sometime I get my light moments after commiting a patch.\n\nIn such a case I usually run git log or gitk to find the commit where a fix\nis best applied, git checkout -b tmp , edit/commit,\ngit checkout (if needed), git pull . tmp, find out that\nI made a typo, fix it, test, \"git checkout -m tmp\" and \"git commit\" and\nfinally merge the tmp branch or cherry-pick the changes somewhere\nsafe. Then remove the tmp branch (it's such a special branch to me).\nSometimes I clone the current repo somewhere just to create the\ntemporary branch there, work in the cloned repo, and pull fixes to test\nback in the first repo (it helps to avoid recompilations, while only\nfixed files will be updated and recompile)\n"},{"id":"25250","messageId":"20060814112544.GA13116@coredump.intra.peff.net","threadId":"5228","inReplyTo":"20060814015127.GA18667@spearce.org","subject":"Re: [RFC] git-publish","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-08-14T11:25:44Z","receivedAt":"2006-08-14T11:25:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 13, 2006 at 09:51:27PM -0400, Shawn Pearce wrote:\n\n> But even worse this style of workflow will generate a very messy\n> history. Almost every commit will have been done in isolation,\n\nI think the real reason CVS histories stay un-messy is that 'cvs commit' is\nactually more like 'git-commit && git-fetch && git-rebase origin &&\ngit-push'. That is the workflow I use for small personal repositories\nwhere I am replacing CVS with git. I always want to keep the server up\nto date so my work is accessible from multiple machines, and I almost\nnever want to branch (I generally only rebase because I forgot a push or\npull). I still don't think I'd want all of that in one command, though.\n\n> So in my humble opinion I think this is not really a workflow style\n> that should be encouraged with GIT. But perhaps tools to show you\n> what would happen if you pushed right now (e.g. a shortlog of the\n> commits that would upload or that must be downloaded and merged)\n> would be useful.\n\nLike git-log --pretty=online origin..HEAD?\n\nOne of the things I like about git is how easy it is to find out\nwhat's going on. I have a large number of small project repostories\nchecked out at any given time. I can quickly get the status of all of\nthem with this script:\n\n #!/bin/sh\n\n count_zero() {\n test `\"$@\" | wc -l` = 0\n }\n\n check_git() {\n cd $1\n count_zero git-ls-files \\\n -m -o -d --exclude-per-directory=.gitignore \\\n --directory --no-empty-directory || echo COMMIT:$1\n if test -e .git/branches/origin -o -e .git/remotes/origin; then\n git-fetch || echo FETCH:$1\n count_zero git-rev-list master..origin || echo MERGE:$1\n count_zero git-rev-list origin..master || echo PUSH:$1\n else\n echo ORIGIN:$1\n fi\n test \"`git-count-objects | cut -d' ' -f1`\" -gt 1000 && echo PACK:$1\n }\n\n for i in `find $PROJECT_ROOTS -type -d -name .git | sed 's!/.git$!!'`; do\n echo Checking $i...\n errors=\"$errors `check_git $i`\n done\n echo $errors | sed -e 's/ /\\n/g' -e 's/:/: /g'\n\nThis lets me know if I've forgotten to commit anything, if I've forgotten to\npush (or if I haven't even set up an origin yet!), or if there are new changes\nwaiting for me to merge.\n\n-Peff\n"},{"id":"27546","messageId":"20060924120634.GN20017@pasky.or.cz","threadId":"5228","inReplyTo":"46a038f90608131653k1a2d0480x411be91bdc3f60ca@mail.gmail.com","subject":"Re: [RFC] git-publish","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-24T12:06:34Z","receivedAt":"2006-09-24T12:06:34Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Aug 14, 2006 at 01:53:07AM CEST, I got a letter\nwhere Martin Langhoff said that...\n> On 8/14/06, Daniel Barkalow wrote:\n> >Like how \"pull\" is \"fetch\" + \"merge\",\n> \n> Slightly OT... I thought git-publish host:/path/to/repo.git would be\n> something to automate the initial \"publishing\" actions, which for me\n> are:\n> \n> ssh host 'mkdir path/to/repo.git'\n> ssh host 'GIT_DIR=path/to/repo.git git init-db'\n> ssh host 'GIT_DIR=path/to/repo.git git repo-config someopts'\n> git-push git+ssh://host:/path/to/repo.git\n> \n> Hmmmm. Would this be git publish-repo maybe?\n\nActually, this is a nice idea for cg-admin-setuprepo, thanks. :-) It now\naccepts a git+ssh URL just as well as a local path. (It won't work with\ngit-shell, but that's a good thing.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i