[RFC] git-publish

[RFC] git-publish

[Daniel Barkalow]

Like how "pull" is "fetch" + "merge", I think it would be useful to have a 
"commit" + "push". I have the general feeling that this is more like what 
users of other version control systems expect to have happen, and it's 
easy, when working on a non-network-accessible workstation, to commit and 
forget to do anything with the commit before leaving. So I'm considering a 
"git-publish" which is the trivial "git commit $* && git push".

My suspicion is that most people who run commit directly and have a 
default push location tend to want to push after every commit (or, at 
least, be fine with that, and really want to have pushed after the last of 
a batch). (Of course, there are plenty of users who don't want to push so 
often, but I bet they either mostly generate commits with git apply, git 
am, or such, or they don't have a push line and publicize their changes 
with format-patch.)

Actually, I'm also curious as to how other people generate the series of 
commits for a patch series, when they've actually got a working directory 
that contains the end result. I doubt that people actually do their 
modifications in patch order, committing each time, without writing 
and testing the end result.

	-Daniel
*This .sig left intentionally blank*

Re: [RFC] git-publish

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> My suspicion is that most people who run commit directly and have a 
> default push location tend to want to push after every commit (or, at 
> least, be fine with that, and really want to have pushed after the last of 
> a batch).

I for one would be horrified ;-) but that's probably just me.

Some people seem to like 'commit -o' (which now is the default),
and worse yet (from 'discipline' point of view) there are even
people who want to be able to edit the patch preview in place in
'commit -v' buffer.  Commits by these people are by definition
not even compile tested in isolation.  I suspect those are the
very people who would want to push immediately after they make
commits.

Chilly.

Don't get me wrong -- I am not opposed to "git-commit && git-push".
It may be handy if you are pushing into some alternate (backup)
location.  But "publish" (implying "public consumption") is too
much for my taste, and I am hesitant to endorse such a workflow.

Re: [RFC] git-publish

[Johannes Schindelin]

Hi,

On Sun, 13 Aug 2006, Daniel Barkalow wrote:

> Like how "pull" is "fetch" + "merge", I think it would be useful to have 
> a "commit" + "push".

I found myself the other day, looking for files I committed on a box which 
was 280 kilometer away, where I forgot to push. So I understand your 
feeling.

However, adding to Junio's arguments, I find it saner to keep them 
separated: you should commit _often_. Way more often than you would need 
to push. There are many reasons, why small patches are more beautiful than 
big ones, and git actually encourages you to make small patches.

I'd rather have a command which tells me if I have commits after the last 
time I pushed.

Ciao,
Dscho

Re: [RFC] git-publish

[Sam Ravnborg]

On Sun, Aug 13, 2006 at 12:34:49PM -0400, Daniel Barkalow wrote:
> 
> Actually, I'm also curious as to how other people generate the series of 
> commits for a patch series, when they've actually got a working directory 
> that contains the end result. I doubt that people actually do their 
> modifications in patch order, committing each time, without writing 
> and testing the end result.
hack hack
git commit -a
test <= ohh crap a trivial bug
git format-patch HEAD^..HEAD
git reset HEAD^ --hard
patch -p1 0001*
hack hack
git commit -a <= reading in old changelog from 0001*

The above is easier if you know git I expect.
If I find bugs in older patches I just go back more steps.

I often (twice or more for each kernel release) throw away my kbuild.git
tree and start all over.
That gives me a recent kernel to work with and still providing Linux
with a linar history.

I have considered stgit - but have not tried it. The above works pretty
well for me (my fingers and my logic i accused to it now) so the
incentive to shift is small.

But important note is that publishing is something I defer until some
limited test has been done. And when I omit that I have always ended u
pushing some crappy stuff that needs to be dealt with.

	Sam

Re: [RFC] git-publish

[Fredrik Kuivinen]

