1. 23 Feb, 2018 1 commit
    • Bernhard M. Wiedemann's avatar
      perl: call timegm and timelocal with 4-digit year · a40e06ee
      Bernhard M. Wiedemann authored
      Amazingly, timegm(gmtime(0)) is only 0 before 2020 because perl's
      timegm deviates from GNU timegm(3) in how it handles years.
      
      man Time::Local says
      
       Whenever possible, use an absolute four digit year instead.
      
      with a detailed explanation about ambiguity of 2-digit years above that.
      
      Even though this ambiguity is error-prone with >50% of users getting it
      wrong, it has been like this for 20+ years, so we just use 4-digit years
      everywhere to be on the safe side.
      
      We add some extra logic to cvsimport because it allows 2-digit year
      input and interpreting an 18 as 1918 can be avoided easily and safely.
      Signed-off-by: Bernhard M. Wiedemann's avatarBernhard M. Wiedemann <bwiedemann@suse.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a40e06ee
  2. 08 Dec, 2017 1 commit
  3. 12 Sep, 2017 1 commit
  4. 25 Jun, 2015 1 commit
  5. 29 Apr, 2015 1 commit
    • Junio C Hamano's avatar
      merge: deprecate 'git merge <message> HEAD <commit>' syntax · d45366e8
      Junio C Hamano authored
      We had this in "git merge" manual for eternity:
      
          'git merge' <msg> HEAD <commit>...
      
          [This] syntax (<msg> `HEAD` <commit>...) is supported for
          historical reasons.  Do not use it from the command line or in
          new scripts.  It is the same as `git merge -m <msg> <commit>...`.
      
      With the update to "git merge" to make it understand what is
      recorded in FETCH_HEAD directly, including Octopus merge cases, we
      now can rewrite the use of this syntax in "git pull" with a simple
      "git merge FETCH_HEAD".
      
      Also there are quite a few fallouts in the test scripts, and it
      turns out that "git cvsimport" also uses this old syntax to record
      a merge.
      
      Judging from this result, I would not be surprised if dropping the
      support of the old syntax broke scripts people have written and been
      relying on for the past ten years.  But at least we can start the
      deprecation process by throwing a warning message when the syntax is
      used.
      
      With luck, we might be able to drop the support in a few years.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d45366e8
  6. 24 Feb, 2013 1 commit
  7. 09 Feb, 2013 1 commit
  8. 04 Nov, 2012 1 commit
    • Jeff King's avatar
      cvsimport: work around perl tzset issue · c2b3af05
      Jeff King authored
      On many platforms, the first invocation of localtime_r will
      check $TZ in the environment, but subsequent invocations
      will use a cached value. That means that setting $ENV{TZ} in
      the middle of the program may or may not have an effect on
      later calls to localtime.  Perl 5.10.0 and later handles
      this automatically for us, but we try to remain portable
      back to 5.8. Work around it by calling tzset ourselves.
      c2b3af05
  9. 17 Oct, 2012 1 commit
  10. 06 Sep, 2012 1 commit
    • Ken Dreyer's avatar
      cvsimport: strip all inappropriate tag strings · 70b67b07
      Ken Dreyer authored
      Certain characters such as "?" can be present in a CVS tag name, but
      git does not allow these characters in tags. If git-cvsimport
      encounters a CVS tag that git cannot handle, cvsimport will error and
      refuse to continue the import beyond that point.
      
      When importing CVS tags, strip all the inappropriate strings from the
      tag names as we translate them to git tag names.
      
      Provide more debugging information to the user if we've altered the
      tag and the "git tag" command still fails. Also, warn the user if we
      end up skipping an (unusable) tag altogether.
      Signed-off-by: default avatarKen Dreyer <ktdreyer@ktdreyer.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      70b67b07
  11. 01 May, 2011 1 commit
    • Guy Rouillier's avatar
      Look for password in both CVS and CVSNT password files. · 58fdef0c
      Guy Rouillier authored
      In conn, if password is not passed on command line, look for a password
      entry in both the CVS password file and the CVSNT password file.  If only
      one file is found and the requested repository is in that file, or if both
      files are found but the requested repository is found in only one file, use
      the password from the single file containing the repository entry.  If both
      files are found and the requested repository is found in both files, then
      produce an error message.
      
      The CVS password file separates tokens with a space character, while
      the CVSNT password file separates tokens with an equal (=) character.
      Add a sub find_password_entry that accepts the password file name
      and a delimiter to eliminate code duplication.
      Signed-off-by: default avatarGuy Rouillier <guyr@burntmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      58fdef0c
  12. 27 Feb, 2011 1 commit
    • Fabian Keil's avatar
      git-cvsimport.perl: Bail out right away when reading from the server fails · e7cad3cc
      Fabian Keil authored
      If the CVS server is down, this reduced the git-cvsimport output from:
      
      ssh: connect to host ijbswa.cvs.sourceforge.net port 22: Connection refused
      Use of uninitialized value $rep in scalar chomp at /usr/local/libexec/git-core/git-cvsimport line 369.
      Use of uninitialized value $rep in substitution (s///) at /usr/local/libexec/git-core/git-cvsimport line 370.
      Expected Valid-requests from server, but got: <unknown>
      
      to the less noisy:
      
      ssh: connect to host ijbswa.cvs.sourceforge.net port 22: Connection refused
      Failed to read from server at /usr/local/libexec/git-core/git-cvsimport line 370.
      
      In this case a silent exit() instead of the die() would probably do,
      but I assume that there could be cases where the connection attempt
      succeeds, but reading from the server fails for other reasons.
      Signed-off-by: default avatarFabian Keil <fk@fabiankeil.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      e7cad3cc
  13. 04 Jan, 2011 1 commit
    • Michael J Gruber's avatar
      cvsimport: handle the parsing of uppercase config options · 60d5985d
      Michael J Gruber authored
      The current code leads to
      
        fatal: bad config value for 'cvsimport.r' in .git/config
      
      for a standard use case with cvsimport.r set.
      
      cvsimport sets internal variables by checking the config for each
      possible command line option. The problem is that config items are case
      insensitive, so config.r and config.R are the same. The ugly error is
      due to that fact that cvsimport expects a bool for -R (and thus
      config.R) but a remote name for -r (and thus config.r).
      
      Fix this by making cvsimport expect long names for uppercase options.
      
      config options for cvsimport have been undocumented so far, though
      present in the code and advertised in several tutorials. So one may read
      "enhance" for "fix". Similarly, the names for the options are
      "documented" in the code, waitiing for their lowercase equivalents to be
      transformed into long config options, as well.
      Helped-by: default avatarJunio C Hamano <gitster@pobox.com>
      Signed-off-by: default avatarMichael J Gruber <git@drmicha.warpmail.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      60d5985d
  14. 30 Nov, 2010 1 commit
  15. 19 Oct, 2010 1 commit
  16. 27 Sep, 2010 2 commits
    • Ævar Arnfjörð Bjarmason's avatar
      perl: use "use warnings" instead of -w · 3328aced
      Ævar Arnfjörð Bjarmason authored
      Change the Perl scripts to turn on lexical warnings instead of setting
      the global $^W variable via the -w switch.
      
      The -w sets warnings for all code that interpreter runs, while "use
      warnings" is lexically scoped. The former is probably not what the
      authors wanted.
      
      As an auxiliary benefit it's now possible to build Git with:
      
          PERL_PATH='/usr/bin/env perl'
      
      Which would previously result in failures, since "#!/usr/bin/env perl -w"
      doesn't work as a shebang.
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3328aced
    • Ævar Arnfjörð Bjarmason's avatar
      perl: bump the required Perl version to 5.8 from 5.6.[21] · d48b2841
      Ævar Arnfjörð Bjarmason authored
      Formalize our dependency on perl 5.8, bumped from 5.6.[12]. We already
      used the three-arg form of open() which was introduced in 5.6.1, but
      t/t9700/test.pl explicitly depended on 5.6.2.
      
      However git-add--interactive.pl has been failing on the 5.6 line since
      it was introduced in v1.5.0-rc0~12^2~2 back in 2006 due to this open
      syntax:
      
          sub run_cmd_pipe {
                 my $fh = undef;
                 open($fh, '-|', @_) or die;
                 return <$fh>;
          }
      
      Which when executed dies on "Can't use an undefined value as
      filehandle reference". Several of our tests also fail on 5.6 (even
      more when compiled with NO_PERL_MAKEMAKER=1):
      
          t2016-checkout-patch.sh
          t3904-stash-patch.sh
          t3701-add-interactive.sh
          t7105-reset-patch.sh
          t7501-commit.sh
          t9700-perl-git.sh
      
      Our code is bitrotting on 5.6 with no-one interested in fixing it, and
      pinning us to such an ancient release of Perl is keeping us from using
      useful features introduced in the 5.8 release.
      
      The 5.6 series is now over 10 years old, and the 5.6.2 maintenance
      release almost 7. 5.8 on the other hand is more than 8 years old.
      
      All the modern Unix-like operating systems have now upgraded to it or
      a later version, and 5.8 packages are available for old IRIX, AIX
      Solaris and Tru64 systems.
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Acked-by: default avatarTor Arntsen <tor@spacetec.no>
      Acked-by: default avatarRandal L. Schwartz <merlyn@stonehenge.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d48b2841
  17. 06 Feb, 2010 1 commit
  18. 19 Jan, 2010 3 commits
  19. 19 Oct, 2009 1 commit
  20. 17 Sep, 2009 1 commit
  21. 06 Sep, 2009 1 commit
  22. 15 Aug, 2009 1 commit
  23. 05 Aug, 2008 1 commit
  24. 13 Jul, 2008 1 commit
    • Stephan Beyer's avatar
      Make usage strings dash-less · 1b1dd23f
      Stephan Beyer authored
      When you misuse a git command, you are shown the usage string.
      But this is currently shown in the dashed form.  So if you just
      copy what you see, it will not work, when the dashed form
      is no longer supported.
      
      This patch makes git commands show the dash-less version.
      
      For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
      generates a dash-less usage string now.
      Signed-off-by: default avatarStephan Beyer <s-beyer@gmx.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      1b1dd23f
  25. 11 Jun, 2008 1 commit
  26. 25 May, 2008 1 commit
  27. 30 Apr, 2008 1 commit
  28. 13 Mar, 2008 1 commit
  29. 01 Mar, 2008 2 commits
  30. 13 Feb, 2008 1 commit
  31. 14 Jan, 2008 1 commit
  32. 24 Dec, 2007 1 commit
    • Jeff King's avatar
      cvsimport: die on cvsps errors · 3a969ef1
      Jeff King authored
      We were not previously checking the exit status of cvsps at
      all. If it exited before producing any useful output, we
      ended up with an empty import, which caused a spew of
      confusing error messages from other parts of git:
      
      $ git-cvsimport foo
      Initialized empty Git repository in ...
      some error from cvsps
      fatal: refs/heads/origin: not a valid SHA1
      fatal: master: not a valid SHA1
      warning: You appear to be on a branch yet to be born.
      warning: Forcing checkout of HEAD.
      fatal: just how do you expect me to merge 0 trees?
      checkout failed: 256
      
      Now we get:
      
      $ git-cvsimport foo
      Initialized empty Git repository in ...
      some error from cvsps
      git-cvsimport: fatal: cvsps reported error
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Acked-by: default avatarMartin Langhoff <martin@catalyst.net.nz>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3a969ef1
  33. 22 Dec, 2007 1 commit
  34. 30 Nov, 2007 1 commit
    • Jeff King's avatar
      cvsimport: fix usage of cvsimport.module · 67d23242
      Jeff King authored
      There were two problems:
      
        1. We only look at the config variable if there is no module
           given on the command line. We checked this by comparing
           @argv == 0. However, at the time of the comparison, we
           have not yet parsed the dashed options, meaning that
           "git cvsimport" would read the variable but "git
           cvsimport -a" would not. This is fixed by simply moving
           the check after the call to getopt.
      
        2. If the config variable did not exist, we were adding an
           empty string to @argv. The rest of the script, rather
           than barfing for insufficient input, would then try to
           import the module '', leading to rather confusing error
           messages. Based on patch from Emanuele Giaquinta.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      67d23242
  35. 28 Nov, 2007 2 commits