On 28/04/2014 09:32, Felipe Contreras wrote:
some people to is to always merge with --no-ff, that way you see the branch
name in the merge commit.
But surely, it's recommended with Git that you try to avoid doing
--no-ff merges to avoid commit noise?
Nope. Different people have different needs, there's no recommendation. If
anything, the recommendation is to do a ff merge, because that's the default.
That's what I'm saying. With an ff merge, you don't get the merge
commit message telling you the branch name.
Also, it is a lot more hassle (and no doubt, CPU cycles) to track down where
a branch was merged to try and figure out which branch name a commit
pertained to, not to mention the fact that the commit could've been moved
since. Nothing short of tagging the commit with the branch name when the
commit is made will definitely record the branch name at the time of
committing.
But why do you need that information?
As I said before, I usually consider my branch names useful information
worth keeping around - I'm not sure why you don't. I might include a
bug# in the branch name so I don't have to keep typing it in every
commit message, or I might just have a handy short description of what
part of the application this branch is modifying (like my
"pacman-minigame" example).
--
Best regards,
Jeremy Morton (Jez)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html