|
oiseaux morts 1994 posted:But we can go back to a specific commit, and change date, author, commit message, right? Does that mean the original is deleted and a new commit is made? If so, then what if said original commit is a parent of another commit? quote:So in the below case, if it isn't the timestamp that defines the order, what is the nature specific to one of the parents of C6 (either C4 or C5) that determines the order? Sure, 5 is greater than 4 in this example, but they're just labels in this case, they could easily be called * and / and have no inherent order. Or do the parent attributes for the commit object contain some hitherto unknown information, or is it a property of the graph structure in some way?
|
#
?
Nov 15, 2013 11:48
|
|
|
|
| # ? May 26, 2024 23:12 |
|
|
welcome to hell posted:A new commit is created, but the original commit still exists in the repository. It's just no longer connected to the branch in any way. Understood, but say I have C1 <- C2 <- C3, and I modify the commit message for C2, I can't possibly have C1 <- C2' <- C3, because that would require C3 to be modified. So I would imagine something like this pre:*foo C1 <- C2 <- C3 pre:C2 <- C3 |-----| v *foo C1 <- C2' <- C3' o.m. 94 fucked around with this message at 12:46 on Nov 15, 2013 |
|
#
?
Nov 15, 2013 12:44
|
|
|
oiseaux morts 1994 posted:Seems mental, especially if you wanted to edit a commit way back, you'd create a massive chain of copies of your original commits. But I suppose if the old commits are garbage collected anyway, it's a viable method? Sorry, I appreciate this is really pedantic but stuff like this just sets off my goony autism like nothing else That is exactly how it works. Bear in mind that commits themselves are tiny, and the file data they point to is in content addressed storage and thus deduplicated. So if the commit contents are mostly the same the space cost is minimal even before garbage collection.
|
|
#
?
Nov 15, 2013 14:21
|
|
|
aerique posted:You seem quite insistent to rationalize why you should not invest time in Git. While you can just keep on using SVN if you want to. I use git every day, but I see a lot of blanket statements in here like 'git is just better' and like all blanket statements those are false. git has a different feature set, not a better feature set.
|
|
#
?
Nov 15, 2013 15:20
|
|
|
Gul Banana posted:speaking of git! does anyone know about good git server/wrapper software that is *easy to host on Windows*? Alternatively HG works reasonably well on windows and is reasonably easy to setup -- see http://www.jeremyskinner.co.uk/mercurial-on-iis7/ Bonus points is that the windows clients are better too.
|
|
#
?
Nov 15, 2013 15:25
|
|
|
Plorkyeran posted:The only documentation for it I could find is a handful of out-of-date blog posts and an expensive book, but all of the stuff for that screenshot can be found at https://github.com/Aegisub/Aegisub/tree/master/aegisub/build. The important bits are Aegisub.xml, which defines the fields which will be settable via the UI, Aegisub.targets, which imports that file and adds it to the project settings, and DefaultConfiguration.props, which sets the default values for all of the settings. Actually, getting this set up was pretty easy (finding that old blog post helped). It turns out that the properties you establish will just live in macros, so I didn't need to finagle with targets or build orders or anything. Thanks so much for your help.
|
|
#
?
Nov 17, 2013 20:49
|
|
|
What's the easiest way to view the differences between two git branches using a GUI? Essentially, I want to be able to browse through the results of code:code:
|
|
#
?
Nov 23, 2013 04:19
|
|
|
NoDamage posted:What's the easiest way to view the differences between two git branches using a GUI? gitk can do this; open it up, select one branch, then right-click on the other and "diff this->selected" (or vice versa). I think there's also a way to get it to pass all the filepairs to difftool at once (if your difftool supports that), but I don't remember where I read it.
|
|
#
?
Nov 23, 2013 04:52
|
|
|
After a week of casual tinkering with Git, everything finally 'clicked' and oh my God Git is so sick!
|
|
#
?
Nov 26, 2013 09:22
|
|
|
Woodsy Owl posted:After a week of casual tinkering with Git, everything finally 'clicked' and oh my God Git is so sick! I know, right? It takes some getting used to and some understanding, but now I never want to go back to another CVSC.
|
|
#
?
Nov 26, 2013 13:38
|
|
|
Volmarias posted:I know, right? I'm still trying to work out how to use it, but I get the idea behind it. I use command-line git to do my commits and whatever and then I close it afterwards. When I open it back up, will git automagically checkout the master local repository? That is to say: I open the git command line,init a repository, add some files, commit, and then exit the command line interface. Then I edit some of the files. Then I fire up git in a command line again. Will git automatically checkout the last commit into the working directory, and therefore remove my changes to those files? Also, does git automatically track everything? This is a correct statement; "git commit" only commits newly added files, "git commit -a" only commits tracked-and-changed files" ? Is it just me or is the git documentation really obscure? The learning-curve seems pretty steep, but I know it will be worth it if I keep plugging away at it.
|
|
#
?
Nov 26, 2013 15:47
|
|
|
Woodsy Owl posted:I'm still trying to work out how to use it, but I get the idea behind it. No, git won't override your working directory unless you tell it to. Any new files that you add to your working directory will be there when you come back to it in the command-line. Git just tracks the stuff in the repo and lets you know if your working directory differs in any way (git status). git commit -a will do a commit that adds all changes, tracked or otherwise. If you want to only commit file that are being tracked and changed you would do git add -u to stage those changes, then git commit to commit what you've staged. This two step process is how I would suggest you work with git, at least at first.
|
|
#
?
Nov 26, 2013 15:59
|
|
|
Marsol0 posted:No, git won't override your working directory unless you tell it to. Any new files that you add to your working directory will be there when you come back to it in the command-line. Git just tracks the stuff in the repo and lets you know if your working directory differs in any way (git status). So "git commit -a" is equivalent to "git add -u" + "git commit" ?
|
|
#
?
Nov 27, 2013 04:54
|
|
|
Woodsy Owl posted:So "git commit -a" is equivalent to "git add -u" + "git commit" ? Almost. git commit -a will include untracked files as well, while git add -u; git commit will only include tracked file.
|
|
#
?
Nov 27, 2013 05:36
|
|
|
Marsol0 posted:Almost. git commit -a will include untracked files as well, while git add -u; git commit will only include tracked file.
|
|
#
?
Nov 27, 2013 09:17
|
|
|
welcome to hell posted:This is incorrect. commit -a does not include untracked files. Hrm, I guess you're right. I was under the impression that it did. Thanks for correcting me. Sorry for any confusion.
|
|
#
?
Nov 27, 2013 13:15
|
|
|
How can you list the files that are currently being tracked in a git repository? git status seems to only show files that haven't yet been added...
|
|
#
?
Nov 28, 2013 07:38
|
|
|
I think git ls-files is what you want.
|
|
#
?
Nov 28, 2013 11:29
|
|
|
Woodsy Owl posted:How can you list the files that are currently being tracked in a git repository? git status seems to only show files that haven't yet been added... Git status shows the difference between the most recent commit on your branch, what you've staged, and what changes are unstaged. Use git-ls as suggested, and filter on unmodified files.
|
|
#
?
Nov 28, 2013 16:50
|
|
|
Woodsy Owl posted:I use command-line git to do my commits and whatever and then I close it afterwards. When I open it back up, will git automagically checkout the master local repository? That is to say: I open the git command line,init a repository, add some files, commit, and then exit the command line interface. Then I edit some of the files. Then I fire up git in a command line again. Will git automatically checkout the last commit into the working directory, and therefore remove my changes to those files? It's worth reading up on HEAD. Every repository has a HEAD, which points to a branch and thus follows it - when you make a commit in a branch, the branch pointer moves to the new commit, and thus HEAD references the new commit as well. pre:C1 <- C2 <- C4 (master <- HEAD)
|
-- C3 <- C5 (mybranch)
pre:C1 <- C2 <- C4 (master)
|
-- C3 <- C5 (mybranch <- HEAD)
|
|
#
?
Nov 28, 2013 17:53
|
|
|
All the git command line window does is host a bash session, and that bash session doesn't do anything with repositories or working directories except run the commands that you give. Neither the window nor bash have anything to do with maintaining the state of git repositories. Individual git commands do that.
Gazpacho fucked around with this message at 23:54 on Nov 28, 2013 |
|
#
?
Nov 28, 2013 23:44
|
|
|
Solid. You guys got me all squared away. I'm working my way through this documentation now. Everything's starting to come together in my mind.
|
|
#
?
Nov 29, 2013 06:16
|
|
|
This isn't so much a git question as a GitHub question; I know you need a README.md to be able to clone a repository but how exactly do you format it? Is there a certain standard that should be followed? How is the README.md parsed on GitHub? How do you write a good README? edit: I am working through https://github.com/github/markup/edit/master/README.md and figuring it out, more or less. Woodsy Owl fucked around with this message at 11:13 on Nov 29, 2013 |
|
#
?
Nov 29, 2013 11:09
|
|
|
Woodsy Owl posted:This isn't so much a git question as a GitHub question; I know you need a README.md to be able to clone a repository but how exactly do you format it? Is there a certain standard that should be followed? How is the README.md parsed on GitHub? How do you write a good README? Its markdown, the syntax can be found here http://daringfireball.net/projects/markdown/syntax
|
|
#
?
Nov 29, 2013 11:24
|
|
|
Woodsy Owl posted:This isn't so much a git question as a GitHub question; I know you need a README.md to be able to clone a repository but how exactly do you format it? Is there a certain standard that should be followed? How is the README.md parsed on GitHub? How do you write a good README? Wait, what? I clone my own repos all the time without a README.md...
|
|
#
?
Nov 29, 2013 18:32
|
|
|
I think github either makes you add one or you have to have at least one file in the repo, so they suggest that.
|
|
#
?
Nov 29, 2013 20:08
|
|
|
Thermopyle posted:Wait, what? I clone my own repos all the time without a README.md... I was taking this pre:Initialize this repository with a README This will allow you to git clone the repository immediately. Also, GitHub is suggesting I call my new rep cloaked-octo-shame. Sounds kinky. edit: bugfree-dubstep, petulant-wookie, north-american-hipster Woodsy Owl fucked around with this message at 02:40 on Nov 30, 2013 |
|
#
?
Nov 30, 2013 02:37
|
|
|
iirc you can't have an empty directory in git so if you want to be able to clone a repo it can't be empty.
|
|
#
?
Nov 30, 2013 03:18
|
|
|
Empty repos are a special case that git does handle, and will normally allow you to clone. They don't have any branches or commits though, so they don't always behave as you might expect. It's just more straightforward (and possibly more backward compatible) when you clone a repo with real branches/commits. Also, github displays readme files directly below the file listing on the main repo page, so they encourage you to have some form of readme no matter how you create the repo. When creating new repos I prefer to initialize it and commit locally, then create the repo on github and add that as a remote. But it all amounts to the same thing in the end.
|
|
#
?
Nov 30, 2013 08:17
|
|
|
With regards to git, how common are other VCS solutions these days? Is it worthwhile to master SVN or whatever else?
|
|
#
?
Nov 30, 2013 09:54
|
|
|
Woodsy Owl posted:With regards to git, how common are other VCS solutions these days? Is it worthwhile to master SVN or whatever else? Git is becoming more and more prevalent. Older, slower moving companies will still be using CVS or SVN so it would be good to have some experience with them but I would not "master" them. Especially since they do not really offer anything over Git.
|
|
#
?
Nov 30, 2013 11:37
|
|
|
Woodsy Owl posted:With regards to git, how common are other VCS solutions these days? Is it worthwhile to master SVN or whatever else? It's worthwhile if your job uses SVN and does not plan on switching any time soon. It's kind of a tough thing to answer because it's like asking "with regards to Python, how common are other programming languages these days? Is it worthwhile to master Perl or whatever else?"
|
|
#
?
Nov 30, 2013 17:10
|
|
|
Volmarias posted:It's worthwhile if your job uses SVN and does not plan on switching any time soon. It's kind of a tough thing to answer because it's like asking "with regards to Python, how common are other programming languages these days? Is it worthwhile to master Perl or whatever else?" Wow, I didn't consider that. It's kind of a stupid question, in hindsight.
|
|
#
?
Dec 1, 2013 03:01
|
|
|
Woodsy Owl posted:Wow, I didn't consider that. It's kind of a stupid question, in hindsight. It's not a stupid question, it's just a little asinine. You should definitely understand the difference between CVCS and DVCS, since it will let you talk more intelligently about your choice to use a DVCS, and if you need to use SVN etc you won't be completely blindsided. That said, I personally wouldn't recommend more than a working familiarity unless you'll be using it frequently.
|
|
#
?
Dec 1, 2013 03:17
|
|
|
While there are many factors to consider in any given workplace, a company that still uses CVS as its main version control is broadcasting that they don't have any kind of technology leadership in place, and that they see fit for devs to manually wrestle with problems (like version skew) that have had affordable automated solutions for over a decade. e: meaning the Concurrent Versioning System Gazpacho fucked around with this message at 05:41 on Dec 1, 2013 |
|
#
?
Dec 1, 2013 04:23
|
|
|
For the specific case of git and svn, git-svn is good enough that you can mostly get away without knowing how to use svn.
|
|
#
?
Dec 1, 2013 04:30
|
|
|
Gazpacho posted:While there are many factors to consider in any given workplace, a company that still uses CVS as its main version control is broadcasting that they don't have any kind of technology leadership in place, and that they see fit for devs to manually wrestle with problems (like version skew) that have had affordable automated solutions for over a decade If you mean CVS as in centralized versioning, I think that companies can have compelling reasons to want to use a CVCS, such as stronger controls (it's more difficult to accidentally leak a full SVN repo than a git clone) without being shortsighted. If you mean CVS as in CVS, then yes, that's a good sign that you should run, not walk, out of the interview.
|
|
#
?
Dec 1, 2013 05:01
|
|
|
Using git, if I have a tracking branch to remote A, can I push that to remote B such that cloning from B will retain references to A? I'm using git-svn to migrate a messy work repo to git, and it tracks svn branches as remote branches. Now I'm pushing to a new git repo, but I'd like a way to track and merge the svn changes that are bound to come in during the interim. Ideally I'd like to do this without having to maintain the original git-svn working copy.
|
|
#
?
Dec 2, 2013 08:03
|
|
|
I have a decent working knowledge of Git and Mercurial, but rarely use anything that would clean up branches & histories as the projects are typically only with 1 or 2 people. I'm sure theres a lot of this that would be personal style, but is there something like a best practices guide to managing branches and history for maintainable projects. The ability to rewrite history and clean it up is obviously very powerful after the dirtier working state has been cleaned up, but I haven't really ever seen much more than a users manual for version control, so I'd like to know if there's good resources to pick up this stuff. Maluco Marinero fucked around with this message at 08:23 on Dec 2, 2013 |
|
#
?
Dec 2, 2013 08:16
|
|
|
|
| # ? May 26, 2024 23:12 |
|
|
fartmanteau posted:Using git, if I have a tracking branch to remote A, can I push that to remote B such that cloning from B will retain references to A? I think that it's possible to recreate the state of your original import, but realistically I'd say that it's easier to say better safe than sorry, and just keep it around until you're reasonably confident that everyone has migrated. Maluco Marinero posted:I have a decent working knowledge of Git and Mercurial, but rarely use anything that would clean up branches & histories as the projects are typically only with 1 or 2 people. I'm sure theres a lot of this that would be personal style, but is there something like a best practices guide to managing branches and history for maintainable projects. You might want to take a look at http://sethrobertson.github.com/GitBestPractices/#sausage . I'm personally a proponent of hiding the sausage making, and I consider the ability to rewrite your own history (and rebase -i in general) to be a killer feature of git, but I'm a bit of a perfectionist and it has bitten me in the past on occasion.
|
|
#
?
Dec 2, 2013 16:49
|
|