Conversation
@Foxboron @brauner can you describe what was "a bit weird"? Was it the cover letter requirement?
0
0
0
@Foxboron @brauner I understand. The biggest hurdle for me is how to make it simple to submit not just the initial patch, but also the inevitable v2, v3 etc -- because it's almost never the case that your first patch submission is accepted as-is. So, we need a place to track the patch history, and preferably in the way that can be pushed to the remote repo.
0
0
0
@Foxboron @brauner Unfortunately, git notes is a bad solution here: 1) they don't survive rebases (because they are tied to the commit hash), and 2) they don't get pushed to the remote unless you remember to push the notes ref.
0
0
1
@Foxboron @brauner There may be other options in the future. Git folks suggested using a merge commit for this purpose (the parent commit of the series and the last patch of the series), but it can't work until some upstream changes in git.

See:
https://lore.kernel.org/git/20220721182645.45xrwf2buohibcaw@meerkat.local/
https://lore.kernel.org/git/20220721191349.kf3zx4tpwrjhzudt@nitro.local/
0
0
0
@javierm @Foxboron @brauner I'm quite familiar with patman and my goal isn't to compete with it -- if it works for you, then you should use it! My goal with b4 is to simplify the workflow for first-time and occasional contributors without making the process centralized or dependent on a single point of failure. Patman is powerful and robust, but it's not something I can give to newcomers and say "just do this."
0
0
1
@brauner @Foxboron I'm curious about your experience with notes and rebases. When you have notes on your commits and your rebase your series on a newer -rc, don't you frequently lose notes, or is git now properly updating all your notes refs when the commits they are associated with change?
0
0
1
@Foxboron @brauner I'm afraid that would be too fragile. I am deliberately avoiding any kind of clever magic that would make b4 a required part of the process. If a user re-clones their repo or blows away a part of their git config, I don't want them to wonder what happened to their content. This is why I keep the cover letter so bluntly in the branch at the start of the series -- it will survive any changes to the local repository or to the config file and it doesn't interfere with regular git work or git-format-patch.

I know that this is not how a lot of people's workflow goes, but my goal isn't to support all possible workflows, but to design a straightforward and resilient workflow that would be easy to understand for end-users -- especially newbies. It's proving really difficult precisely because everyone is so used to their own way of doing things and want b4 to slot nicely into it.
1
0
2
@brauner @Foxboron I'm surprised that git-filter-repo isn't doing this already when it finds a rewriteRef configured. I'll have to talk to the upstream about what they recommend. I shouldn't have to do anything manually in b4.
0
0
0
@Foxboron @brauner Sorry, the last part came off grumpy, but it wasn't meant to be -- I intended it to be just a statement of known limitations (by design).
0
0
0