Git/Atlassian Stash - how do combine commits before making a PR?
-
The problem is, with Git, there's no way to secure code on the server without creating a commit message! What a terrible design.
Oh totally. Much better to be able to change things without a trace.
Also I need to wait 2+ hours per clone for them to download.
Dang...more evidence that your company's workflow is screwed up. You can't even locally clone something?
Filed Under: No doubt
'd, but too funny
-
I think that's the oh-so-cute term Git uses for what I want to do, but, again, it only works locally. Once you've pushed to the server, you're sunk. But if you don't push, and your laptop HD dies, you're also sunk. I don't like lose-lose situations.
Does your company not have a remote backup system set up for your laptop?
-
Our network drive is backed up of course, and I could maybe do dev from it, but then I wouldn't be able to work offline. Which is the only reason to use git in the first place.
What's your plan to protect your code from a meteor strike during a coding session?
-
I hear tell it's possible to freeze oxygen, then stab yourself in the eye with it. I imagine that would put any meteor-related coding session difficulties rapidly into perspective.
-
Oh, yeah, because unless you stabbed the hard drive, first, teh codez are still there, safe and sound.
-
But what if you accidentally slipped, and this happened?
https://www.youtube.com/watch?v=h9ybp6_jvVY&t=36s
-
But what if you accidentally slipped, and this happened?
You make a good case for how git is ruining my life.
-
But what if you accidentally slipped, and this happened?
What a boring workplace, and so many things you have to slip on for the destruction to happen...
AMS-500HD Hard Drive Shredder by Ameri-Shred – [00:21..01:59] 01:59
— AmeriShred
-
1) None of the Git clients I'm using supporting the "stash" command (meaning, I have to make a junk commit just to switch branches, since any given day I'm juggling 2-4 different branches)
- SourceTree actually does have stash support. You might have an ancient version or you might not look carefully enough. That's a half of your problem.
2) The need to check-in code at the end of each day so it'll be secure if my laptop gets run over by a bus (meaning, there's a lot of "work in progress" commits due to this)
2) You cannot juggle remote history at your whim (and mind you, all other VCSes have this problem too, because it would cause weird problems for all others working on your thing). However: if there's so much concern about code integrity, I would be given a workstation by my boss that's left on the company's premises when you leave work.Okay, I understand that you still want to run your airliner upside down, 'cause neither you nor your boss are gonna budge in.
How about: you do your commits to your "work" branch, after stabilizing, just before a PR, you make another branch which you actually "rebase" before pushing? Like, having a "draft" branch and "PR" branch?
-
1) SourceTree actually does have stash support. You might have an ancient version or you might not look carefully enough. That's a half of your problem.
ISTR SourceTree not being a preferred Git tool because it's awful or something. I dunno, I don't use Git
-
STR SourceTree not being a preferred Git tool because it's awful or something. I dunno, I don't use Git
It does not exist for Linux and that might be the reason.On OS X it's quite awesome and has well designed features. Haven't seen it on Windows but I speculate it's also pretty awesome there.
One feature I tend to use is staging individual hunks — I'm a person of small, logically tied, concise commits, and sometimes I can get caught by momentum and do a few commits worth of work. I don't think there's an easy way to do it without a GUI of any sort. And I have never seen this implemented elsewhere.
-
One feature I tend to use is staging individual hunks — I'm a person of small, logically tied, concise commits, and sometimes I can get caught by momentum and do a few commits worth of work. I don't think there's an easy way to do it without a GUI of any sort. And I have never seen this implemented elsewhere.
git add -p(orgit add --interactivefor a bit more... interactiveness).
-
Or the default, no-frills Windows git GUI that comes with a default Windows git install.
-
Or the default, no-frills Windows git GUI that comes with a default Windows git install.
My solution is according to spec:
do it without a GUI of any sort
-
It can be done on the command line as in @OffByOne's post, but I prefer GitX on OS X right now.
-
Ugh, that thing is just as intuitive as the command line, in which case I'd take the latter because its switches are at least documented.
If we move the goalposts then I prefer
git-cola, the only downside is that they didn't build a real git blame or gitk alternative yet.
-
What seems the most odd to me is why is it so critically important to backup a couple of hours' worth of half-done work that you have to redo half of the assumptions in your source control system to get it to do it? That couple hours of half-done work is basically never so brilliant or important that it will make a meaningful contribution to your replacement picking up where you left off if you happen to get hit by a train. Why not use Git like it (or any other source control system) is meant to be used, and only commit and push cleaned-up, refactored, documented, commented, and test-supported code that actually does something useful?
If it's so critically important to not ever lose a couple of hours of your work (or more likely, somebody thinks it is), then use a tool that's made to do up-to-the-minute syncing to an off-site remote, like Google Drive, Dropbox, etc. Or just work remotely.
-
only commit and push cleaned-up, refactored, documented, commented, and test-supported code that actually does something useful?
For many developers, even reaching cleaned-up and test-supported means thirty seconds before it's due.
I used to hate getting the first peek at code when it's already late. This would happen:
Manager: Bob, is feature X done yet?
Bob: Just finished it, I'll check it in.
Manager: Good, I'll get the QA team to jump on it.
Me: Hold on... bob, you made a second config file with a different format from the current one, you tightly coupled these components together, and you made a breaking change to a shared library that's used by a project with almost no unit tests.
Manager: But, we're late. Let it go.From that day on, everyone now knows that if you want to bypass code review, just hold your code until the last minute. Code reviews then cease to happen.
-
Sorry, thought it was a blakeyrant so command-line is never acceptable!
-
No offense taken
I wasn't replying to Blakey or I would have not given a command line only solution.
I don't have anything to say about Blakey's original problem that hasn't been said already:
- Don't (ab)use the VCS as a backup sytem, but use a proper backup system instead. A VCS is for versioning programs and ideally every commit should compile. That may be not the case when committing at the end of the day.
- Create 2 branches per ticket:
- A "work in progress" branch that is private-by-convention (even though it will be pushed to the central repository at the end of the day, so someone else *could* pull it, but they shouldn't). Branch names can contain `/` characters. I find that very clear. You could name your work in progress branches `wip/bugfix-1234` for example.
- A branch where the real fix will be committed when it's implemented, tested and polished.
Work on the WIP branch. Push it to the central repository at the end of the day, so your work is not lost to your employer if you have an unfortunate encounter with public transportation.
When you've finished your bugfix/feature/whatever, switch to the "real" branch. Do an interactive rebase from the WIP branch. You can now reorder and squash your commits and clean up their commit messages to your heart's content.
Push the "real" branch to the central server. Delete the WIP branch both locally and on the remote server: all the work is still in the "real" branch, so you don't destroy information.
Figuring out how to do that with the UI that's used is left as an exercise for the programmer.
None of these operations (creating branches, switching, interactive rebase, deleting (local and remote) branches) should be difficult with a UI that doesn't suck donkey balls.
-
Hear Hear. I think @B has found a way to troll us without even saying anything. We keep repeating the same good advice over and over again.
There is also this, from Atlassian's SourceTree GUI:
Which should work as intended -- even for @B.
-
Hear Hear. I think @B has found a way to troll us without even saying anything. We keep repeating the same good advice over and over again.
Well, actually™, I didn't see it as a trolling attempt. There were some misunderstandings on both sides. People assuming that Blakey can change his workflow however he pleases, while in reality his particular workflow is mandated by management.
Blakey not being entirely clear that there isn't a one-to-one mapping between tickets and branches. Every branch has to reference a ticket, but there can be more than 1 branch per ticket.
He never denied that, but it took some time before he explicitly stated that.There is also this, from Atlassian's SourceTree GUI:
Which should work as intended -- even for @B.
Not unless that button pushes the stashed commits to the central repo (which standard
git stashdoesn't do AFAIK). That was one of Blakey's requirements, so he doesn't lose work when his HD explodes.
-
Not unless that button pushes the stashed commits to the central repo (which standard git stash doesn't do AFAIK). That was one of Blakey's requirements, so he doesn't lose work when his HD explodes.
No, but it does solve the issue where he needs to switch branches to do some quick-fix. Unless he intends to run away mid-quick-fix and roll under a bus, that is.
-
[
git stash] does solve the issue where he needs to switch branches to do some quick-fix. Unless he intends to run away mid-quick-fix and roll under a bus, that is.True.
I'm not a big fan of
git stashmyself. I tend to end up with a stash with 10+ items. I don't stash big diffs (I'd rather commit then), so I usually find easier to redo the work that I've stashed than to pop my stash and figure out where exactly I was and what I was doing when I stashed.Like Blakey, I don't like keeping too much state in my head. Using a "throwaway" commit at least gives me the opportunity of writing a commit message where I can dump my mental state at the time of commit.
-
No, but it does solve the issue where he needs to switch branches to do some quick-fix. Unless he intends to run away mid-quick-fix and roll under a bus, that is.
Do you think it will improve his intestinal issues? Everything lately is "poop this" and "fart that." I'm a little concerned. We all know he has a thing about being Regular.
-
It's a small shift from his usual "fuck", so I guess it's a natural regression. He is probably just trying to widen his vocabulary.
-
In the interest of feeding the troll, I'd recommend this book:
-
I'll just leave this here:
GitHub - bartman/git-wip: help track git Work In Progress branches
help track git Work In Progress branches. Contribute to bartman/git-wip development by creating an account on GitHub.
-
Using a "throwaway" commit at least gives me the opportunity of writing a commit message where I can dump my mental state at the time of commit.
git stash save "mental dump goes here"
-
git stash save "mental dump goes here"
My mental dumps usually take more than one line. By the way, I'm not willing to jeff around with
\nand the like to get that (I don't even know if that would work for stashing).It's a good idea for mental state that can be expressed in a single line though. I'll try to remember your suggestion next time I could use it.
-
My mental dumps usually take more than one line
I may be pointing out the obvious here, but:
git stash save "multi line mental dump still goes here because you're using quotes around the message and don't need no stinkin' \n"I haven't done this so have no idea how it looks in
git stash list.
-
I may be pointing out the obvious here,
Yes. Yes you are. It's what I needed though
git stash save "multi line
mental dump
still goes here
because you're using quotes around the message
and don't need no stinkin' \n"
I haven't done this so have no idea how it looks in
git stash list.In the interest of SCIENCE (and to thank you for your obvious-outpointing in a way that's more useful than just a simple like):
offbyone@boxbyone:~/tmp/multiline_stash $ echo "foo" > a.txt offbyone@boxbyone:~/tmp/multiline_stash $ git stash save "multi line > mental dump > still goes here > because you're using quotes around the message > and don't need no stinkin' \n" Saved working directory and index state On master: multi line mental dump still goes here because you're using quotes around the message and don't need no stinkin' \n HEAD is now at 5bcb1ae Initial commit offbyone@boxbyone:~/tmp/multiline_stash $ git stash list stash@{0}: On master: multi line mental dump still goes here because you're using quotes around the message and don't need no stinkin' \n offbyone@boxbyone:~/tmp/multiline_stash $Good idea, but computer says nooooo...
EDIT: Oh fuck you Dicsourse and your disconsistent post preview/baking!
-
Thank you for doing that which I was too lazy to do. :)
-
Thank you for doing that which I was too lazy to do. :)
You're welcome. It's not like it took more than 2 minutes.
Getting the post to show correctly in Dicsourse on the other hand took 6 edits
Amazon.com