Why SQLite Does Not Use Git

Re:Why SQLite Does Not Use Git by aidenn0 on Wednesday April 11, 2018 @12:09AM (#16807961)

Rebase is "rewind local changes" "pull" "replay local chances"

Basically it makes it so that all of the local-only commits are sequenced after any remote changes that you have not seen yet.

[edit]

YZF is correct. In the context of pulling (i.e. "git pull --rebase") my description is correct. However in general rebasing branch X to Y that diverge from commit C is:

rewind branch Y to commit C; call the old tip of Y Y'

play all commits from C -> X on Y

play all commits from C -> Y' to branch Y.

[ Parent | on HN ]

Re:Why SQLite Does Not Use Git by YZF on Wednesday April 11, 2018 @12:14AM (#16807982)

You can rebase between two local branches. The rebase operation has nothing to do with pull or remote vs. local.

[ Parent | on HN ]

Re:Why SQLite Does Not Use Git by aidenn0 on Wednesday April 11, 2018 @01:23AM (#16808282)

Yes. I thought we were in the context of git pull --rebase...

[ Parent | on HN ]

Re:Why SQLite Does Not Use Git by e12e on Wednesday April 11, 2018 @02:06AM (#16808462)

"pull" might be the first thing I'd throw out, if thought there was any hope of fixing git ux. Then add a working merge --dry-run #do i have conflicts?.

[ Parent | on HN ]

Re:Why SQLite Does Not Use Git by aidenn0 on Wednesday April 11, 2018 @12:01PM (#16812467)

I think a default of --ff-only would be fine for pull. This is great for when I'm merely a consumer of a project, and will never silently perform a merge or rebase.

[ Parent | on HN ]

Re:Why SQLite Does Not Use Git by specialist on Wednesday April 11, 2018 @12:36PM (#16812838)

Thanks (all) for the clarifications.

When explaining to others, I should probably say 'pull, reapply, then push'.

Perhaps 'rebranch' is a better word choice than 'rebase', to conceptually more closely match what's actually happening under the hood.

[ Parent | on HN ]