Re: Should branches be objects?

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jun 20, 2014, 01:01 UTC
Message-ID: <20140620010147.GZ8557@google.com>
In-Reply-To: <CAK3OfOjnYXxhWT7Vp-0Pcb=F8ze6wJnqSm1_LW0Zp1FmYZfUEg@mail.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?

[...]

Show 13 quoted lines

> $ 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}'?

[...]

Show 6 quoted lines

>>>  - 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