|
Janin posted:It tracks file renames, which is *very* useful for versioning non-text (images, compressed files, external libraries, etc). Can't comment on the rest (besides making a snide "who gives a poo poo about Windows?" taunt, and mention that Mercurial is supposed to have good Windows support too) but Git tracks file renames just fine, as far as I can tell? I'm afraid Bazaar is looking like it's going to lose out to Mercurial and Git, sadly for Bazaar users / Ubuntu / Canonical. I don't know anybody who's choosing it over the other two unless they were an early adopter before Mercurial basically overtook it in popularity. Python itself has gone with Mercurial. Etc. Which I find interesting, since even a year ago (or even less) it seemed more like a 3-way tie with no clear winner. I wonder if Git/Mercurial will ever see a clear winner or if they'll end up balancing out somehow.
|
#
¿
Apr 17, 2009 01:29
|
|
|
|
| # ¿ Apr 27, 2024 23:24 |
|
|
Janin posted:Git only tracks file contents, so when a binary file is both renamed and modified, it's usually treated as a completely different file. This can make it difficult to track things like "who added this image to the project?". Right, my point is that I think you're working off of old info. I just made a random binary file with dd and then 1) added it as-is, 2) renamed it without modifying it, and 3) renamed AND modified it in the same commit. During that process, git status was showing me the right information (i.e. detecting a rename instead of showing an add + delete) and git log is capable of following the file's entire history: code:
|
|
#
¿
Apr 17, 2009 15:50
|
|
|
haywire posted:Anywho, I'm having a bit of an issue with git, basically every time something gets pulled from a repo, git resets the permissions to rwxr--r-- which sucks, because the group (users) needs to be able to work on the files. Why is this happening? How can I stop it? Unfortunately this is due to a core aspect of how Git does its thing -- it cares primarily about chunks of text and not so much about the actual files/directories on disk. A relatively decent answer I found googling around was actually here on StackOverflow. Kind of surprised they don't address this in the official Git FAQ; perhaps I was searching for the wrong phrases or something v  vAnyway, if it's happening on every pull, that strikes me as a tad odd -- I don't recall having that issue myself. Assuming it's happening due to files being newly created somehow, you could try working around it by setting your umask to something more permissive (e.g. 0002), or seeing if setting the setgid bit on the top level directory helps any (which should mean that new files created get that directory's group-ownership.)
|
|
#
¿
Sep 15, 2009 16:32
|
|
|
floWenoL posted:Why are multiple people working on the same repository? Checkout on a staging or production server, maybe? That's where I run into SVN multiuser permissions issues, anyway. Person A checks repo out, now person B can't run an svn up to deploy on a day when Person A is out of the office or whatever. Granted, we don't "work on" the files in this situation (that's a huge no-no) but the problem is the same.
|
|
#
¿
Sep 19, 2009 03:06
|
|
|
chips posted:The problem comes when I checkout the "master" branch again and the "tasks/" directory is still there in the file system. I've set git up to ignore .pyc files, since they're just compilation objects and I don't want them hanging around, but doing this means that they're still hanging around and propping up the old directory structure. Shall I add them? Will it pollute the svn repository when I push the changes back up? Is your problem that the directory exists, period, or is it that it's showing up in your git status output when in the master branch? As you mentioned, the latter can be fixed by ignoring it: you can create a top level .gitignore file, which is itself versioned, and thus can differ between branches. The former can be "fixed" by running git clean (which has options, read up on 'em, you'll probably need to do e.g. git clean -fd) but I can't recall offhand if you'd need to do that every time you checkout master, or if there's a shortcut for it, or what.
|
|
#
¿
Sep 30, 2009 17:41
|
|
|
Ferg posted:Does anybody know how exactly a git graph is built out? I figured it'd be a fun project to build a graphing tool, something to compliment a git tool I've already built, but I can't seem to find any information that really explains the concept behind it, at the lowest possible level within git. Don't most of the various tools print out parent and child SHAs all over the place? or is that not what you're looking for?
|
|
#
¿
Oct 16, 2009 00:03
|
|
|
Yea, that only makes sense if one of them has incorrect remote settings, or has incorrect tracking/merging settings for their local verison of the master branch. Double check that stuff and you'll hopefully find something amiss. Or print out your remotes / cat your .git/config, and share with us.
|
|
#
¿
Nov 15, 2009 00:22
|
|
|
Thermopyle posted:I've forked someone's project on github with the intention of them pulling my changes back in eventually. Part of my work involves adding a library written by me that's also hosted on github. A) You actually can't do it quite that simply, you need to use git submodules, Google around for that phrase and you'll find plenty of tutorials. It's basically declaring you want other git repo URL X to be rooted at path Y in the current repo, and a few management commands to set it up and pull it down. B) Depending on the language you're using, it may be better to release your library on the language's package distribution channel and then just specify it as a dependency in the project's metadata. For example, in Python, add the lib to PyPI and its name to your project's setup.py; for Ruby, add it to Rubygems and update your Gemfile or whatever is in vogue these days for that stuff. Etc. You can often just specify a Git repo directly in such tools as well, bypassing the "host it on a package network" step entirely, but the end result is the same -- a copy of the library is installed into your language library path instead of inside your own codebase.
|
|
#
¿
Oct 14, 2010 21:03
|
|
|
Thermopyle posted:Say I use git submodule. How does that work for the root project's maintainer and for people who clone from the root project? Is it transparent to them, and they just do a regular git clone? IIRC you do still need to do submodule init/update after cloning, but I actually don't work with submodules a ton, and they apparently got some fixes to make them more usable in recent Git versions, so I'd either experiment or read the man pages closely.
|
|
#
¿
Oct 15, 2010 00:13
|
|
|
epswing posted:We're using mercurial. Is this what mercurial's "branches" are for? Not an Hg user but this is not really specific to any one VCS: yes, you want branches, for this very reason. The typical setup I see is having a release branch for each "line" of development, and then some number of "developing the new hotness" branch(es) (which varies a lot but that's mostly orthogonal to this). So in your case, at this point in time, you "should" have had a branch each for 4.0, 4.1, and 4.2. Then you would've applied your fix to the 4.0 branch and tagged 4.0.1 to distribute to anybody using 4.0, and repeated that process by re-applying that patch to 4.1 and 4.2, and cutting 4.1.1 and 4.2.1 as you mentioned. And of course, applied it to the branch you're using for what will become the 4.3 line of development. The benefit of this kind of approach is hopefully obvious: you have independent clones of your source tree, branched off at the point in time where they were released, available for additional commits as you write or backport bugfixes. Tags alone are not usually sufficient for this as they typically just point to one single snapshot in time (as you've noticed).
|
|
#
¿
Jan 12, 2011 22:03
|
|
|
epswing posted:This right here is the missing link in my brain, how do I do this? There's two angles to this: how to determine what changes to make to each branch to fix "the problem", and how to actually apply those changes. Usually you're lucky and the chunk of code you fixed the bug in has not changed a lot, or at all, from 4.0 to 4.3. In that case, you can just take the same literal change (i.e. you could make a diff/patch file out of it) and "apply" it to each branch as a separate commit. Manually that would be "check out 4.0 branch, edit file X with the change, then check out 4.1, edit file X with the change, [repeat for other branches]". VCSs often have tools to make this easier, Git lets you "cherry-pick" a commit from one branch and apply it to another one with one command -- I bet Mercurial can too. If you're not lucky, the code has changed such that the fix to 4.0 doesn't apply cleanly to later versions, and so what it means to "fix the problem" might be different -- only you can figure out what changes have to be made. Maybe your function got refactored so you have to go hunt down where those two lines that have the bug, ended up. Whatever. The mechanical process is the same: check out one branch, make the change, commit; check out the next branch, make maybe a different change to the same effect, commit; repeat. Once you're done with all this crap you've got one new shiny bugfix commit in each release branch, each saying something like "Fix bug #123", or maybe "Ported fix for #123 from the 4.0 branch". And now you can throw 4.1.1 at somebody and it has the fix. The entire point is to separate your released versions so you can apply changes to them independently of one another.
|
|
#
¿
Jan 13, 2011 00:07
|
|
|
|
| # ¿ Apr 27, 2024 23:24 |
|
|
Modern Pragmatist posted:Git question here. You want release branches. git checkout -b 1.0 v1.0.0 will make a new branch based off of how your repository looked when you tagged v1.0.0, and you can then put bugfixes in there instead of in master. This lets you break poo poo in master and continue cutting bugfix releases (since you can just tag off of the 1.0 branch now). You can also usually merge 1.0 into master pretty easily and thus 1.1 or 2.0 or whatever will still contain all the bugfixes from your 1.0.x line.
|
|
#
¿
Apr 28, 2011 18:01
|
|