Git Product home page Git Product logo

barter-rs / barter-rs Goto Github PK

View Code? Open in Web Editor NEW
616.0 25.0 101.0 868 KB

Open-source Rust framework for building event-driven live-trading & backtesting systems

Home Page: https://github.com/orgs/barter-rs/repositories

License: MIT License

Rust 100.00%
algo-trading algorithmic-trading algotrading backtesting backtesting-engine backtesting-trading-strategies hft high-frequency-trading quant quantitative-finance

barter-rs's Introduction

Barter

Barter is an open-source Rust framework for building event-driven live-trading & backtesting systems. Algorithmic trade with the peace of mind that comes from knowing your strategies have been backtested with a near-identical trading Engine. It is:

  • Fast: Barter provides a multi-threaded trading Engine framework built in high-performance Rust (in-rust-we-trust).
  • Easy: Barter provides a modularised data architecture that focuses on simplicity.
  • Customisable: A set of traits define how every Barter component communicates, providing a highly extensible framework for trading.

See: Barter-Data, Barter-Integration & Barter-Execution

Crates.io MIT licensed Build Status Discord chat

API Documentation | Chat

Overview

Barter is an open-source Rust framework for building event-driven live-trading & backtesting systems. It provides a high-performance, easy to customise trading Engine that enables backtesting strategies on a near-identical system to live trading. The Engine can be controlled by issuing Commands over the Engine's command_tx. Similarly, the Engine's Events can be listened to using the event_rx (useful for event-sourcing). At a high level, it provides several de-coupled components that interact via a set of traits:

  • Data: MarketGenerator trait governs the generation of a MarketEvents that acts as the system heartbeat. For example, a live::MarketFeed implementation is provided that utilises Barter-Data WebSocket integrations to provide live exchange data (ie/ trades, candles, etc).
  • Strategy: The SignalGenerator trait governs potential generation of Signal after analysing incoming MarketEvents. Signals are advisory and sent to the Portfolio for analysis.
  • Portfolio: MarketUpdater, OrderGenerator, and FillUpdater govern global state Portfolio implementations. A Portfolio may generate OrderEvents after receiving advisory SignalEvents from a Strategy. The Portfolio's state updates after receiving MarketEvents and FillEvents.
  • Execution: The ExecutionClient trait governs the generation of FillEvents after receiving OrderEvents from the Portfolio. For example, a SimulatedExecution handler implementation is provided for simulating any exchange execution behaviour required in dry-trading or backtesting runs.
  • Statistic: Provides metrics such as Sharpe Ratio, Calmar Ratio, and Max Drawdown to analyse trading session performance. One-pass dispersion algorithms analyse each closed Position and efficiently calculates a trading summary.
  • Trader: Capable of trading a single market pair using a customisable selection of it's own Data, Strategy & Execution instances, as well as shared access to a global Portfolio.
  • Engine: Multi-threaded trading Engine capable of trading with an arbitrary number of Trader market pairs. Each contained Trader instance operates on its own thread.

Example

  • For brevity: Imports are not included - see /examples for everything you need!
  • For simplicity:
    • Engine and Trader(s) are configuration with hard-coded values rather than loaded in configuration values.
    • Engine only contains one Trader (usually you would have many Traders, one for each Market).
    • Remote Commands (eg/ Command::Terminate, Command::ExitPosition) are not sent to the Engine via it's command_tx, this control over the Engine can be added as per your taste (eg/ connected to an HTTP endpoint).
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Setup Logger & Load Config For Engine & Trader Instances Here

    // Create channel to distribute Commands to the Engine & it's Traders (eg/ Command::Terminate)
    let (command_tx, command_rx) = mpsc::channel(20);
    
    // Create Event channel to listen to all Engine Events in real-time
    let (event_tx, event_rx) = mpsc::unbounded_channel();
    let event_tx = EventTx::new(event_tx);
    
    // Generate unique identifier to associate an Engine's components
    let engine_id = Uuid::new_v4();
    
    // Create the Market(s) to be traded on (1-to-1 relationship with a Trader)
    let market = Market::new("binance", ("btc", "usdt", InstrumentKind::Spot));
    
    // Build global shared-state MetaPortfolio (1-to-1 relationship with an Engine)
    let portfolio = Arc::new(Mutex::new(
        MetaPortfolio::builder()
            .engine_id(engine_id)
            .markets(vec![market.clone()])
            .starting_cash(10_000.0)
            .repository(InMemoryRepository::new())
            .allocation_manager(DefaultAllocator { default_order_value: 100.0 })
            .risk_manager(DefaultRisk {})
            .statistic_config(StatisticConfig {
                starting_equity: 10_000.0,
                trading_days_per_year: 365,
                risk_free_return: 0.0,
            })
            .build_and_init()
            .expect("failed to build & initialise MetaPortfolio"),
    ));
    
    // Build Trader(s)
    let mut traders = Vec::new();
    
    // Create channel for each Trader so the Engine can distribute Commands to it
    let (trader_command_tx, trader_command_rx) = mpsc::channel(10);

    traders.push(
        Trader::builder()
            .engine_id(engine_id)
            .market(market.clone())
            .command_rx(trader_command_rx)
            .event_tx(event_tx.clone())
            .portfolio(Arc::clone(&portfolio))
            .data(historical::MarketFeed::new([test_util::market_candle].into_iter()))
            .strategy(RSIStrategy::new(StrategyConfig { rsi_period: 14 }))
            .execution(SimulatedExecution::new(ExecutionConfig {
                simulated_fees_pct: Fees {
                        exchange: 0.1,
                        slippage: 0.05,
                        network: 0.0,}
                }))
            .build()
            .expect("failed to build trader")
    );
    
    // Build Engine (1-to-many relationship with Traders)
    
    // Create HashMap<Market, trader_command_tx> so Engine can route Commands to Traders 
    let trader_command_txs = HashMap::from_iter([(market, trader_command_tx)]);
    
    let engine = Engine::builder()
        .engine_id(engine_id)
        .command_rx(command_rx)
        .portfolio(portfolio)
        .traders(traders)
        .trader_command_txs(trader_command_txs)
        .statistics_summary(TradingSummary::init(StatisticConfig {
            starting_equity: 1000.0,
            trading_days_per_year: 365,
            risk_free_return: 0.0
        }))
        .build()
        .expect("failed to build engine");
        
    // Listen to Engine Events & do something with them
    tokio::spawn(listen_to_events(event_rx)); 
        
    // --- Run Trading Session Until Remote Shutdown OR Data Feed ends naturally (ie/ backtest) ---
    engine.run().await;
}

Getting Help

Firstly, see if the answer to your question can be found in the API Documentation. If the answer is not there, I'd be happy to help to Chat and try answer your question via Discord.

Contributing

๐ŸŽ‰ Thanks for your help in improving the barter ecosystem! Please do get in touch on the discord to discuss development, new features, and the future roadmap.

Related Projects

In addition to the Barter crate, the Barter project also maintains:

  • Barter-Integration: High-performance, low-level framework for composing flexible web integrations.
  • Barter-Data: High performance & normalised WebSocket integration for leading cryptocurrency exchanges - batteries included.
  • Barter-Execution: In development and soon to be integrated.

Roadmap

  • Integrate the new "Barter-Execution" library to provide additional out-of-the-box functionality for executing OrderEvents.
  • Build Strategy utilities for aggregating tick-by-tick Trades and/or Candles into multi-timeframe datastructures, as well as providing an example multi-timeframe Strategy using the utilities.
  • Flesh out the MetaPortfolio Allocator & Risk management systems.
  • And more!

Licence

This project is licensed under the MIT license.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in Barter by you, shall be licensed as MIT, without any additional terms or conditions.

barter-rs's People

Contributors

c10k-cc avatar just-a-stream avatar liamwh avatar mempooler avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

barter-rs's Issues

Perform various GitHub repo chores

Perform various GitHub repo chores

Summary

This issue / proposal addresses various miscellaneous tasks related to GitHub repo which need to be performed.

Description

These are some of the tasks which need to be performed (on all 4 repos):

Project activity and Discord link

I'm very interested in using barter for my project and I'm wondering if there are funds and solid plans / roadmap to maintain and further develop this library in the long term.

I also wanted to point out that the discord link in the "Getting Help" section is invalid

examples/engine_with_historic_candles.rs breaks

File path issue

Tried run examples with the following command

cd barter-rs # Same level as barter-rs/Cargo.toml
cargo run --example engine_with_historic_candles

rust complains the data file candles_1h.json can not be found

Running target/debug/examples/engine_with_historic_candles
thread 'main' panicked at 'failed to read file: Os { code: 2, kind: NotFound, message: "No such file or directory" }', examples/engine_with_historic_candles.rs:116:71

I guess this is because the path of the data file lives in barter-rs/examples/data/candles_1h.json, while the current working directory is barter-rs. The line causing trouble is in engine_with_historic_candles.rs line 116: let candles = fs::read_to_string("barter-rs/examples/data/candles_1h.json").expect("failed to read file"); When I changed the path to fs::read_to_string("examples/data/candles_1h.json"), The error can be fixed.

I am not sure if this is a bug, or I am in the wrong directory? What is the expected working directory for a new user to run the example with cargo run --example engine_with_historic_candles?

Data out of sync

