This project is mirrored from https://github.com/git/git. Updated .
  1. 19 Apr, 2014 1 commit
    • Johan Herland's avatar
      Git 2.0: git svn: Set default --prefix='origin/' if --prefix is not given · fe191fca
      Johan Herland authored
      git-svn by default puts its Subversion-tracking refs directly in
      refs/remotes/*. This runs counter to Git's convention of using
      refs/remotes/$remote/* for storing remote-tracking branches.
      
      Furthermore, combining git-svn with regular git remotes run the risk of
      clobbering refs under refs/remotes (e.g. if you have a git remote
      called "tags" with a "v1" branch, it will overlap with the git-svn's
      tracking branch for the "v1" tag from Subversion.
      
      Even though the git-svn refs stored in refs/remotes/* are not "proper"
      remote-tracking branches (since they are not covered by a proper git
      remote's refspec), they clearly represent a similar concept, and would
      benefit from following the same convention.
      
      For example, if git-svn tracks Subversion branch "foo" at
      refs/remotes/foo, and you create a local branch refs/heads/foo to add
      some commits to be pushed back to Subversion (using "git svn dcommit),
      then it is clearly unhelpful of Git to throw
      
        warning: refname 'foo' is ambiguous.
      
      every time you checkout, rebase, or otherwise interact with the branch.
      
      The existing workaround for this is to supply the --prefix=quux/ to
      git svn init/clone, so that git-svn's tracking branches end up in
      refs/remotes/quux/* instead of refs/remotes/*. However, encouraging
      users to specify --prefix to work around a design flaw in git-svn is
      suboptimal, and not a long term solution to the problem. Instead,
      git-svn should default to use a non-empty prefix that saves
      unsuspecting users from the inconveniences described above.
      
      This patch will only affect newly created git-svn setups, as the
      --prefix option only applies to git svn init (and git svn clone).
      Existing git-svn setups will continue with their existing (lack of)
      prefix. Also, if anyone somehow prefers git-svn's old layout, they
      can recreate that by explicitly passing an empty prefix (--prefix "")
      on the git svn init/clone command line.
      
      The patch changes the default value for --prefix from "" to "origin/",
      updates the git-svn manual page, and fixes the fallout in the git-svn
      testcases.
      
      (Note that this patch might be easier to review using the --word-diff
      and --word-diff-regex=. diff options.)
      
      [ew: squashed description of <= 1.9 behavior into manpage]
      Suggested-by: Thomas Ferris Nicolaisen's avatarThomas Ferris Nicolaisen <tfnico@gmail.com>
      Signed-off-by: default avatarJohan Herland <johan@herland.net>
      Signed-off-by: default avatarEric Wong <normalperson@yhbt.net>
      fe191fca
  2. 12 Oct, 2013 1 commit
  3. 10 Oct, 2013 1 commit
  4. 19 Jun, 2013 1 commit
  5. 12 Jun, 2013 1 commit
  6. 20 May, 2013 1 commit
  7. 09 May, 2013 2 commits
  8. 25 Feb, 2013 1 commit
  9. 24 Feb, 2013 1 commit
  10. 24 Jan, 2013 1 commit
  11. 17 Jan, 2013 1 commit
    • John Keeping's avatar
      git-svn: teach find-rev to find near matches · 2934a484
      John Keeping authored
      When a single SVN repository is split into multiple Git repositories
      many SVN revisions will exist in only one of the Git repositories
      created.  For some projects the only way to build a working artifact is
      to check out corresponding versions of various repositories, with no
      indication of what those are in the Git world - in the SVN world the
      revision numbers are sufficient.
      
      By adding "--before" to "git-svn find-rev" we can say "tell me what this
      repository looked like when that other repository looked like this":
      
          git svn find-rev --before \
              r$(git --git-dir=/over/there.git svn find-rev HEAD)
      Signed-off-by: John Keeping's avatarJohn Keeping <john@keeping.me.uk>
      Signed-off-by: default avatarEric Wong <normalperson@yhbt.net>
      2934a484
  12. 05 Oct, 2012 1 commit
  13. 10 Aug, 2012 1 commit
    • Robert Luberda's avatar
      git svn: handle errors and concurrent commits in dcommit · e48fb750
      Robert Luberda authored
      dcommit didn't handle errors returned by SVN and coped very
      poorly with concurrent commits that appear in SVN repository
      while dcommit was running. In both cases it left git repository
      in inconsistent state: index (which was reset with `git reset
      --mixed' after a successful commit to SVN) no longer matched the
      checkouted tree, when the following commit failed or needed to be
      rebased. See http://bugs.debian.org/676904 for examples.
      
      This patch fixes the issues by:
      - introducing error handler for dcommit. The handler will try
        to rebase or reset working tree before returning error to the
        end user. dcommit_rebase function was extracted out of cmd_dcommit
        to ensure consistency between cmd_dcommit and the error handler.
      - calling `git reset --mixed' only once after all patches are
        successfully committed to SVN. This ensures index is not touched
        for most of the time of dcommit run.
      Signed-off-by: default avatarEric Wong <normalperson@yhbt.net>
      e48fb750
  14. 02 Aug, 2012 8 commits
  15. 27 Jul, 2012 11 commits
  16. 19 Jul, 2012 1 commit
    • Marcin Owsiany's avatar
      git-svn: don't create master if another head exists · e3bd4dda
      Marcin Owsiany authored
      git-svn insists on creating the "master" head (unless it exists) on every
      "fetch". It is useful that it gets created initially, when no head exists
      - users expect this git convention of having a "master" branch on initial
      clone.
      
      However creating it when there already is another head does not provide any
      value - the ref is never updated, so it just gets stale after a while.  Also,
      some users find it annoying that it gets recreated, especially when they would
      like the git branch names to follow SVN repository branch names. More
      background in http://thread.gmane.org/gmane.comp.version-control.git/115030
      
      Make git-svn skip the "master" creation if HEAD already points at a valid head.
      This means "master" does get created on initial "clone" but does not get
      recreated once a user deletes it.
      
      Also, make post_fetch_checkout work with any head that is pointed to by HEAD,
      not just "master".
      
      Also, use fatal error handling consistent with the rest of the program for
      post_fetch_checkout.
      Signed-off-by: default avatarMarcin Owsiany <marcin@owsiany.pl>
      Signed-off-by: default avatarEric Wong <normalperson@yhbt.net>
      e3bd4dda
  17. 10 Jun, 2012 3 commits
    • Jonathan Nieder's avatar
      git-svn: use YAML format for mergeinfo cache when possible · 68f532f4
      Jonathan Nieder authored
      Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30),
      git-svn has maintained some private per-repository caches in
      .git/svn/.caches to avoid refetching and recalculating some
      mergeinfo-related information with every "git svn fetch".
      
      These caches use the 'nstore' format from the perl core module
      Storable, which can be read and written quickly and was designed for
      transfer over the wire (the 'n' stands for 'network').  This format is
      endianness-independent and independent of floating-point
      representation.
      
      Unfortunately the format is *not* independent of the perl version ---
      new perl versions will write files that very old perl cannot read.
      Worse, the format is not independent of the size of a perl integer.
      So if you toggle perl's use64bitint compile-time option, then using
      'git svn fetch' on your old repositories produces errors like this:
      
      	Byte order is not compatible at ../../lib/Storable.pm (autosplit
      	into ../../lib/auto/Storable/_retrieve.al) line 380, at
      	/usr/share/perl/5.12/Memoize/Storable.pm line 21
      
      That is, upgrading perl to a version that uses use64bitint for the
      first time makes git-svn suddenly refuse to fetch in existing
      repositories.  Removing .git/svn/.caches lets git-svn recover.
      
      It's time to switch to a platform independent serializer backend with
      better compatibility guarantees.  This patch uses YAML::Any.
      
      Other choices were considered:
      
       - thawing data from Data::Dumper involves "eval".  Doing that without
         creating a security risk is fussy.
      
       - the JSON API works on scalars in memory and doesn't provide a
         standard way to serialize straight to disk.
      
      YAML::Any is reasonably fast and has a pleasant API.  In most
      backends, LoadFile() reads the entire file into a scalar anyway and
      converts it as a second step, but having an interface that allows the
      deserialization to happen on the fly without a temporary is still a
      comfort.
      
      YAML::Any is not a core perl module, so we take care to use it when
      and only when it is available.  Installations without that module
      should fall back to using Storable with all its quirks, keeping their
      cache files in
      
      	.git/svn/.caches/*.db
      
      Installations with YAML peacefully coexist by keeping a separate set
      of cache files in
      
      	.git/svn/.caches/*.yaml.
      
      In most cases, switching between is a one-time thing, so it doesn't
      seem worth the complication to migrate existing caches.
      
      The upshot: after this patch, as long as YAML::Any is installed you
      can move your git repository between machines with different perl
      installations and "git svn fetch" will work fine.  If you do not have
      YAML::Any, the behavior is unchanged (and in particular does not get
      any worse).
      Reported-by: default avatarSandro Weiser <sandro.weiser@informatik.tu-chemnitz.de>
      Reported-by: default avatarBdale Garbee <bdale@gag.com>
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarEric Wong <normalperson@yhbt.net>
      68f532f4
    • Jonathan Nieder's avatar
      git-svn: make Git::SVN::RA a separate file · 9f7ad147
      Jonathan Nieder authored
      This slices off another 600 or so lines from the frighteningly long
      git-svn.perl script.
      
      The Git::SVN::Ra interface is similar enough to SVN::Ra that it is
      probably safe to ignore most of its implementation on first reading.
      (Documenting or moving functions that do not fit that pattern is left
      as an exercise to the interested reader.)
      
      [ew: rebased and fixed conflict against
       commit c26ddce8
       (git-svn: platform auth providers are working only on 1.6.15 or newer)]
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarEric Wong <normalperson@yhbt.net>
      9f7ad147
    • Jonathan Nieder's avatar
      git-svn: make Git::SVN::Editor a separate file · 8f9facfe
      Jonathan Nieder authored
      This makes the git-svn script shorter and less scary for beginners to
      read through for the first time.  Take the opportunity to explain the
      purpose and basic interface of the Git::SVN::Editor class while at it.
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarEric Wong <normalperson@yhbt.net>
      8f9facfe
  18. 04 Jun, 2012 1 commit
  19. 29 May, 2012 2 commits