On Sun, Aug 13, 2006 at 09:13:46PM +0200, Sam Ravnborg wrote:
> On Sun, Aug 13, 2006 at 12:34:49PM -0400, Daniel Barkalow wrote:
> > 
> > Actually, I'm also curious as to how other people generate the series of 
> > commits for a patch series, when they've actually got a working directory 
> > that contains the end result. I doubt that people actually do their 
> > modifications in patch order, committing each time, without writing 
> > and testing the end result.
> hack hack
> git commit -a
> test <= ohh crap a trivial bug
> git format-patch HEAD^..HEAD
> git reset HEAD^ --hard
> patch -p1 0001*
> hack hack
> git commit -a <= reading in old changelog from 0001*
> 
> The above is easier if you know git I expect.
> If I find bugs in older patches I just go back more steps.

If it is the top commit you want to change it is possible to do so
with the '--amend' option to git commit. Instead of the sequence of
commands above you can just do:

    hack hack
    git commit -a
    test <= trivial bug
    hack hack
    git commit -a --amend

It wont work if you find bugs in older patches though.

> 
> I often (twice or more for each kernel release) throw away my kbuild.git
> tree and start all over.
> That gives me a recent kernel to work with and still providing Linux
> with a linar history.
> 
> I have considered stgit - but have not tried it. The above works pretty
> well for me (my fingers and my logic i accused to it now) so the
> incentive to shift is small.

I really like stgit. IMHO it is much easier to use stgit when preparing
a patch series compared to git itself. Maybe it is because I never got
used to the sequence of commands you described above.


- Fredrik

Re: [RFC] git-publish

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I'd rather have a command which tells me if I have commits after the last 
> time I pushed.

Yes.

However, I have not felt the need for "a command".  In my
workflow, I use tracking branches for the push destination.

Before I rewind / rebase / clean-up, I fetch from my usual push
destination with these lines:

	URL: kernel.org:/pub/scm/git/git.git/
        Pull: master:refs/tags/ko-master
        Pull: next:refs/tags/ko-next
        Pull: +pu:refs/tags/ko-pu
        Pull: maint:refs/tags/ko-maint

and have a script to do this (Meta/KO -- found in "todo" branch):

	#!/bin/sh
	git fetch ko
        for i in master next pu maint
        do
        	git show-branch $i ko-$i
        done

I primarily use this to make sure I do not rewind beyond what
are already pushed out, but I also can use it to see what's
outstanding to be pushed.

Re: [RFC] git-publish

[Daniel Barkalow]

On Sun, 13 Aug 2006, Sam Ravnborg wrote:

> But important note is that publishing is something I defer until some
> limited test has been done. And when I omit that I have always ended u
> pushing some crappy stuff that needs to be dealt with.

I also test before publishing. But I test before committing, too, because 
I never get anything right (or even logically complete) the first time. My 
cycle is edit/build/test, and if the test is successful, I commit and 
push. Do other people really commit after editing each time? Or are they 
testing before the commit, and doing more extensive testing after the 
commit before the push?

	-Daniel
*This .sig left intentionally blank*

Re: [RFC] git-publish

[Sam Ravnborg]

On Sun, Aug 13, 2006 at 04:11:32PM -0400, Daniel Barkalow wrote:
> On Sun, 13 Aug 2006, Sam Ravnborg wrote:
> 
> > But important note is that publishing is something I defer until some
> > limited test has been done. And when I omit that I have always ended u
> > pushing some crappy stuff that needs to be dealt with.
> 
> I also test before publishing. But I test before committing, too, because 
> I never get anything right (or even logically complete) the first time. My 
> cycle is edit/build/test, and if the test is successful, I commit and 
> push.

It happens that I discover bugs while working on next issue.
And sometime I get my light moments after commiting a patch.

Obviously I test before commit.

	Sam

Re: [RFC] git-publish

[Martin Langhoff]

On 8/14/06, Daniel Barkalow <barkalow@iabervon.org> wrote:
> Like how "pull" is "fetch" + "merge",

