Nico Williams n...@cryptonector.com writes:
On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o ty...@mit.edu 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,
On Wed, Jun 25, 2014 at 10:42:49AM -0700, Junio C Hamano wrote:
Nico Williams n...@cryptonector.com writes:
On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o ty...@mit.edu wrote:
...
This seems pretty close to what we have with signed tags. When I send
a pull request to Linus, I create a
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, but
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 Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o ty...@mit.edu 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
(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
[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
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
themselves, which is one thought that led
me to branches should be objects.
Another thought that led me there is that I often do:
$ 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
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
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
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 and
12 matches
Mail list logo
