Something tells me that this git workflow is not very idiomatic



  • From git log --graph --oneline --color:




  • My god...it's full of stars!



  • What's the problem? Too many parallel workflows? It could be normal, depending on the size of the project.



  • Now, imagine the merge before the release.


  • ♿ (Parody)

    ZOMG! It even scribbles all over the branch graph!



    1. If you're using the commandline to view a workflow graph, you're doing it wrong.
    2. If you're using git, you're doing it wrong.


  • @The_Assimilator said:

    2. If you're using anything other than git, you're doing it wrong.
     

     FTFY.

    (yes, I know it's pretty subjective. But seriously, I could never go back to anything else than git now that I have tasted it. It's just so convenient and quick)



  • Graphs in the terminal? How can the "Open Source community", with all their books about Unix philosophy and good practices and whatnot, tolerate such a dirty hack?


  • Trolleybus Mechanic

     



  • @TheLazyHase said:

    (yes, I know it's pretty subjective. But seriously, I could never go back to anything else than git now that I have tasted it. It's just so convenient and quick)

     

     Much the same has been said about crack.

     



  • @TheLazyHase said:

    @The_Assimilator said:

    2. If you're using anything other than git, you're doing it wrong.
     

     FTFY.

    (yes, I know it's pretty subjective. But seriously, I could never go back to anything else than git now that I have tasted it. It's just so convenient and quick)

    After using both Git and Mercurial, I can safely say that the latter is objectively better. If you insist on using Git, well, my only question is:



  • @The_Assimilator said:

    @TheLazyHase said:

    @The_Assimilator said:

    2. If you're using anything other than git, you're doing it wrong.
     

     FTFY.

    (yes, I know it's pretty subjective. But seriously, I could never go back to anything else than git now that I have tasted it. It's just so convenient and quick)

    After using both Git and Mercurial, I can safely say that the latter is objectively better.

    Huh? How so? I use Git because IT IS OBJECTIVELY BETTER THAN MERCURIAL.



  • @TheLazyHase said:

    @The_Assimilator said:
    2. If you're using anything other than git, you're doing it wrong.
    FTFY.(yes, I know it's pretty subjective. But seriously, I could never go back to anything else than git now that I have tasted it. It's just so convenient and quick)

    Do we have to have this git discussion every fucking time?

    Look it's shit. It's nice that you like it, but it's BAD SOFTWARE. There's the short version. Git is bad shitty software. Maybe *if* the Git developers realize it's bad shitty software and begin fixing its flaws, it'll become better software in the near future. Maybe pigs will fly. My money's on the pigs.

    EDIT: and while I'm ranting, why the fuck are you looking at a GRAPH in a TEXT-MODE WINDOW and thinking to yourself, "hey this Git program is pretty damn good!" Doesn't the fact that it's SO COMPLETELY FUCKING INCOMPETENT IT CAN'T EVEN DRAW A GRAPH PROPERLY enter into your little tiny brain? Don't you have the part of your brain that says, "programs that draw graphs in text-mode windows are pretty shitty"? What happened to it?



  • Doesn't Bioshock Infinite have flying pigs?

    Maybe I imagined it.



  • @dhromed said:

    Doesn't Bioshock Infinite have flying pigs?

    Maybe I imagined it.

    No but it has robot angel Abraham Lincoln fighting robot angel George Washington. So that's close.

    It has flying kaiju.



  • @The_Assimilator said:

    1. If you're using the commandline to view a workflow graph, you're doing it wrong.

    I have tools to view a commit history graph in a similar way, this just happens to be one compelling way to present the hilarious and impenetrable level of complication present in this portion of the commit history. Git's ASCII art view is far more compelling when the graph more closely approximates a straight line. :P

    The codebase in question actually does have way too many people working on it at once, and it should be multiple repositories of encapsulated unrelated components managed by unrelated teams, and that is happening... gradually, of course, but in a few years it may be an eminently well-organized series of codebase with a really nice architecture. In the meantime, though, the homegrown workflow-management tools used to manage "too many people working on it at once" also make the history graph approximately, oh, twice as hard to track, I think? :)



  •  You must be awesome at Frogger. I've never even seen that level before.



  • It's like a big ball of wibbly-wobbly branchy-wanchy slashes.

    I don't see how that's supposed to help anybody.

    Also anybody who calls git "quick" and "convenient" is obviously using it on a single computer and a single branch.



  • Having used Git for 4 years, and Mercurial for 2, I F****ING HATE MERCURIAL!!! It is just wrong. Its idea of branches are wrong and useless. Its development philosophy is wrong.

    Git has fewer features to provide far more functionality. I'm very glad that the new manager I'm now working under is willing to push Git again. And now, our parent company is trying to standardize Git across the whole organization.

    @The_Assimilator said:

    After using both Git and Mercurial, I can safely say that the latter is objectively better.

    How so? They both try to use a snapshot-based idiom, yet Mercurial still has a diff-based storage engine. The Git object database is a far cleaner design. While some objects are stored in diff-based packs, those packs are read-only and are only generated in batch, which makes the database far more robust. There is no equivalent in Mercurial, that I've seen, of the Reflog. It's just as easy, in both systems, to damage a branch tip, but in Git you can easily go back to where you have been with the reflog. Mercurial has no such "Oh S***!" facility.

    Lastly, I can't count the number of times Mercurial has given me a unicorn without a useful error message. (While it turned out to be a co-worker's fault, it took way too long to track down what happened, and I only found the problem by trying to convert the mercurial repo to Git.)


  • ♿ (Parody)

    @Circuitsoft said:

    Having used Git for 4 years, and Mercurial for 2, I F****ING HATE MERCURIAL!!! It is just wrong. Its idea of branches are wrong and useless.

    Could you be more specific about why you think mercurial branches are wrong and useless?

    @Circuitsoft said:

    The Git object database is a far cleaner design. While some objects are stored in diff-based packs, those packs are read-only and are only generated in batch, which makes the database far more robust.

    As an end user, why should I care about this? OK, "robust" is a good thing, I guess, but I've yet to run into a problem with this.

    @Circuitsoft said:

    There is no equivalent in Mercurial, that I've seen, of the Reflog. It's just as easy, in both systems, to damage a branch tip, but in Git you can easily go back to where you have been with the reflog. Mercurial has no such "Oh S***!" facility.

    I've looked around a little, and I can't figure out WTF a Reflog (i.e., git-reflog) actually is. The best explanation I found:
    @gitolite said:

    a reflog is a very special "branch" that records each position of HEAD in the last 30 days (by default). So removed branches won't be purged by prune until after waiting for 30 days, when the last reference to them will finally be released.

    Perhaps the reason there's no such thing in hg is that you generally don't remove history like you do in git. This seems like a difference in philosophy, and one of the reasons I suspect git is better suited to really large projects.

    @Circuitsoft said:

    Lastly, I can't count the number of times Mercurial has given me a unicorn without a useful error message. (While it turned out to be a co-worker's fault, it took way too long to track down what happened, and I only found the problem by trying to convert the mercurial repo to Git.)

    Hmm...I haven't had that experience either. What sort of issue was it? I've heard others complain about this sort of thing. Usually, it was coming from someone really comfortable with svn, and without a clue about DVCS. But it turned out to be pretty obvious to me and others familiar with hg.



  • @boomzilla said:

    @Circuitsoft said:
    Having used Git for 4 years, and Mercurial for 2, I F****ING HATE MERCURIAL!!! It is just wrong. Its idea of branches are wrong and useless.

    Could you be more specific about why you think mercurial branches are wrong and useless?

    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.
    @boomzilla said:
    @Circuitsoft said:
    The Git object database is a far cleaner design. While some objects are stored in diff-based packs, those packs are read-only and are only generated in batch, which makes the database far more robust.

    As an end user, why should I care about this? OK, "robust" is a good thing, I guess, but I've yet to run into a problem with this.

    I supppose it doesn't really matter to an end-user, but it makes it much easier to build other software and utilities on top of Git, having a unified object model, than Mercurial's database. You might look at the Git Notes facility, and try to imagine how you could implement that in Mercurial. I've also seen Wikis and bug-trackers implemented with Git as the storage engine, and you can even have your code and bug database in the same repo if you want.
    @boomzilla said:
    @Circuitsoft said:
    There is no equivalent in Mercurial, that I've seen, of the Reflog. It's just as easy, in both systems, to damage a branch tip, but in Git you can easily go back to where you have been with the reflog. Mercurial has no such "Oh S***!" facility.

    I've looked around a little, and I can't figure out WTF a Reflog (i.e., git-reflog) actually is. The best explanation I found:
    @gitolite said:

    a reflog is a very special "branch" that records each position of HEAD in the last 30 days (by default). So removed branches won't be purged by prune until after waiting for 30 days, when the last reference to them will finally be released.

    Perhaps the reason there's no such thing in hg is that you generally don't remove history like you do in git. This seems like a difference in philosophy, and one of the reasons I suspect git is better suited to really large projects.

    That would make sense, but I gave an example above of where history editing would be necessary in both systems. 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.
    @boomzilla said:
    @Circuitsoft said:
    Lastly, I can't count the number of times Mercurial has given me a unicorn without a useful error message. (While it turned out to be a co-worker's fault, it took way too long to track down what happened, and I only found the problem by trying to convert the mercurial repo to Git.)

    Hmm...I haven't had that experience either. What sort of issue was it? I've heard others complain about this sort of thing. Usually, it was coming from someone really comfortable with svn, and without a clue about DVCS. But it turned out to be pretty obvious to me and others familiar with hg.

    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".


  • ♿ (Parody)

    @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."

    @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."

    @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.

    @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.



  • @blakeyrat said:

    EDIT: and while I'm ranting, why the fuck are you looking at a GRAPH in a TEXT-MODE WINDOW and thinking to yourself, "hey this Git program is pretty damn good!" Doesn't the fact that it's SO COMPLETELY FUCKING INCOMPETENT IT CAN'T EVEN DRAW A GRAPH PROPERLY enter into your little tiny brain? Don't you have the part of your brain that says, "programs that draw graphs in text-mode windows are pretty shitty"? What happened to it?
     

    Goddamn blakey, chill out. It's just an option. For as long as I've used Git it has also come with a GUI version of the same thing.

    And having a text-mode version is portable & handy. It works on my phone, for instance, when I want to check on new commits while waiting for lunch.

    Even if Git was as shitty as you say, it would still be the only VCS I could stand, since it's the only one that let's me fuck everything up so bad, and then fix it easily, anyway. Everything else has too many gotcha situations, and I feel like I have to be extra careful, and do things the right way the FIRST time EVERY time. I'm too error-prone for that.

    Just look at the hg supporter claiming that committing to the wrong branch is an error "a lot deeper" than "using the UI wrong."



  • @superjer said:

    Goddamn blakey, chill out.

    You must be new here.


  • ♿ (Parody)

    @superjer said:

    Just look at the hg supporter claiming that committing to the wrong branch is an error "a lot deeper" than "using the UI wrong."

    I'm...not sure what you mean by that. It's kinda like saying running "sudo rm -rf /" is "using the UI wrong."

    I would classify, committing files you didn't mean to commit yet as "using the UI wrong." But to commit to the wrong branch takes several steps, and probably means you aren't paying attention or don't know what you're doing or are in too much of a hurry to care. I guess that in a sense, anything can be "using the UI wrong."

    "I put my server password into public source control. Oops, used the UI wrong."



  • @boomzilla said:

    @superjer said:
    Just look at the hg supporter claiming that committing to the wrong branch is an error "a lot deeper" than "using the UI wrong."

    I'm...not sure what you mean by that. It's kinda like saying running "sudo rm -rf /" is "using the UI wrong."

    I would classify, committing files you didn't mean to commit yet as "using the UI wrong." But to commit to the wrong branch takes several steps, and probably means you aren't paying attention or don't know what you're doing or are in too much of a hurry to care. I guess that in a sense, anything can be "using the UI wrong."

    "I put my server password into public source control. Oops, used the UI wrong."

     

    But the point is, committing to the wrong branch doesn't NEED to be a big deal. Git makes it one less thing I need to worry about, esp. since I usually have lots of branches and switch tasks frequently.

    And I DON'T care. I don't need to. I can always put it on the right branch later. Sometimes I just want it committed.

     



  • @superjer said:

    Goddamn blakey, chill out.

    Improving the quality of software is important to me.

    @superjer said:

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

    Liar.

    @superjer said:

    It works on my phone, for instance, when I want to check on new commits while waiting for lunch.

    Jesus man. Get a life.

    @superjer said:

    Even if Git was as shitty as you say, it would still be the only VCS I could stand, since it's the only one that let's me fuck everything up so bad, and then fix it easily, anyway.

    Yeah, but Git's the one doing the fucking-up in the first place! So you're saying, "Git is a great SCM because it lets me fix the problems created by Git being a shitty SCM."



  • @blakeyrat said:

    @superjer said:
    Goddamn blakey, chill out.

    Improving the quality of software is important to me.

    Well then do that? Bitching while ignoring reality doesn't help. See:

    @blakeyrat said:

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

    Liar.

    https://github.com/git/git/commit/5569bf9bbedd63a00780fc5c110e0cfab3aa97b9

    No, I was not using Git in 2005.

    @blakeyrat said:

    @superjer said:
    It works on my phone, for instance, when I want to check on new commits while waiting for lunch.

    Jesus man. Get a life.

    ...says the guy bitching about version control he doesn't use on the Internet.

    @blakeyrat said:

    @superjer said:
    Even if Git was as shitty as you say, it would still be the only VCS I could stand, since it's the only one that let's me fuck everything up so bad, and then fix it easily, anyway.

    Yeah, but Git's the one doing the fucking-up in the first place! So you're saying, "Git is a great SCM because it lets me fix the problems created by Git being a shitty SCM."

    Git does exactly what I tell it to. (Except once when I ran into an actual bug in it.) Sometimes I tell it to do the wrong thing. Believe it or not, I actually make mistakes all on my own. I make the exact same mistakes with other VCSs but there it's actually a problem.


  • ♿ (Parody)

    @superjer said:

    But the point is, committing to the wrong branch doesn't NEED to be a big deal. Git makes it one less thing I need to worry about, esp. since I usually have lots of branches and switch tasks frequently.

    OK. It's not a big deal on mercurial, either. I've had to clean up that sort of thing. But I'm glad you can deal with it, too.

    @superjer said:

    And I DON'T care. I don't need to. I can always put it on the right branch later. Sometimes I just want it need to be committed.

    FTFY



  • @superjer said:

    Git does exactly what I tell it to. (Except once when I ran into an actual bug in it.) Sometimes I tell it to do the wrong thing. Believe it or not, I actually make mistakes all on my own. I make the exact same mistakes with other VCSs but there it's actually a problem.

    So I take it you don't need spell checking then, since you believe that software should just let you make what it knows to be mistakes?

    Also, since you think it's so easy to tell Git to fix your mistakes, how about you fix the one that made me stop using Git? I made changes to a binary file that was changed on another system and PCP'd*, the committed without pulling first, thus creating an anonymous branch. I couldn't pull back from the master after that since the branches couldn't be merged, as it failed with some unhelpful error the text of which was lost to the mists of time. I couldn't tell it to either toss out my changed file and just use the one from the other branch, nor could I tell it to toss out the entire branch and replace it with the latest from the master, save for just deleting the entire local repository and cloning up a fresh copy from the master.

    (I got $5 down that you don't even have a master branch.)

    * Pull/Commit/Push



  • @blakeyrat said:

    Do we have to have this git discussion every fucking time?

    Look it's shit. It's nice that you like it, but it's BAD SOFTWARE. There's the short version. Git is bad shitty software.

    isn't git Torvalds' baby?


  • @esoterik said:

    isn't git Torvalds' baby?
     

    Objection, your honor; relevance?


  • Discourse touched me in a no-no place

    @superjer said:

    And I DON'T care. I don't need to. I can always put it on the right branch later. Sometimes I just want it committed.
    What??? <whimpers/>



  • @boomzilla said:

    @Circuitsoft said:
    There is no equivalent in Mercurial, that I've seen, of the Reflog. It's just as easy, in both systems, to damage a branch tip, but in Git you can easily go back to where you have been with the reflog. Mercurial has no such "Oh S***!" facility.

    I've looked around a little, and I can't figure out WTF a Reflog (i.e., git-reflog) actually is.

    It's for when your software behaves very badly, and you really need to flog it again.



  • @boh said:

    It's for when your software behaves very badly, and you really need to flog it again.
     

    Awwww yeah



  • @esoterik said:

    isn't git Torvalds' baby?

    More like the afterbirth, rotting away in a biohazard bin.



  • @superjer said:

    https://github.com/git/git/commit/5569bf9bbedd63a00780fc5c110e0cfab3aa97b9

    I have no idea what the fuck I'm looking at from that highly descriptive URL. But my logic was as-follows: if Git did have a GUI to do this (and I'm still 99.9% sure it doesn't), why the holy fuck would someone use that awful text abomination?



  • @blakeyrat said:

    @superjer said:
    https://github.com/git/git/commit/5569bf9bbedd63a00780fc5c110e0cfab3aa97b9

    I have no idea what the fuck I'm looking at from that highly descriptive URL. But my logic was as-follows: if Git did have a GUI to do this (and I'm still 99.9% sure it doesn't), why the holy fuck would someone use that awful text abomination?

    You're looking at Github user "git"'s repository "git"'s commit with an identifier starting with 5569bf9b. It has a very descriptive commit message if you actually couldn't tell from CONTEXT CLUES.



  • @Ben L. said:

    It has a very descriptive commit message

    @very descriptive commit message said:

    Do a cross-project merge of Paul Mackerras' gitk visualizer
    gitk is really quite incredibly cool, and is great for visualizing what
    is going on in a git repository. It's especially useful when you are
    looking at what has changed since a particular version, since it
    gracefully handles partial trees (and this also avoids the expense of
    looking at all changes in a big project).

    For example, to see what changed in a merge after a "git pull", do

    <p>gitk ORIG_HEAD..
    

    to see only the new things. Or you can simply do "gitk v2.6.12.." to see what has changed since the v2.6.12 tag etc.

    That you think is "very descriptive?" Is there anybody who uses Git who is a human being capable of talking in human being words?


  • Discourse touched me in a no-no place

    @blakeyrat said:

    @superjer said:
    https://github.com/git/git/commit/5569bf9bbedd63a00780fc5c110e0cfab3aa97b9

    I have no idea what the fuck I'm looking at from that highly descriptive URL. But my logic was as-follows: if Git did have a GUI to do this (and I'm still 99.9% sure it doesn't), why the holy fuck would someone use that awful text abomination?

    That's a URL to a specific commit. In the space of all possible commits in the world, that URL indicates that specific one. It might have other nicer names that point to it (i.e., it might be tagged or — less likely — the tip of some branch) but that's that specific one. In the non-DVCS world, you could use a shorter ID (e.g., a sequence number) but you can'd do that when you distribute things because you no longer have a central authority for issuing them. Instead, you use a content hash (which is what that ID really is). Suggestions for anything else are welcome, but it's really hard to come up with anything that is readable and works without a central authority (central authorities being distinctly problematic for other reasons).



  • @MiffTheFox said:

    I made changes to a binary file that was changed on another system and PCP'd*, the committed without pulling first, thus creating an anonymous branch. I couldn't pull back from the master after that since the branches couldn't be merged, as it failed with some unhelpful error the text of which was lost to the mists of time. I couldn't tell it to either toss out my changed file and just use the one from the other branch, nor could I tell it to toss out the entire branch and replace it with the latest from the master, save for just deleting the entire local repository and cloning up a fresh copy from the master.

    (I got $5 down that you don't even have a master branch.)

    * Pull/Commit/Push

    If I understand you right, that's not too hard. Give your HEAD with the favored commit a name for convenience (git checkout -b temp). Reset your other branch (git checkout master; git fetch; git reset --hard origin/master) (I'm assuming you're working on master and your organization's canonical repo is named origin). Now you're on your main master, you can say something like "git merge --strategy=theirs temp" to copy what you have on temp and overwrite what you have on master. When you're done, push, and git branch -d temp (delete the temporary branch).

    Not that git is intuitive or anything, but it's certainly capable of doing what you wanted. Not even that hard ;) if you want REAL trickiness, ask me how to merge two repositories with no history in common whatsoever. Consider Stack Overflow next time if you're having trouble? :D

    Also, you didn't create an anonymous branch, theoretically; your branch is named 'master'... it's just your local edition of 'master', as opposed to origin/master. You could think of it as miffthefox/master? (If someone added your machine as a remote named 'miffthefox', that's what they'd see.)



  • @fennec said:

    @The_Assimilator said:
    1. If you're using the commandline to view a workflow graph, you're doing it wrong.

    I have tools to view a commit history graph in a similar way, this just happens to be one compelling way to present the hilarious and impenetrable level of complication present in this portion of the commit history. Git's ASCII art view is far more compelling when the graph more closely approximates a straight line. :P

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



  • ♿ (Parody)

    @blakeyrat said:

    @Ben L. said:
    It has a very descriptive commit message

    @very descriptive commit message said:

    ...

    That you think is "very descriptive?" Is there anybody who uses Git who is a human being capable of talking in human being words?

    Wow. That is extremely descriptive for a commit message, and you didn't even quote all of it. It's quite well written if one actually pauses to read it (I know, that's asking way too much here). Maybe you just meant that there weren't enough capitalized expletives or something?



  • @boomzilla said:

    That is extremely descriptive for a commit message,
     

    That's not a commit message, that's a generic forum post talking about some feature of git, that accidentally got posted into the commit message field.

    I decipher that Linus torvals wrote some code (or whatever) and committed it to the repositiry, but there's no mention of what he did.

    Unless..

    Unless Linus is confused about how to use English verbs and present/past tense, and "Do a cross-project merge of Paul Mackerras' gitk visualizer" is supposed to mean "Did a cross-project merge of Paul Mackerras' gitk visualizer". And then added a lot of pointless text that should have gone on some dicussion board.



  • @dhromed said:

    @boomzilla said:

    That is extremely descriptive for a commit message,
     

    That's not a commit message, that's a generic forum post talking about some feature of git, that accidentally got posted into the commit message field.

    I decipher that Linus torvals wrote some code (or whatever) and committed it to the repositiry, but there's no mention of what he did.

    The word "merge" and 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.

    @dhromed said:

    Unless..

    Unless Linus is confused about how to use English verbs and present/past tense, and "Do a cross-project merge of Paul Mackerras' gitk visualizer" is supposed to mean "Did a cross-project merge of Paul Mackerras' gitk visualizer".

    I don't know if kernel follows the same rules, but the standard for GNU ChangeLog entries specifies to use present, not past tense. 

    @dhromed said:

    And then added a lot of pointless text that should have gone on some dicussion board.

    Yeah, it's fairly pointlessly chatty, but given that it was a simple import of a single file, there wasn't a lot to say, so I'm pretty indifferent about the whole thing.



  • @dhromed said:

    Unless Linus is confused about how to use English verbs and present/past tense, and "Do a cross-project merge of Paul Mackerras' gitk visualizer" is supposed to mean "Did a cross-project merge of Paul Mackerras' gitk visualizer". And then added a lot of pointless text that should have gone on some dicussion board.

    Yeah, this is more or less canonical git commit message style, which I believe was summarized in its most canonical format in 2008: using the imperative.

    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.



  • The point was, the link was provided to me as "evidence" that Git ships with a GUI diagram-creation tool. There's nothing on the link that says what the file involved does (and it seems to assume you already knew what it did before reading the link.)

    So the link is useless to me as evidence that Git ships with a diagram-creation tool.



  •  @blakeyrat said:

    The point was, the link was provided to me as "evidence" that Git ships with a GUI diagram-creation tool. There's nothing on the link that says what the file involved *does* (and it seems to assume you already knew what it did before reading the link.)

    So the link is useless to me as evidence that Git ships with a diagram-creation tool.

     I don't give a flying fuck if you accept it or not. I posted it to counter your stupid bullshit, calling me a liar. Anyone who cares can use it to easily check that you are full of shit.

     

     

     



  • @blakeyrat said:

    The point was, the link was provided to me as "evidence" that Git ships with a GUI diagram-creation tool. There's nothing on the link that says what the file involved does (and it seems to assume you already knew what it did before reading the link.)

    So the link is useless to me as evidence that Git ships with a diagram-creation tool.

    '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" with a diff adding likes to the file "gitk" authored by Linus Torvalds, presented on a page labeled "git/git". However, I can expend the effort to whine about it.'

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



  • @MiffTheFox said:

    @superjer said:
    Git does exactly what I tell it to. (Except once when I ran into an actual bug in it.) Sometimes I tell it to do the wrong thing. Believe it or not, I actually make mistakes all on my own. I make the exact same mistakes with other VCSs but there it's actually a problem.

    So I take it you don't need spell checking then, since you believe that software should just let you make what it knows to be mistakes?

    Sorry, but no, I don't want any VCS telling me "It looks like you are committing this to the wrong branch" because it has absolutely no way to know that. It's nothing like spell checking at all.

    I'd love to see an example of something that Git lets you do, "knowing" it to be a mistake. Is deleting a file a mistake? What if it is a really important file?

    And $5 for having a master branch? How is this relevant? I have at least 80 across different repos, but what's it matter?

     


Log in to reply