Re: Should branches be objects?

[Jonathan Nieder <jrnieder@gmail.com>]

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