[PATCH] Improved example "To move the whole tree into a subdirectory..." to not fail when early commits are empty.
Previously this example would fail if the oldest commit(s) in any filtered branch is/are empty (no files) because the index would not change, and the mv would fail with: mv: cannot stat /index.new': No such file or directory This commonly occurs with histories created from git-svn-clone. The updated example checks whether the index file has been created before attempting the mv. The empty commit is retained. See http://stackoverflow.com/questions/7798142/error-combining-git-repositories-into-subdirs for an example and explanation. Signed-off-by: Brett Randall <javabr...@gmail.com> --- Documentation/git-filter-branch.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index 003731f..271d5b0 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -385,7 +385,7 @@ git filter-branch --index-filter \ 'git ls-files -s | sed "s-\t\"*-/-" | GIT_INDEX_FILE=$GIT_INDEX_FILE.new \ git update-index --index-info && -mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD +if [ -f "$GIT_INDEX_FILE.new" ]; then mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"; fi' HEAD --- -- 2.8.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Doc, git-svn, added mention of config key: svn-remote.name.include-paths
I send this small doc-patch back in June[1], but it may not have come through properly, or may have been lost, so I'm resending it. Thanks Brett [1] http://marc.info/?l=gitm=143313445425214w=2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Doc, git-svn, added mention of config key: svn-remote.name.include-paths
Signed-off-by: Brett Randall javabr...@gmail.com --- Documentation/git-svn.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 11d1e2f..0c0f60b 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -174,6 +174,9 @@ Skip branches and tags of first level directories;; (including automatic fetches due to 'clone', 'dcommit', 'rebase', etc) on a given repository. '--ignore-paths' takes precedence over '--include-paths'. ++ +[verse] +config key: svn-remote.name.include-paths --log-window-size=n;; Fetch n log entries per request when scanning Subversion history. -- 2.5.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Improved example To move the whole tree into a subdirectory....
Previously this example would fail if the history contained any empty commit, because the index would not change, and the mv would fail with: mv: cannot stat redacted/index.new': No such file or directory The updated example checks whether the index file has been created before attempting the mv. The empty commit is retained. See http://stackoverflow.com/questions/7798142/error-combining-git-repositories-into-subdirs for an example and explanation. Signed-off-by: Brett Randall javabr...@gmail.com --- Documentation/git-filter-branch.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index 73fd9e8..0b9e690 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -385,7 +385,7 @@ git filter-branch --index-filter \ 'git ls-files -s | sed s-\t\*-newsubdir/- | GIT_INDEX_FILE=$GIT_INDEX_FILE.new \ git update-index --index-info -mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD +if [ -f $GIT_INDEX_FILE.new ]; then mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE; fi' HEAD --- -- 2.3.5 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Doc, git-svn, added mention of config key: svn-remote.name.include-paths
Signed-off-by: Brett Randall javabr...@gmail.com --- Documentation/git-svn.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 11d1e2f..0c0f60b 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -174,6 +174,9 @@ Skip branches and tags of first level directories;; (including automatic fetches due to 'clone', 'dcommit', 'rebase', etc) on a given repository. '--ignore-paths' takes precedence over '--include-paths'. ++ +[verse] +config key: svn-remote.name.include-paths --log-window-size=n;; Fetch n log entries per request when scanning Subversion history. -- 2.3.5 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git-svn, different merge-parent selected in independent clones following SVN merge
Hi, git version 1.8.3.2 I've used git-svn on a few repositories for a long time. In what is a testament to the consistency and stability of git-svn, despite often maintaining separate git-svn clones on different machines, I've never once seen a different commit-sha in independent clones for the same SVN revision. That is until just now. Two of three clones have the same commit-sha, the third has a different sha for the same SVN revision (and as expected for all subsequent commits). All of the tree-shas are identical. I never mix/push/pull local commits between these independent clones. The commit where the commit-sha diverged on the one clone is an SVN commit that involved a branch merge. The difference in this clone is that git-svn selected a different parent commit for one of the two parents of the merge (the other parent is the same). For that commit, the two clones that agreed had: commit de2dbe2e045f626cff8e282da1660c239b926765 tree f57a4d8b88262e1f1cd79f98c7d2f5ae82751636 parent f058fd2e05a2ef54c6bf056a3d2a46d17735253d parent e2722a1a24b490dbc8d7375b64050f1a0c010018 and the one that did not had: commit a3cfdff262b6afe8b22acd92f01554294f98c851 tree f57a4d8b88262e1f1cd79f98c7d2f5ae82751636 parent f058fd2e05a2ef54c6bf056a3d2a46d17735253d parent be09b04a3fa582ba12420e0a9b9c3233b41b600d (tree and one parent same, other parent and therefore new commit sha differ) On investigation, I found that commit be09b0 is actually an ancestor of e2722a, and the parent commit of e2722a is another (SVN) merge commit, with be09b0 as one of the parents. My best guess is that this can happen when git-svn rebase-ing trunk/master, when the associated branch isn't fully fetched. I often run git svn fetch on these clones, which fetches all branches, before git svn rebase but there's a chance that I've occasionally run git svn rebase on master (trunk) on its own, which only fetches trunk. So my questions are: 1) Does that sound like the most likely way this would happen - seeing an SVN merge hit trunk during an git svn rebase on master, when the merged branch was not completely git svn fetch-ed? And on the other agreeing clones, the better parent commit had already been picked-up as part of a git svn fetch? 2) If so, is there any reasonable way to prevent this ... I guess making sure (perhaps via an alias) that svn rebases occur only via git svn fetch followed by git svn rebase -l . Thanks Brett -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A couple of rebase --autosquash proposals
This aims to support code-review workflows of teams that prefer rebase over merge, when committing a new peer-reviewed feature. * Developer starts with commit OM, commits A. * During testing, the developer may make further changes, either through --amend or new commits, but either way, all work is rebased to a single new commit for review, OM - A' . * A' is pushed as a new branch to origin for team review. The review system facilitates the review of the change, and review comments are made. * The developer responds to the review comments by making changes in commits B and C, and pushes OM - A' - B - C. Reviewers can understand the feedback that has been addressed in the changes with through the commit-log in B and C. * Code passes review. Because the team prefers rebased commits, A'..C is rebased onto the current OM (which may now be OM+10) and committed. If the commit-log entries for B and C allow simultaneous fixup!/squash! syntax together with and free-text log-text, they can serve both purposes: 1) they communicate that the change is a feedback-generated fix (rather than a new feature), and describe which parts of the feedback each commit addresses, and 2) they pre-empt and support the eventual rebase-before-origin-push, through --autosquash annotation. Brett On 9 December 2013 20:26, Chris Packham judge.pack...@gmail.com wrote: On 09/12/13 19:51, Johannes Sixt wrote: Am 12/9/2013 3:23, schrieb Brett Randall: * fixup! or squash! on it's own would default to fixing-up the previous commit (or result of previous step of rebase if that was a squash/fixup). Why would you want that? To fixup the previous commit, just use 'git commit --amend'. What am I missing? In the past I've used this kind of approach when doing merging/porting work with 3rd party code (or just large integrations). The first (and eventually final) commit introduces the new code. The subsequent fixups address build issues which are either errors in the 3rd party code (which I will want to submit bug reports for later and carry in my tree as real commits) or errors in my merging (which I want to squash into the merge commit). When faced with a screen full of compilation errors I'm not sure which of these 2 categories are applicable at the time so I tend to have lots of little fixups that I need to juggle around with git rebase once I've got the code compiling and passing some tests. All that being said I think allowing multiple fixup!\n stack up on each other might be a bit dangerous. There are cases where fixup!-fixup!-real might be useful but those would be hard to distinguish those from cases where someone absent mindedly forgot to put something after fixup!. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A couple of rebase --autosquash proposals
I had not previously noticed commit --fixup, so that is something useful I have learned from this thread, thanks. The workflow here can be summarized as I have an initial commit and subsequent, review-generated commits, that I'd like to share on a review-branch with proper commit-log comments, but also pre-marked for future --autosquash. So when the review is completed, I can auto squash/fixup all the review-generated commits and rebase onto origin/master at the same time. I find this more appealing than continually pushing rebased branches to colleagues, as the history is lost and it is hard to review incremental changes. I can live with it as it is: I just use rebase -i and change all review-generated commits pick - r as if autosquash didn't exist. It's just that when I first tried-out fixup!, I mistakenly thought that I could use the first line as the special syntax, and use following-lines as annotation - which is not the case, but I thought it might be worth suggesting here. Brett On 10 December 2013 07:20, Junio C Hamano gits...@pobox.com wrote: Johannes Sixt j.s...@viscovery.net writes: Am 12/9/2013 3:23, schrieb Brett Randall: * fixup! or squash! on it's own would default to fixing-up the previous commit (or result of previous step of rebase if that was a squash/fixup). Why would you want that? To fixup the previous commit, just use 'git commit --amend'. What am I missing? When you are not absolutely sure if the amend is a good thing to do. Then work work work git commit --fixup HEAD work work work git commit --fixup HEAD^ work work work git commit --fixup HEAD^^ ... git rebase --autosquash -i ... may become a good way to polish a single commit. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
A couple of rebase --autosquash proposals
Hi, I am using Git 1.8.4.3 compiled by me on OEL6. I'd like to be able to use rebase --autosquash like this: == # git log commit b94f970cd869dfbf5254b19867fa7200df732d4f Author: Me m...@me.com Date: Mon Dec 9 17:02:32 2013 -0800 fixup! This is a second fixup. commit 64e516c8b26b7e0531a1e8b2fc8dfa21de259b85 Author: Me m...@me.com Date: Sun Dec 8 17:02:32 2013 -0800 fixup! This is a meaningful commit-log message, on a new line, that will be discarded later during rebase --autosquash. commit f21cd48d5eeac92130dc0617252c6ee6989c0252 Author: Me m...@me.com Date: Tue Dec 3 21:47:52 2013 -0800 This is the commit that will be fixed-up. commit 259c0eb41ef16ac94868ee3c9253ba938ed24c9f Author: Me m...@me.com Date: Mon Dec 2 21:47:52 2013 -0800 This commit is origin/master. == then # git rebase -i --autosquash 259c0eb41ef16ac94868ee3c9253ba938ed24c9f The differences here are: * fixup! or squash! on it's own would default to fixing-up the previous commit (or result of previous step of rebase if that was a squash/fixup). Interestingly using HEAD~1 or HEAD^1 works, but it only works for a single fixup/squash. Is there another treeish that would work? * Allow real commit-log text, perhaps only on lines other than the first line (the one containing the fixup). The motivations are: * I can default a fixup to apply to the previous commit (a common wish) without explicitly stating it's treeish or commit-message. * I can easily apply multiple fixups. * I can retain a meaningful WIP commit-log prior to the rebase - I can still see what each commit does, without needing to forgo the future autosquash capability - just put the !fixup or !squash on the first line on its own, and put the real changes on line 2 and onwards. In the case of squash! instead of fixup!, this means I could retain some valuable text to be squashed into the original commit. Thoughts on these two ideas? Thanks Brett -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
