Christian Engwer wrote:

> In theory it might be nice to follow both, but an "svn dcommit" will
> implicitly do a rebase which in turn might lead to problems with the
> git upstream repository, at least if fast-forward is required, which
> is the default.

Got it.  You're looking for a safety that would prevent rebasing
history that has already been made public in a remote git repo, at
least in the case that this rebasing happens as a side-effect of "git
svn dcommit".

By contrast, I really want to be able to do the following:

        git checkout -b tmp my-git-remote/topic
        git svn dcommit

to push changes I worked on on another machine concerning "topic" to
the svn repo, and I don't mind that I need to force a non-fast-forward
push to make the result available at my remote git repo afterwards.
(Well, I do mind, because dcommit rewriting history at all is
annoying, but I understand why the current design requires it and I
can live with it.)

When different workflows require git to act in different ways, how is
it possible to make git pleasant to use for both types of person?
Make it configurable.

A pre-rebase hook (see githooks(5)) would not be enough to satisfy
your request because in the typical case "git svn dcommit" rewrites
history without ever invoking "git rebase":

        if (@diff) {
 ...
        } else {
                print "No changes between current HEAD and ",
                        $gs->refname,
                        "\nResetting to the latest ",
                        $gs->refname, "\n";
                @finish = qw/reset --mixed/;
        }

A possible conclusion is that git-svn desperately needs a pre-dcommit
hook that carries out an arbitrary site-specific policy about when a
dcommit is allowed and not allowed.  Such a hook would be useful for
other purposes, too, like flagging violations of coding standards.

Once such a hook is in place, it would be easier to talk about what
the default pre-dcommit hook should do.

Does that sound right?

Thanks for some useful clarifications.

Sincerely,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to