|
That's fair but we're still not at the point where we are able to do feature-flagging, so we're really just dealing with the cards we've been dealt. We have different environment variables in each build that we can't expose in the client, since this is all open-source.
|
#
?
Apr 19, 2019 00:54
|
|
|
|
| # ? May 30, 2024 19:53 |
|
|
Grump posted:That's fair but we're still not at the point where we are able to do feature-flagging, so we're really just dealing with the cards we've been dealt. "feature toggling" is another word for "an if statement". There's nothing to be "ready" for. Your continuous delivery solution or configuration management software should set environment variables, not your build process. Solving these problems is better than regressing to a horrible, antiqued branching model.
|
|
#
?
Apr 19, 2019 01:13
|
|
|
https://nvie.com/posts/a-successful-git-branching-model/ This is what I modeled several successful CI/CD pipelines off of. You don't have to follow it one for one, but it's a good baseline for making sure all your edge cases are handled.
|
|
#
?
Apr 19, 2019 15:54
|
|
|
poemdexter posted:https://nvie.com/posts/a-successful-git-branching-model/ I've done the same. The biggest challenge is teams where everything else about their development process is broken, but they don't want to address any of the cultural or technical issues because "it's always worked fine before!"
|
|
#
?
Apr 19, 2019 16:02
|
|
|
I'm trying to set up gitlab-runner to run locally in the same way that it runs on Gitlab CI. This is easy in general except when you get into more complicated pipelines that rely on environment variables set by GitLab CI. So, first question, asking to make sure this isn't an X/Y problem: does anyone know if there's a way to get gitlab-runner to set these automatically? Assuming not, what I came in here to ask, is what is the git command to get CI_GIT_COMMIT_REF_SLUG? It's "The branch or tag name for which project is built", slugified. The slugified part we can do with sed but is there a straightforward way to get the current tag or branch name without writing an elaborate function? Edit: just found this and ugh 
SurgicalOntologist fucked around with this message at 15:58 on Apr 25, 2019 |
|
#
?
Apr 25, 2019 14:26
|
|
|
git rev-parse --short HEAD will get you the current branch/tag. The option name might be different, phone posting and the man page of big.
|
|
#
?
Apr 25, 2019 19:50
|
|
|
Thanks, that's not it exactly but looks like rev-parse is the man page I needed at least.
|
|
#
?
Apr 26, 2019 09:28
|
|
|
What's the best practice for incorporating a third party github repo as part of my own repo? I'm using and modifying libraries from an actively developed open source project.
|
|
#
?
May 3, 2019 00:28
|
|
|
shrike82 posted:What's the best practice for incorporating a third party github repo as part of my own repo? Submodule?
|
|
#
?
May 3, 2019 00:40
|
|
|
1. Don't 2. if you must: fork the repo, include it in your own repo as a subtree. Keep your changes to their own commits in the fork, and do regular merges of the upstream or face potentially nightmarish merges when you find yourself needing to update.
|
|
#
?
May 3, 2019 00:49
|
|
|
Alternately, try to get your changes into the main repo.
|
|
#
?
May 3, 2019 02:17
|
|
|
Don't fork it unless you'll be making forked changes. Best to just pull in the appropriate RELEASE or STABLE branch into your build pipeline.
|
|
#
?
May 5, 2019 20:02
|
|
|
In the Github WebUI when you look at a branch, you can see how many commits ahead it is of master, and if you go through the pull request UI (even if you don't actually submit it) Github will tell you what files are in your branch compared to master. It won't include changes in master that haven't been introduced into your branch. As far as I can tell, I can use this git command to get that same data git diff --name-only origin/master... My understanding is that this is trip dot notation shows you every change starting with the first thing and ending at the last thing, or at your current point if you leave it blank. I can reverse it and do ...origin/master if I wanna see ways I'm behind master as well. When a pull request is merged Github will also tell you what changed when the PR was merged, and among other things will send that data in a webhook if you have that turned on. I think in plain language it's giving you all the files that have changed between this commit and the previous commit to the same branch (so generally from previous master to current master). What command can I run to find that?
|
|
#
?
Jun 9, 2019 20:25
|
|
|
Well I think I answered my own question... When you've got the current master checked out (or any branch for that matter), I think you can find out what changed in it compared to to the last commit to the branch with git diff --name-only HEAD~1..HEAD. These seems to work both when your PR merged in all commits from the branch and when a squash & merge was done. Not sure that it matters but this works for me where I'm checking out the commit hash of a branch and not just checking out the branch, which is what Azure Devops (and presumably other CI systems) do. So even though HEAD points to a commit and not a branch it still seems to know branch that commit is in to be able to get the previous commits from that branch to do the diff. Also apparently HEAD~1 is the same as HEAD~ is the same has HEAD^ is the same as HEAD^1 but I'll be damned if I can understand why. FISHMANPET fucked around with this message at 04:25 on Jun 10, 2019 |
|
#
?
Jun 10, 2019 03:31
|
|
|
~1, ~2, ~3 mean parent, grandparent, great-grandparent, etc. But commits can have more than one parent, like when you're merging. ~ always picks the first parent. ^1, ^2, ^3 mean first parent of this commit, second parent of this commit, third parent of this commit, etc. So they are only the same when the number is exactly 1. And if you omit the number then it assumes 1.
|
|
#
?
Jun 10, 2019 05:32
|
|
|
So I think HEAD^! is another useful shortcut such that if you run git diff HEAD^! you'll only get changes from the current commit, which is probably generally the same as git diff HEAD~...HEAD but not exactly the same? I looked a little closer at some webhook data and I'm fairly certain it's doing HEAD~..HEAD based on this snippet:code:This quest is actually two fold. First, figure out what changed when code is merged into master after the fact or predict what will be changed (solved by HEAD~...HEAD and origin/master...HEAD). The second is I'm working on a Powershell project called BuildHelpers that has some little helper functions that are useful when you're inside a build pipeline. One of them is for getting the set of files that has changed in a commit, and it does it by doing git diff-tree --no-commit-id --name-only -r HEAD which as I've dug in is not a very useful command. By default you won't get anything from merge commits. It's basically only useful if you go from one revision in a branch to the next revision in that same branch, and will only tell you what changed in that last revision. But in an attempt to fix this and make it as backwards compatible as possible, I'm trying to find a somewhat equivalent command using git diff. I think the current behavior is so pointless to be called a bug, but I think HEAD^! is enough to basically get a functional equivalent.
|
|
#
?
Jun 11, 2019 00:19
|
|
|
Why not use the actual commit hashes (before+after) from the webhook?
|
|
#
?
Jun 11, 2019 00:43
|
|
|
In my case I won't have the web hook. We currently have a process where the got commit fires off a web hook to an Azure Automation runbook that downloads files and deploys them based on what changed. I'm replacing this whole workflow with Azure Devops where I don't have access to that web hook data so I have to figure it out from git. Additionally, I want a "preview" of what the changes will be before a commit is made to master or even a PR so changed filed can be deployed to a test environment for testing. Since each file takes about a minute to deploy and we have 30 or 40 we can't just deploy every file every time.
|
|
#
?
Jun 11, 2019 03:34
|
|
|
In a p4 streams world, is there an equivalent to git's 'git branch --no-color -r --no-merge' I'm looking for streams/branches that were created, had commits to them, but weren't copied up back to their source. Edit found unpublished command p4 interchanges -S that does what I needed Hughlander fucked around with this message at 23:45 on Nov 7, 2019 |
|
#
?
Nov 7, 2019 22:29
|
|
|
Question. I had a laptop break while I was doing something that was not committed, and it went in for repairs for about a week. I had commits to master in the meanwhile from a different machine. Now I have gotten back my laptop, but there were some things I wanted to keep on it, but which would conflict with work I did in the past week. In order to try to preserve both, I created a branch on my laptop, but I think in the process I screwed something up, and what I ended up with was a commit that contained my old work, and overrode everything I did in the past week completely. I'm the only person working on this project and it's not really a "production" thing yet, so as long as both versions of the code base are on github, I don't really care that much about the particulars of how they are stored. Because of this I decided to just do git reset --hard [commit hash] for the commit hash that I want to be the current master. But now I get this error: To https://github.com/bbrener1/rusty_lumberjack ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'https://github.com/bbrener1/rusty_lumberjack' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. Help?
|
|
#
?
Dec 3, 2019 04:10
|
|
|
On your laptop, what does the actual commit look like? Does it contain your changes from the laptop, and also revert the changes you made elsewhere; or does it contain the changes from the laptop, and just happens to be built on top of master as it was a week ago?
|
|
#
?
Dec 3, 2019 04:29
|
|
|
When I do checkout [thing I want] the local repo on the laptop looks like [thing I want] I just want to convince github that this is the new master.
|
|
#
?
Dec 3, 2019 04:39
|
|
|
I guess you could just rewrite history on github and make it look exactly like what your local repository looks like. That's almost certainly not what you actually want to do though. Git doesn't really care about what your directory looks like, it cares about what your commits look like. It's incredibly difficult to divine what your issue is if you only tell me what your directory looks like and dodge the question when I ask what your commits look like.
|
|
#
?
Dec 3, 2019 05:54
|
|
|
Eh, close enough to fixed, instead of git push I should have been doing git push -f origin master
|
|
#
?
Dec 3, 2019 06:58
|
|
|
Having some trouble understanding how to best handle pull requests on GitHub. We have a master branch and a develop branch, as usual, and I want the general workflow to be as follows: 1. Branch from dev 2. Do your work 3. Create pull request for your branch to merge into dev 4. Pull request is merged as a squashed commit 5. When ready, dev's commits are merged to master According to GitHub's documentation, step 5 should perform a fast-forward merge of the single commit onto master, without a merge commit: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request posted:Pull requests are merged using the --no-ff option, except for pull requests with squashed or rebased commits, which are merged using the fast-forward option. But no matter what, when I do this I end up with a merge commit on master and so now dev says that it is 1 commit behind master. How can I get GitHub to perform fast forward merges?
|
|
#
?
Dec 9, 2019 03:01
|
|
|
So I think maybe you're reading the quoted part such that you believe that how the commit was merged into dev will impact how it merges into master, but I think it's just saying how the merge into master will behave based on how you merge it. I don't fully understand the ff vs no-ff action but I think if you're always merging a single commit from dev into master you want to merge all commits, because squash and merge will make a new commit, which causes dev to be "behind" master
|
|
#
?
Dec 9, 2019 04:30
|
|
|
FISHMANPET posted:So I think maybe you're reading the quoted part such that you believe that how the commit was merged into dev will impact how it merges into master, but I think it's just saying how the merge into master will behave based on how you merge it. I don't fully understand the ff vs no-ff action but I think if you're always merging a single commit from dev into master you want to merge all commits, because squash and merge will make a new commit, which causes dev to be "behind" master Ah k, so use the rebase-then-merge option? That sounds about right actually.
|
|
#
?
Dec 9, 2019 05:13
|
|
|
I think you're fine to continue doing rebase for merges into dev, so that each feature that goes into dev is a single commit, then to merge that single commit into master and have them be identical, merge all commits into master (which will just be your single commit). Otherwise rebase and merge will make a new commit (I assume it does this even if there's a single commit but I don't think I've tried that) with a new hash that will be in master but not dev, making dev "behind" master even though the code is identical.
|
|
#
?
Dec 9, 2019 06:26
|
|
|
Is master in a state where it can be fast-forwarded? If there have been commits to master that haven't been merged to develop, it can't fast-forward.
|
|
#
?
Dec 9, 2019 14:50
|
|
|
a hot gujju bhabhi posted:According to GitHub's documentation, step 5 should perform a fast-forward merge of the single commit onto master, without a merge commit: I think you're misinterpreting this. When it says "PRs with squashed or rebased commits", I believe (not verified but fairly certain) it means that the PR is configured to do a squash-merge or a rebase-merge. It doesn't mean "if the PR is full of commits that have been squashed/rebased". Basically, if github has multiple commits to merge, and the rebase merge strategy isn't selected, it will always do a no-ff. You can probably just switch to a rebase merge (which should be fundamentally identical, provided there's no hotfixes to master in the meantime that weren't already merged to dev), or use a non-pr-based master merge process, because AFAIK if you're doing a regular merge github will never allow you to do a fast-forward
|
|
#
?
Dec 10, 2019 17:34
|
|
|
New Yorp New Yorp posted:Is master in a state where it can be fast-forwarded? If there have been commits to master that haven't been merged to develop, it can't fast-forward. I've been testing this and set up a repo with dev directly rebased off of master, so they share the exact same commit history. At this stage, master and dev are shown to be equal in GitHub. But as soon as I try any kind of merge from dev to master, GitHub reports that they are now diverged. ChickenWing posted:I think you're misinterpreting this. When it says "PRs with squashed or rebased commits", I believe (not verified but fairly certain) it means that the PR is configured to do a squash-merge or a rebase-merge. It doesn't mean "if the PR is full of commits that have been squashed/rebased". Basically, if github has multiple commits to merge, and the rebase merge strategy isn't selected, it will always do a no-ff. Yeah I did consider this and experimented a bit. This is what I did:
Up to this point is always fine. It's getting that extra commit onto master that is giving me trouble. So by using resets and force pushes to continually reset my branches after each attempt, I tried all three options:
Is this just "the way it is" and I'm trying to do something crazy/stupid? I want my dev branch to never appear as though it is 'behind' master, and I want the number of commits ahead to actually correspond to commits I intend to merge. The biggest issue with the first two is that when another pull request is made, those commits are included in the pull request because GitHub thinks they haven't been merged yet.
|
|
#
?
Dec 10, 2019 22:49
|
|
|
a hot gujju bhabhi posted:Is this just "the way it is" and I'm trying to do something crazy/stupid? I want my dev branch to never appear as though it is 'behind' master, and I want the number of commits ahead to actually correspond to commits I intend to merge. If you're trying to update master by way of github PRs, then yes this is just "the way it is". Github is definitely opinionated in their use of git, and you're not going to get a ff merge. If you want dev to never be behind master, you'll have to manually merge+push.
|
|
#
?
Dec 11, 2019 16:35
|
|
|
ChickenWing posted:If you're trying to update master by way of github PRs, then yes this is just "the way it is". Github is definitely opinionated in their use of git, and you're not going to get a ff merge. If you want dev to never be behind master, you'll have to manually merge+push. Thanks, at least I know I'm not just doing something wrong. I knew this thread would be able to get me an answer haha.
|
|
#
?
Dec 11, 2019 21:45
|
|
|
Hoping this is an easy question. I've been made to understand that there are circumstances where a squash merge can cause problems, but I'm not clear on them. Here's what I want to do: I have a feature branch A off of master, and a feature branch B off A. Can I squash merge A into master without getting B into trouble? My instinct would be to merge master into B, then squash merge B into master, and I'm hoping it won't cause any bizarre conflicts and the pull request will show just the changes made in B. Will that work? VV Thank you, that makes sense. Opulent Ceremony fucked around with this message at 23:24 on Dec 12, 2019 |
|
#
?
Dec 12, 2019 22:10
|
|
|
If you squash merge A then B will still have all those old commits from A, even if you merge master in. But doing so should clean the diff up, the extra commits will "disappear" when b is then squash merged.
|
|
#
?
Dec 12, 2019 23:17
|
|
|
E:nm
Linear Zoetrope fucked around with this message at 14:46 on Dec 14, 2019 |
|
#
?
Dec 14, 2019 14:41
|
|
|
I guess this is a github specific question, but is there any way to annotate code in general to sort of give an "anchor" for links to go to? I want to have some markdown docs that link to specific functions or example usage in tests. I know you can link to specific lines of code in source, but would be really cool if there was something that could adapt to changing line numbers.
|
|
#
?
Dec 14, 2019 23:41
|
|
|
It probably exists, but I have no idea where it is or how maintained it is. It's probably no more than a weekend project to write if it doesn't exist, just grab a good parser library, ignore the fact you're parsing code and laser-focus on finding your tag structure and then find/replace matching tags in some markdown template file. E: Found this toy project on a quick search. Undocumented, unmaintained, was someone's learning project, but it does exist. E2: Heeey, actually github permalinks use the commit history to automatically update line numbers already. https://stackoverflow.com/questions/23821235/how-to-link-to-specific-line-number-on-github Linear Zoetrope fucked around with this message at 00:07 on Dec 15, 2019 |
|
#
?
Dec 15, 2019 00:02
|
|
|
Linear Zoetrope posted:It probably exists, but I have no idea where it is or how maintained it is. It's probably no more than a weekend project to write if it doesn't exist, just grab a good parser library, ignore the fact you're parsing code and laser-focus on finding your tag structure and then find/replace matching tags in some markdown template file. thanks for digging that up, thats useful to know about
|
|
#
?
Dec 15, 2019 01:22
|
|
|
|
| # ? May 30, 2024 19:53 |
|
|
Linear Zoetrope posted:E2: Heeey, actually github permalinks use the commit history to automatically update line numbers already. What I see there is talking about making a permalink, which always link to a specific commit. I don't think its capable of any kind of automatic updating of line numbers, Its just that the line numbers will never change for any given commit id. So when you update your source, the links you've made won't *break* or point to the wrong line, but will point to *outdated* code. Anyways I had a feeling what I was asking for probably wasn't possible, but thanks for looking into it.
|
|
#
?
Dec 15, 2019 03:03
|
|