Re: One-command mail import with X-Seq: and ChangeLog

[Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:
> On Apr 5,  6:57pm, Frank Terbeck wrote:
[...]
> The one thing I'm finding missing from both places is a discussion of
> how to perform a simple one-file (well, two, counting ChangeLog) push
> directly from a clone of the master.  Can I --amend a commit without
> having a branch, or must I wait even to commit until I've edited the
> ChangeLog?  Or is creating a branch THE way, and I should ignore all
> the discussion of branching for "a feature" and just create a branch
> that's always there and use it repeatedly whenver I edit?

For most things people usually do, additional branches are _absolutely_
optional. People usually use them, because they are cheap to create and
easy to handle. But there's no requirement to use them at all.

You can do this if you like:

  - HACK HACK HACK
  - commit
  - format-patch/send-email
  - Get the X-Seq: number from the mail as it returns
  - Add a ChangeLog entry, however you like
  - "git add ChangeLog"
  - "git commit --amend" and put the X-Seq: Number in front for the
    commit message's first line
  - "git push"

This will work just fine. It might even be the way to go for trivial
changes, that you would commit as "unposted: ..." because you don't have
to do much of anything, except for adding a ChangeLog entry.

Here is one scenario, that might arise, when doing development directly
on master:

  - You got your changes on master
  - Someone else has their changes pushed in the meantime,
  - Your copy of master is outdated, and to regain linear history, you'd
    have to do "git pull --rebase"
  - If you already have added an entry to ChangeLog, you will definitely
    get a merge conflict while rebasing.

The easy way around this would be to "git pull --rebase" before adding
ChangeLog entries. If you don't do your development on master, you can
always just "git pull" while master is checked out locally and it will
trivially work because there are no changes on there. You can just
"zsh-am" your changes on top of it, if you like and then push.


You also asked, if "commit --amend" is possible on master. And the
answer is yes. "master" is in no way special to git, other than being
the default name it uses when creating a repository. There is one catch:
Do not amend commits you already pushed. Amending commits changes the
hash sum for the commit and people who already have the old version will
run into trouble if you change published history from under their feet.


As for the idea of a hacking branch: Yes, you can do that, too:

  - While having master checked out, do: git checkout -b bart/hack
  - That will create a new branch "bart/hack" and check it out.
  - You can now do all the things I lined out in README.org
  - Instead of removing the branch once you're finished you can also do
    this:
  - git reset --hard master

That will make "bart/hack" the same as the current master branch, ready
for you next development cycle.

> }   - Mark mails containing commits in MUA
> }   - Make MUA save those Mails into mbox file
> }   - Call: zsh-am the-mbox-file
>
> I think the first thing I'm going to do unless you beat me to it is to
> make zsh-am read patch emails from standard input ... it's just way too
> easy in e.g. Alpine to hit "|" rather than save the message.  I know
> a number of people send patches in several parts and want to commit
> them all at once, but far and away the most common thing is to want to
> operate on just one message.

Makes sense. I'm not sure how soon I can get onto it.

> (Aside: zsh-am is a bash script?  Horrors! :-)

Well, if your /bin/sh is bash, then you might call it that. It only uses
POSIX features, though, and will happily work with debian's `dash' shell
or some ksh flavour on other operating systems, as well. :-)

Regards, Frank