* namespace convention for short-lived branches
@ 2015-04-20 16:20 Glenn Morris
2015-04-20 19:08 ` Stefan Monnier
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Glenn Morris @ 2015-04-20 16:20 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: namespace convention for short-lived branches
2015-04-20 16:20 namespace convention for short-lived branches Glenn Morris
@ 2015-04-20 19:08 ` Stefan Monnier
2015-04-21 11:04 ` Oleh Krehel
2015-04-20 19:40 ` Dmitry Gutov
2015-04-21 10:54 ` Phillip Lord
2 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2015-04-20 19:08 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: namespace convention for short-lived branches
2015-04-20 16:20 namespace convention for short-lived branches Glenn Morris
2015-04-20 19:08 ` Stefan Monnier
@ 2015-04-20 19:40 ` Dmitry Gutov
2015-04-22 17:56 ` Glenn Morris
2015-04-21 10:54 ` Phillip Lord
2 siblings, 1 reply; 13+ messages in thread
From: Dmitry Gutov @ 2015-04-20 19:40 UTC (permalink / raw
To: Glenn Morris, emacs-devel
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: namespace convention for short-lived branches
2015-04-20 16:20 namespace convention for short-lived branches Glenn Morris
2015-04-20 19:08 ` Stefan Monnier
2015-04-20 19:40 ` Dmitry Gutov
@ 2015-04-21 10:54 ` Phillip Lord
2015-04-21 11:38 ` Ted Zlatanov
2 siblings, 1 reply; 13+ messages in thread
From: Phillip Lord @ 2015-04-21 10:54 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: namespace convention for short-lived branches
2015-04-20 19:08 ` Stefan Monnier
@ 2015-04-21 11:04 ` Oleh Krehel
2015-04-21 14:12 ` Stefan Monnier
2015-04-21 19:00 ` Achim Gratz
0 siblings, 2 replies; 13+ messages in thread
From: Oleh Krehel @ 2015-04-21 11:04 UTC (permalink / raw
To: Stefan Monnier; +Cc: Glenn Morris, emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: namespace convention for short-lived branches
2015-04-21 10:54 ` Phillip Lord
@ 2015-04-21 11:38 ` Ted Zlatanov
0 siblings, 0 replies; 13+ messages in thread
From: Ted Zlatanov @ 2015-04-21 11:38 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: namespace convention for short-lived branches
2015-04-21 11:04 ` Oleh Krehel
@ 2015-04-21 14:12 ` Stefan Monnier
2015-04-21 19:00 ` Achim Gratz
1 sibling, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2015-04-21 14:12 UTC (permalink / raw
To: Oleh Krehel; +Cc: Glenn Morris, emacs-devel
> Renamed "fix-info-dups" to "scratch/fix-info-dups".
Thanks,
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: namespace convention for short-lived branches
2015-04-21 11:04 ` Oleh Krehel
2015-04-21 14:12 ` Stefan Monnier
@ 2015-04-21 19:00 ` Achim Gratz
2015-04-21 19:00 ` Oleh Krehel
1 sibling, 1 reply; 13+ messages in thread
From: Achim Gratz @ 2015-04-21 19:00 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: namespace convention for short-lived branches
2015-04-21 19:00 ` Achim Gratz
@ 2015-04-21 19:00 ` Oleh Krehel
2015-04-21 19:21 ` Achim Gratz
0 siblings, 1 reply; 13+ messages in thread
From: Oleh Krehel @ 2015-04-21 19:00 UTC (permalink / raw
To: Achim Gratz; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: namespace convention for short-lived branches
2015-04-21 19:00 ` Oleh Krehel
@ 2015-04-21 19:21 ` Achim Gratz
2015-04-21 19:26 ` Achim Gratz
0 siblings, 1 reply; 13+ messages in thread
From: Achim Gratz @ 2015-04-21 19:21 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: namespace convention for short-lived branches
2015-04-21 19:21 ` Achim Gratz
@ 2015-04-21 19:26 ` Achim Gratz
0 siblings, 0 replies; 13+ messages in thread
From: Achim Gratz @ 2015-04-21 19:26 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: namespace convention for short-lived branches
2015-04-20 19:40 ` Dmitry Gutov
@ 2015-04-22 17:56 ` Glenn Morris
2015-04-23 1:03 ` Dmitry Gutov
0 siblings, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2015-04-22 17:56 UTC (permalink / raw
To: Dmitry Gutov; +Cc: emacs-devel
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).
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: namespace convention for short-lived branches
2015-04-22 17:56 ` Glenn Morris
@ 2015-04-23 1:03 ` Dmitry Gutov
0 siblings, 0 replies; 13+ messages in thread
From: Dmitry Gutov @ 2015-04-23 1:03 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-04-23 1:03 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-04-20 16:20 namespace convention for short-lived branches Glenn Morris
2015-04-20 19:08 ` Stefan Monnier
2015-04-21 11:04 ` Oleh Krehel
2015-04-21 14:12 ` Stefan Monnier
2015-04-21 19:00 ` Achim Gratz
2015-04-21 19:00 ` Oleh Krehel
2015-04-21 19:21 ` Achim Gratz
2015-04-21 19:26 ` Achim Gratz
2015-04-20 19:40 ` Dmitry Gutov
2015-04-22 17:56 ` Glenn Morris
2015-04-23 1:03 ` Dmitry Gutov
2015-04-21 10:54 ` Phillip Lord
2015-04-21 11:38 ` Ted Zlatanov
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.