|
Slanderer posted:Any thoughts? It's been a long time, but I seem to recall doing something similar with a SVN hook script back when I used it. IIRC, the hook script just needs to return an errorlevel (exit code) other than 0 and it will fail. Anything written to stderr will show up in the message. I am in Windows land, so I wrote a c# console app that performed my check and returned the correct value. Assuming you're a coder, that shouldn't take very long to knock something up in your language of choice.
|
#
?
Mar 11, 2016 23:03
|
|
|
|
| # ? May 12, 2024 19:02 |
|
|
Ralith posted:Yeah, hooks like you describe sound like a pretty reasonable solution, considering the limitations of your tools. Might be worth complaining to whoever maintains the IDE, just so they know they've got a problem. This isn't really a problem with the IDE; it's a limitation intrinsic to SVN.
|
|
#
?
Mar 11, 2016 23:07
|
|
|
IDEs that aren't garbage support splitting your project into multiple files so that you can have non-version-controlled parts. Most garbage IDEs do too, for that matter.
|
|
#
?
Mar 12, 2016 01:02
|
|
|
I want to take a minute to make sure I'm understanding how Git sort of works, especially when rebases get involved. I've got a repo with a master branch (remote tracking a central repo's master branch) and a local-only branch, warnings-fixes, for clearing up a bunch of warnings in our C++ project over time. master is some dozen commits ahead of warnings-fixes at this point, and I'd like to catch warnings-fixes up to see if some warnings got fixed (or new ones got made because apparently people can't be bothered  )git rebase master warnings-fixes 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? Does anything in particular happen to the old commits in that branch? Is this different if there's a remote-tracking or another local branch there before I do the rebase? Will rebasing in this way interfere with anyone? 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? Ciaphas fucked around with this message at 01:27 on Mar 12, 2016 |
|
#
?
Mar 12, 2016 01:22
|
|
|
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
|
|
|
necrotic posted: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. If you have your own local commits you can also just rebase them on top of a force-pushed branch rather than hard resetting.
|
|
#
?
Mar 12, 2016 03:53
|
|
|
Cool, thanks, glad I got it right. We're finally freeing ourselves of ClearCase, me and four others, and I'm the designated "train them or figure out what training we need" guy, so I'm busying myself making sure I'm clear on concepts and how things will change (and how things will stay the same) for everyone else.
|
|
#
?
Mar 12, 2016 04:19
|
|
|
ToxicFrog posted:This isn't really a problem with the IDE; it's a limitation intrinsic to SVN.
|
|
#
?
Mar 14, 2016 04:39
|
|
|
Plorkyeran posted:IDEs that aren't garbage support splitting your project into multiple files so that you can have non-version-controlled parts. We have that, and it does that. The problem is that we still want to include our debugger hardware configuration in version control, because there are some potential pitfalls if people had to set them up themselves. It normally isn't a problem if your entire team is using the same hardware tools (which is the case 99% of the time around here). B-Nasty posted:It's been a long time, but I seem to recall doing something similar with a SVN hook script back when I used it. IIRC, the hook script just needs to return an errorlevel (exit code) other than 0 and it will fail. Anything written to stderr will show up in the message. I am in Windows land, so I wrote a c# console app that performed my check and returned the correct value. Thanks for the feedback (and to everyone else who replied). I'll give this a shot when I have a spare moment.
|
|
#
?
Mar 14, 2016 22:41
|
|
|
Slanderer posted:We have that, and it does that. The problem is that we still want to include our debugger hardware configuration in version control, because there are some potential pitfalls if people had to set them up themselves. It normally isn't a problem if your entire team is using the same hardware tools (which is the case 99% of the time around here).
|
|
#
?
Mar 15, 2016 02:48
|
|
|
ToxicFrog posted:This isn't really a problem with the IDE; it's a limitation intrinsic to SVN. Or you can just set an "ignore" on the local config file in SVN: code:
|
|
#
?
Mar 16, 2016 15:10
|
|
|
bobthecheese posted:Or you can just set an "ignore" on the local config file in SVN: The original question was about ignoring changes to a specific line in the file while still committing the rest of the file.
|
|
#
?
Mar 16, 2016 17:01
|
|
|
Oh. Well then. Maybe I should have read back further.
|
|
#
?
Mar 16, 2016 19:36
|
|
|
I have a visualSVN server set up on a box at home and if I am at work every time I try to get updates or commit (through tortoiseSVN) the first request will never go through but if I make a second request it works just fine. Is there something on the box I can check to see why that is happening?
|
|
#
?
Mar 16, 2016 19:42
|
|
|
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.
|
|
#
?
Mar 22, 2016 19:32
|
|
|
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
|
|
|
My coworkers and I are all working in master in a git project, fetching and pushing from a single central bare repo. As a result, when we do git pulls we end up with a lot of merge commits. Not really a problem, but having them sprinkled in the history tree is kind of ugly. I've taken to doing git fetch; git rebase origin/master master instead which makes things nice and clean; are there any disadvantages to doing things this way instead of using git pull? So far I'm thinking "no--again as long as you haven't pushed anything you rebase" but I want to make sure before I tell the others to start doing this. (I know we should be working in branches rather than all colliding on master; they're all new to Git after a decade on ClearCase and I'm a rubbish teacher, and there's no money for training for a few months.) (ed: by the way if anyone can recommend a training company that'd come to Las Vegas and do a course for our team I'd listen  )
Ciaphas fucked around with this message at 00:21 on Mar 23, 2016 |
|
#
?
Mar 23, 2016 00:11
|
|
|
Ciaphas posted:My coworkers and I are all working in master in a git project, fetching and pushing from a single central bare repo. As a result, when we do git pulls we end up with a lot of merge commits. Not really a problem, but having them sprinkled in the history tree is kind of ugly. If I'm understanding you correctly, then what you're doing is so common that some people feel it should be the default behavior.
|
|
#
?
Mar 23, 2016 00:42
|
|
|
Ciaphas posted:My coworkers and I are all working in master in a git project, fetching and pushing from a single central bare repo. As a result, when we do git pulls we end up with a lot of merge commits. Not really a problem, but having them sprinkled in the history tree is kind of ugly. I think you can just do git pull --rebase for that.
|
|
#
?
Mar 23, 2016 00:50
|
|
|
Well then, that answers that . I just kind of stumbled into that solution for my own OCD purposes, didn't think it was that common. Thanks!
|
|
#
?
Mar 23, 2016 00:54
|
|
|
Ciaphas posted:Well then, that answers that It's what I always tell teams that are moving from centralized VCS to Git to do until they're comfortable with DVCS.
|
|
#
?
Mar 23, 2016 00:59
|
|
|
Does it really come with any disadvantages ompared to plain old pull? Only thing I can see or think of is that the precise chronology of events is a little muddled when looking at a --graph --pretty=oneline log, but 99% of the time I don't care about that, and I don't think the rest of my team does either. If there's no real disadvantage I'll just set it in /etc/gitconfig and keep silent (edit) Sidenote, I'm not really seeing any reason for our team not to just stick to cloning off of /var/git/projectnamehere.git and pushing/fetching from that, either. It's only 4 of us and it's more maintenance than active development nowadays, anyway. Ciaphas fucked around with this message at 01:17 on Mar 23, 2016 |
|
#
?
Mar 23, 2016 01:04
|
|
|
I prefer the rebase to keep a nice linear history. That way, branches are clearly for features or whatever standard branching strategy you use. I picked up this tendency from a shop that had rebase as a policy, and I don't see any compelling reason not to do it even though I was steeped in Hg originally.
|
|
#
?
Mar 23, 2016 15:08
|
|
|
Ciaphas posted:Does it really come with any disadvantages ompared to plain old pull? In general, with Git/DVCSes I don't think policies of "always rebase" are realistic, as there are times when a merge or squash-then-rebase are cleaner operations. In the common case of having one outstanding commit on master and doing a pull before push, "git pull -r" is almost always preferred, yes.
|
|
#
?
Mar 23, 2016 15:30
|
|
|
I don't suppose anyone has a script handy for updating the svn:external paths for a directory tree? The reason is a huge I told you so about the setup of a huge project here, and now I would like to be able to fix all of their external paths to point at a new location in certain branches. Unfortunately, the externals are scattered across multiple subdirectories on multiple levels, so its a huge pain to do manually. All of the externals point to a lib directory ^/project/Lib/<external>, but I need to point them at ^/project/branch/Lib/<external> I looked at the SVN command line documentation, and while it is trivial to export a list of the svn:external properties for a given directory tree, there is no way to apply property changes using such a list. This is probably a trivial task, but only rarely do any scripting so I don't want to waste hours relearning perl if there is a solution already on github somewhere.
|
|
#
?
Mar 23, 2016 19:38
|
|
|
It should be noted that you can set 'git pull' to rebase by default on a branch, project, or system-wide level if that fits your workflow and you understand how to deal with conflicts.
|
|
#
?
Mar 23, 2016 20:26
|
|
|
Ok, so I'm working from a Windows machine in a mostly Linux environment, on a huge (like 900,000 revisions) SVN repository. I've been doing this by using rsync to get my checkout from my dev server to my laptop and SFTP to move my changes back, but this causes issues when big changes to the repository happen, and one of those happened last week, so I'm playing around with alternatives. Using the Windows SVN client (command-line or Tortoise) fails due to some weird syntax somewhere that Windows doesn't know how to deal with; recently I found some success with git-svn. Meaning, I was able to successfully get a checkout from the repository directly to my laptop. Hooray. But I'd also like to run Linux scripts on the checkout locally. I'm using CygWIN to do this, and the process is kinda buggy and lovely. Most recently, I found out that CygWIN's linux installation of SVN does not think my checkout is a working checkout, because Git-SVN did not generate a .svn directory. svn log doesn't work in CygWIN for the same reason (but it does in Windows SVN in cmd). My questions: (1) is it the case that Git-SVN should have generated the .svn directory and hosed up somehow, and if so what could have caused this, and (2) if Git-SVN on Windows just doesn't generate that directory under any circumstances, what's the best way to make one? I could just WinSCP the one from my dev server over to my laptop (my if-all-else-fails option) but this seems like a bad idea.
|
|
#
?
Mar 31, 2016 15:38
|
|
|
loquacius posted:Ok, so I'm working from a Windows machine in a mostly Linux environment, on a huge (like 900,000 revisions) SVN repository. I've been doing this by using rsync to get my checkout from my dev server to my laptop and SFTP to move my changes back, but this causes issues when big changes to the repository happen, and one of those happened last week, so I'm playing around with alternatives. Using the Windows SVN client (command-line or Tortoise) fails due to some weird syntax somewhere that Windows doesn't know how to deal with; recently I found some success with git-svn. Meaning, I was able to successfully get a checkout from the repository directly to my laptop. Hooray.
Your post implies a few more fundamental questions, though. Did you try simply checking out the repository, fresh, on your Windows system? What do you need to do with SVN tools, that you can't do locally with Git in your git-svn clone? Why are you going through so much pain to work on a local Windows system instead of just using Linux (perhaps locally), to avoid the "buggy and lovely" stuff you're encountering with Cygwin?
|
|
#
?
Mar 31, 2016 16:30
|
|
|
Lysidas posted:
Yeah, using plain SVN to get a checkout would fail due to some command somewhere having the wrong syntax for SVN's Windows client for some reason (I haven't tried it in a while, but I think it involved wildcards). The reason I apparently needed my checkout to be a valid SVN checkout was that one of my company's config scripts seemed to be complaining that it wasn't, but I'm currently not sure whether that was the real reason that script was failing. I don't need the repo to build locally or anything; I just need to run that config script so I can run another one that will keep all of my IntelliJ project files in line for me. And I'm using a Windows laptop because it's that or a MacBook. I am not a Mac user, never have been, and was having a lot of trouble adapting when I initially tried using a MacBook for this job; I was able to convince them to give me a PC laptop instead -- plenty of non-engineering employees use them -- and my previous rsync setup was fine for getting the repo onto the laptop until the first actual big change happened last week. I'm currently in a transition period; once I get my new workflow sorted out I should be fine. It'll certainly be way easier than learning a different OS.
|
|
#
?
Mar 31, 2016 17:15
|
|
|
I'm using the git bash terminal on Windows, and I'm running across something weird I don't think I've seen before. Sometimes when I use git log it shows me the commit history, but then it just has ":" at the bottom where it should give me the $ for my next command. What's that about?
22 Eargesplitten fucked around with this message at 16:26 on Apr 1, 2016 |
|
#
?
Apr 1, 2016 16:22
|
|
|
22 Eargesplitten posted:I'm using the git bash terminal on Windows, and I'm running across something weird I don't think I've seen before. Sometimes when I use git log it shows me the commit history, but then it just has ":" at the bottom where it should give me the $ for my next command. What's that about? It's paging it via less/more, hit "q" to quit out, hit space (or page down I think?) to advance to the next page, you can search it with / ... there's a bunch of keys you can use.
|
|
#
?
Apr 1, 2016 17:07
|
|
|
22 Eargesplitten posted:I'm using the git bash terminal on Windows, and I'm running across something weird I don't think I've seen before. Sometimes when I use git log it shows me the commit history, but then it just has ":" at the bottom where it should give me the $ for my next command. What's that about? There was too much history to show you in one screen and it dropped you into a pager (probably less). Use pageup/down or arrow up/down to scroll, '/' and '?' to search forwards and backwards, and 'q' to quit. Press 'h' for builtin help, or 'man less' in the shell for the complete manual. You can also use 'git --no-pager log ...' to force it off, even if there's more output than will fit on the screen, and 'git --paginate log ...' to force it on, even if there's not much output. (It has to go before the 'log' because it's an option to 'git' itself, not 'git log' -- many other git commands will autopaginate if they generate lots of output.)
|
|
#
?
Apr 1, 2016 17:18
|
|
|
Thanks. I've got very little experience with Unix shells / terminals / bash, I'm just trying to learn it as I go.
|
|
#
?
Apr 1, 2016 17:19
|
|
|
Anyone have the cliffs notes on how to export Atlassian Stash's repos into Gitlab (or vanilla git?). Everything I'm finding is how to import stuff INTO stash.
|
|
#
?
Apr 1, 2016 17:31
|
|
|
revmoo posted:Anyone have the cliffs notes on how to export Atlassian Stash's repos into Gitlab (or vanilla git?). Everything I'm finding is how to import stuff INTO stash. Aren't they just regular repos? Clone them, set a new remote, push.
|
|
#
?
Apr 1, 2016 18:35
|
|
|
Ithaqua posted:Aren't they just regular repos? Clone them, set a new remote, push. drat that's perfect and I don't know why I didn't think of it. Thanks!
|
|
#
?
Apr 1, 2016 18:47
|
|
|
Is it possible, in Clearcase, to have a config spec line that gives me the absolute most recent version of a file no matter what branch it's on? I've tried element * .../LATEST and element * LATEST to no avail so far.
|
|
#
?
Apr 1, 2016 19:19
|
|
|
Is there an easy way to install just the client of git? I have to develop on a FreeBSD server guarded by a jealous dragon of an admin. He doesn't want to install anything that has any kind of daemon component, and rightly so, really. But the FreeBSD port of git insists on installing git-daemon and a git user, and I can't find any variant in the ports that includes only the client. I know it must be possible because there are a gazillion GUI front-ends for Windows/Mac/etc that don't have any server component.
|
|
#
?
Apr 2, 2016 22:34
|
|
|
Data Graham posted:Is there an easy way to install just the client of git? Does he understand that he doesn't actually have to run the daemon, or open any ports for it, or whatever? You should be able to install git in your home directory if necessary, but honestly I'd just move your development work to a VM instead.
|
|
#
?
Apr 2, 2016 22:38
|
|
|
|
| # ? May 12, 2024 19:02 |
|
|
He rages at anything that creates any executable binaries or installs a user, even if you don't have to launch it. I'd love to do a VM, but there are many reasons why I can't, which aren't really relevant.
|
|
#
?
Apr 2, 2016 22:41
|
|