git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/5] ff-refs: builtin command to fast-forward local refs

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 1, 2015, 00:24 UTC
Message-ID
<xmqqio4j6moo.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<20151124223903.GG29185@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 15 quoted lines
> 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.

Show 10 quoted lines
> 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.
Previous: Jeff King
Message 13 of 13 in “ff-refs: builtin command to fast-forward local refs”
  1. 0/5 ff-refs: builtin command to fast-forward local refsMichael Rappazzo, Nov 11, 2015
  2. 1/5 ff-refs: builtin cmd to check and fast forward local refs to their upstreamMichael Rappazzo, Nov 11, 2015
  3. 2/5 ff-refs: update each updatable refMichael Rappazzo, Nov 11, 2015
  4. 3/5 ff-refs: add --dry-run and --skip-worktree optionsMichael Rappazzo, Nov 11, 2015
  5. 4/5 ff-refs: Add documentationMichael Rappazzo, Nov 11, 2015
  6. 5/5 ff-refs: Add testsMichael Rappazzo, Nov 11, 2015
  7. Michael J GruberNov 11, 2015
  8. Mike RappazzoNov 11, 2015
  9. Michael J GruberNov 17, 2015
  10. Mike RappazzoNov 17, 2015
  11. Johannes SchindelinNov 18, 2015
  12. Jeff KingNov 24, 2015
  13. Junio C HamanoDec 1, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.