|
Data Graham posted:Is there an easy way to install just the client of git? It sounds like the FreeBSD port has gone out of its way to do that integration, I don't typically see that on my Linux systems, not least because the default policy of git-daemon is to expose every repository, and I usually want to install something with smarter access control management, or just do all that by who has ssh access to the box. quote: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. It wouldn't surprise me in the slightest if they just don't perform any of the integration the platform's service management to configure the git-daemon to serve repositories from a given directory.
|
#
?
Apr 2, 2016 22:46
|
|
only
|
|
| # ? May 12, 2024 18:43 |
|
|
It looks like there is a FreeBSD port called git-lite that probably avoids those things.
|
|
#
?
Apr 2, 2016 22:58
|
|
|
I tried git-lite earlier, but it installed the daemon too.  Thanks anyway.
|
|
#
?
Apr 3, 2016 01:40
|
|
|
Data Graham posted:I tried git-lite earlier, but it installed the daemon too.
|
|
#
?
Apr 3, 2016 10:52
|
|
|
Yup. Feel like I'm in 2002 with an unsanctioned BitchX binary 
|
|
#
?
Apr 3, 2016 15:51
|
|
|
So I'm trying to mess around with Git-SVN on Windows again. I'm working on a very large SVN repository with like a zillion revisions and branches I don't care about, so I'm trying to make sure I get only the trunk. My initial git svn clone command (which happened last week or so) was pointed directly at the repository's trunk; if I run git svn info I get the following output:code:I'd now like to get the updated version of the code -- again, though, only the trunk, because there are so, so many branches that I just don't give poo poo one about. Theoretically, if I run git svn rebase, it should just fetch me the updated code, right? The thing is, when I try doing that, it gives a few files a desultory update before starting to scan through all of the branches like code:so, my question is, why is it doing this (it is not supposed to) and how do I make it only get me the trunk
|
|
#
?
Apr 8, 2016 20:43
|
|
|
I'm considering using git submodules in a project, should I turn back before I'm eaten by a grue?
|
|
#
?
Apr 20, 2016 20:05
|
|
|
I really do not like Git submodules. They seem alright, I just personally hate working with them.
|
|
#
?
Apr 20, 2016 22:12
|
|
|
GrumpyDoctor posted:I'm considering using git submodules in a project, should I turn back before I'm eaten by a grue? Currently using them in a project for releases, to make a release of multiple components without stringing tags of multiple repositories together. It works fine for that. I'm full-on stockholm syndromed though, so I'm not a good judge of things.
|
|
#
?
Apr 20, 2016 22:20
|
|
|
Read all of the documentation for git submodule, and not just enough to get what you need to do done. There's a lot of rough edges, and you'll eventually hit a scenario where you have no idea what to do other than rm -rf your clone if you don't take the time to understand what it actually does.
|
|
#
?
Apr 20, 2016 22:42
|
|
|
Submodules are nice, but be careful using them for dependencies--you can easily get yourself in a diamond situation if you're not careful to design your build system such that you only need a single instance of each submodule in any given working tree, usually associated with the top level repository.
|
|
#
?
Apr 20, 2016 23:07
|
|
|
Right now I have our dependency projects (two of them in our case, a custom Lua build and an internal math library) as two separate repos and anyone who wants to clone our main project just has to clone those too. After reading about the idiosyncracies of submodules, and knowing the training level of our team on Git, I have no will to change this 
|
|
#
?
Apr 20, 2016 23:18
|
|
|
Developing in submodules can be useful but it's easy to wreck yourself cause you're just versioning to commits. Properly separating will slow you down but be easier to track, whereas working in submodules gives you shared code but added complexity in tracking it across multiple projects at different stages.
|
|
#
?
Apr 21, 2016 00:52
|
|
|
I am migrating a subversion repository over to git. They were putting all kinds of binary files into the subversion repository, so it's just crammed full of cruft. I'm talking build output, important dependency libraries, and actual releases of the software. I can nail the big stuff pretty easily, but I'm looking for tips for the tons of small stuff. The build output is generally stuff from Visual Studio, so they tend to follow a pattern of [project]/Release or [project]/Debug, with some allowance for [project]/x64/whatever. It's easy enough to set up a .gitignore to catch stuff like that now, but is there a similar way in one fell swoop to knock out those subtrees? When I'm filtering, I only know how to embed git rm commands for removing targeted, absolute paths; they don't seem to work for relative paths. My shell-fu is weak so maybe it's obvious what to do and I'm just helpless. I'm also wondering what is the most efficient means of doing these mass deletion. I'm assuming I should try to run a minimal number of git filter-branch commands, and just give it monster shell commands to execute, if that's even possible. BTW I tried to use this BFG repo cleaner tool, but I'd wind up with missing blobs after the ensuing GC that I couldn't reconcile.
|
|
#
?
Apr 25, 2016 06:29
|
|
|
Rocko Bonaparte posted:I am migrating a subversion repository over to git. They were putting all kinds of binary files into the subversion repository, so it's just crammed full of cruft. I'm talking build output, important dependency libraries, and actual releases of the software. I can nail the big stuff pretty easily, but I'm looking for tips for the tons of small stuff. git filter-branch --tree-filter 'git rm -r -f --ignore-unmatch Debug' HEAD May work.
|
|
#
?
Apr 25, 2016 15:09
|
|
|
Hughlander posted:git filter-branch --tree-filter 'git rm -r -f --ignore-unmatch Debug' HEAD Heh--I should have qualified I was afraid of using "Debug" because the project is used for debugging. I was still going to try to see if, say, obj/Debug will work.
|
|
#
?
Apr 25, 2016 16:08
|
|
|
When a repository is a mess, consider whether or not you can do a tip migration and maintain the current SVN repository in read-only mode for historical purposes.
|
|
#
?
Apr 25, 2016 16:49
|
|
|
Ithaqua posted:When a repository is a mess, consider whether or not you can do a tip migration and maintain the current SVN repository in read-only mode for historical purposes. ...strongly thinking about it, but even the head has all this crap in it. I'm just coming into it now.
|
|
#
?
Apr 25, 2016 17:39
|
|
|
This is more or less just a git shell command question here in disguise. Can anybody imagine how 'git rm' could get carried away if I provided it the following option on different commands? I am doing a 'git filter-branch -f --tree-filter [Script that runs the git rm commands]' That script is just running a sequence of git rm statements on a list of path strings for me. This is the git rm line: Specifically, I run 'git rm -rf --cached --ignore-unmatch [BUTTS HERE]' I use this list: code:rm some/path/that/has/none/of/the/stuff/in/that/list/oh/god/what/is/it/deleting/from/my/history.what It's a big repo I'm filtering, and I have my backup so I don't have to clone it all down again, so I covered there. But I don't get how that runs off on me, deleting all kinds of crap.
|
|
#
?
Apr 26, 2016 05:47
|
|
|
Hi, I have a question about Git. What does the 'x behind' mean in this screenshot? Is it a problem I should get rid of? If it helps, I'm coming from having a lot of experience with Mercurial, and basically none with Git.
|
|
#
?
May 3, 2016 09:58
|
|
|
That master (your local copy of the branch) is seven commits behind origin/master (the same branch in the remote repository). In other words, you should pull to get your local branch up-to-date.
|
|
#
?
May 3, 2016 10:11
|
|
|
When I try to pull, I have to choose the remote branch to pull. I choose master, and it pulls the new commits if there are any, but then the 'x' just increases. (It's 8 currently.)
|
|
#
?
May 3, 2016 10:14
|
|
|
Your own HEAD is on origin/master, which is pretty weird. Try to checkout master (not origin/master), then pull from that.
|
|
#
?
May 3, 2016 10:21
|
|
|
Ok that did something interesting. Now I have this:
|
|
#
?
May 3, 2016 10:30
|
|
|
I guess that's all normal then? What does the little light blue ball mean right before the 'master' and 'origin/master'? And for that matter, what do those mean exactly? I think 'master' is supposed to be the master branch, right? If I remember correctly, Git branches are pointers to something, and the master branch pointer is pointing to that last commit? What's the origin/master thing then?
|
|
#
?
May 3, 2016 11:04
|
|
|
"master" is the name of the default branch in git. "origin/master" refers to the "master" branch on the remote named "origin", which is the default name for the remote you get when you clone a repository. When you make changes, you commit them to your "master" branch. When you've got a bunch of changes you're ready to share with the world, you push your "master" to "origin/master". That's only possible if "origin/master" hasn't moved since you diverted from it, if others have committed to "origin/master" since then you'll have to either merge your changes, or rebase your changes on top of it. HEAD is the name for your current working copy base, it usually follows the local branch you're working on.
|
|
#
?
May 3, 2016 12:26
|
|
|
Is there any particularly compelling reason not to --prune every time I do a git fetch? I want to start teaching my crew how to start using and sharing branches other than master for un-blessed work but not if they're eventually gonna bug me about cruft getting left behind. (They're still rather struggling with the concept of everyone having their own repos to work in, rather than the shared ClearCase vob of olde) On the same note I know 1.8.something added a config to always prune on fetch, but we're stuck on git 1.7.10 because gently caress video games I guess. Any recourse besides a, I dunno, git pfetch and git ppull alias set?
|
|
#
?
May 3, 2016 15:44
|
|
|
nielsm posted:"master" is the name of the default branch in git. "origin/master" refers to the "master" branch on the remote named "origin", which is the default name for the remote you get when you clone a repository. Ok cool. And what's the little empty blue ball icon thing?
|
|
#
?
May 3, 2016 17:17
|
|
|
uXs posted:Ok cool. And what's the little empty blue ball icon thing? What frontend are you using?
|
|
#
?
May 3, 2016 17:50
|
|
|
SourceTree. There's a screenshot a few posts up.
|
|
#
?
May 3, 2016 18:54
|
|
|
Ciaphas posted:Is there any particularly compelling reason not to --prune every time I do a git fetch? I want to start teaching my crew how to start using and sharing branches other than master for un-blessed work but not if they're eventually gonna bug me about cruft getting left behind. (They're still rather struggling with the concept of everyone having their own repos to work in, rather than the shared ClearCase vob of olde) 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)?
|
|
#
?
May 5, 2016 20:03
|
|
|
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
|
|
|
If correct attribution is important enough, you can start a mailmap file.
|
|
#
?
May 5, 2016 20:25
|
|
|
Thanks. shortlog (and OCD) was the only reason I really cared so I'll jus tset up a mailmap.
|
|
#
?
May 6, 2016 01:24
|
|
|
The only reason not to always prune is that you might still want that reference to a deleted branch. Someone at work accidentally performed a 'git push origin :master' on us once. Luckily, it's a distributed system and we have about 10 machines that still knew what master was. It was easy to push it back. I prune only when I get annoyed at how long my list of remote branches is, and I have a pretty high tolerance 
|
|
#
?
May 7, 2016 04:43
|
|
|
I have a client who is currently using centralized VC (and they're not switching; they would be miserable using Git). However, they have literally 20 GB of images in their application, mixed in liberally among the code. They have a weird content deploy process in place, but it doesn't synchronize across all their enviroments, only production. And it's flaky enough that it's okay, but every build they do that's going to eventually make it to prod has to include all the content, which means they have tons of 20 GB build artifacts clogging up their servers, when 19.8 of the 20 GB is exactly the same and static between every single build they've done. They want to start having content deploy to all environments, and going through a "download from VC, 'build' it by copying to an artifact drop location, then copy to the target server" process is a huge waste of space and effort... not to mention the hoops the developers have to jump through to deal with not syncing up gigs of irrelevant crap. So, my thought was to split the content out into a Git-LFS repo. The folks working on content can commit and push their changes, and the sites can just clone the repo into the appropriate folder. Put a .gitignore file in place for non-content files, they merge from dev -> qa via a PR, an automated process fires that does git clean (to remove deleted and now-untracked files) and git pull on the QA servers. And so on and so forth. Even if cloning the repos directly in the live, running application isn't a great idea, it would be trivial to clone the repo into a directory on the build box and do an incremental sync from the appropriate branch to the appropriate environment. They still can't explain why they can't use a CDN for this, of course. Does anyone have any thoughts on this, or am I being a crazy person? [edit] One other wrinkle I just thought of: They have some content that's "baseline" and some content that's region-specific, since they're multinational and have different versions of their software for US, Canada, various EU countries, UK, etc. All built from the same codebase with different libraries and page templates substituted in, with all the content for specific countries/languages separated into folders like "fr-ca" and "en-us", etc. I'd need to solve the "each region has a different set of content but content people need to see it all as a single unit because that's how they're used to it working" problem. Sounds like a case for submodules. ...and another wrinkle: sometimes the "baseline" content changes, but not for all the regions at once, since the regions are all on different versions and released on different schedules. And this needs to be relatively easy to manage because the people working on content aren't developers, so trying to explain Git to them in the first place will be a challenge, let alone cracking open the Pandora's box of submodules. New Yorp New Yorp fucked around with this message at 17:53 on May 7, 2016 |
|
#
?
May 7, 2016 17:36
|
|
|
I made a pretty embarrassing typo in one of my commit messages. I've updated a lot of the contents, but stuff like the project file and other basic stuff that doesn't get changed still has it. Basically I started trying to write a commit message within my commit message when I had just started out with .git. I want to use this project as part of my portfolio, so I want to make it look nice. Or, since I also cleaned up a really messy file system, would it look most professional to just delete that repo and push the finished project to a new one?
|
|
#
?
May 10, 2016 22:34
|
|
|
I see a lot of git projects that have the first commit as something like "First public release".
|
|
#
?
May 10, 2016 23:22
|
|
|
I think I'll go with that, then.
|
|
#
?
May 10, 2016 23:40
|
|
|
|
| # ? May 12, 2024 18:43 |
|
|
Is there some way in Git to just checkout the latest commit, skipping over all the intermediate ones? I had some coworkers commit things with paths beyond the maximum Windows path length, and now I can't get to the latest version, which doesn't have those files anymore.
|
|
#
?
May 11, 2016 13:45
|
|