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
Mike Rappazzo <rappazzo@gmail.com>
Date
Nov 11, 2015, 12:32 UTC
Message-ID
<CANoM8SV77Jg8qYsn7UZ=a18WvrA_ayAWCnAjN9Tf6Re=r1Ggsg@mail.gmail.com>
In-Reply-To
<56431B69.9010007@drmicha.warpmail.net>

On Wed, Nov 11, 2015 at 5:41 AM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

Show 26 quoted lines
> Michael Rappazzo venit, vidit, dixit 11.11.2015 03:11:
>> This patch series is built on (based on) 'next' because it relies on
>> worktree.c
>>
>> `ff-refs` will update local branches which can be fast-forwarded to their
>> upstream tracking branch.  Any branch which has diverged from the upstream
>> will be left untouched by this command.  Additionally, there are options
>> for '--dry-run' and to '--skip-worktrees'.
>>
>> There are two primary update mechanisms for fast-forwarding a branch.
>>   - For a checked out branch, emulate `git-merge --ff-only`
>>   - For a non-checked out branch, emulate `git update-ref`
>>
>> When run on a repo with multiple worktrees (created with git-worktree add),
>> git-ff-refs will take that into account when fast-forwarding.  That is, it
>> will run in 'merge --ff-only' emulation mode when a branch is checked out
>> in a worktree, rather than in 'update-ref' mode.
>>
>> The primary benefit of ff-refs will come for those who maintain several
>> local branches which track upstream remote branches that update often.  The
>> intended usage pattern is to run `git-fetch` followed by `git-ff-refs`.
>
> I'm sorry, but I don't see why this deserves a new command. If refspec
> with and without "+" are not enough then maybe "git fetch --all" or "git
> remote update" should learn a new "--ff-only" option (ignoring all "+")
> like merge has.

Maybe I wasn't clear in my description, or maybe I misunderstand something. This command is about updating local refs (branches, really), not the local copy of a remote ref. If, for example I have local branches:

    master -> origin/master
    next -> origin/next
    pu -> origin/pu
    feature1 -> features/feature1
    feature2 -> features/feature2
    feature3 -> features/feature3
    bug1 -> features/bugs/bug1
    bug2 -> features/bugs/bug2

If I don't use multiple worktrees, I probably only have one of those checked out at any one time. If any of the upstream branches are updated, then when I fetch those branches will be behind. If I wanted to make sure that the branches I am not touching are updated, I would have to do it individually (AFAIK). And why not update my local worktree if it is a fast-forward?. This command aims to put that local branch update into a single command.

    > git fetch --all
    fetching origin...
        abc1234..abc1235  next -> origin/next
        abd1234..abd1235  pu -> origin/pu
    fetching features...
        123abcd..123abce  feature1 -> features/feature1
      + 124abcd...124abce feature2 -> features/feature2
        125abcd..125abce  feature3 -> features/feature3
    > git ff-refs
        master -> origin/master.........[UP-TO-DATE]
        next -> origin/next.............[UPDATED]
        pu -> origin/pu.................[UPDATED]
        feature1 -> features/feature1...[UPDATED]
        feature2 -> features/feature2...[NON-FAST-FORWARD]
        feature3 -> features/feature3...[UPDATED]
        bug1 -> features/bugs/bug1......[UP-TO-DATE]
        bug2 -> features/bugs/bug2......[UP-TO-DATE]

For reference, I have been using a scripted version of this command [1]. Assuming that I change your mind on this command, I will add this example to the help doc.

Show 11 quoted lines
>
> As for updating worktrees: This shouldn't be taken too lightly anyways.
> But the worktree interface still has some rough edges, and I would hope
> that it learns a "foreach" subcommand very much like the submodule
> version. That would allow you to
>
> git worktree foreach git merge --ff-only
>
> with a systematic aproach that opens many other opportunities.
>
> Michael

I am aware of the current status of the worktrees command (I worked on the 'list' command). If a user only wants to update unchecked out branches, there is a command line option provided, '--skip-worktrees'.

The foreach command sounds like a good idea, but I don't know that it would help here, as ff-refs is looping through all of the refs already (ala for-each-ref). If you are proposing foreach-worktree as an alternative, that is good for half of the command, but I would still want to update the unchecked out refs.

_Mike
[1] https://github.com/rappazzo/dotfiles/blob/ff-refs/bin/git-ff-refs
Previous: Michael J GruberNext: Michael J Gruber
Message 8 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.