1. 15 Aug, 2018 1 commit
  2. 20 Jul, 2018 1 commit
    • Derrick Stolee's avatar
      commit-reach: move ref_newer from remote.c · 1d614d41
      Derrick Stolee authored
      There are several commit walks in the codebase. Group them together into
      a new commit-reach.c file and corresponding header. After we group these
      walks into one place, we can reduce duplicate logic by calling
      equivalent methods.
      
      The ref_newer() method is used by 'git push -f' to check if a force-push
      is necessary. By making the method public, we make it possible to test
      the method directly without setting up an envieronment where a 'git
      push' call makes sense.
      Signed-off-by: default avatarDerrick Stolee <dstolee@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      1d614d41
  3. 28 Jun, 2018 1 commit
    • Brandon Williams's avatar
      fetch-pack: implement ref-in-want · 73302051
      Brandon Williams authored
      Implement ref-in-want on the client side so that when a server supports
      the "ref-in-want" feature, a client will send "want-ref" lines for each
      reference the client wants to fetch.  This feature allows clients to
      tolerate inconsistencies that exist when a remote repository's refs
      change during the course of negotiation.
      
      This allows a client to request to request a particular ref without
      specifying the OID of the ref.  This means that instead of hitting an
      error when a ref no longer points at the OID it did at the beginning of
      negotiation, negotiation can continue and the value of that ref will be
      sent at the termination of negotiation, just before a packfile is sent.
      
      More information on the ref-in-want feature can be found in
      Documentation/technical/protocol-v2.txt.
      Signed-off-by: default avatarBrandon Williams <bmwill@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      73302051
  4. 17 May, 2018 10 commits
  5. 24 Apr, 2018 1 commit
  6. 15 Mar, 2018 1 commit
  7. 14 Mar, 2018 1 commit
  8. 09 Feb, 2018 2 commits
    • Ævar Arnfjörð Bjarmason's avatar
      fetch: add a --prune-tags option and fetch.pruneTags config · 97716d21
      Ævar Arnfjörð Bjarmason authored
      Add a --prune-tags option to git-fetch, along with fetch.pruneTags
      config option and a -P shorthand (-p is --prune). This allows for
      doing any of:
      
          git fetch -p -P
          git fetch --prune --prune-tags
          git fetch -p -P origin
          git fetch --prune --prune-tags origin
      
      Or simply:
      
          git config fetch.prune true &&
          git config fetch.pruneTags true &&
          git fetch
      
      Instead of the much more verbose:
      
          git fetch --prune origin 'refs/tags/*:refs/tags/*' '+refs/heads/*:refs/remotes/origin/*'
      
      Before this feature it was painful to support the use-case of pulling
      from a repo which is having both its branches *and* tags deleted
      regularly, and have our local references to reflect upstream.
      
      At work we create deployment tags in the repo for each rollout, and
      there's *lots* of those, so they're archived within weeks for
      performance reasons.
      
      Without this change it's hard to centrally configure such repos in
      /etc/gitconfig (on servers that are only used for working with
      them). You need to set fetch.prune=true globally, and then for each
      repo:
      
          git -C {} config --replace-all remote.origin.fetch "refs/tags/*:refs/tags/*" "^\+*refs/tags/\*:refs/tags/\*$"
      
      Now I can simply set fetch.pruneTags=true in /etc/gitconfig as well,
      and users running "git pull" will automatically get the pruning
      semantics I want.
      
      Even though "git remote" has corresponding "prune" and "update
      --prune" subcommands I'm intentionally not adding a corresponding
      prune-tags or "update --prune --prune-tags" mode to that command.
      
      It's advertised (as noted in my recent "git remote doc: correct
      dangerous lies about what prune does") as only modifying remote
      tracking references, whereas any --prune-tags option is always going
      to modify what from the user's perspective is a local copy of the tag,
      since there's no such thing as a remote tracking tag.
      
      Ideally add_prune_tags_to_fetch_refspec() would be something that
      would use ALLOC_GROW() to grow the 'fetch` member of the 'remote'
      struct. Instead I'm realloc-ing remote->fetch and adding the
      tag_refspec to the end.
      
      The reason is that parse_{fetch,push}_refspec which allocate the
      refspec (ultimately remote->fetch) struct are called many places that
      don't have access to a 'remote' struct. It would be hard to change all
      their callsites to be amenable to carry around the bookkeeping
      variables required for dynamic allocation.
      
      All the other callers of the API first incrementally construct the
      string version of the refspec in remote->fetch_refspec via
      add_fetch_refspec(), before finally calling parse_fetch_refspec() via
      some variation of remote_get().
      
      It's less of a pain to deal with the one special case that needs to
      modify already constructed refspecs than to chase down and change all
      the other callsites. The API I'm adding is intentionally not
      generalized because if we add more of these we'd probably want to
      re-visit how this is done.
      
      See my "Re: [BUG] git remote prune removes local tags, depending on
      fetch config" (87po6ahx87.fsf@evledraar.gmail.com;
      https://public-inbox.org/git/87po6ahx87.fsf@evledraar.gmail.com/) for
      more background info.
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      97716d21
    • Ævar Arnfjörð Bjarmason's avatar
      remote: add a macro for "refs/tags/*:refs/tags/*" · 750d0da9
      Ævar Arnfjörð Bjarmason authored
      Add a macro with the refspec string "refs/tags/*:refs/tags/*". There's
      been a pre-defined struct version of this since e0aaa29f ("Have a
      constant extern refspec for "--tags"", 2008-04-17), but nothing that
      could be passed to e.g. add_fetch_refspec().
      
      This will be used in subsequent commits to avoid hardcoding this
      string in multiple places.
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      750d0da9
  9. 24 Jan, 2018 3 commits
  10. 08 Nov, 2017 1 commit
    • J Wyman's avatar
      for-each-ref: let upstream/push report the remote ref name · 9700fae5
      J Wyman authored
      There are times when scripts want to know not only the name of the
      push branch on the remote, but also the name of the branch as known
      by the remote repository.
      
      An example of this is when a tool wants to push to the very same branch
      from which it would pull automatically, i.e. the `<remote>` and the `<to>`
      in `git push <remote> <from>:<to>` would be provided by
      `%(upstream:remotename)` and `%(upstream:remoteref)`, respectively.
      
      This patch offers the new suffix :remoteref for the `upstream` and `push`
      atoms, allowing to show exactly that. Example:
      
      	$ cat .git/config
      	...
      	[remote "origin"]
      		url = https://where.do.we.come/from
      		fetch = refs/heads/*:refs/remote/origin/*
      	[branch "master"]
      		remote = origin
      		merge = refs/heads/master
      	[branch "develop/with/topics"]
      		remote = origin
      		merge = refs/heads/develop/with/topics
      	...
      
      	$ git for-each-ref \
      		--format='%(push) %(push:remoteref)' \
      		refs/heads
      	refs/remotes/origin/master refs/heads/master
      	refs/remotes/origin/develop/with/topics refs/heads/develop/with/topics
      Signed-off-by: default avatarJ Wyman <jwyman@microsoft.com>
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9700fae5
  11. 17 Jul, 2017 1 commit
  12. 11 Apr, 2017 1 commit
  13. 31 Mar, 2017 2 commits
  14. 02 Mar, 2017 1 commit
  15. 19 Jan, 2017 1 commit
    • Johannes Schindelin's avatar
      remote rename: more carefully determine whether a remote is configured · e459b073
      Johannes Schindelin authored
      One of the really nice features of the ~/.gitconfig file is that users
      can override defaults by their own preferred settings for all of their
      repositories.
      
      One such default that some users like to override is whether the
      "origin" remote gets auto-pruned or not. The user would simply call
      
      	git config --global remote.origin.prune true
      
      and from now on all "origin" remotes would be pruned automatically when
      fetching into the local repository.
      
      There is just one catch: now Git thinks that the "origin" remote is
      configured, even if the repository config has no [remote "origin"]
      section at all, as it does not realize that the "prune" setting was
      configured globally and that there really is no "origin" remote
      configured in this repository.
      
      That is a problem e.g. when renaming a remote to a new name, when Git
      may be fooled into thinking that there is already a remote of that new
      name.
      
      Let's fix this by paying more attention to *where* the remote settings
      came from: if they are configured in the local repository config, we
      must not overwrite them. If they were configured elsewhere, we cannot
      overwrite them to begin with, as we only write the repository config.
      
      There is only one caller of remote_is_configured() (in `git fetch`) that
      may want to take remotes into account even if they were configured
      outside the repository config; all other callers essentially try to
      prevent the Git command from overwriting settings in the repository
      config.
      
      To accommodate that fact, the remote_is_configured() function now
      requires a parameter that states whether the caller is interested in all
      remotes, or only in those that were configured in the repository config.
      
      Many thanks to Jeff King whose tireless review helped with settling for
      nothing less than the current strategy.
      
      This fixes https://github.com/git-for-windows/git/issues/888Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      e459b073
  16. 26 Jul, 2016 1 commit
    • John Keeping's avatar
      push: allow pushing new branches with --force-with-lease · 64ac39af
      John Keeping authored
      If there is no upstream information for a branch, it is likely that it
      is newly created and can safely be pushed under the normal fast-forward
      rules.  Relax the --force-with-lease check so that we do not reject
      these branches immediately but rather attempt to push them as new
      branches, using the null SHA-1 as the expected value.
      
      In fact, it is already possible to push new branches using the explicit
      --force-with-lease=<branch>:<expect> syntax, so all we do here is make
      this behaviour the default if no explicit "expect" value is specified.
      Signed-off-by: John Keeping's avatarJohn Keeping <john@keeping.me.uk>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      64ac39af
  17. 16 Feb, 2016 1 commit
    • Thomas Gummerer's avatar
      remote: simplify remote_is_configured() · 674468b3
      Thomas Gummerer authored
      The remote_is_configured() function allows checking whether a remote
      exists or not.  The function however only works if remote_get() wasn't
      called before calling it.  In addition, it only checks the configuration
      for remotes, but not remotes or branches files.
      
      Make use of the origin member of struct remote instead, which indicates
      where the remote comes from.  It will be set to some value if the remote
      is configured in any file in the repository, but is initialized to 0 if
      the remote is only created in make_remote().
      Signed-off-by: default avatarThomas Gummerer <t.gummerer@gmail.com>
      Reviewed-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      674468b3
  18. 26 Jan, 2016 1 commit
  19. 20 Nov, 2015 2 commits
  20. 22 May, 2015 2 commits
    • Jeff King's avatar
      remote.c: add branch_get_push · e291c75a
      Jeff King authored
      In a triangular workflow, the place you pull from and the
      place you push to may be different. As we have
      branch_get_upstream for the former, this patch adds
      branch_get_push for the latter (and as the former implements
      @{upstream}, so will this implement @{push} in a future
      patch).
      
      Note that the memory-handling for the return value bears
      some explanation. Some code paths require allocating a new
      string, and some let us return an existing string. We should
      provide a consistent interface to the caller, so it knows
      whether to free the result or not.
      
      We could do so by xstrdup-ing any existing strings, and
      having the caller always free. But that makes us
      inconsistent with branch_get_upstream, so we would prefer to
      simply take ownership of the resulting string. We do so by
      storing it inside the "struct branch", just as we do with
      the upstream refname (in that case we compute it when the
      branch is created, but there's no reason not to just fill
      it in lazily in this case).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      e291c75a
    • Jeff King's avatar
      remote.c: return upstream name from stat_tracking_info · 979cb245
      Jeff King authored
      After calling stat_tracking_info, callers often want to
      print the name of the upstream branch (in addition to the
      tracking count). To do this, they have to access
      branch->merge->dst[0] themselves. This is not wrong, as the
      return value from stat_tracking_info tells us whether we
      have an upstream branch or not. But it is a bit leaky, as we
      make an assumption about how it calculated the upstream
      name.
      
      Instead, let's add an out-parameter that lets the caller
      know the upstream name we found.
      
      As a bonus, we can get rid of the unusual tri-state return
      from the function. We no longer need to use it to
      differentiate between "no tracking config" and "tracking ref
      does not exist" (since you can check the upstream_name for
      that), so we can just use the usual 0/-1 convention for
      success/error.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      979cb245
  21. 21 May, 2015 5 commits
    • Jeff King's avatar
      remote.c: report specific errors from branch_get_upstream · 3a429d0a
      Jeff King authored
      When the previous commit introduced the branch_get_upstream
      helper, there was one call-site that could not be converted:
      the one in sha1_name.c, which gives detailed error messages
      for each possible failure.
      
      Let's teach the helper to optionally report these specific
      errors. This lets us convert another callsite, and means we
      can use the helper in other locations that want to give the
      same error messages.
      
      The logic and error messages come straight from sha1_name.c,
      with the exception that we start each error with a lowercase
      letter, as is our usual style (note that a few tests need
      updated as a result).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3a429d0a
    • Jeff King's avatar
      remote.c: introduce branch_get_upstream helper · a9f9f8cc
      Jeff King authored
      All of the information needed to find the @{upstream} of a
      branch is included in the branch struct, but callers have to
      navigate a series of possible-NULL values to get there.
      Let's wrap that logic up in an easy-to-read helper.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a9f9f8cc
    • Jeff King's avatar
      remote.c: provide per-branch pushremote name · da66b274
      Jeff King authored
      When remote.c loads its config, it records the
      branch.*.pushremote for the current branch along with the
      global remote.pushDefault value, and then binds them into a
      single value: the default push for the current branch. We
      then pass this value (which may be NULL) to remote_get_1
      when looking up a remote for push.
      
      This has a few downsides:
      
        1. It's confusing. The early-binding of the "current
           value" led to bugs like the one fixed by 98b406f3
           (remote: handle pushremote config in any order,
           2014-02-24). And the fact that pushremotes fall back to
           ordinary remotes is not explicit at all; it happens
           because remote_get_1 cannot tell the difference between
           "we are not asking for the push remote" and "there is
           no push remote configured".
      
        2. It throws away intermediate data. After read_config()
           finishes, we have no idea what the value of
           remote.pushDefault was, because the string has been
           overwritten by the current branch's
           branch.*.pushremote.
      
        3. It doesn't record other data. We don't note the
           branch.*.pushremote value for anything but the current
           branch.
      
      Let's make this more like the fetch-remote config. We'll
      record the pushremote for each branch, and then explicitly
      compute the correct remote for the current branch at the
      time of reading.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      da66b274
    • Jeff King's avatar
      remote.c: hoist branch.*.remote lookup out of remote_get_1 · f052154d
      Jeff King authored
      We'll want to use this logic as a fallback when looking up
      the pushremote, so let's pull it out into its own function.
      
      We don't technically need to make this available outside of
      remote.c, but doing so will provide a consistent API with
      pushremote_for_branch, which we will add later.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      f052154d
    • Jeff King's avatar
      remote.c: drop "remote" pointer from "struct branch" · 9e3751d4
      Jeff King authored
      When we create each branch struct, we fill in the
      "remote_name" field from the config, and then fill in the
      actual "remote" field (with a "struct remote") based on that
      name. However, it turns out that nobody really cares about
      the latter field. The only two sites that access it at all
      are:
      
        1. git-merge, which uses it to notice when the branch does
           not have a remote defined. But we can easily replace this
           with looking at remote_name instead.
      
        2. remote.c itself, when setting up the @{upstream} merge
           config. But we don't need to save the "remote" in the
           "struct branch" for that; we can just look it up for
           the duration of the operation.
      
      So there is no need to have both fields; they are redundant
      with each other (the struct remote contains the name, or you
      can look up the struct from the name). It would be nice to
      simplify this, especially as we are going to add matching
      pushremote config in a future patch (and it would be nice to
      keep them consistent).
      
      So which one do we keep and which one do we get rid of?
      
      If we had a lot of callers accessing the struct, it would be
      more efficient to keep it (since you have to do a lookup to
      go from the name to the struct, but not vice versa). But we
      don't have a lot of callers; we have exactly one, so
      efficiency doesn't matter. We can decide this based on
      simplicity and readability.
      
      And the meaning of the struct value is somewhat unclear. Is
      it always the remote matching remote_name? If remote_name is
      NULL (i.e., no per-branch config), does the struct fall back
      to the "origin" remote, or is it also NULL? These questions
      will get even more tricky with pushremotes, whose fallback
      behavior is more complicated. So let's just store the name,
      which pretty clearly represents the branch.*.remote config.
      Any lookup or fallback behavior can then be implemented in
      helper functions.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9e3751d4