Hi Wookey and all,
Quoting Wookey (2024-04-09 18:52:43)
> On 2024-04-08 21:44 +0900, Simon Richter wrote:
> > Testing a package requires me to commit everything into git first, so I
> > have to remember to squash all these commits later.
> 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.
if what I want to do is more complicated, what I do is indeed to create a stack
of commits which I squash in the end. I see this as a feature because it allows
me to always go back to an earlier stage of my changes. If the code is complex
I'm unable to keep in my head what I changed when and why. I use git commits to
keep track of that as I work towards the final result. Because every meaningful
change is in a git commit I can always go back to an earlier stage if it turns
out I messed something up. Yes, running "git add ... && git commit" is overhead
but I in my experience I waste more time with forgetting what file I changed
how the last time I tested something than with running these git commands.
> 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...
I manage these "piles of changes" in git branches and oftentimes, those
branches end up as "merge requests" against another repo or my own repo. By
doing it like that I not only allow others to see my work and potentially
contribute as I'm working on it but I also keep a record of all the stuff I'm
working on for future-me as I come back to work on a bug or feature. The extra
data I am storing in git commit messages, that extra work, allows me to
organize myself so it helps me even assuming that nobody else is contributing.
> I realise this (like my previous message) will result in a load of people
> telling me git _is_ better and I'm just doing it wrong, or should learn
> better tools. And they may even be right, (and I will probably learn some
> things from this thread), but I don't believe the goal we agree on (fixing
> other people's packages should be culturally accepted) _requires_ this change
> in tooling (which is a heavy cost for at least some of us).
Personally, I think the project would be better off with more standardization
of our workflows. The more different workflows we have, the harder it is to
make archive-wide changes or for newcomers to learn the ropes. Speaking of
newcomers: if I talk to my students, then for them, using git and workflows
involving branches, tags and pull/merge requests is natural to them. So one can
also argue the other way round and say: we deter younger contributors by not
embracing the git workflow more.
Sadly, there is probably no way to make everybody happy. I'd also not like to
force you to switch your workflows. Of course ideally, I'd like to convince you
that embracing git for packaging not only helps others but can also help you.
:)
> Also what do you git people do to replace uscan? Currently I go to my
> existing version, or a newly-acquired apt get or dget source. I do 'uscan'
> and if there is a new upstream version I have a nice separate directly that
> is easy to dirdiff (then fixup any packaging and dupload). If there isn't I
> can move on.
Personally, I run:
$ uscan --verbose
$ gbp import-orig ../source.orig.tar.gz
> And I do just prefer having two directories rather than multiple
> version on top of each other. My simple brain finds it a lot easier to
> keep track of a version directory to diff between, rather than finding
> the right runes to get git to give meld faked-up directories pointing
> at revisions or branches.
I found this paragraph really interesting because reading your other emails I
was wondering "well but how else do you do it then??" :D Maybe this is just
muscle memory? Your directories are just my git branches. Instead of "cd
../source-verX" I'd do "git switch verX". Personally, I find git branches
superior to directories because the git commit messages in each branch allow me
to describe what this feature-branch is doing much better than a directory name
could. A stack of commits in a branch allows me to trace back what changes I
did in what order when I worked on a feature. By pushing the branches to salsa,
I enable collaboration on my work by doing not much more than running "git push
--set-upstream origin myfeature".
> I do understand the argument that lots of different workflows adds friction.
> But I'm just still using what used to be _the_ standard one (insofar as we
> ever had such a thing). Putting everything in salsa/git doesn't standardise
> workflows in itself. I think Ian/Sean identified 12 different git-based
> methods in their dgit review.
Yes: https://wiki.debian.org/GitPackagingSurvey
> Josch's suggestion that just recording the workflow in metadata would be
> useful is a good one. Then at least you know what other maintainers are
> doing. And dgit's approach of unifying the archive representation and the git
> representation is definitely progress in the right direction. I was very sad
> to find that it didn't help us 'tarball people' directly at all (except I
> guess to reduce exactly this pressure to stop doing it and use git).
>
> So why mandate salsa rather than make dgit more official? That lets the
> people that want to use git use it for everything - even the packages that
> were just uploaded as tarballs. And explicitly _doesn't_ remove the archive
> VCS interface. And it supports all the git-based workflows. (someone should
> probably tell IWJ this conversation is occuring as he's taken a bit
> intererest in it, but no longer reads debian-devel). Does than not solve a
> good chunk of this 'make it easy to fix other packages using your standard
> tools' desire?
Personally, I'd not like to *mandate* git or salsa or whatnot. What I'd
personally like to see would be one standard documented default workflow. I
think that'd already get us a long way into easier collaboration. It would not
even need to be an instance of https://xkcd.com/927/ (Standards). Just pick one
established workflow, deem it *the thing*, document it and call it a day.
Personally I don't care which of the above 12 workflows is picked. I rather
prefer to use the thing that everybody else is using than doing what I *hope*
is familiar for others...
Thanks!
cheers, joschAttachment:
signature.asc
Description: signature