Jeff King <peff@xxxxxxxx> writes:
> On Wed, Nov 18, 2015 at 10:56:02AM +0100, Johannes Schindelin wrote:
>
>> > For me I use this command more as a post-fetch:
>> >
>> > git fetch --all --prune && git-ff-refs
>> >
>> > I imagine that the big difference is in the number of branches that I
>> > maintain, and perhaps in the way that I use gitk to visualize them. I
>> > would be happy to add another option to git-fetch for --ff-refs as an
>> > alternative if that would feel better than a full-on builtin.
>>
>> I would much prefer, say, `git fetch --all --prune
>> --fast-forward-tracking-branches` (with maybe `-T` as short option for
>> `--fast-forward-tracking-branches` and/or a shorter `--ff-tracking`) to a
>> new builtin.
Hmph, I am not sure it is a good idea to allow "git fetch" affect
refs that it was not told to "fetch", but that is why you give a new
option from the command line to update refs that are not involved in
the fetch based on what was fetched, so it might be OK.
But the above is *NOT* fast-forwarding "tracking" branch. It is
doing something else: fast-forwarding the local branch that is based
on a remote-tracking branch.
They have refs/heads/master, and they call it their 'master'
branch.
You have refs/remotes/origin/master, and that is the
remote-tracking branch for their 'master'.
You may have prepared your 'master' to build on their 'master'
branch. That is not a 'tracking branch' for anything.
So --ff-tracking and the other name above need to be rethought.
> FWIW, that makes a lot more sense to me, as it would presumably touch
> only branches which track whatever we just updated, and not other random
> refs.
>
This ff-refs series breaks build for me by introducing calls to chdir()
whose return values are not checked -Werror=unused-result, by the way.
> I have to admit that I'm a little wary of something like ff-refs meeting
> all needs, though. I have custom scripts that match my workflow and tell
> me when a branch could be updated. I could replace part of them with
> "ff-refs --dry-run", but that is really not much code. Basically:
>
> git for-each-ref --format='%(refname) %(upstream)' refs/heads |
> while read ref upstream; do
> git merge-base --is-ancestor $ref $upstream &&
> echo "$ref can fast-forward"
> done
Yup. I like that one.
--
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