[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: I created #17570 about the Windows-related improvements, so this can finally be closed. -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker

[issue14468] Update cloning guidelines in devguide

Roundup Robot added the comment: New changeset 7a707540391e by Ezio Melotti in branch 'default': #14468: add FAQs about merge conflicts, null merges, and heads merges. http://hg.python.org/devguide/rev/7a707540391e -- ___ Python tracker

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: The attached patch fixes the typo and mentions ``hg heads ``. > I think a version of your 6 step display would be helpful. It was for me. The FAQ already describes the general approach (merge heads in each branch and then merge branches as usual). The worst-cas

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Removed file: http://bugs.python.org/file29394/issue14468-new-faqs.diff ___ Python tracker ___ ___ Python-bugs-list

[issue14468] Update cloning guidelines in devguide

Terry J. Reedy added the comment: I now understand what I should have done. After pulling and updating, 1. Make sure there is only 1 head per branch by using 'hg heads *. Merge all but only pairs revealed by that command. * 'hg heads' without giving a branch lists all heads in all branches, in

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: > Question: commit to 3.2, merge forward without change, push, and message is > '... new > remote head in 3.2'. Is 3.2 really the only branch with a head conflict? I don't remember the details of the error message, but you can use "hg heads" to verify that. In

[issue14468] Update cloning guidelines in devguide

Terry J. Reedy added the comment: For the null merge entry, /filed/files/. The "create new remote heads". is really needed. I handled a situation wrong again today. Question: commit to 3.2, merge forward without change, push, and message is '... new remote head in 3.2'. Is 3.2 really the only

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: The attached patch adds 3 new FAQs: * How do I solve merge conflicts? * How do I make a null merge? * I got "abort: push creates new remote heads!" while pushing, what do I do? It also replaces the overly generic "How do I find out which revisions need merging

[issue14468] Update cloning guidelines in devguide

Roundup Robot added the comment: New changeset 50e726533391 by Ezio Melotti in branch 'default': #14468: move a paragraph and link to the list of branches. http://hg.python.org/devguide/rev/50e726533391 -- ___ Python tracker

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: Yes, it should be added back in the FAQs. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: Ezio, did you delete the section on null-merging in your commits? I don't see it in the devguide anymore. -- ___ Python tracker ___ __

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: I went through all the messages on this issue, and I'll address them here. There's enough material for two new issues (advanced FAQs, and improvements about Windows docs), and a few minor issues that can be discussed and fixed as part of this issues before clos

[issue14468] Update cloning guidelines in devguide

Terry J. Reedy added the comment: I have no intention of excluding you ;-). Please comment on any or all of the other 19. But if an issue is stuck with inadequate or conflicting developer opinion, getting supplemental opinions from target users, as in "There is a proposal to change 'abc' to 'x

[issue14468] Update cloning guidelines in devguide

Ned Deily added the comment: "I think the core-mentorship list would be one place to get more opinions if more are needed." Keep in mind that the core-mentorship list is a closed list so any discussions there would take place without direct participation of the (many?) core developers, like m

[issue14468] Update cloning guidelines in devguide

Terry J. Reedy added the comment: While multiple, spaced, commits might have been better, if the first had been made at least 6 months ago, I agree that the best thing *now* was to commit these as a base for further improvements. There are 19 other open devguide issues to review and close as o

[issue14468] Update cloning guidelines in devguide

Roundup Robot added the comment: New changeset a50e537c5914 by Ezio Melotti in branch 'default': #14468: document the use of the share extension as the suggested approach for core developers. http://hg.python.org/devguide/rev/a50e537c5914 New changeset 3e213eaf85a6 by Ezio Melotti in branch 'de

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: This was a somewhat major rewrite. The fact that we had no rietveld available made things more complicated on the reviewer side, and splitting the patch in smaller chunks made things more complicated on my side. FWIW I have 2 major doc issues up next: #4153 and

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: > But, surely at this point, it would be easier to get meaningful additional > review after the current set of changes are committed rather than continually > redoing a large set of patches. This was my reason for asking early on that the changes be proposed a

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: OK, I'll commit 1-6 and 7-8 then. After that we can further improve things starting from there. > it would be easier to get meaningful additional review after the > current set of changes are committed rather than continually redoing a > large set of patches.

[issue14468] Update cloning guidelines in devguide

Ned Deily added the comment: ISTM, committing changes to the devguide is fundamentally different from committing a change to Python itself. The devguide has a much smaller and focused audience, does not have compatibility considerations, it's continuously releasable etc etc. So there's no ne

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: For the record, I don't recall *any* changes being made to any of the patches in response to mine or others' comments, other than dividing them up. So we're not talking about perfection. If they're going to be committed as is, it might as well be one patch.

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: > Perfect is the enemy of good. I vote for just committing it, then > Chris can propose additional fixes/changes in a subsequent patch. Agreed. Chris, any preference about the number of commits (8 separate commits, 1-6 + 7-8, 2 on its own)? --

