Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Nov 26, 2013
  1. @jrn @gitster

    remove #!interpreter line from shell libraries

    jrn authored gitster committed
    In a shell snippet meant to be sourced by other shell scripts, an
    opening #! line does more harm than good.
    
    The harm:
    
     - When the shell library is sourced, the interpreter and options from
       the #! line are not used.  Specifying a particular shell can
       confuse the reader into thinking it is safe for the shell library
       to rely on idiosyncrasies of that shell.
    
     - Using #! instead of a plain comment drops a helpful visual clue
       that this is a shell library and not a self-contained script.
    
     - Tools such as lintian can use a #! line to tell when an
       installation script has failed by forgetting to set a script
       executable.  This check does not work if shell libraries also start
       with a #! line.
    
    The good:
    
     - Text editors notice the #! line and use it for syntax highlighting
       if you try to edit the installed scripts (without ".sh" suffix) in
       place.
    
    The use of the #! for file type detection is not needed because Git's
    shell libraries are meant to be edited in source form (with ".sh"
    suffix).  Replace the opening #! lines with comments.
    
    This involves tweaking the test harness's valgrind support to find
    shell libraries by looking for "# " in the first line instead of "#!"
    (see v1.7.6-rc3~7, 2011-06-17).
    
    Suggested by Russ Allbery through lintian.  Thanks to Jeff King and
    Clemens Buchacher for further analysis.
    
    Tested by searching for non-executable scripts with #! line:
    
    	find . -name .git -prune -o -type f -not -executable |
    	while read file
    	do
    		read line <"$file"
    		case $line in
    		'#!'*)
    			echo "$file"
    			;;
    		esac
    	done
    
    The only remaining scripts found are templates for shell scripts
    (unimplemented.sh, wrap-for-bin.sh) and sample input used in tests
    (t/t4034/perl/{pre,post}).
    
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Nov 8, 2012
  1. @mjg @peff

    push/pull: adjust missing upstream help text to changed interface

    mjg authored peff committed
    In case of a missing upstream, the git-parse-remote script suggests:
    
    If you wish to set tracking information for this branch you can do so
    with:
    
        git branch --set-upstream nsiv2 origin/<branch>
    
    But --set-upstream is deprectated. Change the suggestion to:
    
        git branch --set-upstream-to=origin/<branch> nsiv2
    
    Reported-by: Jeroen van der Ham <vdham@uva.nl>
    Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
    Signed-off-by: Jeff King <peff@peff.net>
Commits on Mar 5, 2012
  1. @carlosmn @gitster

    Make git-{pull,rebase} message without tracking information friendlier

    carlosmn authored gitster committed
    The current message is too long and at too low a level for anybody
    to understand it if they don't know about the configuration format
    already.
    
    The text about setting up a remote is superfluous and doesn't help
    understand or recover from the error that has happened.  Show the
    usage more prominently and explain how to set up the tracking
    information. If there is only one remote, that name is used instead
    of the generic <remote>.
    
    Also simplify the message we print on detached HEAD to remove
    unnecessary information which is better left for the documentation.
    
    Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Apr 28, 2011
  1. @gitster

    Merge branch 'mz/rebase'

    gitster authored
    * mz/rebase: (34 commits)
      rebase: define options in OPTIONS_SPEC
      Makefile: do not install sourced rebase scripts
      rebase: use @{upstream} if no upstream specified
      rebase -i: remove unnecessary state rebase-root
      rebase -i: don't read unused variable preserve_merges
      git-rebase--am: remove unnecessary --3way option
      rebase -m: don't print exit code 2 when merge fails
      rebase -m: remember allow_rerere_autoupdate option
      rebase: remember strategy and strategy options
      rebase: remember verbose option
      rebase: extract code for writing basic state
      rebase: factor out sub command handling
      rebase: make -v a tiny bit more verbose
      rebase -i: align variable names
      rebase: show consistent conflict resolution hint
      rebase: extract am code to new source file
      rebase: extract merge code to new source file
      rebase: remove $branch as synonym for $orig_head
      rebase -i: support --stat
      rebase: factor out call to pre-rebase hook
      ...
