11 ms·

If you’re including rebasing, then I can believe this (rewriting history is nuanced and complex), but I’m not sure I’d be teaching that straight away. My recomm

by rmccue 3y ago

If you’re including rebasing, then I can believe this (rewriting history is nuanced and complex), but I’m not sure I’d be teaching that straight away. My recommendation is usually only to start using rebase once you’re already very familiar with the rest of git, since it’s almost never necessary to achieve what you want. Also, bisect is definitely not common, and the vast majority of my colleagues wouldn’t know it exists; I’d place it into the look-it-up-if-needed category.

cassianoleal 3y ago
> bisect is definitely not common Agree. > I’d place it into the look-it-up-if-needed category. Disagree. Bisect is so useful in so many different scenarios that learning about it and the basics of how to use it is a great way to get people into git. Obviously not right at the beginning of their learning curve but as soon as the basics have been covered satisfactorily.
- aaomidi 3y ago
  I wish more people would know about bisect mainly because they’d design the toolchains to actually support testing when you’re doing bisect.
jedberg 3y ago
> I’d place it into the look-it-up-if-needed category. Knowing how to use git bisect is what elevates a programmer to the next level. Just understanding how it works gives you a new way to reason about bug finding and fixing (or feature development using old and new), and then actually using it can make you a bug fixing master.
- pydry 3y ago
  It feels like a weird and magical superpower but realistically I find use for it about once every 6 years and even then I'm fairly sure I could have done without it. This was not my impression when I first learned about it. I thought I'd be using it all the time.
  - jedberg 3y ago
    > and even then I'm fairly sure I could have done without it. Just understating how git bisect works is the real superpower. The tool is a nice add on, but often you're right, is easier to bisect by hand by going to a known working commit and then doing a smart bisect based on the code you think might be offending. But at least knowing the concept of bisection is a huge game changer.
    - pixelpoet 3y ago
      I'm pretty sure every programmer learns about binary search near the beginning, and even without that has searched through some alphabetical listing without starting at aardvark (if not, I'd argue they have zero hope at much of anything abstract). Really feels like a stretch to credit git, of all things, with that fundamental understanding. It's like saying you need to operate a nuclear power plant to understand the benefits of locking doors.
      - xenomachina 3y ago
        When people search through alphabetical listings, they usually don't use plain old binary search, but instead use something like interpolation search. For example, if you want to find the word "xylostroma” in the dictionary, you aren't going to start in the middle. Instead, you'll start about 90% of the way through, and then make adjustments based on how far off you were.
        lost_tourist 3y ago
        Yeah but that is only optimal if you know the general location. Often when you have a bug you don't know where it snuck in, especially if it's something like a race condition.
        xenomachina 3y ago
        Sure. My point was just that contrary to what programmers typically think, people don't use binary search to look up things in a dictionary.
- rmccue 3y ago
  I don’t disagree, and I personally use it, but it’s a decent distance from teaching students the basics of git. I’d bundle it into a group of tools that are useful to know the existence of, and look up the docs when needed.
ranaexmachina 3y ago
If you teach all the concepts of Git (e.g. commits point to parents but not to children or branches are labels that point to a commit) properly it takes some time but then you get a lot of the more advanced things such as rebase kind of for free. In my experience, people often struggle with those because they have no clue how Git internally works. I had the same problem but when I looked into that it clicked and suddenly all the commands made a lot more sense.
willio58 3y ago
I’ve used git successfully professionally for almost 10 years and I’m not lying when I say I’ve used rebase about 5 times. We just merge. We squash sometimes. I think it must be because I’ve always worked in smaller orgs but rebase just seems to always be over complicating something simple (a merge). I get that there’s a benefit of a cleaner history but to me the benefit of simplicity merge offers makes it superior
- ttfkam 3y ago
  I always rebase from an up-to-date main/master before pushing my feature branches. So much easier to deal with than merging after the fact. But yeah, after that initial push, it's just merges from there on out.
