Something tells me that this git workflow is not very idiomatic



  • @fennec said:

    'I can't expend the effort to pick out the words "gitk is really quite incredibly cool, and is great for visualizing what is going on in a git repository"

    For all I know, that means it draws a little animated .gif of a happy puppy if your repo has more than 5 commits a day. That's "quite incredibly cool".

    I concede that whatever it does, it is (or was) part of the git project. But that's not the point. The point is nobody's demonstrated, or hell even *stated*, what the fucking thing *does*.

    @fennec said:

    I think you just like whining and excuses to whine. :)

    Call me crazy, but if someone gives me a link of evidence of X, I'd expect the link to actually contain some kind of evidence of X.



  • @DaveK said:

    the line "Showing 1 changed file with 1,711 additions and 0 deletions." makes it pretty clear to me that he imported a single file wholesale.
     

    Didn't even see that. I was focusing on the blather, which boomy calls good which it isn't.

    @DaveK said:

    the standard for GNU ChangeLog entries specifies to use present, not past tense. 

    @fennec said:

    You end up with a sequence of commit summaries which combine together like a sequence of commands... "Do this. Add this. Change that. Merge the other thing. Fix bug." It is a style. It has its advantages and disadvantages.
     

    Fair enough.

    @DaveK said:

    given that it was a simple import of a single file, there wasn't a lot to say

    So say nothing! My comments for this kind of thing are always super-terse, and may contain a reference to the bugtracker or whatever management software the company uses.

    @superjer said:

    I posted it to counter your stupid bullshit, calling me a liar.
     

    Good job.

    PS. I've dispatched the hounds because of your icon. Start running. No bell is going to save you.

     



  • When I read that commit I thought this was gitk:

    [op's picture]



  • @fennec said:

    Also, I have to expend effort to anonymize some visualizations. e.g. here. But here we go! Github version of a hilarious graph.



    "begone-ye-403"? I approve of exorcising bugs with Olde Englishe... :)



  • @blakeyrat said:

    The point is nobody's demonstrated, or hell even stated, what the fucking thing does.
    http://lmgtfy.com/?q=gitk



  • @boomzilla said:

    "Oops, used the UI wrong."

    This is my new favorite excuse:

    "Condom broke and I accidentally detonated a baby bomb in the secretary.. must've used the UI wrong!"

    "Woke up in some hotel in a pile of somebody's vomit next to a dead hooker and can't remember the last 3 days.. it's that goddamn UI again!"

    "Annihilated the world economy and left the US a third-world shithole teetering on the edge.. why do they make the UI so confusing??"



  •  

    @morbiuswilters said:

    "Annihilated the world economy and left the US a third-world shithole teetering on the edge.. why do they make the UI so confusing??"
     

    Ah, you've played the new SimCity?



  • @dhromed said:

     

    @morbiuswilters said:

    "Annihilated the world economy and left the US a third-world shithole teetering on the edge.. why do they make the UI so confusing??"
     

    Ah, you've played the new SimCity?

    Lies. Nobody's played the new SimCity.



  • @dhromed said:

     

    @morbiuswilters said:

    "Annihilated the world economy and left the US a third-world shithole teetering on the edge.. why do they make the UI so confusing??"
     

    Ah, you've played the new SimCity?

    If by "the new SimCity" you mean "Master of Orion II", then yes. Yes I have.



  • @blakeyrat said:

    @fennec said:
    'I can't expend the effort to pick out the words "gitk is really quite incredibly cool, and is great for visualizing what is going on in a git repository"

    For all I know, that means it draws a little animated .gif of a happy puppy if your repo has more than 5 commits a day. That's "quite incredibly cool".

    Deliberately assuming something stupid is your fault, not anyone else's.

    @blakeyrat said:

    I concede that whatever it does, it is (or was) part of the git project. But that's not the point. The point is nobody's demonstrated, or hell even stated, what the fucking thing does.

    @fennec said:

    I think you just like whining and excuses to whine. :)

    Call me crazy, but if someone gives me a link of evidence of X, I'd expect the link to actually contain some kind of evidence of X.

    Let's just have a little recap of the conversation, shall we, only this time, with subtitles for the stupid hard-of-thinking (Blakey):

    @superjer said:

    For as long as I've used Git it has also come with a GUI version of the same thing.

    @Blakeymoron said:

    Liar

    @superjer said:

    Link to the time that a feature was added to git that includes the word "visualising"

    Obviously, if you have the memory of a goldfish, you might be able to infer anything from that link, but as above, the problem is your failure to comprehend perfectly ordinary conversation.  (Which I'm convinced you do deliberately on purpose in order to be an argumentative dickweed.)

     



  • @boomzilla said:

    @Circuitsoft said:
    In Mercurial, since a branch is an attribute of a commit, rather than a line of development, it's very easy to accidentally commit to the wrong branch, and undoing the commit and moving it to the right branch is far more difficult than I think it should be. There are a lot of situations I've been in where I just say "oops" and my mistake is very easy to fix (in git) in a few seconds, where Mercurial takes a lot of gymnastics to fix mistakes caused by using the UI wrong.

    Wow. Um. I guess I can see that. It wouldn't be hard to fix with mercurial, though you wouldn't erase the history. Erasing history like that both fascinates and scares me. Also, this mistake is a lot deeper than "using the UI wrong."

    Unfortunately, it really isn't deeper than "using the UI wrong." I have done this, by checking out a different branch (in TortoiseHG), making changes, then committing. The little textbox above the commit area kept the name of the branch I was previously on, so now there were two tips on the same branch (the old one) even though the changes I had just made belonged on the new branch.



    In Git, commits always go to the currently-checked-out branch. Oh, and how would you fix this in Mercurial? Do a revert, then re-commit on the proper branch? If you revert on the old branch, the result of the revert is now the latest commit on the old branch, and contains what had been on the new branch. If you revert on the new branch, then recommit, then your changes, on top of the original state of the new branch become the newest commit on the old branch. A third option is to strip the commit, then re-commit on the right branch. The fact that branches are not equivalent to tips is what makes this mess so confusing.
    @boomzilla said:
    @Circuitsoft said:
    That would make sense, but I gave an example above of where history editing would be necessary in both systems.

    No, you didn't. That's just one way to solve the problem. I'm reminded of the saying, "You can code FORTRAN in any language."

    And now that I've clarified why history editing is necessary...@boomzilla said:
    @Circuitsoft said:
    The fact that Git lets you say "Oops, let me fix that" before publishing your work is a killer feature for me. Also, systems like Gerrit could not function as they do with Mercurial's representation of history, and its refusal to edit it.

    Yes, I can accept that you feel the need to edit history.


    ...@boomzilla said:
    @Circuitsoft said:
    In this case, it was a sub-repo and the parent repo had some commits that referenced commits that had never been pushed in the subrepo. But the error was "path does not exist", not "revision/commit does not exist".

    I think you fucked yourself by trying to use sub-repos. It sounds like the sort of situation where that's the best that could be done, though I've never actually tried to implement sub-repos. And everyone always says that you shouldn't, so I don't.

    That wasn't my decision. I wouldn't have.

    Git has a feature called subtree that allows you to pull shared code from another repository into a subdirectory of your main repository, and actually include the history of both repos in one, so you don't have subrepos to worry about. If you do want to separate out the work, subtree can find all commits that touch that subtree, split out the changes, and push them back to the original repository (or one of your choice).



  • @morbiuswilters said:

    @dhromed said:

     

    @morbiuswilters said:

    "Annihilated the world economy and left the US a third-world shithole teetering on the edge.. why do they make the UI so confusing??"
     

    Ah, you've played the new SimCity?

    If by "the new SimCity" you mean "Master of Orion II", then yes. Yes I have.

    If by "Advanced Technology" you mean "a butt", then yes. Yes I have one.


  • ♿ (Parody)

    @Circuitsoft said:

    Unfortunately, it really isn't deeper than "using the UI wrong." I have done this, by checking out a different branch (in TortoiseHG), making changes, then committing. The little textbox above the commit area kept the name of the branch I was previously on, so now there were two tips on the same branch (the old one) even though the changes I had just made belonged on the new branch.

    I will agree that using Tortoise anything is using the wrong UI for SCM. I'm not sure how Tortoise managed to do this, but I can't think of how you would do this without its nonsense getting in the way, since your commits in hg go to the checked out branch, too.

    @Circuitsoft said:

    In Git, commits always go to the currently-checked-out branch. Oh, and how would you fix this in Mercurial? Do a revert, then re-commit on the proper branch? If you revert on the old branch, the result of the revert is now the latest commit on the old branch, and contains what had been on the new branch. If you revert on the new branch, then recommit, then your changes, on top of the original state of the new branch become the newest commit on the old branch. A third option is to strip the commit, then re-commit on the right branch. The fact that branches are not equivalent to tips is what makes this mess so confusing.

    You're over thinking this. Just go back to where you were working before and commit from there. Then close that other head.



  • @boomzilla said:

    I will agree that using Tortoise anything is using the wrong UI for SCM. I'm not sure how Tortoise managed to do this, but I can't think of how you would do this without its nonsense getting in the way, since your commits in hg go to the checked out branch, too.

    TortoiseGit is absolutely horrid. I've seen corruption due to improper file locking. From what I've seen, TortoiseHG is the only option, especially since FogCreek/Kiln distribute it with their own enhancements.
    @boomzilla said:
    You're over thinking this. Just go back to where you were working before and commit from there. Then close that other head.
    I suppose you can still branch off of a commit before a closed tip. I just haven't wrapped my head around what a closed tip actually means. Is it just hidden?


  • ♿ (Parody)

    @Circuitsoft said:

    @boomzilla said:
    I will agree that using Tortoise anything is using the wrong UI for SCM. I'm not sure how Tortoise managed to do this, but I can't think of how you would do this without its nonsense getting in the way, since your commits in hg go to the checked out branch, too.

    TortoiseGit is absolutely horrid. I've seen corruption due to improper file locking. From what I've seen, TortoiseHG is the only option, especially since FogCreek/Kiln distribute it with their own enhancements.

    I don't know what you're talking about when you say, "TortoiseHG is the only option." As far as I'm concerned, anything with Tortoise in the name is never an option.

    @Circuitsoft said:

    I suppose you can still branch off of a commit before a closed tip. I just haven't wrapped my head around what a closed tip actually means. Is it just hidden?

    Basically. When you (or others) subsequently do an update in that branch, it will ignore the closed branch. It's still in the repo, but you'll have to go out of your way to do anything with it. There are some ways to back out a commit, but they typically aren't pretty, and unless it's something that would be a security breach (e.g., checking in a password), I don't think it's worth the hassle.


Log in to reply