namespace convention for short-lived branches

namespace convention for short-lived branches

[Glenn Morris]

Hi,

I'm really not interested in all these tiny, short-lived branches that
people seem to like to push to savannah.gnu.org (recently map,
fix-info-dups, etc). The thing that sends out mails to emacs-diffs isn't
configurable per-branch (unlike the bzr one), so they all get mailed
out. I suppose I could (in my Gnus) score down every mail on that list,
and score up "master", but I'd appreciate it if people would use a
standard namespace for such branches. Some people use "scratch/", which
seems sensible to me. (But there's also one "fix/" and one "feature/" ...)

TIA.

Re: namespace convention for short-lived branches

[Stefan Monnier]

> standard namespace for such branches. Some people use "scratch/", which
> seems sensible to me. (But there's also one "fix/" and one "feature/" ...)

Agreed, we should push people to use "scratch/" more systematically.


        Stefan

Re: namespace convention for short-lived branches

[Dmitry Gutov]

On 04/20/2015 07:20 PM, Glenn Morris wrote:
> I suppose I could (in my Gnus) score down every mail on that list,
> and score up "master", but I'd appreciate it if people would use a
> standard namespace for such branches. Some people use "scratch/", which
> seems sensible to me. (But there's also one "fix/" and one "feature/" ...)

I think scratch/ prefix was designated for short-lived branches, later 
to be amended and/or rebased.

If the branch contents are simply merged, will the mailed send out the 
contents of every commit therein again?

Re: namespace convention for short-lived branches

[Phillip Lord]

Glenn Morris <rgm@gnu.org> writes:
> Some people use "scratch/", which seems sensible to me. (But there's
> also one "fix/" and one "feature/" ...)


"fix" and "feature" are after gitflow, which is how they got there, but
I think "scratch" was the final decision.

The fix/ branch was me; as it's going to take me a long time to finish,
I've removed it.

Phil

Re: namespace convention for short-lived branches

[Oleh Krehel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> standard namespace for such branches. Some people use "scratch/", which
>> seems sensible to me. (But there's also one "fix/" and one "feature/" ...)
>
> Agreed, we should push people to use "scratch/" more systematically.

Renamed "fix-info-dups" to "scratch/fix-info-dups".

Oleh

Re: namespace convention for short-lived branches

[Ted Zlatanov]

On Tue, 21 Apr 2015 11:54:17 +0100 phillip.lord@newcastle.ac.uk (Phillip Lord) wrote: 

PL> Glenn Morris <rgm@gnu.org> writes:
>> Some people use "scratch/", which seems sensible to me. (But there's
>> also one "fix/" and one "feature/" ...)

PL> "fix" and "feature" are after gitflow, which is how they got there, but
PL> I think "scratch" was the final decision.

PL> The fix/ branch was me; as it's going to take me a long time to finish,
PL> I've removed it.

I've removed one `feature' branch too. Please let us know what other
existing branches don't match the conventions so we can remove or rename
them.

Ted

Re: namespace convention for short-lived branches

[Stefan Monnier]

> Renamed "fix-info-dups" to "scratch/fix-info-dups".

Thanks,


        Stefan

Re: namespace convention for short-lived branches

[Achim Gratz]

Oleh Krehel writes:
> Renamed "fix-info-dups" to "scratch/fix-info-dups".

I think you've created a new branch scratch/fix-info-dups, but left the
abandoned fix-info-dups in place.  To delete a branch in upstream you
need to push "nothing" onto the old branch, maybe like this:

git push origin :fix-info-dups


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: namespace convention for short-lived branches

[Oleh Krehel]

Achim Gratz <Stromeko@nexgo.de> writes:

> Oleh Krehel writes:
>> Renamed "fix-info-dups" to "scratch/fix-info-dups".
>
> I think you've created a new branch scratch/fix-info-dups, but left the
> abandoned fix-info-dups in place.  To delete a branch in upstream you
> need to push "nothing" onto the old branch, maybe like this:
>
> git push origin :fix-info-dups

I'm pretty sure I've deleted it with magit. I doesn't show up on my
system any more. Did you "git pull" on your end?

Oleh

Re: namespace convention for short-lived branches

[Achim Gratz]

Oleh Krehel writes:
> I'm pretty sure I've deleted it with magit.

Yes, I see it now.

> I doesn't show up on my
> system any more. Did you "git pull" on your end?

Yes.  I simply threw away the whole refs/origin directory and updated
the remote again, now it's clean.  I'll have to check how to get rid of
branches deleted upstream properly one of these days.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: namespace convention for short-lived branches

[Achim Gratz]

Achim Gratz writes:
> Yes.  I simply threw away the whole refs/origin directory and updated
> the remote again, now it's clean.  I'll have to check how to get rid of
> branches deleted upstream properly one of these days.

Or today.  It's either/or:

git fetch -p origin
git remote prune origin

depending on the version of Git and assuming you've kept the default
name of the upstream remote.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: namespace convention for short-lived branches

[Glenn Morris]

Dmitry Gutov wrote:

> If the branch contents are simply merged, will the mailed send out the
> contents of every commit therein again?

Well, AFAICS it sends out the relevant information that I think it should?
That's why I'm personally not interested in seeing the diffs for
"work-in-progress" branches. I'll read them when/if they go to master.

You can verify this by looking at the mails that come about when
emacs-24 is merged to trunk, eg:

http://lists.gnu.org/archive/html/emacs-diffs/2015-03/msg00037.html

There have been no complaints so far.


At the risk of opening the chat-about-git-floodgates again, this prompts
me to ask: is there a setting that will make such merge mails better?
I'm using

log --format=full -C --stat -p -m --first-parent

I'm a simple-minded person who just wants to see
"difference between master before this change was applied and after it
was applied"

Sometimes the diffs don't seem to make sense. Eg in

  http://lists.gnu.org/archive/html/emacs-diffs/2015-03/msg00040.html

The NEWS diff is completely bogus AFAICS (the NEWS file in emacs-24
merges to NEWS.24 in trunk).

Re: namespace convention for short-lived branches

[Dmitry Gutov]

On 04/22/2015 08:56 PM, Glenn Morris wrote:

> You can verify this by looking at the mails that come about when
> emacs-24 is merged to trunk, eg:
>
> http://lists.gnu.org/archive/html/emacs-diffs/2015-03/msg00037.html
>
> There have been no complaints so far.

Like I thought, it's only showing the new commits (the merge commits in 
this case, both the "meaty" and "skipping" ones).

While it seems like the emails contain all the changes (squished 
together, which might appeal to people used to Bazaar's merges), you 
don't see the merged commits' messages (only their first lines).

And while in merges from emacs-24 you see the ChangeLog changes now, as 
soon as they're auto-generated there too, that will change. I'm not sure 
we want to include the full message of each commit inside the merge 
commit's message (which would be a way to fix that).

> At the risk of opening the chat-about-git-floodgates again, this prompts
> me to ask: is there a setting that will make such merge mails better?
> I'm using
>
> log --format=full -C --stat -p -m --first-parent
>
> I'm a simple-minded person who just wants to see
> "difference between master before this change was applied and after it
> was applied"

Yup, it seems you're already aware of what I described above.

> Sometimes the diffs don't seem to make sense. Eg in
>
>    http://lists.gnu.org/archive/html/emacs-diffs/2015-03/msg00040.html
>
> The NEWS diff is completely bogus AFAICS (the NEWS file in emacs-24
> merges to NEWS.24 in trunk).

I believe that some of the edits there were done by hand, to resolve the 
conflicts. And some of NEWS entries were moved to NEWS.24 in a later 
merge commit, 98284ef.

So it seems correct.