Replies: 2 comments 5 replies
-
|
While I don't believe that this a currently available option, as an open source project there is no reason why you couldn't propose a patch (to upstream git - see their plain text mailing list) that would do what you desire. However, one has to ask "what is the defining reason for this particular distinction?". Having a clear reason to support the proposal is a core element of submission of patches process, along with a good name for the option. Don't let any concerns about Git being written in 'C' stop you having a go - the rationale will lead you! Do label your example to show that it's |
Beta Was this translation helpful? Give feedback.
-
|
The reason for this distinction is to solve branching hell as much as possible and not to use Squash as this option drops history.
Yes, ISSUE-222 and HOTFIX-333 were branches before (feature/one-small-commit and feature/one-small-hotfix) and they fast-forwarded into master. You can see the original branch names on the right (green boxes) |
Beta Was this translation helpful? Give feedback.
-
|
Hi, The rationale would need to explain what it is about one's process that need "to solve branching hell", and how that "branching hell" came about, and how that interacts with the "not to use Squash" choice. Sometimes what is observed is that certain 'old fashioned' (aka out of date) rules have been maintained by companies that create the problems they claim to solve (remembering that almost all version control methods were developed when everyone used pen, paper and tracings, i.e. pre-computers with it's perfect replication). Have a look at the branching structure used within the Git code base to compare and contrast the processes (yours and Git's) and where the important differences are located (where folks can't cope.. - that 'hell'' thing). Git is designed for an open distributed model of development, so there can be issues when it hits the closed, centralised, corporate control models of development, so a clarity of reason is required (or just add your own patches, rebase and recompile to provide the options you [your company?] need). |
Beta Was this translation helpful? Give feedback.
-
|
If we use squash we will lose some context and occasionally, we need multiple small features combined into one big feature. We would rather not mix it into one monolithic non-readable blob. For us, sometimes it is better to rebase something to make history more accurate than squash everything into one commit. Currently, there are only two merging strategies:
There we lost which commits contain ISSUE-111, HOTFIX-444 and if we need to roll back some feature we can't revert just one commit.
There we have extra merges for extra simple changes You need to juggle the parameters every time to have history without extra merges for simple changes and to use merges for complex features So, we prepared a small patch to add something like
|
Beta Was this translation helpful? Give feedback.
-
|
PR git#1599
|
Beta Was this translation helpful? Give feedback.
-
|
Wow, looks like that it is what I need exactly. 🤣 |
Beta Was this translation helpful? Give feedback.
-
|
Main thing is to explain what problem it solves, with background assumptions, and why it's a sensible option, with some tests (GGG PR # 1599 git#1599) That is @thenik, help @QuAzI with the explanation of what makes it good for you, how your teams get into situations that makes it a benefit, the less than perfect workarounds, traps and bad practices (i.e. a bit of judgement ;-) that others fall into, etc. Give it a bit of that soft-skill persuasion we are all so good at ;-) (Oh and be in for the long haul, expectations can be quite high) |
Beta Was this translation helpful? Give feedback.
-
Would it be possible to configure git to use fast-forward for merges only if the branch has one commit? In other way --no-ff should be used by default. As example, I want the next history
Beta Was this translation helpful? Give feedback.
All reactions