|
Plorkyeran posted:I've literally never seen anyone advocate this, so I'm pretty sure you're just misunderstanding people talking about doing WIP commits on a personal branch that you then rewrite into something sensible before mixing it with other peoples' code. It may be the case, if everyone is saying this then that must be it. Still, in a world that has merge --squash rewriting history is never needed. While is true that on a private, only you work on it, branch anything goes, why would you have one workflow in one instance and another workflow when working with other people when is trivially easy to just merge -squash and not carry the WIP baggage with you?
|
# ? Sep 20, 2018 20:33 |
|
|
# ? Jun 7, 2024 22:20 |
Working on an open source project recently, I've done a lot of interactive rebasing to squash a large number of WIP and "oops fix" commits into a smaller number of logically separate changesets. Each changeset is clean, compiles, breaks nothing in itself, and is more reviewable than getting a single large patch. It's not just a straight squash either, there's lots of reordering of changes and integrating fixes back into earlier commits. Hide the sausage making, present it like a perfectly executed waterfall plan.
|
|
# ? Sep 20, 2018 21:20 |
|
We've probably beat it into the ground, but I'm wondering if the intention is to pull --rebase origin master on top of your feature branch and do a force push when creating a PR so you have a "clean" PR. This was the preferred way to do it a long time ago, but public GitHub has had a one-click Squash and Merge button for a few years now, and you'd have to be running really old enterprise GitHub from like 2 years ago to not have it today. Who cares if there are a few WIP commits in a PR that disappear from the log when you merge? The downside to that approach is getting in the habit of force pushing on your feature branches all the time - the last two times I've had to rewrite git history is from people accidentally force pushing on master when trying to do the above workflow and just whipping through commands too quickly.
|
# ? Sep 20, 2018 21:21 |
|
Volguus posted:It may be the case, if everyone is saying this then that must be it. Still, in a world that has merge --squash rewriting history is never needed. While is true that on a private, only you work on it, branch anything goes, why would you have one workflow in one instance and another workflow when working with other people when is trivially easy to just merge -squash and not carry the WIP baggage with you? A PR may have multiple things that should remain distinct commits when merged, but there really isn't any value to preserving "oops fixed a typo" commit.
|
# ? Sep 20, 2018 22:35 |
|
Plorkyeran posted:A PR may have multiple things that should remain distinct commits when merged, but there really isn't any value to preserving "oops fixed a typo" commit. Perfect, then you merge --squash from multiple branches. you can go as deep as you want in this rabbit hole. The only time I had to use push --force was when Helicity posted:The downside to that approach is getting in the habit of force pushing on your feature branches all the time - the last two times I've had to rewrite git history is from people accidentally force pushing on master when trying to do the above workflow and just whipping through commands too quickly. Life is complicated enough, without additional help. Why make it hard when it can be easy? Why have a headache when I can sleep soundly? Why give myself work to do when I could be playing a game? Or work on poo poo that actually is important?
|
# ? Sep 21, 2018 00:12 |
|
Volguus posted:Perfect, then you merge --squash from multiple branches. you can go as deep as you want in this rabbit hole. The only time I had to use push --force was when Why would I assemble several different branches when I can just have several commits on one branch?
|
# ? Sep 21, 2018 00:15 |
|
Plorkyeran posted:Why would I assemble several different branches when I can just have several commits on one branch? Because branches are cheap in git and because you can't use --force because the powers that be (who know their poo poo) disabled such heresies.
|
# ? Sep 21, 2018 00:23 |
|
Nah, I think I'll continue to use git features rather than jumping through dumb hoops to achieve the same thing.
|
# ? Sep 21, 2018 00:44 |
|
Plorkyeran posted:Nah, I think I'll continue to use git features rather than jumping through dumb hoops to achieve the same thing. push --force is the nuclear option. Sure, it's nice to have it when poo poo hits the fan, required even, but just like the nuclear red button that US presidents have, exercise caution when using it. Preferably, never touch it. Use the better suited features for your goal.
|
# ? Sep 21, 2018 01:22 |
|
Oh, like push origin :dev/branch
|
# ? Sep 21, 2018 01:30 |
|
Volguus posted:push --force is the nuclear option. Sure, it's nice to have it when poo poo hits the fan, required even, but just like the nuclear red button that US presidents have, exercise caution when using it. Preferably, never touch it. Use the better suited features for your goal.
|
# ? Sep 21, 2018 02:28 |
|
Im really confused by this conversation. Why wouldnt it just follow the standard process of branching, dev changes, commit, merge? Ive done some full discards in a local branch but once i push, i fix and push again. This is all internal repos. What am i missing on this discussion?
|
# ? Sep 21, 2018 03:40 |
|
ultrafilter posted:The number of people who can handle web apps and the statistics side of things is small. That might be a good niche to explore in the hopes of finding a job that you like better than the one you might get if you just do web apps. Khorne fucked around with this message at 04:21 on Sep 21, 2018 |
# ? Sep 21, 2018 03:43 |
|
downout posted:Im really confused by this conversation. Why wouldnt it just follow the standard process of branching, dev changes, commit, merge? Ive done some full discards in a local branch but once i push, i fix and push again. This is all internal repos. What am i missing on this discussion? git is hard to use and even more confusing to talk about.
|
# ? Sep 21, 2018 03:48 |
|
pokeyman posted:git is hard to use and even more confusing to talk about. Exactly. And what's even more baffling, is that there are few simple rules that one should follow to not shoot oneself in the foot and make life simple and easy for everyone (including himself). And then there are still those that come and say: naah, i'll keep shooting, since not once in the last X years i blew my foot off. Which is technically correct i guess.
|
# ? Sep 21, 2018 04:05 |
|
Helicity posted:I'm not either, but it's interesting getting their point of view and reading the associated comments on HN. Things to think about. There were a looooot of comments on HN about how the use of a shared library between the microservices was the real problem. Saying things like if you have a shared dependency you are missing one of the fundamental requirements of a microservice which is independence. This smells to me, a shared library that doesn’t change much is fine. Doesn’t matter if it’s your code or third party code. I’ll even go further, a shared library that changes a bunch is fine too so long as the build/test/deploy complexity is well managed. In segment’s case the example they gave for what their shared lib did seemed fragile and hard to manage across the many data sources they had. It seemed like it would cause more problems than it would solve and maybe they should have thrown it away. quote:As time went on, we added over 50 new destinations, and that meant 50 new repos. To ease the burden of developing and maintaining these codebases, we created shared libraries to make common transforms and functionality, such as HTTP request handling, across our destinations easier and more uniform. Seems like the shared library amasses one off special cases for specific destinations and is incredibly fragile. What if two destinations have orthogonal approaches to representing a name? A more stable approach to creating a shared lib like this is to force conversion to a common format and put only the transformation logic in the shared lib like: code:
Dren fucked around with this message at 06:58 on Sep 21, 2018 |
# ? Sep 21, 2018 06:38 |
|
Volguus posted:Exactly. And what's even more baffling, is that there are few simple rules that one should follow to not shoot oneself in the foot and make life simple and easy for everyone (including himself). And then there are still those that come and say: naah, i'll keep shooting, since not once in the last X years i blew my foot off. Which is technically correct i guess. There are no simple rules when it comes to git, that’s what I was saying. I’m glad you’ve found a way to make it work for you though.
|
# ? Sep 21, 2018 12:30 |
|
pokeyman posted:There are no simple rules when it comes to git, that’s what I was saying. I’m glad you’ve found a way to make it work for you though. I've found that most developers like and understand git a lot better when they do two things: start using the CLI almost exclusively, and understand that it's a https://en.wikipedia.org/wiki/Directed_acyclic_graph at heart and what that means. There are simple rules, but git gives you a million ways to violate them. Dren posted:There were a looooot of comments on HN about how the use of a shared library between the microservices was the real problem. Saying things like if you have a shared dependency you are missing one of the fundamental requirements of a microservice which is independence. This smells to me, a shared library that doesnt change much is fine. Doesnt matter if its your code or third party code. This is exactly the problem I've struggled with the most using microservices, and why I'm currently a big fan of monorepo microservices until I need differently. You have 6 microservices that all use the same ThingyParser module/class/whatever. You confine ThingyParser to a single lib, you're wary of violating Open/Close and you're promoting DRY - you're a good developer(tm). Microservice 1 needs a new feature that the others don't care about, so you implement/test/PR/deploy the change in the lib and MS1. You keep doing this for a few weeks, and MS1 is quite a bit ahead in versions than MS2-6. Johnny got some new feature into MS4 that's kind of prod ready but not really and it's checked into master. A big bug is found and now MS1-6 all need to go to the latest version. Johnny's change has to piggyback along on the ride to prod even if it's not fully ready. That's also 7 things you need create PRs for and maybe even get change requests and releases scheduled for. You finally get through all that ceremony and process, go to a meeting, and there are new requirements for MS5-6 that are at odds with the others. You question the decisions you've made and why you're even a developer. You comfort yourself in the knowledge that in 10 years your code probably won't exist and in 50 years you'll probably be dead. quote:a shared library that changes a bunch is fine too so long as the build/test/deploy complexity is well managed.
|
# ? Sep 21, 2018 14:35 |
|
Helicity posted:This is exactly the problem I've struggled with the most using microservices, and why I'm currently a big fan of monorepo microservices until I need differently. Yep. If there's that many diverging changes to the shared lib then it's probably time to rethink what belongs in the shared lib and what belongs in each microservice. The shared lib is doing too many client specific tasks which is making it unstable. Refactor it to have a simpler, less likely to change set of functionality. Incidentally, this is not a microservice problem, the exact same problem with the exact same consequences happens in monoliths or any time there's a shared library.
|
# ? Sep 21, 2018 15:55 |
|
Helicity posted:The downside to that approach is getting in the habit of force pushing on your feature branches all the time - the last two times I've had to rewrite git history is from people accidentally force pushing on master when trying to do the above workflow and just whipping through commands too quickly. Why does master even accept force pushes from random people? Restrict that to an admin account that nobody uses day-to-day.
|
# ? Sep 21, 2018 16:43 |
|
That's what I'd do on larger, more non-heterogenous (experience-wise) teams in hindsight. On smaller teams where everyone is very experienced and you have a degree of trust, I feel like the balance of safety vs. productivity tips in favor of everyone being an org admin, but YMMV. If you can't fix your own force push mistakes, you shouldn't be an admin.
luchadornado fucked around with this message at 17:07 on Sep 21, 2018 |
# ? Sep 21, 2018 17:02 |
|
Grant people power only after they've butted up against at least a few cases where not having that power legitimately interfered with their workflows. At that point you've demonstrated that they do actually need it, and they've had a few chances to see how things are done properly (by having to get someone who's already been through the process to help them). And naturally, if you have someone coming in and saying "give me admin i need to force push" that is the last person that should be an administrator.
|
# ? Sep 21, 2018 17:11 |
|
TooMuchAbstraction posted:Grant people power only after they've butted up against at least a few cases where not having that power legitimately interfered with their workflows. At that point you've demonstrated that they do actually need it, and they've had a few chances to see how things are done properly (by having to get someone who's already been through the process to help them). Words of wisdom here. I'd just add that, in general, it's much easier to be strict early on and loosen up as you go than it is to move the other way. That's good advice for anyone in charge, whether you're teaching or administering a git repo.
|
# ? Sep 22, 2018 00:25 |
|
Helicity posted:I've found that most developers like and understand git a lot better when they do two things: start using the CLI almost exclusively, and understand that it's a https://en.wikipedia.org/wiki/Directed_acyclic_graph at heart and what that means. There are simple rules, but git gives you a million ways to violate them. I use a GUI almost exclusively because I like staring at the DAG all the time and having tools that make it clear that I'm directly manipulating it
|
# ? Sep 22, 2018 02:47 |
|
The git cli is exhibit A in the annals of awful interfaces. You can bang your ahead against the wall so much that it starts to "feel alright", it’s still a bad idea. Many guis simply replicate the awfulness but with a couple edges filed off, ensuring that someone who knows the cli can’t help someone struggling with the gui and vice versa. In conclusion, sourcetree.
|
# ? Sep 22, 2018 02:54 |
|
git koansquote:A UNIX programmer was working in the cubicle farms. As she saw Master Git traveling down the path, she ran to meet him.
|
# ? Sep 22, 2018 04:48 |
|
pokeyman posted:The git cli is exhibit A in the annals of awful interfaces. You can bang your ahead against the wall so much that it starts to "feel alright", it’s still a bad idea. Except sourcetree is garbage. I mean I use it, but I hate it. And I revert to the cli when doing anything more complicated than checkout, merge, etc.
|
# ? Sep 22, 2018 04:49 |
|
There are parts of git's CLI that are bad (some of the names are stupid) but I find that once I really understood git what seemed kind of befuddling before made sense in context. I used to train people on git and the most reliable way to give people a lightbulb moment was, consistently, to walk through exactly what git is. And git isn't a DAG. Git is a key-value store where a DAG is implemented in terms of conventions inside of items. The process of manually working through exactly how `git add` and `git commit` work is one that shines a lot of light on how git expects you to think, and that's valuable because the git CLI is designed in terms of its own domain rather than the expectations of random Ruby/Node/whoever developers using it Because GitHub Uses It. I quite like git and I stopped using SourceTree at all once I learned about `git log --graph`, but there was a place, for a while, for a tool that's safer for people who won't or can't invest in an understanding of their downstack tools. I feel similarly about understanding your stdlib, if not also your compiler; your core workflow tool, and git slots in as a workflow tool as much or more than a source control tool, is about as important. But Mercurial's more or less dead, so lol.
|
# ? Sep 22, 2018 07:27 |
|
"git is a DAG" is a gross oversimplification, but I was attempting to distill things down a bit since I already post enough words on this thread. Point being: if you understand what a DAG is, how git's history is laid out as a DAG, and how the CLI commands affect the graph you will be doing much better than the average developer. Sourcetree and friends are great for new developers or sometimes as a visual guide, but those tools usually end up being crutches in the long term, from my experience. On that note, from a skills/knowledge perspective what are the 2-3 biggest things a developer can do to go from being a junior or average developer to something better? I'm getting asked this more and more, and I've had mixed results on how the advice is received. An example is that I found picking up a second language (and third, etc.) to be incredibly helpful to my career, but some devs don't want to be polyglots, and I'm not convinced you need to be a polyglot to be a good developer.
|
# ? Sep 22, 2018 13:29 |
|
Ultimately I think it comes down to breadth of experience - when you encounter something new (which you will do all the time, regardless of experience), it's the difference between being totally in the dark, or being able to say "huh, it's kind of like this other thing that I'm familiar with", and being able to use your previous experience to guide you towards the best solution. This is why learning a new programming language is useful, even if you don't really intend to program in it long-term - it exposes you to concepts and idioms than are foreign to your original language, but that you can then give you new perspective when looking at problems. If learning a new programming language isn't really your thing, you could look for other ways to build breadth of experience - for example, if you're mainly writing business logic and snapping together ui components for a mobile application, try doing some work on a scalable distributed server, or write code to run on an embedded microcontroller, or write some high-performance graphics rendering code. Something that's different from what you've done in the past.
|
# ? Sep 22, 2018 14:08 |
|
Helicity posted:I'm getting asked this more and more, and I've had mixed results on how the advice is received. Some advice is just not pleasant and you can't expect it to be well-received. Experience is the answer and knowing more than one language can be an effective part of that even if you never have a job where you actually have to use the language.
|
# ? Sep 22, 2018 14:59 |
Thirding that having cursory knowledge in a large diversity of areas has been a great help to me. I spent hours upon hours just reading about random things I didn't have any immediate use for, and often barely understood, but it still helped me become aware of ideas and approaches I've later had use of and been better able to understand. However getting that kind of breadth of (shallow) knowledge might be hard if you don't have a natural curiosity, then it's just dreadful homework.
|
|
# ? Sep 22, 2018 16:15 |
|
Thermopyle posted:Some advice is just not pleasant and you can't expect it to be well-received. I think some people have an expectation that work will be like school where there is a right answer and someone will help guide them to it so the idea that learning must continue even when it doesn’t directly solve their work is unwelcome. Dren fucked around with this message at 17:46 on Sep 22, 2018 |
# ? Sep 22, 2018 17:35 |
|
Helicity posted:On that note, from a skills/knowledge perspective what are the 2-3 biggest things a developer can do to go from being a junior or average developer to something better? I'm getting asked this more and more, and I've had mixed results on how the advice is received. An example is that I found picking up a second language (and third, etc.) to be incredibly helpful to my career, but some devs don't want to be polyglots, and I'm not convinced you need to be a polyglot to be a good developer. People who can program can program in more than one language. That's not really a nice thing to say, but in my experience it's true. I think there's a pretty standard career progression these days, particularly at the early stages. Rent the Runway has a very nice explanation of their career ladder (text or table), and that might be a good source of ideas for things to work on. While it doesn't explicitly get into breadth and depth of knowledge, you can probably easily imagine how those become more important as you progress. I would say that breadth is the most important thing for the first couple levels, but once you become a senior engineer, you need to start specializing to keep moving up the ladder.
|
# ? Sep 22, 2018 17:35 |
|
ultrafilter posted:I think there's a pretty standard career progression these days, particularly at the early stages.
|
# ? Sep 22, 2018 18:57 |
|
Love Stole the Day posted:I think there are some things you're not taking into consideration when you say that. I wish I could agree with you but from my perspective it's exactly the same as it was during the recession. You're not talking about the same thing he's talking about. It being hard to find a job is not the same thing as there being a pretty standard progression when you do find a job. That being said...maybe programming is not the career for you? I don't want to kick you while you're down, but at some point it seems like someone will be doing you a favor by telling you to move on to something else. It feels like you've been posting about trying to find a job in this field for years, and you might be the only person I hear about with such problems. Thermopyle fucked around with this message at 19:52 on Sep 22, 2018 |
# ? Sep 22, 2018 19:49 |
|
Apologies for not being clearer - I was thinking along the lines of learn a second language, get good on the command line, really understand functional programming, etc. Things anyone can do while they're in the process of getting more experience that in retrospect are like "holy poo poo I leveled up when I did that". The interns and other new devs I end up interacting with are begging for advice that is beyond "get more experience". Just looking for more ideas outside of my own experience that I might be able to share with them.Love Stole the Day posted:I think there are some things you're not taking into consideration when you say that. I wish I could agree with you but from my perspective it's exactly the same as it was during the recession. Do you live in a rural swamp or have a swastika tattoo on your forehead? Even during the recession, developers had a pretty easy go of it. edit: VVV I'll go check it out luchadornado fucked around with this message at 20:46 on Sep 22, 2018 |
# ? Sep 22, 2018 20:39 |
|
Helicity posted:Do you live in a rural swamp or have a swastika tattoo on your forehead? Even during the recession, developers had a pretty easy go of it.
|
# ? Sep 22, 2018 20:46 |
|
You could suggest programming challenges like capture the flag games or project euler. Maybe find some sort of reading list to get them engaged with. Basically like “here are things you can look at to give you food for thought”.
|
# ? Sep 22, 2018 21:50 |
|
|
# ? Jun 7, 2024 22:20 |
|
Helicity posted:Apologies for not being clearer - I was thinking along the lines of learn a second language, get good on the command line, really understand functional programming, etc. Things anyone can do while they're in the process of getting more experience that in retrospect are like "holy poo poo I leveled up when I did that". The interns and other new devs I end up interacting with are begging for advice that is beyond "get more experience". Just looking for more ideas outside of my own experience that I might be able to share with them. It's hard to give really specific advice because what somebody needs to do to level up depends a lot on what they've already done. That said, there are some common things that can be helpful:
|
# ? Sep 22, 2018 22:41 |