Feature idea : notes to track status of a commit, which remotes it is shared to

Hi,

This is my first time on this list (and by the way, I'm not subscribed, so please Cc me to the replies). I have an idea that could be useful to make rewriting history safer and easier to new users (I'm training some of them). I thought I could share this idea, but perhaps someone already thought about it. And I'm not providing code.

The idea is to basically track automatically (in notes, either in the notes namespace or in another namespace) which repository/remote contains a commit. When doing git log, we'd see lines with each commit, something like:

commit b044e6d0f1a1782820b052348ab0db314e2db3ca
Author: Myself <myself@localhost.localdomain>
Date:   Tue Nov 20 16:46:38 2012 +0100

     This is the commit description

Published on:
     origin
     git@git.host.com:pub/repo.git

Then, we could have all the history rewriting commands (such as rebase or pull --rebase) die when rewriting commits that are already published anywhere. We could make an exception for a --force/-f flag or configuration option, or commits published in another local repository owned by the same user.

In most setups, it could be useful to tell users they can safely rebase without worrying about published commits as Git is tracking it for them. Of course this is not an absolute security, but it's a good start.

What do you think?

Mildred

Mildred Ki'Lya <mildred-ml@mildred.fr> writes:

The problem here is that doing this in notes is unreliable: you'd have to identify all places where the set of "publishes" can change for any commit, and update them there.

It's much easier, if a bit slower, to just run

  git branch -r --contains $commit

Thomas Rast <trast@student.ethz.ch> writes:

Unreliable you can fix with effort.

But I think a bigger problem is that it is a pointless "false economy" to attempt to record and try to maintain this note for each and every commit.

When you push out a tip of the branch to a new location, you would have to update notes to all commits from that tip down to where in the history to record that new location? To the root? Also your upstream may fetch from your published place and you may fetch it back (you will notice that now the commit appears in your 'origin'). Would you do the traversal and update all notes?

It is both much easier and cheaper to compute this on demand as you pointed out.

On Tue, Feb 19, 2013 at 10:38:09AM +0100, Mildred Ki'Lya wrote:

You might want to look into extending the sample pre-rebase hook, which prevents topic branches that are already merged to 'next' branch from getting rebased. You'd just have to loop over all remote references instead of only checking the local 'next' branch.

On Tue, Feb 19, 2013 at 11:13:19AM +0100, Thomas Rast wrote:

Ah, this would be better than looping in your hook ;).