|
The Fool posted:I'm having problems wrapping my head around git remote right now. I've never had issues using git with github, but this is a little different. The tricky thing here is that if it's a bare repository, they can't run scripts directly from it, and if it's a non-bare repository, you can't push to it. Offhand, I can think of three different ways to do this: - Don't bother with a remote at all. When you want to push a new version, run git --work-tree=/path/to/network/share reset --hard HEAD - Clone your working repo onto the network share (as a non-bare repo) and then pull from there to update: (cd /path/to/network/share && git pull) - Create a bare repo as a remote (not necessarily on the network share) and install a hook that causes it to checkout its contents to the share when you git push to it Of these, I'd probably just go with #1, given the assumption that your coworkers aren't using git in the first place.
|
#
?
Oct 18, 2016 01:11
|
|
|
|
| # ? May 13, 2024 14:27 |
|
|
ToxicFrog posted:The tricky thing here is that if it's a bare repository, they can't run scripts directly from it, and if it's a non-bare repository, you can't push to it. Yeah, most of what I was reading assumes wanting to use the network share as the main repository for multiple git users, and that used a bare repository, and that's just not what I want. Thanks for the info, #1 sounds like it's going to be the best bet. e: it works perfectly The Fool fucked around with this message at 01:36 on Oct 18, 2016 |
|
#
?
Oct 18, 2016 01:32
|
|
|
Is `git mv` the best way to rename a file and retain its history such that `git log follow` works? I know Linus has some weird thing about renames not being something Git cares about it, but this is a repo that I have control over, so I'm trying to find the "safest" way to rename files and retain history.
|
|
#
?
Oct 18, 2016 06:36
|
|
|
Yes.
|
|
#
?
Oct 18, 2016 06:39
|
|
|
Whenever possible, I also try to not change and move a file in the same commit.
|
|
#
?
Oct 18, 2016 07:24
|
|
|
Does anyone here use GitLab? I've been playing with the merge options and don't like that it creates a merge even when I've rebased on to the head of the branch I'm merging. I would like it to behave more git does locally where it will FF if possible and only do a merge otherwise. Is there something in the settings I can set to allow for the desired behavior?
|
|
#
?
Oct 19, 2016 15:00
|
|
|
It's apparently an Enterprise feature. https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html
|
|
#
?
Oct 19, 2016 16:31
|
|
|
Kobayashi posted:Is `git mv` the best way to rename a file and retain its history such that `git log follow` works? I know Linus has some weird thing about renames not being something Git cares about it, but this is a repo that I have control over, so I'm trying to find the "safest" way to rename files and retain history. `git mv old new` is just shorthand for `mv old new && git add old new`. `git log --follow` determines renames based solely on % similarity, which iirc defaults to 80%.
|
|
#
?
Oct 28, 2016 22:34
|
|
|
I have a build process that involves cloning a repo "project1", and then copying files from another repo "project2" to a dir inside of that project1, and running a bunch of build scripts, generating .o files etc all over the place and eventually i get a tar file with the full project build in it. project1 is huge, and cloning it takes a long time, so in the master script that starts all this, instead of wiping the whole build dir and cloning a fresh one, can I do something like "git checkout -f " and that would have the same result?
|
|
#
?
Nov 2, 2016 17:38
|
|
|
peepsalot posted:I have a build process that involves cloning a repo "project1", and then copying files from another repo "project2" to a dir inside of that project1, and running a bunch of build scripts, generating .o files etc all over the place and eventually i get a tar file with the full project build in it. Unless I'm misunderstanding, you can just do 'git pull' to pull down the latest changes to project1, instead of cloning the whole thing afresh.
|
|
#
?
Nov 2, 2016 18:10
|
|
|
peepsalot posted:project1 is huge, and cloning it takes a long time, so in the master script that starts all this, instead of wiping the whole build dir and cloning a fresh one, can I do something like "git checkout -f " and that would have the same result?
|
|
#
?
Nov 2, 2016 20:06
|
|
|
Is there anyway to pluck a file that exists on another branch with it's commit history? I have a feature branch that I want to pluck a file from and move into master, AND I want it's commit history. How could I do that?
|
|
#
?
Jan 6, 2017 15:36
|
|
|
In Git? I don't know how you'd actually perform it, but you'd have to generate a new branch mirroring the branch the file with changes comes from, but containing only that file. Then you can merge that new "fake" branch in. I think "filter-branch" may be the command? This would obviously still decouple those changes from the original branch, and you may get trouble if you later attempt to merge in that branch too.
|
|
#
?
Jan 6, 2017 15:45
|
|
|
KoRMaK posted:Is there anyway to pluck a file that exists on another branch with it's commit history?
|
|
#
?
Jan 6, 2017 16:25
|
|
|
ExcessBLarg! posted:You can merge the two branches such that the merge commit only includes one file from the "other" branch. But both branch histories would show in "git log", the history wouldn't be specific to that one file. That was also my first idea, but not only will it cause history to show commits not relevant to the single file, it will probably also cause even bigger issues if you need to merge the branch in full later on.
|
|
#
?
Jan 6, 2017 17:03
|
|
|
nielsm posted:In Git?
|
|
#
?
Jan 7, 2017 07:32
|
|
|
nielsm posted:That was also my first idea, but not only will it cause history to show commits not relevant to the single file, it will probably also cause even bigger issues if you need to merge the branch in full later on. The problem with the filter-branch approach is that, if you do a full merge later you end up with two histories. You end up with an entire fake commit history related to the filter-branch procure, and then the real commit history from the merge. Both sets of commits would appear in the log and confuse the poo poo out of everybody. If I was cherry-picking a file from a feature branch and wanted to "preserve" its history, I'd first tag the feature branch, then do a "git checkout feature_branch file" and commit it with a squashed log and a reference to the tag. That way the actual history of the file is preserved as a tag and I can see what's up from the log, but there's no branch merge operation actually done and no confusing quasi-real history.
|
|
#
?
Jan 7, 2017 18:41
|
|
|
Can anyone recommend a good out-of-the-box SVN hosting service with good bandwidth between US/Asia? Uptime and security are big factors too. Thanks in advance.
|
|
#
?
Jan 12, 2017 21:34
|
|
|
Using git, I merged a couple of single commits from one branch to another. git log and Fisheye (and anything else I've tried) show only the expected commits, with the expected files changed. However, either one of the commits changed a bunch of other files, and they aren't listed anywhere as being changed, or there's some sort of hidden commit that happened and changed those files. The biggest problem is that I don't even know specifically which files have been changed. git diff between commits don't show the change, but I can see that the file contents changed mysteriously between two of adjacent commits in the history. What could possibly cause this, and how should I fix it? Should I just revert the whole branch to a time before any of those commits and patch in the diffs or something? edit: Apparently the whole branch history somehow got merged in instead of a single commit. This causes a ton of extra commits to appear in the history, but they're all backdated, with no obvious way to separate out the unwanted ones. Is there a way to find out when some particular commits/merges were pushed to a specific branch, rather than when they were originally committed/pushed to their original branch? Kilson fucked around with this message at 21:53 on Jan 17, 2017 |
|
#
?
Jan 17, 2017 21:14
|
|
|
If you only wanted single commits you should have cherry picked the commits specifically. Reset your branch to before the merge and try again.
|
|
#
?
Jan 18, 2017 00:56
|
|
|
Blinkz0rz posted:If you only wanted single commits you should have cherry picked the commits specifically. Reset your branch to before the merge and try again. I realize now that cherry pick was what I wanted. I'm still a little baffled as to how this happened, because there wasn't really any indication that it was happening. Diff showed only the 12 expected files had changed. How can I reset to before the merge, when there's a bunch of stuff in the history from way before that? (Also, this merge got pushed to origin.) There doesn't appear to be a normal merge commit for this one, for some reason. At least it isn't displaying the way they usually do. Or is reset based on topology, not ancestry, and resetting/rewinding before that would remove everything merged in, even if it appears months old? Sorry, I'm pretty new to using git (from a long time using svn), so I don't quite understand how it works yet.
|
|
#
?
Jan 18, 2017 02:32
|
|
|
git reset moves the branch pointer to the given commit, so the new contents of the branch is all the commits reachable from that commit, dates don't really play into it. I'm not sure what you mean by topology vs ancestry, I thought ancestry defines the topology. But if you're already published the current state of the branch, it's really bad form to try to rewrite history. You'd want to use git revert to undo specific commits/merges by introducing more commits. I think that might become super messy. I'm not sure if git blame would be helpful to find out when certain changes appeared in your branch, I assume it will point to the original commits and not the merge commits, but I don't know from the top of my head. It's not always obvious from glancing at git log what commits are reachable from the branch head, showing the history so linearly is kinda misleading when there's merges involved. I dunno what fisheye is exactly, have you used tools that visualize the history as a graph, so you can just trace all the lines and see where they go?
|
|
#
?
Jan 21, 2017 17:10
|
|
|
Vanadium posted:git reset moves the branch pointer to the given commit, so the new contents of the branch is all the commits reachable from that commit, dates don't really play into it. I'm not sure what you mean by topology vs ancestry, I thought ancestry defines the topology. I'm sure I was using incorrect terms. By ancestry I meant age, but what I said probably didn't make sense anyway. quote:But if you're already published the current state of the branch, it's really bad form to try to rewrite history. You'd want to use git revert to undo specific commits/merges by introducing more commits. I think that might become super messy. Merging in all those changes (which I wanted to remove) already rewrote the history with all kinds of added junk. I wanted to get rid of it all. quote:I'm not sure if git blame would be helpful to find out when certain changes appeared in your branch, I assume it will point to the original commits and not the merge commits, but I don't know from the top of my head. The problem was that there didn't seem to be a clear way of even determining what had been merged in, because most of it was dated far in the past. Nobody had a recent version of that branch, because I'd been the only one working on it (doing hotfixes) for probably a couple months, so there wasn't anyone who could just do a diff or something. I tried reverting to the commit before the bad merge, but at least some of the stuff that was dated before that was still in there, and it was going to be way too much work to go through everything and figure out what didn't belong. quote:It's not always obvious from glancing at git log what commits are reachable from the branch head, showing the history so linearly is kinda misleading when there's merges involved. I dunno what fisheye is exactly, have you used tools that visualize the history as a graph, so you can just trace all the lines and see where they go? Fisheye is just some visualization tool that you can see history/logs (in text and graph form), you can browse the code and show differences between any commits, etc. The history graph just looked like a giant ball of yarn. I couldn't make any sense out of it. In the end, I just force pushed the branch based on a backup we had from the friday before the bad merge to rewrite everything back to its correct state, then correctly cherry picked the necessary commits into the branch.
|
|
#
?
Jan 25, 2017 00:03
|
|
|
For future reference, you can always look through "git reflog" to find a previous state of a branch, no matter how mangled your history has gotten.
|
|
#
?
Jan 25, 2017 01:07
|
|
|
Also, if you're just using "git log", consider using "git log --oneline --graph --decorate" or even a graphical tool like "gitk" to get a better sense of history. You may have a better idea of what the results of the merge actually are once you've done so.
|
|
#
?
Jan 25, 2017 01:17
|
|
|
What kind of git hooks do people find useful? We have two pre commit hooks: one to prevent committing focused jasmine JavaScript tests (focused means it will only run that test when you run the entire suite) and one to prevent someone checking in our database scheme name (because it differs between environments and should come from a setting.) smackfu fucked around with this message at 14:08 on Jan 31, 2017 |
|
#
?
Jan 31, 2017 13:52
|
|
|
Kilson posted:Merging in all those changes (which I wanted to remove) already rewrote the history with all kinds of added junk. Also, since merging is additive, and doesn't rewrite anything, you can always undo a merge with a 'git reset --hard MERGE_PARENT" where MERGE_PARENT is one of the parents listed in the "Merge:" line of the merge commit. If you've just done a merge, usually "git reset --hard HEAD^" does what you want. Kilson posted:Nobody had a recent version of that branch, because I'd been the only one working on it (doing hotfixes) for probably a couple months, so there wasn't anyone who could just do a diff or something. Kilson posted:I tried reverting to the commit before the bad merge, but at least some of the stuff that was dated before that was still in there, and it was going to be way too much work to go through everything and figure out what didn't belong. Kilson posted:In the end, I just force pushed the branch based on a backup we had from the friday before the bad merge to rewrite everything back to its correct state, then correctly cherry picked the necessary commits into the branch.
|
|
#
?
Jan 31, 2017 15:11
|
|
|
nielsm posted:In Git? Ralith posted:I've always done this with filter-branch, yeah. Never tried to merge in a superset of it again later though. Ugh, both of these solutions seem like they would be more of a pain in the rear end down the road, so I just copy/pasted that poo poo into the branch. Thanks for the advice though!
|
|
#
?
Feb 5, 2017 15:25
|
|
|
In git is there a canonical way to update a commit message if it's already been pushed? My tactic so far has been to tsk at the the individual responsible (when it's not me  ) then tell them to revert the commit, revert the revert (using the commit message they actually wanted), then push those results.(We're required to put work order numbers in the summary, and I haven't gotten a trigger to check for that fully working yet.) Ciaphas fucked around with this message at 23:42 on Feb 14, 2017 |
|
#
?
Feb 14, 2017 23:35
|
|
|
Force push the history of you don't care about fast forwards, or use git replace to amend the message and tell people to reconfigure their clients to push and pull replace refs. Alternatively have pre-merge commit review.
|
|
#
?
Feb 14, 2017 23:42
|
|
only
|
I always struggle with how to commit inconsequential changes. For example, I'll be working on a feature and come across some unused imports, some comments that need fixing, some formatting issues...any of which are unrelated to the feature I'm working on. Lump those changes into a commit dealing with the actual feature I'm working on? Add additional commits for those changes to the feature branch I'm working on? Something else?
|
|
#
?
Feb 17, 2017 21:13
|
|
|
Making them their own commit doesn't cost anything, does it? My principle is to always make every commit be about ONE thing, so you can find it later. What reason is there to hide inconsequential things under another thing? Why not just have a commit for them and label it as being inconsequential?
|
|
#
?
Feb 17, 2017 21:16
|
|
|
Thermopyle posted:I always struggle with how to commit inconsequential changes. For example, I'll be working on a feature and come across some unused imports, some comments that need fixing, some formatting issues...any of which are unrelated to the feature I'm working on. I am a literal monster but I have no real problems with with having a... more extensive commit history, as long as it explains what is being done and isn't a stream of "made an update" and other low-quality garbage. Maybe doing clean-up in a block, writing individual commits, and squashing when you've finished that "block" is the answer?
|
|
#
?
Feb 17, 2017 21:22
|
|
|
Thermopyle posted:I always struggle with how to commit inconsequential changes. For example, I'll be working on a feature and come across some unused imports, some comments that need fixing, some formatting issues...any of which are unrelated to the feature I'm working on. I like separate commits for unrelated changes, otherwise it's harder to review the feature. But I also like to make the small change when I see it, otherwise I'll forget. What I do is make the unrelated change immediately and commit it. Then, once I'm in a good spot, interactive rebase to move the commit so it's the parent of the feature branch. before: pre:o <- feature branch o o <- unrelated change o o o <- master pre:o <- feature branch o o o o <- unrelated change o <- master
|
|
#
?
Feb 17, 2017 22:35
|
|
|
Thermopyle posted:I always struggle with how to commit inconsequential changes. For example, I'll be working on a feature and come across some unused imports, some comments that need fixing, some formatting issues...any of which are unrelated to the feature I'm working on. I lump them in unless a) its a change which will confuse the hell out of future diffs, like formatting xml with a tool cos its got out of control. If someone suspects a bug with my actual change I know that would make it v.difficult, so I separate the check-ins, and do a special "reformatting only, no functional changes" check in. b) it costs me nothing to check in separately, like its an unrelated file with no other changes. Its not ideal, I should be doing them all separately so the diffs are easy to navigate, but, gently caress. Apparently separate is hard for me to spell, I love spell check.
|
|
#
?
Feb 17, 2017 22:39
|
|
|
Thermopyle posted:I always struggle with how to commit inconsequential changes. If I generate multiple "inconsequential" commits while working on a private branch I'll usually squash them together. I figure that they're noise in the history and people who might be reviewing the branch history really don't care about them. I always keep a reformat run in a separate commit, because the deltas can be huge and they're functionally inconsequential by definition.
|
|
#
?
Feb 18, 2017 16:23
|
|
|
Thermopyle posted:I always struggle with how to commit inconsequential changes. For example, I'll be working on a feature and come across some unused imports, some comments that need fixing, some formatting issues...any of which are unrelated to the feature I'm working on. Definitely keep functional changes separate from broad code restyling. That's a PITA to review together.
|
|
#
?
Feb 25, 2017 11:47
|
|
|
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.
|
|
#
?
Feb 27, 2017 19:42
|
|
|
boo_radley posted:You avoid this kind of janitor work with a workspace-per-branch scheme. We have 900+ projects with multiple branches per project, so we'd feel a lot more pain immediately if we tried to pull in an entire project's code across all branches at once. 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?
|
|
#
?
Mar 7, 2017 18:36
|
|
|
|
| # ? May 13, 2024 14:27 |
|
|
EmmyOk posted: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. Are the repos all public?
|
|
#
?
Mar 9, 2017 01:13
|
|