* Pitfalls in auto-fast-forwarding heads that are not checked out?
@ 2013-05-03 22:46 Martin Langhoff
2013-05-04 7:34 ` Johannes Sixt
0 siblings, 1 reply; 6+ messages in thread
From: Martin Langhoff @ 2013-05-03 22:46 UTC (permalink / raw)
To: Git Mailing List
I am building a small git wrapper around puppet, and one of the
actions it performs is auto-fastforwarding of branches without
checking them out.
In simplified code... we ensure that we are on a head called master,
and in some cases "ppg commit", will commit to master and...
## early on
# sanity-check we are on master
headname=$(git rev-parse --symbolic-full-name --revs-only HEAD)
if [ "$headname" -ne "refs/heads/headname" ]; then
echo >&2 "ERROR: can only issue --immediate commit from the
master branch!"
exit 1
fi
## then
git commit -bla blarg baz
## and then...
# ensure we can ff
head_sha1=$(git rev-parse --revs-only master)
mb=$(git merge-base $production_sha1 refs/heads/master)
if [[ "$mb" -ne "$production_sha1" ]]; then
echo >&2 "ERROR: cannot fast-forward master to production"
exit 1
fi
$GIT_EXEC_PATH/git-update-ref -m "ppg immediate commit"
refs/heads/production $head_sha1 $production_sha1 || exit 1
Are there major pitfalls in this approach? I cannot think of any, but
git has stayed away from updating my local tracking branches; so maybe
there's a reason for that...
cheers,
m
--
martin.langhoff@gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Pitfalls in auto-fast-forwarding heads that are not checked out?
2013-05-03 22:46 Pitfalls in auto-fast-forwarding heads that are not checked out? Martin Langhoff
@ 2013-05-04 7:34 ` Johannes Sixt
2013-05-04 11:35 ` Martin Langhoff
0 siblings, 1 reply; 6+ messages in thread
From: Johannes Sixt @ 2013-05-04 7:34 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
Am 04.05.2013 00:46, schrieb Martin Langhoff:
> I am building a small git wrapper around puppet, and one of the
> actions it performs is auto-fastforwarding of branches without
> checking them out.
>
> In simplified code... we ensure that we are on a head called master,
> and in some cases "ppg commit", will commit to master and...
>
> ## early on
> # sanity-check we are on master
> headname=$(git rev-parse --symbolic-full-name --revs-only HEAD)
> if [ "$headname" -ne "refs/heads/headname" ]; then
You mean "refs/heads/master" and "!=" here because -ne is numeric
comparison in a shell script.
> echo >&2 "ERROR: can only issue --immediate commit from the
> master branch!"
> exit 1
> fi
>
> ## then
> git commit -bla blarg baz
>
> ## and then...
>
> # ensure we can ff
> head_sha1=$(git rev-parse --revs-only master)
> mb=$(git merge-base $production_sha1 refs/heads/master)
> if [[ "$mb" -ne "$production_sha1" ]]; then
Your approach looks OK (but note again the incorrect "-ne").
Since git 1.8.0 you can express this check as
if git merge-base --is-ancestor $production_sha1 refs/heads/master
> echo >&2 "ERROR: cannot fast-forward master to production"
echo >&2 "ERROR: cannot fast-forward production to master"
> exit 1
> fi
> $GIT_EXEC_PATH/git-update-ref -m "ppg immediate commit"
> refs/heads/production $head_sha1 $production_sha1 || exit 1
>
> Are there major pitfalls in this approach?
I don't think there are.
> I cannot think of any, but
> git has stayed away from updating my local tracking branches; so maybe
> there's a reason for that...
I don't understand what you are saying here. What is "that"?
-- Hannes
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Pitfalls in auto-fast-forwarding heads that are not checked out?
2013-05-04 7:34 ` Johannes Sixt
@ 2013-05-04 11:35 ` Martin Langhoff
2013-05-04 13:17 ` John Szakmeister
2013-05-04 18:51 ` Jonathan Nieder
0 siblings, 2 replies; 6+ messages in thread
From: Martin Langhoff @ 2013-05-04 11:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
On Sat, May 4, 2013 at 3:34 AM, Johannes Sixt <j6t@kdbg.org> wrote:
> You mean "refs/heads/master" and "!=" here because -ne is numeric
> comparison in a shell script.
thanks! Yeah, I fixed those up late last night :-)
> Since git 1.8.0 you can express this check as
>
> if git merge-base --is-ancestor $production_sha1 refs/heads/master
Ah, that's great! Unfortunate it's not there in earlier / more widely
used releases of git.
>> Are there major pitfalls in this approach?
>
> I don't think there are.
Thanks...
>> I cannot think of any, but
>> git has stayed away from updating my local tracking branches; so maybe
>> there's a reason for that...
>
> I don't understand what you are saying here. What is "that"?
When I do git pull, git is careful to only update the branch I have
checked out (if appropriate). It leaves any other branches that track
branches on the remote that has just been fetched untouched. I always
thought that at some point git pull would learn to evaluate those
branches and auto-merge them if the merge is a ff.
I would find that a natural bit of automation in git pull. Of course
it would mean a change of semantics, existing scripts could be
affected.
cheers,
m
--
martin.langhoff@gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Pitfalls in auto-fast-forwarding heads that are not checked out?
2013-05-04 11:35 ` Martin Langhoff
@ 2013-05-04 13:17 ` John Szakmeister
2013-05-04 18:51 ` Jonathan Nieder
1 sibling, 0 replies; 6+ messages in thread
From: John Szakmeister @ 2013-05-04 13:17 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Johannes Sixt, Git Mailing List
On Sat, May 4, 2013 at 7:35 AM, Martin Langhoff
<martin.langhoff@gmail.com> wrote:
[snip]
> When I do git pull, git is careful to only update the branch I have
> checked out (if appropriate). It leaves any other branches that track
> branches on the remote that has just been fetched untouched. I always
> thought that at some point git pull would learn to evaluate those
> branches and auto-merge them if the merge is a ff.
>
> I would find that a natural bit of automation in git pull. Of course
> it would mean a change of semantics, existing scripts could be
> affected.
I agree. I've been using this script for quite a while now:
<https://github.com/jszakmeister/etc/blob/master/git-addons/git-ffwd>
I've been pretty happy with it. It's not of my own design, I picked
up from StackOverflow:
<http://stackoverflow.com/a/9076361/683080>
And made a couple of minor tweaks to cope with my configuration (I
have merge setup to not fast-forward merge by default).
-John
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Pitfalls in auto-fast-forwarding heads that are not checked out?
2013-05-04 11:35 ` Martin Langhoff
2013-05-04 13:17 ` John Szakmeister
@ 2013-05-04 18:51 ` Jonathan Nieder
2013-05-07 14:27 ` Martin Langhoff
1 sibling, 1 reply; 6+ messages in thread
From: Jonathan Nieder @ 2013-05-04 18:51 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Johannes Sixt, Git Mailing List
Martin Langhoff wrote:
> On Sat, May 4, 2013 at 3:34 AM, Johannes Sixt <j6t@kdbg.org> wrote:
>> Since git 1.8.0 you can express this check as
>>
>> if git merge-base --is-ancestor $production_sha1 refs/heads/master
>
> Ah, that's great! Unfortunate it's not there in earlier / more widely
> used releases of git.
Another trick is to use "git push":
git push . $production_sha1:refs/heads/master
This advances the "master" branch if
(1) it is not the current branch, and
(2) that update is a fast-forward
It can be convenient sometimes.
Hope that helps,
Jonathan
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-05-07 14:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-05-03 22:46 Pitfalls in auto-fast-forwarding heads that are not checked out? Martin Langhoff
2013-05-04 7:34 ` Johannes Sixt
2013-05-04 11:35 ` Martin Langhoff
2013-05-04 13:17 ` John Szakmeister
2013-05-04 18:51 ` Jonathan Nieder
2013-05-07 14:27 ` Martin Langhoff
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).