- ahelwer 3y ago
  You have to fix conflicts either way so what's the difference? I suppose when merging you only have to fix the cumulative conflicts, while when rebasing you have to incrementally fix the conflicts introduced by every commit which is annoying. I usually squash a branch (rebase on where it diverged) before rebasing to fix this.
  - halostatue 3y ago
    It’s worth configuring rerere (reuse recorded resolution): https://git-scm.com/docs/git-rerere https://git-scm.com/docs/git-rerere for merges and rebases, because repeated rebases or merges of similar code will become substantially easier.
    - frutiger 3y ago
      > revere Innocent typo but for anyone else reading, it’s “rerere”.
      - halostatue 3y ago
        Thanks. I still had time to fix it, so I’ve corrected it. I had typed rerere, but autocorrect "fixed" it for me whether I wanted it fixed or not.
adontz 3y ago
I see bisect as a git superpower. Also grep (with rev-list). It's like knowing regular expressions. Not that one writes regexps every day, but this knowledge/skill definitely uplifts one to the next level.
- lost_tourist 3y ago
  I basically have to relearn regex's almost everytime, yeah it's a bit easier each time, but I still have to go back through some basic examples to get those old neurons stirring.
Jenk 3y ago
I don't know how successful of a metaphor this would be for students, but for developers who haven't had any familiarity with DVCS that I have worked with, I use a coat-rail analogy with some success: You start with a "main" rail of coats. Each coat is given a number, indicating what order it is in. You start adding coats to a new, empty, rail, using the next number. When you are done collecting coats on this new rail, you want to move your coats onto the original rail. In the time it has taken you to collect the coats onto your rail, someone else has already added coats from their new rail to the end of the "main" rail, and they used the same base number that you have - which means you cannot just add the coats from your rail onto the main rail, else the numbering would be broken - we call this a conflict. (NB: There is a magic guardian of the rails that means this just cannot happen, which is a plot device that is just to make this metaphor work so don't question it, it's just a metaphor.) To resolve the conflict you have the following "rebase" options: - Slide all of the coats on the main rail up to make room for yours, and update all of the numbers on your coats, using the new number from the last coat as the base number for your rail's sequence. This ensures that everything on the main rail is "before" your rail. This is the equivalent of a rebase. After this, you can then put your coats on the end of the main rail without conflict. - Then there is the option to take a copy of the main rail onto the front of your rail, and organising the coats one-by-one (much like in the above), placing your coat(s) in between some of the new coats on the main rail, then forcibly replacing the main rail with your updated rail. This last one is just as drastic in reality as it sounds in this metaphor. We call this the "interactive rebase" and it is rewriting history for anyone who has used the main rail before. - Finally we have a merge which means adding one big magic coat at the end that takes the coats from both rails and combines them in a singularity, with the new base number being Hawking's radiation or something, I dunno. The metaphor is no good for merges. (Truth be told: the entire metaphor started in my head some years ago with just the visualisation of that distinct coat rail sweep noise to squish the garments on the rail to onside to fit what our main protagonist is holding onto the rail, the rest I just back-filled over time)
jupp0r 3y ago
Rebase is used for many things in a lot of workflows. I use it probably 30 times per day in my job.
kazinator 3y ago
Using rebase is crucially important to anyone who is ready to start using git to track a remote repository and produce new changes to be pushed must learn about rebase. You have to use rebase to rewrite your unpublished commits over the latest upstream in order to be able to push a fast-forward change. Many new users of git don't have the luxury of learning how to use local-only git with no remote. Now rebase is a farm implement: a mechanized cherry picker. Cherry picking should be taught first, and then rebase explained in terms of being a multi-cherry-pick operation. Before teaching cherry picking, you have to teach that Git is based on snapshots and not deltas. Git cherry-pick is part of tooling that is inside Git, but external to its snapshot-based storage model. When you cherry pick some commit into your current branch, the tool finds the common ancestor between your branch and that commit. It then does a three-way diff using the files in the cherry-picked snasphot, your own branch snapshot and the common ancestor-snapshot. The three-way diff operations produce a merged version that becomes a new commit: another snapshot. If I ran a class on Git, we would spend part of a lecture doing manual merges with the diff3 utility: I would have the students take some ancestor file and make a "my" and "yours" with different changes, and merge these with diff3. We would go through conflict markers and all that. Old time hackers who used other version control systems before Git knew all this stuff already. The first time I encountered conflicts, I already knew how to resolve them. Just a few git concepts were new like having to add resolved files to the index. Imagine you know nothing about version control. Words like "unified diff" ring no bell. You've never seen conflict markers. You've never applied a patch or produced one.

