what's the purpose of a commit?

[samuelstroschein]

Research question

What's the one job a commit fulfills across different user groups and workflows?

Context

Internal testing revealed that commits are used for different things:

• not overwriting changes ("festhalten von änderungen")
• reviewing
• descriptions for changes

Already planned changes

Based on the insights above, we already concluded that we should:

• Reviewing could be a separate "mark as reviewed" feature
• Descriptions for changes will be unbundled from commits (every change will have an optional thread. no need to commit to describe changes)

[samuelstroschein]

@niklas.buchfink @nils.jacobsen let's use this issue to share your findings.

[samuelstroschein]

Side note: The value of commits as concept to express "this is the main/fixed history" is further diminished once LIXDK-126 is introduced.

• a branch e.g. main can be modeled as "this is the main/history"
• every change has to go through a change proposal
• every accepted change lands on main

Understanding the Impact of Branching on Commit History

[samuelstroschein]

Freezing this discussion until LIXDK-126, LIXDK-147 and LIXDK-115 is implemented.

• all three will influence the perception of a commit
• the result might be that no commit is needed
• if a commit is desired, i have a solution that potentially unlocks many other use cases. more to be shared after implementing the three issues (hint: tags)

[NilsJacobsen]

Thoughts:

• Like the branch - main workflow
• You are right commits are not needed when looking on merging
• I wouldn't say we don't need commits -> it groups changes to be consumable. If we only rely on changes for history that would be a huge list of changes instantly or we force apps to deal with debouncing this. (Which I kinda don't like)

[NiklasBuchfink]

I see many upsides:

• commits are removed (simplification)
• one source of truth with main and the history
• one unified workflow (create branch -> add change -> preview -> change proposal -> merge)

The downside might be:

• getting the typo fix "live" requires a speedrun through the workflow

[NiklasBuchfink]

I also see @nils.jacobsen last point, that we need to find a way to have a useful change history with unmutable changes that is not on key stroke.

[samuelstroschein]

Having a useful change history seems to boil down to filters. One filter could be "committed" but so could "reviewed", "machine translated", etc. be filters.

Let's wait for branching, discussions, and merge preview to be implemented. Afterwards, we look at commits again :)

[samuelstroschein]

@jan.johannes yes, let's close the commit discussion and see how far we get without commits. thanks for taking the initiative