Slightly OT... I thought git-publish host:/path/to/repo.git would be
something to automate the initial "publishing" actions, which for me
are:

 ssh host 'mkdir path/to/repo.git'
 ssh host 'GIT_DIR=path/to/repo.git git init-db'
 ssh host 'GIT_DIR=path/to/repo.git git repo-config someopts'
 git-push git+ssh://host:/path/to/repo.git

Hmmmm. Would this be git publish-repo maybe?

cheers,



martin

Re: [RFC] git-publish

[Shawn Pearce]

Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Sun, 13 Aug 2006, Sam Ravnborg wrote:
> 
> > But important note is that publishing is something I defer until some
> > limited test has been done. And when I omit that I have always ended u
> > pushing some crappy stuff that needs to be dealt with.
> 
> I also test before publishing. But I test before committing, too, because 
> I never get anything right (or even logically complete) the first time. My 
> cycle is edit/build/test, and if the test is successful, I commit and 
> push. Do other people really commit after editing each time? Or are they 
> testing before the commit, and doing more extensive testing after the 
> commit before the push?

I typically edit/commit/test, with a possible commit --amend after
the test to fix whatever trivial bug came up during the test.
But usually I get the initial edit right, so I don't --amend
that often.

When building a patch series for core GIT I tend to make heavy use
of git-format-pach and git-am; e.g. I'll edit/commit/test each change,
then go back and do something like:

	git format-patch -o .. next
	git reset --hard next
	git am ../0003-*
	git am ../0001-*
	git am ../0002-*

or whatever to clean up my history before doing a final test and
format-patch for emailing.  The reason I do this is I tend to to
pay attention to "patch size" when writing a change but I try to
minimize the number of changed lines before submitting so the patch
is cleaner.  :-)

When I'm not hacking on core GIT I'm typically using `git push`
to publish my changes to a common repository.  In this case I
still tend to commit before I test so I'd definately _not_ use a
`git commit && git push` style of operation.


Although other SCMs (e.g. SVN or CVS) would encourage you to commit
and push to the remote immediately this is actually a pretty bad
idea in GIT.

If the remote is ahead of you then the push would automatically fail.
If you are working on a team where everyone is doing `git commit &&
git push` then you will probably find that every other commit the
remote is ahead of you, requiring you to pull first.  But with CVS
and SVN you usually don't run into that issue unless you touched the
same files, and typically in that type of workflow users only edit
"their" files so conflicts like that tend not to happen very often.

But even worse this style of workflow will generate a very messy
history.  Almost every commit will have been done in isolation,
with yet another merge commit to connect it to the commit that
beat it into the shared repository.  This is not going to look very
pretty in gitk.


So in my humble opinion I think this is not really a workflow style
that should be encouraged with GIT.  But perhaps tools to show you
what would happen if you pushed right now (e.g. a shortlog of the
commits that would upload or that must be downloaded and merged)
would be useful.

-- 
Shawn.

Re: [RFC] git-publish

[Junio C Hamano]

Shawn Pearce <spearce@spearce.org> writes:

> Although other SCMs (e.g. SVN or CVS) would encourage you to commit
> and push to the remote immediately this is actually a pretty bad
> idea in GIT.

Well, non-distributed SCM is totally a different story.  For
them, committing is to propagating the change to the central
repository to be consumed by others.

You can use git in that way as well, but you do not have to, and
that is an improvement;-).

Re: [RFC] git-publish

[Alex Riesen]

On 8/13/06, Sam Ravnborg <sam@ravnborg.org> wrote:
> On Sun, Aug 13, 2006 at 04:11:32PM -0400, Daniel Barkalow wrote:
> > On Sun, 13 Aug 2006, Sam Ravnborg wrote:
> >
> > > But important note is that publishing is something I defer until some
> > > limited test has been done. And when I omit that I have always ended u
> > > pushing some crappy stuff that needs to be dealt with.
> >
> > I also test before publishing. But I test before committing, too, because
> > I never get anything right (or even logically complete) the first time. My
> > cycle is edit/build/test, and if the test is successful, I commit and
> > push.
>
> It happens that I discover bugs while working on next issue.
> And sometime I get my light moments after commiting a patch.

