1. 16 Jan, 2007 3 commits
  2. 15 Jan, 2007 16 commits
    • Jeff King's avatar
      git-pull: disallow implicit merging to detached HEAD · a74b1706
      Jeff King authored
      Instead, we complain to the user and suggest that they explicitly
      specify the remote and branch. We depend on the exit status of
      git-symbolic-ref, so let's go ahead and document that.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      a74b1706
    • Junio C Hamano's avatar
      Fix git-fetch while on detached HEAD not to give needlessly alarming errors · a0f4280f
      Junio C Hamano authored
      When we are on a detached HEAD, there is no current branch.
      There is no reason to leak the error messages to the end user
      since this is a situation we expect to see.
      
      This adds -q option to git-symbolic-ref to exit without issuing
      an error message if the given name is not a symbolic ref.
      
      By the way, with or without this patch, there currently is no
      good way to tell failure modes between "git symbolic-ref HAED"
      and "git symbolic-ref HEAD".  Both says "is not a symbolic ref".
      
      We may want to do something about it.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      a0f4280f
    • Junio C Hamano's avatar
      15261e3b
    • Junio C Hamano's avatar
      Merge git://git.kernel.org/pub/scm/gitk/gitk · 38ebbacd
      Junio C Hamano authored
      * git://git.kernel.org/pub/scm/gitk/gitk:
        [PATCH] Make gitk work when launched in a subdirectory
        [PATCH] gitk: add current directory to main window title
      38ebbacd
    • Shawn O. Pearce's avatar
      Use nice names in conflict markers during cherry-pick/revert. · 6e2931a8
      Shawn O. Pearce authored
      Always call the current HEAD 'HEAD', and name the patch being
      cherry-picked or reverted by its oneline subject rather than
      its SHA1.  This matches git am's behavior and is done because
      users most commonly are cherry-picking by SHA1 rather than by
      ref name.
      Signed-off-by: default avatarShawn O. Pearce <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      6e2931a8
    • Junio C Hamano's avatar
      Use merge-recursive in git-revert/git-cherry-pick · acb4441e
      Junio C Hamano authored
      This makes revert and cherry-pick to use merge-recursive, to
      allow them to notice renames.  A pair of test scripts
      demonstrate that an old change before a rename happened can be
      applied (reverted) after a rename with cherry-pick (with revert).
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      acb4441e
    • Junio C Hamano's avatar
      Documentation: merge-output is not too verbose now. · 5fe3acc4
      Junio C Hamano authored
      We've squelched output from merge-recursive, and git-merge when
      used with recursive does not attempt the trivial one first
      anymore, so there won't be "Trying ... Nope." messages now.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5fe3acc4
    • Shawn O. Pearce's avatar
      Remove hash in git-describe in favor of util slot. · e7eb5034
      Shawn O. Pearce authored
      Currently we don't use the util field of struct commit but we want
      fast access to the highest priority name that references any given
      commit object during our matching loop.  A really simple approach
      is to just store the name directly in the util field.
      Signed-off-by: default avatarShawn O. Pearce <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      e7eb5034
    • Shawn O. Pearce's avatar
      Correct priority of lightweight tags in git-describe. · cf69fd49
      Shawn O. Pearce authored
      We really want to always favor an annotated tag over a lightweight
      tag when describing a commit.  Unfortunately git-describe wasn't
      doing this as it was favoring the depth attribute of a possible_tag
      over the priority.  Now priority is the highest sort and we only
      consider a lightweight tag if no annotated tags were identified.
      
      Rather than searching for the minimum tag using a simple loop we
      now sort them using a stable sort algorithm, this way the possible
      tags display in order if --debug gets used.  The stable sort helps
      to preseve the inherit topology/date order that we obtain during
      our search loop.
      
      This fix allows the tests in t6120-describe.sh to pass.
      Signed-off-by: default avatarShawn O. Pearce <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      cf69fd49
    • Junio C Hamano's avatar
      Add describe test. · 5312ab11
      Junio C Hamano authored
      ... with help from Shawn.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5312ab11
    • Shawn O. Pearce's avatar
      Improve git-describe performance by reducing revision listing. · 8713ab30
      Shawn O. Pearce authored
      My prior version of git-describe ran very slowly on even reasonably
      sized projects like git.git and linux.git as it tended to identify
      a large number of possible tags and then needed to generate the
      revision list for each of those tags to sort them and select the
      best tag to describe the input commit.
      
      All we really need is the number of commits in the input revision
      which are not in the tag.  We can generate these counts during
      the revision walking and tag matching loop by assigning a color to
      each tag and coloring the commits as we walk them.  This limits us
      to identifying no more than 26 possible tags, as there is limited
      space available within the flags field of struct commit.
      
      The limitation of 26 possible tags is hopefully not going to be a
      problem in real usage, as most projects won't create 26 maintenance
      releases and merge them back into a development trunk after the
      development trunk was tagged with a release candidate tag.  If that
      does occur git-describe will start to revert to its old behavior of
      using the newer maintenance release tag to describe the development
      trunk, rather than the development trunk's own tag.  The suggested
      workaround would be to retag the development trunk's tip.
      
      However since even 26 possible tags can take a while to generate a
      description for on some projects I'm defaulting the limit to 10 but
      offering the user --candidates to increase the number of possible
      matches if they need a more accurate result.  I specifically chose
      10 for the default as it seems unlikely projects will have more
      than 10 maintenance releases merged into a development trunk before
      retagging the development trunk, and it seems to perform about the
      same on linux.git as v1.4.4.4 git-describe.
      
      A large amount of debugging information was also added during
      the development of this change, so I've left it in to be toggled
      on with --debug.  It may be useful to the end user to help them
      understand why git-describe took one particular tag over another.
      Signed-off-by: default avatarShawn O. Pearce <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      8713ab30
    • Shawn O. Pearce's avatar
      Use binary searching on large buckets in git-describe. · 910c0d7b
      Shawn O. Pearce authored
      If a project has a really huge number of tags (such as several
      thousand tags) then we are likely to have nearly a hundred tags in
      some buckets.  Scanning those buckets as linked lists could take
      a large amount of time if done repeatedly during history traversal.
      
      Since we are searching for a unique commit SHA1 we can sort all
      tags by commit SHA1 and perform a binary search within the bucket.
      Once we identify a particular tag as matching this commit we walk
      backwards within the bucket matches to make sure we pick up the
      highest priority tag for that commit, as the binary search may
      have landed us in the middle of a set of tags which point at the
      same commit.
      Signed-off-by: default avatarShawn O. Pearce <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      910c0d7b
    • Shawn O. Pearce's avatar
      Hash tags by commit SHA1 in git-describe. · c3e3cd4b
      Shawn O. Pearce authored
      If a project has a very large number of tags then git-describe
      will spend a good part of its time looping over the tags testing
      them one at a time to determine if it matches a given commit.
      For 10 tags this is not a big deal, but for hundreds of tags the
      time could become considerable if we don't find an exact match for
      the input commit and we need to walk back along the history chain.
      Signed-off-by: default avatarShawn O. Pearce <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      c3e3cd4b
    • Shawn O. Pearce's avatar
      Always perfer annotated tags in git-describe. · dccd0c2a
      Shawn O. Pearce authored
      Several people have suggested that its always better to describe
      a commit using an annotated tag, and to only use a lightweight tag
      if absolutely no annotated tag matches the input commit.
      Signed-off-by: default avatarShawn O. Pearce <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      dccd0c2a
    • Nicolas Pitre's avatar
      some doc updates · c14261ea
      Nicolas Pitre authored
      1) talk about "git merge" instead of "git pull ."
      
      2) suggest "git repo-config" instead of directly editing config files
      
      3) echo "URL: blah" > .git/remotes/foo is obsolete and should be
         "git repo-config remote.foo.url blah"
      
      4) support for partial URL prefix has been removed (see commit
         ea560e6d) so drop mention of it.
      Signed-off-by: default avatarNicolas Pitre <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      c14261ea
    • Junio C Hamano's avatar
      git log documentation: teach -<n> form. · adb7ba6b
      Junio C Hamano authored
      We say "this shows only the most often used ones"; so instead of
      teaching --max-number=<n> form, list -<n> form which is much
      easier to type.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      adb7ba6b
  3. 14 Jan, 2007 11 commits
  4. 13 Jan, 2007 10 commits