Skip to content
Commits on Jan 31, 2010
  1. @jrn @gitster

    Do not install shell libraries executable

    jrn committed with gitster Jan 31, 2010
    Some scripts are expected to be sourced instead of executed on their own.
    Avoid some confusion by not marking them executable.
    
    The executable bit was confusing the valgrind support of our test scripts,
    which assumed that any executable without a #!-line should be intercepted
    and run through valgrind.  So during valgrind-enabled tests, any script
    sourcing these files actually sourced the valgrind interception script
    instead.
    
    Reported-by: Jeff King <peff@peff.net>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jun 12, 2009
  1. @gitster

    parse-remote: remove unused functions

    Santi Béjar committed with gitster Jun 12, 2009
    Signed-off-by: Santi Béjar <santi@agolina.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @gitster

    parse-remote: support default reflist in get_remote_merge_branch

    Santi Béjar committed with gitster Jun 12, 2009
    Expand get_remote_merge_branch to compute the tracking branch to merge
    when called without arguments (or only the remote name). This allows
    "git pull --rebase" without arguments (default upstream branch) to
    work with a rebased upstream. With explicit arguments it already worked.
    
    Also add a test to check for this case.
    
    Signed-off-by: Santi Béjar <santi@agolina.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  3. @gitster

    parse-remote: function to get the tracking branch to be merge

    Santi Béjar committed with gitster Jun 12, 2009
    The only user of get_remote_refs_for_fetch was "git pull --rebase" and
    it only wanted the tracking branch to be merge. So, add a simple
    function (get_remote_merge_branch) with this new meaning.
    
    No behavior changes. The new function behaves like the old code in
    "git pull --rebase". In particular, it only works with the default
    refspec mapping and with remote branches, not tags.
    
    Signed-off-by: Santi Béjar <santi@agolina.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Apr 23, 2009
  1. @gitster

    Convert to use quiet option when available

    Dan Loewenherz committed with gitster Apr 22, 2009
    A minor fix that eliminates usage of "2>/dev/null" when --quiet or
    -q has already been implemented.
    
    Signed-off-by: Dan Loewenherz <daniel.loewenherz@yale.edu>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jul 3, 2007
  1. @gitster

    Rewrite "git-frotz" to "git frotz"

    gitster committed Jul 2, 2007
    This uses the remove-dashes target to replace "git-frotz" to "git frotz".
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on May 12, 2007
  1. @raalkml

    Allow fetching references from any namespace

    raalkml committed with Junio C Hamano May 11, 2007
    not only from the three defined: heads, tags and remotes.
    
    Noticed when I tried to fetch the references created by git-p4-import.bat:
    they are placed into separate namespace (refs/p4import/, to avoid showing
    them in git-branch output). As canon_refs_list_for_fetch always prepended
    refs/heads/ it was impossible, and annoying: it worked before. Normally,
    the p4import references are useless anywhere but in the directory managed
    by perforce, but in this special case the cloned directory was supposed
    to be a backup, including the p4import branch: it keeps information about
    where the imported perforce state came from.
    
    Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Mar 16, 2007
  1. @bonzini

    git-fetch, git-branch: Support local --track via a special remote '.'

    bonzini committed with Junio C Hamano Mar 15, 2007
    This patch adds support for a dummy remote '.' to avoid having
    to declare a fake remote like
    
            [remote "local"]
                    url = .
                    fetch = refs/heads/*:refs/heads/*
    
    Such a builtin remote simplifies the operation of "git-fetch",
    which will populate FETCH_HEAD but will not pretend that two
    repositories are in use, will not create a thin pack, and will
    not perform any useless remapping of names.  The speed
    improvement is around 20%, and it should improve more if
    "git-fetch" is converted to a builtin.
    
    To this end, git-parse-remote is grown with a new kind of
    remote, 'builtin'.  In git-fetch.sh, we treat the builtin remote
    specially in that it needs no pack/store operations.  In fact,
    doing git-fetch on a builtin remote will simply populate
    FETCH_HEAD appropriately.
    
    The patch also improves of the --track/--no-track support,
    extending it so that branch.<name>.remote items referring '.'
    can be created.  Finally, it fixes a typo in git-checkout.sh.
    
    Signed-off-by: Paolo Bonzini  <bonzini@gnu.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Feb 14, 2007
  1. Use stdin reflist passing in parse-remote

    Julian Phillips committed with Junio C Hamano Feb 13, 2007
    Use the new stdin reflist passing mechanism for the call to
    fetch--tool expand-refs-wildcard, allowing passing of more
    than ~128K of reflist data.
    
    Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. git-fetch: rewrite expand_ref_wildcard in C

    Junio C Hamano committed Jan 16, 2007
    This does not seem to make measurable improvement when dealing
    with 1000 unpacked refs, but we would need something like it
    if we were to do a full rewrite in C somedaoy.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Feb 5, 2007
  1. Revert "Allow branch.*.merge to talk about remote tracking branches."

    Junio C Hamano committed Feb 3, 2007
    This reverts commit 80c7977.
    
    Back when I committed this, it seemed to be a good idea.  People
    who always use remote tracking branches can optionally use the
    local name they happen to use to specify what to merge, which meant
    that I did not have to teach them why we use the name at the remote
    side every time they are confused.
    
    But allowing it seems to break other people's scripts.  The real
    solution is not to allow more ways to express the same thing, but
    to educate people to use the right syntax.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Jan 30, 2007
  1. git-fetch: Allow fetching the remote HEAD

    Santi Béjar committed with Junio C Hamano Jan 30, 2007
    ... with:
    
    $ git fetch ${remote} HEAD
    
    Also
    
    $ git fetch ${remote} :${localref}
    
    worked, but
    
    $ git fetch ${remote} HEAD:{localref}
    
    didn't. Now both are equivalent.
    
    Signed-off-by: Santi Béjar <sbejar@gmail.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Jan 29, 2007
  1. @tomprince

    [PATCH] Rename git-repo-config to git-config.

    tomprince committed with Junio C Hamano Jan 28, 2007
    Signed-off-by: Tom Prince <tom.prince@ualberta.net>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Jan 26, 2007
  1. parse-remote: do not barf on a remote shorthand without any refs to f…

    Junio C Hamano committed Jan 25, 2007
    …etch.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Jan 25, 2007
  1. make --upload-pack option to git-fetch configurable

    Uwe Kleine-König committed with Junio C Hamano Jan 25, 2007
    This introduces the config item remote.<name>.uploadpack to override the
    default value (which is "git-upload-pack").
    
    Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Jan 15, 2007
  1. Fix git-fetch while on detached HEAD not to give needlessly alarming …

    Junio C Hamano committed Jan 15, 2007
    …errors
    
    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: Junio C Hamano <junkio@cox.net>
Commits on Jan 1, 2007
  1. Do not merge random set of refs out of wildcarded refs

    Junio C Hamano committed Dec 31, 2006
    When your fetch configuration has only the wildcards, we would
    pick the lexicographically first ref from the remote side for
    merging, which was complete nonsense.  Make sure nothing except
    the one that is specified with branch.*.merge is merged in this
    case.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Dec 24, 2006
  1. Allow branch.*.merge to talk about remote tracking branches.

    Junio C Hamano committed Dec 24, 2006
    People often get confused if the value of branch.*.merge should
    be the remote branch name they are fetching from, or the
    tracking branch they locally have.  So this allows either.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Dec 22, 2006
  1. Do not support "partial URL shorthand" anymore.

    Junio C Hamano committed Dec 22, 2006
    We used to support specifying the top part of remote URL in
    remotes and use that as a short-hand for the URL.
    
    	$ cat .git/remotes/jgarzik
    	URL: git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/
    	$ git pull jgarzik/misc-2.6
    
    This is confusing when somebody attempts to do this:
    
    	$ git pull origin/foo
    
    which is not syntactically correct (unless you have origin/foo.git
    repository) and should fail, but it resulted in a mysterious
    access to the 'foo' subdirectory of the origin repository.
    
    Which was what it was designed to do, but because this is an
    oddball "feature" I suspect nobody uses, let's remove it.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. default pull: forget about "newbie protection" for now.

    Junio C Hamano committed Dec 22, 2006
    This will not be backward compatible no matter how you cut it.
    Shelve it for now until somebody comes up with a better way to
    determine when we can safely refuse to use the first set of
    branchse for merging without upsetting valid workflows.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  3. parse-remote: mark all refs not for merge only when fetching more tha…

    Junio C Hamano committed Dec 21, 2006
    …n one
    
    An earlier commit a71fb0a implemented much requested safety
    valve to refuse "git pull" or "git pull origin" without explicit
    refspecs from using the first set of remote refs obtained by
    reading .git/remotes/origin file or branch.*.fetch configuration
    variables to create a merge.  The argument was that while on a
    branch different from the default branch, it is often wrong to
    merge the default remote ref suitable for merging into the master.
    
    That is fine as a theory.  But many repositories already in use
    by people in the real world do not have any of the per branch
    configuration crap.  They did not need it, and they do not need
    it now.  Merging with the first remote ref listed was just fine,
    because they had only one ref (e.g. 'master' from linux-2.6.git)
    anyway.
    
    So this changes the safety valve to be a lot looser.  When "git
    fetch" gets only one remote branch, the irritating warning would
    not trigger anymore.
    
    I think we could also make the warning trigger when branch.*.merge
    is not specified for the current branch, but is for some other
    branch.  That is for another commit.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  4. Revert "git-pull: refuse default merge without branch.*.merge"

    Junio C Hamano committed Dec 21, 2006
    This reverts commit a71fb0a.
    
    The logic to decide when to refuse to use the default "first set of
    refs fetched" for merge was utterly bogus.
    
    In a repository that happily worked correctly without any of the
    per-branch configuration crap did not have (and did not have to
    have) any branch.<current>.merge.  With that broken commit, pulling
    from origin no longer would work.
Commits on Dec 19, 2006
  1. @weidendo

    Move "no merge candidate" warning into git-pull

    weidendo committed with Junio C Hamano Dec 19, 2006
    The warning triggered even when running "git fetch" only
    when resulting .git/FETCH_HEAD only contained
    branches marked as 'not-for-merge'.
    
    Signed-off-by: Josef Weidendorfer <weidendo@gmx.de>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. Merge branch 'jc/test-clone' into jc/clone

    Junio C Hamano committed Dec 19, 2006
    * jc/test-clone: (35 commits)
      Introduce GIT_TEMPLATE_DIR
      Revert "fix testsuite: make sure they use templates freshly built from the source"
      fix testsuite: make sure they use templates freshly built from the source
      rerere: fix breakage of resolving.
      Add config example with respect to branch
      Add documentation for show-branch --topics
      make git a bit less cryptic on fetch errors
      make patch_delta() error cases a bit more verbose
      racy-git: documentation updates.
      show-ref: fix --exclude-existing
      parse-remote::expand_refs_wildcard()
      vim syntax: follow recent changes to commit template
      show-ref: fix --verify --hash=length
      show-ref: fix --quiet --verify
      avoid accessing _all_ loose refs in git-show-ref --verify
      git-fetch: Avoid reading packed refs over and over again
      Teach show-branch how to show ref-log data.
      markup fix in svnimport documentation.
      Documentation: new option -P for git-svnimport
      Fix mis-mark-up in git-merge-file.txt documentation
      ...
Commits on Dec 18, 2006
  1. parse-remote::expand_refs_wildcard()

    Junio C Hamano committed Dec 18, 2006
    Work around dash incompatibility by not using "${name%'^{}'}".
    
    Noticed by Jeff King; dash seems to mistake the closing brace
    inside the single quote as the terminating brace for parameter
    expansion.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Dec 16, 2006
  1. git-pull: refuse default merge without branch.*.merge

    Junio C Hamano committed Dec 16, 2006
    Everybody hated the pull behaviour of merging the first branch
    listed on remotes/* file (or remote.*.fetch config) into the
    current branch.  This finally corrects that UI wart by
    forbidding "git pull" without an explicit branch name on the
    command line or branch.$current.merge for the current branch.
    
    The matching change to git-clone was made to prepare the default
    branch.*.merge entry for the primary branch some time ago.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Dec 9, 2006
  1. @weidendo

    Add branch.*.merge warning and documentation update

    weidendo committed with Junio C Hamano Dec 9, 2006
    This patch clarifies the meaning of the branch.*.merge option.
    Previously, if branch.*.merge was specified but did not match any
    ref, the message "No changes." was not really helpful regarding
    the misconfiguration. This patch adds a warning for this.
    
    Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Dec 4, 2006
  1. git-fetch: ignore dereferenced tags in expand_refs_wildcard

    Michael Loeffler committed with Junio C Hamano Dec 4, 2006
    There was a little bug in the brace expansion which should remove
    the ^{} from the tagname. It used ${name#'^{}'} instead of $(name%'^{}'},
    the difference is that '#' will remove the given pattern only from the
    beginning of a string and '%' only from the end of a string.
    
    Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Nov 25, 2006
  1. git-fetch: allow forcing glob pattern in refspec

    Junio C Hamano committed Nov 25, 2006
    Building on top of the earlier refspec glob pattern enhancement,
    this allows a glob pattern to say the updates should be forced
    by prefixing it with '+' as usual, like this:
    
    	Pull: +refs/heads/*:refs/remotes/origin/*
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Nov 24, 2006
  1. git-fetch: allow glob pattern in refspec

    Junio C Hamano committed Nov 22, 2006
    This adds Andy's refspec glob.  You can have a single line:
    
    	Pull: refs/heads/*:refs/remotes/origin/*
    
    in your ".git/remotes/origin" and say "git fetch" to retrieve
    all refs under heads/ at the remote side to remotes/origin/ in
    the local repository.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Sep 24, 2006
  1. fetch: get the remote branches to merge from the branch properties

    Santi Béjar committed with Junio C Hamano Sep 23, 2006
    If in branch "foo" and this in config:
    
    [branch "foo"]
          merge=bar
    
    "git fetch": fetch from the default repository and program the "bar"
                 branch to be merged with pull.
    
    Signed-off-by: Santi Béjar <sbejar@gmail.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. Fetch: default remote repository from branch properties

    Santi Béjar committed with Junio C Hamano Sep 23, 2006
    If in branch "foo" and this in config:
    
    [branch "foo"]
           remote=bar
    
    "git fetch" = "git fetch bar"
    "git  pull" = "git pull  bar"
    
    Signed-off-by: Santi Béjar <sbejar@gmail.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on May 4, 2006
  1. @dscho

    fetch, pull: ask config for remote information

    dscho committed with Junio C Hamano May 3, 2006
    Now you can say
    
        [remote.junio]
            url = git://git.kernel.org/pub/scm/git/git.git
            fetch = next:next
    
        in your .git/config.
    
    [jc: fixed up the log message that still said "pull" ]
    
    Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Apr 14, 2006
  1. Fix-up previous expr changes.

    Junio C Hamano committed Apr 13, 2006
    The regexp on the right hand side of expr : operator somehow was
    broken.
    
    	expr 'z+pu:refs/tags/ko-pu' : 'z\+\(.*\)'
    
    does not strip '+'; write 'z+\(.*\)' instead.
    
    We probably should switch to shell based substring post 1.3.0;
    that's not bashism but just POSIX anyway.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Apr 13, 2006
  1. @distorted-mdw

    Shell utilities: Guard against expr' magic tokens.

    distorted-mdw committed with Junio C Hamano Apr 13, 2006
    Some words, e.g., `match', are special to expr(1), and cause strange
    parsing effects.  Track down all uses of expr and mangle the arguments
    so that this isn't a problem.
    
    Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Something went wrong with that request. Please try again.