* discussion: an option to fail git fetch if a pulled branch tip is not a fast forward of the existing remote tip?
@ 2010-01-13 11:54 Jon Seymour
2010-01-13 12:59 ` Thomas Rast
0 siblings, 1 reply; 3+ messages in thread
From: Jon Seymour @ 2010-01-13 11:54 UTC (permalink / raw)
To: Git Mailing List
I spent a little while this afternoon debugging an issue where an
upstream publisher had backtracked and published a branch tip which
was not a descendant of a previously published (and fetched) branch
tip. The net result was that the backtracked changes were preserved in
the downstream branch once the 2nd tip was pulled.
Now clearly the upstream developer should not have backtracked. That
said, it would have been nice if I could have easily configured my
porcelain to detect the backtracking condition. An option on git fetch
that implemented something similar to the git push check would have
made this easy to achieve.
Has any consideration been given to such an option? Is there a
well-known alternative pattern for detecting this case?
jon.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: discussion: an option to fail git fetch if a pulled branch tip is not a fast forward of the existing remote tip?
2010-01-13 11:54 discussion: an option to fail git fetch if a pulled branch tip is not a fast forward of the existing remote tip? Jon Seymour
@ 2010-01-13 12:59 ` Thomas Rast
2010-01-13 17:14 ` Jon Seymour
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Rast @ 2010-01-13 12:59 UTC (permalink / raw)
To: Jon Seymour; +Cc: Git Mailing List
Jon Seymour wrote:
[discussion of a case of branch rewriting, called "backtracking" here]
> Now clearly the upstream developer should not have backtracked. That
> said, it would have been nice if I could have easily configured my
> porcelain to detect the backtracking condition. An option on git fetch
> that implemented something similar to the git push check would have
> made this easy to achieve.
This is an instance of a non-fast-foward update, which is indicated by
the little "+" in git-fetch's output. E.g., fetching git.git a moment
ago gave me
>From git://git.kernel.org/pub/scm/git/git
fbb9971..8efa5f6 maint -> origin/maint
c0eb604..054d2fa master -> origin/master
e295b7f..e84eab0 next -> origin/next
+ 10659b7...6a048fc pu -> origin/pu (forced update)
which means that the 'pu' branch was a non-fast-forward update.
If you do not want to rely on checking the results manually, you can
edit the remote configuration. Normally, it will look like
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/origin/*
Note the "+" in the 'fetch' line, which means "allow non-fast-forward
updates". Removing the + (leaving the rest intact) results in
>From git://git.kernel.org/pub/scm/git/git
! [rejected] pu -> origin/pu (non-fast-forward)
You can then manually add lines _with_ the "+" for branches where you
do want to allow non-ff updates, e.g., for git.git I might say
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/pu:refs/remotes/origin/pu
fetch = refs/heads/*:refs/remotes/origin/*
since only 'pu' will be rewritten regularly. ('next' gets the
occasional treatment too, so that config would not be very
futureproof.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: discussion: an option to fail git fetch if a pulled branch tip is not a fast forward of the existing remote tip?
2010-01-13 12:59 ` Thomas Rast
@ 2010-01-13 17:14 ` Jon Seymour
0 siblings, 0 replies; 3+ messages in thread
From: Jon Seymour @ 2010-01-13 17:14 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git Mailing List
Thomas,
Ah - thanks for your very helpful response!
jon.
On 13/01/2010, at 23:59, Thomas Rast <trast@student.ethz.ch> wrote:
> Jon Seymour wrote:
> [discussion of a case of branch rewriting, called "backtracking" here]
>> Now clearly the upstream developer should not have backtracked. That
>> said, it would have been nice if I could have easily configured my
>> porcelain to detect the backtracking condition. An option on git
>> fetch
>> that implemented something similar to the git push check would have
>> made this easy to achieve.
>
> This is an instance of a non-fast-foward update, which is indicated by
> the little "+" in git-fetch's output. E.g., fetching git.git a moment
> ago gave me
>
> From git://git.kernel.org/pub/scm/git/git
> fbb9971..8efa5f6 maint -> origin/maint
> c0eb604..054d2fa master -> origin/master
> e295b7f..e84eab0 next -> origin/next
> + 10659b7...6a048fc pu -> origin/pu (forced update)
>
> which means that the 'pu' branch was a non-fast-forward update.
>
> If you do not want to rely on checking the results manually, you can
> edit the remote configuration. Normally, it will look like
>
> [remote "origin"]
> url = git://git.kernel.org/pub/scm/git/git.git
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> Note the "+" in the 'fetch' line, which means "allow non-fast-forward
> updates". Removing the + (leaving the rest intact) results in
>
> From git://git.kernel.org/pub/scm/git/git
> ! [rejected] pu -> origin/pu (non-fast-forward)
>
> You can then manually add lines _with_ the "+" for branches where you
> do want to allow non-ff updates, e.g., for git.git I might say
>
> [remote "origin"]
> url = git://git.kernel.org/pub/scm/git/git.git
> fetch = +refs/heads/pu:refs/remotes/origin/pu
> fetch = refs/heads/*:refs/remotes/origin/*
>
> since only 'pu' will be rewritten regularly. ('next' gets the
> occasional treatment too, so that config would not be very
> futureproof.)
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-01-13 20:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-13 11:54 discussion: an option to fail git fetch if a pulled branch tip is not a fast forward of the existing remote tip? Jon Seymour
2010-01-13 12:59 ` Thomas Rast
2010-01-13 17:14 ` Jon Seymour
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).