* Access to CVS @ 2012-12-04 22:32 Vin Shelton 2012-12-04 22:51 ` Phil Pennock 0 siblings, 1 reply; 60+ messages in thread From: Vin Shelton @ 2012-12-04 22:32 UTC (permalink / raw) To: zsh-workers Can anyone access zsh.cvs.sourceforge.net? I'm seeing: cvs [update aborted]: reading from server: Connection reset by peer when I try to do a cvs update. Regards, Vin ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-04 22:32 Access to CVS Vin Shelton @ 2012-12-04 22:51 ` Phil Pennock 2012-12-05 0:33 ` Oliver Kiddle 2012-12-05 2:26 ` Vin Shelton 0 siblings, 2 replies; 60+ messages in thread From: Phil Pennock @ 2012-12-04 22:51 UTC (permalink / raw) To: Vin Shelton; +Cc: zsh-workers On 2012-12-04 at 17:32 -0500, Vin Shelton wrote: > Can anyone access zsh.cvs.sourceforge.net? I'm seeing: > > cvs [update aborted]: reading from server: Connection reset by peer > > when I try to do a cvs update. Works with :ext: stuff such that it's going over SSH. The rsync interface for cloning the CVS tree is working fine. My local copy of the tree is intact and updates fine. (It does so via cron, normally, but I just forced a zsh-specific verbose run and rsync ran without issues). Perhaps the CVS-on-wire protocol server has issues; can you switch to SSH-based access? (zsh is about the only thing I still use CVS for; FWIW, if folks do ever decide to switch, I don't much care which DVCS is chosen (git, hg, whatever) but would appreciate such a switch. Any hope of the git mirror becoming the official master repo?) -Phil ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-04 22:51 ` Phil Pennock @ 2012-12-05 0:33 ` Oliver Kiddle 2012-12-05 3:14 ` Phil Pennock 2012-12-05 2:26 ` Vin Shelton 1 sibling, 1 reply; 60+ messages in thread From: Oliver Kiddle @ 2012-12-05 0:33 UTC (permalink / raw) To: zsh-workers Phil Pennock wrote: > (zsh is about the only thing I still use CVS for; FWIW, if folks do ever > decide to switch, I don't much care which DVCS is chosen (git, hg, > whatever) but would appreciate such a switch. Any hope of the git > mirror becoming the official master repo?) I gather that the current status is that we just need a git expert willing to take the lead on that. There's also a couple of things that need sorting out: Associating commits to mailing list numbers. This amounts to using git notes (see workers/30123) so probably just needs a clear convention. Perhaps we could use a hook script to enforce it on the master repository. Generating the patch level some other way. Using the git hash (or first eight characters of it) would be easy enough but you would lose the ability to compare patch levels and assert which is newer or older. I don't think there is much we can do about that. While git sort-of supports $Id$ style strings it seems that isn't what we should do. For some ideas on what git people appear to recommend, see: http://stackoverflow.com/questions/1792838/enable-ident-string-for-git-repos http://git.kernel.org/?p=git/git.git;a=blob;f=GIT-VERSION-GEN;hb=HEAD Does anyone have any idea whether sourceforge makes it easy for an individual to publish forked/cloned git repositories in the manner of github or bitbucket? Or is it better to just keep development branches/threads in the main repository. Oliver ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-05 0:33 ` Oliver Kiddle @ 2012-12-05 3:14 ` Phil Pennock 2012-12-05 9:40 ` Bart Schaefer 0 siblings, 1 reply; 60+ messages in thread From: Phil Pennock @ 2012-12-05 3:14 UTC (permalink / raw) To: Oliver Kiddle; +Cc: zsh-workers On 2012-12-05 at 01:33 +0100, Oliver Kiddle wrote: > Phil Pennock wrote: > > (zsh is about the only thing I still use CVS for; FWIW, if folks do ever > > decide to switch, I don't much care which DVCS is chosen (git, hg, > > whatever) but would appreciate such a switch. Any hope of the git > > mirror becoming the official master repo?) > > I gather that the current status is that we just need a git expert > willing to take the lead on that. > > There's also a couple of things that need sorting out: > > Associating commits to mailing list numbers. This amounts to using git > notes (see workers/30123) so probably just needs a clear convention. > Perhaps we could use a hook script to enforce it on the master > repository. Biggest problem is if the change in the mail doesn't exactly match the files being patched, in which case there's not identifying information in the mail to figure out the commit. If the person grabbing the patch uses "git note" manually, or as a filter to grab X-Seq, then it works. *If* the patch in the mail is cleanly applying to the exact same files, then you can use a cron job, taking recent mails from zsh-workers, so that there's as much decoupling as possible, and zsh-workers vs git-commit ordering doesn't matter. Taking a git patch from an email and turning it into full blobs of the new version of a file (ie, the id of the new content): cat mail-file | \ pcregrep -o1 -M '^index\s+[0-9A-Fa-f]+\.\.([0-9A-Fa-f]{6,})\s\d+\r?\n--- a/' \ | git cat-file --batch-check Output is lines of "${checksum-id} blob ${blobsize}" Use with: https://github.com/jwiegley/git-scripts/blob/master/git-find-blob and find the earliest commit id where a tree referenced the blobs from the mail. It's horrendously inefficient, but if you're constraining it to --since="5 days ago" to allow for maximum discrepancy, then you've bounded the O(N^2) to very small values of N. Scenario 1 (rarer): * commit, then mail out the patch to say "er, I did this" * mail is processed, finds the commit, you have five days to get around to mailing Scenario 2: * mail out, then commit. The mail is held until successfully matched. Once the commit is made, the mail is deleted. The cronjob presumably runs every hour or so, thus --since="5 days ago" is about 4days23hrs generous Scenario 3: * no git diffs in the mail; log that nothing found for that X-Seq:, delete Ickiest bit is the reporting for mails older than a week which haven't been matched, and the commits without the note. That requires HTML skills to make the pretty web-page people want when tracking down what got lost. ;) > Generating the patch level some other way. Using the git hash (or There's what we do in Exim: http://git.exim.org/exim.git/blob/HEAD:/src/scripts/reversion around line 40. I can't commit time for a _project_ to complete any of this until some time next year. Sorry. :( Folks are still waiting on revamped regex/multibyte-counting fixes from me. :( -Phil ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-05 3:14 ` Phil Pennock @ 2012-12-05 9:40 ` Bart Schaefer 2012-12-05 11:26 ` Phil Pennock 0 siblings, 1 reply; 60+ messages in thread From: Bart Schaefer @ 2012-12-05 9:40 UTC (permalink / raw) To: zsh-workers On Dec 4, 10:14pm, Phil Pennock wrote: } Subject: Re: Access to CVS } } On 2012-12-05 at 01:33 +0100, Oliver Kiddle wrote: } > Associating commits to mailing list numbers. This amounts to using git } > notes (see workers/30123) so probably just needs a clear convention. } > Perhaps we could use a hook script to enforce it on the master } > repository. } } Biggest problem is if the change in the mail doesn't exactly match the } files being patched, in which case there's not identifying information } in the mail to figure out the commit. If the person grabbing the patch } uses "git note" manually, or as a filter to grab X-Seq, then it works. I'm not sure this is necessary? We currently rely on people to manually insert the X-Seq into their commit logs. Attempting to automatically extract it from the list archives sounds like a complete nightmare. Further we sometimes reference X-Seq numbers of messages that don't have a patch at all, just to connect a change to a background discussion. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-05 9:40 ` Bart Schaefer @ 2012-12-05 11:26 ` Phil Pennock 2012-12-05 12:11 ` Frank Terbeck 2012-12-05 19:50 ` Peter Stephenson 0 siblings, 2 replies; 60+ messages in thread From: Phil Pennock @ 2012-12-05 11:26 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers On 2012-12-05 at 01:40 -0800, Bart Schaefer wrote: > I'm not sure this is necessary? We currently rely on people to manually > insert the X-Seq into their commit logs. Attempting to automatically > extract it from the list archives sounds like a complete nightmare. > > Further we sometimes reference X-Seq numbers of messages that don't have > a patch at all, just to connect a change to a background discussion. Excellent, less work for migration and I can stop feeling guilty for not writing it myself. So, with CVS dying a slow death[*], and a git repo already existing, are you, Bart, happy with the idea of switching to Git? Peter? If so, what's actually needed? A guideline on the workflow? Someone with sourceforge project admin rights to make changes there? Something else? I'm using git enough to be doing horrid nasty things to it. I'm happy to try to help out, short term. I know, that's not the right answer, but it's all I can commit to. Anyone? [*] FreeBSD switching away, code-bases not really maintained, little modern tooling continuing to support it, and it's always been just frustrating. Git's frustrating too, but with some hope for the future, in my stupid optimistic moments. Mercurial's nicer to use, but doesn't have the momentum that Git does, and zsh already has the unofficial git synchronised repo. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-05 11:26 ` Phil Pennock @ 2012-12-05 12:11 ` Frank Terbeck 2012-12-05 21:13 ` Aaron Schrab 2012-12-05 19:50 ` Peter Stephenson 1 sibling, 1 reply; 60+ messages in thread From: Frank Terbeck @ 2012-12-05 12:11 UTC (permalink / raw) To: zsh-workers Phil Pennock wrote: [...] > If so, what's actually needed? A guideline on the workflow? Someone > with sourceforge project admin rights to make changes there? Something > else? I think a git-switch was last discussed in workers/29966 and the following thread¹. I linked to some interesting documents in there as well. I think the most important outstanding issue is to put something useful into $ZSH_PATCHLEVEL. `git-describe' can produce reasonable values. The rest is largely related to workflow. I also whined about the fact that manually keeping a ChangeLog is a pain in the behind, esp. with a system that actually already uses changeset instead of changes to individual files. Which means, that you get a change log for free. I came up with http://ft.bewatermyfriend.org/comp/genchangelog.html, in case people would like to have a traditional ChangeLog file around in release tarballs (although, I'd still argue that a release tarball only needs a list of user-visible changes, as long as the VCS history is publicly available for everyone to look at). With regard to the actual switch: Someone could prepare a patch-series that make the source-tree git-aware ($ZSH_PATCHLEVEL conversion etc) and make that repository available on bitbucket (or github or whatever) for review. Once that repository is fine, the changes can be merged in the sf.net repository and the primary VCS could be switched, by someone with the appropriate access. Regards, Frank ¹ http://thread.gmane.org/gmane.comp.shells.zsh.devel/23984/focus=23992 -- In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC 1925 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-05 12:11 ` Frank Terbeck @ 2012-12-05 21:13 ` Aaron Schrab 2012-12-05 23:34 ` Aaron Schrab 0 siblings, 1 reply; 60+ messages in thread From: Aaron Schrab @ 2012-12-05 21:13 UTC (permalink / raw) To: zsh-workers At 13:11 +0100 05 Dec 2012, Frank Terbeck <ft@bewatermyfriend.org> wrote: >I think the most important outstanding issue is to put something useful >into $ZSH_PATCHLEVEL. `git-describe' can produce reasonable values. The following patch seems to produce decent results. Such as: 1004$ echo $ZSH_PATCHLEVEL zsh-5.0.0-91-g2c149d7 Contrary to a previous comment this does give some indication of relationships between different patch levels. The "91" in that string is the number of commits since the named tag (zsh-5.0.0) in this case. --- 8< --- Subject: [PATCH] Generate patch level using `git describe` Generate the patch level using `git describe` rather than relying on the CVS $Revision$. Need to use the `--tags` option, since currently there are no annotated tags. Since changes to the patchlevel could now be caused by changes to any file, force the rule to be called every time that `make` is run. But, only update the file when there are actually changes to prevent unnecessary rebuilding of other build products (currently just `params.o` and `zsh`). --- Src/zsh.mdd | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Src/zsh.mdd b/Src/zsh.mdd index 6e90776..5d9460d 100644 --- a/Src/zsh.mdd +++ b/Src/zsh.mdd @@ -39,10 +39,10 @@ params.o: patchlevel.h version.h: $(sdir_top)/Config/version.mk zshcurses.h zshterm.h echo '#define ZSH_VERSION "'$(VERSION)'"' > $@ -patchlevel.h: $(sdir_top)/ChangeLog - sed -ne \ - 's/^\* *\$$''Revision: \(.*\) ''\$$/#define ZSH_PATCHLEVEL "\1"/p' \ - $(sdir_top)/ChangeLog >patchlevel.h +patchlevel.h: FORCE + echo '#define ZSH_PATCHLEVEL "'`git describe --tags`'"' > $@.tmp + cmp $@ $@.tmp && rm -f $@.tmp || mv $@.tmp $@ +FORCE: zshcurses.h: ../config.h @if test x$(ZSH_CURSES_H) != x; then \ -- 1.7.10.4 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-05 21:13 ` Aaron Schrab @ 2012-12-05 23:34 ` Aaron Schrab 0 siblings, 0 replies; 60+ messages in thread From: Aaron Schrab @ 2012-12-05 23:34 UTC (permalink / raw) To: zsh-workers At 16:13 -0500 05 Dec 2012, I wrote: >+ echo '#define ZSH_PATCHLEVEL "'`git describe --tags`'"' > $@.tmp Thinking about this a bit more, that should probably use the git describe's --long option as well. That way it will consistently produce output in the tag-commits-hash format rather than just giving the tag when there are no later changes. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-05 11:26 ` Phil Pennock 2012-12-05 12:11 ` Frank Terbeck @ 2012-12-05 19:50 ` Peter Stephenson 2012-12-06 19:59 ` Peter Stephenson 2012-12-07 0:05 ` Aaron Schrab 1 sibling, 2 replies; 60+ messages in thread From: Peter Stephenson @ 2012-12-05 19:50 UTC (permalink / raw) To: zsh-workers On Wed, 5 Dec 2012 06:26:47 -0500 Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote: > So, with CVS dying a slow death[*], and a git repo already existing, are > you, Bart, happy with the idea of switching to Git? > > Peter? > > If so, what's actually needed? A guideline on the workflow? Someone > with sourceforge project admin rights to make changes there? Something > else? Apart from sorting out the patch level and the mailing list links, it really just needs someone to take it on who can keep managing it, or at least advising on it since it really shouldn't take any special managing once it's set up. I don't think there's anything significant in the way. -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-05 19:50 ` Peter Stephenson @ 2012-12-06 19:59 ` Peter Stephenson 2012-12-07 0:05 ` Aaron Schrab 1 sibling, 0 replies; 60+ messages in thread From: Peter Stephenson @ 2012-12-06 19:59 UTC (permalink / raw) To: zsh-workers On Wed, 5 Dec 2012 19:50:13 +0000 Peter Stephenson <p.w.stephenson@ntlworld.com> wrote: > Apart from sorting out the patch level and the mailing list links, it > really just needs someone to take it on who can keep managing it, or at > least advising on it since it really shouldn't take any special managing > once it's set up. I don't think there's anything significant in the way. By the way, if anyone thinks they do have the time to spend on this, let me know and I'll make sure they get the appropriate sourceforge permissions. -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-05 19:50 ` Peter Stephenson 2012-12-06 19:59 ` Peter Stephenson @ 2012-12-07 0:05 ` Aaron Schrab 2012-12-07 7:13 ` Alex Ogier ` (2 more replies) 1 sibling, 3 replies; 60+ messages in thread From: Aaron Schrab @ 2012-12-07 0:05 UTC (permalink / raw) To: zsh-workers At 19:50 +0000 05 Dec 2012, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote: >Apart from sorting out the patch level and the mailing list links, it I'm still unclear about what is expected in regards to handling of the mailing list links. Why is it necessary to handle those differently for git than is currently done with CVS, just mention the sequence number in the commit message? For patches that are sent to the mailing list and then added to the official repository the sequence number would obviously be known before the commit is done, so the commit message could be edited to include it at that time. If submissions start being sent more in the form of pull requests rather than patches sent to the list, the changes could be merged using `git merge --no-ff --edit` (the --edit option is the default in recent versions of git, so wouldn't always be necessary) to create a new commit with its own commit message where the sequence number could be included. This would mean that somebody who uses `git bisect` to try to determine where something was introduced would likely find the original commit, and would need to look forward a bit in the history to find the relevant sequence number; but that doesn't seem to be a huge burden to me. This has the advantage that these links would be in the commit message no matter if the commit was done before or after the conversion. Since there isn't really a standard format for these messages, it would be difficult to automatically convert the existing ones and it would be a tedious (and error-prone) process to do that manually. It also doesn't require that people need to know anything about git notes which are still somewhat of an obscure area of git. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 0:05 ` Aaron Schrab @ 2012-12-07 7:13 ` Alex Ogier 2012-12-07 9:34 ` Frank Terbeck 2012-12-07 15:11 ` Aaron Schrab 2012-12-07 9:29 ` Frank Terbeck 2012-12-07 9:49 ` Peter Stephenson 2 siblings, 2 replies; 60+ messages in thread From: Alex Ogier @ 2012-12-07 7:13 UTC (permalink / raw) To: zsh-workers [-- Attachment #1: Type: text/plain, Size: 2187 bytes --] For pull requests that originate outside of patches, a convenient work flow is to have the committer merge with 'git merge --squash' as a matter of course. This way allows all of the advantages of distributed version control while still keeping mainline history a linear sequence of clean patches you can bisect to. Best, Alex Ogier On Dec 6, 2012 4:06 PM, "Aaron Schrab" <aaron@schrab.com> wrote: > At 19:50 +0000 05 Dec 2012, Peter Stephenson <p.w.stephenson@ntlworld.com> > wrote: > >> Apart from sorting out the patch level and the mailing list links, it >> > > I'm still unclear about what is expected in regards to handling of the > mailing list links. Why is it necessary to handle those differently for > git than is currently done with CVS, just mention the sequence number in > the commit message? > > For patches that are sent to the mailing list and then added to the > official repository the sequence number would obviously be known before the > commit is done, so the commit message could be edited to include it at that > time. > > If submissions start being sent more in the form of pull requests rather > than patches sent to the list, the changes could be merged using `git merge > --no-ff --edit` (the --edit option is the default in recent versions of > git, so wouldn't always be necessary) to create a new commit with its own > commit message where the sequence number could be included. This would > mean that somebody who uses `git bisect` to try to determine where > something was introduced would likely find the original commit, and would > need to look forward a bit in the history to find the relevant sequence > number; but that doesn't seem to be a huge burden to me. > > This has the advantage that these links would be in the commit message no > matter if the commit was done before or after the conversion. Since there > isn't really a standard format for these messages, it would be difficult to > automatically convert the existing ones and it would be a tedious (and > error-prone) process to do that manually. It also doesn't require that > people need to know anything about git notes which are still somewhat of an > obscure area of git. > ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 7:13 ` Alex Ogier @ 2012-12-07 9:34 ` Frank Terbeck 2012-12-07 15:11 ` Aaron Schrab 1 sibling, 0 replies; 60+ messages in thread From: Frank Terbeck @ 2012-12-07 9:34 UTC (permalink / raw) To: zsh-workers Alex Ogier wrote: > For pull requests that originate outside of patches, a convenient work flow > is to have the committer merge with 'git merge --squash' as a matter of > course. This way allows all of the advantages of distributed version > control while still keeping mainline history a linear sequence of clean > patches you can bisect to. Wait a minute, `squash'? Doesn't that mean, that a reduce a series of perfectly separated patches into one single blob of changes? If you want to enforce linear history, why not require contributors to rebase their series on top of the current development? That being said, I'd still prefer if contributions came in via patches to the mailing list only. Regards, Frank ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 7:13 ` Alex Ogier 2012-12-07 9:34 ` Frank Terbeck @ 2012-12-07 15:11 ` Aaron Schrab 2012-12-07 15:37 ` François Revol 1 sibling, 1 reply; 60+ messages in thread From: Aaron Schrab @ 2012-12-07 15:11 UTC (permalink / raw) To: zsh-workers At 02:13 -0500 07 Dec 2012, Alex Ogier <alex.ogier@gmail.com> wrote: >For pull requests that originate outside of patches, a convenient work flow >is to have the committer merge with 'git merge --squash' as a matter of >course. This way allows all of the advantages of distributed version >control while still keeping mainline history a linear sequence of clean >patches you can bisect to. While that would take care of the problem that I mentioned about, bisecting to a commit that doesn't mention a mailing list sequence number I believe it creates more, worse issues. With that a change set that involved a number of commits would be reduced to a single one, so bisecting to that wouldn't give as much information about the actual change which caused the problem. It also loses the finer-grained information about the changes for other purposes. Also, this would not be convenient for the submitter of the pull request. If a normal merge is done, it is easy for the submitter (or other people) to determine that the branch was fully merged, since the submitted commits are part of the history. With --squash, if the submitter wants to determine if the changes were merged as-is or if further modifications were done a more thorough examination would need to be done, especially if the merge was done on top of a different commit than where the original branch was based. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 15:11 ` Aaron Schrab @ 2012-12-07 15:37 ` François Revol 2012-12-07 16:06 ` Aaron Schrab 0 siblings, 1 reply; 60+ messages in thread From: François Revol @ 2012-12-07 15:37 UTC (permalink / raw) To: zsh-workers On 07/12/2012 16:11, Aaron Schrab wrote: > Also, this would not be convenient for the submitter of the pull > request. If a normal merge is done, it is easy for the submitter (or > other people) to determine that the branch was fully merged, since the > submitted commits are part of the history. With --squash, if the > submitter wants to determine if the changes were merged as-is or if > further modifications were done a more thorough examination would need > to be done, especially if the merge was done on top of a different > commit than where the original branch was based. Well you can merge back master into your branch, then git diff master will tell if there are still differences... But it's unhandy. François. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 15:37 ` François Revol @ 2012-12-07 16:06 ` Aaron Schrab 0 siblings, 0 replies; 60+ messages in thread From: Aaron Schrab @ 2012-12-07 16:06 UTC (permalink / raw) To: zsh-workers At 16:37 +0100 07 Dec 2012, François Revol <revol@free.fr> wrote: >On 07/12/2012 16:11, Aaron Schrab wrote: >> Also, this would not be convenient for the submitter of the pull >> request. If a normal merge is done, it is easy for the submitter (or >> other people) to determine that the branch was fully merged, since the >> submitted commits are part of the history. With --squash, if the >> submitter wants to determine if the changes were merged as-is or if >> further modifications were done a more thorough examination would need >> to be done, especially if the merge was done on top of a different >> commit than where the original branch was based. > >Well you can merge back master into your branch, then git diff master >will tell if there are still differences... >But it's unhandy. I've generally found it more convenient to rebase a copy of the branch in question on top of the commit where it was applied by the upstream maintainer, then compare my results to what was published by the upstream. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 0:05 ` Aaron Schrab 2012-12-07 7:13 ` Alex Ogier @ 2012-12-07 9:29 ` Frank Terbeck 2012-12-07 10:57 ` Christian Neukirchen 2012-12-07 15:31 ` Bart Schaefer 2012-12-07 9:49 ` Peter Stephenson 2 siblings, 2 replies; 60+ messages in thread From: Frank Terbeck @ 2012-12-07 9:29 UTC (permalink / raw) To: zsh-workers Aaron Schrab wrote: > At 19:50 +0000 05 Dec 2012, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote: >>Apart from sorting out the patch level and the mailing list links, it > > I'm still unclear about what is expected in regards to handling of the mailing > list links. Why is it necessary to handle those differently for git than is > currently done with CVS, just mention the sequence number in the commit > message? Obviously, you don't *have* to change anything about that. However the path of a patch currently looks like this: You hack up the patch. Then you send it to the mailing list. You wait for the mail to arrive at the mailing list. Then you pick up the X-Seq: header number from the mail that returns from the mailing list software. Now you add an entry to ChangeLog that mentions the X-Seq: number, the files that were changed in the patch; plus the first line of the actual commit message. (If you're just the committer and not the author of the patch you also mention the original author's name.) That's not very convenient. I don't mind the mail going through the mailing list. That's good for review and stuff like that. But it would be pretty neat, if I could save a mail from my MUA somewhere and run "git am foo.patch" on it. If that would extract the X-Seq: number from the mail and put it in front of the first line of the commit message, then that would require no manual intervention at all. (Well, that and an automatically generated ChangeLog instead of a manually updated one.) I'd need to take a look at git-am to see whether there is a hook that would let us do something like that. Another way would be to put the number into notes. However there would be potential for that to be forgotten. > For patches that are sent to the mailing list and then added to the official > repository the sequence number would obviously be known before the commit is > done, so the commit message could be edited to include it at that > time. Indeed. > If submissions start being sent more in the form of pull requests rather than > patches sent to the list [...] How about not doing that? :) It's not like it is hard to produce series of a larger number patches with "git format-patch". And even sending them is trivial with "git send-email". That way, the way we handle contributions doesn't change a whole lot. Everything would still pass the mailing list. Pretty much like git development itself works. And if it scales for them, it will scale for us - just judging by the sheer amount of patches they receive. > This has the advantage that these links would be in the commit message no > matter if the commit was done before or after the conversion. ACK. Also, that would mean that both the SHA1 number as well as the X-Seq: number would be listed in a ChangeLog generated by [1]. :-) So that would mean that you could quickly do lookups of the individual change in git history as well as the mailing list archive. > Since there > isn't really a standard format for these messages, it would be difficult to > automatically convert the existing ones and it would be a tedious (and > error-prone) process to do that manually. It also doesn't require that people > need to know anything about git notes which are still somewhat of an obscure > area of git. ACK to the obscurity of git-notes. IIRC there were issues with some git tools and notes to, like they where lost when someone did a rebase? But maybe that's fixed by now... Still, you have a point. Regards, Frank [1] http://ft.bewatermyfriend.org/comp/genchangelog.html -- In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC 1925 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 9:29 ` Frank Terbeck @ 2012-12-07 10:57 ` Christian Neukirchen 2012-12-07 11:08 ` Frank Terbeck 2012-12-07 15:31 ` Bart Schaefer 1 sibling, 1 reply; 60+ messages in thread From: Christian Neukirchen @ 2012-12-07 10:57 UTC (permalink / raw) To: zsh-workers Frank Terbeck <ft@bewatermyfriend.org> writes: > That's not very convenient. I don't mind the mail going through the > mailing list. That's good for review and stuff like that. But it would > be pretty neat, if I could save a mail from my MUA somewhere and run > "git am foo.patch" on it. If that would extract the X-Seq: number from > the mail and put it in front of the first line of the commit message, > then that would require no manual intervention at all. (Well, that and > an automatically generated ChangeLog instead of a manually updated one.) > > I'd need to take a look at git-am to see whether there is a hook that > would let us do something like that. Just write a tool that takes the mail, extracts X-Seq: and fiddles it into the Subject. Then pipe that into git-am. -- Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 10:57 ` Christian Neukirchen @ 2012-12-07 11:08 ` Frank Terbeck 2012-12-07 11:38 ` Frank Terbeck 0 siblings, 1 reply; 60+ messages in thread From: Frank Terbeck @ 2012-12-07 11:08 UTC (permalink / raw) To: zsh-workers Christian Neukirchen wrote: > Frank Terbeck <ft@bewatermyfriend.org> writes: >> [...] if I could save a mail from my MUA somewhere and run >> "git am foo.patch" on it. If that would extract the X-Seq: number from >> the mail and put it in front of the first line of the commit message, [...] >> I'd need to take a look at git-am to see whether there is a hook that >> would let us do something like that. > > Just write a tool that takes the mail, extracts X-Seq: and fiddles it > into the Subject. Then pipe that into git-am. Right, that's a good point. Since we'd have to document how to configure git-am to respect the X-Seq: header anyway, we could just to that aswell. And keep the script in Util/git-am or something along those lines. Regards, Frank ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 11:08 ` Frank Terbeck @ 2012-12-07 11:38 ` Frank Terbeck 0 siblings, 0 replies; 60+ messages in thread From: Frank Terbeck @ 2012-12-07 11:38 UTC (permalink / raw) To: zsh-workers Frank Terbeck wrote: > Christian Neukirchen wrote: [...] >> Just write a tool that takes the mail, extracts X-Seq: and fiddles it >> into the Subject. Then pipe that into git-am. > > Right, that's a good point. Since we'd have to document how to configure > git-am to respect the X-Seq: header anyway, we could just to that > aswell. And keep the script in Util/git-am or something along those > lines. ...although. IIRC, you can feed complete mbox files into git-am, which would make that script a little more complex, albeit not impossible to get right. Regards, Frank ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 9:29 ` Frank Terbeck 2012-12-07 10:57 ` Christian Neukirchen @ 2012-12-07 15:31 ` Bart Schaefer 2012-12-07 16:01 ` Aaron Schrab 1 sibling, 1 reply; 60+ messages in thread From: Bart Schaefer @ 2012-12-07 15:31 UTC (permalink / raw) To: zsh-workers On Dec 7, 10:29am, Frank Terbeck wrote: } } I'd need to take a look at git-am to see whether there is a hook that } would let us do something like that. } } Another way would be to put the number into notes. However there would } be potential for that to be forgotten. I'm not a git power-user [*] -- is there a push-time hook that could issue a warning if there's no sequence number in the log message? Is there anything like "cvs admin -m" that allows you to update the log message after the fact? [*] This (and that neither is PWS) is probably a significant reason why we're still using CVS for zsh. I've got my own local CVS repository and tools for doing the equivalent of "rebase" etc., so I'm rarely doing work directly against the main repository. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 15:31 ` Bart Schaefer @ 2012-12-07 16:01 ` Aaron Schrab 0 siblings, 0 replies; 60+ messages in thread From: Aaron Schrab @ 2012-12-07 16:01 UTC (permalink / raw) To: zsh-workers At 07:31 -0800 07 Dec 2012, Bart Schaefer <schaefer@brasslantern.com> wrote: >I'm not a git power-user [*] -- is there a push-time hook that could >issue a warning if there's no sequence number in the log message? Not currently, there's been a little bit of discussion on adding a hook that would be called before a push was done, but real progress on that last I checked. >Is there anything like "cvs admin -m" that allows you to update the log >message after the fact? There's `git commit --amend` which allows modifying both the commit message and contents of the most recent commit. If you want to modify the message on an older commit, you can use `git rebase -i HEAD~10` to begin an interactive rebase of the 10 (or some other number) most recent commits and choose to "reword" the commit message of any of those, or even choose to "edit" any of those commits modifying both the content and message. Either of those options involves rewriting history, so should not be done for commits that have already been made public. (But the rebase one won't change history of commits older than what you actually edit or reword, so there isn't a huge problem with choosing too big a number when beginning). ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 0:05 ` Aaron Schrab 2012-12-07 7:13 ` Alex Ogier 2012-12-07 9:29 ` Frank Terbeck @ 2012-12-07 9:49 ` Peter Stephenson 2012-12-07 11:03 ` Frank Terbeck 2012-12-11 23:05 ` Access to CVS Oliver Kiddle 2 siblings, 2 replies; 60+ messages in thread From: Peter Stephenson @ 2012-12-07 9:49 UTC (permalink / raw) To: zsh-workers On Thu, 06 Dec 2012 19:05:22 -0500 Aaron Schrab <aaron@schrab.com> wrote: > I'm still unclear about what is expected in regards to handling of > the mailing list links. Why is it necessary to handle those > differently for git than is currently done with CVS, just mention the > sequence number in the commit message? I'm expecting (from my limited knowledge of git) that git-aware people will do the following: - Play with the change locally, committing it, possibly multiple times. I don't see any reason you'd *have* to do this, it just strikes me as the natural way a developer used to git would work, so you have a record in the archive of what went to the list. The ability to do this is one of the big advantages of the distributed system. - Send the overall diff of the changes to the mailing list. - If it needs tweaking, there might be further local commits. - When it looks OK, push the set of changes to the main repository. So the issue would be to associate the link at the point where it got pushed. I don't know enough about git to say if what you or Alex or others are suggesting fits in with this. pws ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 9:49 ` Peter Stephenson @ 2012-12-07 11:03 ` Frank Terbeck 2013-03-17 14:55 ` Simon Ruderich 2012-12-11 23:05 ` Access to CVS Oliver Kiddle 1 sibling, 1 reply; 60+ messages in thread From: Frank Terbeck @ 2012-12-07 11:03 UTC (permalink / raw) To: zsh-workers Peter Stephenson wrote: > Aaron Schrab <aaron@schrab.com> wrote: >> I'm still unclear about what is expected in regards to handling of >> the mailing list links. Why is it necessary to handle those >> differently for git than is currently done with CVS, just mention the >> sequence number in the commit message? > > I'm expecting (from my limited knowledge of git) that git-aware people > will do the following: > > - Play with the change locally, committing it, possibly multiple times. > I don't see any reason you'd *have* to do this, it just strikes me > as the natural way a developer used to git would work, so you have > a record in the archive of what went to the list. The ability to > do this is one of the big advantages of the distributed system. Exactly. Potentially, you could refine a set of changes until you're perfectly happy with it and not pile refinement upon refinement on top of your original series as small commits. With git, history only becomes immutable when it's made public (i.e. pushed to a central server). Because when people base work off of it and you still change it afterwards, the SHA1 sums will change and that'll just blow up into the face of anyone who already worked with the old history. > - Send the overall diff of the changes to the mailing list. Yup. > - If it needs tweaking, there might be further local commits. Right. That would be one of the refinements I talked about earlier. > - When it looks OK, push the set of changes to the main repository. Yes. And git helps with making things easier with external contributors who don't have commit access (yet). Because git has things like "git-am". With that you can just save a mail that contains a patch to a file and feed it into "git am". It'll extract information like "author" and "commit message" from the mail and commit everything in your local repository, ready to be pushed. > So the issue would be to associate the link at the point where it got > pushed. It would be great if we could make "git-am" process the X-Seq: header, too. If that would be possible, integrating someone else's patch from the mailing list would boil down to this: - Save the mail to a file. - git am foo.patch - git push Regards, Frank -- In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC 1925 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 11:03 ` Frank Terbeck @ 2013-03-17 14:55 ` Simon Ruderich 2013-04-04 13:38 ` Simon Ruderich 0 siblings, 1 reply; 60+ messages in thread From: Simon Ruderich @ 2013-03-17 14:55 UTC (permalink / raw) To: zsh-workers [-- Attachment #1.1: Type: text/plain, Size: 1347 bytes --] On Fri, Dec 07, 2012 at 12:03:31PM +0100, Frank Terbeck wrote: > It would be great if we could make "git-am" process the X-Seq: header, > too. If that would be possible, integrating someone else's patch from > the mailing list would boil down to this: > > - Save the mail to a file. > - git am foo.patch > - git push On Thu, Dec 13, 2012 at 03:57:47PM +0100, Simon Ruderich wrote: > Sadly git-am doesn't provide any hooks which get the original > patch message as argument. > > [snip] Turns out this isn't quite true. Attached is a simple applypatch-msg hook which extracts the X-Seq from the original patch and prepends it to the commit message (if the message doesn't already contain a sequence number). The hook should work fine all Git versions and works fine with multiple patches (mbox of patches or multiple patch files passed to git am). To use it simply drop it in .git/hooks/ and chmod +x it. Please tell me what you think. If it works fine we should ship it in Etc/ and developers can just symlink it into .git/hooks/. Btw. what's missing to complete the Git conversion? Please tell me if there's anything I can do to help. I'd really like to see Zsh finally switch to Git. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 [-- Attachment #1.2: applypatch-msg --] [-- Type: text/plain, Size: 722 bytes --] #!/bin/sh # applypatch-msg for Zsh which extracts X-Seq from the patch and prepends it # to the commit message. if test ! -f "$1"; then exit 0 fi # Path to ".git/rebase-apply/" directory. dotest=`dirname "$1"` # Path to the patch file which will be applied. this=`cat "$dotest/next"` patch="$dotest/`printf '%04d' "$this"`" # Extract sequence number. sequence=`grep -E '^X-Seq: ' "$patch" | awk '{ print $2 }'` if test -z "$sequence"; then exit 0 fi # Prepend sequence number to commit message if not already present. if ! grep -E '^unposted: ' "$1" > /dev/null && ! grep -E '^[0-9][0-9]*: ' "$1" > /dev/null; then printf "%s: " "$sequence" > "$1.tmp" cat "$1" >> "$1.tmp" mv "$1.tmp" "$1" fi [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2013-03-17 14:55 ` Simon Ruderich @ 2013-04-04 13:38 ` Simon Ruderich 2013-04-05 16:57 ` One-command mail import with X-Seq: and ChangeLog (was: Re: Access to CVS) Frank Terbeck 0 siblings, 1 reply; 60+ messages in thread From: Simon Ruderich @ 2013-04-04 13:38 UTC (permalink / raw) To: zsh-workers [-- Attachment #1: Type: text/plain, Size: 562 bytes --] On Sun, Mar 17, 2013 at 03:55:07PM +0100, Simon Ruderich wrote: > Attached is a simple applypatch-msg hook which extracts the X-Seq > from the original patch and prepends it to the commit message (if > the message doesn't already contain a sequence number). Now that we've switched to Git, this applypatch-msg hook should be useful (if it works). Could you please have a look and test it when you apply patches. Suggestions are welcome. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* One-command mail import with X-Seq: and ChangeLog (was: Re: Access to CVS) 2013-04-04 13:38 ` Simon Ruderich @ 2013-04-05 16:57 ` Frank Terbeck 2013-04-07 19:07 ` Bart Schaefer 0 siblings, 1 reply; 60+ messages in thread From: Frank Terbeck @ 2013-04-05 16:57 UTC (permalink / raw) To: zsh-workers Simon Ruderich wrote: [...] > Now that we've switched to Git, this applypatch-msg hook should > be useful (if it works). Could you please have a look and test it > when you apply patches. Suggestions are welcome. My go at this is available at: https://github.com/ft/zsh-am There is a pretty long README file included, that explains how to arrive at directly-commitable email messages, that can be consumed by "git am". That makes it a little long. The short version is this: - Mark mails containing commits in MUA - Make MUA save those Mails into mbox file - Call: zsh-am the-mbox-file That imports all commits from the mbox file, adds X-Seq: numbers in the appropriate places (it also detects if a mail was send to -users instead of -workers and prefix the X-Seq: number with "users/") and updates ChangeLog after each and every commit automatically along the way. I've committed some changes I sent to the list a while ago using this (because nobody complained since I sent them): http://sourceforge.net/p/zsh/code/ci/6654b87b450ee317fb73ec9a875cb8c29f8a0e83/ http://sourceforge.net/p/zsh/code/ci/daf4f19c3f52c63c4131b66ee086b5214a67d451/ http://sourceforge.net/p/zsh/code/ci/dd638aea93c920228f164e38e350cd6388a6a645/ Note, that the ChangeLog is updated for _every_ commit and not once for all commits after committing. The ChangeLog generated looks like this: 2013-04-05 Frank Terbeck <ft@bewatermyfriend.org> * 31174: Src/Zle/zle_main.c: 31174: zle: Make sure state changes are refreshed after init hook * 31172: Src/Zle/zle_main.c: 31172: Let vared define custom init and finish hooks * 31175: Doc/Zsh/zle.yo: 31175: Add documentation for the new -i and -f options of vared The fact that the X-Seq: number appears twice, was due to a bug in `genchangelog' and me not checking the result properly before pushing... That bug should be fixed by now. Regards, Frank ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: One-command mail import with X-Seq: and ChangeLog (was: Re: Access to CVS) 2013-04-05 16:57 ` One-command mail import with X-Seq: and ChangeLog (was: Re: Access to CVS) Frank Terbeck @ 2013-04-07 19:07 ` Bart Schaefer 2013-04-07 19:48 ` One-command mail import with X-Seq: and ChangeLog Simon Ruderich ` (3 more replies) 0 siblings, 4 replies; 60+ messages in thread From: Bart Schaefer @ 2013-04-07 19:07 UTC (permalink / raw) To: zsh-workers On Apr 5, 6:57pm, Frank Terbeck wrote: } Subject: One-command mail import with X-Seq: and ChangeLog } } My go at this is available at: https://github.com/ft/zsh-am Thanks for this, Frank. Particularly the README.org, which is a lot more like what I was hoping would end up in Etc/zsh-development-guide than what we settled on (which is not meant as a slight against any of those who worked on updating z-d-g; I wouldn't have known what to ask for at the time). The one thing I'm finding missing from both places is a discussion of how to perform a simple one-file (well, two, counting ChangeLog) push directly from a clone of the master. Can I --amend a commit without having a branch, or must I wait even to commit until I've edited the ChangeLog? Or is creating a branch THE way, and I should ignore all the discussion of branching for "a feature" and just create a branch that's always there and use it repeatedly whenver I edit? } - Mark mails containing commits in MUA } - Make MUA save those Mails into mbox file } - Call: zsh-am the-mbox-file I think the first thing I'm going to do unless you beat me to it is to make zsh-am read patch emails from standard input ... it's just way too easy in e.g. Alpine to hit "|" rather than save the message. I know a number of people send patches in several parts and want to commit them all at once, but far and away the most common thing is to want to operate on just one message. (Aside: zsh-am is a bash script? Horrors! :-) ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: One-command mail import with X-Seq: and ChangeLog 2013-04-07 19:07 ` Bart Schaefer @ 2013-04-07 19:48 ` Simon Ruderich 2013-04-07 21:08 ` Bart Schaefer 2013-04-07 21:08 ` Frank Terbeck ` (2 subsequent siblings) 3 siblings, 1 reply; 60+ messages in thread From: Simon Ruderich @ 2013-04-07 19:48 UTC (permalink / raw) To: zsh-workers [-- Attachment #1: Type: text/plain, Size: 2033 bytes --] On Sun, Apr 07, 2013 at 12:07:49PM -0700, Bart Schaefer wrote: > The one thing I'm finding missing from both places is a discussion of > how to perform a simple one-file (well, two, counting ChangeLog) push > directly from a clone of the master. Can I --amend a commit without > having a branch, or must I wait even to commit until I've edited the Technically you're always on a branch (ignoring detached HEAD here), it's just the master branch and not a special branch created for a specific feature. Of course you can --amend on the master branch without creating a new feature branch (in Git all branches are equal). Don't --amend anything public though, e.g. nothing which is already in origin/master. > ChangeLog? Or is creating a branch THE way, and I should ignore all > the discussion of branching for "a feature" and just create a branch > that's always there and use it repeatedly whenver I edit? Normally you're on the master branch which tracks the remote branch origin/master. How you work with this branch depends on your workflow. Some people prefer to always create new branches for specific features, this is the workflow described by Frank, others just work on master for small features (e.g. the one file change you just mentioned) and push that to the remote. It depends what you like better. From Git's point-of-view you don't have to create any new branches at all, but it's sometimes/often useful. Personally I don't use any extra branches for small features, but that just my preference. Using _one_ extra branch repeatedly is not necessary in Git, as branches are very cheap. If you want a new branch for this feature, just create it (with an appropriate name) and remove it later once the changes are merged/pushed to origin/master just as Frank described. One the other hand if you don't need a specific feature branch, just work on master. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: One-command mail import with X-Seq: and ChangeLog 2013-04-07 19:48 ` One-command mail import with X-Seq: and ChangeLog Simon Ruderich @ 2013-04-07 21:08 ` Bart Schaefer 2013-04-07 21:14 ` Frank Terbeck 2013-04-07 21:51 ` Simon Ruderich 0 siblings, 2 replies; 60+ messages in thread From: Bart Schaefer @ 2013-04-07 21:08 UTC (permalink / raw) To: zsh-workers Thanks, Simon. On Apr 7, 9:48pm, Simon Ruderich wrote: } } Don't --amend anything public though, e.g. nothing which is already in } origin/master. Hmm. Is there some way to effectively make that impossible? I.e., rebase after push or something? } Using _one_ extra branch repeatedly is not necessary in Git, as } branches are very cheap. Cheaply implemented, yes; cheap in terms of me executing the absolute minimum number of shell commands between deciding to respond to a bug report on the list and a fix arriving in the origin master ... :-) -- Barton E. Schaefer ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: One-command mail import with X-Seq: and ChangeLog 2013-04-07 21:08 ` Bart Schaefer @ 2013-04-07 21:14 ` Frank Terbeck 2013-04-07 21:51 ` Simon Ruderich 1 sibling, 0 replies; 60+ messages in thread From: Frank Terbeck @ 2013-04-07 21:14 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers Bart Schaefer wrote: > On Apr 7, 9:48pm, Simon Ruderich wrote: > } Don't --amend anything public though, e.g. nothing which is already in > } origin/master. > > Hmm. Is there some way to effectively make that impossible? I.e., rebase > after push or something? I don't think you can do this accidentally, if you're trying to rewrite history with a push, git will warn you and to actually do it, you'll have to use "git push --force". I think we could configure the remote repository to disallow forced pushes, but I'm not sure if that's required. Just don't --force. :) Regards, Frank ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: One-command mail import with X-Seq: and ChangeLog 2013-04-07 21:08 ` Bart Schaefer 2013-04-07 21:14 ` Frank Terbeck @ 2013-04-07 21:51 ` Simon Ruderich 1 sibling, 0 replies; 60+ messages in thread From: Simon Ruderich @ 2013-04-07 21:51 UTC (permalink / raw) To: zsh-workers [-- Attachment #1: Type: text/plain, Size: 870 bytes --] On Sun, Apr 07, 2013 at 02:08:20PM -0700, Bart Schaefer wrote: > Cheaply implemented, yes; cheap in terms of me executing the absolute > minimum number of shell commands between deciding to respond to a bug > report on the list and a fix arriving in the origin master ... :-) Also cheap to create regarding the number of shell commands. Switch to your one hack branch: git checkout hack Create a new branch for this feature: git checkout -b feature But the cheapest way (counted in shell commands) is just to fix the bug on master: no branches to switch and you can just commit and then push the fix. With git add --patch (or -p) it's also not a big problem if you have some local unrelated changes in your work tree. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: One-command mail import with X-Seq: and ChangeLog 2013-04-07 19:07 ` Bart Schaefer 2013-04-07 19:48 ` One-command mail import with X-Seq: and ChangeLog Simon Ruderich @ 2013-04-07 21:08 ` Frank Terbeck 2013-04-08 9:09 ` One-command mail import with X-Seq: and ChangeLog (was: Re: Access to CVS) Mikael Magnusson 2013-04-11 15:10 ` One-command mail import with X-Seq: and ChangeLog Frank Terbeck 3 siblings, 0 replies; 60+ messages in thread From: Frank Terbeck @ 2013-04-07 21:08 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers Bart Schaefer wrote: > On Apr 5, 6:57pm, Frank Terbeck wrote: [...] > The one thing I'm finding missing from both places is a discussion of > how to perform a simple one-file (well, two, counting ChangeLog) push > directly from a clone of the master. Can I --amend a commit without > having a branch, or must I wait even to commit until I've edited the > ChangeLog? Or is creating a branch THE way, and I should ignore all > the discussion of branching for "a feature" and just create a branch > that's always there and use it repeatedly whenver I edit? For most things people usually do, additional branches are _absolutely_ optional. People usually use them, because they are cheap to create and easy to handle. But there's no requirement to use them at all. You can do this if you like: - HACK HACK HACK - commit - format-patch/send-email - Get the X-Seq: number from the mail as it returns - Add a ChangeLog entry, however you like - "git add ChangeLog" - "git commit --amend" and put the X-Seq: Number in front for the commit message's first line - "git push" This will work just fine. It might even be the way to go for trivial changes, that you would commit as "unposted: ..." because you don't have to do much of anything, except for adding a ChangeLog entry. Here is one scenario, that might arise, when doing development directly on master: - You got your changes on master - Someone else has their changes pushed in the meantime, - Your copy of master is outdated, and to regain linear history, you'd have to do "git pull --rebase" - If you already have added an entry to ChangeLog, you will definitely get a merge conflict while rebasing. The easy way around this would be to "git pull --rebase" before adding ChangeLog entries. If you don't do your development on master, you can always just "git pull" while master is checked out locally and it will trivially work because there are no changes on there. You can just "zsh-am" your changes on top of it, if you like and then push. You also asked, if "commit --amend" is possible on master. And the answer is yes. "master" is in no way special to git, other than being the default name it uses when creating a repository. There is one catch: Do not amend commits you already pushed. Amending commits changes the hash sum for the commit and people who already have the old version will run into trouble if you change published history from under their feet. As for the idea of a hacking branch: Yes, you can do that, too: - While having master checked out, do: git checkout -b bart/hack - That will create a new branch "bart/hack" and check it out. - You can now do all the things I lined out in README.org - Instead of removing the branch once you're finished you can also do this: - git reset --hard master That will make "bart/hack" the same as the current master branch, ready for you next development cycle. > } - Mark mails containing commits in MUA > } - Make MUA save those Mails into mbox file > } - Call: zsh-am the-mbox-file > > I think the first thing I'm going to do unless you beat me to it is to > make zsh-am read patch emails from standard input ... it's just way too > easy in e.g. Alpine to hit "|" rather than save the message. I know > a number of people send patches in several parts and want to commit > them all at once, but far and away the most common thing is to want to > operate on just one message. Makes sense. I'm not sure how soon I can get onto it. > (Aside: zsh-am is a bash script? Horrors! :-) Well, if your /bin/sh is bash, then you might call it that. It only uses POSIX features, though, and will happily work with debian's `dash' shell or some ksh flavour on other operating systems, as well. :-) Regards, Frank ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: One-command mail import with X-Seq: and ChangeLog (was: Re: Access to CVS) 2013-04-07 19:07 ` Bart Schaefer 2013-04-07 19:48 ` One-command mail import with X-Seq: and ChangeLog Simon Ruderich 2013-04-07 21:08 ` Frank Terbeck @ 2013-04-08 9:09 ` Mikael Magnusson 2013-04-11 15:10 ` One-command mail import with X-Seq: and ChangeLog Frank Terbeck 3 siblings, 0 replies; 60+ messages in thread From: Mikael Magnusson @ 2013-04-08 9:09 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh workers On 7 April 2013 21:07, Bart Schaefer <schaefer@brasslantern.com> wrote: > The one thing I'm finding missing from both places is a discussion of > how to perform a simple one-file (well, two, counting ChangeLog) push > directly from a clone of the master. Can I --amend a commit without > having a branch, or must I wait even to commit until I've edited the > ChangeLog? After you clone, your master is already a branch, so you can do whatever you want with it. origin/master is the one that's tracking the state of the repository you cloned from (by default called origin). "one-file push" is a bit strange, but yes, you can commit stuff to your master branch, amend them, and then push. What you can't do, is amend a commit that is already reachable from origin/master, iow, only amend commits you haven't pushed yet. git clone git://zsh/blabla zsh; cd zsh # hack hack hack git add myfiles; git commit -m 'informative message' git push Is the thing you're asking for? There is no need to create an extra local branch for this. > Or is creating a branch THE way, and I should ignore all > the discussion of branching for "a feature" and just create a branch > that's always there and use it repeatedly whenver I edit? This is what your 'master' branch is for :). -- Mikael Magnusson ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: One-command mail import with X-Seq: and ChangeLog 2013-04-07 19:07 ` Bart Schaefer ` (2 preceding siblings ...) 2013-04-08 9:09 ` One-command mail import with X-Seq: and ChangeLog (was: Re: Access to CVS) Mikael Magnusson @ 2013-04-11 15:10 ` Frank Terbeck 3 siblings, 0 replies; 60+ messages in thread From: Frank Terbeck @ 2013-04-11 15:10 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers Bart Schaefer wrote: [...] > I think the first thing I'm going to do unless you beat me to it is to > make zsh-am read patch emails from standard input [...] The latest code from zsh-am's git repository¹ now supports doing that. The mode is entered in two cases: 1.) There is _no_ non-option argument on the command line 2.) There is exactly _one_ non-option argument and that argument is exactly one single dash: "-" Also, that mode requires mktemp(1) to be available². Regards, Frank ¹ https://github.com/ft/zsh-am ² mktemp(1) is not POSIX, so it's not strictly portable, but widely available across many operating systems; if your system does not have it, that's though luck. ;) ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-07 9:49 ` Peter Stephenson 2012-12-07 11:03 ` Frank Terbeck @ 2012-12-11 23:05 ` Oliver Kiddle 2012-12-12 8:23 ` Frank Terbeck 1 sibling, 1 reply; 60+ messages in thread From: Oliver Kiddle @ 2012-12-11 23:05 UTC (permalink / raw) To: zsh-workers On 7 Dec, Peter Stephenson wrote: > I'm expecting (from my limited knowledge of git) that git-aware people > will do the following: > > - Play with the change locally, committing it, possibly multiple times. > I don't see any reason you'd *have* to do this, it just strikes me > as the natural way a developer used to git would work, so you have > a record in the archive of what went to the list. The ability to > do this is one of the big advantages of the distributed system. > - Send the overall diff of the changes to the mailing list. > - If it needs tweaking, there might be further local commits. > - When it looks OK, push the set of changes to the main repository. But would you want the "set of changes" to appear as several changes or one single change in the main repository? And if other changes have been applied since the patches were posted to the mailing list, would you prefer that checksums are preserved but you have a merge commit? For a project like zsh which has a small number of developers, I think it is better to keep things simple and have a linear history (avoiding merge commits). To produce that overall diff Peter mentions in the second stage, you would probably use rebase to squash all your intermediate steps. As with our current cvs practices, big changes that warrant multiple patches, also warrant multiple mailing list posts. I would also be happy if later tweaks also get squashed, especially if we're stuffing X-Seq numbers in commit messages and checksums from a git am are already invalidated. (The main advantage of git notes is that checksums are preserved so you can apply a change from the mailing list and it is handled more cleanly when the patch appears in the main repository.) Are people happy enough with the history as it is in the Sourceforge mirror. Using it as-is has advantages for people that already use it. I think that to make the switch, we essentially just need to ask Wayne to turn off his cron job. Oliver ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-11 23:05 ` Access to CVS Oliver Kiddle @ 2012-12-12 8:23 ` Frank Terbeck 2012-12-12 15:31 ` Aaron Schrab 2012-12-12 17:25 ` Oliver Kiddle 0 siblings, 2 replies; 60+ messages in thread From: Frank Terbeck @ 2012-12-12 8:23 UTC (permalink / raw) To: zsh-workers Oliver Kiddle wrote: > But would you want the "set of changes" to appear as several changes or > one single change in the main repository? And if other changes have been > applied since the patches were posted to the mailing list, would you > prefer that checksums are preserved but you have a merge commit? > > For a project like zsh which has a small number of developers, I think > it is better to keep things simple and have a linear history (avoiding > merge commits). I agree. > To produce that overall diff Peter mentions in the > second stage, you would probably use rebase to squash all your > intermediate steps. Just to clarify: You don't mean to squash everything to one blob of changes, if there were logically separated changeset in the commits before, right? You mean to use interactive rebasing to get rid of those "Crap, forgot a semicolon here and there." commits before submitting to the list? > As with our current cvs practices, big changes that > warrant multiple patches, also warrant multiple mailing list posts. I > would also be happy if later tweaks also get squashed, especially if > we're stuffing X-Seq numbers in commit messages and checksums from a git > am are already invalidated. I think git-am would still work if we had something that would scan a saved mail for the X-Seq: header, amend Subject and then feed that into git-am. > (The main advantage of git notes is that > checksums are preserved so you can apply a change from the mailing list > and it is handled more cleanly when the patch appears in the main > repository.) Sure, but how well are notes supported within git as a whole? Also, who would we make sure adding notes isn't forgotten? I think everything, that saves a manual step should be encouraged. > Are people happy enough with the history as it is in the Sourceforge > mirror. Using it as-is has advantages for people that already use it. > I think that to make the switch, we essentially just need to ask Wayne > to turn off his cron job. Pretty much, except for re-doing the $ZSH_PATCHLEVEL variable, which currently is fed the patchlevel from CVS. Regards, Frank ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-12 8:23 ` Frank Terbeck @ 2012-12-12 15:31 ` Aaron Schrab 2012-12-12 17:25 ` Oliver Kiddle 1 sibling, 0 replies; 60+ messages in thread From: Aaron Schrab @ 2012-12-12 15:31 UTC (permalink / raw) To: zsh-workers At 09:23 +0100 12 Dec 2012, Frank Terbeck <ft@bewatermyfriend.org> wrote: >Pretty much, except for re-doing the $ZSH_PATCHLEVEL variable, which >currently is fed the patchlevel from CVS. I sent a patch to change that to be generated using `git describe` in #30840, although I did note something that should be slightly modified about that in my reply to that message. I can send an updated version if necessary. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-12 8:23 ` Frank Terbeck 2012-12-12 15:31 ` Aaron Schrab @ 2012-12-12 17:25 ` Oliver Kiddle 2012-12-12 18:57 ` Bart Schaefer 1 sibling, 1 reply; 60+ messages in thread From: Oliver Kiddle @ 2012-12-12 17:25 UTC (permalink / raw) To: zsh-workers Frank Terbeck wrote: > > Just to clarify: You don't mean to squash everything to one blob of > changes, if there were logically separated changeset in the commits > before, right? > > You mean to use interactive rebasing to get rid of those "Crap, forgot a > semicolon here and there." commits before submitting to the list? Yes, exactly. If there are logically separated changesets I'd post each in a separate mailing list message. > I think git-am would still work if we had something that would scan a > saved mail for the X-Seq: header, amend Subject and then feed that into > git-am. That only really helps when someone who doesn't have permissions to push to the main repository posts a patch and someone else pushes it on their behalf. For my own patches, I'd use git commit --amend. > > > (The main advantage of git notes is that > > checksums are preserved so you can apply a change from the mailing list > > and it is handled more cleanly when the patch appears in the main > > repository.) > > Sure, but how well are notes supported within git as a whole? Also, who > would we make sure adding notes isn't forgotten? I'm not really arguing for git notes: that point was meant as context for the preceding sentence. This discussion has actually convinced me that our best approach is to amend commit messages for the X-Seq number. Correct me if I'm wrong but I got the impression that was forming as the general consensus. It also avoids having to retrospectively add notes for all past commits in the repository. And it is easy to change to notes at a later point if we change are minds. > Pretty much, except for re-doing the $ZSH_PATCHLEVEL variable, which > currently is fed the patchlevel from CVS. Aaron's patch looks good for that. I reckon we're all set to go. Oliver ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-12 17:25 ` Oliver Kiddle @ 2012-12-12 18:57 ` Bart Schaefer 2012-12-13 12:58 ` Oliver Kiddle 0 siblings, 1 reply; 60+ messages in thread From: Bart Schaefer @ 2012-12-12 18:57 UTC (permalink / raw) To: zsh-workers On Dec 12, 6:25pm, Oliver Kiddle wrote: } } If there are logically separated changesets I'd post each in } a separate mailing list message. } } > I think git-am would still work if we had something that would scan a } > saved mail for the X-Seq: header, amend Subject and then feed that into } > git-am. } } That only really helps when someone who doesn't have permissions to push } to the main repository posts a patch and someone else pushes it on their } behalf. For my own patches, I'd use git commit --amend. } } This discussion has actually convinced me that our best approach is to } amend commit messages for the X-Seq number. Correct me if I'm wrong but } I got the impression that was forming as the general consensus. } } It also avoids having to retrospectively add notes for all past commits } in the repository. And it is easy to change to notes at a later point if } we change are minds. } } I reckon we're all set to go. I would greatly appreciate it if someone would generate a summary of the conclusions of this discussion with all the various "recommended" steps that one would perform, so that it could be added as a sort of how-to in Etc/zsh-development-guide. As someone only passingly familiar with git, there are subtleties and best-practices here that I'm not yet following. And then for everyone to agree with at least the general outline of that that summary, before we make the switch -- which I further think should wait until 5.0.1 has gone out. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-12 18:57 ` Bart Schaefer @ 2012-12-13 12:58 ` Oliver Kiddle 2012-12-13 14:57 ` Simon Ruderich ` (4 more replies) 0 siblings, 5 replies; 60+ messages in thread From: Oliver Kiddle @ 2012-12-13 12:58 UTC (permalink / raw) To: zsh-workers Bart wrote: > I would greatly appreciate it if someone would generate a summary of the > conclusions of this discussion with all the various "recommended" steps > that one would perform, so that it could be added as a sort of how-to in > Etc/zsh-development-guide. Ok, how does this look? The zsh patch archive doesn't exist any more does it? Having prepared this with git, I realise that "git format-patch" doesn't really fit with the way we're used to working. It produces full e-mail headers with the expectation that the commit message forms the actual body of the e-mail. It also uses [PATCH] instead of PATCH: though that's minor. As with this message, we often include a patch in a reply. Should we recommend something else? > And then for everyone to agree with at least the general outline of that > that summary, before we make the switch -- which I further think should > wait until 5.0.1 has gone out. Yes, waiting for 5.0.1 makes sense. Oliver diff --git a/Etc/zsh-development-guide b/Etc/zsh-development-guide index db78f94..cf7ff1c 100644 --- a/Etc/zsh-development-guide +++ b/Etc/zsh-development-guide @@ -32,6 +32,7 @@ Patches ------- * Send all patches to the mailing list rather than directly to me. + Use a Subject: line starting with "PATCH:". * Send only context diffs "diff -c oldfile newfile" or unified diffs "diff -u oldfile newfile". They are much easier to read and @@ -39,7 +40,7 @@ Patches intelligently. Please make sure the filenames in the diff header are relative to the top-level directory of the zsh distribution; for example, it should say "Src/init.c" rather than "init.c" or - "zsh/Src/init.c". + "zsh/Src/init.c". Alternatively, use "git format-patch". * Please put only one bug fix or feature enhancement in a single patch and only one patch per mail message. This helps me to multiplex the many @@ -52,9 +53,37 @@ Patches * Please test your patch and make sure it applies cleanly. It takes considerably more time to manually merge a patch into the baseline code. -* There is now a zsh patch archive. To have your patches appear in the - archive, send them to the mailing list with a Subject: line starting - with "PATCH:". +Git Workflow +------------ + +* To allow changesets to be cross-referenced between the mailing list + archives and version control history, commit messages should start with + the mailing list sequence number. This number is generated by the list + server and inserted as an X-Seq: header field in the e-mail. To add + the number, you can use "git commit --amend" to change the commit. + +* Do not merge your private feature branches onto the master branch: a + linear history without merge commits is simpler to follow (and to + bisect). Both "git cherry-pick" and "git merge --ff-only" can be used + bring changes over to another branch without a merge commit. + +* It is often useful to regularly check in changes while prototyping a + solution on a private branch. When finished, it is better to deliver a + clean history. For small changes, use "git merge --squash" to get a + single changeset for the feature. Where a change can be logically + divided into separate changesets use "git rebase -i master" from the + feature branch and squash your many intermediate steps into + appropriate changesets that each do something meaningful. Post each + changeset separately to the mailing list. + +* Before pushing your changes to the main zsh repository, you can use + "git pull --rebase" to fetch any new updates from the server and + rebase your changes on top of them. You can also use "git rebase + master" from your feature branches. + +* Patches can be prepared for the mailing list with "git format-patch + origin/master". To apply patches from a mailing list message, you can + use "git am". Testing ------- ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-13 12:58 ` Oliver Kiddle @ 2012-12-13 14:57 ` Simon Ruderich 2012-12-13 15:37 ` Bart Schaefer ` (3 subsequent siblings) 4 siblings, 0 replies; 60+ messages in thread From: Simon Ruderich @ 2012-12-13 14:57 UTC (permalink / raw) To: zsh-workers [-- Attachment #1: Type: text/plain, Size: 4672 bytes --] On Thu, Dec 13, 2012 at 01:58:52PM +0100, Oliver Kiddle wrote: >> I would greatly appreciate it if someone would generate a summary of the >> conclusions of this discussion with all the various "recommended" steps >> that one would perform, so that it could be added as a sort of how-to in >> Etc/zsh-development-guide. > > Ok, how does this look? Looks good to me, see below for some minor comments. > The zsh patch archive doesn't exist any more does it? > > Having prepared this with git, I realise that "git format-patch" doesn't > really fit with the way we're used to working. It produces full e-mail > headers with the expectation that the commit message forms the actual > body of the e-mail. It also uses [PATCH] instead of PATCH: though that's I've configured mutt's $editor to fix the [PATCH] subject line, but maybe we could change the policy to allow [PATCH] in the subject. Last time I checked git format-patch can't create patches without the []. > minor. As with this message, we often include a patch in a reply. Should > we recommend something else? Those mails (for example this mail) work fine with git am. The only problems are the mail subject and the body (for the commit message). The committer could either use git commit --amend or git am -i to fix the commit message. It's not too much trouble and just requires adding the X-Seq and fixing the commit message in your $editor. Sadly git-am doesn't provide any hooks which get the original patch message as argument. Therefore we can't extract it automatically when applying the patch (extending git-am to add another hook shouldn't be too hard though). Alternatively we could provide a little wrapper script which is used to apply Zsh patches and extracts the X-Seq and adapts the subject (I could write it if you think it's a good idea). But we could use pre-applyhook to prevent accidental commits without a X-Seq number in the commit message (checks can be skipped with commit --no-verify). We could also use git-am/git-format-patch's scissors feature (man git-format-patch | less -p '^DISCUSSION'), but I think it just creates unnecessary burden for the patch sender. > diff --git a/Etc/zsh-development-guide b/Etc/zsh-development-guide > index db78f94..cf7ff1c 100644 > --- a/Etc/zsh-development-guide > +++ b/Etc/zsh-development-guide > @@ -32,6 +32,7 @@ Patches > ------- > > * Send all patches to the mailing list rather than directly to me. > + Use a Subject: line starting with "PATCH:". Maybe we should allow [PATCH] as well. > * Send only context diffs "diff -c oldfile newfile" or unified diffs > "diff -u oldfile newfile". They are much easier to read and > @@ -39,7 +40,7 @@ Patches > intelligently. Please make sure the filenames in the diff header > are relative to the top-level directory of the zsh distribution; for > example, it should say "Src/init.c" rather than "init.c" or > - "zsh/Src/init.c". > + "zsh/Src/init.c". Alternatively, use "git format-patch". > > * Please put only one bug fix or feature enhancement in a single patch and > only one patch per mail message. This helps me to multiplex the many > @@ -52,9 +53,37 @@ Patches > * Please test your patch and make sure it applies cleanly. It takes > considerably more time to manually merge a patch into the baseline code. > > -* There is now a zsh patch archive. To have your patches appear in the > - archive, send them to the mailing list with a Subject: line starting > - with "PATCH:". > +Git Workflow > +------------ > + > +* To allow changesets to be cross-referenced between the mailing list > + archives and version control history, commit messages should start with > + the mailing list sequence number. This number is generated by the list > + server and inserted as an X-Seq: header field in the e-mail. To add > + the number, you can use "git commit --amend" to change the commit. Maybe we should add: before pushing it to zsh's repository. To make it clear that --amend is only used in the local repository but not for published commits. > [snip] > + > +* Patches can be prepared for the mailing list with "git format-patch > + origin/master". To apply patches from a mailing list message, you can > + use "git am". I think we should add some information for committers how to "fix" patches sent to the mailing list (e.g. git am -i or git commit --amend, maybe combined with the custom wrapper which I mentioned above). Regards, Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-13 12:58 ` Oliver Kiddle 2012-12-13 14:57 ` Simon Ruderich @ 2012-12-13 15:37 ` Bart Schaefer 2012-12-13 16:03 ` Aaron Schrab 2012-12-13 15:50 ` Aaron Schrab ` (2 subsequent siblings) 4 siblings, 1 reply; 60+ messages in thread From: Bart Schaefer @ 2012-12-13 15:37 UTC (permalink / raw) To: zsh-workers On Dec 13, 1:58pm, Oliver Kiddle wrote: } } +* Do not merge your private feature branches onto the master branch: a } + linear history without merge commits is simpler to follow (and to } + bisect). Both "git cherry-pick" and "git merge --ff-only" can be used } + bring changes over to another branch without a merge commit. Is there any way to actually enforce this? How does one "recover" from an accidental merge commit? ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-13 15:37 ` Bart Schaefer @ 2012-12-13 16:03 ` Aaron Schrab 0 siblings, 0 replies; 60+ messages in thread From: Aaron Schrab @ 2012-12-13 16:03 UTC (permalink / raw) To: zsh-workers At 07:37 -0800 13 Dec 2012, Bart Schaefer <schaefer@brasslantern.com> wrote: >On Dec 13, 1:58pm, Oliver Kiddle wrote: >} >} +* Do not merge your private feature branches onto the master branch: a >} + linear history without merge commits is simpler to follow (and to >} + bisect). Both "git cherry-pick" and "git merge --ff-only" can be used >} + bring changes over to another branch without a merge commit. > >Is there any way to actually enforce this? If the main git repository were fully under our control, yes, a hook could be setup there to reject pushes which introduce merge commits. Unfortunately, I'm not aware of any of the free git hosting sites which allow that type of policy to be configured for repositories that they host, although I haven't really looked into that. >How does one "recover" from an accidental merge commit? If that were to happen, we'd either need to live with it or rewrite published history. I think just allowing it to stay in would be the better option, having an occasional merge in the history shouldn't introduce much confusion an is better than dealing with the mess of altering commits that were already made public. If the accidental merge is discovered before it has been pushed, or any other changes have been made to the target branch the merge can be backed out simply by using: git reset --hard HEAD~ To reset the branch and working tree to the state before the merge, allowing another try at merging the changes without creating a merge commit. This would also blow away any uncommitted changes, although those could be safely saved away using `git stash` before doing the reset and then recovered later with `git stash pop`. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-13 12:58 ` Oliver Kiddle 2012-12-13 14:57 ` Simon Ruderich 2012-12-13 15:37 ` Bart Schaefer @ 2012-12-13 15:50 ` Aaron Schrab 2012-12-13 16:13 ` Peter Stephenson 2012-12-15 18:57 ` Wayne Davison 4 siblings, 0 replies; 60+ messages in thread From: Aaron Schrab @ 2012-12-13 15:50 UTC (permalink / raw) To: zsh-workers At 13:58 +0100 13 Dec 2012, Oliver Kiddle <okiddle@yahoo.co.uk> wrote: >+* Do not merge your private feature branches onto the master branch: a >+ linear history without merge commits is simpler to follow (and to >+ bisect). Both "git cherry-pick" and "git merge --ff-only" can be used >+ bring changes over to another branch without a merge commit. The `--ff-only` option is only somewhat useful here. It merely causes the merge to be aborted if it can't be done without creating a merge commit, in which case some other method of bringing in those changes would need to be tried. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-13 12:58 ` Oliver Kiddle ` (2 preceding siblings ...) 2012-12-13 15:50 ` Aaron Schrab @ 2012-12-13 16:13 ` Peter Stephenson 2012-12-13 16:20 ` Bart Schaefer 2012-12-15 18:57 ` Wayne Davison 4 siblings, 1 reply; 60+ messages in thread From: Peter Stephenson @ 2012-12-13 16:13 UTC (permalink / raw) To: zsh-workers On Thu, 13 Dec 2012 13:58:52 +0100 Oliver Kiddle <okiddle@yahoo.co.uk> wrote: > Bart wrote: > > I would greatly appreciate it if someone would generate a summary > > of the conclusions of this discussion with all the various > > "recommended" steps that one would perform, so that it could be > > added as a sort of how-to in Etc/zsh-development-guide. > > Ok, how does this look? Probably OK, although I don't understand all the words. It might be useful to give a sample list of explicit git commands to use at each stage, in particular what you'd do for an initial commit, for updating the commit with the mailing list ID, for any kind of trickery to reduce the number of commits that get pushed, and for pushing it back (as this is for those new to git you can assume the relationship between the local archive and the remote master is simple and let the git gurus do the clever stuff). pws ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-13 16:13 ` Peter Stephenson @ 2012-12-13 16:20 ` Bart Schaefer 2012-12-13 19:13 ` Phil Pennock 0 siblings, 1 reply; 60+ messages in thread From: Bart Schaefer @ 2012-12-13 16:20 UTC (permalink / raw) To: zsh-workers On Dec 13, 4:13pm, Peter Stephenson wrote: } } It might be useful to give a sample list of explicit git commands to use } at each stage, in particular what you'd do for an initial commit, for } updating the commit with the mailing list ID, for any kind of trickery } to reduce the number of commits that get pushed, and for pushing it back Heck, I'd even like an example of the git command for creating a local feature branch. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-13 16:20 ` Bart Schaefer @ 2012-12-13 19:13 ` Phil Pennock 2012-12-14 9:22 ` Frank Terbeck 0 siblings, 1 reply; 60+ messages in thread From: Phil Pennock @ 2012-12-13 19:13 UTC (permalink / raw) To: zsh-workers On 2012-12-13 at 08:20 -0800, Bart Schaefer wrote: > Heck, I'd even like an example of the git command for creating a local > feature branch. You are normally on a branch called "master", which by strong convention tracks the remote branch "origin/master" (with the tools making it easy to reconcile). HEAD is an alias for "tip of the current branch". % git checkout -b feature_foo % vi/emacs/ed/flamewar_bait path/to/files ... % git commit -a # or git add, blah blah, git commit The "checkout -b" basically switches the current working tree state to be in the new branch named. "commit -a" is "all". You can use "-i <files>" to name explicit files, or use "git add" manually and then just "git commit". The workflow described seems to not have code pushed centrally, so instead when the changes are fixed you can use: % git rebase -i master to collapse changes since the branch-point where you split from master. If you just have the one commit and you want to change the _latest_ commit to add files, then "git commit --amend" works. This creates a new commit, with a new id (SHA1 checksum) so the old commit is not valid. Thus the caution if you've pushed the changes to where others can see and pull them, because you can end up requiring others to manually reconcile "non fast-forward" changes. Yes, you end up with stale commits no longer referenced by a branch, and much like a file-system's lost inodes, these hang around until cleaned up. You can see them with "git fsck --unreachable". Note I've not yet _needed_ to use git-fsck for anything other than curiosity and learning. But it's there. IF you want to make the code available on the server you cloned from as a branch, and accept that this involves a non-linear history (eg, a major feature change where it's worth keeping a more accurate history) then: % git push origin feature_foo [ do mailing-list stuff here ] Switch back to master: % git checkout master and get the most recent changes: % git pull then bring in your changes: % git merge feature_foo % git commit % git push Cleanup: % git branch -d feature_foo % git push origin :feature_foo It's worth understanding how git does what it does, because a lot of this is surfaced in the presented abstractions. The black boxes are mostly translucent. Until you learn the underlying layers "git reset" vs "git checkout" to revert files is confusing as hell. Or was for me. git help tutorial git help tutorial-2 git help gitcore-tutorial -Phil ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-13 19:13 ` Phil Pennock @ 2012-12-14 9:22 ` Frank Terbeck 0 siblings, 0 replies; 60+ messages in thread From: Frank Terbeck @ 2012-12-14 9:22 UTC (permalink / raw) To: zsh-workers Phil Pennock wrote: [...] > IF you want to make the code available on the server you cloned from as > a branch, and accept that this involves a non-linear history (eg, a > major feature change where it's worth keeping a more accurate history) > then: And if you just want do have a local branch, to do your work in and still want to enforce linear history, you can use the same workflow as Phil described. You just need to "replay" your changes on top of "master". "git rebase" does that. > % git push origin feature_foo > [ do mailing-list stuff here ] > > Switch back to master: > % git checkout master > and get the most recent changes: > % git pull Switch back to the feature branch: % git checkout feature_foo Rebase the feature branch on top of new changes that were just pulled: % git rebase master This does the following (ASCII graphs from git's manual): Commit situation before the rebase: A---B---C topic / ... D---E---F---G master And after: A'--B'--C' topic / ... D---E---F---G master This essentially replays the commits from the topic (or feature) branch on top of master. That creates commits with different SHA1 sums, hence the apostrophes with the rebased branch. > then bring in your changes: > % git merge feature_foo That merge is a fast-forward then, because it just involves putting the pointer of the master branch to the tip of the topic branch; because its linear history again - no real merges involved at all. > % git commit > % git push [...] > git help tutorial > git help tutorial-2 > git help gitcore-tutorial Those are actually pretty helpful indeed. Regards, Frank -- In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC 1925 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-13 12:58 ` Oliver Kiddle ` (3 preceding siblings ...) 2012-12-13 16:13 ` Peter Stephenson @ 2012-12-15 18:57 ` Wayne Davison 4 siblings, 0 replies; 60+ messages in thread From: Wayne Davison @ 2012-12-15 18:57 UTC (permalink / raw) To: Oliver Kiddle; +Cc: Zsh list [-- Attachment #1: Type: text/plain, Size: 780 bytes --] On Thu, Dec 13, 2012 at 4:58 AM, Oliver Kiddle <okiddle@yahoo.co.uk> wrote: > +* Before pushing your changes to the main zsh repository, you can use > + "git pull --rebase" to fetch any new updates from the server and > + rebase your changes on top of them. It's nice to create an alias for this to make it less likely that someone pulls and creates a merge commit. I like this: git config --global alias.up 'pull --rebase --stat' That lets you just say "git up" to update to the latest code, rebasing any of your local changes. It also comments on what files were changed (the --stat part), which I also like. Someone might also be interested in my scm helper aliases if you find yourself changing between several type of scm: http://opencoder.net/repos/ ..wayne.. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-04 22:51 ` Phil Pennock 2012-12-05 0:33 ` Oliver Kiddle @ 2012-12-05 2:26 ` Vin Shelton 1 sibling, 0 replies; 60+ messages in thread From: Vin Shelton @ 2012-12-05 2:26 UTC (permalink / raw) To: Vin Shelton, zsh-workers On Tue, Dec 4, 2012 at 5:51 PM, Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote: > Perhaps the CVS-on-wire protocol server has issues; can you switch to > SSH-based access? I see that ssh access does work; thanks, Phil. - Vin ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS @ 2012-12-14 14:44 Oliver Kiddle 2012-12-14 15:09 ` Peter Stephenson 0 siblings, 1 reply; 60+ messages in thread From: Oliver Kiddle @ 2012-12-14 14:44 UTC (permalink / raw) To: Zsh workers Aaron Schrab wrote: > The `--ff-only` option is only somewhat useful here. It merely causes > the merge to be aborted if it can't be done without creating a merge > commit, in which case some other method of bringing in those changes > would need to be tried. I was trying to keep it reasonably brief. Feel free to suggest alternative wording. Aaron Schrab wrote: > At 07:37 -0800 13 Dec 2012, Bart Schaefer <schaefer@brasslantern.com> wrote: > >Is there any way to actually enforce this? > > If the main git repository were fully under our control, yes, a hook > could be setup there to reject pushes which introduce merge commits. For sourceforge, we can get at the repository using the shell access. The documentation mentions commit email hooks so others are probably possible. That said, I'm not sure it would be wise because it would also block merges from public feature branches. Peter Stephenson wrote: > It might be useful to give a sample list of explicit git commands to use > at each stage, in particular what you'd do for an initial commit, for > updating the commit with the mailing list ID, for any kind of trickery > to reduce the number of commits that get pushed, and for pushing it back > (as this is for those new to git you can assume the relationship between > the local archive and the remote master is simple and let the git gurus > do the clever stuff). Is that a suggestion for the contents of Etc/zsh-development-guide or just a case that it'd be useful. I'm assuming the latter - it's not like we have an introduction to CVS, autoconf, C etc in the file. Anyway, in that case it seems Phil and Frank have already answered this. Oliver ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-14 14:44 Oliver Kiddle @ 2012-12-14 15:09 ` Peter Stephenson 2012-12-14 19:29 ` Phil Pennock 0 siblings, 1 reply; 60+ messages in thread From: Peter Stephenson @ 2012-12-14 15:09 UTC (permalink / raw) To: Zsh workers On Fri, 14 Dec 2012 15:44:22 +0100 Oliver Kiddle <okiddle@yahoo.co.uk> wrote: > Peter Stephenson wrote: > > It might be useful to give a sample list of explicit git commands > > to use at each stage, in particular what you'd do for an initial > > commit, for updating the commit with the mailing list ID, for any > > kind of trickery to reduce the number of commits that get pushed, > > and for pushing it back (as this is for those new to git you can > > assume the relationship between the local archive and the remote > > master is simple and let the git gurus do the clever stuff). > > Is that a suggestion for the contents of Etc/zsh-development-guide or > just a case that it'd be useful. I'm assuming the latter - it's not > like we have an introduction to CVS, autoconf, C etc in the file. > Anyway, in that case it seems Phil and Frank have already answered > this. If there was a compact enough summary to go in the development guide, that would be great, though it's not crucial. The problem is git allows a zillion different ways of doing it whereas in CVS you were restricted to committing what you've changed, and that was it. I'm still hoping for a simple, straightforward list of the basic commands you'd need to use *not* involving the manifold ramifications of branches here, there and everywhere. Presumably this isn't more than half a dozen commands or so. pws ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-14 15:09 ` Peter Stephenson @ 2012-12-14 19:29 ` Phil Pennock 2012-12-15 18:09 ` Peter Stephenson 2012-12-16 9:50 ` Phil Pennock 0 siblings, 2 replies; 60+ messages in thread From: Phil Pennock @ 2012-12-14 19:29 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh workers On 2012-12-14 at 15:09 +0000, Peter Stephenson wrote: > I'm still hoping for a simple, straightforward list of the basic > commands you'd need to use *not* involving the manifold ramifications of > branches here, there and everywhere. Presumably this isn't more than > half a dozen commands or so. % $VISUAL file1.c file2.c new-file3.c % git add new-file3.c % git commit -a % git push "git commit -a" automatically finds files which are tracked and have been modified, but doesn't pick up files newly tracked. "git add" starts tracking a file. "git commit -a -i new-file3.c" should also add the file. If you want to be more selective, then for each file changed, "git add" it to stage it in the index for the next commit, then just "git commit" which will only commit the manually-staged files. "git push" assumes that you're on the master branch and the repository was created by cloning it from some place, with default options. Try to get the most recent version of git you can, they're in the middle of switching "git push" semantics to be saner/safer/cleaner by default ("only push the current branch, and only if this branch exists on the remote server") and you probably want this new default. Git 1.8+ Everything else is about building on that. It's just that with an existing repository and code-base where complexity is already an issue, you're in the unfortunate position of trying to avoid making the repository complicated and so folks are suggesting ways to minimise the history complexity of the repository, and so your learning curve is even steeper. I faced the same problems when Exim switched. :-/ -Phil ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-14 19:29 ` Phil Pennock @ 2012-12-15 18:09 ` Peter Stephenson 2012-12-15 19:07 ` Wayne Davison 2012-12-16 9:50 ` Phil Pennock 1 sibling, 1 reply; 60+ messages in thread From: Peter Stephenson @ 2012-12-15 18:09 UTC (permalink / raw) To: Phil Pennock, Zsh workers On Fri, 14 Dec 2012 14:29:45 -0500 Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote: > On 2012-12-14 at 15:09 +0000, Peter Stephenson wrote: > > I'm still hoping for a simple, straightforward list of the basic > > commands you'd need to use *not* involving the manifold ramifications of > > branches here, there and everywhere. Presumably this isn't more than > > half a dozen commands or so. > > % $VISUAL file1.c file2.c new-file3.c > % git add new-file3.c > % git commit -a > % git push Thanks, that's pretty much what I was expecting... In this (ultra-simple) case, presumably we're assuming the mailing list link gets added immediately in the commit log. If anybody thinks that above *isn't* the basic sequence, or that their own preferred procedure is something other than a more sophisticated form of theabove, it would be good to hear. -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-15 18:09 ` Peter Stephenson @ 2012-12-15 19:07 ` Wayne Davison 2012-12-15 21:07 ` Aaron Schrab 0 siblings, 1 reply; 60+ messages in thread From: Wayne Davison @ 2012-12-15 19:07 UTC (permalink / raw) To: Peter Stephenson; +Cc: Phil Pennock, Zsh workers [-- Attachment #1: Type: text/plain, Size: 1104 bytes --] On Sat, Dec 15, 2012 at 10:09 AM, Peter Stephenson < p.w.stephenson@ntlworld.com> wrote: > If anybody thinks that above *isn't* the basic sequence, or that their > own preferred procedure is something other than a more sophisticated > form of theabove, it would be good to hear. > It's always good to view your own commit to double-check it, and to also to check for missed files. So I'd suggest adding "git show" after "git commit -a" (that lets you look over your latest commit) and "git status" (lets you look for uncommitted files). And then, right before the "git push", toss in "git pull --rebase" to remind folks to check for remote changes prior to pushing (using --rebase instead of merge). Finally, it would be good to mention tags somewhere, since it requires a separate "git push --tags" if you want your tags to become public, but I doubt we'd want to mention it in the basic sequence, since it's likely we just want things like release tags. % $VISUAL file1.c file2.c new-file3.c % git add new-file3.c % git commit -a % git show % git status % git pull --rebase % git push ..wayne.. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-15 19:07 ` Wayne Davison @ 2012-12-15 21:07 ` Aaron Schrab 0 siblings, 0 replies; 60+ messages in thread From: Aaron Schrab @ 2012-12-15 21:07 UTC (permalink / raw) To: zsh-workers At 11:07 -0800 15 Dec 2012, Wayne Davison <wayned@users.sourceforge.net> wrote: >It's always good to view your own commit to double-check it, and to >also to check for missed files. So I'd suggest adding "git show" after >"git commit -a" (that lets you look over your latest commit) It's even nicer to look it over before committing. For that I've done: git config --global alias.ci 'commit -v' Then I always use `git ci` rather than `git commit`. This causes the diff of what I'm going to be committing to be included in the file where I create the commit message, so I can look it over there. This can also help for editing the commit message by having modified functions included in the edit buffer so that their names are available for completion if I want to mention them in the message. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-14 19:29 ` Phil Pennock 2012-12-15 18:09 ` Peter Stephenson @ 2012-12-16 9:50 ` Phil Pennock 2012-12-16 18:14 ` Bart Schaefer 1 sibling, 1 reply; 60+ messages in thread From: Phil Pennock @ 2012-12-16 9:50 UTC (permalink / raw) To: zsh-workers; +Cc: Peter Stephenson On 2012-12-14 at 14:29 -0500, Phil Pennock wrote: > "git commit -a" automatically finds files which are tracked and have > been modified, but doesn't pick up files newly tracked. "git add" > starts tracking a file. *sigh* Dumbass mis-statement on my part, sorry. "git commit -a" doesn't pick up newly created files, because they're not tracked (except just enough to say "not tracked" and to be handled by commands like "git stash"). > If you want to be more selective, then for each file changed, "git add" > it to stage it in the index for the next commit, then just "git commit" > which will only commit the manually-staged files. To be clear: "git add" is not "add tracking this new file to the repository", it's "add this file to the index of changes to be in the next commit", where such a change _might_ be the creation of a new file, or might simply be "I changed it, include it". -Phil ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Access to CVS 2012-12-16 9:50 ` Phil Pennock @ 2012-12-16 18:14 ` Bart Schaefer 0 siblings, 0 replies; 60+ messages in thread From: Bart Schaefer @ 2012-12-16 18:14 UTC (permalink / raw) To: zsh-workers On Dec 16, 4:50am, Phil Pennock wrote: } } *sigh* Dumbass mis-statement on my part, sorry. OK, I now count about ten messages *since* Oliver's summary in 30877 that have useful information about git procedures applicable to using it for zsh in conjuction with the mailing list for patches. Anybody want to summarize *again*? As PWS noted, there really wasn't much reason for zsh-development-guide to have this kind of detail for CVS, because CVS doesn't have very many options for how to use it. Git is complex enough that I think we should give additional guidance to avoid missteps. ^ permalink raw reply [flat|nested] 60+ messages in thread
end of thread, other threads:[~2013-04-11 15:10 UTC | newest] Thread overview: 60+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-12-04 22:32 Access to CVS Vin Shelton 2012-12-04 22:51 ` Phil Pennock 2012-12-05 0:33 ` Oliver Kiddle 2012-12-05 3:14 ` Phil Pennock 2012-12-05 9:40 ` Bart Schaefer 2012-12-05 11:26 ` Phil Pennock 2012-12-05 12:11 ` Frank Terbeck 2012-12-05 21:13 ` Aaron Schrab 2012-12-05 23:34 ` Aaron Schrab 2012-12-05 19:50 ` Peter Stephenson 2012-12-06 19:59 ` Peter Stephenson 2012-12-07 0:05 ` Aaron Schrab 2012-12-07 7:13 ` Alex Ogier 2012-12-07 9:34 ` Frank Terbeck 2012-12-07 15:11 ` Aaron Schrab 2012-12-07 15:37 ` François Revol 2012-12-07 16:06 ` Aaron Schrab 2012-12-07 9:29 ` Frank Terbeck 2012-12-07 10:57 ` Christian Neukirchen 2012-12-07 11:08 ` Frank Terbeck 2012-12-07 11:38 ` Frank Terbeck 2012-12-07 15:31 ` Bart Schaefer 2012-12-07 16:01 ` Aaron Schrab 2012-12-07 9:49 ` Peter Stephenson 2012-12-07 11:03 ` Frank Terbeck 2013-03-17 14:55 ` Simon Ruderich 2013-04-04 13:38 ` Simon Ruderich 2013-04-05 16:57 ` One-command mail import with X-Seq: and ChangeLog (was: Re: Access to CVS) Frank Terbeck 2013-04-07 19:07 ` Bart Schaefer 2013-04-07 19:48 ` One-command mail import with X-Seq: and ChangeLog Simon Ruderich 2013-04-07 21:08 ` Bart Schaefer 2013-04-07 21:14 ` Frank Terbeck 2013-04-07 21:51 ` Simon Ruderich 2013-04-07 21:08 ` Frank Terbeck 2013-04-08 9:09 ` One-command mail import with X-Seq: and ChangeLog (was: Re: Access to CVS) Mikael Magnusson 2013-04-11 15:10 ` One-command mail import with X-Seq: and ChangeLog Frank Terbeck 2012-12-11 23:05 ` Access to CVS Oliver Kiddle 2012-12-12 8:23 ` Frank Terbeck 2012-12-12 15:31 ` Aaron Schrab 2012-12-12 17:25 ` Oliver Kiddle 2012-12-12 18:57 ` Bart Schaefer 2012-12-13 12:58 ` Oliver Kiddle 2012-12-13 14:57 ` Simon Ruderich 2012-12-13 15:37 ` Bart Schaefer 2012-12-13 16:03 ` Aaron Schrab 2012-12-13 15:50 ` Aaron Schrab 2012-12-13 16:13 ` Peter Stephenson 2012-12-13 16:20 ` Bart Schaefer 2012-12-13 19:13 ` Phil Pennock 2012-12-14 9:22 ` Frank Terbeck 2012-12-15 18:57 ` Wayne Davison 2012-12-05 2:26 ` Vin Shelton 2012-12-14 14:44 Oliver Kiddle 2012-12-14 15:09 ` Peter Stephenson 2012-12-14 19:29 ` Phil Pennock 2012-12-15 18:09 ` Peter Stephenson 2012-12-15 19:07 ` Wayne Davison 2012-12-15 21:07 ` Aaron Schrab 2012-12-16 9:50 ` Phil Pennock 2012-12-16 18:14 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).