|
Edison was a dick posted:At work we're working on tools for embedded development, where we're trying to solve this problem by ensuring we don't ever need to check in the result of a build, by making builds fast and always reproducible. We don't yet do Android though, and to tell the truth, we're not there yet for actually applying updates reliably. My projects are binary-reproducible, which is nice, but an android baseline build is a massive process. Plus, even with the entire structure in RAM on a beefy machine, building a single module has a 30sec "think time" before it even starts. So our code lives out of the android tree and the build process merges it with the generated filesystem. Git really isn't the right tool but the entire repo compresses down to 250mb, 90% of the files will never change, and most of the field fixes are text config files - binaries would involve doing a build, which pushes to staging, and then changes get synced to individual field units. I'll deal with it unless there's something that's a much better fit. Since everything else is in git it seems overkill to manage a separate VCS for what's ultimately a minor task - merging in changes from multiple sources.
|
#
?
May 22, 2014 21:39
|
|
|
|
| # ? May 11, 2024 11:43 |
|
|
I'm using Stash and SourceTree and trying to set-up some process documentation for users to start the switch from SVN and running into a dumb issue. Both machines I'm using have the same files and on one I started a new feature to start tracking some. When I try to pull this merged commit back down on the other machine it throws an error stating that it can't do the pull as it would overwrite the files that are already there (even though nothing changed between the files, just added them to the repo). Any idea on how I'm supposed to handle this case?
|
|
#
?
May 23, 2014 14:24
|
|
|
Just delete the files before pulling
|
|
#
?
May 24, 2014 00:08
|
|
|
I like that you can close issues in bitbucket via commit messages like "Fixed #401 - Blah blah blah" but why can't you also put in things like "Issue #401 - Blah blah blah" and have it show up in that ticket?
|
|
#
?
Jun 12, 2014 00:22
|
|
|
https://confluence.atlassian.com/display/BITBUCKET/Resolve+issues+automatically+when+users+push+code
|
|
#
?
Jun 12, 2014 01:46
|
|
|
I've been using SVN at my company for four years. We just switched to Git, and holy gently caress, I literally have never been more angry in my life than when trying to deal with this abstruse bullshit. Within hours after the switch, the log was getting filled up with a bunch of pointless "merge" logs that for some reason have different authors and committers. When I tried to push a commit, I had to do a pull because I was behind, and then because I now had a merge log of my own in my list of commits, it wouldn't let me push (we enforce a specific formatting on commit messages, which the git merge message doesn't follow). So I tried to cherry-pick a commit to push, and that still wasn't working for some reason that I can't divine. I eventually needed to have one of my coworkers on the server side (they've been on git for a while) come over and work some weird magic with resetting and/or rebasing to unfuck my local repo so I could push just the files I wanted. He then showed me how you can make pulls use rebase instead of merge, so this kind of thing doesn't happen. Why that's not the default setting in git, I'll never loving know. I think the worst part is that the logs aren't even in chronological order. If I commit something locally, and then push it two hours later, the timestamp on it still shows the original local commit time. So I can't even tell when people pushed which changes, which makes the job of keeping an eye on our code that much harder. I'd like to think I'm a pretty intelligent software engineer, and I could probably get a handle on things in a few days if I really study it, but it just seems like doing even the most simple tasks is needlessly complex--at least if you try to just use it out of the box.
|
|
#
?
Jun 21, 2014 02:44
|
|
|
here, this will replicate the SVN experience: git config --global --bool pull.rebase true (you probably shouldn't actually do this)
|
|
#
?
Jun 21, 2014 03:35
|
|
|
404notfound posted:I've been using SVN at my company for four years. We just switched to Git, and holy gently caress, I literally have never been more angry in my life than when trying to deal with this abstruse bullshit. Within hours after the switch, the log was getting filled up with a bunch of pointless "merge" logs that for some reason have different authors and committers. It sounds like all of these problems could be solved if you just used git branch. Branching is the lifeblood of git!
|
|
#
?
Jun 21, 2014 04:43
|
|
|
ambushsabre posted:It sounds like all of these problems could be solved if you just used git branch. Branching is the lifeblood of git! That's not gonna cut down on the merge commits any. Personally, I'm wondering why they switched to git at all; if you've got a working centralized workflow with SVN, why switch to a more complicated one with new features generally aimed at distributed use?
|
|
#
?
Jun 21, 2014 06:41
|
|
|
I don't know what ultimately drove the decision to switch to git, but since the server team has already been using it for a while, I think they just wanted to unify all our systems. We're already sharing the same Jira and Confluence systems anyway, so I guess it kinda makes sense, maybe? In any case, it was really god drat stupid to switch while we're in the middle of a project, and I'm trying to get my code checked in and I can't loving figure out how. I'm sure everything will make sense with time, but there was no clear explanation of "this is the equivalent of svn update, this is the equivalent of svn commit," so I'm just kinda flailing about trying to get work done, and the idiosyncrasies of git just keep getting in the way.
|
|
#
?
Jun 21, 2014 08:00
|
|
|
GrumpyDoctor posted:That's not gonna cut down on the merge commits any. Personally, I'm wondering why they switched to git at all; if you've got a working centralized workflow with SVN, why switch to a more complicated one with new features generally aimed at distributed use? From what I've seen, there's a ton of cargo culting going on in the industry. I've had several conversations that went like this: Client: We want to switch from <whatever> to Git Me: Okay, what pain points are you experiencing using <whatever>? Client: None, it works fine, we just want to switch because <vague suppositions about increased productivity> / "everyone else uses it" Me: What Git features are you looking to use that you don't have today? Client: We want to use it exactly the same way we use <whatever> Keep in mind, the teams I'm having these conversations with are generally not particularly sharp. But it happens with alarming frequency.
|
|
#
?
Jun 21, 2014 08:22
|
|
|
Definitely. You can't switch to a different VCS without also changing your procedures. Particularly not when going from a centralized VCS to a decentralized one. There are two different equivalents for SVN Commit, as I see it. One is always rebasing your changes onto master. This gives you commits with mismatched physical and actual timestamps, since they had to be re-written to match the new past history. Still do keep in mind that every commit keeps both timestamps: The one the author claims it was made, and the one it was actually made. The former will be out of order if you use a rebase-based workflow, the latter will not. The other way is to view the merge-to-master as the equivalent to the SVN Commit. The SVN Commit is when you share your changes with the world, but your changes have to be one big lump, with no time-structure to it. The Git merge-to-master (followed by push) is also when you share your changes to the world, but it can have more structure in it, since the separate history of multiple Git commits is kept. Using Git the same way you use SVN is going to be painful, you really should try to change your procedures and re-educate your developers, to use it better: Private branches, feature branches. Merge the master into the feature branch once in a while, merge the feature branch into master when it's finished (or at a good point). It's somewhat more complex, but it keeps your logical history cleaner, since related commits (related by feature/bugfix) are kept together in a branch; compare with SVN where commits related by feature may be distant in the history.
|
|
#
?
Jun 21, 2014 09:15
|
|
|
404notfound posted:I've been using SVN at my company for four years. We just switched to Git, and holy gently caress, I literally have never been more angry in my life than when trying to deal with this abstruse bullshit. Within hours after the switch, the log was getting filled up with a bunch of pointless "merge" logs that for some reason have different authors and committers. Probably because they're working locally, merging other people's work in, and then pushing. Same as they would with SVN, except the merge actually shows up in the history (and you can back out of it if it goes wrong rather than just being completely hosed). quote:When I tried to push a commit, I had to do a pull because I was behind, and then because I now had a merge log of my own in my list of commits, it wouldn't let me push (we enforce a specific formatting on commit messages, which the git merge message doesn't follow). So don't blindly accept the default merge message? git merge and git pull both give you an opportunity to edit the merge message. If for some reason they don't, you can use the --edit option to force them to, or git commit --amend to edit the commit message after the fact. quote:So I tried to cherry-pick a commit to push, and that still wasn't working for some reason that I can't divine. I eventually needed to have one of my coworkers on the server side (they've been on git for a while) come over and work some weird magic with resetting and/or rebasing to unfuck my local repo so I could push just the files I wanted. He then showed me how you can make pulls use rebase instead of merge, so this kind of thing doesn't happen. Why that's not the default setting in git, I'll never loving know. Because most people using git don't care that much about clinging to the illusion that history is linear. If this is really important to you, use git pull --rebase. If you really want to replicate the svn experience, use git merge --squash to collapse all of your work into a single commit just before you push it. quote:I think the worst part is that the logs aren't even in chronological order. If I commit something locally, and then push it two hours later, the timestamp on it still shows the original local commit time. So I can't even tell when people pushed which changes, which makes the job of keeping an eye on our code that much harder.  I'm not sure what else you would expect? The commit timestamp reflects when the commit was made. If it reflected when it was pushed, pushing the same commits to multiple repos leaves you with otherwise-identical commits with different timestamps and commit IDs and the repos can no longer be merged. It would also mean that, say, setting up new hosting for an established repo and pushing to it leaves your entire commit history with a timestamp of whenever the new hosting was set up. That's useful!Again, rebasing/squashing will give you a linear history and ensure that stuff shows up in the history in the same order it was pushed (because you have to relocate it to the end of history before you can push it). If having a linear history is that important to your team, maybe look into server-side hooks to enforce a "no merge commits" policy.
|
|
#
?
Jun 21, 2014 12:33
|
|
|
Nthing rebasing. My workflow is to fetch (NOT pull), examine the commit tree, and rebase/merge as appropriate. Definitely use branches, since they're effectively free, and get used to doing work on feature branches. Don't let this put you off of git. Git's workflows are extremely powerful once you understand what's going on. Volmarias fucked around with this message at 15:21 on Jun 21, 2014 |
|
#
?
Jun 21, 2014 15:19
|
|
|
Volmarias posted:Don't let this put you off of git. Git's workflows are extremely powerful once you understand what's going on. They're powerful like C is powerful. Which is to say they're also confusing and easy to shoot yourself with. 
|
|
#
?
Jun 21, 2014 16:27
|
|
|
404notfound posted:I'd like to think I'm a pretty intelligent software engineer, and I could probably get a handle on things in a few days if I really study it, but it just seems like doing even the most simple tasks is needlessly complex--at least if you try to just use it out of the box. 404notfound posted:
SVN is not git, git is not SVN. I had a tiny meltdown coming to terms with git and I can assure you that you should completely forget about SVN when approaching how git works because the two are quite, quite different. The irony of git is that it's an extremely elegant system, beautiful even- but only if you invest the time into repeatedly bashing your head against a wall and breaking your repositories and generally having a terrible time in order to understand it. Then one morning at 4am, it will click. Like some self-flagellating asetic, the process will bring you closer to the Divine Nature Of Things and make working with people who still don't understand it a complete nightmare. Gotta Love It
|
|
#
?
Jun 21, 2014 18:05
|
|
|
prefect posted:They're powerful like C is powerful. Which is to say they're also confusing and easy to shoot yourself with. Most of the ways git gives you to shoot yourself in the foot you can recover completely from, one exception being like reset --hard. The reflog is your friend.
|
|
#
?
Jun 22, 2014 10:24
|
|
|
Ithaqua posted:From what I've seen, there's a ton of cargo culting going on in the industry. For example, it's annoying in SVN to do a bunch of work, and then have to deal with resolving a merge conflict when you really just want to commit the work you've done for now and deal with the merge later. It's also annoying to have other folks regularly break your code, or having to deal with revision histories having a bunch of "derp" commits. Of course, the solution to these problems is branching, which SVN makes difficult, and amend/rebase, which SVN doesn't support. Annoyingly, the actual outcome I've seen with SVN is commit avoidance. Folks don't want to commit untested/potentially buggy code until "it's time", but due to time constraints the uncommitted code will end up running somewhere anyways. Obviously part of the solution here is to ensure that a VCS checkout/update is required as part of deployment, but having a tool and workflow that makes branching much easier is really helpful.
|
|
#
?
Jun 22, 2014 23:41
|
|
|
Deus Rex posted:Most of the ways git gives you to shoot yourself in the foot you can recover completely from, one exception being like reset --hard. The reflog is your friend. reset --hard is hardly worse than checkout . though, which sounds a lot more innocent.
|
|
#
?
Jun 26, 2014 12:50
|
|
|
I'm starting to use mercurial queues via tortoisehg. I have 3 patches sitting on top of qparent, and I want to commit them to the repo, one by one. How do I do this? It appears no matter which of the patches are pushed/popped, the usual commit button only allows me to qrefresh and qnew. Edit: Found it. You have to right click the patch, go to the Modify History submenu, and click Finish Patch. I have no idea why this is not in the Commit splitbutton. epswing fucked around with this message at 00:11 on Jun 28, 2014 |
|
#
?
Jun 27, 2014 23:20
|
|
|
Vanadium posted:reset --hard is hardly worse than checkout . though, which sounds a lot more innocent. I'm not sure what you are talking about with checkout. If you have uncommited changes it won't do it without a warning about overwriting files. If you have files you have not yet added, it will warn you about those too. ExcessBLarg! posted:Annoyingly, the actual outcome I've seen with SVN is commit avoidance. Folks don't want to commit untested/potentially buggy code until "it's time", but due to time constraints the uncommitted code will end up running somewhere anyways. Obviously part of the solution here is to ensure that a VCS checkout/update is required as part of deployment, but having a tool and workflow that makes branching much easier is really helpful. I find SVN tends to encourage large monolithic commits. Touched 20 files, wrote 1000 lines of code for the new feature that possibly merge with at least 10 files. Yep one commit. Have fun figuring out if something went wrong. My own comment: Git is very difficult to understand if you have only used central code repo's. Once you change the way you think, it becomes easy and central VCS systems feel clunky and bad.
|
|
#
?
Jul 2, 2014 06:42
|
|
|
HFX posted:I find SVN tends to encourage large monolithic commits. Touched 20 files, wrote 1000 lines of code for the new feature that possibly merge with at least 10 files. Yep one commit. Have fun figuring out if something went wrong. I see this happening with Git, actually. There are some people who love rewriting their commits so much that they put everything into one commit and then merge when all the different things are combined and done.
|
|
#
?
Jul 2, 2014 11:31
|
|
|
prefect posted:I see this happening with Git, actually. There are some people who love rewriting their commits so much that they put everything into one commit and then merge when all the different things are combined and done. They don't love rewriting, they're just developers that should not be allowed near computers, due to being actively hostile against codevelopers and their own future selves.
|
|
#
?
Jul 2, 2014 11:53
|
|
|
HFX posted:I'm not sure what you are talking about with checkout. If you have uncommited changes it won't do it without a warning about overwriting files. If you have files you have not yet added, it will warn you about those too. I mean git checkout <path> where <path> is the current directory or w/e, which just throws away all unadded changes in <path> by overwriting them with the state of the index with no warning. That's also really the destructive thing that git reset --hard does, the bit where it makes the current branch point somewhere else is comparatively easy to undo.
|
|
#
?
Jul 2, 2014 12:26
|
|
|
prefect posted:I see this happening with Git, actually. There are some people who love rewriting their commits so much that they put everything into one commit and then merge when all the different things are combined and done. Well, I do this a lot, but it's more of a case of "I don't want to push a broken patch to master because then I can't bisect it". So, if I'm working on a large feature or rewrite that's difficult to split up any other way, I'll certainly make a lot of small commits and plenty of fixups, and then merge it into one. The majority of my fixups have commit messages like "ff", "ff2", "ff6", etc. They're not meant to be pushed.
|
|
#
?
Jul 2, 2014 12:27
|
|
|
Suspicious Dish posted:Well, I do this a lot, but it's more of a case of "I don't want to push a broken patch to master because then I can't bisect it". So, if I'm working on a large feature or rewrite that's difficult to split up any other way, I'll certainly make a lot of small commits and plenty of fixups, and then merge it into one. I found that one useful way to do this kind of thing and keep commits small is to add the code sections of various bits of functionality in single commits, without actually hooking them up to the working code base, and then to make the hooking-up changes a separate commit. I do this by doing almost the same thing you do, a ton of small commits which get squashed together into one, but then i use git gui and git amend to remove lines from that commmit until it's a logical unit, then put the rest into a new commit and repeat the process, thus constructing a history that will be helpful to the guy who needs to find a bug in these changes. (Often helps find errors too.)
|
|
#
?
Jul 2, 2014 13:19
|
|
|
Sure, but sometimes I have a big rewrite that's not too easy to break into pieces. I feel bad for pushing a giant commit, but sometimes that's the smallest logical change you can make.
|
|
#
?
Jul 2, 2014 13:21
|
|
|
Vanadium posted:I mean git checkout <path> where <path> is the current directory or w/e, which just throws away all unadded changes in <path> by overwriting them with the state of the index with no warning. That's also really the destructive thing that git reset --hard does, the bit where it makes the current branch point somewhere else is comparatively easy to undo. That honestly seems like a bug and definitely isn't consistent with checkout at all. Hopefully if you have been committing fairly often, you won't lose too much data. That said, it definitely should not occur by default. As to the reset command, that one probably gets tossed out as a solution when something else would suffice. It did take me a bit to understand what the reset really was doing. Suspicious Dish posted:Sure, but sometimes I have a big rewrite that's not too easy to break into pieces. I feel bad for pushing a giant commit, but sometimes that's the smallest logical change you can make. I will admit this does tend to happen with refactoring. The other item is that it sometimes points too tightly coupled code. Unfortunately, sometimes their is just no way around it. HFX fucked around with this message at 13:24 on Jul 2, 2014 |
|
#
?
Jul 2, 2014 13:21
|
|
|
Suspicious Dish posted:Sure, but sometimes I have a big rewrite that's not too easy to break into pieces. I feel bad for pushing a giant commit, but sometimes that's the smallest logical change you can make.  Otoh, if you really do mean "i can't figure out how to break it down", i'd recommend getting a second set of eyes on it.
|
|
#
?
Jul 2, 2014 13:26
|
|
Suspicious Dish posted:Well, I do this a lot, but it's more of a case of "I don't want to push a broken patch to master because then I can't bisect it". So, if I'm working on a large feature or rewrite that's difficult to split up any other way, I'll certainly make a lot of small commits and plenty of fixups, and then merge it into one. Why not use a branch? Also I'm not sure there's ever a reason to use such bad commit messages, no matter how coupled/complex what you're doing is. At least describe the task in the first message and put "continued" or something in the future ones, "ff1", "ff2", etc. is just a nightmare for the next developer to look at it (if they ever do)
|
|
|
#
?
Jul 2, 2014 13:36
|
|
|
down with slavery posted:Why not use a branch? I think he's saying that the "ff1" commit messages get wiped out when he combines commits for a push later on.
|
|
#
?
Jul 2, 2014 13:43
|
|
|
down with slavery posted:Why not use a branch? How does that help me? down with slavery posted:Also I'm not sure there's ever a reason to use such bad commit messages, no matter how coupled/complex what you're doing is. At least describe the task in the first message and put "continued" or something in the future ones, "ff1", "ff2", etc. is just a nightmare for the next developer to look at it (if they ever do) The only time the next developer will see them is if I make a mistake and push them by accident. It's happened before. But it's not meant to happen, obviously.
|
|
#
?
Jul 2, 2014 13:45
|
|
Suspicious Dish posted:How does that help me? It gives you the ability to push your changes without disturbing others so it's not entirely stored locally. quote:The only time the next developer will see them is if I make a mistake and push them by accident. It's happened before. But it's not meant to happen, obviously. The developer not having access to the individual steps is also a nightmare.
|
|
|
#
?
Jul 2, 2014 14:33
|
|
|
down with slavery posted:It gives you the ability to push your changes without disturbing others so it's not entirely stored locally. I push work in progress branches all the time. down with slavery posted:The developer not having access to the individual steps is also a nightmare. A bunch of boring typo fixes and reformatting isn't really important to warrant their own steps.
|
|
#
?
Jul 2, 2014 14:52
|
|
|
Suspicious Dish posted:A bunch of boring typo fixes and reformatting isn't really important to warrant their own steps. Opinions are divided on that and I am solidly in the camp that the individual commit steps should be visible. Bugs can hide in all kinds of places and the steps being separate makes them easier to spot. Usually because the steps mean time has passed between the work on the boring fixes and the developer might not have been very concentrated during one of those steps.
|
|
#
?
Jul 2, 2014 15:44
|
|
|
aerique posted:Opinions are divided on that and I am solidly in the camp that the individual commit steps should be visible. Bugs can hide in all kinds of places and the steps being separate makes them easier to spot. Usually because the steps mean time has passed between the work on the boring fixes and the developer might not have been very concentrated during one of those steps. I agree with this post. But I can see where the commit-cleaners are coming from. There have been plenty of times I have wished I could have just added some tiny tweak to a change that I had made two seconds earlier.
|
|
#
?
Jul 2, 2014 15:48
|
|
|
HFX posted:That honestly seems like a bug and definitely isn't consistent with checkout at all. Hopefully if you have been committing fairly often, you won't lose too much data. That said, it definitely should not occur by default. Ha ha ha ha ha ha ha ha ha ha  No, this is not a bug. As much as I like git, its UI is an inconsistent trainwreck and "git checkout" meaning both "switch to a different branch or commit (and abort if this can't be done safely" and "'check out' specific versions of files into the working tree, obliterating whatever is already there without confirmation" depending on how it's invoked is entirely deliberate. gently caress knows why. git checkout master will switch branch to master (and check out its contents into the working tree) if and only if this can be done without losing untracked files/changes. git checkout -- . will nuke your entire working tree instantly and without confirmation, equivalent to git reset --hard HEAD.
|
|
#
?
Jul 2, 2014 16:21
|
|
ToxicFrog posted:Ha ha ha ha ha ha ha ha ha ha Is this a bad thing?
|
|
|
#
?
Jul 2, 2014 16:24
|
|
|
prefect posted:I agree with this post. git commit --amend It also taught me how to spell amend. (Ok, two hyphens so only one m)
|
|
#
?
Jul 2, 2014 16:31
|
|
|
|
| # ? May 11, 2024 11:43 |
|
|
Hughlander posted:git commit --amend 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.
|
|
#
?
Jul 2, 2014 17:08
|
|