|
ToxicFrog posted:Ha ha ha ha ha ha ha ha ha ha Yeah I'm pretty sure it's not a bug either. The way I've come to rationalize it is that the "core functionality" of git checkout is to copy state in the direction of the committed history towards the working copy, and while setting HEAD to another branch might be where it got its name from, that's really just an incidental detail...
|
#
?
Jul 2, 2014 17:15
|
|
|
|
| # ? May 25, 2024 15:39 |
|
|
down with slavery posted:Is this a bad thing? Well, it's inconsistent in a pretty dangerous way. A lot of things you can ask git to do are potentially dangerous, but most of them, including other uses of checkout itself, will refuse to destroy uncommitted work unless you specifically ask them to. And I quite commonly see newbies told things like "git will try very hard to avoid losing your data, commands that don't have -f or --hard in them somewhere are generally safe". Except for checkout, which will "try very hard to avoid losing your data" when used in the 90% case (switching branches) and quietly destroy everything in the 10% case. Once you're aware of this pitfall it's easy to avoid (although I guess you could still have a really bad time if you typo a branch name and the typo happens to form a valid file or directory name), but it shouldn't exist in the first place.
|
|
#
?
Jul 2, 2014 19:16
|
|
|
Mithaldu posted:In fact, just start using git gui to construct your commits and resist the SVNish urge to just click on a file to add it. Commits will sky-rocket in quality and it provides a hilariously convenient way to switch between amending and creation of new commits. When we switched from svn to git a lot of my coworkers gravitated towards SourceTree. I mean it seems nice and all but I felt like it was waaaaay too complicated. Some of them were having a hard time grasping the git flow and I feel like the complexity of SourceTree was contributing to that. In hindsight I wish we had pushed git gui and gitk more. They are so simple and easy to use.
|
|
#
?
Jul 2, 2014 19:24
|
|
|
fletcher posted:When we switched from svn to git a lot of my coworkers gravitated towards SourceTree. I mean it seems nice and all but I felt like it was waaaaay too complicated. Some of them were having a hard time grasping the git flow and I feel like the complexity of SourceTree was contributing to that. In hindsight I wish we had pushed git gui and gitk more. They are so simple and easy to use. I'm pretty fond of git cola, too; it's basically a prettier and more customizeable git-gui.
|
|
#
?
Jul 2, 2014 19:32
|
|
|
fletcher posted:When we switched from svn to git a lot of my coworkers gravitated towards SourceTree.
|
|
#
?
Jul 2, 2014 20:11
|
|
|
^^^ Sourcetree actually does pretty well on that front. FWIW, the few guys we have doing command line commits tend to commit the most extraneous junk. Whereas the guys doing gui commits tend to keep things clean. hg add -a is a wonder drug it seems.
|
|
#
?
Jul 2, 2014 20:21
|
|
|
On the git command line, doing git add without -p should result in public floggings.
|
|
#
?
Jul 2, 2014 20:27
|
|
|
Is there a good visual Git client that can handle word-by-word diffs (generally) or LaTeX diffs specifically? Basically right now I'm using SourceTree, which is great, but it's hard to track (let alone merge) small changes because it causes the entire line to show changed. Sentence-per-line and then explicitly breaking my paragraphs in LaTeX would work I guess, but that's not an entirely satisfactory solution either. What I really want is hunks of just the changed words. Sourcetree also doesn't line-wrap, which is making even finding the word that changed kinda  Overall I do really like it, but I wish it was open-source and/or cross-platform. On Linux I use SmartGit which is acceptable but definitely not as refined.e: Windows, yeah. I broke my paragraphs up into sentence-per-line and I think that'll make SourceTree manageable for now. Paul MaudDib fucked around with this message at 21:17 on Jul 2, 2014 |
|
#
?
Jul 2, 2014 20:29
|
|
|
Paul MaudDib posted:Is there a good visual Git client that can handle word-by-word diffs (generally) or LaTeX diffs specifically? If you're on windows (why would you ask this without mentioning OS?), try TortoiseMerge, either from TortoiseGit or TortoiseSVN. It handles wrapping and word change highlighting well.
|
|
#
?
Jul 2, 2014 20:47
|
|
|
I really like Beyond Compare, which you can set up git to use.
|
|
#
?
Jul 2, 2014 21:14
|
|
|
wwb posted:^^^ Sourcetree actually does pretty well on that front. I still haven't figured out how to work git add -p, so it's always SourceTree for me when I need to make "partial" adds/commits. The git add -p UI is barely better than that of venerable 'ed'.
|
|
#
?
Jul 2, 2014 22:19
|
|
|
nielsm posted:I still haven't figured out how to work git add -p, so it's always SourceTree for me when I need to make "partial" adds/commits. The git add -p UI is barely better than that of venerable 'ed'. Just use git gui and be Zen.
|
|
#
?
Jul 2, 2014 22:47
|
|
|
wwb posted:^^^ Sourcetree actually does pretty well on that front. Are you sure it isn't because they are just morons? Hell I rarely ever do a git add . Most everything is git add -p <filename> That said, I use Sourcetree quite a bit, especially if I can't drop a cygwin terminal on the system. I just wish it handled git svn. HFX fucked around with this message at 04:14 on Jul 3, 2014 |
|
#
?
Jul 3, 2014 04:04
|
|
|
I very infrequently use git add -p. I do, however, habitually use git diff --cached to verify what I'm going to commit before I commit it. I'm not sure why everyone is on the git add -p bandwagon, when 99 out of 100 times you want to commit every change you made in the file.
|
|
#
?
Jul 3, 2014 04:36
|
|
|
Volmarias posted:I very infrequently use git add -p. I do, however, habitually use git diff --cached to verify what I'm going to commit before I commit it. I'm not sure why everyone is on the git add -p bandwagon, when 99 out of 100 times you want to commit every change you made in the file. Sometimes I write more changes then makes sense to add at single time. Verifying what I am commiting goes without saying. But that is a good practice for ever vcs.
|
|
#
?
Jul 3, 2014 05:42
|
|
|
HFX posted:Sometimes I write more changes then makes sense to add at single time. Right, which is when you use git add -p. I'm just surprised at all of the people who seem to be suggesting that you should always use -p.
|
|
#
?
Jul 4, 2014 02:54
|
|
|
I totally agree with people saying git's command line interface needs improvement (although it has been improving over the years) but I do not see what is so hard about "git add -p". That said, I still prefer to use Emacs' Magit package.
|
|
#
?
Jul 4, 2014 09:07
|
|
|
Volmarias posted:I'm just surprised at all of the people who seem to be suggesting that you should always use -p. Volmarias posted:99 out of 100 times you want to commit every change you made in the file.
|
|
#
?
Jul 4, 2014 10:46
|
|
|
Mithaldu posted:It's a matter of default and code review. In practice people who don't do -p don't review their code before committing you seem to not get that git supports a lot of radically different work flows
|
|
#
?
Jul 4, 2014 15:04
|
|
|
Plorkyeran posted:or maybe I use wonderful tools like git diff, and 99% of the time want to commit all changes because there's only one uncommitted change That said, i get that. I know there are some people who have a clue and get the same results by doing different things. On average however people haven't a clue and don't give a gently caress about code review as long as they can close their ticket and go home to a beer. Please understand that i'm not saying every every single developer acts identically and as such people like you couldn't possibly exist; but that my claims apply to most of them, based on observing developers in many different companies and open source projects in the wild over years.
|
|
#
?
Jul 4, 2014 15:45
|
|
|
Mithaldu posted:To be fair, i worded that badly. This is why peer reviewed code reviews need to be a mandatory part of your developer infrastructure, like source control and build servers. If your environment is missing that and you can't get that changed, you need to leave. Otherwise, you end up working at Sulla-Marius 88's job as your liver slowly withers away.
|
|
#
?
Jul 4, 2014 16:53
|
|
|
Got a git qusetion. I'm doing some work in a feature branch on my fork and ran into an issue that needed to be fixed upstream. So I reset my repo back to upstream/master, make a new branch "fix-thingy-upstream", make the commit and pull request. Then I go back to my feature branch, which I want to apply that fix to right away so I can continue to make progress while upstream reviews the pull request. Do I just do a git merge fix-thingy-upstream? Then in a day or two when I rebase my feature branch on upstream/master (after they've accepted my PR), git knows that I already had the changes in "fix-thingy-upstream"?
|
|
#
?
Jul 24, 2014 18:53
|
|
|
fletcher posted:Got a git qusetion. I'm doing some work in a feature branch on my fork and ran into an issue that needed to be fixed upstream. So I reset my repo back to upstream/master, make a new branch "fix-thingy-upstream", make the commit and pull request. Then I go back to my feature branch, which I want to apply that fix to right away so I can continue to make progress while upstream reviews the pull request. Do I just do a git merge fix-thingy-upstream? Then in a day or two when I rebase my feature branch on upstream/master (after they've accepted my PR), git knows that I already had the changes in "fix-thingy-upstream"? Just rebase your feature branch on top of your hot-fix branch right now. A merge does nothing helpful in that situation and only complicates the graph. Generally merges are useful ONLY if you absolutely must retain the information that it happened, or can't afford the time to do a rebase.
|
|
#
?
Jul 24, 2014 23:36
|
|
|
With DVCS (or in general) and very large projects, do people usually separate out installation specific stuff (libraries, scripts, installers etc.) into a stand-alone repository or do you keep it with the respective project?
|
|
#
?
Aug 1, 2014 16:20
|
|
|
Mr. Crow posted:With DVCS (or in general) and very large projects, do people usually separate out installation specific stuff (libraries, scripts, installers etc.) into a stand-alone repository or do you keep it with the respective project?
|
|
#
?
Aug 1, 2014 17:24
|
|
|
hirvox posted:I prefer to keep it together. For example, if you add a new dependency in the new version, you'll probably need to change the scripts/installers as well to handle said dependency. If you keep them separate, there's a chance that your new installation stuff can't install an old version or vice versa. It's an especially good idea if you do your development on branches. Keep the related code together, and you don't have to deal with matching branches in separate repositories.
|
|
#
?
Aug 1, 2014 17:39
|
|
|
The kicker for us has typically been CI -- we really want everything to get there in one package and not have to figure out ways to stitch multiple repos together. One thing we have started doing is doing subrepos for things with big binaries in it. Typically we don't care so much for the tracking data on said binary, only that it can get pulled in with the project in one fell swoop. The project we do care about history. So we can keep the binaries separate and avoid risks of making a repository to big for hosts to deal with / too large to download / what have you. If you pave the files and it doubles the size of the repo you can always choose to just integrate a new subrepo that is clean. It has saved a few things and we've only had this in place for a year or so.
|
|
#
?
Aug 1, 2014 18:22
|
|
|
We're migrating from SVN to git, any gotcha's we should be aware of? And slightly related to my previous question, what are peoples thoughts on submodules in the year of our lord 2014? Any GUI's support it yet and/or any recommended alternatives?
|
|
#
?
Aug 1, 2014 20:10
|
|
|
Mr. Crow posted:We're migrating from SVN to git, any gotcha's we should be aware of? Yes, we gotcha now, muahahaha! quote:And slightly related to my previous question, what are peoples thoughts on submodules in the year of our lord 2014? Any GUI's support it yet and/or any recommended alternatives? I like them, but they're not as powerful as the equivalent in svn iirc.
|
|
#
?
Aug 1, 2014 20:16
|
|
only
|
Mr. Crow posted:With DVCS (or in general) and very large projects, do people usually separate out installation specific stuff (libraries, scripts, installers etc.) into a stand-alone repository or do you keep it with the respective project? Third party libraries/binaries come from our Nexus server (maven proxy/cache). Installation scripts and whatnot are all chef recipes, stored in a separate ops repo. We don't put any binaries in git anymore, learned that one the hard way. Still a couple repos that are > 1GB in size, it's painful.
|
|
#
?
Aug 1, 2014 20:33
|
|
|
Mr. Crow posted:We're migrating from SVN to git, any gotcha's we should be aware of? Read "Git from the Bottom Up". You may not care about the lower-level details of Git, but it will help you immensely when you're trying to understand why it's doing what it does. Mr. Crow posted:And slightly related to my previous question, what are peoples thoughts on submodules in the year of our lord 2014? Any GUI's support it yet and/or any recommended alternatives? Submodules are the devil.
|
|
#
?
Aug 1, 2014 21:48
|
|
|
prefect posted:Submodules are the devil. I like them for the small stuff I do outside of work  quote:Read "Git from the Bottom Up". You may not care about the lower-level details of Git, but it will help you immensely when you're trying to understand why it's doing what it does. Thanks I'll check it out, always like more resources 
|
|
#
?
Aug 1, 2014 21:52
|
|
|
prefect posted:Read "Git from the Bottom Up". You may not care about the lower-level details of Git, but it will help you immensely when you're trying to understand why it's doing what it does. Anyone have reading recommendations along these lines for mercurial?
|
|
#
?
Aug 2, 2014 03:34
|
|
|
Mr. Crow posted:We're migrating from SVN to git, any gotcha's we should be aware of? Completely forget everything about how SVN works and approach git with a blank mind. SVN thinking will delay your coming to terms with git. Learn what each command is actually doing to your repository tree and you'll be golden. Btw I'm not advocating git as superior, I'm just saying that SVN concepts are totally useless and damaging when trying to apply to git, so start from the bottom as if you've never used versioning before.
|
|
#
?
Aug 2, 2014 10:10
|
|
|
Is there any redeeming feature to bzr other than that a bunch of ubuntu infrastructure got built around it before it was clear how big git would win?
|
|
#
?
Aug 2, 2014 12:24
|
|
|
ShadowHawk posted:Is there any redeeming feature to bzr other than that a bunch of ubuntu infrastructure got built around it before it was clear how big git would win? I theoretically like the branch model where branches aren't grouped by repository. Branches as directories is a neat idea, but I've never used it in practice, and I've heard people complain that it doesn't let you re-use object files when you change your branch and want to recompile something that hasn't had many changes. A full hierachy of config files is more useful than git's system-wide, per-user or per-repository, as it lets you arrange your repositories as subdirectories of a project directory, and have a config file for that project directory. Its history model is a bit swiss-cheesed by its format changes. It used to have a history model where you could have external commits in another repository. The result of this is that now there's some repositories where history has been lost, so conversions to git don't work.
|
|
#
?
Aug 2, 2014 13:33
|
|
|
o.m. 94 posted:Completely forget everything about how SVN works and approach git with a blank mind. SVN thinking will delay your coming to terms with git. Learn what each command is actually doing to your repository tree and you'll be golden. Btw I'm not advocating git as superior, I'm just saying that SVN concepts are totally useless and damaging when trying to apply to git, so start from the bottom as if you've never used versioning before. Yeah, basically this. Also bear in mind that it might take a while to really "get" git, so you may not immediately take to really important concepts like constantly using working branches, or hiding the sausage making by rebasing and rewriting before merging into master. Be prepared for a lot of "this is dumb, SVN is better" from everyone before it clicks.
|
|
#
?
Aug 2, 2014 16:17
|
|
|
So this is driving me bonkers, like I said we're working on migrating to git and trying to improve / move to standard layouts for our repository, but we're coming from like 10 years of garbage and non-standard stuff. So I'm trying to git svn clone only the last couple years of history, but I can't get it to work for the life of me because of our non-standard svn repo. Currently the SVN repo looks like this
I can clone just the this-is-our-actual-trunk-to-be-master branch and it becomes the correct master with that branches full history, but we also want a couple of the previous years (on the other branches) in our new history and I'm having a damnable time getting it to work. I've been reading various stuff, especially this and trying to git svn init ... *do stuff to set up the config git svn fetch but this just hangs after the fetch without any output; and similarly when I try to just git svn clone ... --trunk=stuff --branches=path{branch,branch} etc. Any ideas, need more info? Preferably we could just pull the extra branches of history into a linear git history and then purge all the SVN refs (we're going to keep the svn repo around for the full history but want to make as clean a break from it for git as we can). Edit: Regarding the original question, it still stands, although I'm also aware you can use just --trunk and it will try to resolve the entire history (which may be what we end up doing, not the full repo but still probably stuff we don't need). Different question, what is the difference between say, Gitlab, Stash, and something like SmartGit? Having a hard time figuring it out, is it just basically using the standalone client (SmartGit / SourceTree) through a web-interface everyone shares? Mr. Crow fucked around with this message at 19:47 on Aug 8, 2014 |
|
#
?
Aug 8, 2014 17:20
|
|
|
Mr. Crow posted:Different question, what is the difference between say, Gitlab, Stash, and something like SmartGit? Having a hard time figuring it out, is it just basically using the standalone client (SmartGit / SourceTree) through a web-interface everyone shares? They're like github and bit bucket. Places to look at the repos, discuss stuff (comment on code, etc), do pull/merge requests, and handle user permissions. I setup Gitlab where I work, it works pretty well and it's free.
|
|
#
?
Aug 9, 2014 16:56
|
|
|
|
| # ? May 25, 2024 15:39 |
|
|
Something I'm confused on, I understand you can use git-filter-branch (or I guess BFG is recommended too) to prune old files, but something I don't really get is how is it reflected in the history, after the fact? Does it just remove the data and the commit history/integrity remains? E.g. I used BFG to prune our repo of like 600mb of data we don't want or need but I'm not really fully grasping how it changed the log, if at all. I think it's basically just removing the reference to the file, am I wrong? For example, I have binary-file.REMOVED.git-id in old commits, presumably this is just BFG script removing the file references and updating the file name in the actual commit?
|
|
#
?
Aug 12, 2014 20:42
|
|