1. 19 Apr, 2016 1 commit
  2. 26 Nov, 2013 1 commit
    • Jonathan Nieder's avatar
      remove #!interpreter line from shell libraries · 11d62145
      Jonathan Nieder authored
      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: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      11d62145
  3. 08 Nov, 2012 1 commit
  4. 05 Mar, 2012 1 commit
    • Carlos Martín Nieto's avatar
      Make git-{pull,rebase} message without tracking information friendlier · 3c02396a
      Carlos Martín Nieto authored
      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: default avatarCarlos Martín Nieto <cmn@elego.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3c02396a
  5. 31 Mar, 2011 1 commit
  6. 30 Mar, 2011 1 commit
  7. 02 Mar, 2011 2 commits
  8. 10 Feb, 2011 1 commit
    • Martin von Zweigbergk's avatar
      rebase: use @{upstream} if no upstream specified · 15a147e6
      Martin von Zweigbergk authored
      '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: default avatarYann Dirson <ydirson@altern.org>
      Helped-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarMartin von Zweigbergk <martin.von.zweigbergk@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      15a147e6
  9. 07 Dec, 2010 1 commit
  10. 29 Nov, 2010 1 commit
  11. 31 Jan, 2010 1 commit
  12. 12 Jun, 2009 3 commits
  13. 23 Apr, 2009 1 commit
  14. 03 Jul, 2007 1 commit
  15. 12 May, 2007 1 commit
    • Alex Riesen's avatar
      Allow fetching references from any namespace · 96f12b54
      Alex Riesen authored
      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: default avatarAlex Riesen <raa.lkml@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      96f12b54
  16. 16 Mar, 2007 1 commit
    • Paolo Bonzini's avatar
      git-fetch, git-branch: Support local --track via a special remote '.' · 9debc324
      Paolo Bonzini authored
      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's avatarPaolo Bonzini  <bonzini@gnu.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      9debc324
  17. 14 Feb, 2007 2 commits
  18. 05 Feb, 2007 1 commit
    • Junio C Hamano's avatar
      Revert "Allow branch.*.merge to talk about remote tracking branches." · 756373da
      Junio C Hamano authored
      This reverts commit 80c79776.
      
      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: default avatarJunio C Hamano <junkio@cox.net>
      756373da
  19. 30 Jan, 2007 1 commit
  20. 29 Jan, 2007 1 commit
  21. 26 Jan, 2007 1 commit
  22. 25 Jan, 2007 1 commit
  23. 15 Jan, 2007 1 commit
    • 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 <junkio@cox.net>
      a0f4280f
  24. 01 Jan, 2007 1 commit
  25. 24 Dec, 2006 1 commit
  26. 22 Dec, 2006 4 commits
    • Junio C Hamano's avatar
      Do not support "partial URL shorthand" anymore. · ea560e6d
      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: default avatarJunio C Hamano <junkio@cox.net>
      ea560e6d
    • Junio C Hamano's avatar
      default pull: forget about "newbie protection" for now. · fb8696d9
      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: default avatarJunio C Hamano <junkio@cox.net>
      fb8696d9
    • Junio C Hamano's avatar
      parse-remote: mark all refs not for merge only when fetching more than one · d41cb273
      Junio C Hamano authored
      An earlier commit a71fb0a1 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: default avatarJunio C Hamano <junkio@cox.net>
      d41cb273
    • Junio C Hamano's avatar
      Revert "git-pull: refuse default merge without branch.*.merge" · 9e115549
      Junio C Hamano authored
      This reverts commit a71fb0a1.
      
      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.
      9e115549
  27. 19 Dec, 2006 1 commit
  28. 18 Dec, 2006 1 commit
  29. 16 Dec, 2006 1 commit
    • Junio C Hamano's avatar
      git-pull: refuse default merge without branch.*.merge · a71fb0a1
      Junio C Hamano authored
      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: default avatarJunio C Hamano <junkio@cox.net>
      a71fb0a1
  30. 09 Dec, 2006 1 commit
  31. 04 Dec, 2006 1 commit
  32. 25 Nov, 2006 1 commit
  33. 24 Nov, 2006 1 commit