Git/Atlassian Stash - how do combine commits before making a PR?



  • In that case you're still hosed if the server dies. Although I guess you're hosed either way at that point.



  • You know what I did?

    I said fuck off.

    Problem solved.

    I'm sorry, I make commits as I work so I don't lose progress.

    If you have some kind of process you'd like me to use before making final commits to the main repository, please feel free to tell me.

    Because I'm not going to change the number of my commits to make your log look pretty.


  • :belt_onion:

    @blakeyrat said:

    Then what do "normal" Git users do about all the junk, "taking my laptop home for the day" commits? Just leave them in place?

    Yes. That's exactly what you're supposed to do. Or more accurately, commit when you finish things, and there's no need for those commits 😄

    Let others join the conversation

    This topic is clearly important to you – you've posted more than 24% of the replies here.

    Are you sure you're providing adequate time for other people to share their points of view, too?



  • @blakeyrat said:

    I don't know what that means. How do you get "prompted" with a text file?

    When the CLI command is run, vi is initialized automatically with the text file to be edited.

    @blakeyrat said:

    ... have I mentioned recently how many people tell me Git is a good high-quality tool? Christ.

    I know that I'm not one of them. However, I do understand how it works even if it makes me want to find the developers would made it, especially the ones who wrote the docs, and slowly beat them to death with a spoon.



  • @EvanED said:

    Remember, squash is a special case of what you can do with rebasing; rebasing can perform arbitrary modifications to the history.

    Ok, but again I don't want to make "arbitrary modifications to the history". That is not on my roadmap. At all.

    The stuff I want to do is: 1) extremely easy to do without conflicts, and 2) an extremely obvious problem. So I don't see how it's unfair to call it a bug on Git's part, because it's a bug.

    Saying you won't validate SimpleCaseA because it's impossible to validate ExtremelyComplicatedCaseB doesn't make any sense, doubly-so when 99% of the time people only want to do SimpleCaseA in the first place!


  • :belt_onion:

    @blakeyrat said:

    Ok, but again I don't want to make "arbitrary modifications to the history". That is not on my roadmap. At all.

    You want to squash your commits. They're one and the same.

    @blakeyrat said:

    how do I check-in code to ensure it's safely stored on the server without polluting the hell out of the branch's history?

    You don't care. Because it's not polluting the branch's history.

    @blakeyrat said:

    So I don't see how it's unfair to call it a bug on Git's part, because it's a bug.

    Bug Report: My hammer is ineffective at hammering screws.

    @blakeyrat said:

    Again, if some random dude is in my branch before I create the PR, and they didn't let me know, we have bigger problems.

    Well they pulled the repository, so everyone's in your branch. That's how it works.



  • @blakeyrat said:

    Then what do "normal" Git users do about all the junk, "taking my laptop home for the day" commits? Just leave them in place?

    Fuck right you do.

    @blakeyrat said:

    I don't care about any of the details.

    Me neither.

    Committing is my save button.

    @blakeyrat said:

    How do I do it?!

    Copy all your files to uncontrolled destination, undo your branch, redo your branch, copy files back in, let it diff, bam one commit per branch.

    Create a batch to do that, and you have your Git feature.



  • Reasons more commits aren't a problem.

    1. You can diff from the start and end of a branch, that's what matters, the diff. Git scales with diffs just fine.
    2. You can prove your workflow. Someone asks how much time you spent on something, there you go. Someone asks how much progress you made mid project, there you go. Want to prove you worked late last night, there you go.
    3. It's safer having more than one copy of your work completed so far.
    4. It gives you more restore points. Realize today's work is a wash, you don't have to figure out what you did. Roll back.
    5. It gives more tools to code review. Hey I can see the way you think by reviewing your commits one at a time.

  • :belt_onion:

    +∞



  • @Yamikuronue said:

    According to my devs: by having a VM on the central server hold all your work and tools, and your laptop be a dumb terminal, so you don't have to commit until a feature is done because the work never leaves the building.

    Ugh. Well that's a solution. I guess. That's awful though.

    @xaade said:

    You know what I did?

    I said fuck off.

    Problem solved.

    Ugh. Well that's a solution. I guess. That's awful though.

    @sloosecannon said:

    Yes. That's exactly what you're supposed to do. Or more accurately, commit when you finish things

    What, in any of the stuff I've typed in this thread, leads you to believe I don't commit when I finish things?

    @sloosecannon said:

    there's no need for those commits

    Yes there is. My laptop HD could die at any moment, and making a commit is the only way for me to safely store code on the server and preserve my work.

    Preserve my work. You know, the thing source control is for in the first place? That is the reason. THIS IS WHAT GIT WAS BUILT TO DO. (Presumably?)

    @sloosecannon said:

    Bug Report: My hammer is ineffective at hammering screws.

    Git only gives me the hammer (the rebase command.) I want a screwdriver; where's the screwdriver?

    This is like Atwood calling Discourse a luxury car and not a pick-up truck. That's fine; but that argument doesn't make sense when people want the pick-up truck and the pick-up truck doesn't exist. The argument turns into "don't use Git".

    @xaade said:

    undo your branch,

    I don't know what this means. How do you "undo" a branch?

    @xaade said:

    bam one commit per branch.

    Oh! If that's what you want, there's a checkbox in the Merge dialog that says "only create one commit message".

    @xaade said:

    Create a batch to do that, and you have your Git feature.

    I don't know what a "batch" is or how to create one. EDIT: oh wait, do you mean a .bat file?

    @xaade said:

    Reasons more commits aren't a problem.

    Yeah well like I said, if my boss presses the issue I have stuff to tell him. Then maybe I can ask we go to TFS 2013 and I can be rid of this constant waking-nightmare of a source control tool.


  • I survived the hour long Uno hand

    @blakeyrat said:

    I don't know what a "batch" is or how to create one.

    batch file. A shell script for Windows.

    Hanzo'd by edit



  • Well since it turns out the whole 4573546347647324-step process is just a single checkbox in Stash, there's no point for a "batch". This is the power of GUIs, people. Welcome to 1984.



  • @blakeyrat said:

    Then maybe I can ask we go to TFS 2013 and I can be rid of this constant waking-nightmare of a source control tool.
    Let me ask this: what would you do under TFS? Git gives you strictly more options for how to deal with this than you have with a CVCS. And as I've said, Git handles this situation fine, and I and others have suggested you what you should do. If your Git front end can't rebase pushed branches or can't force push, then that's your crappy front end's problem, not Git's.


  • :belt_onion:

    @blakeyrat said:

    What, in any of the stuff I've typed in this thread, leads you to believe I don't commit when I finish things?

    Allow me to rephrase. Commit when, and only when you finish something. Maybe not when you finish the entire job, but when you finish working on a file, or finish a bug fix, or something like that. If you haven't finished things at the end of the day, it's up to you whether you want to commit them or not. If you want to decrease log spam, no need to commit. If you want to commit, go ahead...

    @blakeyrat said:

    making a commit is the only way for me to safely store code on the server and preserve my work.

    No, that would be a push. That's not a commit. They're 2 completely different things. A commit never leaves your system

    If your hard drive dying is that big of a concern, you probably need a new hard drive...

    Commit when you do anything. Push when you finish something.

    @blakeyrat said:

    Git only gives me the hammer (the rebase command.) I want a screwdriver; where's the screwdriver?

    I was talking about Git in general. You're calling it a bug when it doesn't follow the workflow you're trying to force it to.

    I'm beginning to think you really don't understand how DVCS works at all, if you managed to confuse a commit and a push. Do you actually understand what's happening behind the scenes or does the GUI really cover it all up?



  • @sloosecannon said:

    A commit never leaves your system

    This is his problem with just committing. Thus the entire thread. I can agree with him on this.


  • :belt_onion:

    @JazzyJosh said:

    This is his problem with just committing. Thus the entire thread. I can agree with him on this.

    But if you really need to put everything on the server THAT often, your computer is probably dying



  • @blakeyrat said:

    My laptop HD could die at any moment, and making a commit is the only way for me to safely store code on the server and preserve my work.

    You do realize that, in git, commit only commits to the local repository - which should be on your laptop. push is what protects you from hard drive failure.



  • I mean, seems like he's just risk averse to losing code.



  • Again the issue is that he commits and then immediately pushes so he doesn't have a large chance of losing code. See the above post.


  • I survived the hour long Uno hand

    You can't imagine a scenario in which someone walks away with code on their machine and the code doesn't ever make it back into the building? Not one? I came up with three examples just typing that first sentence.


  • :belt_onion:

    @Yamikuronue said:

    You can't imagine a scenario in which someone walks away with code on their machine and the code doesn't ever make it back into the building? Not one? I came up with three examples just typing that first sentence.

    Did I say that?
    I never said that...

    Yeah, push your code before you leave for the day. That's pretty much SOP and a good idea...



  • @sloosecannon said:

    it's up to you whether you want to commit them or not.

    It's not up to me. It's not my code, it's my employer's. And it's my duty as a developer to keep that code safe, by placing it on their servers.

    The only decision here is "do I want to be a competent software developer?" or "do I want to be an incompetent nitwit?" and I'm picking the first one.

    @sloosecannon said:

    I'm beginning to think you really don't understand how DVCS works at all,

    I do understand how it works: shitty. It works shitty.

    @sloosecannon said:

    Do you actually understand what's happening behind the scenes

    Way more than I want to. I'm the user, I shouldn't have to know or care what's happening behind the scenes. That's why the scenes are there.

    The reason I need to know when it comes to Git is because Git was written by shitty software developers who are ok with shipping a shitty product.

    @JazzyJosh said:

    I mean, seems like he's just risk averse to losing code.

    I await an explanation of how this is a bad thing.

    @sloosecannon said:

    Yeah, push your code before you leave for the day. That's pretty much SOP and a good idea...

    Ok, then how do you combine your commits before you finish the feature and create the PR so you don't have a bunch of useless commit messages lik-- OH WHOA, DEJA VU!


  • :belt_onion:

    @blakeyrat said:

    Ok, then how do you combine your commits before you finish the feature and create the PR so you don't have a bunch of useless commit messages lik-- OH WHOA, DEJA VU!

    You DON'T. There is no need. Why do you keep thinking there is one!?
    Describe the feature in the PR. If the boss needs more detail, he can look at the individual commits, or can diff them all as a group. Or diff specific ones. Or do whatever the hell he wants to.

    @blakeyrat said:

    I await an explanation of how this is a bad thing.

    Because the argument could be made that your paranoia is negatively impacting your workflow



  • @sloosecannon said:

    You DON'T. There is no need. Why do you keep thinking there is one!?

    My boss told me there was. It was in the OP, remember? Go back and read it.


  • :belt_onion:

    So your boss is doing it wrong. Unfortunately for you, there's no way to do what he wants reasonably, given your workflow. So, I'm sorry, but you're kinda stuck.

    That was the point of my prior posts, just so you know. You're not doing it wrong here, it's your boss. Please feel free to quote us here - Squashing all the commits down doesn't help anything. He's trying to smash nailsscrews in with a hammer.



  • @sloosecannon said:

    He's trying to smash nails in with a hammer.

    Like you're supposed to?


  • :belt_onion:

    Belgium you Freud.



  • @sloosecannon said:

    Squashing all the commits down doesn't help anything.

    I disagree with this, because it does clean up the repository. If changing the commit "history" leads to a better story of what changes go together, what different things are doing, etc., then I definitely think it is helpful to make the history reflect that. (This is why I'm pretty open to the whole rebasing thing, as you can probably tell.)

    The fact that rewriting history makes it so that you don't actually see what people were thinking and how they got to a solution I think is a fiction, because the fact that your repository reflects all that if you don't rebase is already a fiction. If you introduce a bug and discover it while still working on a feature and can go fix it then, that's almost always what you do (I hope); you don't commit the broken version. If you work for a while and realize your approach is fundamentally flawed, you don't commit your flawed attempt because "hey that's what actually happened man"; you revert and and try again.

    If I have a feature A for which two commits, A1 and A2 are a nice logical division, but after doing A1 I discover a bug B that is blocking A2, I would much rather see a rebased history of B -> A1 -> A2 than a non-rebased history of A1 -> B -> A2 or a merged history with A1 -> A2 on one branch, B on another, and a merge commit. I definitely think the former will be the most useful down the line.

    Now whether you actually should do that, I'm not sure, because in my experience getting a history I actually like is often a fair bit of effort and time, and I don't know it's worth it.


  • :belt_onion:

    Well I personally rebase instead of pull all the time, to quash the merge commits that are white noise commits. But, since Blakey's workflow (either due to policies or his own personal rules) is to push everything when he commits, he shouldn't be doing history rewrites, since it's all up on the server already


  • Discourse touched me in a no-no place

    @blakeyrat said:

    So I don't see how it's unfair to call it a bug on Git's part, because it's a bug.

    Your worldview, where "something that doesn't work the way I think it should' is a bug, fascinates me.



  • @FrostCat said:

    Your worldview, where "something that doesn't work the way I think it should' is a bug, fascinates me.

    Do you believe I'm the only Git user on the planet who has this problem? (Ignoring for a fact that, even if I was, it'd still be a bug.)

    Note: saying it's a bug is not the same as saying it's an important bug, or even that it's a bug they should ever fix. That's an entirely different continuum.

    But there's no way this isn't a bug. I'd even call it a relatively important one, if I somehow worked on the Git team.



  • Just saying.

    Also, I'd really like the tool that blakey sketched. Looks neat.

    As for how I'd solve the problem... well, as a not very advanced git user, I'd avoid as much complexity as possible and just do the simple stuff I know won't fuck me over. So for every branch I need to work on, I'd

    • Create a scratch branch. Eg. for "feature-blarg", create local branch "feature-blarg-scratch".
    • Push "feature-blarg-scratch" to remote server
    • Work on the branch "feature-blarg-scratch", creating all the bullshit commits I want
    • Once done, switch to local branch "feature-blarg" (that I didn't touch yet)
    • Merge in the stuff from "feature-blarg-scratch"
    • Squash everything into a single feature commit
    • Push to remote "feature-blarg"
    • Create a pull request

  • I survived the hour long Uno hand

    What is a defect? When the system does not perform as expected. If the only oracle you have for your testing is "the way I imagine it works", then any unexpected behavior is a bug. This is why choosing a good, consistent oracle is key to writing test cases.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Do you believe I'm the only Git user on the planet who has this problem?

    No, I'm saying that it's unreasonable to call something that's working as designed a bug just because you don't like the way it works. Bugs are when things don't work as documented, not when you wish they worked differently.

    Given how much trouble git has caused you, it seems like for your next job you should make sure as part of the interview process they don't use it, if you're not willing to use it the way it's designed to work.

    That's not intended to be snark or anything, by the way. This caused you grief at your last job too, didn't it? Either find a job where they don't use the tool you don't like, or learn to use it the way it's intended to be used, even though you're afraid of CLI.



  • @cartman82 said:

    Just saying.

    Your screenshot is a good reminder why I don't use that tool. What terrible, misleading, confusing menu captions.

    @cartman82 said:

    Also, I'd really like the tool that blakey sketched. Looks neat.

    It doesn't even "look neat", it looks like BONE-HEADEDLY SIMPLE SHIT THEY SHOULD HAVE HAD BEFORE 1.0!

    @cartman82 said:

    Create a scratch branch. Eg. for "feature-blarg", create local branch "feature-blarg-scratch".
    Push "feature-blarg-scratch" to remote server
    Work on the branch "feature-blarg-scratch", creating all the bullshit commits I want
    Once done, switch to local branch "feature-blarg" (that I didn't touch yet)
    Merge in the stuff from "feature-blarg-scratch"
    Squash everything into a single feature commit
    Push to remote "feature-blarg"
    Create a pull request

    aint_got_no_time_for_that.gif



  • While I agree that Git interfaces are pretty terrible, your situation is made all the more awful by the particular way your employer chose to implement git. In particular, the "one branch per ticket" rule.

    Assuming you're allowed to push back on that, since their own policies are in conflict**, I would try to get permission to create new branches. They can still demand that each ticket have one branch, but if you can branch off of your branch that would solve most of your problems.

    ** By their policies being in conflict, I mean they have rules that:

    • You can only have one branch per ticket,
    • You shouldn't lose your work (it may not be written down, but they probably wouldn't be happy if you lost any work)
    • Your log should be clean.

    The only way to save your work is to push, and the only place to push is the one branch they allow you to have per ticket. Demanding that the log stay clean conflicts with these two.

    If you can get permission to create new branches, you can then have the "official branch" that will be used to create the pull request, and a secondary branch hanging off of that one to push temporary commits to. You can then merge from the temporary branch to the real branch, selecting as many or as few commits into each "official" commit, and then send the pull request.

    So, Git isn't great, but combining Git with poor policies is the real issue. I'm guessing the "one branch per ticket" is a hold over from whatever system they had before Git. It might have been a good fit for that previous system, but it's unreasonably constraining for git. It's as if you were given a car, then told to never turn left, ever. So when you want to go left, you instead have to take three rights. It's not the car that's at fault, it's the unreasonable constraints added to the car.



  • @FrostCat said:

    No, I'm saying that it's unreasonable to call something that's working as designed a bug just because you don't like the way it works. Bugs are when things don't work as documented, not when you wish they worked differently.

    Dafuq? Do you develop software this way?

    So if the spec says, "the 'save' button should delete all the user's files and also kick their dog", and the save button does exactly what it says, that's not a bug?

    @FrostCat said:

    Given how much trouble git has caused you, it seems like for your next job you should make sure as part of the interview process they don't use it, if you're not willing to use it the way it's designed to work.

    I agree. One of the reasons I took my last job (that turned out to be super-shitty-- see the How To Demoralize Employees thread) is because they used TFS, actually.

    @FrostCat said:

    Either find a job where they don't use the tool you don't like, or learn to use it the way it's intended to be used, even though you're afraid of CLI.

    Based on this conversation, I'm not sure anybody understands "how it's intended to be used".


  • I survived the hour long Uno hand

    @blakeyrat said:

    if the spec says, "the 'save' button should delete all the user's files and also kick their dog", and the save button does exactly what it says, that's not a bug?

    As a QA person: yeah, basically. Insisting that the spec is wrong just gets everyone mad at you. In theory you can file defects against the spec if the spec is going to lead to problems, but in practice, people just get pissy.


  • Discourse touched me in a no-no place

    @Yamikuronue said:

    What is a defect? When the system does not perform as expected.

    Expected by whom? The people who use it every day, and are arguing with Blakey? Or Blakey, who doesn't want to use it the way as it is?

    I'm not even necessarily disagreeing with him about the underlying issue. It seems kinda screwy to me, but I think we can all agree his boss' dislike of "extra" commits is TRWTF.

    If this causes him so much heartburn he should quit and find a job with a company that uses TeamSource (or whatever the VS CVS is). If it's not such a big deal, he should consider just using it the way it's supposed to be used. Or perhaps he just likes to stir up trouble on for--oh, wait.

    Anyway, back to responding to you, if it doesn't work as expected by him, and he asks someone else wht's up, and they say, "no, that's how it is supposed to work", guess what, it's not a bug. He can call it one until he starts another flamewar here if he wants, but he's still wrong, because his shoulder aliens have him confused about what the word "bug" means.


  • I survived the hour long Uno hand

    @FrostCat said:

    Expected by whom?

    That's literally the point of the rest of the post you quoted.



  • @Kian said:

    In particular, the "one branch per ticket" rule.

    Huh? That's not a thing, and I'm not sure where you got that idea.

    Each branch has to link to a ticket, but a single ticket can have X branches.

    @Kian said:

    They can still demand that each ticket have one branch, but if you can branch off of your branch that would solve most of your problems.

    No it wouldn't; because there's still no GUI to do this and I'm sure as FUCK not using Vi.

    What would solve this problem is Git not being an irredeemable piece of broken shit.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    So if the spec says, "the 'save' button should delete all the user's files and also kick their dog", and the save button does exactly what it says, that's not a bug?

    Yes. That's a bad spec, you big dummy.

    A bug is when the spec says the save button should save the user's files and it doesn't.

    I know you're not as simple as you pretend.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Based on this conversation, I'm not sure anybody understands "how it's intended to be used".

    Ha! Rest assured, Torvalds could probably "enlighten" you on that point.


  • Discourse touched me in a no-no place

    @Yamikuronue said:

    That's literally the point of the rest of the post you quoted.

    I'm gonna go all shoulder alien here about your use of terms like oracle.

    Having said that, I'll allow that a person who sees unexpected behavior can claim something is a bug, but when he's informed by someone else who actually knows that no, that's what it's supposed to do, it's no longer something you can reasonably call a bug, as you yourself agreed, in a later post. At that point it's "I don't like how this works". There's nothing necessarily wrong with that, but use the right damn term. Unless you're trying to stir up shit and start flamewar--oh, right.



  • @FrostCat said:

    but I think we can all agree his boss' dislike of "extra" commits is TRWTF.

    I don't agree with that, and I have no idea what post of mine in this thread could possibly lead you to that conclusion.

    I posted this because I'd like to follow his recommendation, because I also think it's a good idea. If I had disagreed with it, why would I have asked how to do it?

    I just naively assumed that there was a solution to this problem, since it'd bound to affect a hell of a lot more people than just our company.

    @FrostCat said:

    Yes. That's a bad spec, you big dummy.

    A bug is when the spec says the save button should save the user's files and it doesn't.

    So the user's expectation isn't taken into-effect at all at your company? Christ.

    @FrostCat said:

    Ha! Rest assured, Torvalds could probably "enlighten" you on that point.

    Torvalds seems like a pretty sharp guy, he's just surrounded by morons. He'd probably be the first one to say, "whoa, Git? Doesn't fit your workflow at all. Try BitLocker, I was happy with them for a lot of years."



  • @blakeyrat said:

    Huh? That's not a thing, and I'm not sure where you got that idea.

    Ah, my bad. I got confused by this:
    @blakeyrat said:
    Atlassian Stash doesn't allow that; every commit has to be attached to a Jira ticket.

    But then, what I proposed should work, shouldn't it? I mean, you have a GUI for making pull requests, and a tickbox for turning that request into a single commit. So do that, from the temporary branch into your real branch. Then make the pull request from the real branch with just the "real" commits.

    I don't know what your gui looks like, I'm just going from what you described of your workflow in this thread.


  • :belt_onion:

    @blakeyrat said:

    So the user's expectation isn't taken into-effect at all at your company? Christ.

    I believe the original user for this product was the same one who both wrote the spec and wrote the actual product. So it's not a bug unless Torvalds says it is... (Hint: It's not a bug.)


  • Discourse touched me in a no-no place

    @blakeyrat said:

    I don't agree with that, and I have no idea what post of mine in this thread could possibly lead you to that conclusion.

    Meh. I don't see what the big deal is either way, but "I don't like the number of commits" strikes me as a silly criticism. Of course, I'm also used to working on systems that get regularly backed up so I don't feel the need to do otherwise-superfluous end-of-day commits.

    @blakeyrat said:

    So the user's expectation isn't taken into-effect at all at your company? Christ.

    Aren't you the guy who usually rages about being unable to leap to conclusions? Why don't you try not doing it here.

    If a user didn't like the way something worked, I would consider changing it, but I wouldn't call it a bug fix--and I do, in fact, push back on that. I have a cow-orker who, when customers call about app behavior not being what they thought it might be, will call it a bug and say "oh, we'll get the developers to fix it." I push back on that because that attitudes leads to the customer thinking they're using a crappy product. Newsflash: you can tell people the right way to use something without saying "you're doing it wrong."

    @blakeyrat said:

    Torvalds seems like a pretty sharp guy

    I was just making a joke there.


  • :belt_onion:

    @blakeyrat said:

    I don't agree with that, and I have no idea what post of mine in this thread could possibly lead you to that conclusion.

    I posted this because I'd like to follow his recommendation, because I also think it's a good idea. If I had disagreed with it, why would I have asked how to do it?

    Then both of you are TRWTF. His suggestion is stupid and USING THE TOOL WRONG.



  • What kind of crazy person would complain about extra detail?

    Unnecessary detail is just noise.


Log in to reply