Best practices for merging?
eir at cis.upenn.edu
Mon Feb 1 17:10:32 UTC 2016
I have this in effect:
alias gitlog='git log --graph --full-history --all --color --pretty=format:"%x1b[31m%h%x09%x1b[32m%d%x1b[0m%x20%s"'
I didn't come up with the incantation (and I forget the source), but it has obviated entirely my use of gitk. I use this command many times a day.
On Feb 1, 2016, at 11:04 AM, Ben Gamari <ben at smart-cactus.org> wrote:
> Jan Stolarek <jan.stolarek at p.lodz.pl> writes:
>>> If there are multiple commits then a merge commit can serve to logically
>>> group them.
>> The cost of this is non-linear history. But I am still not sure what the actual benefit is? If the
>> commits come one after another they are still logically grouped, with or without a merge commit.
>> I also wonder what is the preferred way of viewing history for most of the people. I either use
>> `git log` or github, but rarely resort to gitk. Only the latter makes the non-linear commits
>> explicitly visible. The former two just collapse everything into a linear history and is such a
>> setting merge commits are a major clutter. So perhaps that's why I don't like them. Perhaps
>> people who tend to use gitk are more keen on merge commits?
> Indeed I make quite frequent use of gitk (even git log --graph is pretty
> - Ben
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs