[kgb-maintainers] Bug#698133: Bug#698133: kgb-client: Should not resend the whole history when pushing branches with content merged from other branches

[Raphael Hertzog]

Hi,

On Mon, 14 Jan 2013, Damyan Ivanov wrote:
> Unless both branches are being pushed in which case we lose the commit 
> as it is always present in another branch at the time the hook is 
> invoked.

Right, you still have the possibility to read the whole input and use that
information to update your knowledge of where things used to point before
the push.

> > It's not to difficult to implement. git-commit-notice on alioth 
> > already has some logic to prevent this in the "report by mail" case. 
> > You can check it out if you want.
> 
> My attempts are towards reworking the current logic by using 
> git-rev-list, which avoids reporting commits twice nicely. The hard 
> thing seems to be tracking which branch each commit was made to.

Why does it matter which branch a commit was made to? What matters is
where it appears first when it's pushed.

The code used to find out which commits can be reported is (to be run for
each updated branch).

git rev-parse --not --branches | grep -v $(git rev-parse $refname) | \
    git rev-list --stdin $oldrev..$newrev

Now if you really care about the case where a new commit is pushed to
two refs at the same time, then you can replace the initial "git rev-parse
--not --branches" by something of your own where you put those values
except that you substitute any updated commit by its former value.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/