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

Better Git configuration

blog.scottnonnenberg.com

Post reply on HN
Print view View original

61–66 of 66 posts

Re: Better Git configuration

#61

Post by growse »

rlpb wrote: post #47
ymse wrote: post #7

Oddly, the author recommends signing commits, yet uses only fast-forward merges. Little do they know that signed commits necessarily can not be resolved as fast-forwards in a merge situation, since that would require changing the signatures! Rebasing is the answer, but that will of course re-sign every commit with your key. In a shared repository, I prefer creating "useless" merge commits to changing other peoples si…

Perhaps I misunderstand you, but a fast forward merge isn't really a merge (there is no merge commit) and by definition doesn't change any commits. So it doesn’t require changing any commits, and therefore no signatures need changing either. Is there some other part of a workflow that you're inferring here that will need changing commits?

If you have a feature branch with multiple commits signed by multiple people, does rebasing that not invalidate the signatures (changes the parent and thus every hash)?

Re: Better Git configuration

#62

Post by ereyes01 »

jwilk wrote: post #37
ereyes01 wrote: post #27

I'm a long time vim user and my brain is wired to reach for the keyboard shortcuts in vimdiff to jump from diff to diff. Also, I really love diffing entire trees in one vim session using the DirDiff plugin ( https://github.com/will133/vim-dirdiff ). Here's how I wire it into my .gitconfig, which gets me the alias "git dirdiff": [difftool "default-difftool"] cmd = gvim -f '+next' '+execute \"DirDiff\" argv(0) argv(1)'…

The last section should be: [alias] dirdiff = difftool --dir-diff

Copy/paste fail... Thanks for catching

Re: Better Git configuration

#65

Post by rlpb »

growse wrote: post #61
rlpb wrote: post #47

Earlier quoted context omitted.

Perhaps I misunderstand you, but a fast forward merge isn't really a merge (there is no merge commit) and by definition doesn't change any commits. So it doesn’t require changing any commits, and therefore no signatures need changing either. Is there some other part of a workflow that you're inferring here that will need changing commits?

If you have a feature branch with multiple commits signed by multiple people, does rebasing that not invalidate the signatures (changes the parent and thus every hash)?

I see. The rebasing you mention is part the implied workflow I was missing. I see it now. Yes - if the rule is that merge commits to master are not permitted (ie. all commits must be rebased onto master first), then of course one person cannot rebase someone else's signed commits without losing those signatures. Thanks.

Theoretically one could devise a tool which allows each contributor to re-sign (in the correct order), but I'm not aware that any such thing exists, and it'd probably be too impractical anyway.

Re: Better Git configuration

#66

Post by collinmanderson »

scrollaway wrote: post #10

I want to also recommend the following: git config --global stash.showPatch true: A recent addition to git which defaults the -p flag to `git stash show`; meaning `git stash show` shows the diff from that stash (should really be default...) git config --global rebase.autostash true: will automatically stash and unstash the working directory before and after rebases. This makes it possible to rebase with changes in th…

I just use `git show stash` rather than `git stash show`.
Post reply on HN