|
Ender.uNF posted:Is there any way to set an ignore file that is committed as part of the repo, but applies to all branches? Right now I have to cherry pick and merge to mine and everyone else's named branches, plus the legit branches, otherwise some of our devs accidentally commit crap. No, since the .gitignore file is a file, it's part of a tree like any other file and you can't really just silently add anything to a tree. (At least it creates a new commit anyway, per tree/branch.) What you can perhaps do is write a hook script that validates pushes to the central repository, and reject them if they contain unwanted things.
|
#
?
Apr 26, 2014 09:00
|
|
|
|
| # ? May 11, 2024 10:02 |
|
|
Ender.uNF posted:Git question... I think the answer is no, but wanted to make sure. We have a bunch of branches going at the same time. Often I find myself needing to make changes to the ignore file as I clean things up (move binary dependencies to a private nuget repo, exclude build products, etc). Is there any way to set an ignore file that is committed as part of the repo, but applies to all branches? Right now I have to cherry pick and merge to mine and everyone else's named branches, plus the legit branches, otherwise some of our devs accidentally commit crap. Correct. The scopes you can ignore are
You could do it organisation wide by setting core.excludesfile to a file in a drop-box or mounted network share, but updating all the branches may be easier.
|
|
#
?
Apr 26, 2014 13:20
|
|
only
|
Using svn at work. I have my checkout on my network drive for reasons. Our company network is abysmally designed (everything is flat, no sub network etc..) We are only 50 machines but I mean my speed on the network fluctuates wildly and it sucks basically. I just now got a problem I never saw before and was wondering if any of you knew what was up. Out of the blue after releasing a document lock I cannot do any svn operations. I get the message sqlite : database image malformed or something like that. I tried to check for consistency of the .svn database and got plenty of errors but sadly could not repair it. Had to re-checkout everything... Anyone ever experienced something like that?
|
|
#
?
Apr 29, 2014 11:30
|
|
|
Le0 posted:Using svn at work. I have my checkout on my network drive for reasons. Our company network is abysmally designed (everything is flat, no sub network etc..) We are only 50 machines but I mean my speed on the network fluctuates wildly and it sucks basically. This kind of stuff happened to me constantly when working from our remote office with a lovely connection  Our solution was to move to mercurial but that probably won't help you in your case, although maybe you could use something like git-svn to alleviate that pain?
|
|
#
?
Apr 29, 2014 18:08
|
|
|
Strange git problem: A couple of people made various commits, pulling first each time and pushing their changes. Everything was cool. Then another dev, who had not fetched any changes over those two days added one file, did a "Pull" to merge remote with his local, and pushed that out. His merge, even though it only contains one file according to the history, completely blasted a bunch of changes from everyone else. If I run "git log <hash>.. -- file path" I only see commits to that file *after* the merge. If I run "git log <hash>.. --follow -- file path" I see the other people's commits. The file was not renamed or moved in any way. So it appears that his merge somehow just ignored/dead-ended the other people's commits, but nowhere in the history/log is this evident as a change of any kind. How can the merge commit not show any changes to the file? In the SourceTree or git GUIs, If I checkout latest and do a Log, none of the commits on the group's timeline show up, only the commits prior to the one dev merging and after. If I checkout detached one of those group commits and look at Log, I see all the missing commits but they just dead-end (if I check out the merge commit and do a Log those commits disappear). Anyone have ideas? edit: OK on the merge commit if I show all files I can see the ones that had their changes blasted and if I diff against the other merge parent I see the lines being removed. What I can't figure out is what the one dev did to make this happen. He swears he didn't do anything special. Simulated fucked around with this message at 23:06 on Apr 30, 2014 |
|
#
?
Apr 30, 2014 20:29
|
|
|
Ender.uNF posted:Strange git problem: git merge origin/master git checkout --ours . git add -A . git commit Would probably do it.
|
|
#
?
May 1, 2014 03:01
|
|
|
Coming from git to svn it's been a long time and I don't like it. How would I get a diff of all revisions by a user between a range of two commits? I have two revision numbers and I want to see a full diff of all commits by that user.
|
|
#
?
May 2, 2014 02:57
|
|
|
I'm using git now to track code I'm working on myself, so the repository has a single user, no other commits but mine to worry about. It's updating an existing codebase to a newer version of the framework and I tend to commit when I add new files but I don't know how frequently to commit the rest of the time. I test it as I go on a VM so I'm not worried so much about reverting major gently caress-ups, I just want a trackable history of all my modifications in case of a minor omission or whatever. Do people tend to have rules-of-thumb for this? I've never actually had to look at the revision history or use it for anything, it's more just a safeguard system for now, so I don't have any experience that tells me "oh I wish I'd committed more/less".
|
|
|
#
?
May 6, 2014 08:39
|
|
|
Sulla-Marius 88 posted:I'm using git now to track code I'm working on myself, so the repository has a single user, no other commits but mine to worry about. If you're going for a full development history, it would make sense to have a commit for every time you run the tests, so you can easily see what you changed since you last ran the test, so you can see what change you made may have broken something. This gets tedious for changes that take a while, as you end up with a long development history, as there's often a lot of back and forth with the changes, so you have a noisy, and generally not very useful history for working out why a change was made, and why it's currently causing something to break. So before you push your changes to master, you ought to rebase or squash the development history into commits that are
|
|
#
?
May 6, 2014 09:00
|
|
|
It really does depend upon your style to some extent. Some people commit every 5 minutes, no matter what. Others only commit after a feature is finished. What Edison was a dick suggests is probably a reasonable solution. Something to remember is that git has the interactive rebase feature, which allows you to go back in time and fix up your commits to pretend that you did everything perfectly the first time. If you haven't tried it yet, I strongly encourage you to; it's one of the killer features of git.
|
|
#
?
May 6, 2014 12:59
|
|
|
I was really not expecting such a large number of recommended commits. I suppose it works only one way -- it's better to have more commits that you can squash down into fewer, but you can't break one huge commit up into multiple different chunks to identify the differences in each.
|
|
|
#
?
May 7, 2014 09:01
|
|
|
Does anybody have a "git rebase for idiots" guide? I'm probably just overcomplicating it but it seems obtuse and the few times I've tried rebasing I've hosed things up horrendously.
|
|
#
?
May 7, 2014 09:12
|
|
|
Sulla-Marius 88 posted:I was really not expecting such a large number of recommended commits. I suppose it works only one way -- it's better to have more commits that you can squash down into fewer, but you can't break one huge commit up into multiple different chunks to identify the differences in each. You can go the other way, with creative use of git reset HEAD^; git add -p; git commit; git add -a; git commit. However it's much more difficult, since you don't have as much context of what each of the individual changes were if you didn't have the commit messages at the time, and you may end up with extra work keeping the codebase in a working state when 1 commit is logically 2, but the first commit doesn't work on its own, without a bit more scaffolding.
|
|
#
?
May 7, 2014 09:53
|
|
|
Sulla-Marius 88 posted:I was really not expecting such a large number of recommended commits. I suppose it works only one way -- it's better to have more commits that you can squash down into fewer, but you can't break one huge commit up into multiple different chunks to identify the differences in each. You absolutely can go the other way. Take a look at the -p argument to git add, git checkout, etc. You can stage changes line by line, and even write a custom patch section if necessary using your git editor. It's super powerful, and once you "get" it you suddenly have so much more power over your branch.
|
|
#
?
May 7, 2014 13:41
|
|
|
Arcsech posted:Does anybody have a "git rebase for idiots" guide? I'm probably just overcomplicating it but it seems obtuse and the few times I've tried rebasing I've hosed things up horrendously. https://www.atlassian.com/git/tutorial/rewriting-git-history Have you modified your .gitconfig to use your favourite diff/merge tool and your favourite editor? Rebasing in itself is not complicated; It just tries to reapply the changes to a different point in the commit tree. Because the commits are merged one at a time, fixing conflicts should be easier than during a full merge. But if you don't see clearly what you're doing, it's easy to treat rebasing as black magic. Oh, and don't be afraid to use git rebase --abort if you feel like you've painted yourself into a corner.
|
|
#
?
May 7, 2014 15:45
|
|
|
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
|
|
|
What I do is frequently amend the commit I'm working on (ie. after almost every save), then create a new commit whenever I hit a breaking point. That way work is almost always checked in, but the history doesn't get totally huge (and everything but the most recent commit has the codebase in a working state). If I need to do something more major that's going to keep things broken for a while I'll start a branch, then rebase it on master and possibly squash it down when it's done. My goal is to always have every commit on master to be working (as far as I know at the time), that makes it easy to select release versions. necrotic posted: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. You can think of it as checking out the base, then cherry-picking each commit in the branch in chronological order, pausing if there are conflicts and asking you to fix them up before continuing. evensevenone fucked around with this message at 20:18 on May 7, 2014 |
|
#
?
May 7, 2014 20:14
|
|
|
evensevenone posted:What I do is frequently amend the commit I'm working on (ie. after almost every save), then create a new commit whenever I hit a breaking point. evensevenone posted:My goal is to always have every commit on master to be working (as far as I know at the time), that makes it easy to select release versions.
|
|
#
?
May 7, 2014 21:38
|
|
|
evensevenone posted:What I do is frequently amend the commit I'm working on (ie. after almost every save), then create a new commit whenever I hit a breaking point. I typically do the opposite; I'll commit relatively frequently (as soon as I've done something worth saving, or even a 30 minute "checkpoint!" commit). I'll amend for "whoops, forgot a letter in a comment" but that's about it. Later, I'll go back and rebase my commits into something more coherent.
|
|
#
?
May 8, 2014 00:52
|
|
|
Plorkyeran posted:I almost never amend due to that I failed to figure out a way to get it to not ask me to edit the commit message each time, so making a new commit after every save and then squashing them later involves less disruption while working on things. code:
|
|
#
?
May 8, 2014 01:03
|
|
|
I really don't get the obsession people have, especially in the git community, for a "clean" history. Personally, I'm content having all my intermediate changes on there; it makes it easier if I go back to follow my own thought process.
|
|
#
?
May 8, 2014 03:07
|
|
|
Axiem posted:I really don't get the obsession people have, especially in the git community, for a "clean" history. Personally, I'm content having all my intermediate changes on there; it makes it easier if I go back to follow my own thought process.
|
|
#
?
May 8, 2014 05:30
|
|
|
Axiem posted:I really don't get the obsession people have, especially in the git community, for a "clean" history. Personally, I'm content having all my intermediate changes on there; it makes it easier if I go back to follow my own thought process. The operative term being 'your own thought process'. Other people can't or don't always have the time to decipher the last 7 hours of work you just did when everyone has a completely different approach. When you increase the number of developers, housekeeping goes a long way to being able to understand what is going on.
|
|
#
?
May 8, 2014 07:53
|
|
|
What I don't get is how people don't manage to have a fine-grained history comprised of logical checkpoints. Sometimes you need to make a big change, but, usually?
|
|
#
?
May 8, 2014 12:27
|
|
|
Axiem posted:I really don't get the obsession people have, especially in the git community, for a "clean" history. Personally, I'm content having all my intermediate changes on there; it makes it easier if I go back to follow my own thought process. "fix typo in comment" shrughes posted:What I don't get is how people don't manage to have a fine-grained history comprised of logical checkpoints. Sometimes you need to make a big change, but, usually? "Fine-grained" is hardly an objective term.
|
|
#
?
May 8, 2014 18:42
|
|
|
GrumpyDoctor posted:"fix typo in comment" Then again it avoids regressing the typo back into your software when reverting a big commit and looking stupid to your users.
|
|
#
?
May 8, 2014 18:57
|
|
|
No history clean-freaks edit published history. (None I'd want to be associated with, anyway.)
|
|
#
?
May 8, 2014 19:53
|
|
|
aerique posted:Then again it avoids regressing the typo back into your software when reverting a big commit and looking stupid to your users. All those users reading comments in your code, yeah
|
|
#
?
May 8, 2014 20:12
|
|
|
revmoo posted:Coming from git to svn it's been a long time and I don't like it. git log --author="a regex that partially matches the author field" dead..beef It's in the manpage for git-log or at git log --help. Steve French posted:All those users reading comments in your code, yeah for certain products where users are developers that have a license to your source, yeah (not that a simple typo is necessarily going to make you look bad to them) Deus Rex fucked around with this message at 20:28 on May 8, 2014 |
|
#
?
May 8, 2014 20:26
|
|
|
o.m. 94 posted:The operative term being 'your own thought process'. Other people can't or don't always have the time to decipher the last 7 hours of work you just did when everyone has a completely different approach. When you increase the number of developers, housekeeping goes a long way to being able to understand what is going on. I guess it also depends on the context and the culture of a development group. At home, it's just me, and I really don't care, because I see version control more as a way of keeping a backup and the ability to easily reverse huge changes if I go down the rabbit hole, along with making deployment easier. At work, I'm on a small team, and we have a very much commit-and-push mentality, with the rule being that each commit should be just big enough to make a change to make the app better without breaking it. So we have a very long master, but in theory, we never have a state where the app is unusable.
|
|
#
?
May 9, 2014 04:12
|
|
|
Steve French posted:All those users reading comments in your code, yeah Yeah, I guess I should have read that better.
|
|
#
?
May 9, 2014 12:35
|
|
|
Nothing fancy, but I like saying this line out loud:Objective-C code:lord funk fucked around with this message at 19:51 on May 9, 2014 |
|
#
?
May 9, 2014 16:32
|
|
|
This might be more of a Visual Studio question, but does anyone have any idea why the Git Extensions source control provider isn't showing up as available in VS 2013? (I know there's built-in git, but it doesn't seem as fully-featured as the one I've been used to.) I can see that the add-in is loaded, but it's not in the source control plug-in list.
|
|
#
?
May 9, 2014 19:25
|
|
|
So say I approved a pull request into a github repo and now I want to (If it helps - gitflow, and it was a merge into a feature branch from a dev's fork. There's been no further merges or commits into that branch as yet.)
|
|
#
?
May 15, 2014 09:50
|
|
|
Thel posted:So say I approved a pull request into a github repo and now I want to Use git log to get the hash of the commit before the bad merge, git reset --hard <hash> back to it, then git push -f origin <branch name>, assuming the github repo is origin. Then send them an email or whatever telling them to reopen their pull request. If it was the very last thing, you could also do git reset --hard HEAD~1.
|
|
#
?
May 15, 2014 13:28
|
|
|
The GitHub help page for creating a project page says:quote:To set up a Project Pages site, you need to create a new "orphan" branch (a branch that has no common history with an existing branch) in your repository. The safest way to do this is to start with a fresh clone: Umm, what's unsafe about just creating the required orphan branch without creating a fresh clone? Can't I just do the next step on that page and skip the clone part?
|
|
#
?
May 15, 2014 19:09
|
|
|
If you sufficiently mistype "git rm -rf ." you could delete things you don't want to delete, which is far less of a danger if you're working in a fresh clone.
|
|
#
?
May 15, 2014 19:19
|
|
|
Thel posted:(If it helps - gitflow, and it was a merge into a feature branch from a dev's fork. There's been no further merges or commits into that branch as yet.) I'll note that since it's a feature branch it's probably okay to do do a hard reset and force push. But it could be a pain to clones downstream from you that are tracking that branch. Another safer (but noisier) option is to revert the merge. This is what you'd probably want to do had you merged this pull request into your main or master branch (which likely have many trackers). http://git-scm.com/blog/2010/03/02/undoing-merges.html
|
|
#
?
May 16, 2014 14:56
|
|
|
I'm managing an android release (Not an app, a full android build) and I'm trying to improve the build versioning management. It works out to ~350mb of binaries. I don't think git-annex is a good fit due to the symlinks - I need the actual files in place so the release can make a filesystem image. I can't just follow symlinks, since some symlinks need to be part of the filesystem. The main reason I'd like a git-like is to handle three-way-merges better. If we field-fix a unit that's behind mainline, with git I can rsync its filesystem on top of a checkout of the matching release, commit the just the changes for the issue in question, then rebase that to mainline. This is a common workflow, since the devices in the field are in beta stage and we've got remote SSH access into them to edit/replace files on the fly. I'm asking because I feel like I'm holding a hammer and thinking this is a nail. Is there a better tool for the job?
|
|
#
?
May 22, 2014 05:55
|
|
|
|
| # ? May 11, 2024 10:02 |
|
|
Harik posted:I'm managing an android release (Not an app, a full android build) and I'm trying to improve the build versioning management. It works out to ~350mb of binaries. I don't think git-annex is a good fit due to the symlinks - I need the actual files in place so the release can make a filesystem image. I can't just follow symlinks, since some symlinks need to be part of the filesystem. Git Annex has a mode to not replace git annex added files with symlinks in the working tree. Git-Fat would also work, but it requires a centralised rsync repository, so may not be a good fit for every organisation. quote:The main reason I'd like a git-like is to handle three-way-merges better. If we field-fix a unit that's behind mainline, with git I can rsync its filesystem on top of a checkout of the matching release, commit the just the changes for the issue in question, then rebase that to mainline. This is a common workflow, since the devices in the field are in beta stage and we've got remote SSH access into them to edit/replace files on the fly. It's definitely not something Git is designed for. I've read articles by people from Atlassian who were saying we needed to get better at version controlling our output, hence we need to buy their product, which felt too much like marketing for me to be interested. At work we're working on tools for embedded development, where we're trying to solve this problem by ensuring we don't ever need to check in the result of a build, by making builds fast and always reproducible. We don't yet do Android though, and to tell the truth, we're not there yet for actually applying updates reliably.
|
|
#
?
May 22, 2014 08:21
|
|