[issue14468] Update cloning guidelines in devguide

Nick Coghlan added the comment: Perfect is the enemy of good. I vote for just committing it, then Chris can propose additional fixes/changes in a subsequent patch. On 26 Feb 2013 09:52, "Chris Jerdonek" wrote: > > Chris Jerdonek added the comment: > > > I still fail to understand what are you t

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: > I still fail to understand what are you trying to achieve. My goal is to reach consensus on changes and have them committed. In its current form, I don't agree with the patch. The length of the comment thread and the length of the patch has discouraged me

[issue14468] Update cloning guidelines in devguide

Antoine Pitrou added the comment: I haven't really followed the discussion here, but both patches look ok to me (the committing.rst one, especially, is a welcome cleanup). -- ___ Python tracker ___

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: > I'm going to start proposing smaller issues off of this one I still fail to understand what are you trying to achieve. If you want to further dissect my patches, hand picking chunks and reorder them in order to obtain even more patches, I'll just close this i

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: As discussed above and because this comment thread is getting very long, I'm going to start proposing smaller issues off of this one. In this way we can start committing as we reach agreement, and hash out any disagreements in more focused contexts around sma

[issue14468] Update cloning guidelines in devguide

Terry J. Reedy added the comment: I meant one pull and multiple updates (instead of the multiple 'pull -u's I have now). -- ___ Python tracker ___ __

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: > I think it would be good to have a separate subsection dedicated just > to the setting up portion of multiple clones with the share extension I'm not sure that's necessary though, given how simple it is (enable share extension, "hg share source dest", repeat)

[issue14468] Update cloning guidelines in devguide

Terry J. Reedy added the comment: As someone who previously tried but failed to setup shared clones, to avoid the apparently senseless copying of multiple copies of .hg/store, because of the inadequate disjointed doc, I like patch 1. I am using it now to redo my setup and batch file. I think h

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: > The "Clones setup" section is not about "how to set up a clone", but "how do > I do these steps depending on the specific setup I'm using" (single or > multiple clones). Then the section should be called something like "Cloning approaches" rather than "Clon

[issue14468] Update cloning guidelines in devguide

Terry J. Reedy added the comment: > Do you you mean s/update/clone/? duh, yes > I don't think the devguide should cover tortoisehg. Given the obnoxiousness of Command Prompt, and how foreign it is to working on Windows, I think maybe there should be an addendum *somewhere*, but I don't expect

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: > The current "1-add_clones_setup.diff" patch mixes things by including > info on applying, committing, and merging a patch under the section on > setting things up. The goal of that section is to provide an overview of all the steps that a committer has to fol

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: For reasons I stated above, I think it will help to break this issue into smaller, self-contained parts as we go -- even if some of the issues turn out to be short-lived. For example, an issue can be created for adding to the docs a section on how to set up m

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: I could mention mercurial.ini too, but I don't think the devguide should cover tortoisehg. All the commands should work fine on Windows too. > I don't think that is actually used as I created the clones with > hg update rather than hg share. Do you you mean s/u

[issue14468] Update cloning guidelines in devguide

Terry J. Reedy added the comment: Looking at patch 1. On Windows, ~/.hgrc is $HOME$/mercurial.ini. On my win7 machine, that translates to C:/Users/Terry/mercurial.ini. I think it would be different on xp. But with TortoiseHG/Workbench, one should better use the Settings dialogs than edit directl

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: Thanks for waiting and for posting the patches here. I think the second patch "2-move_two_sections.diff" should be committed now, along with making "Working with Mercurial" a higher-level header (as it is done in the aggregate patch). This will separate the

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: I extracted the diffs and attached them to the issue. The first 6 patches update committing.rst: [1]: https://bitbucket.org/ezio_melotti/devguide-14468/commits/c2fca99bdb7212c4815d9fe6b0c869bb4358886a [2]: https://bitbucket.org/ezio_melotti/devguide-14468/commits

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Added file: http://bugs.python.org/file29150/1-6-committing.rst.diff ___ Python tracker ___ ___ Python-bugs-list mai

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Added file: http://bugs.python.org/file29151/7-8-faqs.rst.diff ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Added file: http://bugs.python.org/file29147/6-remove_outdated_sections.diff ___ Python tracker ___ ___ Python-bugs-

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Added file: http://bugs.python.org/file29149/8-update_faqs.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Added file: http://bugs.python.org/file29146/5-update_merge_between_major_versions.diff ___ Python tracker ___ ___

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Added file: http://bugs.python.org/file29145/4-update_merge_within_same_version.diff ___ Python tracker ___ ___ Pyt

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Added file: http://bugs.python.org/file29142/1-add_clones_setup.diff ___ Python tracker ___ ___ Python-bugs-list mai

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Added file: http://bugs.python.org/file29148/7-move_faq_in_two_subsections.diff ___ Python tracker ___ ___ Python-bu

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Added file: http://bugs.python.org/file29144/3-update_active_branches_and_mergin_order.diff ___ Python tracker ___

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Added file: http://bugs.python.org/file29143/2-move_two_sections.diff ___ Python tracker ___ ___ Python-bugs-list ma

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Removed file: http://bugs.python.org/file28540/issue14468.diff ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Removed file: http://bugs.python.org/file28629/committing.rst ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Removed file: http://bugs.python.org/file28628/issue14468-2.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : -- hgrepos: -170 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: Because this is a patch for the devguide, so we cannot use Rietveld for the review. -- ___ Python tracker ___ ___

