|
Anyone a gerrit expert? I'm trying to enable force push rights for myself (I'm an admin) so I can delete remote branches and tags but gerrit -refuses- to let me do it, even though I've ticked the "force push" box in every place I could find it.
|
#
?
Aug 29, 2017 14:09
|
|
|
|
| # ? May 28, 2024 15:37 |
|
|
I'm sure this is pretty straightforward for people used to large scale git, but I've mostly used it for small open source stuff I've been a primary author on. There are essentially three actors here: 1. The master repository we're working with 2. My coworker's work, that I'll need to depend on 3. My own work With respect to 3, there are essentially two types of branches here: features and enhancements that need to be in their own branch as they may be proposed and merged into the master repo (1), and my own internal changes to the libraries for my personal work. This means that I essentially need my own branch off master that merges all my features, and the features of my coworker, and contains my personal changes, and I'm wondering what the easiest structure to do this is. What I'm primarily worried about is avoiding having to detangle a merge/rebase conflict rat's nest where I merge feature A into my branch, and later it's merged into master and I want to remerge or rebase my work on master for new features. Is my best option here just to do it the straightforward way and do an interactive rebase to manually ignore merges my internal branch has already seen when I need to sync up with the master branch?
|
|
#
?
Sep 2, 2017 10:58
|
|
|
Linear Zoetrope posted:I'm sure this is pretty straightforward for people used to large scale git, but I've mostly used it for small open source stuff I've been a primary author on. I'd create a new branch off of master and cherry-pick the commits I wanted from my development branch and create a pull request for that.
|
|
#
?
Sep 2, 2017 13:43
|
|
|
netcat posted:Anyone a gerrit expert? I'm trying to enable force push rights for myself (I'm an admin) so I can delete remote branches and tags but gerrit -refuses- to let me do it, even though I've ticked the "force push" box in every place I could find it. Not a gerrit expert, but I would imagine that you're missing some configuration/token that allows you to locally perform force pushes against your gerrit instance. The gerrit UI doesn't change what commands git issues locally. If I'm misunderstanding your question, please post some error you get when trying to force commit.
|
|
#
?
Sep 2, 2017 18:28
|
|
|
Coffee Mugshot posted:Not a gerrit expert, but I would imagine that you're missing some configuration/token that allows you to locally perform force pushes against your gerrit instance. The gerrit UI doesn't change what commands git issues locally. If I'm misunderstanding your question, please post some error you get when trying to force commit. Yeah, I'd make sure that you have the ability to force push straight on the command line before doing anything in gerrit.
|
|
#
?
Sep 2, 2017 18:40
|
|
|
Can someone walk me through git stash, because I obviously don't want to end up losing the stash? What do I do to create a stash? For specific files. What do I do to retrieve it? What do I do to add more stuff to it? How do multiple, separate stashes work? ufarn fucked around with this message at 01:04 on Sep 5, 2017 |
|
#
?
Sep 5, 2017 01:01
|
|
|
ufarn posted:Can someone walk me through git stash, because I obviously don't want to end up losing the stash? It's really hard to lose the stash. Don't use git stash drop or git stash pop and it's not going anywhere. quote:What do I do to create a stash? git stash or git stash save <description> to create one and git stash apply or git stash pop to retrieve it -- this is in the first page of git help stash.  quote:For specific files. This isn't directly supported, but you can fake it by staging the files you don't want to stash and then using git stash save --keep-index. You can also use git stash save --patch to interactively select individual diff hunks to stash. quote:What do I do to add more stuff to it? You don't, although you can create more stashes. quote:How do multiple, separate stashes work? They're recorded in the reflog of their own sort of "pseudo-branch" called stash; git stash list will list them and you can refer to them by index.
|
|
#
?
Sep 5, 2017 02:03
|
|
|
ufarn posted:Can someone walk me through git stash, because I obviously don't want to end up losing the stash? What exactly are you trying to do? From #3/#4, It kinda sounds like you should just make a branch and work on it.
|
|
#
?
Sep 5, 2017 18:44
|
|
|
I have main project with all sorts of things. I can't branch off, because I'll need to commit everything, and I just want to stow away some stuff that's cluttering my git status without adding it to .gitignore. The stuff cluttering things is mainly confined to one or two folders.
|
|
#
?
Sep 5, 2017 20:29
|
|
|
ufarn posted:I have main project with all sorts of things. I can't branch off, because I'll need to commit everything, One of us is misunderstanding something. Why does the latter preclude the former?
|
|
#
?
Sep 5, 2017 21:23
|
|
|
ufarn posted:I have main project with all sorts of things. I can't branch off, because I'll need to commit everything, and I just want to stow away some stuff that's cluttering my git status without adding it to .gitignore. The stuff cluttering things is mainly confined to one or two folders. You could make a branch that has your clutter on it and another branch that is hard reset to the correct HEAD, for example, which might as well be a stash in some way. However, if it really is a couple of directories you're trying to ignore, you should just add it to .gitignore. I mean, if you're really desperate, you could always hardcode those paths into core.excludesFile. Based on what you said so far, .gitignore sounds like the only reasonable thing to do here. It doesn't sound like you even care about the content you want to stash/branch off.
|
|
#
?
Sep 5, 2017 23:52
|
|
|
In Git parlance (or hell in other VC software) is a Pull Request anything other than a formal way of saying "here's the changes I wanna merge into master/dev/whatever, everyone cool with that"?
|
|
#
?
Sep 11, 2017 23:37
|
|
|
It's you (a third party contributor) requesting that the owner of the code pull your changes into the trunk. E: sometimes you and they are the same person.
|
|
#
?
Sep 12, 2017 00:10
|
|
|
I encourage regular rebasing in my team for bringing long-lived feature branches up-to-date with master/develop branches that have moved on a lot. I've got one or two devs in the team who seem to have consistent trouble with rebases, they take absolutely forever to do, and encounter two problems frequently: 1. 'Conflicts' in files that no one else has touched. For example. Foo.cs has only been edited on the feature branch. Dev is trying to rebase the feature branch on master. Git marks Foo.cs as conflicted, bringing it up in a merge tool like VS will show the 2 versions of the file - the one from master and the one from the feature branch, even though no-one's actually committed any changes to that file on the master branch. 2. Same conflicts coming up repeatedly. Dev will mark a conflict as resolved, rebase will play through a few more commits, then suddenly the same conflict will pop up again. Whenever I babysit them through the rebase from the beginning, things seem to go fine, but I generally get called in to help half way through when they are seeing a lot of these types of issues, and I'm not 100% sure how they got there. Does anyone know what they might be doing to get themselves into these sort of messes? I use rebase regularly and never seem to have problems like this. I realise this is a bit of a vague question and I wish I could give more detail, but I'm a bit confused myself.
|
|
#
?
Sep 14, 2017 16:30
|
|
|
Not sure what's happening in 1), but for 2), you can tell git to "re-use recorded resolutions."code:
|
|
#
?
Sep 14, 2017 16:40
|
|
|
Urgh, I think I know what it is. I think the situation has been created by them doing a pull at the end of the rebase (because the remote branch now shows as diverged), instead of a force push*. Then, when they rebase the branch again, they started running into these types of problems. This is my working theory, anyway. * I know it's kind of sketchy rebasing branches that are pushed to a remote, but we always push to our remote at the end of the day so we've got an off-site backup, even for our own local feature branches. I've advised them never to do any of this on shared branches.
|
|
#
?
Sep 14, 2017 17:10
|
|
|
chippy posted:Urgh, I think I know what it is. I think the situation has been created by them doing a pull at the end of the rebase (because the remote branch now shows as diverged), instead of a force push*. Then, when they rebase the branch again, they started running into these types of problems. This is my working theory, anyway. Probably, yeah. Typical scenario: - End of work, time to push. git push -f - New day, time to rebase. git rebase origin/master - Hmm, git says my branch is out of date with its tracking branch and I should pull to update. git pull - Oh, master is updated again. git rebase origin/master and then suffering. FWIW, we encourage the same approach of rebase and force-push on personal branches. I think it's a fine workflow, but it also makes git pull a big footgun when you're on one of those branches. I generally ask junior engineers to get a GUI with a nice log view, because even mild history editing like git rebase benefits from being able to actually see the history. Merges are a lot more lenient.
|
|
#
?
Sep 15, 2017 09:09
|
|
|
Xerophyte posted:- End of work, time to push. git push -f 
|
|
#
?
Sep 15, 2017 13:33
|
|
|
what the fuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuck kind of workflow includes force pushes as a regular occurrence
|
|
#
?
Sep 15, 2017 13:34
|
|
|
ChickenWing posted:what the fuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuck kind of workflow includes force pushes as a regular occurrence Edit: though --force-with-lease is a nice safety. Less Fat Luke fucked around with this message at 13:53 on Sep 15, 2017 |
|
#
?
Sep 15, 2017 13:48
|
|
|
+1 to rebasing and force-pushing personal branches. It's not like there's actually any danger (with a lease). You can always pull out the reflog, and in the unlikely event that someone else is defying best practices and trying to track your branch, they can clearly see what happened and rebase their own work in turn.
|
|
#
?
Sep 15, 2017 18:45
|
|
|
Ralith posted:+1 to rebasing and force-pushing personal branches. It's not like there's actually any danger (with a lease). You can always pull out the reflog, and in the unlikely event that someone else is defying best practices and trying to track your branch, they can clearly see what happened and rebase their own work in turn. That's some next level obsessive compulsive disorder. Going out of one's way just to ... see a straight line. The kind of line that nobody ever will look at, because it is irrelevant. But yes, as long as you keep your fetishes in personal branches, it's ok.
|
|
#
?
Sep 15, 2017 18:56
|
|
|
Volguus posted:That's some next level obsessive compulsive disorder. Going out of one's way just to ... see a straight line. The kind of line that nobody ever will look at, because it is irrelevant. But yes, as long as you keep your fetishes in personal branches, it's ok. 
|
|
#
?
Sep 15, 2017 19:20
|
|
|
Volguus posted:That's some next level obsessive compulsive disorder. Going out of one's way just to ... see a straight line. The kind of line that nobody ever will look at, because it is irrelevant. But yes, as long as you keep your fetishes in personal branches, it's ok. It's not about OCD or a fetish at all, it's just replaying your changes on top of the newer master and resolving changes that way instead of through merges.
|
|
#
?
Sep 15, 2017 19:26
|
|
|
Ralith posted:I'd like to try a merge-only workflow sometime, but so far everywhere I've worked has preferred linearity Yea, I cannot claim that I understand this ... preference, since well ... from where I sit, i don't give a poo poo if it's the spaghetti monster in there, since i don't look at that. I think I saw a picture of the git branch tree once or twice in my life. Branch or tag v1.2.3 is release 1.2.3. Development happens in the dev/development/devel branch from where things can be merged or cherrypicked into release branches if need be. From master releases are made (tag or branch, but is so much simpler to just branch) and everyone is happy. why wouldn't they be? When the number of branches exceeds some arbitrary number (10, 20, 100?) some can be deleted. The last thing in the world that I want is to babysit a version control repository. And the only time I ever had to unfuck a git repo was when someone hosed it by using force (of course, not in their personal branches).
|
|
#
?
Sep 15, 2017 19:30
|
|
|
Volguus posted:But yes, as long as you keep your fetishes in personal branches, it's ok. The Something Awful Forums > Discussion > Serious Hardware / Software Crap > The Cavern of COBOL > Version Control Questions Megathread: No Graph Shaming
|
|
#
?
Sep 15, 2017 19:41
|
|
|
There's something to be said for keeping master's history concise and readable for auditing purposes, but that's really more about squashing commits than anything.
|
|
#
?
Sep 15, 2017 19:47
|
|
|
Ralith posted:There's something to be said for keeping master's history concise and readable for auditing purposes, but that's really more about squashing commits than anything. Squashing commits, yes, totally. You don't want (if you can help it) "wip did something, doesn't work" kind of commits in master or devel, which are unavoidable during normal workday. But in their own branch ... is perfect for tracking when exactly bug 55 was introduced.
|
|
#
?
Sep 15, 2017 19:54
|
|
|
Am I crazy, or is there no way to fetch or push git tags through VS2015? You have to use the command line?
|
|
#
?
Sep 15, 2017 21:16
|
|
|
Commits in your feature branch and commits in your pull request serve two different purposes: one is just for getting something done, the other is for explaining what was gotten done. Sometimes they're the same, but I rebase extensively and I find that if nothing else, I'll rewrite the commit messages from being one-line notes to self.
|
|
#
?
Sep 15, 2017 22:25
|
|
|
Doc Hawkins posted:Commits in your feature branch and commits in your pull request serve two different purposes: one is just for getting something done, the other is for explaining what was gotten done. code:
|
|
#
?
Sep 16, 2017 00:20
|
|
|
I want to include someone else's repository in my repository because they have some scripts and things that I can re-use specifically for this project. Quick searching tells me that git submodules are what I want for this. I also need to modify some of his scripts with different options or different things. What is the best way to do this? Thinking about it, the options I came up with are 1. Fork his repository, make a new branch, do my edits in there, and add this specific branch into my repository as a submodule (in "external" or "contrib" for example). 2. Add his repository to my repository as a submodule but do not modify it at all. Create a patch file that I will track in my repository, and use that patch file to create modified versions of his scripts that I'll use. In both cases I'll theoretically be able to keep the scripts updated against his main repository/releases but still have my own modifications but I'm not sure what is the standard way of doing this.
|
|
#
?
Sep 16, 2017 13:22
|
|
|
Volguus posted:Yea, I cannot claim that I understand this ... preference, since well ... from where I sit, i don't give a poo poo if it's the spaghetti monster in there, since i don't look at that. I think I saw a picture of the git branch tree once or twice in my life. Some of us visualize the graph regularly! 
|
|
#
?
Sep 16, 2017 13:39
|
|
|
raminasi posted:Some of us visualize the graph regularly! Are you a developer or an integrator? As a person who puts builds together for release, i can see that happening, of course. As a developer ... there isn't anything in there of value..
|
|
#
?
Sep 16, 2017 15:36
|
|
|
Boris Galerkin posted:I want to include someone else's repository in my repository because they have some scripts and things that I can re-use specifically for this project. Quick searching tells me that git submodules are what I want for this. I also need to modify some of his scripts with different options or different things. What is the best way to do this? 1 will be much easier to keep up to date with upstream, and easier to push changes to upstream from.
|
|
#
?
Sep 16, 2017 17:15
|
|
|
How bad is it to push a large unchanging binary into git? Like a 1 gb database image. I know it's not meant for it but it's our easiest way to share files.
|
|
#
?
Sep 17, 2017 00:11
|
|
|
smackfu posted:How bad is it to push a large unchanging binary into git? Like a 1 gb database image. I know it's not meant for it but it's our easiest way to share files. It's not really bad per se, it's just not very efficiently compressed. But if it never changes it'll just make the first clone/pull/push/whatever take longer.
|
|
#
?
Sep 17, 2017 00:17
|
|
|
Could you serve the file from a secure url and just share a post-checkout hook that ensures it's downloaded? E: that might not work, I'm not a hook expert, but pretend I said "share a script" Doc Hawkins fucked around with this message at 00:27 on Sep 17, 2017 |
|
#
?
Sep 17, 2017 00:23
|
|
|
smackfu posted:How bad is it to push a large unchanging binary into git? Like a 1 gb database image. I know it's not meant for it but it's our easiest way to share files. Didn't Facebook end up with Mercurial because Git couldn't handle their large GBs of code base or something?
|
|
#
?
Sep 17, 2017 00:34
|
|
|
|
| # ? May 28, 2024 15:37 |
|
|
It's no longer applicable anymore (maybe?) but many years ago (2008-9 maybe) a coworker pushed to git a 3GB binary file. The push went fine. The pull ... not so fine. We were on windows 32 bit at the time and git would try to load that entire 3GB file in memory and it would obviously die a very painful death when windows decided that you had enough(2gb i think was the limit per process). Other pushes with 1KB file to overwrite it were failing and since none of us had any idea what to do (very noobs in git) we just nuked the git repo and started from scratch. Since then I have an aversion towards large binary files pushed to a version control repository.
|
|
#
?
Sep 17, 2017 01:40
|
|