[Dune] [#981] git support for dunecontrol

Dune flyspray at dune-project.org
Mon Nov 21 15:06:49 CET 2011


The following task has a new comment added:

FS#981 - git support for dunecontrol
User who did this - Jö Fahlke (joe)

FS#429 was a trivial fix. FS#479 was (by Sven):

The support for git-svn in dunecontrol only works for one special use of git
and breaks things in many other use cases. These cases include one-shot
checkouts using git-svn, not being on the master branch and having modified
files that are different in the current branch, being in the middle of an
interactive rebase and many more.

Moreover, local changes in .git/info/exclude are overwritten (without any
backup copy!) and replaced by some arbitrary default.

I think the git-svn support should be dropped. It would be a lot of work to
fix it, and hardly anyone would use it. In my local checkout, I removed the
support a long time ago because it screwed up "dunecontrol update" over and
over again.

These concerns were for a different implementation, but lets see how valid
they are with the proposed patch.

 1. One-shot checkouts: A one-shot checkout, I believe, is where you convert a
    subversion-repository to a git repository, and subsequently make the
    git-repository authorative, either as a fork or by replacing the
    subversion repository.  The problem here is that a one-shot checkout
    differs only in purpose from any other git-svn repository.  On dunecontrol
    update it would try to download changes from svn.  In the case of a fork,
    it would then try to rebase the "local changes" onto the "upstream
    changes", which (failing or not) is not what is desired.  This is
    undesired, but in git this change to the repository can be undone.  In
    other cases, the download would either download nothing, or would fail
    because the upstream svn repository no longer exists.  In any case, no
    great harm is done, but having modules in such repositories would prevent
    the use of "dunecontrol update" completely.

 2. Being on a different branch than master: If the branch is a svn branch as
    well, the patch should work flawlessly.  If it isn't the branch is rebased
    onto the current head of the svn branch (or trunk) it was branched of
    from.  This may or may not be what you want.

 3. Modified files: You're not supposed to rebase with modified and uncommited
    files.  If you do, git will error out.  This is actually reasonable
    behaviour, so I see no problem here.

 4. Middle of an interactive rebase: This is another repository state where
    you shouldn't try to update.  I'm not actually sure what git will do if
    you try, but I suppose it will error out because you're attemping a rebase
    while another rebase is going on.

 5. Local changes in .git/info/exclude: The current patch doesn't try to deal
    with excludes/ignores, so this isn't a problem.

To remedy the remaining problems, we can introduce a git config option, which
can be set per-repository, like

[ dune ]
update = false # or git, or svn

This can be used to either disable updating on "dunecontrol update", or to
force the plain git or git-svn update methods (instead of autodetecting them).
This way you can force one-shot checkout to have no upstream or to even have a
git upstream.  If you create a branch that you don't want to update from svn,
you can (temporarily) mark your repository not to be updated.

We could even introduce a per-branch option (dune-update) so people don't have
to edit their git-options each time they switch branches.  But I suppose that
would be the another iteration.


More information can be found at the following URL:

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

More information about the Dune mailing list