1. 28 Jun, 2016 1 commit
  2. 01 Nov, 2015 1 commit
  3. 12 Jul, 2015 2 commits
  4. 07 Jul, 2015 1 commit
  5. 06 Jul, 2015 3 commits
  6. 17 Jun, 2015 1 commit
  7. 14 Mar, 2015 1 commit
  8. 07 Jan, 2015 2 commits
    • Duy Nguyen's avatar
      git-checkout.txt: a note about multiple checkout support for submodules · a83a66ac
      Duy Nguyen authored
      The goal seems to be using multiple checkouts to reduce disk space.
      But we have not reached an agreement how things should be. There are a
      couple options.
      
       - You may want to keep $SUB repos elsewhere (perhaps in a central
         place) outside $SUPER. This is also true for nested submodules
         where a superproject may be a submodule of another superproject.
      
       - You may want to keep all $SUB repos in $SUPER/modules (or some
         other place in $SUPER)
      
       - We could even push it further and merge all $SUB repos into $SUPER
         instead of storing them separately. But that would at least require
         ref namespace enabled.
      
      On top of that, git-submodule.sh expects $GIT_DIR/config to be
      per-worktree, at least for the submodule.* part. Here I think we have
      two options, either update config.c to also read
      $GIT_DIR/config.worktree (which is per worktree) in addition to
      $GIT_DIR/config (shared) and store worktree-specific vars in the new
      place, or update git-submodule.sh to read/write submodule.* directly
      from $GIT_DIR/config.submodule (per worktree).
      
      These take time to address properly. Meanwhile, make a note to the
      user that they should not use multiple worktrees in submodule context.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      a83a66ac
    • Duy Nguyen's avatar
  9. 01 Dec, 2014 3 commits
  10. 21 Jan, 2014 1 commit
  11. 11 Sep, 2013 1 commit
  12. 21 Apr, 2013 1 commit
    • Johan Herland's avatar
      checkout: Use remote refspecs when DWIMming tracking branches · fa83a33b
      Johan Herland authored
      The DWIM mode of checkout allows you to run "git checkout foo" when there
      is no existing local ref or path called "foo", and there is exactly _one_
      remote with a remote-tracking branch called "foo". Git will automatically
      create a new local branch called "foo" using the remote-tracking "foo" as
      its starting point and configured upstream.
      
      For example, consider the following unconventional (but perfectly valid)
      remote setup:
      
      	[remote "origin"]
      		fetch = refs/heads/*:refs/remotes/origin/*
      	[remote "frotz"]
      		fetch = refs/heads/*:refs/remotes/frotz/nitfol/*
      
      Case 1: Assume both "origin" and "frotz" have remote-tracking branches called
      "foo", at "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo"
      respectively. In this case "git checkout foo" should fail, because there is
      more than one remote with a "foo" branch.
      
      Case 2: Assume only "frotz" have a remote-tracking branch called "foo". In
      this case "git checkout foo" should succeed, and create a local branch "foo"
      from "refs/remotes/frotz/nitfol/foo", using remote branch "foo" from "frotz"
      as its upstream.
      
      The current code hardcodes the assumption that all remote-tracking branches
      must match the "refs/remotes/$remote/*" pattern (which is true for remotes
      with "conventional" refspecs, but not true for the "frotz" remote above).
      When running "git checkout foo", the current code looks for exactly one ref
      matching "refs/remotes/*/foo", hence in the above example, it fails to find
      "refs/remotes/frotz/nitfol/foo", which causes it to fail both case #1 and #2.
      
      The better way to handle the above example is to actually study the fetch
      refspecs to deduce the candidate remote-tracking branches for "foo"; i.e.
      assume "foo" is a remote branch being fetched, and then map "refs/heads/foo"
      through the refspecs in order to get the corresponding remote-tracking
      branches "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo".
      Finally we check which of these happens to exist in the local repo, and
      if there is exactly one, we have an unambiguous match for "git checkout foo",
      and may proceed.
      
      This fixes most of the failing tests introduced in the previous patch.
      Signed-off-by: default avatarJohan Herland <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      fa83a33b
  13. 15 Apr, 2013 1 commit
  14. 01 Feb, 2013 1 commit
  15. 18 Dec, 2012 2 commits
  16. 04 Sep, 2012 1 commit
  17. 26 Aug, 2012 1 commit
  18. 26 Apr, 2012 1 commit
    • Jeff King's avatar
      docs: stop using asciidoc no-inline-literal · 6cf378f0
      Jeff King authored
      In asciidoc 7, backticks like `foo` produced a typographic
      effect, but did not otherwise affect the syntax. In asciidoc
      8, backticks introduce an "inline literal" inside which markup
      is not interpreted. To keep compatibility with existing
      documents, asciidoc 8 has a "no-inline-literal" attribute to
      keep the old behavior. We enabled this so that the
      documentation could be built on either version.
      
      It has been several years now, and asciidoc 7 is no longer
      in wide use. We can now decide whether or not we want
      inline literals on their own merits, which are:
      
        1. The source is much easier to read when the literal
           contains punctuation. You can use `master~1` instead
           of `master{tilde}1`.
      
        2. They are less error-prone. Because of point (1), we
           tend to make mistakes and forget the extra layer of
           quoting.
      
      This patch removes the no-inline-literal attribute from the
      Makefile and converts every use of backticks in the
      documentation to an inline literal (they must be cleaned up,
      or the example above would literally show "{tilde}" in the
      output).
      
      Problematic sites were found by grepping for '`.*[{\\]' and
      examined and fixed manually. The results were then verified
      by comparing the output of "html2text" on the set of
      generated html pages. Doing so revealed that in addition to
      making the source more readable, this patch fixes several
      formatting bugs:
      
        - HTML rendering used the ellipsis character instead of
          literal "..." in code examples (like "git log A...B")
      
        - some code examples used the right-arrow character
          instead of '->' because they failed to quote
      
        - api-config.txt did not quote tilde, and the resulting
          HTML contained a bogus snippet like:
      
            <tt><sub></tt> foo <tt></sub>bar</tt>
      
          which caused some parsers to choke and omit whole
          sections of the page.
      
        - git-commit.txt confused ``foo`` (backticks inside a
          literal) with ``foo'' (matched double-quotes)
      
        - mentions of `A U Thor <[email protected]>` used to
          erroneously auto-generate a mailto footnote for
          [email protected]
      
        - the description of --word-diff=plain incorrectly showed
          the output as "[-removed-] and {added}", not "{+added+}".
      
        - using "prime" notation like:
      
            commit `C` and its replacement `C'`
      
          confused asciidoc into thinking that everything between
          the first backtick and the final apostrophe were meant
          to be inside matched quotes
      
        - asciidoc got confused by the escaping of some of our
          asterisks. In particular,
      
            `credential.\*` and `credential.<url>.\*`
      
          properly escaped the asterisk in the first case, but
          literally passed through the backslash in the second
          case.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      6cf378f0
  19. 05 May, 2011 1 commit
  20. 11 Mar, 2011 1 commit
    • Jeff King's avatar
      doc: drop author/documentation sections from most pages · 48bb914e
      Jeff King authored
      The point of these sections is generally to:
      
        1. Give credit where it is due.
      
        2. Give the reader an idea of where to ask questions or
           file bug reports.
      
      But they don't do a good job of either case. For (1), they
      are out of date and incomplete. A much more accurate answer
      can be gotten through shortlog or blame.  For (2), the
      correct contact point is generally [email protected], and even if you
      wanted to cc the contact point, the out-of-date and
      incomplete fields mean you're likely sending to somebody
      useless.
      
      So let's drop the fields entirely from all manpages except
      git(1) itself. We already point people to the mailing list
      for bug reports there, and we can update the Authors section
      to give credit to the major contributors and point to
      shortlog and blame for more information.
      
      Each page has a "This is part of git" footer, so people can
      follow that to the main git manpage.
      48bb914e
  21. 22 Feb, 2011 1 commit
  22. 08 Feb, 2011 1 commit
  23. 03 Nov, 2010 1 commit
  24. 27 Sep, 2010 1 commit
  25. 20 Aug, 2010 1 commit
  26. 09 Jul, 2010 1 commit
  27. 25 Jun, 2010 1 commit
  28. 11 Jun, 2010 1 commit
  29. 02 Jun, 2010 2 commits
  30. 01 Jun, 2010 1 commit
  31. 21 Mar, 2010 1 commit
    • Erick Mattos's avatar
      git checkout: create unparented branch by --orphan · 9db5ebf4
      Erick Mattos authored
      Similar to -b, --orphan creates a new branch, but it starts without any
      commit.  After running "git checkout --orphan newbranch", you are on a
      new branch "newbranch", and the first commit you create from this state
      will start a new history without any ancestry.
      
      "git checkout --orphan" keeps the index and the working tree files
      intact in order to make it convenient for creating a new history whose
      trees resemble the ones from the original branch.
      
      When creating a branch whose trees have no resemblance to the ones from
      the original branch, it may be easier to start work on the new branch by
      untracking and removing all working tree files that came from the
      original branch, by running a 'git rm -rf .' immediately after running
      "checkout --orphan".
      Signed-off-by: default avatarErick Mattos <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      9db5ebf4
  32. 29 Aug, 2009 1 commit