[issue14468] Update cloning guidelines in devguide

Éric Araujo added the comment: Let’s stay friends here :) Why not remove the existing patches here, export the 8 changesets as patches, attach them here, let people comment? (I’m not keen on having discussion outside of our system) -- ___ Python t

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: > The point is to allow a manageable discussion to take place around > points of contention That can be done as (possibly inline) comments on bitbucket on the individual commits. > while making forward commit progress along the way. I'm not sure how you intend

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: The point is to allow a manageable discussion to take place around points of contention while making forward commit progress along the way. I have suggestions right now, but the current massive batch of changes makes it too unwieldy. The incremental commits

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: I'm not sure what's the point though. The repo on bitbucket provides an easy way to review individual changes, and pushing everything at once prevents history pollution (assuming you consider 8 related changesets as pollution). That's similar to the process we

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: I see ways that the changes can be proposed and committed incrementally. I can start proposing those. -- ___ Python tracker ___ __

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: Yes, I was planning to collapse them in a single patch and push only that. I don't think they can be further divided. In the moment I add the paragraph about setting up the multiple repos using "hg share" the old description becomes unnecessary, the instructio

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: Also, I would be happy to start that process using the work that you have done. -- ___ Python tracker ___ __

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: My understanding is that the commits are all or nothing. In other words, they all need to be reviewed before any are committed. I would like for the patches to be reviewed and committed individually so the review process is more manageable and people can par

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: On the repo I created (https://bitbucket.org/ezio_melotti/devguide-14468) there are separate commits that include smaller changes. The patches attached to this issue are outdated. -- ___ Python tracker

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: I would like to request again that these changes be proposed and committed in smaller chunks. I have comments of a basic nature that would be much easier to discuss and address in the context of smaller patches. Otherwise, the discussion isn't manageable bec

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: If there are no comments I'll commit this during the weekend. -- ___ Python tracker ___ ___ Python-bug

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: I now divided and regrouped the FAQs in two sections, one "for everyone" and one "for core developers". I'm not sure what to do with the "long-term development of features" section. One one hand I would prefer to move it away from committing.rst, but on the oth

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: I made a separate repo to implement this and divided the previous commits in smaller ones: https://bitbucket.org/ezio_melotti/devguide-14468 If this is OK, I'll start regrouping the FAQs in faqs.rst and then move there the section about long-term development of f

[issue14468] Update cloning guidelines in devguide

Nick Coghlan added the comment: The combination of the last two suggestions sounds good to me. -- ___ Python tracker ___ ___ Python-bu

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: I used FAQ-style titles to make easier to find the solution starting from a problem ("how do I do X?") and because I was planning to add more, but I can revert them to normal titles. So that would result in 4 sections: * Active branches (was "In what branches sh

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: I think it could cause confusion to have FAQs spread across two different files because then we'll have to distinguish between two FAQs in our hyperlinks, and it won't be obvious which FAQ page contains which questions. I would recommend creating a new section

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: I added more comments on bitbucket to indicate the new parts, the ones that have been moved, and the ones that have been removed. That should make reviews easier. I still haven't looked at the original FAQs (in faqs.rst), and still have to decide what should g

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: I just talked to Ezio on IRC about this. I think it will be a lot easier to review and see what's going on with these changes if they are put forth in smaller, bite-sized pieces and committed incrementally. It's harder to understand and have a dialogue about

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: FTR I created a bitbucket clone of the devguide to make reviews easier: Here you can find the rendered output: https://bitbucket.org/ezio_melotti/devguide/src/default/committing.rst?at=default Here you can find the patches I applied and comment on them: https://

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: Okay, it looks like you can't do it. It failed with a "repository is unrelated" error. -- ___ Python tracker ___ _

[issue14468] Update cloning guidelines in devguide

Changes by Chris Jerdonek : -- hgrepos: -169 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: Sorry, my apologies for the mess-ups! -- hgrepos: +170 ___ Python tracker ___ ___ Python-bugs-list m

[issue14468] Update cloning guidelines in devguide

Changes by Chris Jerdonek : -- hgrepos: +169 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue14468] Update cloning guidelines in devguide

Changes by Chris Jerdonek : -- hgrepos: -168 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue14468] Update cloning guidelines in devguide

