On Tue, Apr 09, 2024 at 05:52:43PM +0100, Wookey wrote: > Right - this was (one of the) main thing(s) that annoyed me enough to > just go back to the non-git based workflow. I want to make changes and > try them. I don't want to have to commit every damn time - it's not > done yet - I'll commit it after I'm satisfied that it works. But I > don't know that until I've made a whole set of changes and it builds. > > So now I've got a pile of changes which should really be separate > commits and logically separate things often affect the same files, and > even the same lines, so really I need to commit some chunks and not > others and tidy it all up. Yes this makes a nice set of commits but > it's _so_ much work in comparison to just editing the damn files, and > then effectively doing one fat 'commit' when I dupload. Often > something ends up stalled for weeks or months or years because I've > got some chunks in the wrong places and sorting it out is painful, so > I go do something else and lose all my state. You all know how that > goes... Again, you don't need to commit anything to test it, so you can use whatever commit style is fine, including one fat commit before dupload. You may mean that doing this provides no benefit over not using git, which isn't really true. > Also what do you git people do to replace uscan? gbp import-orig --uscan > git world seems to make this way more complicated. I have to set up > two different repos - one for salsa one for upstream, then pull them, > maybe into different branches, and fight the diff config to let me > dirdiff two different commits. And the upstream pull will always pull > changes, not just only do it is there is an actual release (tag). You don't need to do that, you can't do that with upstreams that don't use git and some (probably all?) teams forbid that. -- WBR, wRAR
Attachment:
signature.asc
Description: PGP signature