by rmccue 3y ago

cassianoleal 3y ago

> bisect is definitely not common Agree. > I’d place it into the look-it-up-if-needed category. Disagree. Bisect is so useful in so many different scenarios that learning about it and the basics of how to use it is a great way to get people into git. Obviously not right at the beginning of their learning curve but as soon as the basics have been covered satisfactorily.

aaomidi 3y ago
I wish more people would know about bisect mainly because they’d design the toolchains to actually support testing when you’re doing bisect.

jedberg 3y ago

> I’d place it into the look-it-up-if-needed category. Knowing how to use git bisect is what elevates a programmer to the next level. Just understanding how it works gives you a new way to reason about bug finding and fixing (or feature development using old and new), and then actually using it can make you a bug fixing master.

pydry 3y ago
It feels like a weird and magical superpower but realistically I find use for it about once every 6 years and even then I'm fairly sure I could have done without it. This was not my impression when I first learned about it. I thought I'd be using it all the time.
- jedberg 3y ago
  > and even then I'm fairly sure I could have done without it. Just understating how git bisect works is the real superpower. The tool is a nice add on, but often you're right, is easier to bisect by hand by going to a known working commit and then doing a smart bisect based on the code you think might be offending. But at least knowing the concept of bisection is a huge game changer.
  - pixelpoet 3y ago
    I'm pretty sure every programmer learns about binary search near the beginning, and even without that has searched through some alphabetical listing without starting at aardvark (if not, I'd argue they have zero hope at much of anything abstract). Really feels like a stretch to credit git, of all things, with that fundamental understanding. It's like saying you need to operate a nuclear power plant to understand the benefits of locking doors.
    - xenomachina 3y ago
      When people search through alphabetical listings, they usually don't use plain old binary search, but instead use something like interpolation search. For example, if you want to find the word "xylostroma” in the dictionary, you aren't going to start in the middle. Instead, you'll start about 90% of the way through, and then make adjustments based on how far off you were.
      - lost_tourist 3y ago
        Yeah but that is only optimal if you know the general location. Often when you have a bug you don't know where it snuck in, especially if it's something like a race condition.
        xenomachina 3y ago
        Sure. My point was just that contrary to what programmers typically think, people don't use binary search to look up things in a dictionary.
rmccue 3y ago
I don’t disagree, and I personally use it, but it’s a decent distance from teaching students the basics of git. I’d bundle it into a group of tools that are useful to know the existence of, and look up the docs when needed.

ranaexmachina 3y ago

If you teach all the concepts of Git (e.g. commits point to parents but not to children or branches are labels that point to a commit) properly it takes some time but then you get a lot of the more advanced things such as rebase kind of for free. In my experience, people often struggle with those because they have no clue how Git internally works. I had the same problem but when I looked into that it clicked and suddenly all the commands made a lot more sense.

willio58 3y ago

I’ve used git successfully professionally for almost 10 years and I’m not lying when I say I’ve used rebase about 5 times. We just merge. We squash sometimes. I think it must be because I’ve always worked in smaller orgs but rebase just seems to always be over complicating something simple (a merge). I get that there’s a benefit of a cleaner history but to me the benefit of simplicity merge offers makes it superior

ttfkam 3y ago
I always rebase from an up-to-date main/master before pushing my feature branches. So much easier to deal with than merging after the fact. But yeah, after that initial push, it's just merges from there on out.
ahelwer 3y ago
You have to fix conflicts either way so what's the difference? I suppose when merging you only have to fix the cumulative conflicts, while when rebasing you have to incrementally fix the conflicts introduced by every commit which is annoying. I usually squash a branch (rebase on where it diverged) before rebasing to fix this.
- halostatue 3y ago
  It’s worth configuring rerere (reuse recorded resolution): https://git-scm.com/docs/git-rerere https://git-scm.com/docs/git-rerere for merges and rebases, because repeated rebases or merges of similar code will become substantially easier.
  - frutiger 3y ago
    > revere Innocent typo but for anyone else reading, it’s “rerere”.
    - halostatue 3y ago
      Thanks. I still had time to fix it, so I’ve corrected it. I had typed rerere, but autocorrect "fixed" it for me whether I wanted it fixed or not.

adontz 3y ago

I see bisect as a git superpower. Also grep (with rev-list). It's like knowing regular expressions. Not that one writes regexps every day, but this knowledge/skill definitely uplifts one to the next level.

lost_tourist 3y ago
I basically have to relearn regex's almost everytime, yeah it's a bit easier each time, but I still have to go back through some basic examples to get those old neurons stirring.

Jenk 3y ago

I don't know how successful of a metaphor this would be for students, but for developers who haven't had any familiarity with DVCS that I have worked with, I use a coat-rail analogy with some success: You start with a "main" rail of coats. Each coat is given a number, indicating what order it is in. You start adding coats to a new, empty, rail, using the next number. When you are done collecting coats on this new rail, you want to move your coats onto the original rail. In the time it has taken you to collect the coats onto your rail, someone else has already added coats from their new rail to the end of the "main" rail, and they used the same base number that you have - which means you cannot just add the coats from your rail onto the main rail, else the numbering would be broken - we call this a conflict. (NB: There is a magic guardian of the rails that means this just cannot happen, which is a plot device that is just to make this metaphor work so don't question it, it's just a metaphor.) To resolve the conflict you have the following "rebase" options: - Slide all of the coats on the main rail up to make room for yours, and update all of the numbers on your coats, using the new number from the last coat as the base number for your rail's sequence. This ensures that everything on the main rail is "before" your rail. This is the equivalent of a rebase. After this, you can then put your coats on the end of the main rail without conflict. - Then there is the option to take a copy of the main rail onto the front of your rail, and organising the coats one-by-one (much like in the above), placing your coat(s) in between some of the new coats on the main rail, then forcibly replacing the main rail with your updated rail. This last one is just as drastic in reality as it sounds in this metaphor. We call this the "interactive rebase" and it is rewriting history for anyone who has used the main rail before. - Finally we have a merge which means adding one big magic coat at the end that takes the coats from both rails and combines them in a singularity, with the new base number being Hawking's radiation or something, I dunno. The metaphor is no good for merges. (Truth be told: the entire metaphor started in my head some years ago with just the visualisation of that distinct coat rail sweep noise to squish the garments on the rail to onside to fit what our main protagonist is holding onto the rail, the rest I just back-filled over time)

jupp0r 3y ago

Rebase is used for many things in a lot of workflows. I use it probably 30 times per day in my job.

kazinator 3y ago

Using rebase is crucially important to anyone who is ready to start using git to track a remote repository and produce new changes to be pushed must learn about rebase. You have to use rebase to rewrite your unpublished commits over the latest upstream in order to be able to push a fast-forward change. Many new users of git don't have the luxury of learning how to use local-only git with no remote. Now rebase is a farm implement: a mechanized cherry picker. Cherry picking should be taught first, and then rebase explained in terms of being a multi-cherry-pick operation. Before teaching cherry picking, you have to teach that Git is based on snapshots and not deltas. Git cherry-pick is part of tooling that is inside Git, but external to its snapshot-based storage model. When you cherry pick some commit into your current branch, the tool finds the common ancestor between your branch and that commit. It then does a three-way diff using the files in the cherry-picked snasphot, your own branch snapshot and the common ancestor-snapshot. The three-way diff operations produce a merged version that becomes a new commit: another snapshot. If I ran a class on Git, we would spend part of a lecture doing manual merges with the diff3 utility: I would have the students take some ancestor file and make a "my" and "yours" with different changes, and merge these with diff3. We would go through conflict markers and all that. Old time hackers who used other version control systems before Git knew all this stuff already. The first time I encountered conflicts, I already knew how to resolve them. Just a few git concepts were new like having to add resolved files to the index. Imagine you know nothing about version control. Words like "unified diff" ring no bell. You've never seen conflict markers. You've never applied a patch or produced one.