> I understand most of what you said except: > > But use the rebase/editing on the feature development branch to make that look clean (not to hide your mistakes, but to make it easier to understand and bug fix later),
Second guessing the parts that need explaining .... Part of the original idea for the "rebase" for the Linux code base, particularly the `-i` --interactive mode, is the ability to edit, correct and polish your patches (commits) so that what gets recorded in the formal project history is each of the small well formed steps of development. This is so that maintenance phase (bug fixing) can proceed smoothly and easily, no matter who is looking at the history. Unfortunately (speaking as an old person;-) the proliferation of computer storage means many think we should record every key and pencil stroke, because because we can (or none at all). Just as we will use an eraser on a pencil sketch before we finalise a drawing, we should do the same with our commits (neat and tidy submitted work, like a freshly prepared melon, ready to eat). The tricky bit is we aren't taught formal writing of commits (try looking at the git SubmittingPatches file, search for "imperative") https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L47 "Make separate commits for logically separate changes" https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L111 " Describe your changes well" Definitely worth a read! On Thursday, January 27, 2022 at 2:59:46 PM UTC [email protected] wrote: > I understand most of what you said except: > > But use the rebase/editing on the feature development branch to make > that look clean (not to hide your mistakes, but to make it easier to > understand and bug fix later), > > Thanks for the reply! > On Thursday, January 27, 2022 at 8:24:37 PM UTC+5:30 [email protected] > wrote: > >> Use --first-parent log/show when looking at your history to get that >> clean "+1 feature" view. >> But use the rebase/editing on the feature development branch to make that >> look clean (not to hide your mistakes, but to make it easier to understand >> and bug fix later), >> and then merge with --no-ff set, adding a full commit message describing >> the feature (for the --first-parent log). >> >> This gives best of both worlds. You have a clean feature add view, and >> clean details for feature debugging (and if you have even a small amount of >> 'test driven bug fixing' ;-) then you can also use `git bisect` to locate >> (automatic) the _small_ detail commit that introduced the bug that fails >> the test. >> >> Your one remaining choice is whether to keep rebasing features to the >> clean tip of main, or keep them as starting from the original start point >> (depends on how you manage the 'conflicts' during feature dev) >> >> On Thursday, January 27, 2022 at 6:20:50 AM UTC [email protected] >> wrote: >> >>> Even if a branch and a commit bundle occupy the same amount of space, in >>> my opinion, commit bundles would appear much cleaner which is the whole >>> point of this anyways. >>> >>> Thanks >>> On Thursday, January 27, 2022 at 11:30:58 AM UTC+5:30 Tassilo Horn wrote: >>> >>>> Shreyans Jain <[email protected]> writes: >>>> >>>> Hi, >>>> >>>> > So I had an idea if git could have a feature that allows you to >>>> squash >>>> > commits into a commit bundle which keeps the commit history clean >>>> > while still maintaining a lot of the important verbose commit >>>> > history. Just wanted some comments on this from the community. >>>> >>>> I think that would create the need for a lot of changes in many places. >>>> But you can achieve what you want with what's there already. Say you >>>> develop a feature on a branch features/feature-x which you push to >>>> origin/features/feature-x. When you are done, you squash the commits on >>>> features/feature-x (but don't push), add a note >>>> >>>> For dev history, see branch features/feature-x. >>>> >>>> to the commit message, and finally merge features/feature-x (not >>>> origin/features/feature-x) into main or wherever it should be. >>>> >>>> Maybe it would be a good convention to rename the branch so that it is >>>> immediately distinguishable from active branches, e.g., to >>>> history/features/feature-x (and then link that in the squash commit's >>>> message). >>>> >>>> Bye, >>>> Tassilo >>>> >>> -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/ff243759-7db2-462c-a03b-16d6b378b836n%40googlegroups.com.
