Nico Williams wrote:
> a) reflogs include information about what's done to the workspace
> (checkout...) that's not relevant to any branch,
Nope, reflogs just record changes to refs and information about why
they happened.
> b) reflogs aren't objects, which ISTM has caused transactional issued
> (even if they are fixed or soon to be),
Not sure I understand. Do you mean that if reflogs were named by their
content then they wouldn't need to be renamed when a ref is renamed?
Or are you referring to some other atomicity issue?
[...]
> $ git checkout -b ${branch}-rebase1
> $ git rebase -i master
> ...
> $ git checkout -b ${branch}-rebase2
> $ git rebase -i master
> ...
>
> I iterate through this until a set of commits is the way the upstream wants it.
>
> No one really needs that history, except me: possibly to show my
> boss/customer, possibly to put together a list of changes I've done to
> show the upstream maintainer, ... Yes, this is in the reflog, but...
> it's mixed up with unrelated stuff.
Yes, this isn't something we do well at all. It would be nice to have a
tool that can take two versions of a branch (from different refs, taken
from the reflog, or whatever) and visually represent what happened to
corresponding commits.
Thomas Rast started work on such a thing called tbdiff, which you can
find at https://github.com/trast/tbdiff.
[...]
> Also, I'd like to be able to git diff
> <branch-version>..<same-branch-diff-branch-version>. Again, for my
> own purposes in collating changes I've done to previously submitted
> PRs.
Do you mean 'git diff mybranch mybranch@{3}' /
'git diff <mybranch> <mybranch>@{3.days.ago}'?
[...]
>>> - object transactional APIs would be used to update branches
>>
>> Ronnie's recent ref-transaction code does this.
>
> Speaking of which: are there any power failure corruption cases left
> in git? How is this tested?
What kind of power failure corruption are you talking about? Git
usually updates files by writing a completely new file and then
renaming it into place, so depending on your filesystem this means it
is very hard or very easy to lose data with a power failure. :)
If you're on one of those filesystems where it is very easy and you
lose power a lot, you'll probably want to enable the
core.fsyncobjectfiles configuration option. It might be worth adding
another knob like that for the other files git writes if someone is
interested.
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html