|
Plorkyeran posted:git rebase -i B, delete the line for C, save and exit. It sounds like he wants to keep the changes. Step 3 in his example (diff between B and D) would include the changes in C. Instead of deleting the commit from the rebase UI he should squash (or fixup) it.
|
#
¿
Jan 14, 2014 17:29
|
|
|
|
| # ¿ May 14, 2024 21:03 |
|
|
oiseaux morts 1994 posted:Don't want to keep changes in C. But of course D would have them, I want what D changed but not C. Presumably interactive rebase as stated does that Then yeah, what Plorkyeran said. I was reading your step 3 as `git diff B D` which would have included the C changes.
|
|
#
¿
Jan 14, 2014 20:38
|
|
|
Doc Hawkins posted:I love rebase, but if anyone else has pulled this branch, you'd be better off using `git revert C` to make a new commit which cancels out whatever C did. Yeah, you should only rebase (or any kind of history changes) on "private" branches.
|
|
#
¿
Jan 14, 2014 22:48
|
|
|
Jethro posted:And even if git makes it easy to screw that up, I'm still not convinced that using dropbox instead of github (or whatever) makes much sense. If you make changes on machine A, sync them to dropbox, and then can't get to dropbox from machine B for whatever reason, it seems like it would be a pain in the rear end to merge any changes you do on machine B once you can get to dropbox, whereas doing that with an external repo is what a DVCS is for. Wasn't he talking about putting a repo in dropbox? A simple "private server" that only really works for one person.
|
|
#
¿
Jan 23, 2014 23:24
|
|
|
Strong Sauce posted:It seems a bit insane. Why not just use BitBucket if you don't want to pay, or GitHub if you're willing to pay $7/month for 5 repos? Seems like a lot of time better spent writing more apps. Setting up gitolite on a small VPS is incredibly simple. If you need anything more than what Gitolite offers (pull requests and such) there are open source offers (GitLab HQ) that work fairly well and can be simple to setup if you have experience with Rails. A half day of effort tops to save a 2-person shop $84/year (does Bitbucket's free plan allow you to share private repos? I thought it didn't...)
|
|
#
¿
Feb 14, 2014 17:45
|
|
|
wwb posted:Bitbucket gives you free private repos for up to 5 private users, you need to pay beyond that. I didn't realize you could have 5 users on the free accounts.
|
|
#
¿
Feb 14, 2014 21:44
|
|
|
Yeah, reset only touches tracked files. Untracked files are handled with clean (although its not restricted to untracked files).
|
|
#
¿
Feb 20, 2014 02:27
|
|
|
aerique posted:Who here is using Git in a larger organization with more than, say, 50 or 100 developers? Do you use something like GitLab for managing users and repositories? We have ~60 developers using Git in our organization. Currently we're on GitHub, but we have plans to move off to something else (maybe Stash, we already use Jira).
|
|
#
¿
Mar 12, 2014 18:27
|
|
|
NOTinuyasha posted:Bet it's a lot of fun when Github.com goes down for hours at a time, like yesterday. We use Github too but we're only three developers so our budget is tight, if we were any larger we'd totally rather have our own Gitlab server rather than be subject to Github's occasional but extremely annoying service problems. This was a problem for us when our deploy system simply checked out code from github.com on all 500+ of our servers. We build a slug on one box and ship it out to the rest now. Amazing how many problems that solved.
|
|
#
¿
Mar 13, 2014 06:47
|
|
|
Hughlander posted:How do you keep that up to date vs github? IE: I'm an engineer I push to github and want to see a build kicked off within seconds. Does kicking off the build start with the slug pulling from github then notifying the 500+ servers? We don't do continuous deployment yet, just integration tests. A deploy to all 500+ servers has a bit of process behind it... Sailor_Spoon posted:That's pretty much what we have. A push to github triggers a jenkins job which pulls from github, builds everything, then pushes (SCP, I think) everything out to each server. This relies on having the jenkins server be build identically to the production servers, but that's what puppet is for. Something similar to this. Any new PR (or changes to a PR) triggers a build on Jenkins for our testing platform, and when changes are ready for prod our team merges PRs into a release branch that also triggers a build. We then use an in-house tool to push the slug out to all of our servers (or a single facet, or a single server in each facet, or a percentage of servers, etc...). We plan on releasing the tool at some point to the public, but it's still changing a lot so thats some ways away yet  edit: Also, chef is the workhorse. If a new server spins up (EC2 auto scalers) it knows how to fetch the current production slug and install it. Once a server spins up Chef only does a few maintenance tasks (around user access and such).
|
|
#
¿
Mar 13, 2014 18:15
|
|
|
It looks like you're creating 2.5.1 as a branch and not a tag, though. Are you tagging it later on? I think if you have a branch and a tag with the same name it has issues with ambiguity when you try to checkout that ref.code:For your second question, you can merge in the tag if you have a multiple engineers working on the branch: code:code:1. Master is the "stable" branch. In your case this would be 2.5.0 at the start. 2. Develop is the "unstable" branch. New work for 2.6.0 should be merged here when completed. 3. When you need to make bug fixes for 2.5.x you create a branch based off of master (or the tag, but master should always be the latest stable tag), do your testing with this branch, etc... When you're done with the fixes and they are verified you can merge that branch back into master and tag as 2.5.1. 4. To get changes into develop you have two options: (1) rebase develop onto master. As people should not be working directly on this branch it should not disrupt peoples flows. If someone working on a feature requires the bugfix they can now rebase on develop. (2) simply merge it into develop. The downside of this now develop will have a merge commit at a later point than master. I personally like the first option under 4, but I think people have pretty varying opinions on this.
|
|
#
¿
Mar 27, 2014 20:31
|
|
|
hirvox posted:https://www.atlassian.com/git/tutorial/rewriting-git-history For someone who hasn't done a rebase before the concept can be a little strange. I like the verbage they use when you start: "First, rewinding head to replay your work on top of it...". Tells you exactly what rebase does.
|
|
#
¿
May 7, 2014 16:53
|
|
|
Marsol0 posted:The repo doesn't care. I guess github might, though. Seems silly to me. GitHub doesn't really care either. But if you remove a fork then it can no longer be a remote, so changing it to "unknown repository" makes sense.
|
|
#
¿
Sep 16, 2014 05:14
|
|
|
caiman posted:Newbie git question. Why does checking out a commit result in the "detached HEAD" state? If I do "git checkout . " my working directory simply gets changed to look just like the repo, so why doesn't "git checkout <sha>" simply make my working directory look like that commit? Why act like a new branch? http://gitolite.com/detached-head.html might be of some help. Specifically: quote:HEAD is, normally, a symbolic reference to [the tip of] a branch. For instance, if you do cat .git/HEAD on a brand new repository, you'll get back ref: refs/heads/master. When you add a commit, git actually updates 'master', because that's where HEAD points. You can see this by doing cat .git/refs/heads/master before and after making a commit. HEAD does not change (it's only a symbolic reference) but 'master' does.
|
|
#
¿
May 22, 2015 18:28
|
|
|
caiman posted:Thanks guys, that's the reasonable explanation I was looking for. The far left line is the branch you are on, all of the forking "branches" are just that: branches (demarcated by merge commits). The reason you can have multiple lines is multiple branches created at different points off the base tree. Oh, and each * is an actual commit, the dashed lines are just visual so you can follow.
|
|
#
¿
Jun 10, 2015 16:23
|
|
|
Seashell Salesman posted:Is there a way, in Git, to checkout the commit at the head of a branch (not by looking up the hash) so that you end up with detached head? Sometimes for bug fixes I want to just get to the head of a team branch and start committing stuff and create a branch for the fix later, and I'm sick of having to reset --hard my copy of the team branch afterwards. This workflow just works when I'm working off a tag instead of a branch so I feel like there is a way to do it without too much pain. git checkout -b new-branch-name shared-branch-name creates a new branch named "new-branch-name" with the same HEAD as "shared-branch-name". https://git-scm.com/docs/git-checkout
|
|
#
¿
Oct 16, 2015 20:15
|
|
|
Seashell Salesman posted:Put it another, maybe less confusing way, 'git checkout A' then 'git commit' will move me to the head of A, create a new commit, and then make A point to the new commit. I don't want A to point to the new commit, and I don't want to create a new branch or have to look up the hash for the head of A beforehand. I'm curious why you would even want to do this.
|
|
#
¿
Oct 17, 2015 18:11
|
|
|
fletcher posted:What's your favorite mergetool on linux? I've been using kdiff3, wondering if there's anything else I should check out. p4merge is amazingly good.
|
|
#
¿
Oct 21, 2015 01:44
|
|
|
Edison was a dick posted:Yeah, if you want to do sparse checkout, it's a per repository clone option, and you have to do it before checking out, so it's a PITA. When you check out part of a tree in SVN you don't get the entire repository, though. This method you still fetch *everything*, but the checkout will only be that sub-tree. Semantically it will look the same, but if the point is to save space or bandwidth this won't help.
|
|
#
¿
Oct 22, 2015 02:17
|
|
|
ToxicFrog posted:I delete the branches, but I don't know how universally true that is. I believe its all over the place. For example, some people in my company delete branches after merging; others leave them around for ever! I recently went through and pruned a bunch of merged branches and killed off ~8k of them. But it doesn't really matter with how cheap branches are if you have a decent scheme for naming them.
|
|
#
¿
Nov 11, 2015 00:32
|
|
|
22 Eargesplitten posted:Another question, can github be searched for file names or project names? I'd like to be able to link stuff in a github made for this account, but I don't want to make it easier to doxx me than it probably already is. I use my real name for my github repository name currently. They have a search mechanism. And if its public external search engines will find it, too.
|
|
#
¿
Feb 9, 2016 05:38
|
|
|
Lumpy posted:Because I'm a git idiot (gitiot?) you are saying that because I put the URL in to my push, the code went up, but the remote didn't sync because of it because a fetch never happened to my local. git fetch origin
|
|
#
¿
Mar 4, 2016 06:25
|
|
|
Ciaphas posted:git rebase master warnings-fixes You actually want git rebase origin/master, assuming the remote is named origin, while you have the warnings-fixes branch checked out. quote:will replay all of the commits uniquely reachable by warnings-fixes on top of where master currently is, and save them as new commits, correct? Yes. quote:Does anything in particular happen to the old commits in that branch? quote:Is this different if there's a remote-tracking or another local branch there before I do the rebase? quote:Will rebasing in this way interfere with anyone? Only if its a shared branch. If you rebase they will have to force reset their local copy of the branch instead of a simple pull. quote:My guess is "yes, this is what you want; they are brand new commits; the old ones are orphaned unless another branch, remote or otherwise, was at the head before you rebased; it won't interfere with anyone long as you've never pushed warnings-fixes". Is that about right? Heh, I read this last. Yeah, that's exactly it.
|
|
#
¿
Mar 12, 2016 02:15
|
|
|
ufarn posted:Is there a simple way to make gh-pages the default branch for your GitHub repo? I can't find a simple, canonical way to do it. https://github.com/ORG/REPO/settings/branches You should be able to select it there.
|
|
#
¿
Mar 22, 2016 21:09
|
|
|
Ciaphas posted:Still wondering this, and have a followup question. Someone pushed a couple of commits up to our central repo with the wrong email address (the default, basically, because they forgot to configure it on their new system). If I use filter-branch or whatever to try to fix that on the central, is that going to mess up everyone who's already pulled down the new commits (like rebasing a pushed branch would)? Yes, you're effectively rewriting history so the same issues apply. Unless its a major problem I'd leave it.
|
|
#
¿
May 5, 2016 20:11
|
|
|
uXs posted:Is there some way in Git to just checkout the latest commit, skipping over all the intermediate ones? A shallow-clone should pull only the latest commit, but eventually I think you need the rest of the history? I haven't really looked into shallow clones.
|
|
#
¿
May 11, 2016 16:47
|
|
|
Boris Galerkin posted:So I'm actually browsing our git repository on our gitlab site and holy poo poo this UI is a loving disaster. I have/had my browser snapped to one side/half of my monitor so the ~responsive design~ decided to get rid of all the labels on the menu bar on the left. Maybe I'm just too old (I'm 28...) but the icons they decided to use make no god drat sense to me and aren't very intuitive, specifically the activities (speedometer), milestones (a loving clock), merge request (a server rack??), and snippets (pieces of paper). I tried to look for a way to change my settings to maybe see if it can just force display the labels so I clicked on 'profile settings' but wasn't expecting the sidebar to replace the icons with different options so I spent 10 seconds of my life upset that "profile settings" literally only lets me change my profile information before realizing the sidebar changed. Doubt there's a full "Github UI" script. Gitlab does have a lovely UI, though. It was way better before they did the overhaul.
|
|
#
¿
Aug 16, 2016 03:48
|
|
|
That sounds like a reasonable approach. Just try to keep it to one or a few commits so if they enter conflict hell it's not as bad.
|
|
#
¿
Aug 30, 2016 23:03
|
|
|
It's apparently an Enterprise feature. https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html
|
|
#
¿
Oct 19, 2016 16:31
|
|
|
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 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
|
|
|
Thermopyle posted:Why are they in the same repository at all? If they all unrelated this is the correct way. Axiem posted:But Google puts everything in one repo! Yeah, because they are all intertwined. My last job had a bunch of lovely microservices that all dependend on each other in separate repos and adding new features across them was the worst.
|
|
#
¿
May 11, 2017 23:41
|
|
|
Should be relatively straight forward with subtrees: https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging
|
|
#
¿
May 12, 2017 17:36
|
|
|
Not new in the direct sense, but a replacement yes. The previous chapter of that book tries to do the same thing with submodules as a setup for the subtree chapter.
|
|
#
¿
May 13, 2017 04:48
|
|
|
They'll have to copy the file somewhere else locally beforehand, or use something like this after pulling down your commit:code:Snak posted:I'm thinking there should be some way to do what you're wanting to do by adding those files to the .gitignore file. But I'm not sure what the interaction is if they don't have the updated gitignore before they pull the changes that remove the files... .gitignore only matters for adding files to your stage. If you ignore a file already in the tree it will prevent adding changes to the file without the force flag. It won't help for what he wants (although those files should 100% be added to the gitignore so it doesn't happen again).
|
|
#
¿
May 30, 2017 21:46
|
|
|
Change the file to some ridiculous settings so they see the problem with it as is.
|
|
#
¿
May 30, 2017 23:54
|
|
|
edit: nevermind, that was not what I thought it was! Yeah, that's dumb.
|
|
#
¿
Jun 8, 2017 15:04
|
|
|
Yeah just use bitbucket for that as you get free private repos.
|
|
#
¿
Jun 10, 2017 19:07
|
|
|
Does the hook file have an extension? They have to be hook-name exactly, no extensions. Hooks can be any executable file, as long as the name matches. If it's a shell script (or any other interpreted file) you need a shebang at the top declaring the interpreter. If the name is correct I'd sprinkle some debug statements in the script and make sure they are output. edit: added some more. necrotic fucked around with this message at 23:46 on Jun 19, 2017 |
|
#
¿
Jun 19, 2017 23:42
|
|
|
|
| # ¿ May 14, 2024 21:03 |
|
|
Boris Galerkin posted:I'm using Git LFS with my Bitbucket account and I noticed I have a few large binary files that still show up in the LFS storage online but I'm 99% sure that I've deleted them and don't need them anymore. Is my understanding correct that these files still show up in the LFS repository simply because some old commit(s) reference them? If so I would like to just delete them from the website interface to free up some limited LFS space I get. I'm not familiar with LFS usage, but with git in general it is the case that a "deleted" file still exists in the history. You have to use filter-branch to go back through history and delete the files from every previous commit, thus building an entirely new history. This also means the repo will be 100% out of sync with anyone else using it. GitHub has a pretty good article on removing files completely: https://help.github.com/articles/removing-sensitive-data-from-a-repository/ All of it should apply to LFS as well. Boris Galerkin posted:
All git commands should work against LFS files, right? So git rm the/file.bin and then commit the deletion.
|
|
#
¿
Jul 11, 2017 15:42
|
|