Changes by Chris Jerdonek : -- hgrepos: +168 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: > Can you try? I would be surprised if it didn't. IIRC it does a diff between the head of the cpython repo and the head of the linked one. > Okay, then it sounds like they're more like sections that fit into > the natural flow of the main body of text. Yes, t

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: > I'm not sure the remote hg repo supports non-cpython repos. Can you try? I would be surprised if it didn't. > What I was doing was converting the current prose in smaller FAQ-like sections Okay, then it sounds like they're more like sections that fit into t

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: > Since this patch is on the longer side, would it be possible to use > the "Remote hg repo" feature so Rietveld will work? I was actually thinking about doing this for the devguide and for the peps repos, using the "components" to determine what repo should be

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: Since this patch is on the longer side, would it be possible to use the "Remote hg repo" feature so Rietveld will work? I assume this is possible for devguide patches. Regarding the FAQ, it seems preferable to me to keep all questions in the FAQ, even if non

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: I just noticed that the devguide already contains a section in the FAQ about Mercurial. Would it make sense to move/keep questions for committers only in the committing.rst page, and leave the generic question in faq.rst? -- ___

[issue14468] Update cloning guidelines in devguide

Changes by Ezio Melotti : Added file: http://bugs.python.org/file28629/committing.rst ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: Here is another iteration of the patch. I removed some of the old material, added half of the FAQs and the title and outline for the other FAQs. If the structure looks good I'll proceed. -- assignee: sandro.tosi -> ezio.melotti Added file: http://bugs.py

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: It can probably be added to the list of "FAQs", or mentioned together with null merges. -- ___ Python tracker ___ ___

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: One thing that occurred to me is that it is often or usually not sufficient to go from 2.7 to 3.2 and on forward because applying a patch made against the default branch loses information if first applied to an earlier branch. The given workflow assumes no lo

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: > I would break up the 20 lines of command-line commands. I would have to find a compromise for this, because on one hand it's convenient to have all the commands in a single place (so it's easy to get an overview), but on the other hand that block includes seve

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: Content-wise the patch looks pretty good. I agree with the recommendations. A couple suggestions though: I would break up the 20 lines of command-line commands. Right now that chunk is a bit too long to grasp meaningfully. My suggestion would be to break i

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: The attached patch adds a couple of section about the single and multiple clones approaches. The patch is still incomplete, because the rest of the page should be adapted to the new content (in particular the old sections should be removed, and the whole structu

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: Note that "hg graft" is already mentioned/discussed in the devguide here: http://docs.python.org/devguide/committing.html#porting-between-major-versions -- ___ Python tracker

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: "hg graft" should also be mentioned. I now use "hg graft 2.7" instead of "hg export 2.7 | hg import -" to copy changeset from 2.7 to 3.2 (and then merge on 3.3/3.x). -- ___ Python tracker

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: FTR I now switched to hg share, and while I think it's a better option for committers that work on several branches on a daily basis, it might not be the same for contributors that usually prepare patches against default. --

[issue14468] Update cloning guidelines in devguide

Changes by Mike Hoy : -- nosy: -mikehoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue14468] Update cloning guidelines in devguide

Changes by Mike Hoy : -- nosy: +mikehoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue14468] Update cloning guidelines in devguide

Éric Araujo added the comment: FWIW I agree with Antoine’s comments. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: You could mention "hg out" where you talk about pushing all the changes. About hg graft, I would assume that most of the patches grafted from 3.x don't work right away on 2.7, or if the graft work the code might still need to be changed. How do you deal with th

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: > I think the aim of that part of the devguide is to give one clear, simple, > working way to operate on different branches at the same time. The change can be as simple as adding a sentence along the lines of, "Also see the version control section of the FAQ

[issue14468] Update cloning guidelines in devguide

Sandro Tosi added the comment: I think the aim of that part of the devguide is to give one clear, simple, working way to operate on different branches at the same time. Additional workflows can be presented, but probably in another place (like the FAQ indeed). What others thing about this? --

[issue14468] Update cloning guidelines in devguide

Antoine Pitrou added the comment: Sandro, I find your patch is really a regression: -* Then clone it to create another local repository which is then used to - checkout branch 3.2:: +* Then clone it to create another local repository for the 3.2 branch:: This makes the terminology ambiguous.

  1   2   >