Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git rebase in depth

git-rebase.io

Post reply on HN
Print view View original

71–80 of 248 posts

Re: Git rebase in depth

#71

Post by mixmastamyk »

Sir_Cmpwn wrote: post #27
jaequery wrote: post #23

FWIW i've never really needed rebase. i am pretty happy with seeing all the commits that ever happened.

I've heard this before, and it seems reasonable on the surface. The argument I make against this viewpoint is: "git rebase gives us powerful tools that allow us to curate a good commit history in the same way we use refactoring to uphold good software design practices."

Most shops don't follow good software design practices, so how likely is it to get a practice one-step-removed from that, with a difficult UI to boot, adopted?

Re: Git rebase in depth

#72

Post by Dayshine »

dmitryminkovsky wrote: post #57
gwright wrote: post #32

About 99.9% of the time when people talk about rebase they talk about ‘editing’ history or ‘rewriting’ history as in the first sentence of the article. I find that terminology terribly misleading and when I was learning git and rebase it confused the heck out of me. No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. Git rebase creates a…

> No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. They are still in the repo, but if no treeish item (eg. a branch) points to them, then they'll eventually get garbage collected. Still, glad to see people are trying to elucidate git rebase. A small subset of its functionality is fundamental part of my workflow and I wouldn't know how…

I really don't understand why git doesn't create a tag when you rebase in case things go wrong, or more generally when doing potentially gc-able actions. Pretending the average user will know how to get things back to how they are is silly.

Re: Git rebase in depth

#73

Post by amelius »

Regarding the rewriting of history: can't the git history itself be stored in git somehow, so its change over time (and e.g. by tools such as git-rebase) is properly tracked? Of course you'd need a meta tool to change the history of the history, but perhaps it's not needed?

Re: Git rebase in depth

#74

Post by dahart »

AlexTWithBeard wrote: post #70
dahart wrote: post #49

Earlier quoted context omitted.

Git does have two levels of the API explicitly, one for tools (“plumbing”) and one for every day use (“porcelain”). I don’t think the argument is that the difficulty is a virtue, nobody is trying to be snobby, so try to avoid jumping to that conclusion. Git just has some inherent complexity. Git does have a steep learning curve that is the root of a UX problem. But it’s not clear what better abstractions there are or…

The main problem with git is that it tries to be two things at once: a change management system and a version control system. For the former you want flexible history, distributed repos and freedom to do whatever you want. For the latter the history should be sacrosanct and the repository is better be more or less centralized. git tries to sit on both chairs and therefore has to adapt a quite awkward position.

I totally don’t understand your implied semantic difference between “change management” and “version control”. Those sound like exactly the same thing to me. ;)

I also don’t understand your larger point about git and what the problem is. For almost everyone using git, the pushed history is sacrosanct, and the main repo is centralized. The main workflow for rebase is to clean up before making commits public.

Re: Git rebase in depth

#75

Post by Sir_Cmpwn »

amelius wrote: post #73

Regarding the rewriting of history: can't the git history itself be stored in git somehow, so its change over time (and e.g. by tools such as git-rebase) is properly tracked? Of course you'd need a meta tool to change the history of the history, but perhaps it's not needed?

It is: man git-reflog.

Re: Git rebase in depth

#76

Post by rusk »

gwright wrote: post #32

About 99.9% of the time when people talk about rebase they talk about ‘editing’ history or ‘rewriting’ history as in the first sentence of the article. I find that terminology terribly misleading and when I was learning git and rebase it confused the heck out of me. No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. Git rebase creates a…

I'd suggest creating the branch before the rebase:

    $ git co feature-branch
    $ git branch before-rebase-feature-branch
    $ git rebase develop

Re: Git rebase in depth

#77

Post by mixmastamyk »

Dayshine wrote: post #72
dmitryminkovsky wrote: post #57

Earlier quoted context omitted.

> No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. They are still in the repo, but if no treeish item (eg. a branch) points to them, then they'll eventually get garbage collected. Still, glad to see people are trying to elucidate git rebase. A small subset of its functionality is fundamental part of my workflow and I wouldn't know how…

I really don't understand why git doesn't create a tag when you rebase in case things go wrong, or more generally when doing potentially gc-able actions. Pretending the average user will know how to get things back to how they are is silly.

Yep, it was designed by and for linux kernel development, that average users are using it is an accident of history.

Re: Git rebase in depth

#78

Post by pjc50 »

gwright wrote: post #32

About 99.9% of the time when people talk about rebase they talk about ‘editing’ history or ‘rewriting’ history as in the first sentence of the article. I find that terminology terribly misleading and when I was learning git and rebase it confused the heck out of me. No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. Git rebase creates a…

As the old Andre Previn sketch joke says: all the right commits, but not necessarily in the right order.

Re: Git rebase in depth

#79

Post by sktrdie »

rich-tea wrote: post #34

What I really like to do is make actual fixup (or squash) commits during a code review and just push these to the branch normally. That way reviewers can easily keep up with the changes. Right at the end, the maintainer requests that the original developer does a rebase --autosquash before the branch is actually merged. This works really well but I rarely see people talk about it. It means you don't have to use somet…

Indeed this is the whole reason I like fixups. Reviewers can actually keep up with the requested changes and know exactly which fixup-commit is related to which change.

Re: Git rebase in depth

#80

Post by jrockway »

Dayshine wrote: post #72
dmitryminkovsky wrote: post #57

Earlier quoted context omitted.

> No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. They are still in the repo, but if no treeish item (eg. a branch) points to them, then they'll eventually get garbage collected. Still, glad to see people are trying to elucidate git rebase. A small subset of its functionality is fundamental part of my workflow and I wouldn't know how…

I really don't understand why git doesn't create a tag when you rebase in case things go wrong, or more generally when doing potentially gc-able actions. Pretending the average user will know how to get things back to how they are is silly.

There is the reflog for that. https://www.atlassian.com/git/tutorials/rewriting-history/gi...
Post reply on HN