• (disco) in reply to sloosecannon

    My understanding is that SVN 1.5 or later can be configured to launch your favourite 3-way merge tool when it detects conflicts while updating your working directory, so that the update-merge-commit paradigm should result in the same commit as the commit-fetch-rebase-push paradigm used by git.

  • (disco) in reply to urkerab
    urkerab:
    so that the update-merge-commit paradigm should result in the same commit as the commit-fetch-rebase-push paradigm used by git.

    I don't see how that could possibly be.

  • (disco) in reply to boomzilla

    Agreed; surely update-merge-commit is more like pull-merge-commit-push?

  • (disco) in reply to RaceProUK

    Sort of, except in the case of svn, the merge part is happening with transient changes, not something that's already been stored in the repository's history. If you mess up a merge of stuff already committed, you can go back and do it again. If you do mess up the merge of your uncommitted changes with svn, you're fucked (unless you copied all your changes off to another directory or something).

  • (disco) in reply to boomzilla

    Sure, but if you pull before committing in Git, isn't that the same problem of transience? You seem to be talking about commit-pull-merge-push or some such

  • (disco) in reply to Yamikuronue
    Yamikuronue:
    Sure, but if you pull before committing in Git, isn't that the same problem of transience?

    I don't git, but doesn't pull just pull in new commits from the remote repo to your local repo? It doesn't mess with your working copy (or whatever the gitism is) does it?

    Yamikuronue:
    You seem to be talking about commit-pull-merge-push or some such

    The pull and push are distractions. Imagine the stuff is there (or that git is acting like a CVCS). Remember that in svn, you can't commit if your working copy isn't at HEAD and if someone has changed a file after your working revision that you have also changed in your working copy.

  • (disco) in reply to boomzilla
    boomzilla:
    It doesn't mess with your working copy (or whatever the gitism is) does it?

    wait, I thought the local repo basically was your working copy. I'm officially confused. All I know is when I hit the "sync" button in Github for Windows (which appears to do a push and a pull), the files in my local folder change to reflect updates done in Github's version of the repo.

  • (disco) in reply to boomzilla
    boomzilla:
    Remember that in svn, you can't commit if your working copy isn't at HEAD and if someone has changed a file after your working revision that you have also changed in your working copy.
    You can simulate that in `git` (or any DVCS) by always `pull`ing before `commit`ting
    Yamikuronue:
    wait, I thought the local repo basically was your working copy
    For all incense and porpoises, it is ;)
  • (disco) in reply to Yamikuronue
    Yamikuronue:
    wait, I thought the local repo basically was your working copy.

    The local repo contains all the history of commits. When I say, "working copy," I'm talking about the files that you're working with.

    Yamikuronue:
    All I know is when I hit the "sync" button in Github for Windows

    That probably includes an update or something. I have no clue what's going on there. When I DVCS, I use hg.

  • (disco) in reply to boomzilla
    boomzilla:
    When I DVCS, I use hg.
    `git` is basically like `hg`, but more obtuse
  • (disco) in reply to boomzilla

    A pull is both a fetch and a merge, apparently: http://stackoverflow.com/questions/18529206/when-do-i-need-to-do-git-pull-before-or-after-git-add-git-commit

    So I was right, it does change your files.

  • (disco) in reply to Yamikuronue
    Yamikuronue:
    A pull is both a fetch and a merge, apparently

    Ah, an hg pull is just a git fetch, then. hg uses update like svn.

    Yamikuronue:
    So I was right, it does change your files.

    Yes, but you asked for it. You could have just fetched and done a merge of two commits, instead of your transient changes.

  • (disco) in reply to boomzilla
    boomzilla:
    in svn, you can't commit if your working copy isn't at HEAD

    It's worse than that. You can commit (by forcing it) if your working copy isn't at HEAD. So guess what some people do? :facepalm:

  • (disco) in reply to Yamikuronue

    Nope - Pull includes an implicit merge (if needed), and it won't let you pull unless you've committed your stuff, for exactly that reason :stuck_out_tongue:

    Fetch does not, but fetch only gets the commits, it doesn't do anything to your working copy

    ED: :hanzo:

    Yamikuronue:
    A pull is both a fetch and a merge, apparently: http://stackoverflow.com/questions/18529206/when-do-i-need-to-do-git-pull-before-or-after-git-add-git-commit

    So I was right, it does change your files.

  • (disco) in reply to sloosecannon
    sloosecannon:
    it won't let you pull unless you've committed
    Yeah, no, it will :stuck_out_tongue:
  • (disco) in reply to dkf

    Oh no... That's not OK to do

    Yeah, that's the same as the idiots who force push (hehe star wars joke) stuff in git

  • (disco) in reply to RaceProUK

    ...

    It won't let you pull and overwrite things, because it triggers an untracked changes error, OK?

    I'm considering :triangular_flag_on_post: for pendants

  • (disco) in reply to sloosecannon
    sloosecannon:
    I'm considering :triangular_flag_on_post: for pendants
    If you want to, go ahead; we like those :badger:s ;)
  • (disco) in reply to RaceProUK

    Ah, why the hell not.

    :triangular_flag_on_post:ed

  • BrandonPhone (unregistered)
    Comment held for moderation.

Leave a comment on “Source History Information Tool”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article