Re: [PATCH v3 15/15] rebase: change the default backend from "am" to "merge"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Elijah Newren wrote:

>                                          Then omit calling the
> post-commit hook and it behaves the same as the am backend and no one
> in the world notices because no one in the world uses or cares about
> that hook except a few people at Google who happen to be used to the
> am-backend

Just responding to this part: I know this was a bit of thinking out
loud, but the "just a few people at Google" bit is counter-productive.
The search Emily ran
<https://github.com/search?l=&q=filename%3A%2Apost-commit%2A&type=Code>
shows that it's fairly common to use a post-commit hook for
deployment, with scripts like

	#!/bin/bash
	unset GIT_INDEX_FILE
	git --work-tree=/var/www/html --git-dir=/home/daniel/proj/.git checkout -f

or

	#!/bin/bash
	# Sync gh-pages branch with master
	#########################################
	git checkout gh-pages
	git rm -rf -q .
	git checkout master -- .
	git add .
	git commit -am "Syncing gh-pages with master"
	git checkout master

And I'm not saying that selfishly --- obviously, from a selfish
perspective, what you're proposing would change behavior the least and
I'd end up with happy users. :)  I'm just trying to help with updating
the list's collective model of user behavior.

(Actually, I want to remove jiri's post-commit hook --- so it is only
the example that revealed this behavior change and is not my
motivation for continuing to chime in in this thread.)

The deployment examples above seem like examples where the user would
want the script to run on "git am" (and on "git merge --ff-only", for
that matter) but not on the intermediate commits in "git rebase",
since when rebasing a multi-commit series, deploying earlier rebased
commits would cause the deployment to lose the benefit of later fixes.

[...]
> Ooh, that sounds interesting.  Do you have any more details?  My
> simple testing here shows that we exit with status 1, so we shouldn't
> have that problem unless perhaps there was something else in next
> (ra/rebase-i-more-options??) or some other special conditions that was
> causing it.

I can set aside some more time to investigate that one early next
week.

Thanks for the quick answers --- it's been very helpful.

Sincerely,
Jonathan



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux