Why is the reflog always depicted as something bad by non-git users? I think the reflog is possibly the best and most powerful feature git has as opposed to concurrent SCM tools! Compare before and after rebase? Use reflog! See when you last pulled? Use reflog! Revert your commit amend? Use reflog! Revert the reversion of commit amend? Use reflog! Tons of other things? Use reflog! Use it all the way
Because it is fairly unintuitive, a leaky abstraction and it loses information eventually. Not that reflog shouldn't exist! Mercurial obviously has one too. But it should be abstracted away. This is a common problem with git: You need to know about its implementation details to effectively edit history. And when history is edited, those changes aren't shared, meaning there is no safe way to edit public commits. Mercurial's Changeset Evolution addresses those problems and more, like cherry-picking.
@@Elite7555 How is it a leaky abstraction? It is a well designed exposed feature that doesn't have to be there for git to work on a daily basis. I also don't agree that it's counter intuitive. Sure you need to learn what it is before you can use it, but that's with everything. And how does Mercurial have one too? Can you ask it where a bookmark was pointing to an hour ago? Where is it 'abstracted away' into? I don't know hg enough, but as far as I understood, when you e.g. rebase your changes, it spits out a bundle which is a backup of the old commits. What should you do with this bundle? How do you know later what's in all those bundle files? Should you organize them and how? With git the 'backup' is still just in the repository. And they are organized by git in the reflog. And if you want to keep it you can make a new ref (tag/brach/whatever) to it.
It sucks for branch with a lot of commits in a rebase flow. Every time you rebase it creates as many entries as the # of commits being rebased. For branches with say 30+ commits, the reflog becomes useless after 1-2 rebases -- not only does it fill up the reflog with useless intermediate commits, there is almost no way to tell if the rebase commit was a "pick" or "non-pick" (reword/edit/etc) after the fact.
@@voidvector To ignore intermediate commits, do something like git reflog master And yea, I agree it would have been nice to be able to see what you did with those individual commits. Could be an additional feature when someone is willing to build that in. Not too hard i guess. Still I wonder, although possible, why would you rebase 30+ commits on a regular basis? Feels like there is an underlying problem that upstream is resistant to accept your changes or something?
@@Jopie65 It is quite common to get 30+ commits in a branch, and 30 is a small number for larger organizations: * working/release branch for a team of 10-20 people * daily commits by 1 dev for a month long branch * any system with automated commits If we are questioning the rationale of using git for rebasing 30+ commits, it basic proves the presenter's point that the git is potentially not suitable (not scalable) for this use case. Do we force our workflow to ways that conform to the original use case of a tool? Or do we find/develop a new tool that fits our workflow?
3 years later.
Which of those features are now implemented in Git?
sparse checkout
Why is the reflog always depicted as something bad by non-git users?
I think the reflog is possibly the best and most powerful feature git has as opposed to concurrent SCM tools!
Compare before and after rebase? Use reflog!
See when you last pulled? Use reflog!
Revert your commit amend? Use reflog!
Revert the reversion of commit amend? Use reflog!
Tons of other things? Use reflog! Use it all the way
Because it is fairly unintuitive, a leaky abstraction and it loses information eventually. Not that reflog shouldn't exist! Mercurial obviously has one too. But it should be abstracted away. This is a common problem with git: You need to know about its implementation details to effectively edit history. And when history is edited, those changes aren't shared, meaning there is no safe way to edit public commits. Mercurial's Changeset Evolution addresses those problems and more, like cherry-picking.
@@Elite7555
How is it a leaky abstraction? It is a well designed exposed feature that doesn't have to be there for git to work on a daily basis. I also don't agree that it's counter intuitive. Sure you need to learn what it is before you can use it, but that's with everything.
And how does Mercurial have one too? Can you ask it where a bookmark was pointing to an hour ago? Where is it 'abstracted away' into?
I don't know hg enough, but as far as I understood, when you e.g. rebase your changes, it spits out a bundle which is a backup of the old commits. What should you do with this bundle? How do you know later what's in all those bundle files? Should you organize them and how?
With git the 'backup' is still just in the repository. And they are organized by git in the reflog. And if you want to keep it you can make a new ref (tag/brach/whatever) to it.
It sucks for branch with a lot of commits in a rebase flow. Every time you rebase it creates as many entries as the # of commits being rebased. For branches with say 30+ commits, the reflog becomes useless after 1-2 rebases -- not only does it fill up the reflog with useless intermediate commits, there is almost no way to tell if the rebase commit was a "pick" or "non-pick" (reword/edit/etc) after the fact.
@@voidvector
To ignore intermediate commits, do something like
git reflog master
And yea, I agree it would have been nice to be able to see what you did with those individual commits. Could be an additional feature when someone is willing to build that in. Not too hard i guess.
Still I wonder, although possible, why would you rebase 30+ commits on a regular basis? Feels like there is an underlying problem that upstream is resistant to accept your changes or something?
@@Jopie65 It is quite common to get 30+ commits in a branch, and 30 is a small number for larger organizations:
* working/release branch for a team of 10-20 people
* daily commits by 1 dev for a month long branch
* any system with automated commits
If we are questioning the rationale of using git for rebasing 30+ commits, it basic proves the presenter's point that the git is potentially not suitable (not scalable) for this use case.
Do we force our workflow to ways that conform to the original use case of a tool? Or do we find/develop a new tool that fits our workflow?
"How Facebook deals with developers who have 0 discipline when programming + a bad overall infrastructure."