1. 15 Mar, 2016 1 commit
    • Junio C Hamano's avatar
      rerere: allow multiple variants to exist · a13d1370
      Junio C Hamano authored
      The shape of the conflict in a path determines the conflict ID.  The
      preimage and postimage pair that was recorded for the conflict ID
      previously may or may not replay well for the conflict we just saw.
      
      Currently, we punt when the previous resolution does not cleanly
      replay, but ideally we should then be able to record the currently
      conflicted path by assigning a new 'variant', and then record the
      resolution the user is going to make.
      
      Introduce a mechanism to have more than one variant for a given
      conflict ID; we do not actually assign any variant other than 0th
      variant yet at this step.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a13d1370
  2. 08 Feb, 2016 1 commit
    • Junio C Hamano's avatar
      rerere: split conflict ID further · 1869bbe1
      Junio C Hamano authored
      The plan is to keep assigning the backward compatible conflict ID
      based on the hash of the (normalized) text of conflicts, keep using
      that conflict ID as the directory name under $GIT_DIR/rr-cache/, but
      allow each conflicted path to use a separate "variant" to record
      resolutions, i.e. having more than one <preimage,postimage> pairs
      under $GIT_DIR/rr-cache/$ID/ directory.  As the first step in that
      direction, separate the shared "conflict ID" out of the rerere_id
      structure.
      
      The plan is to keep information per $ID in rerere_dir, that can be
      shared among rerere_id that is per conflicted path.
      
      When we are done with rerere(), which can be directly called from
      other programs like "git apply", "git commit" and "git merge", the
      shared rerere_dir structures can be freed entirely, so they are not
      reference-counted and they are not freed when we release rerere_id's
      that reference them.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      1869bbe1
  3. 01 Sep, 2015 1 commit
    • Jeff King's avatar
      rerere: release lockfile in non-writing functions · 9dd330e6
      Jeff King authored
      There's a bug in builtin/am.c in which we take a lock on
      MERGE_RR recursively. But rather than fix am.c, this patch
      fixes the confusing interface from rerere.c that caused the
      bug. Read on for the gory details.
      
      The setup_rerere() function both reads the existing MERGE_RR
      file, and takes MERGE_RR.lock. In the rerere() and
      rerere_forget() functions, we end up in write_rr(), which
      will then commit the lock file.
      
      But for functions like rerere_clear() that do not write to
      MERGE_RR, we expect the caller to have handled
      setup_rerere(). That caller would then need to release the
      lockfile, but it can't; the lock struct is local to
      rerere.c.
      
      For builtin/rerere.c, this is OK. We run a single rerere
      operation and then exit immediately, which has the side
      effect of rolling back the lockfile.
      
      But in builtin/am.c, this is actively wrong. If we run "git
      am -3 --skip", we call setup-rerere twice without releasing
      the lock:
      
        1. The "--skip" causes us to call am_rerere_clear(), which
           calls setup_rerere(), but never drops the lock.
      
        2. We then proceed to the next patch.
      
        3. The "--3way" may cause us to call rerere() to handle
           conflicts in that patch, but we are already holding the
           lock. The lockfile code dies with:
      
           BUG: prepare_tempfile_object called for active object
      
      We could fix this by having rerere_clear() call
      rollback_lock_file(). But it feels a bit odd for it to roll
      back a lockfile that it did not itself take. So let's
      simplify the interface further, and handle setup_rerere in
      the function itself, taking away the question from the
      caller over whether they need to do so.
      
      We can give rerere_gc() the same treatment, as well (even
      though it doesn't have any callers besides builtin/rerere.c
      at this point). Note that these functions don't take flags
      from their callers to pass along to setup_rerere; that's OK,
      because the flags would not be meaningful for what they are
      doing.
      
      Both of those functions need to hold the lock because even
      though they do not write to MERGE_RR, they are still writing
      and should be protected from a simultaneous "rerere" run.
      But rerere_remaining(), "rerere diff", and "rerere status"
      are all read-only operations. They want to setup_rerere(),
      but do not care about taking the lock in the first place.
      Since our update of MERGE_RR is the usual atomic rename done
      by commit_lock_file, they can just do a lockless read. For
      that, we teach setup_rerere a READONLY flag to avoid the
      lock.
      
      As a bonus, this pushes builtin/rerere.c's setup_rerere call
      closer to the functions that use it. Which means that "git
      rerere totally-bogus-command" will no longer silently
      exit(0) in a repository without rerere enabled.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9dd330e6
  4. 24 Jul, 2015 2 commits
  5. 15 Sep, 2014 1 commit
  6. 15 Jul, 2013 1 commit
  7. 16 Sep, 2012 1 commit
  8. 08 May, 2011 1 commit
  9. 16 Feb, 2011 1 commit
    • Martin von Zweigbergk's avatar
      rerere "remaining" · ac49f5ca
      Martin von Zweigbergk authored
      After "rerere" resolves conflicts by reusing old resolution, there would
      be three kinds of paths with conflict in the index:
      
       * paths that have been resolved in the working tree by rerere;
       * paths that need further work whose resolution could be recorded;
       * paths that need resolving that rerere won't help.
      
      When the user wants a list of paths that need hand-resolving, output from
      "rerere status" does not help, as it shows only the second category, but
      the paths in the third category still needs work (rerere only makes sense
      for regular files that have both our side and their side, and does not
      help other kinds of conflicts, e.g. "we modified, they deleted").
      
      The new subcommand "rerere remaining" can be used to show both. As
      opposed to "rerere status", this subcommand also skips printing paths
      that have been added to the index, since these paths are already
      resolved and are no longer "remaining".
      
      Initial patch provided by Junio. Refactored and modified to skip
      resolved paths by Martin. Commit message mostly by Junio.
      Helped-by: default avatarJunio C Hamano <gitster@pobox.com>
      Signed-off-by: default avatarMartin von Zweigbergk <martin.von.zweigbergk@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ac49f5ca
  10. 11 Jan, 2010 1 commit
  11. 04 Dec, 2009 1 commit
  12. 15 Feb, 2009 1 commit
    • SZEDER Gábor's avatar
      rerere: remove duplicated functions · 90056966
      SZEDER Gábor authored
      Both rerere.c and builtin-rerere.c define the static functions
      rr_path() and has_resolution() the exact same way.  To eliminate this
      code duplication this patch turns the functions in rerere.c
      non-static, and makes builtin-rerere.c use them.  Also, since this
      puts these two functions into the global namespace, rename them to
      rerere_path() and has_rerere_resolution(), respectively, and rename
      their "name" parameter to "hex", because it better reflects what that
      parameter actually is.
      Signed-off-by: default avatarSZEDER Gábor <szeder@ira.uka.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      90056966
  13. 22 Jul, 2008 1 commit
    • Johannes Schindelin's avatar
      Rename path_list to string_list · c455c87c
      Johannes Schindelin authored
      The name path_list was correct for the first usage of that data structure,
      but it really is a general-purpose string list.
      
      $ perl -i -pe 's/path-list/string-list/g' $(git grep -l path-list)
      $ perl -i -pe 's/path_list/string_list/g' $(git grep -l path_list)
      $ git mv path-list.h string-list.h
      $ git mv path-list.c string-list.c
      $ perl -i -pe 's/has_path/has_string/g' $(git grep -l has_path)
      $ perl -i -pe 's/path/string/g' string-list.[ch]
      $ git mv Documentation/technical/api-path-list.txt \
      	Documentation/technical/api-string-list.txt
      $ perl -i -pe 's/strdup_paths/strdup_strings/g' $(git grep -l strdup_paths)
      
      ... and then fix all users of string-list to access the member "string"
      instead of "path".
      
      Documentation/technical/api-string-list.txt needed some rewrapping, too.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c455c87c
  14. 10 Jul, 2008 1 commit