Commits on Mar 31, 2011
  1. @gitster

    Merge branch 'maint'

    gitster authored
    * maint:
      parse-remote: typofix
  2. @gitster

    parse-remote: typofix

    gitster authored
    An earlier patch had a trivial typo that two people did not notice.
    Pointed out by Michael Schubert.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Mar 30, 2011
  1. @gitster

    Merge branch 'maint'

    gitster authored
    * maint:
      contrib/thunderbird-patch-inline: do not require bash to run the script
      t8001: check the exit status of the command being tested
      strbuf.h: remove a tad stale docs-in-comment and reference api-doc instead
      Typos: t/README
      Documentation/config.txt: make truth value of numbers more explicit
      git-pack-objects.txt: fix grammatical errors
      parse-remote: replace unnecessary sed invocation
  2. @bebarino @gitster

    parse-remote: replace unnecessary sed invocation

    bebarino authored gitster committed
    Just use parameter expansion instead.
    
    Signed-off-by: Stephen Boyd <bebarino@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Mar 2, 2011
  1. @gitster

    git-request-pull: open-code the only invocation of get_remote_url

    Uwe Kleine-König authored gitster committed
    So sh:get_remote_url can go now and git-request-pull
    doesn't need to source git-parse-remote. anymore.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @gitster

    get_remote_url(): use the same data source as ls-remote to get remote…

    Uwe Kleine-König authored gitster committed
    … urls
    
    The formerly implemented algorithm behaved differently to
    remote.c:remote_get() at least for remotes that contain a slash.  While the
    former just assumes a/b is a path the latter checks the config for
    remote."a/b" first which is more reasonable.
    
    This removes the last user of git-parse-remote.sh:get_data_source(), so
    this function is removed.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Feb 10, 2011
  1. @gitster

    rebase: use @{upstream} if no upstream specified

    Martin von Zweigbergk authored gitster committed
    'git rebase' without arguments is currently not supported. Make it
    default to 'git rebase @{upstream}'. That is also what 'git pull
    [--rebase]' defaults to, so it only makes sense that 'git rebase'
    defaults to the same thing.
    
    Defaulting to @{upstream} will make it possible to run e.g. 'git
    rebase -i' without arguments, which is probably a quite common use
    case. It also improves the scenario where you have multiple branches
    that rebase against a remote-tracking branch, where you currently have
    to choose between the extra network delay of 'git pull' or the
    slightly awkward keys to enter 'git rebase @{u}'.
    
    The error reporting when no upstream is configured for the current
    branch or when no branch is checked out is reused from git-pull.sh. A
    function is extracted into git-parse-remote.sh for this purpose.
    
    Helped-by: Yann Dirson <ydirson@altern.org>
    Helped-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Dec 13, 2010
  1. @gitster

    Merge branch 'mz/pull-rebase-rebased'

    gitster authored
    * mz/pull-rebase-rebased:
      Use reflog in 'pull --rebase . foo'
Commits on Dec 7, 2010
  1. @gitster

    parse-remote: handle detached HEAD

    Santi Béjar authored gitster committed
    get_remote_merge_branch with zero or one arguments returns the
    upstream branch. But a detached HEAD does no have an upstream branch,
    as it is not tracking anything. Handle this case testing the exit code
    of "git symbolic-ref -q HEAD".
    
    Reported-by: Sverre Rabbelier <srabbelier@gmail.com>
    Signed-off-by: Santi Béjar <santi@agolina.net>
    Tested-by: Sverre Rabbelier <srabbelier@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Nov 29, 2010
  1. @gitster

    Use reflog in 'pull --rebase . foo'

    Martin von Zweigbergk authored gitster committed
    Since c85c792 (pull --rebase: be cleverer with rebased upstream
    branches, 2008-01-26), "git pull --rebase" has used the reflog to try to
    rebase from the old upstream onto the new upstream.
    
    Make this work if the local repository is explicitly passed on the
    command line as in 'git pull --rebase . foo'.
    
    Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
    Acked-by: Santi Béjar <santi@agolina.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jan 31, 2010
  1. @jrn @gitster

    Do not install shell libraries executable

    jrn authored gitster committed
    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 authored gitster committed
    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 authored gitster committed
    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 authored gitster committed
    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 authored gitster committed
    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 authored
    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 authored Junio C Hamano committed
    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 authored Junio C Hamano committed
    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 authored Junio C Hamano committed
    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 authored
    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 authored
    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 authored Junio C Hamano committed
    ... 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 authored Junio C Hamano committed
    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 authored
    …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 authored Junio C Hamano committed
    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 authored
    …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 authored
    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 authored
    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 authored
    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 authored
    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 authored
    …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>
Something went wrong with that request. Please try again.