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

Hitting every branch on the way down

rachelbythebay.com

Post reply on HN
Print view View original

31–40 of 144 posts

Re: Hitting every branch on the way down

#31

Post by kccqzy »

arghwhat wrote: post #25
datascienced wrote: post #2

I wont claim to understand C and the reason why is better than “”. I assume it is. But the fact that a merge can have arbitrary changes in it always bothers me! This is a case for rebase over merge if there are conflicts. You could have a merge of 2 empty repo parents where the result is the complete source of the latest version of Kubernetes!

All but the first commit has parents. All commits point to the state of the file tree at that point. A "merge commit" is nothing more than a commit claiming any number of parents greater than one. It is still its own file tree reference that decides how the tree looks, and nothing dictates that it should be related to the parents.

You are right that conceptually this is okay. But it is a UI problem that commands the author tried didn't manage to show the difference between the merge commit against any of its parents.

Re: Hitting every branch on the way down

#32

Post by lmm »

NewJazz wrote: post #29
lmm wrote: post #27

Earlier quoted context omitted.

I don't want to have to go back and forth with someone to pull their branch. I want to just be able to pull anything they've pushed.

I'll often just do a git reset --hard origin/branch-name

Right but that doesn't help if you've done your own work on top of their changes.

Re: Hitting every branch on the way down

#33

Post by doix »

pcl wrote: post #28
chaorace wrote: post #24

Earlier quoted context omitted.

There is a hierarchy to these things: - Person who destroys git history - Person who hates destroying git history - Person who knows how to recover "destroyed" history - Person who knows how to truly destroy git history

> - Person who knows how to truly destroy git history … tell me more!

I cannot imagine how one could _truly_ destroy git history. You could destroy it locally, sure no problem. You _might_ be able to destroy it on your remote, but if you're using something like Github/Gitlab/Bitbucket I'm sure they'll have a cache that isn't trivial to remove from. But even if you remove it locally and from remote, there's no way you're removing it from other peoples clones. And other people could have pushed to other remotes.

Stuff "leaks" so much in git, that it's really hard to lose work. The only way I could see someone losing work is if they never commit or if they never push. But even if you don't push and just rebase, you're not losing work. You would have to go out of your way to delete git history locally.

Re: Hitting every branch on the way down

#34

Post by dale_glass »

pcl wrote: post #28
chaorace wrote: post #24

Earlier quoted context omitted.

There is a hierarchy to these things: - Person who destroys git history - Person who hates destroying git history - Person who knows how to recover "destroyed" history - Person who knows how to truly destroy git history

> - Person who knows how to truly destroy git history … tell me more!

A rebase can be undone, because the old commits keep hanging around in the repo. Rebase doesn't delete or rewrite anything, it just creates new commits and adjusts branch pointers, so the old stuff is still there just hard to get at because nothing points at it anymore.

You just need to find an old commit ID somewhere, normally the reflog.

The old stuff will go away on its own eventually due to git's self-maintenance procedures removing unreachable commits, or it can be done forcefully by adjusting the gc parameters to get rid of it.

Re: Hitting every branch on the way down

#35

Post by doix »

devjab wrote: post #22
datascienced wrote: post #2

I wont claim to understand C and the reason why is better than “”. I assume it is. But the fact that a merge can have arbitrary changes in it always bothers me! This is a case for rebase over merge if there are conflicts. You could have a merge of 2 empty repo parents where the result is the complete source of the latest version of Kubernetes!

Wouldn’t you have the same amount of merge conflicts with rebase? Especially if you don’t do it often, which you frankly also should with merge? I have to admit that I never really understood the advantages of rebase, and what I mean by this is they I actually don’t understand how the dangers of rebase out-weighs any form of advantages. Especially because on of the major advantages of merge is that you can squash you…

> Especially because on of the major advantages of merge is that you can squash your local commit history when you submit it to your main branch.

Squashing is in no-way limited to merging and is actually done by doing an interactive rebase. Nothing is stopping you from squashing without creating a merge commit. It's entirely separate.

If you're squashing everything anyway, what does merging even give you? Is your main branch just:

* merge B

* squashed commit B

* merge A

* squashed commit A

If you didn't merge, you'd have:

* squashed commit B

* squashed commit A

> What we do is that we tie every pull request to a relatively small feature task, and because we do this, we genuinely don’t care about the individual commits developers do.

Except eventually there is a large feature task and then you end up with a giant commit that is annoying when git-bisecting.

But at the end of the day, these things only matter if you are spelunking through git history and/or using things like git bisect. If your git history is "write-only & rollback", then none of this stuff matters.

Re: Hitting every branch on the way down

#36

Post by thriftwy »

bananskalhalk wrote: post #7

$ git show d85c9944c55fb38f4eae149979a0f680ea125ecb | wc -l 11067 $ From `man git-log`: "Note that unless one of --diff-merges variants (including short -m, -c, and --cc options) is explicitly given, merge commits will not show a diff, even if a diff format like --patch is selected, nor will they match search options like -S. The exception is when --first-parent is in use, in which case first-parent is the default fo…

And that's one of the reasons why I advocate against merges in the codebase on every project I work for and in every HN thread where the topic of merges is mentioned.

Re: Hitting every branch on the way down

#37

Post by zilti »

Groxx wrote: post #3
datascienced wrote: post #2

I wont claim to understand C and the reason why is better than “”. I assume it is. But the fact that a merge can have arbitrary changes in it always bothers me! This is a case for rebase over merge if there are conflicts. You could have a merge of 2 empty repo parents where the result is the complete source of the latest version of Kubernetes!

Yep. Stuff like this is part of why I'm a rebaser. Rebase is simple . Always . The end result is obvious and clear and can only be interpreted in one way. Merge has lots of little sharp edges and surprises if you don't know every single tiniest detail. Almost nobody knows it in that level of detail, so it's a terrible choice for interacting with anyone else. If you're on your own, sure, do whatever - many things are…

"But it is littering the commit history with useless commits!" is what I always hear

Re: Hitting every branch on the way down

#38

Post by red_admiral »

datascienced wrote: post #2

I wont claim to understand C and the reason why is better than “”. I assume it is. But the fact that a merge can have arbitrary changes in it always bothers me! This is a case for rebase over merge if there are conflicts. You could have a merge of 2 empty repo parents where the result is the complete source of the latest version of Kubernetes!

The version searches the library path (usually /usr/include/* but can be modified with flags) whereas the "" searches the current working directory.

Re: Hitting every branch on the way down

#39

Post by skywal_l »

zilti wrote: post #37
Groxx wrote: post #3

Earlier quoted context omitted.

Yep. Stuff like this is part of why I'm a rebaser. Rebase is simple . Always . The end result is obvious and clear and can only be interpreted in one way. Merge has lots of little sharp edges and surprises if you don't know every single tiniest detail. Almost nobody knows it in that level of detail, so it's a terrible choice for interacting with anyone else. If you're on your own, sure, do whatever - many things are…

"But it is littering the commit history with useless commits!" is what I always hear

And the best answer is: "Why do you do useless commits?".

With `git amend` and `git fixup` you can arrange your commits to be clean, properly documented and self explanatory (and maybe atomic but that's a little harder). It takes a little time but it is hugely beneficial to code reviews and bug investigation.

Post reply on HN