This project is mirrored from https://github.com/git/git. Pull mirroring updated .
  1. 13 Dec, 2011 7 commits
  2. 12 Dec, 2011 10 commits
    • Jeff King's avatar
      credentials: add "cache" helper · e2770979
      Jeff King authored
      If you access repositories over smart-http using http
      authentication, then it can be annoying to have git ask you
      for your password repeatedly. We cache credentials in
      memory, of course, but git is composed of many small
      programs. Having to input your password for each one can be
      frustrating.
      
      This patch introduces a credential helper that will cache
      passwords in memory for a short period of time.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      e2770979
    • Jeff King's avatar
      docs: end-user documentation for the credential subsystem · a6fc9fd3
      Jeff King authored
      The credential API and helper format is already defined in
      technical/api-credentials.txt.  This presents the end-user
      view.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      a6fc9fd3
    • Jeff King's avatar
      credential: make relevance of http path configurable · a78fbb4f
      Jeff King authored
      When parsing a URL into a credential struct, we carefully
      record each part of the URL, including the path on the
      remote host, and use the result as part of the credential
      context.
      
      This had two practical implications:
      
        1. Credential helpers which store a credential for later
           access are likely to use the "path" portion as part of
           the storage key. That means that a request to
      
             https://example.com/foo.git
      
           would not use the same credential that was stored in an
           earlier request for:
      
             https://example.com/bar.git
      
        2. The prompt shown to the user includes all relevant
           context, including the path.
      
      In most cases, however, users will have a single password
      per host. The behavior in (1) will be inconvenient, and the
      prompt in (2) will be overly long.
      
      This patch introduces a config option to toggle the
      relevance of http paths. When turned on, we use the path as
      before. When turned off, we drop the path component from the
      context: helpers don't see it, and it does not appear in the
      prompt.
      
      This is nothing you couldn't do with a clever credential
      helper at the start of your stack, like:
      
        [credential "http://"]
      	helper = "!f() { grep -v ^path= ; }; f"
      	helper = your_real_helper
      
      But doing this:
      
        [credential]
      	useHttpPath = false
      
      is way easier and more readable. Furthermore, since most
      users will want the "off" behavior, that is the new default.
      Users who want it "on" can set the variable (either for all
      credentials, or just for a subset using
      credential.*.useHttpPath).
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      a78fbb4f
    • Jeff King's avatar
      credential: add credential.*.username · d5742425
      Jeff King authored
      Credential helpers can help users avoid having to type their
      username and password over and over. However, some users may
      not want a helper for their password, or they may be running
      a helper which caches for a short time. In this case, it is
      convenient to provide the non-secret username portion of
      their credential via config.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      d5742425
    • Jeff King's avatar
      credential: apply helper config · 11825072
      Jeff King authored
      The functionality for credential storage helpers is already
      there; we just need to give the users a way to turn it on.
      This patch provides a "credential.helper" configuration
      variable which allows the user to provide one or more helper
      strings.
      
      Rather than simply matching credential.helper, we will also
      compare URLs in subsection headings to the current context.
      This means you can apply configuration to a subset of
      credentials. For example:
      
        [credential "https://example.com"]
      	helper = foo
      
      would match a request for "https://example.com/foo.git", but
      not one for "https://kernel.org/foo.git".
      
      This is overkill for the "helper" variable, since users are
      unlikely to want different helpers for different sites (and
      since helpers run arbitrary code, they could do the matching
      themselves anyway).
      
      However, future patches will add new config variables where
      this extra feature will be more useful.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      11825072
    • Jeff King's avatar
      http: use credential API to get passwords · 148bb6a7
      Jeff King authored
      This patch converts the http code to use the new credential
      API, both for http authentication as well as for getting
      certificate passwords.
      
      Most of the code change is simply variable naming (the
      passwords are now contained inside the credential struct)
      or deletion of obsolete code (the credential code handles
      URL parsing and prompting for us).
      
      The behavior should be the same, with one exception: the
      credential code will prompt with a description based on the
      credential components. Therefore, the old prompt of:
      
        Username for 'example.com':
        Password for 'example.com':
      
      now looks like:
      
        Username for 'https://example.com/repo.git':
        Password for 'https://[email protected]/repo.git':
      
      Note that we include more information in each line,
      specifically:
      
        1. We now include the protocol. While more noisy, this is
           an important part of knowing what you are accessing
           (especially if you care about http vs https).
      
        2. We include the username in the password prompt. This is
           not a big deal when you have just been prompted for it,
           but the username may also come from the remote's URL
           (and after future patches, from configuration or
           credential helpers).  In that case, it's a nice
           reminder of the user for which you're giving the
           password.
      
        3. We include the path component of the URL. In many
           cases, the user won't care about this and it's simply
           noise (i.e., they'll use the same credential for a
           whole site). However, that is part of a larger
           question, which is whether path components should be
           part of credential context, both for prompting and for
           lookup by storage helpers. That issue will be addressed
           as a whole in a future patch.
      
      Similarly, for unlocking certificates, we used to say:
      
        Certificate Password for 'example.com':
      
      and we now say:
      
        Password for 'cert:///path/to/certificate':
      
      Showing the path to the client certificate makes more sense,
      as that is what you are unlocking, not "example.com".
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      148bb6a7
    • Jeff King's avatar
      credential: add function for parsing url components · d3e847c1
      Jeff King authored
      All of the components of a credential struct can be found in
      a URL.  For example, the URL:
      
        http://foo:[email protected]/repo.git
      
      contains:
      
        protocol=http
        host=example.com
        path=repo.git
        username=foo
        password=bar
      
      We want to be able to turn URLs into broken-down credential
      structs so that we know two things:
      
        1. Which parts of the username/password we still need
      
        2. What the context of the request is (for prompting or
           as a key for storing credentials).
      
      This code is based on http_auth_init in http.c, but needed a
      few modifications in order to get all of the components that
      the credential object is interested in.
      
      Once the http code is switched over to the credential API,
      then http_auth_init can just go away.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      d3e847c1
    • Jeff King's avatar
      introduce credentials API · abca927d
      Jeff King authored
      There are a few places in git that need to get a username
      and password credential from the user; the most notable one
      is HTTP authentication for smart-http pushing.
      
      Right now the only choices for providing credentials are to
      put them plaintext into your ~/.netrc, or to have git prompt
      you (either on the terminal or via an askpass program). The
      former is not very secure, and the latter is not very
      convenient.
      
      Unfortunately, there is no "always best" solution for
      password management. The details will depend on the tradeoff
      you want between security and convenience, as well as how
      git can integrate with other security systems (e.g., many
      operating systems provide a keychain or password wallet for
      single sign-on).
      
      This patch provides an abstract notion of credentials as a
      data item, and provides three basic operations:
      
        - fill (i.e., acquire from external storage or from the
          user)
      
        - approve (mark a credential as "working" for further
          storage)
      
        - reject (mark a credential as "not working", so it can
          be removed from storage)
      
      These operations can be backed by external helper processes
      that interact with system- or user-specific secure storage.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      abca927d
    • Jeff King's avatar
      t5550: fix typo · 89650285
      Jeff King authored
      This didn't have an impact, because it was just setting up
      an "expect" file that happened to be identical to the one in
      the test before it.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      89650285
    • Jeff King's avatar
      test-lib: add test_config_global variant · a96250c6
      Jeff King authored
      The point of test_config is to simultaneously set a config
      variable and register its cleanup handler, like:
      
        test_config core.foo bar
      
      However, it stupidly assumes that $1 contained the name of
      the variable, which means it won't work for:
      
        test_config --global core.foo bar
      
      We could try to parse the command-line ourselves and figure
      out which parts need to be fed to test_unconfig. But since
      this is likely the most common variant, it's much simpler
      and less error-prone to simply add a new function.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      a96250c6
  3. 23 Nov, 2011 4 commits
  4. 22 Nov, 2011 4 commits
    • Jonathan Nieder's avatar
      revert: write REVERT_HEAD pseudoref during conflicted revert · 82433cdf
      Jonathan Nieder authored
      When conflicts are encountered while reverting a commit, it can be
      handy to have the name of that commit easily available.  For example,
      to produce a copy of the patch to refer to while resolving conflicts:
      
      	$ git revert 2eceb2a8
      	error: could not revert 2eceb2a8... awesome, buggy feature
      	$ git show -R REVERT_HEAD >the-patch
      	$ edit $(git diff --name-only)
      
      Set a REVERT_HEAD pseudoref when "git revert" does not make a commit,
      for cases like this.  This also makes it possible for scripts to
      distinguish between a revert that encountered conflicts and other
      sources of an unmerged index.
      
      After successfully committing, resetting with "git reset", or moving
      to another commit with "git checkout" or "git reset", the pseudoref is
      no longer useful, so remove it.
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      82433cdf
    • Jonathan Nieder's avatar
      revert: improve error message for cherry-pick during cherry-pick · b8c74690
      Jonathan Nieder authored
      In the spirit of v1.6.3.3~3^2 (refuse to merge during a merge,
      2009-07-01), "git cherry-pick" refuses to start a new cherry-pick when
      in the middle of an existing conflicted cherry-pick in the following
      sequence:
      
       1. git cherry-pick HEAD..origin
       2. resolve conflicts
       3. git cherry-pick HEAD..origin (instead of "git cherry-pick
          --continue", by mistake)
      
      Good.  However, the error message on attempting step 3 is more
      convoluted than necessary:
      
        $ git cherry-pick HEAD..origin
        error: .git/sequencer already exists.
        error: A cherry-pick or revert is in progress.
        hint: Use --continue to continue the operation
        hint: or --quit to forget about it
        fatal: cherry-pick failed
      
      Clarify by removing the redundant first "error:" message, simplifying
      the advice, and using lower-case and no full stops to be consistent
      with other commands that prefix their messages with "error:", so it
      becomes
      
        error: a cherry-pick or revert is already in progress
        hint: try "git cherry-pick (--continue | --quit)"
        fatal: cherry-pick failed
      
      The "fatal: cherry-pick failed" line seems unnecessary, too, but
      that can be fixed some other day.
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      b8c74690
    • Jonathan Nieder's avatar
      revert: rearrange pick_revisions() for clarity · dffc8600
      Jonathan Nieder authored
      Deal completely with "cherry-pick --quit" and --continue at the
      beginning of pick_revisions(), leaving the rest of the function for
      the more interesting "git cherry-pick <commits>" case.
      
      No functional change intended.  The impact is just to unindent the
      code a little.
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      dffc8600
    • Jonathan Nieder's avatar
      revert: rename --reset option to --quit · f80a8726
      Jonathan Nieder authored
      The option to "git cherry-pick" and "git revert" to discard the
      sequencer state introduced by v1.7.8-rc0~141^2~6 (revert: Introduce
      --reset to remove sequencer state, 2011-08-04) has a confusing name.
      Change it now, while we still have the time.
      
      The new name for "cherry-pick, please get out of my way, since I've
      long forgotten about the sequence of commits I was cherry-picking when
      you wrote that old .git/sequencer directory" is --quit.  Mnemonic:
      this is analagous to quiting a program the user is no longer using ---
      we just want to get out of the multiple-command cherry-pick procedure
      and not to reset HEAD or rewind any other old state.
      
      The "--reset" option is kept as a synonym to minimize the impact.  We
      might consider dropping it for simplicity in a separate patch, though.
      
      Adjust documentation and tests to use the newly preferred name (--quit)
      instead of --reset.  While at it, let's clarify the short descriptions
      of these operations in "-h" output.
      
      Before:
      
      	--reset		forget the current operation
      	--continue	continue the current operation
      
      After:
      
      	--quit		end revert or cherry-pick sequence
      	--continue	resume revert or cherry-pick sequence
      Noticed-by: Phil Hord's avatarPhil Hord <[email protected]>
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      f80a8726
  5. 21 Nov, 2011 6 commits
    • Junio C Hamano's avatar
      Merge branch 'maint' · e14d6319
      Junio C Hamano authored
      * maint:
        documentation fix: git difftool uses diff tools, not merge tools.
      e14d6319
    • Junio C Hamano's avatar
      Merge branch 'rr/misc-fixes' · 0f64a5a3
      Junio C Hamano authored
      * rr/misc-fixes:
        convert.c: Fix return type of git_path_check_eol()
      0f64a5a3
    • Ramsay Jones's avatar
      convert.c: Fix return type of git_path_check_eol() · ef563de6
      Ramsay Jones authored
      The git_path_check_eol() function converts a string value to the
      corresponding 'enum eol' value. However, the function is currently
      declared to return an 'enum crlf_action', which causes sparse to
      complain thus:
      
              SP convert.c
          convert.c:736:50: warning: mixing different enum types
          convert.c:736:50:     int enum crlf_action  versus
          convert.c:736:50:     int enum eol
      
      In order to suppress the warning, we simply correct the return type
      in the function declaration.
      Signed-off-by: default avatarRamsay Jones <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      ef563de6
    • Thomas Hochstein's avatar
      documentation fix: git difftool uses diff tools, not merge tools. · 1e501a7c
      Thomas Hochstein authored
      Let the documentation for -t list valid *diff* tools,
      not valid *merge* tools.
      Signed-off-by: default avatarThomas Hochstein <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      1e501a7c
    • Ramsay Jones's avatar
      config.c: Fix a static buffer overwrite bug by avoiding mkpath() · 05bab3ea
      Ramsay Jones authored
      On cygwin, test number 21 of t3200-branch.sh (git branch -m q q2
      without config should succeed) fails. The failure involves the
      functions from path.c which parcel out internal static buffers
      from the git_path() and mkpath() functions.
      
      In particular, the rename_ref() function calls safe_create_leading\
      _directories() with a filename returned by git_path("logs/%s", ref).
      safe_create_leading_directories(), in turn, calls stat() on each
      element of the path it is given. On cygwin, this leads to a call
      to git_config() for each component of the path, since this test
      explicitly removes the config file. git_config() calls mkpath(), so
      on the fourth component of the path, the original buffer passed
      into the function is overwritten with the config filename.
      
      Note that this bug is specific to cygwin and it's schizophrenic
      stat() functions (see commits adbc0b6b, 7faee6b8 and 79748439). The
      lack of a config file and a path with at least four elements is
      also important to trigger the bug.
      
      In order to fix the problem, we replace the call to mkpath() with
      a call to mksnpath() and provide our own buffer.
      Signed-off-by: default avatarRamsay Jones <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      05bab3ea
    • Ramsay Jones's avatar
      t5501-*.sh: Fix url passed to clone in setup test · 3a81f33c
      Ramsay Jones authored
      In particular, the url passed to git-clone has an extra '/' given
      after the 'file://' schema prefix, thus:
      
          git clone --reference=original "file:///$(pwd)/original one
      
      Once the prefix is removed, the remainder of the url looks something
      like "//home/ramsay/git/t/...", which is then interpreted as an
      network path. This then results in a "Permission denied" error, like
      so:
      
          ramsay $ ls //home
          ls: cannot access //home: No such host or network path
          ramsay $ ls //home/ramsay
          ls: cannot access //home/ramsay: Permission denied
          ramsay $
      
      In order to fix the problem, we simply remove the extraneous '/'
      character from the url.
      Signed-off-by: default avatarRamsay Jones <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      3a81f33c
  6. 18 Nov, 2011 9 commits