Experiments: VarCS + Rust

[oahshtsua]

Experimental Branch

This branch is for testing new ideas independently of the existing Python tool. It will contain loosely connected experimental features that explore different approaches, which may later be integrated into the broader workflow.

Since this is implemented as a Git extension, it can coexist with the existing Python CLI, which is also implemented as a Git extension. Both tools can be developed and used together if needed, allowing experimentation with Rust, libgit2, and other libraries while maintaining compatibility with the current workflows.

Features

1. Cherry-Pick Aware Commit Recognition

• Detects commits across branches even if cherry-picked, using an unique identifier assigned to each commit.
• Benefit: Track feature origins and variants reliably.
• Idea: Embed a unique identifier to each commit and compare based on the identifier instead of the commit hash.
• Implementation: Uses a git hook to populate the commit message with a UUID. A better approach would be to add a custom header (git allows this and just ignores any additional header) but this would require building the commit object manually. Also generating the change id based on the delta of the commit as opposed to a random UUID might be better for semantic significance.

2. Deriving Variants from Features

2.1 Commit-Based Variant Assembly

• Idea:
  Traverse commits associated with selected features and replay their changes to construct a variant.

• Implementation:

  • Filter commits using feature metadata.
  • For each commit:
    • Extract file diffs (deltas).
    • For each file:
      • Load file into memory.
      • Iterate through delta hunks:
        • Use old_lineno and new_lineno for positioning.
        • Insert lines for additions.
        • Remove lines for deletions.
        • Pad file if required to align line indices.
    • Write updated files to a new branch.

• Challenges:

  • Line numbers lose meaning when intermediate commits are skipped.
  • No reliable conflict resolution without full history context.
  • Fails with overlapping or interdependent changes.

• Conclusion:
  Works only for simple cases. Not reliable for real-world repositories.

2.2 Line-Based Reconstruction via Blame (WIP)

• Idea:
  Reconstruct files by selecting lines introduced by commits associated with chosen features.

• Implementation:

  • Iterate over all files in the repository.
  • For each file:
    • Run blame to map each line to its originating commit.
    • For each line:
      • Check if the commit has relevant feature metadata.
      • If yes, include the line in the output. If not, remove the line from the in-memory representation.
    • Assemble filtered lines in memory.
  • Write reconstructed files to disk as a new variant.

• Benefits:

  • Avoids replaying commits and merge complexity.
  • Works at line-level granularity.
  • More stable when features are interleaved.

• Limitations:

  • No history is preserved (snapshot only).
  • May produce inconsistent files if dependencies between lines are missing.
  • Does not capture structural changes (e.g., renames, refactors).

• Conclusion:
  Promising for snapshot-based variants that don't require history.

3. Variants Abstraction

• Introduce an abstraction over branches to differentiate between normal short-lived branches and variants, distinct from short-lived branches.
• Benefit: Manage long-lived variants vs dev branches and support operations like “update all variants.”
• Idea: Create a custom name spaced refs that point to branches that are variants.