|
tak posted:Are the repos all public? Yes, I only have public repos.
|
#
?
Mar 9, 2017 02:16
|
|
|
|
| # ? May 30, 2024 21:26 |
|
|
EmmyOk posted:I'm graduating soon so I decided to start putting all my personal projects and things on GitHub so I can show them off to employers etc. The last few days whenever I commit anything be it edits to existing files or brand new files my GitHub website profile only lists me as having one contribution that day. I make multiple changes or add new programs and push them separately throughout the day and it still lists it as one contribution for the day. I'm the only person who contributes to my GitHub and every repository only has one branch. All the changes are made and new files added if I go and check the repos. 1. Do you have an email address set in your git that you are pushing up to github? Only ones that are in your email settings will actually show up on your profile as being made by you. 2. Only changes to your main branch of any repository will show up in your commit graph 3. You can contact support@github.com and they will be able to help you out since they can see exactly what is happening behind the scenes
|
|
#
?
Mar 9, 2017 02:56
|
|
|
I reckon I spend about 10% of my time at work fixing other people's Git problems. Does anyone else find this?
|
|
#
?
Mar 9, 2017 18:34
|
|
|
chippy posted:I reckon I spend about 10% of my time at work fixing other people's Git problems. Does anyone else find this? Some days, but definitely not overall. It helps that both teams I currently work in are crazy small.
|
|
#
?
Mar 9, 2017 20:30
|
|
|
I would recommend getting them on using sourcetree or some other git GUI if they are not already. I helped coworkers on git initially but after they understood using feature branches it was smooth sailing from there.
|
|
#
?
Mar 10, 2017 12:02
|
|
|
Actually almost all of them use SourceTree and a lot of the problems seem to stem from that - they just go around gleefully clicking buttons without a real understanding of what it's doing under the hood. I'm trying to wean them all onto the command line.
|
|
#
?
Mar 10, 2017 13:21
|
|
|
explaining how git fundamentally conceptually works would be a better path, but that requires wanting to learn it edit: just to clarify, whether you use a GUI or the CLI it's just an interface on top of the underlying concepts. git deservedly gets a lot of criticism for an inconsistent and poor CLI from a UI perspective, so just using the CLI isn't going to solve anything. comedyblissoption fucked around with this message at 14:32 on Mar 10, 2017 |
|
#
?
Mar 10, 2017 14:24
|
|
|
Yeah I get that. I've been trying to pair it with explaining the fundamentals but, as you point it, people need to want to learn. At the moment the approach seems to be 'plow in without thinking and call chippy if it fucks up'. I get that they're both just interfaces on top of the core mechanics, I've just found that those fundamentals seem to start sinking in more quickly once people start using the command line. Just seems to slow people down and force them to think about what they're doing a little more carefully. It doesn't help that most of the people I work with are fuckwits.
|
|
#
?
Mar 10, 2017 14:35
|
|
|
Munkeymon posted:Huh. Let's say I have an e-commerce site that's three solutions: front-end, back-end services and internal management tooling. They share a project containing communications APIs/DTOs and whatnot. Let's say we want code to flow from a Dev to a QA into a Live branch. What is TFS supposed to look like if the admin doesn't begin with the assumption that it's supposed to work just like SVN? There's a few different ways this could work, depending on how you deploy your systems. Having worked in a place that branched by environment for a long time, I've seen a lot of ways it gets hosed up. If you're strictly .net, take advantage of config transforms as much as you can, and use them in your build processes. We tend to have integrations with other systems and some host configurations in our projects, so we throw those into a configuration folder that does branch by environment. Keeping those environment-only settings in a separate structure helps separate config from application code. Finally, we have releases that are branched off the main trunk. These are our shipped versions. Here's an anonymized version of what we have in our cleaned up tfs projects. Like I said in the other thread, we've got a ton of old poo poo that's never been well organized. 
|
|
#
?
Mar 11, 2017 22:32
|
|
|
You shouldn't branch per environment, anyway. You should integrate from development branches to your trunk frequently and isolate features in active development behind feature flags so you can continue to ship even if a new feature fails QA. You build out of trunk and deploy the result of that build progressively through a pipeline of environments with appropriate approval gates in place. Environment-specific configuration should come out of a configuration management system at deployment time.
|
|
#
?
Mar 11, 2017 23:44
|
|
|
New Yorp New Yorp posted:You shouldn't branch per environment, anyway. You should integrate from development branches to your trunk frequently and isolate features in active development behind feature flags so you can continue to ship even if a new feature fails QA. You build out of trunk and deploy the result of that build progressively through a pipeline of environments with appropriate approval gates in place. It's taken us 6 years to get to that for a small fraction of our systems.  My original plan was to have a single master git branch with tagged releases. Releases were originally handled with TeamCity, but we went with Microsoft's release manager. It's decent. I'd like to get more of our CMDB integrated into the system, but we're just not interested in that right now.
|
|
#
?
Mar 12, 2017 02:10
|
|
|
clockwork automaton posted:1. Do you have an email address set in your git that you are pushing up to github? Only ones that are in your email settings will actually show up on your profile as being made by you. I only use the one email address, the only recent change I made was changing my password but neither PC ever asked me to re-enter my login details. None of my repos have any branches except main. I guess I will try emailing them, thanks for the answer!
|
|
#
?
Mar 12, 2017 03:49
|
|
|
EmmyOk posted:I only use the one email address, the only recent change I made was changing my password but neither PC ever asked me to re-enter my login details. None of my repos have any branches except main. I guess I will try emailing them, thanks for the answer! Yeah, support@github.com should always be your goto with any struggles with github and for people who have feature requests or specific complaints all of those should be directed there (rather than at the twitter account).
|
|
#
?
Mar 12, 2017 23:31
|
|
|
Any suggestions on the least-poo poo lightweight CI system that integrates with raw git? I'm looking for "not a 15 GB docker container black box of mystery bullshit" which seems to be the default for this kind of thing. loving gitlab Using docker or some other containerization to isolate builds is a bonus though. Planning on installing/testing buildbot and trac-bitten this week, unless there's some other recommendations. I've got a pretty low tolerance for bullshit that can be replaced by cron and a shell script to run on new commits though. Edit: The main thing I'm looking for is to gate master behind a successful build/test run, since it's currently "please remember to run tests before pushing, they catch a lot of stupid errors" and I'd like to enforce it. Harik fucked around with this message at 09:23 on Mar 15, 2017 |
|
#
?
Mar 15, 2017 09:12
|
|
|
Harik posted:Planning on installing/testing buildbot and trac-bitten this week, unless there's some other recommendations. I've got a pretty low tolerance for bullshit that can be replaced by cron and a shell script to run on new commits though. I can't comment much on its Git integration, but I've been happy with Buildbot. I haven't played with the new v0.9 though, just the older uglier v0.8. What I can suggest is: resist the temptation to start out with cron, because it might seem easier at the start, but you'll get to a point where you're just re-implementing stuff that real CI tools have, or moving some complicated shell scripts over to a real CI tool, or just wishing you could have that shiny feature but you've made too big of a commitment to the current system to change. There's always more of a learning curve to figure out something like Buildbot, but it shouldn't be hard to find some trivial examples (hopefully right there in the documentation!).
|
|
#
?
Mar 15, 2017 11:02
|
|
|
Harik posted:Any suggestions on the least-poo poo lightweight CI system that integrates with raw git? I haven't used Buildbot but so far Bamboo is the best CI product I've used so far. Commercial product, but there's a trial and if it meets your needs it's well worth the $10 for the cheapest license (no remote build agents) as far as I'm concerned. Never used it to do builds inside a docker container but it should be doable I think. I've also used Jenkins and it has similar capabilities plus doesn't gate things like remote build agents, but it's a lot more painful to configure IMO. Any product you use is going to be fired off a commit hook in a very similar fashion. Here's Atlassian's script that ties into Bamboo and determines whether a commit merges to master (actually, anything in "protected_refs") and if so fires off a job to the server and checks whether it succeeds. Note you'll need to clone the whole "git-ci-hooks" repo because there's a couple scripts that define util functions. https://bitbucket.org/tpettersen/gi...le-view-default
|
|
#
?
Mar 15, 2017 15:34
|
|
|
Buttcoin purse posted:I can't comment much on its Git integration, but I've been happy with Buildbot. I haven't played with the new v0.9 though, just the older uglier v0.8. Took the comment the wrong way: It better do more than a simple cronjob and some shellscripts can accomplish. I don't really want to re-implement my own CI, I have enough to work on already. Thanks for the +1 to buildbot, I'll play with it first.
|
|
#
?
Mar 16, 2017 02:06
|
|
|
Harik posted:Edit: The main thing I'm looking for is to gate master behind a successful build/test run, since it's currently "please remember to run tests before pushing, they catch a lot of stupid errors" and I'd like to enforce it. We used team city for this and it worked well.
|
|
#
?
Mar 16, 2017 03:11
|
|
|
I don't know a huge amount about Jenkins, but it seems to me from using it a bit that you do all your configuration by clicking around in a web interface, whereas Buildbot is configured using Python code which you can easily check into your version control system. I certainly much prefer the latter option!
|
|
#
?
Mar 16, 2017 08:51
|
|
|
Your preference is the correct one. Luckily, they made a plugin for specifying your pipelines in text files, and another plugin that rebuilds the UI around that first plugin.
|
|
#
?
Mar 16, 2017 10:39
|
|
|
There's also a plugin that checks all config changes into a git repo for you. We had to disable it for some issues I think though and I forget the plugin name at the moment. But there are ways to track he Jenkins changes.
|
|
#
?
Mar 16, 2017 23:05
|
|
|
I'm working on migrating an SVN repo to Git for people that don't understand how source control works. It looks like instead of branching they just made copies of folders. Subgit can handle that situation for the most part, except for the fact that a bunch of their branches live within the trunk. So their structure is like this (yes, this is real): code:I was thinking of doing this, but I want to see if this sounds insane: - Import everything as-is, no branches - Copy Git repo ("Target"). Clean Target's history of everything except the trunk folders - For each of the branches, clean out everything except the branch - Add a remote to "Target" for each branch, create a branch in "Target" at the point at which the branch occurred, and rebase the remote onto the target branch. Ideally I'd fix the source branch folder structure to match up with the target branch folder structure, as well. Then the target repo wouldn't be literally gigabytes of redundant files. I know I'd miss the points at which the branches were merged, but I don't think that's too important as long as the commit history is there. I expect they are going to have significant adoption issues with Git given that they don't even understand how centralized version control works right now. New Yorp New Yorp fucked around with this message at 15:12 on Mar 20, 2017 |
|
#
?
Mar 20, 2017 15:05
|
|
|
New Yorp New Yorp posted:I was thinking of doing this, but I want to see if this sounds insane: It doesn't sound insane to me, I just don't get it - sorry, I'm getting confused between what's in the Subversion "branches" directory and the things that we know are actual "branches"  Also I'm probably not good enough at Git to get how to do things like this in it anyway.If it was me, I'd personally prefer to try to keep all the history by first making some Subversion repositories with the projects split out and rearranged as required. I found http://component-parts.blogspot.com/2013/02/rewriting-history-in-svn-repository.html which talks about how to do this sort of thing. I can't vouch for how well it would work though, I only skimmed it and never had to do SVN repository rewriting like that before, just heard about it.
|
|
#
?
Mar 21, 2017 11:03
|
|
|
Can't you do all the splitting while maintaining history fairly easily in git with, like, the subtree stuff or just some filter-branch work and some patience? I mean that'd be my preference because I don't know any svn.
|
|
#
?
Mar 22, 2017 12:35
|
|
|
I think I was overcomplicating it, I was able to unravel their pseudo-branching structure.
|
|
#
?
Mar 22, 2017 14:44
|
|
|
I was going to recommend letting the branches build out and reseting the empty master to whatever the trunk branch was. Master is purely convention in git it's not even a requirement.
|
|
#
?
Mar 22, 2017 18:53
|
|
|
Has anyone played around with pijul. I keep meaning to but then spending my free time on videogames or organizing my email instead.
Vanadium fucked around with this message at 08:02 on Mar 27, 2017 |
|
#
?
Mar 27, 2017 07:23
|
|
|
Vanadium posted:Has anyone played around with pijul. I keep meaning to but then spending my free time on videogames or organizing my email instead.
|
|
#
?
Mar 27, 2017 23:03
|
|
|
First time working with submodules at my new job, assume I'm doing everything wrong. First I ran code:code:code:
|
|
#
?
Apr 14, 2017 19:16
|
|
|
Looks like a permission problem on the server, your user account doesn't have read permissions on the directories hosting the submodules' repositories.
|
|
#
?
Apr 14, 2017 21:32
|
|
|
code:
|
|
#
?
Apr 25, 2017 20:23
|
|
|
Let's say I have my topic branch in git. I have merged the master into it a few times to keep up with it. I've now reached a point where I want to squash it and fire it to Gerrit. How do I do this without it getting pissy over the merges I had made?
|
|
#
?
May 8, 2017 19:45
|
|
|
Rocko Bonaparte posted:Let's say I have my topic branch in git. I have merged the master into it a few times to keep up with it. I've now reached a point where I want to squash it and fire it to Gerrit. How do I do this without it getting pissy over the merges I had made? `git rebase master` to clean up the history in that branch, I think you can squash it in the same command but can't look it up right now.
|
|
#
?
May 9, 2017 09:09
|
|
|
tak posted:`git rebase master` to clean up the history in that branch, I think you can squash it in the same command but can't look it up right now. There's at least two ways: - git checkout master; git merge --squash topic - git checkout topic; git rebase -i master; and then set all commits except the first to "s" or "f" rather than "p".
|
|
#
?
May 10, 2017 02:18
|
|
|
At any given time at work I have 3 projects max that I am working on. Would it be better to have a dev branch and test branch that all 3 projects live in or a branch for each project?
|
|
#
?
May 11, 2017 17:58
|
|
|
huhu posted:At any given time at work I have 3 projects max that I am working on. Would it be better to have a dev branch and test branch that all 3 projects live in or a branch for each project? Why are they in the same repository at all?
|
|
#
?
May 11, 2017 18:02
|
|
|
Thermopyle posted:Why are they in the same repository at all? There's a www/wsgi repo that houses all the web apps we work on. They're all internal tools. Not sure if that's actually a good answer.
|
|
#
?
May 11, 2017 18:10
|
|
|
As many branches as possible imo.
|
|
#
?
May 11, 2017 21:13
|
|
|
huhu posted:At any given time at work I have 3 projects max that I am working on. Would it be better to have a dev branch and test branch that all 3 projects live in or a branch for each project? Each project should almost certainly be in a different repository.
|
|
#
?
May 11, 2017 22:23
|
|
|
|
| # ? May 30, 2024 21:26 |
|
|
Each feature should live in its own branch. Each project is either its own repository, or a collection of repositories. You definitely shouldn't have multiple projects being worked on in the same branch. You wouldn't be able to deploy changes to one project without also deploying whatever half-finished changes you have to the others. The history would be super muddled with changes to each project inextricably intertwined, making things impossible to revert without also changing unrelated things in an entirely different program.
|
|
#
?
May 11, 2017 22:42
|
|
