Git's getting in my way again
-
@blakeyrat said in Git's getting in my way again:
I would like that too, but since Git has no way of storing stashes on the server, alas, I frequently end up having to commit in-process code. But we've all had that discussion before.
The git way would be to push them as branches… but with some convention to mark them as “not real branches”, such as prefixing the branch name with
stash/%USERNAME%/or something like that. Whether your corporate processes would be happy with that is another whole ball of wax (and some of those might be enforced with server-side scripting) but git itself wouldn't mind at all. A UI could then potentially present these as separate things, despite them fundamentally not actually being so (a bit like the differences between branches and tags in SVN) though I don't think any current UIs that I'm practiced with would do this. Another approach would be a separate stashes repository (which could be on the same actual server or elsewhere); git handles using multiple servers better than most DVCSs.tl;dr The big problem is not technological, but rather is management. We've all heard that story before…
-
@jazzyjosh said in Git's getting in my way again:
@blakeyrat said in Git's getting in my way again:
Is your method better than doing a merge? For reasons other than aesthetics?
Yes. By rebasing instead of using merge commits you should be able to run a successful build on every single commit. With merge commits, you can end up with broken code between where code diverged and where the merge commit is.
Eh? It's the rebased commits that tend to fail because they were never executed! Observe:
master:
a=1
b=2
c=3branch1, commit 1:
a=1
b=2
c=3branch2, commit2:
a=1
b=2
c=3aif you rebase branch2 on branch1, commit2 will be recreated to read
b=2
c=3aeven though you never wrote this code. You didn't run tests on it either. Of course, if you merge, you introduce the same error. But it will be obvious from history how the error was introduced. And you can test the merge commit which is the first commit where the error was introduced. When you rebase, the error may have been introduced anywhere in a string of rebased commits.
-
@gleemonk There's a method of preventing that which works with any version control system: Test Your Shit.
@blakeyrat or others might have glanced over the part in my previous post where I said that Get Latest in TFVC is actually similar to a git rebase. Thus, the problem you outline can happen there as well, and you should always run some tests before checking in.
EDIT: Oh, you were talking about git rebase and testability. That might take an interactive rebase with "edit" steps to halt after each commit and run the tests again.
-
IME, the rebase-vs-merge debate is one of these things where people make ever-so persuasive arguments that never actually persuade anyone.
However…
Rebasing is about telling lies. The final commit history is not a record of what happened. I prefer merging, and I note that with a merging strategy tools like bisecting only work on primary branches, not some random work-in-progress branch. Some places really don't like to see those WiP branches, but I think they're a good thing as they allow people in a team to monitor what everyone else is up to as well. I imagine that things would be very different with a large team, but that's not the reality of the environment I've been working in for years.
-
@jbert said in Git's getting in my way again:
EDIT: Oh, you were talking about git rebase and testability. That might take an interactive rebase with "edit" steps to halt after each commit and run the tests again.
Sounds like pointless work. What do you do when a test fails during a rebase? If you fix it, your commits down the line might not apply cleanly anymore.
-
@gleemonk said in Git's getting in my way again:
If you fix it, your commits down the line might not apply cleanly anymore.
True, but then again you're rebasing so you might as well amend the broken patches. A good merge tool always helps in any case.
-
@timebandit said in Git's getting in my way again:
When you rebase, what happen is basically this:
All your changes are undone
All changes done on the original branch since you forked are applied to your branch
All your changes are re-appliedThat makes a cleaner history
Except for when it completely breaks things.... Consider the original branch had a method Foo, you branch and add code that calls Foo, prior to each commit you do you due diligence and ensure that code builds and passes tests...
Now before you can merge, the original branch is updated so that Foo is now named FoockedUp....
-
@jbert Sure you can do that, but why would you spend time on this pointless work? You'd be rewriting superseded patches.
Hey I noticed you've removed the new warble()method again.
Yea it was redundant because now you can just call wobble(warble=true)which is clearer.
That's not good because I'm using warble()in one of my feature branches.
Just patch it to use wobble(warble=true)
But when I rebase on your code, my intermediate commits will be broken.
Then don't rebase.
But clean history something! How can I get a clean rebase? I'll have to fix up all the intermediate commits that deal with warble().
Why rebase?
Bisect impossible something. Look it just gives a cleaner history.
A cleaner wrong history.
No, cleaner and more right!
Which buys us nothing.
Look this is really important to me.
-
@gleemonk - Great example....
Having a solid and complete history of exactly what was done and when provides so much value [if one is willing to use the data].
Additionally while "Git has made branching easy" there is still the issues of isolation and eventual merge. An increasing number of companies are adopting branchless development where everyone is committing frequently (often well over a dozen commits per hour total). Achieving this requires certain approaches such as bottom up implementation (mitigate impact), robust testing (catch logical/functional but not semantic conflicts) and feature flags (to control visibility).
-
Some times I just "git reset --soft" and "git commit" again
-
@thecpuwizard said in Git's getting in my way again:
An increasing number of companies are adopting branchless development
That's utterly moronic; I feel stupider just from having read what you've written about it!
Branches aren't a problem, and most of the time if you're working on different features from everyone else on the team then you don't get merge conflicts anyway. But not all changes are so accommodating. Never were. Branches mean you can work on something a bit complex without having to worry about some other person parachuting their crap into your code, or at least not until you combine the branch back (or explicitly decide to copy the changes in from elsewhere). The conflicts that occur happen at times when you are ready for them.
With cheap branches, you don't need to decide if a piece of work is great now. You can just commit it on a branch (hey, it's just storage, right?) and return to that later if you want, and it will still have all the context it ever did. There's simply no need for great amounts of ceremony when branching in any DVCS.
-
@dkf said in Git's getting in my way again:
Branches aren't a problem
Actually they are. If one is following TDD (as an example) then red-green-refactor impacts not just the code in question during the refactor, but also changes that can easily span the codebase. If I have code committed with robust tests, then there is no way anyone is going to be able to "crap into" the code at all.
Remember I am talking about high-velocity teams. With an average team size of 7 and a typical commit interval of 30 minutes, you are talking about over 40 commits per day [each with build and tests].
Another difficulty with branches is determining the order in which (seemingly unrelated) changes occurred. Let's presume we are each going to add a method to a class [no conflicts, simple new blocks sufficiently separated that an auto-merge will work]. Try to determine if your change [on branch A] or my change [on branch B] was made! Also figure out when you are going to do the refactoring to optimize the existence of both (as compared to each individually).
-
@dkf said in Git's getting in my way again:
Some places really don't like to see those WiP branches, but I think they're a good thing as they allow people in a team to monitor what everyone else is up to as well.
Nothing is preventing anyone on my team looking at my personal fork to see what I have in development.
That is, assuming I haven't forgot to grant someone permission to view.
-
@gleemonk said in Git's getting in my way again:
If you fix it, your commits down the line might not apply cleanly anymore.
But when I rebase on your code, my intermediate commits will be broken.You cascade the fix. That's fine. You have to click a couple more buttons on your merge tool. NBD.
-
@dkf said in Git's getting in my way again:
and I note that with a merging strategy tools like bisecting only work on primary branches
Why is that? I've never used bisection with git.
-
@boomzilla I've never needed for it either. I believe it's a technique to locate regressions which can relatively easily be performed by someone who doesn't know the codebase. It could theoretically also be done by a non-coder, but since they'd still need to use git I guess that's a non-starter.
-
@pleegwat I know what bisection is (I've used it with hg and svn), just not with git, so I don't know why the merge thing precludes git bisect.
-
@boomzilla said in Git's getting in my way again:
I don't know why the merge thing precludes git bisect.
My understanding is that the concern is when you "bisected" to find the commit that created the bug, building and running the previous commit to confirm your findings might be impossible if the developer committed half-completed code. You'd have to keep trying older and older commits until you found one that builds.
-
@blakeyrat said in Git's getting in my way again:
My understanding is that the concern is when you found "bisected" to find the commit that created the bug, building and running the previous commit to confirm your findings might be impossible if the developer committed half-completed code. You'd have to keep trying older and older commits until you found one that builds.
Oh, OK. Yeah, I've had to deal with that. You have to use that as a special case when deciding on the range of your bisection.
-
@boomzilla Considering how little I use bisect, it's one of those things where I get the problem, but I don't see it as a big problem.
In any case, if Git didn't lack obvious features in the first place, it'd be no problem.
-
@blakeyrat said in Git's getting in my way again:
Considering how little I use bisect, it's one of those things where I get the problem, but I don't see it as a big problem.
Yeah, I just thought there was some git specific thing going on there. Because git.
-
@blakeyrat said in Git's getting in my way again:
it's one of those things where I get the problem, but I don't see it as a big problem.
Like inability to lock files?
-
@blakeyrat said in Git's getting in my way again:
find the commit that created the bug, building and running the previous commit to confirm your findings
While many teams do not do root cause analysis of bugs, those that do need the ability to reliably perform that operation effectively.
NOTE: Having the commits be focused to a specific element of work [Jira Ticket, TFS Task, etc.] is also key. This is virtually destroyed by many "squash" type operations....
-
Just ran across this little gem, slightly anonymized:
$ git checkout develop Switched to branch 'develop' Your branch is up-to-date with 'origin/develop'. $ git pull origin remote: Counting objects: 21, done. remote: Compressing objects: 100% (21/21), done. remote: Total 21 (delta 15), reused 0 (delta 0) Unpacking objects: 100% (21/21), done. b505189..4209aef develop -> origin/develop * [new branch] release/1.5 -> origin/release/1.5 9176dba..04c4dae releases -> origin/releases * [new tag] version1.4 -> version1.4 Updating b505189..4209aef Fast-forward file1.py | 8 ++++++-- file2.py | 12 ++++++++++-- 2 files changed, 16 insertions(+), 4 deletions(-)
-
@masonwheeler said in Git's getting in my way again:
$ git checkout develop Switched to branch 'develop' Your branch is up-to-date with 'origin/develop'. $ git pull origin remote: Counting objects: 21, done. remote: Compressing objects: 100% (21/21), done. remote: Total 21 (delta 15), reused 0 (delta 0) Unpacking objects: 100% (21/21), done. b505189..4209aef develop -> origin/develop * [new branch] release/1.5 -> origin/release/1.5 9176dba..04c4dae releases -> origin/releases * [new tag] version1.4 -> version1.4 Updating b505189..4209aef Fast-forward file1.py | 8 ++++++-- file2.py | 12 ++++++++++-- 2 files changed, 16 insertions(+), 4 deletions(-)I'm not sure what makes this a gem. Looks like correct behavior (for Git) to me.
-
@heterodox He pulled an update from origin for a branch that was up to date with origin
-
@raceprouk How long passed between those two commands?
You know "up to date" is only meaningful for a very short amount of time.
-
@raceprouk said in Git's getting in my way again:
@heterodox He pulled an update from origin for a branch that was up to date with origin
That "up to date" message doesn't actually involve a fetch from the remote tracking branch (it'd be inappropriate to fetch from the remote on every branch switch on a distributed VCS). git pull does actually contact the remote origin for updates (it's a fetch + merge).
Yes, it's not intuitive behavior but what is, with Git.
-
@raceprouk Well ok, but at least explain it like it is.
His local develop branch was up-to-date with the cached origin/develop branch. Then pull synced the locally cached origin/develop branch with the server and immediately pulls in new changes into his local develop branch.
-
@blakeyrat said in Git's getting in my way again:
@raceprouk How long passed between those two commands?
Presumably a few seconds, otherwise why post it?
-
@raceprouk said in Git's getting in my way again:
Presumably a few seconds, otherwise why post it?
How the fuck would I know why you're posting it? Point is: there's not enough information there to judge anything.
"check branch"
"branch is up to date!"
wait 437284632462 hours
"check branch"
"branch is not up to date!"
"OMG guyz look how broken Git is!"I'm so annoyed you're making me defend Git, too. Stop it.
Keep in mind while posting here that people don't have the telepathic power to:
- Determine how much time passed between two commands
- Determine why another poster posted something
-
@blakeyrat said in Git's getting in my way again:
You know "up to date" is only meaningful for a very short amount of time.
"Up to date" is pretty stupid terminology from Git in this case. It just means you're not behind (i.e. you would be behind if you did a fetch but not a merge/rebase) and you're not ahead (haven't made any of your own commits to the branch that haven't been pushed). It's probably meant to emphasize the latter more.
-
@blakeyrat said in Git's getting in my way again:
How the fuck would I know why you're posting it?
I didn't post it:
@masonwheeler said in Git's getting in my way again:
Just ran across this little gem, slightly anonymized:
$ git checkout develop Switched to branch 'develop' Your branch is up-to-date with 'origin/develop'. $ git pull origin remote: Counting objects: 21, done. remote: Compressing objects: 100% (21/21), done. remote: Total 21 (delta 15), reused 0 (delta 0) Unpacking objects: 100% (21/21), done. b505189..4209aef develop -> origin/develop * [new branch] release/1.5 -> origin/release/1.5 9176dba..04c4dae releases -> origin/releases * [new tag] version1.4 -> version1.4 Updating b505189..4209aef Fast-forward file1.py | 8 ++++++-- file2.py | 12 ++++++++++-- 2 files changed, 16 insertions(+), 4 deletions(-)
-
@blakeyrat said in Git's getting in my way again:
@raceprouk How long passed between those two commands?
You know "up to date" is only meaningful for a very short amount of time.
About 2 seconds.
-
@heterodox said in Git's getting in my way again:
Looks like correct behavior (for Git) to me.
Yup, "checkout" is a local only operation, does not look at the actual remote....
-
@thecpuwizard Then how can it possibly make meaningful reports about my status in relation to the actual remote, is it is purporting to do here?
-
@thecpuwizard said in Git's getting in my way again:
Yup, "checkout" is a local only operation, does not look at the actual remote....
Exactly. Some people don't understand what Distributed means
-
@masonwheeler said in Git's getting in my way again:
About 2 seconds.
Imagine how much less annoyed everybody would have been if you had put information critical to understanding your post inside the post itself.
Although it turns out this is a totally unrelated Git bug, but even if it were the bug you were trying to demonstrate, you didn't include enough information to demonstrate it. And that vexes me.
-
@timebandit said in Git's getting in my way again:
Exactly. Some people don't understand what Distributed means
Toby Faire, the misleading message doesn't help learn what it means.
-
@timebandit said in Git's getting in my way again:
Exactly. Some people don't understand what Distributed means
Maybe they don't care what it means and just want shit to work.
-
@blakeyrat said in Git's getting in my way again:
Imagine how much less annoyed everybody would have been if you had put information critical to understanding your post inside the post itself.
Although it turns out this is a totally unrelated Git bug, but even if it were the bug you were trying to demonstrate, you didn't include enough information to demonstrate it. And that vexes me.
Isn't it sort of implied that, if I show two command-line commands, one immediately after the other, that the one was entered immediately after the other?
-
@blakeyrat said in Git's getting in my way again:
Maybe they don't care what it means and just want shit to work.
I don't care what the manual say, I want to hammer that nail in with my measuring tape.
-
@masonwheeler said in Git's getting in my way again:
Isn't it sort of implied that, if I show two command-line commands, one immediately after the other, that the one was entered immediately after the other?YMBNH. "Implied" is not a thing with @blakeyrat. "Implied" ==
s.
-
@masonwheeler said in Git's getting in my way again:
Isn't it sort of implied that, if I show two command-line commands, one immediately after the other, that the one was entered immediately after the other?
No. Why would it be?
I know you guys all think I'm a retard, but I know how CLIs work at a fundamental level. Until you type something new in, they just sit there doing nothing for hours or days.
-
@blakeyrat said in Git's getting in my way again:
I know you guys all think I'm a retard
How do you know what I think, you can read minds now ?
Edit: grammar
-
@blakeyrat said in Git's getting in my way again:
Although it turns out this is a totally unrelated Git bug
What bug?
-
@masonwheeler said in Git's getting in my way again:
Then how can it possibly make meaningful reports about my status in relation to the actual remote, is it is purporting to do here?
-
@blakeyrat said in Git's getting in my way again:
@masonwheeler said in Git's getting in my way again:
Then how can it possibly make meaningful reports about my status in relation to the actual remote, is it is purporting to do here?
But it is not purporting to do ANYTHING related to the remote. It is saying that the working folder matches the HEAD in the locally cached repository........
-
@thecpuwizard ............................
...........
$ git checkout develop Switched to branch 'develop' Your branch is up-to-date with 'origin/develop'................... I don't see the word "cached" there........................................
-
@thecpuwizard said in Git's getting in my way again:
But it is not purporting to do ANYTHING related to the remote. It is saying that the working folder matches the HEAD in the locally cached repository........
It doesn't say that at all, and since it names the remote in the message even, it's understandable that an end user would think the remote was contacted for status.
