On Wed, Jun 25, 2014 at 10:42:49AM -0700, Junio C Hamano wrote:
> Nico Williams writes:
>
> > On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o wrote:
> > ...
> >> This seems pretty close to what we have with signed tags. When I send
> >> a pull request to Linus, I create a signed tag which create
Nico Williams writes:
> On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o wrote:
> ...
>> This seems pretty close to what we have with signed tags. When I send
>> a pull request to Linus, I create a signed tag which createscontains a
>> message about a set of commits, and this message is automatic
On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o wrote:
>
> On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
> >
> > Now, suppose that branches were objects. Then at push time one might
> > push with a message about the set of commits being pushed, and this
> > message (and time of pu
On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
>
> Now, suppose that branches were objects. Then at push time one might
> push with a message about the set of commits being pushed, and this
> message (and time of push, and pusher ID) would get recorded in the
> branch object. At
On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
> The Illumos repo, like OpenSolaris before it, and Solaris itself at
> Sun (and now at Oracle) requires that fixes be broken down into small
> commits, with related fixes, tests, and docs changes all typically in
> separate commits, bu
(thinking more about this, digesting Jonathan's response...)
The Illumos repo, like OpenSolaris before it, and Solaris itself at
Sun (and now at Oracle) requires that fixes be broken down into small
commits, with related fixes, tests, and docs changes all typically in
separate commits, but all pus
On Thu, Jun 19, 2014 at 06:01:47PM -0700, Jonathan Nieder wrote:
> > 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
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
>
Another thing is that branches as objects could store a lot more
information, like:
- the merge-base and HEAD for a rebase (and the --onto)
- the interactive rebase plan! (and diffs to what would have been
the non-interactive plan)
- the would-be no-op non-interactive rebase plan post rebase
On Thu, Jun 19, 2014 at 6:46 PM, Jonathan Nieder wrote:
> Nico Williams wrote:
>
>> - one could see the history of branches, including
>
> Interesting. 'git log -g' is good for getting that information
> locally, but the protocol doesn't have a way to get it from a remote
> server so you have to
Hi,
Nico Williams wrote:
> - one could see the history of branches, including
Interesting. 'git log -g' is good for getting that information
locally, but the protocol doesn't have a way to get it from a remote
server so you have to ssh in. Ronnie (cc-ed) and I were talking
recently about whet
[I'm a list newbie here, but a git power user.]
If branches were objects...
- one could see the history of branches, including
- how commits were grouped when pushed/pulled (push 5 commits, and
the branch object will record that its head moved by those five
commits at once)
- rebase history
12 matches
Mail list logo