The example requires the example has a field close_time:

    candles
        .into_iter()
        .map(|candle| MarketEvent {
            exchange_time: candle.close_time,
            received_time: Utc::now(),
            exchange: Exchange::from("binance"),
            ......

But the example data in candles_1h.json only has start_time and end_time, but no close_time:

  {
    "start_time": "2022-04-05 20:00:00.000000000 UTC",
    "end_time": "2022-04-05 21:00:00.000000000 UTC",
    "open": 1000.0,
    "high": 1100.0,
    "low": 900.0,
    "close": 1050.0,
    "volume": 1000000000.0,
    "trade_count": 100
  },

resulting in this error:

Running target/debug/examples/engine_with_historic_candles
thread 'main' panicked at 'failed to parse candles String: Error("missing field close_time", line: 11, column: 3)', examples/engine_with_historic_candles.rs:119:55

This can also be fixed by replacing all the end_time fields with close_time in candles_1h.json. But I am not sure whether the start_time and end_time fileds are still valid fields to keep.

Requesting upgrade `prettytable-rs` to 0.10.0

Background

Unsoundness is found using the nightly toolchain with prettytable-rs version 0.8.0. Details are found in issue

Request

Could you please upgrade prettytable-rs to 0.10.0 which uses safe rust to convert Table to TableSlice.

Contribution

I would love to contribute, but I failed to find the branch where 0.8.6 locates.

Update docs

Update docs

Summary

This issue / proposal attempts to address the project's need for a proper documentation update.

Description

Type of docs which need to be updated / added (including but not limited to):

  • project-related docs
    • rust docs
      • Rust doc-string comments inside the code files which gets auto-rendered to API reference docs - see more here
      • fix cross-linking / cross-referencing
    • README.md
      • file needs to be properly re-structured to reference all other markdown files proposed below
      • sections need to be sorted by the degree of complexity / depth of the topic covered
    • ARCHITECTURE.md
      • describes the project architecture
      • could contain an embedded diagrams (UML or less formal) & flowcharts
    • Concepts
      • covering various concepts (theoretical or otherwise) introduced by the project
      • glossary of terms for the project
    • Examples
      • simple & trivial examples covering various project functionalities
    • Tutorial
      • proper user guide
    • Quick start
      • see 2 sections above
  • repo-related docs
    • CONTRIBUTING.md
      • contains instructions on how to contribute
      • how to write code, tests, docs, git commit, git branches / workflow, setup dev environment etc
    • MAINTAINING.md
      • contains instructions on how to maintain the repo
      • how to manage & review issues / pull requests, organise the project board etc
    • CODE_OF_CONDUCT.md
      • bullshit file covering various topics related to political correctness, inclusivity, racism, sexuality, hate speech, profanity etc.
      • mainly used as a diplomatic no-responsibility disclaimer guarding authors & maintainers from consequences of stupid shit & abuse some degenerate contributor might do and ruin the things for the whole community
      • nice to have, but definitely lowest priority ever
  • dedicated docs site / wiki pages
    • GitHub Wiki pages?
    • currently redundant?

timeline alignment between traders?

It seems that I am unable to align the timelines of independently running traders: I initially intended to monitor a futures contract trader, and when certain conditions are met, send trading commands to the corresponding options contract trader (in another independent thread). However, since the engine is event-driven, traders trade based on their independently held timelines of data and derived market events under the control of their respective strategies. Any insights in terms of timeline alignment between traders?

Organise workflow in `Barter Project` GitHub Project

Organise workflow in Barter Project GitHub Project

Summary

This issue / proposal addresses the organisation of workflow in Barter Project GitHub Project. It mainly focuses on proper organisation of views (Boards & Tables), Status field etc.

Description

Here are some of the things which come to my mind:

  • issue & pull request views need to be separated / filtered
  • unaddressed (unprocessed / un-triaged / untagged) items need to be separated from addressed ones
  • Kanban board Status field needs to be designed in a senseful way
    • Todo, In Progress & Done columns are too generic
      • they don't precisely represent each issue's common increments / phases
    • add some columns which represent additional steps in issue progression
      • e.g. Rejected / Accepted / Approved / In Review / Waiting For Approval / Waiting For Merge or something similar
    • items are only allowed to move from left to right (no backwards movement)
    • items should be pulled instead of pushed by assigned team members
  • additional workflow suggestions?

Is the output of the performance analysis asnychronous?

I got bad formatted output, when I ran the example with BTCUSDTPERP data (about 1000 ticks).
It seems that printing the performance analysis and system event logs is executed asynchronously.

# snipped...
PositionUpdate { position_id: "255385be-bc70-4f3d-bdb6-186049dd7900_binance_(btc_usdt, spot)_position", update_time: 2022-11-14T21:14:59.999Z, current_symbol_price: 16306.0, current_value_gross: 97.836, unrealised_profit_loss: -30.915479999999995 }
PositionUpdate { position_id: "255385be-bc70-4f3d-bdb6-186049dd7900_binance_(btc_usdt, spot)_position", update_time: 2022-11-14T21:29:59.999Z, current_symbol_price: 16338.0, current_value_gross: 98.028, unrealised_profit_loss: -30.723479999999988 }
                PositionUpdate { position_id: "255385be-bc70-4f3d-bdb6-186049dd7900_binance_(btc_usdt, spot)_position", update_time: 2022-11-14T21:44:59.999Z, current_symbol_price: 16374.4, current_value_gross: 98.2464, unrealised_profit_loss: -30.50508 }
PositionUpdate { position_id: "255385be-bc70-4f3d-bdb6-186049dd7900_binance_(btc_usdt, spot)_position", update_time: 2022-11-14T21:59:59.999Z, current_symbol_price: 16396.6, current_value_gross: 98.3796, unrealised_profit_loss: -30.371879999999997 }
 | PositionUpdate { position_id: "255385be-bc70-4f3d-bdb6-186049dd7900_binance_(btc_usdt, spot)_position", update_time: 2022-11-14T22:14:59.999Z, current_symbol_price: 16404.2, current_value_gross: 98.4252, unrealised_profit_loss: -30.32627999999999 }
0.000        PositionUpdate { position_id: "255385be-bc70-4f3d-bdb6-186049dd7900_binance_(btc_usdt, spot)_position", update_time: 2022-11-14T22:29:59.999Z, current_symbol_price: 16393.4, current_value_gross: 98.36040000000001, unrealised_profit_loss: -30.39107999999998 }
 | PositionUpdate { position_id: "255385be-bc70-4f3d-bdb6-186049dd7900_binance_(btc_usdt, spot)_position", update_time: 2022-11-14T22:44:59.999Z, current_symbol_price: 16356.0, current_value_gross: 98.136, unrealised_profit_loss: -30.615479999999998 }
0                 PositionUpdate { position_id: "255385be-bc70-4f3d-bdb6-186049dd7900_binance_(btc_usdt, spot)_position", update_time: 2022-11-14T22:59:59.999Z, current_symbol_price: 16398.0, current_value_gross: 98.388, unrealised_profit_loss: -30.36347999999999 }
Signal { time: 2023-01-01T14:32:05.173112179Z, exchange: binance, instrument: Instrument { base: btc, quote: usdt, kind: Spot }, signals: {CloseLong: SignalStrength(1.0), Short: SignalStrength(1.0)}, market_meta: MarketMeta { close: 16549.2, time: 2022-11-14T23:14:59.999Z } }
PositionUpdate { position_id: "255385be-bc70-4f3d-bdb6-186049dd7900_binance_(btc_usdt, spot)_position", update_time: 2022-11-14T23:14:59.999Z, current_symbol_price: 16549.2, current_value_gross: 99.29520000000001, unrealised_profit_loss: -29.456279999999985 }
OrderEvent { time: 2023-01-01T14:32:05.173124573Z, exchange: binance, instrument: Instrument { base: btc, quote: usdt, kind: Spot }, market_meta: MarketMeta { close: 16549.2, time: 2022-11-14T23:14:59.999Z }, decision: CloseLong, quantity: -0.006, order_type: Market }
FillEvent { time: 2023-01-01T14:32:05.173127616Z, exchange: binance, instrument: Instrument { base: btc, quote: usdt, kind: Spot }, market_meta: MarketMeta { close: 16549.2, time: 2022-11-14T23:14:59.999Z }, decision: CloseLong, quantity: -0.006, fill_value_gross: 99.29520000000001, fees: Fees { exchange: 9.929520000000002, slippage: 4.964760000000001, network: 0.0 } }
PositionExit { position_id: "255385be-bc70-4f3d-bdb6-186049dd7900_binance_(btc_usdt, spot)_position", exit_time: 2023-01-01T14:32:05.173127616Z, exit_balance: Balance { time: 2023-01-01T14:32:05.173127616Z, total: 8754.7218585, available: 8670.3209385 }, exit_fees: Fees { exchange: 9.929520000000002, slippage: 4.964760000000001, network: 0.0 }, exit_fees_total: 14.894280000000002, exit_avg_price_gross: 16549.2, exit_value_gross: 99.29520000000001, realised_profit_loss: -29.494619999999987 }
Balance { time: 2023-01-01T14:32:05.173127616Z, total: 8754.7218585, available: 8754.7218585 }
Signal { time: 2023-01-01T14:32:05.173154442Z, exchange: binance, instrument: Instrument { base: btc, quote: usdt, kind: Spot }, signals: {Short: SignalStrength(1.0), CloseLong: SignalStrength(1.0)}, market_meta: MarketMeta { close: 16634.6, time: 2022-11-14T23:29:59.999Z } }
OrderEvent { time: 2023-01-01T14:32:05.173164310Z, exchange: binance, instrument: Instrument { base: btc, quote: usdt, kind: Spot }, market_meta: MarketMeta { close: 16634.6, time: 2022-11-14T23:29:59.999Z }, decision: Short, quantity: -0.006, order_type: Market }
FillEvent { time: 2023-01-01T14:32:05.173167174Z, exchange: binance, instrument: Instrument { base: btc, quote: usdt, kind: Spot }, market_meta: MarketMeta { close: 16634.6, time: 2022-11-14T23:29:59.999Z }, decision: Short, quantity: -0.006, fill_value_gross: 99.8076, fees: Fees { exchange: 9.98076, slippage: 4.99038, network: 0.0 } }
 Position { position_id: "255385be-bc70-4f3d-bdb6-186049dd7900_binance_(btc_usdt, spot)_position", meta: PositionMeta { enter_time: 2022-11-14T23:29:59.999Z, update_time: 2023-01-01T14:32:05.173167174Z, exit_balance: None }, exchange: binance, instrument: Instrument { base: btc, quote: usdt, kind: Spot }, side: Sell, quantity: -0.006, enter_fees: Fees { exchange: 9.98076, slippage: 4.99038, network: 0.0 }, enter_fees_total: 14.97114, enter_avg_price_gross: 16634.6, enter_value_gross: 99.8076, exit_fees: Fees { exchange: 0.0, slippage: 0.0, network: 0.0 }, exit_fees_total: 0.0, exit_avg_price_gross: 0.0, exit_value_gross: 0.0, current_symbol_price: 16634.6, current_value_gross: 99.8076, unrealised_profit_loss: -29.94228, realised_profit_loss: 0.0 }
Balance { time: 2023-01-01T14:32:05.173167174Z, total: 8754.7218585, available: 8639.9431185 }
Signal { time: 2023-01-01T14:32:05.173184671Z, exchange: binance, instrument: Instrument { base: btc, quote: usdt, kind: Spot }, signals: {CloseLong: SignalStrength(1.0), Short: SignalStrength(1.0)}, market_meta: MarketMeta { close: 16692.1, time: 2022-11-14T23:44:59.999Z } }
PositionUpdate { position_id: "255385be-bc70-4f3d-bdb6-186049dd7900_binance_(btc_usdt, spot)_position", update_time: 2022-11-14T23:44:59.999Z, current_symbol_price: 16692.1, current_value_gross: 100.15259999999999, unrealised_profit_loss: -30.28728 }
Signal { time: 2023-01-01T14:32:05.173202045Z, exchange: binance, instrument: Instrument { base: btc, quote: usdt, kind: Spot }, signals: {CloseLong: SignalStrength(1.0), Short: SignalStrength(1.0)}, market_meta: MarketMeta { close: 16605.2, time: 2022-11-14T23:59:59.999Z } }
PositionUpdate { position_id: "255385be-bc70-4f3d-bdb6-186049dd7900_binance_(btc_usdt, spot)_position", update_time: 2022-11-14T23:59:59.999Z, current_symbol_price: 16605.2, current_value_gross: 99.6312, unrealised_profit_loss: -29.765880000000013 }
|
+-----------------------+--------+------+--------+--------------+----------------+-------------+------------------+------------------+-------------+--------------+--------------+---------------+--------------+--------------+-------------------+---------------+--------------------+

DEX integration

Hello! is it possible to use your library to trade on DEX?

Rewrite project history

Rewrite project history

Summary

This issue / proposal aims to address the complete rewriting of the whole project git history.

Description

About

Hello folks!

@just-a-stream entrusted me a role of barter-rs GitHub organisation owner (along with him, of course),
mainly in order to assist him with structuring the GitHub organisation, teams, project, repositories etc.
One of the first items on my repo "housekeeping agenda" is addressing some problems with the project git history.
Afterwards, I will continue to make other advancements to the repository organisation, backlog, docs, CI etc.

Yes, I actually took my time and reviewed over 400 existing commits in this repo
in order to get a better understanding of the project structure & history (roughly 10 hours of work overall).
Hey, at least I learned the project structure and how the things evolved over time.

Intro

This proposal (along with its associated upcoming PR) aims to completely rewrite the whole project git history,
in order to fix few major otherwise unresolvable issues which are currently present.

However, performing such an unprecedented change is a very brave & dangerous task with a lot of risks associated.
That is why this proposal is designed in such a way to honour the above-limitations, reduce the risks to zero,
and remove any and all dangers associated with it.

Motivation

This whole open-source project was started as a @just-a-stream's personal hobby project.
It is completely understandable that starting a small project from scratch does not assume doing "boilerplatey" tasks,
such as properly organising git branches or formatting git commit messages.
Once the project starts growing, the organic need for a stricter project organisation comes by.
Overall, the author did an amazing job of designing and open-sourcing such an ambitious project.
Nonetheless, it does not change the fact that some things should've / can still be organised better, as mentioned below.

This is a list of issues with a varying degrees of severity / significance:

  • author's private e-mail & personal name are leaking from git commit metadata
    (due to misconfiguration + lack of automatic author e-mail anonymisation feature on legacy commits made on GitLab)
  • project tries to follow Git Flow model, but diverges from some important conventions
    • develop branch was merged into main branch without a fast-forward merge
      • it causes a redundant merge commit to be generated on merge (creates clutter, reduces visibility)
      • this is obviously against the model's conventions, only feature/* branches must be merged without FF merge
    • feat/* branches weren't rebased when going out-of-date from develop, develop was merged into them
      • it causes annoying merge conflicts (and, therefore, generating annoying redundant conflict-resolving commits)
      • generates a redundant merge commit (sometimes even multiple commits)
      • the only exception for merges into feat/* is when the feature/* is going to squash its changes
        (rebase-squash commits)
    • concept of version tagging on main branch was entirely ignored
      • too bad, since GitHub supports easy project release creation from properly-organised tags
    • concept of release/* branches was almost entirely ignored
      • goes in-hand with tagging & merging to main
    • on few occasions, changes were directly applied to main branch
      • this is against a concept of hotfix/* branch utilisation
  • project tries to follow Git Conventional Commits, but again, diverges from some conventions
    • commit messages do not properly utilise topic: prefixes
      • most of the commits are incorrectly prefixed with feat: prefix
    • commit titles do not consistently describe the changes applied (occasional too short & obfuscated message)
    • commit titles are not written in an "imperative" or "present" form
    • commits do not utilise title + body formatting at all, only a brief (and sometimes overly-long) title

Again, all the mentioned issues are completely normal and to-be-expected from an emerging open-source project.
When starting out, a dev works fast and breaks things.
Nobody has the time for such an overhead of a task such as properly organising git branches, commits or commit messages.
However, that is why it is important to perform some "git housekeeping" tasks before taking the project public,
e.g. making a "public appearance".

Now is better than never. The project is still very young and in its early stage.
The transfer to GitHub is also very recent, so it would be a good idea to do it as soon as possible,
before there is a swarm of forks, pull requests, stars & open issues.
All the forks are from the devs who are in communication with each other in the community (at the time of writing),
so nobody will be surprised by the change, without being informed in advance and offered additional migration help.

Constraints

There are multiple constraints due to the fragility & delicacy of such a task.
In other words, nobody recommends to rewrite git history, devs are afraid of merge hells & force git pushes,
git rebase is not well-understood or liked etc.

This set of changes is designed with a strict respect to the constraints in mind:

  • no breaking changes (or otherwise)
    • actually, NO CHANGES AT ALL!
    • changes are bad
  • no unnecessary modifications
    • repeat, NO CHANGES AT ALL!!!
  • maximum historical compatibility (date & author preservation etc.)
    • NO CHANGES!!!1!
  • no side effects for existing & future contributors (e.g. merge hell)

Changes applied

Proposed solution to this problem is to carefully rebase the project's git history.

During the implementation of this solution, additional steps were taken to respect the above-mentioned constraints:

  • no commit contents were actually changed (git tree remains intact for all commits)
  • no additional commits were added
  • only commit messages were modified

The result is a develop-new branch which is 1-to-1 compatible with the current develop branch
throughout all the versions of releases.

Achieved improvements

There are multiple benefits of this newly-rewritten project git history:

  • No leaking personal information from commits
  • Date & author of all the existing commits completely preserved
  • Consistent commit message formatting
    • topic: prefix keywords are properly utilised
    • no commit message title longer than 100 characters (still a very gracious length limit)
      • messages longer than that utilise commit message body separated by a blank line
        • indicated by * at the end of the commit message title / subject line
    • all the symbols (module names, variables, structs, traits, functions etc.) encased in ` (backtick characters)
      • this gets rendered to a Markdown code block, like this: FooBar
        • this makes referenced symbols more visible, without polluting messages / sacrificing conciseness
    • when multiple unrelated changes occur in a commit, they are split with ;
    • messages written in an imperative / present form
    • messages lower-cased and do not end with .
    • overall useful for complying with modern CI/CD tool pipelines & parsing commit messages
  • Organised branch workflow
  • Easier to make future contributions (more inviting to work on a well-organised project)
  • All the project release versions can now be easily tagged, and their releases can be easily generated on GitHub.
  • The history of each file can be easily tracked & traced / inspected, due to tidy & expressive commit messages applied
    • helpful for git blame & similar tools
  • There are now less commits (removed redundant merge commits & some obvious duplicate commits)
    • doesn't affect any historical version, e.g. does not produce any differences at the point of any release
  • A good example is set for all the future project contributions
    • organised git branches, commits & their messages!

Verification (steps to verify / reproduce the results)?

(expand)

Verification method: trust me bro

Nah, just kidding. You can really verify it yourself.
By performing the steps specified below,
you can easily check that all the changes are indeed compatible with the existing develop branch releases.

You can run this shell script, which is hopefully written concise enough and well-documented with expressive comments.
Yes, I had to write it from scratch, what a waste of time.

compare-branches.sh
#!/usr/bin/env bash

ORIG_DIR="$PWD/barter-rs-orig"
REBASED_DIR="$PWD/barter-rs-rebased"

# this array contains hard-coded original branch "version" commits a.k.a. release commits
# how to easily acquire these commit hashes yourself?
#  - run this shell command inside repo dir:
#    `git checkout develop; git log --format=oneline Cargo.toml`
#  - optionally, filter by commits containing "incr" (which is not 100% reliable due to unstructured message format):
#    `git log --format=oneline --grep=incr Cargo.toml`
ORIG_VER_COMMITS=(
  0d1467cc5a1b8318a3d2b4d941b1b8a38bd233a7 # v0.1.0
  5dba365d1fd53630c7aa82943d3faa12aa27f835 # v0.2.0
  1ff46f09f4db8003c816432c16e718e59e00fdd7 # v0.2.1
  68d96309bff2a7fc367dd51b0d5120dc09fc46c6 # v0.2.2
  fd85e3d47348e6c772116e368eca253075ea6c00 # v0.2.3
  ef717c03418840dedfdfc2d95edf950f67ec9e6a # v0.2.4
  57ec50a8551455c5102b2082a56f89676ffd9be6 # v0.2.5
  64de2b24a7c11391683c6265ffcb1e00e9a88aec # v0.2.6
  830c6c17e611107b53e49cdac44da99bade4687f # v0.2.7
  430a33b9df0052b24bd170a0f291847035ddbd1c # v0.2.8
  204b8f5ca50c260c41a1c1f7f6cdedfcd7f64dfd # v0.2.9
  22e0d1d765c64c172377b340716910fda1c4aa37 # v0.2.10
  78ab53fa5a042eb56ece795fb0a6a5b0aceca7a8 # v0.2.11
  25013f809da85bc5c20995397d20d170626bdcc9 # v0.3.0
  557b926e3c202616734dc4a9605253c72416231e # v0.3.1
  5221bf49ce227268b2e6868c6055f200c6321d4b # v0.4.0
  56e5668ad8ccdf4df4c3a7183d045772aef8f151 # v0.4.1
  6d27e30d0603683f2927c106646a3690a4939626 # v0.5.0
  6e659b7601cf107f6716315f52be03827e910599 # v0.5.1
  05830063457ae54db000a3158000a8dec3239fe6 # v0.5.2
  5bae25abc4ed878269bc8df9b679ccf42e235fd3 # v0.5.3
  e9021da46717379615be01eadfc4ccae97422441 # v0.5.4
  953a54cff61ab2dfc560f7adcf304a249aede437 # v0.5.5
  3571f630d2913c76a5eb05e0891b5a3c18c9ad25 # v0.5.6
  d322f9ac6d41fd39f738025cc8f789e28db04e26 # v0.5.7
  f1543e8da74309619da6d71b220528e14ff54671 # v0.5.8
  eaa19c6ed47930f6297692c6d0333d9442b9d336 # v0.5.9
  89fd2602199ad99aec2216611d476b34667cf3d3 # v0.5.10
  945cf1693de2bbaff6c3aa17775d4e67d5454239 # v0.6.0
  f16e763abe006002f7ebf0c295f6bb13a9923a18 # v0.6.1
  2022a73303f6ba467c68d8b2660e64b21912a8cb # v0.6.2
  c86cebcb47b8d3ff1d82dc179215f1d812893ed4 # v0.6.3
  d634cd5e5a3740eb838fefdc63fa8d0320c62419 # v0.6.4
  ca2b714b409686fedf01426533395408a3f48d39 # v0.6.5
  36e98f7ee9c0ad96fd45d3289a1d2b931f0ae122 # v0.7.0
  3d9d4203485ff4e41b0d82527ba14d4a009d39a8 # v0.7.1
  495a8727a796871038c1adad5ffa9cab49f791a7 # v0.7.2
  f855592f8f073d749ad62301724b9b4ac22d2aa8 # v0.8.0
  e10b4533175aadcc5898afed0a623105a2605435 # v0.8.1
  9d9fa2f6a35aace70c2b1e2f4d59adac72f94463 # v0.8.2
  2c5d2994118ac803a87b44f0bd5ce21c5086f50e # v0.8.3
  ba2af7d4639f8977b10dfde927bf4beaf727f9d4 # v0.8.4
)

# this array contains rebased branch "version" commits a.k.a. release commits
# these can be easily acquired, since commit messages are well-formatted
REBASED_VER_COMMITS=(
  `git log --format="%H" --grep="build: increment" Cargo.toml | tac`
)

# if arrays are unexpectedly of different length, the script has to terminate - it makes no sense to continue
if [ "${#ORIG_VER_COMMITS[@]}" -ne "${#REBASED_VER_COMMITS[@]}" ]; then
  echo "${#ORIG_VER_COMMITS[@]}"
  echo "${#REBASED_VER_COMMITS[@]}"
  echo "Error: different number of release commits between original & rebased branches" >&2
  exit 1
fi

# initial cleanup
rm -rf "$ORIG_DIR"
rm -rf "$REBASED_DIR"
rm -rf "diffs"

# clone repo & duplicate the dir (one for original branch releases & other for rebased branch releases)
git clone "https://www.github.com/barter-rs/barter-rs" "$ORIG_DIR"
cp -r "$ORIG_DIR" "$REBASED_DIR"

# iterate over commit arrays, checkout given commits & compare the differences between git trees at that point in time
#  - this is a reliable method, since it takes into account all the changes that might have accumulated over time
#    (up until the release commit)
for i in $(seq 1 "${#ORIG_VER_COMMITS[@]}"); do
  echo "Info: Comparing versions ($i / ${#ORIG_VER_COMMITS[@]})"
  cd "$ORIG_DIR"
  git checkout -q "${ORIG_VER_COMMITS[$(($i-1))]}" # add -q flag to hide verbose git commit info
  orig_ver="$(grep -Eo '^version\s*=\s*"\d\.\d\.\d+"' Cargo.toml | tr -d ' "' | cut -d = -f2)"
  echo "Info: Checked out v$orig_ver (original branch - ${ORIG_VER_COMMITS[$(($i-1))]})"
  cd ..
  cd "$REBASED_DIR"
  git checkout -q "${REBASED_VER_COMMITS[$(($i-1))]}" # add -q flag to hide verbose git commit info
  rebased_ver="$(grep -Eo '^version\s*=\s*"\d\.\d\.\d+"' Cargo.toml | tr -d ' "' | cut -d = -f2)"
  echo "Info: Checked out v$rebased_ver (rebased branch - ${REBASED_VER_COMMITS[$(($i-1))]})"
  cd ..
  # check if captured version variables contain exactly 1 line and are not empty
  if [ -z "$orig_ver" ] && [ "$(echo $orig_ver | wc -l)" -ne 1 ]; then
    err="original repo contains an invalid Cargo.toml file - most likely due to a git conflict"
    break
  fi
  if [ -z "$orig_ver" ] && [ "$(echo $rebased_ver | wc -l)" -ne 1 ]; then
    err="rebased repo contains an invalid Cargo.toml file - most likely due to a git conflict"
    break
  fi
  if [ "$orig_ver" != "$rebased_ver" ]; then
    err="version mismatch occurred on original version $orig_ver / rebased version $rebased_ver"
    break
  fi
  # compare different branch git trees (a.k.a. directories) for differences
  #  (`-r` is recursive, `-q` is quiet / brief - e.g. only show which files differ)
  diff_output_quiet="$(diff -qr -x ".git" -x ".idea" -x "target" -x "Cargo.lock" "$ORIG_DIR" "$REBASED_DIR")"
  if [ ! -z "$diff_output_quiet" ]; then
    # if differences exist (they are not an empty string), re-run a full diff to capture content differences as well
    diff_output="$(diff -r -x ".git" -x ".idea" -x "target" -x "Cargo.lock" "$ORIG_DIR" "$REBASED_DIR")"
    echo "Warning: branches differ on v$orig_ver" >&2
    # create dir for saving `diff` outputs
    mkdir -p diffs
    # save content differences to a file named by a version
    echo "$diff_output" > "diffs/v$orig_ver.diff"
  else
    echo "Info: branch releases are identical for v$orig_ver"
  fi
done

# exit cleanup - remove cloned repos
rm -rf "$ORIG_DIR"
rm -rf "$REBASED_DIR"

if [ ! -z "$err" ]; then
  echo "Error: $err" >&2
  exit 1
fi
Verification process output log (sample)
Info: Comparing versions (1 / 42)
Info: Checked out v0.1.0 (original branch - 0d1467cc5a1b8318a3d2b4d941b1b8a38bd233a7)
Info: Checked out v0.1.0 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.1.0
Info: Comparing versions (2 / 42)
Info: Checked out v0.2.0 (original branch - 5dba365d1fd53630c7aa82943d3faa12aa27f835)
Info: Checked out v0.2.0 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.2.0
Info: Comparing versions (3 / 42)
Info: Checked out v0.2.1 (original branch - 1ff46f09f4db8003c816432c16e718e59e00fdd7)
Info: Checked out v0.2.1 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.2.1
Info: Comparing versions (4 / 42)
Info: Checked out v0.2.2 (original branch - 68d96309bff2a7fc367dd51b0d5120dc09fc46c6)
Info: Checked out v0.2.2 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.2.2
Info: Comparing versions (5 / 42)
Info: Checked out v0.2.3 (original branch - fd85e3d47348e6c772116e368eca253075ea6c00)
Info: Checked out v0.2.3 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.2.3
Info: Comparing versions (6 / 42)
Info: Checked out v0.2.4 (original branch - ef717c03418840dedfdfc2d95edf950f67ec9e6a)
Info: Checked out v0.2.4 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.2.4
Info: Comparing versions (7 / 42)
Info: Checked out v0.2.5 (original branch - 57ec50a8551455c5102b2082a56f89676ffd9be6)
Info: Checked out v0.2.5 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.2.5
Info: Comparing versions (8 / 42)
Info: Checked out v0.2.6 (original branch - 64de2b24a7c11391683c6265ffcb1e00e9a88aec)
Info: Checked out v0.2.6 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.2.6
Info: Comparing versions (9 / 42)
Info: Checked out v0.2.7 (original branch - 830c6c17e611107b53e49cdac44da99bade4687f)
Info: Checked out v0.2.7 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.2.7
Info: Comparing versions (10 / 42)
Info: Checked out v0.2.8 (original branch - 430a33b9df0052b24bd170a0f291847035ddbd1c)
Info: Checked out v0.2.8 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.2.8
Info: Comparing versions (11 / 42)
Info: Checked out v0.2.9 (original branch - 204b8f5ca50c260c41a1c1f7f6cdedfcd7f64dfd)
Info: Checked out v0.2.9 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.2.9
Info: Comparing versions (12 / 42)
Info: Checked out v0.2.10 (original branch - 22e0d1d765c64c172377b340716910fda1c4aa37)
Info: Checked out v0.2.10 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.2.10
Info: Comparing versions (13 / 42)
Info: Checked out v0.2.11 (original branch - 78ab53fa5a042eb56ece795fb0a6a5b0aceca7a8)
Info: Checked out v0.2.11 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.2.11
Info: Comparing versions (14 / 42)
Info: Checked out v0.3.0 (original branch - 25013f809da85bc5c20995397d20d170626bdcc9)
Info: Checked out v0.3.0 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.3.0
Info: Comparing versions (15 / 42)
Info: Checked out v0.3.1 (original branch - 557b926e3c202616734dc4a9605253c72416231e)
Info: Checked out v0.3.1 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.3.1
Info: Comparing versions (16 / 42)
Info: Checked out v0.4.0 (original branch - 5221bf49ce227268b2e6868c6055f200c6321d4b)
Info: Checked out v0.4.0 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.4.0
Info: Comparing versions (17 / 42)
Info: Checked out v0.4.1 (original branch - 56e5668ad8ccdf4df4c3a7183d045772aef8f151)
Info: Checked out v0.4.1 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.4.1
Info: Comparing versions (18 / 42)
Info: Checked out v0.5.0 (original branch - 6d27e30d0603683f2927c106646a3690a4939626)
Info: Checked out v0.5.0 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.5.0
Info: Comparing versions (19 / 42)
Info: Checked out v0.5.1 (original branch - 6e659b7601cf107f6716315f52be03827e910599)
Info: Checked out v0.5.1 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.5.1
Info: Comparing versions (20 / 42)
Info: Checked out v0.5.2 (original branch - 05830063457ae54db000a3158000a8dec3239fe6)
Info: Checked out v0.5.2 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.5.2
Info: Comparing versions (21 / 42)
Info: Checked out v0.5.3 (original branch - 5bae25abc4ed878269bc8df9b679ccf42e235fd3)
Info: Checked out v0.5.3 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.5.3
Info: Comparing versions (22 / 42)
Info: Checked out v0.5.4 (original branch - e9021da46717379615be01eadfc4ccae97422441)
Info: Checked out v0.5.4 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.5.4
Info: Comparing versions (23 / 42)
Info: Checked out v0.5.5 (original branch - 953a54cff61ab2dfc560f7adcf304a249aede437)
Info: Checked out v0.5.5 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.5.5
Info: Comparing versions (24 / 42)
Info: Checked out v0.5.6 (original branch - 3571f630d2913c76a5eb05e0891b5a3c18c9ad25)
Info: Checked out v0.5.6 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.5.6
Info: Comparing versions (25 / 42)
Info: Checked out v0.5.7 (original branch - d322f9ac6d41fd39f738025cc8f789e28db04e26)
Info: Checked out v0.5.7 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.5.7
Info: Comparing versions (26 / 42)
Info: Checked out v0.5.8 (original branch - f1543e8da74309619da6d71b220528e14ff54671)
Info: Checked out v0.5.8 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.5.8
Info: Comparing versions (27 / 42)
Info: Checked out v0.5.9 (original branch - eaa19c6ed47930f6297692c6d0333d9442b9d336)
Info: Checked out v0.5.9 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.5.9
Info: Comparing versions (28 / 42)
Info: Checked out v0.5.10 (original branch - 89fd2602199ad99aec2216611d476b34667cf3d3)
Info: Checked out v0.5.10 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.5.10
Info: Comparing versions (29 / 42)
Info: Checked out v0.6.0 (original branch - 945cf1693de2bbaff6c3aa17775d4e67d5454239)
Info: Checked out v0.6.0 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.6.0
Info: Comparing versions (30 / 42)
Info: Checked out v0.6.1 (original branch - f16e763abe006002f7ebf0c295f6bb13a9923a18)
Info: Checked out v0.6.1 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.6.1
Info: Comparing versions (31 / 42)
Info: Checked out v0.6.2 (original branch - 2022a73303f6ba467c68d8b2660e64b21912a8cb)
Info: Checked out v0.6.2 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.6.2
Info: Comparing versions (32 / 42)
Info: Checked out v0.6.3 (original branch - c86cebcb47b8d3ff1d82dc179215f1d812893ed4)
Info: Checked out v0.6.3 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.6.3
Info: Comparing versions (33 / 42)
Info: Checked out v0.6.4 (original branch - d634cd5e5a3740eb838fefdc63fa8d0320c62419)
Info: Checked out v0.6.4 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.6.4
Info: Comparing versions (34 / 42)
Info: Checked out v0.6.5 (original branch - ca2b714b409686fedf01426533395408a3f48d39)
Info: Checked out v0.6.5 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.6.5
Info: Comparing versions (35 / 42)
Info: Checked out v0.7.0 (original branch - 36e98f7ee9c0ad96fd45d3289a1d2b931f0ae122)
Info: Checked out v0.7.0 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.7.0
Info: Comparing versions (36 / 42)
Info: Checked out v0.7.1 (original branch - 3d9d4203485ff4e41b0d82527ba14d4a009d39a8)
Info: Checked out v0.7.1 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.7.1
Info: Comparing versions (37 / 42)
Info: Checked out v0.7.2 (original branch - 495a8727a796871038c1adad5ffa9cab49f791a7)
Info: Checked out v0.7.2 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.7.2
Info: Comparing versions (38 / 42)
Info: Checked out v0.8.0 (original branch - f855592f8f073d749ad62301724b9b4ac22d2aa8)
Info: Checked out v0.8.0 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.8.0
Info: Comparing versions (39 / 42)
Info: Checked out v0.8.1 (original branch - e10b4533175aadcc5898afed0a623105a2605435)
Info: Checked out v0.8.1 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.8.1
Info: Comparing versions (40 / 42)
Info: Checked out v0.8.2 (original branch - 9d9fa2f6a35aace70c2b1e2f4d59adac72f94463)
Info: Checked out v0.8.2 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.8.2
Info: Comparing versions (41 / 42)
Info: Checked out v0.8.3 (original branch - 2c5d2994118ac803a87b44f0bd5ce21c5086f50e)
Info: Checked out v0.8.3 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.8.3
Info: Comparing versions (42 / 42)
Info: Checked out v0.8.4 (original branch - ba2af7d4639f8977b10dfde927bf4beaf727f9d4)
Info: Checked out v0.8.4 (rebased branch - <some SHA-1 hash>)
Info: branch releases are identical for v0.8.4

Migration (merging issues)

If you run into issues while attempting to merge your forked branch back into this rebased develop-new branch,
here are the steps you need to take to solve the issues:

  1. Backup your branch just in case something goes wrong
    • run git checkout <mybranch>; git checkout -b <mybranch-backup>; git checkout <mybranch>
      (if not already checked out)
  2. Update your branch / sync it with develop-old branch (either via rebase or merge)
  3. Rebase onto develop-new branch
    • run git rebase --onto develop-new develop-old
  4. That's it! Very simple & easy
  5. If you run into problems by any chance (highly unlikely), you could consider few alternatives
    • contact me (@carpetmaker), I can help you resolve it quickly, or do the migration / merge for you
    • git cherry-pick all of your commits (which haven't yet been merged into develop-old branch) into a new branch
      based off / branched (forked) from develop-new
    • export all of your unmerged commits (read above) with git format-patch and apply them to your newly created
      branch via git am (essentially the same as cherry-picking)

OFAQ (Opponent Frequently Asked Questions)

This section is meant for individual(s) who might oppose to the idea of this proposal,
and offers an alternative view in form of common answers for common questions you (or they) might ask.

  • Why rebasing?? My boss / co-worker / friend / cousin / joe / medium.com article told me that rebasing is bad?? We should never rebase, it is forbidden!

    Well, such a generalised statement assumes some level of ignorance from your end.
    Sure, if you are a dev who is just starting out and have an intern-level skills & experience, or are afraid of git,
    then yes, treating the git tool as a black box, and avoiding common sources of problems & complications,
    such as rebasing, might be a smart approach.
    But if you take your time to actually dive deeper into how git works,
    then there is no reason to be afraid of some more aggressive git tasks,
    as long as nothing breaks & all the existing constraints are satisfied.

  • Who cares?? Who cares about the git history, commit messages and branches organisation...

    Well, who cares about the version control at all? Why not just pack your code changes into a ZIP file,
    upload it to Google Drive and share the link to other devs who want to collaborate?
    Or even better, why not print out the new code which you wrote, pack it into an envelope / letter,
    and ship it via postal service or use a homing pigeon who will deliver it to other devs?
    We can go on and on like this... Same mentality, same level of ignorance, same answer.
    Projects which have ambitions for growing and want to onboard a lot of new contributors (which we hope for here)
    need a modern collaboration tools & approaches. Stricter order means less chaos, and more progress & advancement.

  • Changes are bad... I am afraid of changes, it will break my current and future commits!

    Is this really a question?
    Anyhow, if you have read this verbose & overly-explained proposal writeup up to this point,
    then you would've understood that nothing will actually break, and you won't have any problems merging your changes,
    or submitting new PRs in future.

Future Considerations

There are some minor additional items which should be considered in future.
For one, all the future contributions should continue to respect the conventions discussed in this proposal,
and improve the overall quality of project code & structure.
Another thing, there is some concrete room for a future improvement:

  • commit message length should be limited (open for discussion, might be too strict of a rule)
    • titles / subject lines should be no longer than 50 characters (currently, a limit of 100 is enforced)
    • body lines should be no longer than 72 characters each
  • commit messages should also utilise body which is separated from title by an empty line
    • either always or only when the commit message is too long to fit into a descriptive title (open for discussion)
  • commits should be formed in such a way to strictly contain only changes of a single particular topic: type:
    • feat
    • fix
    • test
    • refactor
    • perf
    • style
    • docs
    • build
    • chore
    • ci
    • revert
  • historical commits could be squashed into a single commit per version release, with their messages added to the body
  • all these conventions can and will be documented in a dedicated docs/CONTRIBUTING.md file

Conclusion

Pls just approve this proposal (and its associated PR) and let me take care of this stuff, I can handle it. Thx!

Outro

If any other contributor experiences issues with merging their work back to the repo (which is highly unlikely),
I am always available for one-on-one consultations, to help them resolve the issues without any trouble or pain.
But most likely, the problems won't even occur, or will be solved by running a single git rebase command
(git rebase --onto develop-new develop-old if you will) in the worst-case scenario. But I repeat, unlikely.

Thanks for taking your time to read this!


Sincerely,

@carpetmaker

Progress

This is a list of items which need to be performed:

  • rewrite barter-rs project git repo history
  • rewrite barter-data-rs project git repo history
  • rewrite barter-integration-rs project git repo history
  • rewrite barter-execution-rs project git repo history

Feature request: leverage

Features for futures market

  • Open oders (cross/isolated) (leverages) (sigle/multi-assets mode)
  • Liquidation
  • Increasing/decreasing margin size

for perpetual market

  • Paying funding fee

for delivery market

  • Closing on time to delivery

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.