In such a case I usually run git log or gitk to find the commit where a fix
is best applied, git checkout -b tmp <commit-sha1>, edit/commit,
git checkout <test-branch> (if needed), git pull . tmp, find out that
I made a typo, fix it, test, "git checkout -m tmp" and "git commit" and
finally merge the tmp branch or cherry-pick the changes somewhere
safe. Then remove the tmp branch (it's such a special branch to me).
Sometimes I clone the current repo somewhere just to create the
temporary branch there, work in the cloned repo, and pull fixes to test
back in the first repo (it helps to avoid recompilations, while only
fixed files will be updated and recompile)

Re: [RFC] git-publish

[Jeff King]

On Sun, Aug 13, 2006 at 09:51:27PM -0400, Shawn Pearce wrote:

> But even worse this style of workflow will generate a very messy
> history.  Almost every commit will have been done in isolation,

I think the real reason CVS histories stay un-messy is that 'cvs commit' is
actually more like 'git-commit && git-fetch && git-rebase origin &&
git-push'.  That is the workflow I use for small personal repositories
where I am replacing CVS with git. I always want to keep the server up
to date so my work is accessible from multiple machines, and I almost
never want to branch (I generally only rebase because I forgot a push or
pull). I still don't think I'd want all of that in one command, though.

> So in my humble opinion I think this is not really a workflow style
> that should be encouraged with GIT.  But perhaps tools to show you
> what would happen if you pushed right now (e.g. a shortlog of the
> commits that would upload or that must be downloaded and merged)
> would be useful.

Like git-log --pretty=online origin..HEAD?

One of the things I like about git is how easy it is to find out
what's going on. I have a large number of small project repostories
checked out at any given time. I can quickly get the status of all of
them with this script:

  #!/bin/sh

  count_zero() {
      test `"$@" | wc -l` = 0
  }

  check_git() {
    cd $1
    count_zero git-ls-files \
      -m -o -d --exclude-per-directory=.gitignore \
      --directory --no-empty-directory || echo COMMIT:$1
    if test -e .git/branches/origin -o -e .git/remotes/origin; then
      git-fetch || echo FETCH:$1
      count_zero git-rev-list master..origin || echo MERGE:$1
      count_zero git-rev-list origin..master || echo PUSH:$1
    else
      echo ORIGIN:$1
    fi
    test "`git-count-objects | cut -d' ' -f1`" -gt 1000 && echo PACK:$1
  }

  for i in `find $PROJECT_ROOTS -type -d -name .git | sed 's!/.git$!!'`; do
    echo Checking $i...
    errors="$errors `check_git $i`
  done
  echo $errors | sed -e 's/ /\n/g' -e 's/:/: /g'

This lets me know if I've forgotten to commit anything, if I've forgotten to
push (or if I haven't even set up an origin yet!), or if there are new changes
waiting for me to merge.

-Peff

Re: [RFC] git-publish

[Petr Baudis]

Dear diary, on Mon, Aug 14, 2006 at 01:53:07AM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 8/14/06, Daniel Barkalow <barkalow@iabervon.org> wrote:
> >Like how "pull" is "fetch" + "merge",
> 
> Slightly OT... I thought git-publish host:/path/to/repo.git would be
> something to automate the initial "publishing" actions, which for me
> are:
> 
> ssh host 'mkdir path/to/repo.git'
> ssh host 'GIT_DIR=path/to/repo.git git init-db'
> ssh host 'GIT_DIR=path/to/repo.git git repo-config someopts'
> git-push git+ssh://host:/path/to/repo.git
> 
> Hmmmm. Would this be git publish-repo maybe?

Actually, this is a nice idea for cg-admin-setuprepo, thanks. :-) It now
accepts a git+ssh URL just as well as a local path. (It won't work with
git-shell, but that's a good thing.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)