[Pkg-phototools-devel] [Pkg-phototools-commits] libpano: branch "libpano13/unstable" updated.

[Cyril Brulebois]

On 31/12/2007, Cyril Brulebois wrote:
> ==== libpano12 & libpano13 packaging ====
> 
> The branch "libpano13/unstable" has been updated
>   discards  8d9cc8285efe4ebf5ae82e6ca4b2915998c158d9 (commit)
>       from  8d9cc8285efe4ebf5ae82e6ca4b2915998c158d9 (commit)
> 
> Those revisions listed above that are new to this repository have
> not appeared on any other notification email; so we list those
> revisions in full, below.
> 
> - Log -----------------------------------------------------------------
> -----------------------------------------------------------------------
> 
> Summary of changes:
>  debian/TODO      |    2 --
>  debian/changelog |    6 ------
>  debian/control   |    2 +-
>  debian/rules     |    4 ----
>  4 files changed, 1 insertions(+), 13 deletions(-)

OK, it was just a test, and I'm summarizing here in case someone wonders
what's happening in this case.

When pushing to public repositories, you're supposed to only use
fast-forwarding, and not to erase (or rewrite) some commits.

Usually, you *could* do that anyway, using the “-f” option of git-push.
Typical usage: you committed something wrong, use “git-reset --hard
HEAD^” on it, and then “git-push -f origin $branch”. That should be
coordinated between participants anyway, since that'll probably break
everyone's copy.

Why I didn't do it the git-reset way: I didn't configure ~/.gitconfig
on the box I pushed from, and then wanted to figure out whether such a
non-fast-forwarding push was possible (so as to fix my mail address).
And since this commit wasn't advertised on this list (due to the buggy
mail address), I felt that it was kind of good occasion to try such
non-elegant stuff.

The answer is: since the git repository has been created with the
“--shared” option, the config file contains:
| [receive]
|     denyNonFastforwards = true

So, if you really have a reason to git-push non-fast-forward stuff, just
use -f as you would do normally, but after having *temporarily* changed
this option to “false”.

Maybe we should require (as in: write it down in the guidelines) to
advertise on the list when such a non-fast-forward is needed?

Cheers,

-- 
Cyril Brulebois
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-phototools-devel/attachments/20071231/322a739f/attachment.pgp