[lkml]   [2007]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: git guidance
    Al Boldi wrote:
    > Andreas Ericsson wrote:
    >> So, to get to the bottom of this, which of the following workflows is it
    >> you want git to support?
    >> ### WORKFLOW A ###
    >> edit, edit, edit
    >> edit, edit, edit
    >> edit, edit, edit
    >> Oops I made a mistake and need to hop back to "current - 12".
    >> edit, edit, edit
    >> edit, edit, edit
    >> publish everything, similar to just tarring up your workdir and sending
    >> out ### END WORKFLOW A ###
    >> ### WORKFLOW B ###
    >> edit, edit, edit
    >> ok this looks good, I want to save a checkpoint here
    >> edit, edit, edit
    >> looks good again. next checkpoint
    >> edit, edit, edit
    >> oh crap, back to checkpoint 2
    >> edit, edit, edit
    >> ooh, that's better. save a checkpoint and publish those checkpoints
    >> ### END WORKFLOW B ###
    > ### WORKFLOW C ###
    > for every save on a gitfs mounted dir, do an implied checkpoint, commit, or
    > publish (should be adjustable), on its privately created on-the-fly
    > repository.
    > ### END WORKFLOW C ###

    So you *do* want an editor's undo function, but for an entire filesystem.
    That's a handy thing to have every now and then, but it's not what git
    (or any other scm) does.

    > For example:
    > echo "// last comment on this file" >> /gitfs.mounted/file
    > should do an implied checkpoint, and make these checkpoints immediately
    > visible under some checkpoint branch of the gitfs mounted dir.
    > Note, this way the developer gets version control without even noticing, and
    > works completely transparent to any kind of application.

    One other thing that's fairly important to note is that this can never
    ever handle changesets, since each write() of each file will be a commit
    on its own. It's so far from what git does that I think you'd be better
    off just implementing it from scratch, or looking at a versioned fs, like
    Jakub suggested in his reply.

    You're also neglecting one very important aspect of what an SCM provides
    if you go down this road, namely project history. You basically have two
    choices with this "implicit save on each edit":
    * force the user to supply a commit message for each and every edit
    * ignore commit messages altogether

    Obviously, forcing a commit message each time is the only way to get some
    sort of proper history to look at after it's done, but it's also such an
    appalling nuisance that I doubt *anyone* will actually like that, and since
    changesets aren't supported, you'll have "implement xniz api, commit 1 of X"
    messages. Cumbersome, stupid, and not very useful.

    Ignoring commit messages altogether means you ignore the entire history,
    and the SCM then becomes a filesystem-wide "undo" cache. This could
    ofcourse work, but it's something akin to building a nuclear powerplant
    to power a single lightbulb.

    Andreas Ericsson
    OP5 AB
    Tel: +46 8-230225 Fax: +46 8-230231

     \ /
      Last update: 2007-12-07 13:33    [W:0.024 / U:2.372 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site