4 ms·
> One think which git got wrong IMO is fast-forward when pulling: it means you lose branch information, and the history is hard to understand (it complicates li
by dlsspy 16y ago
> One think which git got wrong IMO is fast-forward when pulling: it means you lose branch information, and the history is hard to understand (it complicates life for bisect or continuous integration) - I change the pull command to make pull non fast forward by default in git.
That sounds pretty terrible. I would certainly refuse any changesets from you in OSS projects I'm managing if you tried to send me changes that had artificial commits introduced everytime you tried to sync with the upstream.
You don't lose any information with a ff. There's no information to lose -- you're just not specifically recording a commit that has no code changes, but says "and on this date, I grabbed some upstream code."
I've seen that complaint elsewhere, though. I always do pull --rebase (and only take merge commits in exceptional cases) because I'm on the other end of that spectrum. My history is very easy to read. Glad you can bend it to do what you want, though.
- codavid 16y agoYou do loose useful information, because you don't know where branches started/ended. For feature branches, that's very useful: useful for bisect, useful for reverting a branch. For syncing to upstream, that's indeed not so useful.
- dlsspy 16y agoIf it fast-forwarded, it's because you haven't added any changes that aren't already upstream. If you're losing information, it's when you considered starting a branch.
- chousuke 16y agoGit pull/merge etc. have a --no-ff switch that will do a normal merge even if a fast-forward is possible. You can even configure the default, though I don't remember the config variable.