[lkml]   [2007]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: git guidance
    On 2007.12.07 13:53:11 +0300, 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 ###
    > 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.

    Ouch... That looks worse than "plain" per-file versioning. Not only do
    you per definition get "broken" commits if there's a change that affects
    two dependent files, you also get an insane amount of commits just for
    testing stuff, or fixing bugs.

    And unless you use some kind of union-fs on top (or keep ignored files
    in special unversioned area in your gitfs, which seems somewhat ugly),
    you'll probably also have to track lots of files in the working
    directory that are generated, unless you want to re-generate them after
    each reboot. And that leads to even more absolutely useless revisions.

    Just thinking of my vim .swp files (which I definitely don't want to
    loose on a crash/power outtage/pkill -9 .<ENTER> dammit) makes me scream
    because of the gazillion of commits they will produce (and no, I don't
    want them in some special out of tree directory).

    Plus, I have vim setup to _replace_ files on write, so that I can more
    easily use hard-linked copies with changing all copies at once _unless_
    I explicitly want to, meaning that I'd get full remove/add commits,
    which are absolutely useless. And trying to detect such patterns
    (rename, then write the changed file with the old name and then delete
    the renamed file) is probably not worth the trouble, because you
    coincidently might _want_ to have just these three steps recorded when
    you happen to perform them manually. And if you go for heuristics,
    you'll complain each time you get a false-positive/negative.

    That said, out of pure curiousness I came up with the attached script
    which just uses inotifywait to watch a directory and issue git commands
    on certain events. It is extremely stupid, but seems to work. And at
    least it hasn't got the drawbacks of a real gitfs regarding the need to
    have a "separate" non-versioned storage area for the working directory,
    because it simply uses the existing working directory wherever that
    might be stored. It doesn't use GIT_DIR/WORK_DIR yet, but hey, should be
    easy to add...

    Feel free to mess with that thing, hey, maybe you even like it and
    extend it to match your proposed workflow even more. I for sure won't
    use or even extend it, so you're likely on your own there.

    Side-note: Writing that script probably took less time than writing this
    email and probably less time than was wasted on this topic. Makes me
    want to use today's preferred "Code talks, b...s... walks" statement,
    but I'll refrain from that... Just because I lack the credibility to say
    that, and the script attached is quite crappy ;-)

    inotifywait -m -r --exclude ^\./\.git/.* -e close_write -e move -e create -e delete . 2>/dev/null |

    # git doesn't care about directories
    if [ -d "$FILE_NAME" ]

    case "$EVENT" in

    case $ACTION in
    git add "$FILE_NAME"
    git commit -m "$FILE_NAME created"
    git rm --cached "$FILE_NAME"
    git commit -m "$FILE_NAME removed"
    git add "$FILE_NAME"
    git commit -m "$FILE_NAME changed"
     \ /
      Last update: 2007-12-07 23:03    [W:0.029 / U:0.768 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site