1. 18 Apr, 2017 1 commit
  2. 30 Mar, 2017 1 commit
    • Jeff King's avatar
      avoid using fixed PATH_MAX buffers for refs · 7f897b6f
      Jeff King authored
      Many functions which handle refs use a PATH_MAX-sized buffer
      to do so. This is mostly reasonable as we have to write
      loose refs into the filesystem, and at least on Linux the 4K
      PATH_MAX is big enough that nobody would care. But:
        1. The static PATH_MAX is not always the filesystem limit.
        2. On other platforms, PATH_MAX may be much smaller.
        3. As we move to alternate ref storage, we won't be bound
           by filesystem limits.
      Let's convert these to heap buffers so we don't have to
      worry about truncation or size limits.
      We may want to eventually constrain ref lengths for sanity
      and to prevent malicious names, but we should do so
      consistently across all platforms, and in a central place
      (like the ref code).
      Signed-off-by: default avatarJeff King <peff@peff.net>
  3. 22 Feb, 2017 1 commit
  4. 21 Feb, 2017 1 commit
    • Kyle Meyer's avatar
      delete_ref: accept a reflog message argument · 755b49ae
      Kyle Meyer authored
      When the current branch is renamed with 'git branch -m/-M' or deleted
      with 'git update-ref -m<msg> -d', the event is recorded in HEAD's log
      with an empty message.  In preparation for adding a more meaningful
      message to HEAD's log in these cases, update delete_ref() to take a
      message argument and pass it along to ref_transaction_delete().
      Modify all callers to pass NULL for the new message argument; no
      change in behavior is intended.
      Note that this is relevant for HEAD's log but not for the deleted
      ref's log, which is currently deleted along with the ref.  Even if it
      were not, an entry for the deletion wouldn't be present in the deleted
      ref's log.  files_transaction_commit() writes to the log if
      REF_NEEDS_COMMIT or REF_LOG_ONLY are set, but lock_ref_for_update()
      doesn't set REF_NEEDS_COMMIT for the deleted ref because REF_DELETING
      is set.  In contrast, the update for HEAD has REF_LOG_ONLY set by
      split_head_update(), resulting in the deletion being logged.
      Signed-off-by: Kyle Meyer's avatarKyle Meyer <kyle@kyleam.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  5. 20 Apr, 2016 1 commit
  6. 20 Nov, 2015 1 commit
  7. 12 Jun, 2015 1 commit
    • Mike Hommey's avatar
      Allow to control where the replace refs are looked for · 58d121b2
      Mike Hommey authored
      It can be useful to have grafts or replace refs for specific use-cases while
      keeping the default "view" of the repository pristine (or with a different
      set of grafts/replace refs).
      It is possible to use a different graft file with GIT_GRAFT_FILE, but while
      replace refs are more powerful, they don't have an equivalent override.
      Add a GIT_REPLACE_REF_BASE environment variable to control where git is
      going to look for replace refs.
      Signed-off-by: default avatarMike Hommey <mh@glandium.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  8. 25 May, 2015 2 commits
  9. 17 Feb, 2015 1 commit
  10. 15 Oct, 2014 1 commit
  11. 03 Sep, 2014 1 commit
  12. 20 Aug, 2014 1 commit
  13. 21 Jul, 2014 3 commits
  14. 25 Jun, 2014 4 commits
  15. 19 May, 2014 4 commits
  16. 29 Apr, 2014 4 commits
  17. 20 Feb, 2014 2 commits
  18. 30 Dec, 2013 1 commit
  19. 12 Dec, 2013 2 commits
    • Christian Couder's avatar
      builtin/replace: unset read_replace_refs · 769a4fa4
      Christian Couder authored
      When checking to see if some objects are of the same type
      and when displaying the type of objects, git replace uses
      the sha1_object_info() function.
      Unfortunately this function by default respects replace
      refs, so instead of the type of a replaced object, it
      gives the type of the replacement object which might
      be different.
      To fix this bug, and because git replace should work at a
      level before replacement takes place, let's unset the
      read_replace_refs global variable at the beginning of
      Suggested-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Christian Couder's avatar
      builtin/replace: teach listing using short, medium or full formats · 44f9f850
      Christian Couder authored
      By default when listing replace refs, only the sha1 of the
      replaced objects are shown.
      In many cases, it is much nicer to be able to list all the
      sha1 of the replaced objects along with the sha1 of the
      replacment objects.
      And in other cases it might be interesting to also show the
      types of the replaced and replacement objects.
      This patch introduce a new --format=<fmt> option where
      <fmt> can be any of the following:
      	'short': this is the same as when no --format
      		option is used, that is only the sha1 of
      		the replaced objects are shown
      	'medium': this also lists the sha1 of the
      		replacement objects
      	'full': this shows the sha1 and the type of both
      		the replaced and the replacement objects
      Some documentation and some tests will follow.
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  20. 06 Sep, 2013 2 commits
    • Christian Couder's avatar
      replace: allow long option names · ed0ff809
      Christian Couder authored
      It is now standard practice in Git to have both short and long option
      names. So let's give a long option name to the git replace options too.
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Christian Couder's avatar
      replace: forbid replacing an object with one of a different type · 277336a5
      Christian Couder authored
      Users replacing an object with one of a different type were not
      prevented to do so, even if it was obvious, and stated in the doc,
      that bad things would result from doing that.
      To avoid mistakes, it is better to just forbid that though.
      If -f option, which means '--force', is used, we can allow an object
      to be replaced with one of a different type, as the user should know
      what (s)he is doing.
      If one object is replaced with one of a different type, the only way
      to keep the history valid is to also replace all the other objects
      that point to the replaced object. That's because:
      * Annotated tags contain the type of the tagged object.
      * The tree/parent lines in commits must be a tree and commits, resp.
      * The object types referred to by trees are specified in the 'mode'
          100644 and 100755    blob
          160000               commit
          040000               tree
        (these are the only valid modes)
      * Blobs don't point at anything.
      The doc will be updated in a later patch.
      Acked-by: Philip Oakley's avatarPhilip Oakley <philipoakley@iee.org>
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  21. 30 Aug, 2013 1 commit
  22. 05 Aug, 2013 1 commit
  23. 18 Jun, 2013 1 commit
  24. 13 Nov, 2012 1 commit
  25. 20 Aug, 2012 1 commit