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.
-
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?
-
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.
... 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.
-
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!
-
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.
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.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.
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.
-
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.
I don't care about any of the details.
Me neither.
Committing is my save button.
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.
- You can diff from the start and end of a branch, that's what matters, the diff. Git scales with diffs just fine.
- 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.
- It's safer having more than one copy of your work completed so far.
- 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.
- It gives more tools to code review. Hey I can see the way you think by reviewing your commits one at a time.
-
+∞
-
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.
You know what I did?
I said fuck off.
Problem solved.
Ugh. Well that's a solution. I guess. That's awful though.
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?
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?)
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".
undo your branch,
I don't know what this means. How do you "undo" a branch?
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".
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?
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 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.
-
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.
-
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...
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.
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?
-
A commit never leaves your system
This is his problem with just committing. Thus the entire thread. I can agree with him on this.
-
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
-
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.
-
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.
-
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...
-
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.
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.
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.
I mean, seems like he's just risk averse to losing code.
I await an explanation of how this is a bad thing.
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!
-
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.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
-
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.
-
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.
-
-
Belgium you Freud.
-
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
andA2
are a nice logical division, but after doingA1
I discover a bugB
that is blockingA2
, I would much rather see a rebased history ofB -> A1 -> A2
than a non-rebased history ofA1 -> B -> A2
or a merged history withA1 -> 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.
-
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
-
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.
-
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
-
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.
-
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.
-
Just saying.
Your screenshot is a good reminder why I don't use that tool. What terrible, misleading, confusing menu captions.
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!
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 requestaint_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.
-
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?
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.
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".
-
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.
-
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.
-
-
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.
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.
-
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.
-
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.
-
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.
-
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.
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.
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."
-
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.
-
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.)
-
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.
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."
Torvalds seems like a pretty sharp guy
I was just making a joke there.
-
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.