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

Git: Using Advanced Rebase Features for a Clean Repository

mtyurt.net

Post reply on HN
Print view View original

51–60 of 87 posts

Re: Git: Using Advanced Rebase Features for a Clean Repository

#51

Post by kobeya »

exDM69 wrote: post #44
kobeya wrote: post #39

Earlier quoted context omitted.

> 1. Projects like the Linux kernel which use frequently use 'git bisect' to perform a binary search on the history of project (to find when a bug was introduced), or where the patch series tell a story to code reviewers. This seems like an instance of adapting development practices to bad tooling, whereas we could be fixing the tool itself. Shouldn't there simply be a "tree aware" git-bisect that can intelligently h…

> Shouldn't there simply be a "tree aware" git-bisect that can intelligently handle branches and merges? Afaik, git-bisect is aware of branches and merges. But there are two drawbacks to not rebasing/squashing: 1) the number of extra commits. Although bisecting is O(log N), it still adds up if it takes a long time to run the tests. 2) if there are any commits that don't build or have to be skipped (git bisect skip) b…

If true, the the whole claim that nonlinear histories break git-bisect is bunk.

Re: Git: Using Advanced Rebase Features for a Clean Repository

#52

Post by EnderMB »

dmacedo wrote: post #37
nothrabannosir wrote: post #28

Earlier quoted context omitted.

Just a note on your nr1: I don't think rebase back-dates the CommitDate, does it? There are two dates on any commit: AuthorDate and CommitDate. Try git log --format=fuller. E.g.: Author: ... AuthorDate: Wed Aug 2 11:02:03 2017 +0100 Commit: ... CommitDate: Wed Aug 9 12:08:52 2017 +0100 This is a commit I originally created last week, but rebased onto my current branch just now. To change the CommitDate, you have to g…

You're correct, it doesn't change the author date. In order to do no.1; perform your rebase, and then change the dates with filter-branch. I have a couple of helper functions for both for resetting to commit or author dates [1], use at your own risk! :) [1] https://gist.github.com/dm/aad8e34a5ee6b542a0bc788375b548ed

Yep, it took me a while to figure out why my commit dates didn't match the dates within GitHub. Luckily, it's fairly straightforward to figure out once you know what the issue is!

Re: Git: Using Advanced Rebase Features for a Clean Repository

#54

Post by whipoodle »

Something that somehow never ever makes it into these tutorials but is important: after you do the rebase locally, you must force push, don't pull then push. (After you rebase, the git client will suggest you pull.) This simple thing caused me a lot of unnecessary confusion about rebasing for a long time.

Re: Git: Using Advanced Rebase Features for a Clean Repository

#55

Post by falsedan »

0xcoffee wrote: post #43
radiospiel wrote: post #11

I personally almost never rebase and/or squash, since I think that the information that gets lost (like: when was it started, what were mistakes along the lines) might be useful for future understanding of how the project work evolved over time, and what adjustments should/could be made to the development process. But I understand that a screen as shown in the article is not immensely usuful. But if it comes down on…

I wish there was some happy medium, like that I can merge a branch and it gets squashed into a single commit, but then if needed I can 'expand' that commit to see its contents, even after the other branch is deleted.

That’s a rebased branch. You can see just the changed introduced by a branch:

  MERGE_COMMIT=$(git rev-parse :/“Merge .*$branchname”)
  git diff $MERGE_COMMIT^1..$MERGE_COMMIT^2
It never occurred to me that people prefer to squash so they can avoid the crummy UI of git diff

Re: Git: Using Advanced Rebase Features for a Clean Repository

#56

Post by epmatsw »

test1235 wrote: post #29
UK-AL wrote: post #15

Earlier quoted context omitted.

The thing is I commit very frequently, and a lot of the commits don't really make much sense by themselves. Often with stuff that's just plain wrong or confusing inbetween.

e.g. remove console.log what do you need that in the git history for?

“Fix lint” is my favorite one.

Re: Git: Using Advanced Rebase Features for a Clean Repository

#57

Post by talkingtab »

git rebase -i on a master with no changes.

As a sole developer, I am pulled in two different directions when using git feature-branch style. I want to make sure I never lose my work so I check in frequently- any time I start a change that might ultimately fail, I commit my current code so I can recover it. But I also want a clean, concise and useful history.

After reading this article I tried 'git rebase -i master' on my feature branch even though the master had no changes since starting the feature branch. This seems to work and allows me clean up my feature branch before I merge it to master.

Is there a better way to do this or are there problems with this?

Re: Git: Using Advanced Rebase Features for a Clean Repository

#58

Post by mtyurt »

whipoodle wrote: post #54

Something that somehow never ever makes it into these tutorials but is important: after you do the rebase locally, you must force push, don't pull then push. (After you rebase, the git client will suggest you pull.) This simple thing caused me a lot of unnecessary confusion about rebasing for a long time.

The video in the blogpost is all about it :)

Re: Git: Using Advanced Rebase Features for a Clean Repository

#59

Post by [deleted] »

wry_discontent wrote: post #48

I vastly prefer rebasing and squashing. Just yesterday I had to review some history, and reading the blames was incredibly frustrating. > Clean up style What was this code committed with? What other changes came along with it. Git, for me, has 2 functions. When I'm developing, it's to save my work in an incremental way that I can reverse. It's to make notes about what I'm doing. After I'm done, it serves as a way to…

[deleted]
Post reply on HN