Re: [PATCH 00/12] git p4: submit conflict handling
On 17/08/12 00:35, Pete Wyckoff wrote: These patches rework how git p4 deals with conflicts that arise during a git p4 submit. These may arise due to changes that happened in p4 since the last git p4 sync. Luke: I especially wanted to get this out as you suggested that you had a different way of dealing with skipped commits. The part that needs the most attention is the interaction loop that happens when a commit failed. Currently, three options are offered: [s]kip this commit, but continue to apply others [a]pply the commit forcefully, generating .rej files [w]rite the commit to a patch.txt file and the implicitctrl-c to stop After this series, it offers two: [c]ontinue to apply others [q]uit to stop This feels more natural to me, and I like the term continue rather than skip as it matches what rebase uses. I'd like to know what others think of the new flow. The skip is still needed. In my workflow, git-p4 gets run periodically and does the usual sync+rebase on behalf of all the people who have pushed to the git repo. If someone pushes a change which conflicts with something from Perforce land, then what I want to happen is for the script to discard the offending commit (git rebase --skip) and then carry on with the others. In 99% of cases this does exactly what I need, as conflicting commits are usually caused by people committing the same fix to both p4 and git at around the same time (someone breaks top-of-tree with an obvious error, two separate people check in slightly different fixes). Discarding the git commit then means that everything carries on working. I've got a small patch which makes skipping work non-interactively; the thing it's missing is reporting the commits which are skipped. Other observable changes are new command-line options: Alias -v for --verbose, similar to other git commands. The --dry-run option addresses Luke's concern in http://thread.gmane.org/gmane.comp.version-control.git/201004/focus=201022 when I removed an unused self.interactive variable that did a similar thing if you edited the code. It prints commits that would be applied to p4. Option --prepare-p4-only is similar to --dry-run, in that it does not submit anything to p4, but it does prepare the p4 workspace, then prints long instructions about how to submit everything properly. It also serves, perhaps, as a replacement for the [a]pply option in the submit-conflict loop. Pete Wyckoff (12): git p4 test: remove bash-ism of combined export/assignment git p4 test: use p4d -L option to suppress log messages git p4: gracefully fail if some commits could not be applied git p4: remove submit failure options [a]pply and [w]rite git p4: move conflict prompt into run, use [c]ontinue and [q]uit git p4: standardize submit cancel due to unchanged template git p4: test clean-up after failed submit, fix added files git p4: rearrange submit template construction git p4: revert deleted files after submit cancel git p4: accept -v for --verbose git p4: add submit --dry-run option git p4: add submit --prepare-p4-only option Documentation/git-p4.txt | 13 +- git-p4.py | 213 +++-- t/lib-git-p4.sh| 10 +- t/t9805-git-p4-skip-submit-edit.sh | 2 +- t/t9807-git-p4-submit.sh | 65 +++ t/t9810-git-p4-rcs.sh | 50 + t/t9815-git-p4-submit-fail.sh | 367 + 7 files changed, 612 insertions(+), 108 deletions(-) create mode 100755 t/t9815-git-p4-submit-fail.sh -- 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: [PATCH 02/12] git p4 test: use p4d -L option to suppress log messages
On 17/08/12 00:35, Pete Wyckoff wrote:
Send p4d output to a logfile in the $TRASH_DIRECTORY.
Its messages add no value to testing.
I'm not totally sold on this; I still fairly frequently see weird errors
from p4d and these help me work out what's going on. For example, at the
moment if you run a test too quickly after the last one, then it won't
start up (or something like that).
The problem with hiding the error messages is that I don't think I will
think to look in this log file if tests start failing.
Signed-off-by: Pete Wyckoffp...@padd.com
---
t/lib-git-p4.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
index 482eeac..edb4033 100644
--- a/t/lib-git-p4.sh
+++ b/t/lib-git-p4.sh
@@ -35,12 +35,13 @@ db=$TRASH_DIRECTORY/db
cli=$(test-path-utils real_path $TRASH_DIRECTORY/cli)
git=$TRASH_DIRECTORY/git
pidfile=$TRASH_DIRECTORY/p4d.pid
+logfile=$TRASH_DIRECTORY/p4d.log
start_p4d() {
mkdir -p $db $cli $git
rm -f $pidfile
(
- p4d -q -r $db -p $P4DPORT
+ p4d -q -r $db -p $P4DPORT -L $logfile
echo $!$pidfile
)
--
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: [PATCH] man: git pull -r is a short for --rebase
Miklos Vajna vmik...@suse.cz writes: I agree that it's a bit strange, but based on a quick search, it seems multiple projects already advertise git pull -r (i.e. not --rebase and not a configuration option): http://lilypond.org/doc/v2.15/Documentation/contributor/pulling-and-rebasing http://wiki.documentfoundation.org/Git_For_LibreOffice_Developers http://www.wiremod.com/forum/wiremod-general-chat/29517-git-introduction-incomplete-unformatted.html So it seems making -r refer to --recurse-submodules would already cause quite some pain to users. Yuck. I could say it's not our problem that others spread something we didn't document ;-) but I am too nice to say that. Let's do this, then, but you have to sign off your patch. Thanks for investigating. -- 8 -- From: Miklos Vajna vmik...@suse.cz Date: Thu, 16 Aug 2012 11:50:18 +0200 Subject: [PATCH] man: git pull -r is a short for --rebase Letting the --rebase option squat on the short-and-sweet single letter option -r was an unintended accident and was not even documented, but the short option seems to be already used in the wild. Let's document it so that other options that begin with r would not be tempted to steal it. --- Documentation/git-pull.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index defb544..67fa5ee 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -101,6 +101,7 @@ include::merge-options.txt[] :git-pull: 1 +-r:: --rebase:: Rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to -- 1.7.12.rc3.2.gbd120e3 -- 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* [PATCH] man: git pull -r is a short for --rebase
Philip Oakley philipoak...@iee.org writes: From: Junio C Hamano gits...@pobox.com Sent: Thursday, August 16, 2012 9:23 PM Philip Oakley philipoak...@iee.org writes: I wasn't aware of the abbreviated options capability. Is meant to be in the man pages as I couldn't find it, or is it described differently? $ git help gitcli is the closest that comes to mind. If it is not reachable from git help git, we may want to sprinkle some more linkgit:gitfoo[$n] around the documentation sources. I didn't check. I eventually found a reference in the parse-options API to the fact that 'Long options may be abbreviated, as long as the abbreviation is unambiguous.' It may be worth bringing some of those parse-options API basics bullets' forward into the gitcli page, if appropriate. OK, how about doing this? Sort of killing two birds with one stone. -- 8 -- Subject: [PATCH] gitcli: describe abbreviation of long options Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/gitcli.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index ea17f7a..3e72a5d 100644 --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -62,6 +62,14 @@ scripting git: `git log -1 HEAD` but write `git log -1 HEAD --`; the former will not work if you happen to have a file called `HEAD` in the work tree. + * many commands allow a long option --option to be abbreviated + only to their unique prefix (e.g. if there is no other option + whose name begins with opt, you may be able to spell --opt to + invoke the --option flag), but you should fully spell them out + when writing your scripts; later versions of Git may introduce a + new option whose name shares the same prefix, e.g. --optimize, + to make a short prefix that used to be unique no longer unique. + ENHANCED OPTION PARSER -- -- 1.7.12.rc3.2.gbd120e3 -- 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 archive invocation with SHA sum
Hello, we have recently upgraded our Ubuntu server to 12.04, which comes with a newer version of GIT. However, we have noticed that git archive -remote does not work anymore by specifying the SHA sum of a commit. By seaching the mailing list I have found out that this was already discussed before (http://thread.gmane.org/gmane.comp.version-control.git/191815). In our company we use the git archive -remote command for a similar purpose in our build system and we must currently stick with an older version of GIT until there is a solution for this. I have read that this restriction was made for some kind of security reason, and one possibility would be to add a config option on the server repo to turn off this safety check. As we manage the git repos ourselves, this would be perfectly ok for us. What is the current status of this - is there already such a config option? Regards, Manfred Rudigier -- 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: [PATCH 03/12] git p4: gracefully fail if some commits could not be applied
Am 8/17/2012 1:35, schrieb Pete Wyckoff: +++ b/t/t9815-git-p4-submit-fail.sh @@ -0,0 +1,93 @@ + +#!/bin/sh This initial blank line is an accident, right? ;-) -- Hannes -- 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: [PATCH] man: git pull -r is a short for --rebase
On Thu, Aug 16, 2012 at 11:18:40PM -0700, Junio C Hamano gits...@pobox.com wrote: From: Miklos Vajna vmik...@suse.cz Date: Thu, 16 Aug 2012 11:50:18 +0200 Subject: [PATCH] man: git pull -r is a short for --rebase Letting the --rebase option squat on the short-and-sweet single letter option -r was an unintended accident and was not even documented, but the short option seems to be already used in the wild. Let's document it so that other options that begin with r would not be tempted to steal it. Signed-off-by: Miklos Vajna vmik...@suse.cz -- 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: GIT archive invocation with SHA sum
Manfred Rudigier manfred.rudig...@omicron.at writes: we have recently upgraded our Ubuntu server to 12.04, which comes with a newer version of GIT. However, we have noticed that git archive -remote does not work anymore by specifying the SHA sum of a commit. ... I have read that this restriction was made for some kind of security reason, and one possibility would be to add a config option on the server repo to turn off this safety check. As we manage the git repos ourselves, this would be perfectly ok for us. What is the current status of this - is there already such a config option? No, there isn't. I am no going to say that such a change will never happen, but you may want to rethink the way you transfer the source material to your build system, especially your build system is rebuilding each and every versions of the software. I can understand that the use of git archive can give you a way to start from an empty directory and build afresh for every version, but it is stupid to _transfer_ the full copy of the source material 300 times over the network in order to rebuild 300 versions a day, all of which will be quite similar to each other (after all, the difference between them will be limited by the productivity of your workforce). Fortunately, it is quite simple to fix. You can maintain a single bare repository on the build machine (i.e. the one you currently run git archive --remote on), and run git fetch --mirror against the machine that hosts the repository (i.e. the one you currently run git archive --remote against) to keep it up to date. That way, you should be able to drastically cut the amount of the network traffic from the source repository and the build server. Then, you copy out from that bare repository (i.e. the one you have on your build server that you git fetch --mirror into) using git archive into a fresh directory to build. Because this invocation of git archive is purely local to the machine, you do not need any configuration option to bust the you can only see the branches available to you security measure to copy things out. If your build server is building only the tagged versions for releases (I doubt that is the case, but I am writing this just for completeness), git archive --remove should be able to reach them, so you do not need such a configuration option, either. Hrm? -- 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: [PATCH 03/12] git p4: gracefully fail if some commits could not be applied
On 17/08/12 00:35, Pete Wyckoff wrote: If a commit fails to apply cleanly to the p4 tree, an interactive prompt asks what to do next. In all cases (skip, apply, write), the behavior after the prompt had a few problems. Change it so that it does not claim erroneously that all commits were applied. Instead list the set of the patches under consideration, and mark with an asterisk those that were applied successfully. Like this example: I could be wrong about this, but this change doesn't seem to help out with git p4 rebase, which for me at least, is where the conflicts usually get picked up first. I modified a file in p4, and the same file in git, and then did 'git p4 rebase' and it just failed in the rebase in the usual way with a big 'ol python backtrace. If this patch series is intended to sort out conflict handling, then it needs a bit more work. (Says Luke, trying not to sound too confrontational, as I'm rubbish at handling conflict) Thanks! Luke -- 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: [PATCH] man: git pull -r is a short for --rebase
Miklos Vajna vmik...@suse.cz writes: On Thu, Aug 16, 2012 at 11:18:40PM -0700, Junio C Hamano gits...@pobox.com wrote: From: Miklos Vajna vmik...@suse.cz Date: Thu, 16 Aug 2012 11:50:18 +0200 Subject: [PATCH] man: git pull -r is a short for --rebase Letting the --rebase option squat on the short-and-sweet single letter option -r was an unintended accident and was not even documented, but the short option seems to be already used in the wild. Let's document it so that other options that begin with r would not be tempted to steal it. Signed-off-by: Miklos Vajna vmik...@suse.cz Thanks. -- 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: git workflow - merging upwards
Thanks, for the great answer. What I am still concerned about is that in my project I plan to make bigger structural changes (let's say in 1.2) while still developing in the older branch (let's say 1.1 with the old structure. I expect that there will be many changes which I think that they can't be easily merged from 1.1 to 1.2. Do you think it is better to have a heavily used 1.1.1 branch which contains all the changes for 1.1.* only, use many revert commits, or should I avoid merging from 1.1 to 1.2 and go for cherry-picking instead? On Thu, Aug 16, 2012 at 10:43 PM, Junio C Hamano gits...@pobox.com wrote: Patrick Sabin patrick.just4...@gmail.com writes: I read through gitworkflows and want to use the Merge Upwards rule in my projects: Always commit your fixes to the oldest supported branch that require them. Then (periodically) merge the integration branches upwards into each other. This looks great but I have some trouble in the case if I want to have a change in an older branch and don't want to propagate the change to the newer branches. Let's say I have a v1.1 and a v1.2 and now a have a bug fix/workaround which only affects version v1.1 but not v1.2. If I commit to v1.1 then the periodical merge would merge the change to v1.2 which is what I don't want. Any ideas/workarounds for that problem? The document may describe the upwards in a bit too simplified way for readability. If you have two fixes to 1.1, one applicable only to 1.1 and the other applicable to both, you would fork them from tip of maint-1.1, like so: git checkout -b fix-1.1-only maint-1.1; do your work and commit git checkout -b fix-1.1-onwards maint-1.1; do your work and commit and when they are proven to be good, you would merge both of them to maint-1.1 branch: git checkout maint-1.1 git merge fix-1.1-only git merge fix-1.1-onwards But merging the resulting maint-1.1 into maint-1.2 will pull the history and the change of fix-1.1-only that you do not want to have in maint-1.2. You want the history so that later merge will not pull it to maint-1.2, but you do not want the change. The first thing to think about is if fix-1.1-only is really a fix that only should go to maint-1.1. If the change is only for 1.1.x release (e.g. update version number from 1.1.4 to 1.1.5), you may not even want to have such a change directly on the maint-1.1 branch in the first place. You would rather want to have release-1.1 branch that is forked from maint-1.1 branch, that contains the whole of maint-1.1 branch, and also contains the update version number from 1.1.x to 1.1.y changes that are not in the maint-1.1 branch [*1*]. That arrangement may be sufficient to allow you merge maint-1.1 to maint-1.2 sanely. Otherwise, you would fork another branch after merging fix-1.1-* branches to maint-1.1 to merge it upwards. After these two merges illustrated above, while still on maint-1.1, you would do: git checkout -B merge-1.1-to-1.2 maint-1.1 git revert -m 1 maint-1.1~1 ;# revert the fix-1.1-only merge which would result in a state as if you merged fix-1.1-onwards but not fix-1.1-only to the original maint-1.1 branch. But the history of this branch contains both fix-1.1-only and fix-1.1-onwards. And merge that result to maint-1.2, i.e. git checkout maint-1.2 git merge merge-1.1-to-1.2 git branch -d merge-1.1-to-1.2 That way, future merges from maint-1.1 to maint-1.2 will not drag the change of fix-1.1-only. [Footnote] *1* This principle applies not just to release numbers. If you want both maint-1.1 and maint-1.2 as generic two codebases, tweaks meant only for customers of maint-1.1 track should *not* go to maint-1.1, but customer-1.1 branch that forks from maint-1.1. That way, you can keep the generic branches clean from this is only for that branch kind of changes. -- 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: Is there a way to find out which commit git rebase --skip skipped?
On 16/08/12 16:43, Junio C Hamano wrote: Luke Diamandl...@diamand.org writes: If I do git rebase --skip, is there a way to find out the commit SHA that was skipped (other than just parsing the output of the command) ? There currently isn't, and I do not think it is doable in general when the command ever gives control back to the user to futz with the history, expecting the user only to fix up the conflict and make a single commit (in which case you would want to say that old commit was replayed as this commit with different patch id) or say rebase --skip (in which case you could record that old commit was manually skipped), but the user can do other things like resetting the head to lose commits that have been rebased already, adding new commits manually before continuing, etc., all of which will be done outside of your control. All I need is to be able to get the commit *immediately* after the failed 'git rebase'. It looks like .git/ORIG_HEAD has exactly what I need. Thanks, Luke -- 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: [PATCH v2] rev-list docs: clarify --topo-order description
Thomas Rast tr...@inf.ethz.ch writes:
Junio C Hamano gits...@pobox.com writes:
The topo order algorithm can be modified to take advantage of
[generation numbers], in order to provide incremental processing:
Let S be the set of tentative sources
Let U be the set of vertices whose out-edges are no known yet
(i.e., the set of commits which haven't been loaded yet)
[...]
while there are any vertices left:
pick any tentative source C from S that we want to emit
# Ascertain that no unknown commit (from U or further beyond) can be
# a descendant of C
while there is a D in U such that g(D) g(C):
load D
remove D from U
add the parents of D to U if they were not already loaded
possibly remove some elements of S if their indegree became nonzero
if C was removed from S:
continue
remove C from the graph and emit it
By the way, this does bump the runtime of the algorithm a bit, depending
on the data structure used for U. Recall that ordinary topo-sort with a
stack for S (i.e., --topo-order) runs linearly with the number of
vertices.
If we use a priority queue for U, which lets us get at the
highest-generation unknown commits easily, it potentially goes to n log n
if U reaches linear size at some point.
That shouldn't hurt too much of course, since on the one hand it should
rarely actually get that big, and OTOH --date-order has n log n runtime
anyway (using a priority queue for S).
Thanks for challenging me on my it should work feeling. It was quite
interesting to actually think it through and write down a workable
algorithm.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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: [PATCH 03/12] git p4: gracefully fail if some commits could not be applied
j.s...@viscovery.net wrote on Fri, 17 Aug 2012 08:53 +0200: Am 8/17/2012 1:35, schrieb Pete Wyckoff: +++ b/t/t9815-git-p4-submit-fail.sh @@ -0,0 +1,93 @@ + +#!/bin/sh This initial blank line is an accident, right? ;-) Yes, the paint on the font was still wet. Thanks! -- Pete -- 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: [PATCH v3] contrib: add win32 credential-helper
On Fri, Aug 17, 2012 at 5:34 AM, Junio C Hamano gits...@pobox.com wrote: Erik Faye-Lund kusmab...@gmail.com writes: On Fri, Jul 27, 2012 at 7:10 PM, Erik Faye-Lund kusmab...@gmail.com wrote: Since the Windows port of Git expects binary pipes, we need to make sure the helper-end also sets up binary pipes. Side-step CRLF-issue in test to make it pass. Signed-off-by: Erik Faye-Lund kusmab...@gmail.com --- Sorry for the delay, but here's the third iteration of my credential helper for Windows' credential API. The only change since v2 is that it now supports protocols without a host component, as suggested by Jeff King. ...aaand just as I sent it out, I realized that my Makefile was a bit on the light side. Imagine this patch on top for now, please :) I notice that I didn't queue either of these; are you still polishing them, or are they in good enough shape that it wouldn't make things harder for you if I queue it, with a plan to merge it soon after 1.7.12? As far as I'm concerned, I consider this complete from my point of view. Should I send out a new version with the fixup squashed in? -- 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: [PATCH 03/12] git p4: gracefully fail if some commits could not be applied
l...@diamand.org wrote on Fri, 17 Aug 2012 08:21 +0100:
On 17/08/12 00:35, Pete Wyckoff wrote:
If a commit fails to apply cleanly to the p4 tree, an interactive
prompt asks what to do next. In all cases (skip, apply, write),
the behavior after the prompt had a few problems.
Change it so that it does not claim erroneously that all commits
were applied. Instead list the set of the patches under
consideration, and mark with an asterisk those that were
applied successfully. Like this example:
I could be wrong about this, but this change doesn't seem to help
out with git p4 rebase, which for me at least, is where the
conflicts usually get picked up first.
Right, this is only about the submit path. I wasn't thinking
about rebase when I worked on this code (or read your message
about rebase ORIG_HEAD).
I modified a file in p4, and the same file in git, and then did 'git
p4 rebase' and it just failed in the rebase in the usual way with a
big 'ol python backtrace.
The backtraces are not pretty, and should be fixed. I confess I
never use git p4 rebase, because it should be only git p4 sync +
git rebase @{u}. There's no conflict handling at all in the git
p4 code.
If this patch series is intended to sort out conflict handling, then
it needs a bit more work.
This patch series tries to fix the conflict handling in the
submit path only. Have to start somewhere.
What do you think we might do about the rebase path? It feels
like a situation that belongs to native git. Are there
p4-specific things like $Id$ tags that need help? We could
just catch the errors from git rebase more gracefully, or exec
directly into git rebase.
-- Pete
--
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: [PATCH 00/12] git p4: submit conflict handling
l...@diamand.org wrote on Fri, 17 Aug 2012 07:04 +0100: On 17/08/12 00:35, Pete Wyckoff wrote: These patches rework how git p4 deals with conflicts that arise during a git p4 submit. These may arise due to changes that happened in p4 since the last git p4 sync. Luke: I especially wanted to get this out as you suggested that you had a different way of dealing with skipped commits. The part that needs the most attention is the interaction loop that happens when a commit failed. Currently, three options are offered: [s]kip this commit, but continue to apply others [a]pply the commit forcefully, generating .rej files [w]rite the commit to a patch.txt file and the implicitctrl-c to stop After this series, it offers two: [c]ontinue to apply others [q]uit to stop This feels more natural to me, and I like the term continue rather than skip as it matches what rebase uses. I'd like to know what others think of the new flow. The skip is still needed. In my workflow, git-p4 gets run periodically and does the usual sync+rebase on behalf of all the people who have pushed to the git repo. If someone pushes a change which conflicts with something from Perforce land, then what I want to happen is for the script to discard the offending commit (git rebase --skip) and then carry on with the others. In 99% of cases this does exactly what I need, as conflicting commits are usually caused by people committing the same fix to both p4 and git at around the same time (someone breaks top-of-tree with an obvious error, two separate people check in slightly different fixes). Discarding the git commit then means that everything carries on working. I've got a small patch which makes skipping work non-interactively; the thing it's missing is reporting the commits which are skipped. This discard offending commits part I had not thought anyone would ever do. Instead, why not do git p4 rebase on its own and use git rebase --skip to discard the offending ones explicitly. It seems dangerous to do it implicitly as part of a multi-commit submit to p4. Thanks for sending your RFC work. I see what you are thinking about. Assuming that it really would be good to have a way to _automatically_ discard conflicting commits, then sure, keeping a list in submit and plumbing that into the rebase would work. It still scares me. There are quite a few special cases where it fails, of course, like if future commits involve dependencies on the one you want to skip. Would this alternative approach work: git p4 submit --discard-conflicting-commits (and/or the option). It automatically hits skip after every submit failure. When done, it does git p4 sync to get a report on what ended up in tree. Then instead of rebasing, the HEAD is simply taken to the top of the p4 tree. No need to rebase if the rule is to discard all skipped patches. Plus some reporting to say what was lost. I will reroll my series once we've figured out how we want these to co-exist. -- Pete -- 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
Temporary merge branch 2 Conflicts
Hi all- Given this branch history: -M--M---M--- dev \ / / / -- v1-maint \ \ \ M---M--- v1.5-maint I am attempting to merge v1.5-maint into dev. There are some expected conflicts, but when I start mergetool (kdiff3) there are also a lot of conflict markers in the base that look like this Temporary merge branch 1 ... code here ... === ... more code here ... Temporary merge branch 2 which confuse kdiff3. Googling around I found a few mentions of these temporary merge branches, e.g. $gmane/157591, but I don't think we have any criss-cross merges. Can anyone provide some advice? Any suggestions are greatly appreciated! Thanks, Stephen -- 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: GIT archive invocation with SHA sum
Junio C Hamano [mailto:gits...@pobox.com] writes: I have read that this restriction was made for some kind of security reason, and one possibility would be to add a config option on the server repo to turn off this safety check. As we manage the git repos ourselves, this would be perfectly ok for us. What is the current status of this - is there already such a config option? No, there isn't. I am no going to say that such a change will never happen, but you may want to rethink the way you transfer the source material to your build system, especially your build system is rebuilding each and every versions of the software. I can understand that the use of git archive can give you a way to start from an empty directory and build afresh for every version, but it is stupid to _transfer_ the full copy of the source material 300 times over the network in order to rebuild 300 versions a day, all of which will be quite similar to each other (after all, the difference between them will be limited by the productivity of your workforce). Our build system creates an embedded firmware image similar to OpenEmbedded or OpenWrt. There all components (including boot loader, kernel, busybox and many other third party components) are compiled during nightly builds. Each component has its own GIT repository on the server and our build system references those components via SHA-1 sums. Many of those components do almost NEVER change (we do not update the Linux kernel every day), so most of this code must only be fetched once using git archive. Fortunately, it is quite simple to fix. You can maintain a single bare repository on the build machine (i.e. the one you currently run git archive --remote on), and run git fetch --mirror against the machine that hosts the repository (i.e. the one you currently run git archive --remote against) to keep it up to date. That way, you should be able to drastically cut the amount of the network traffic from the source repository and the build server. I know that I could workaround this by mirroring all repositories locally, but it is much more convenient to use git archive right away. I agree that once the repos are mirrored, there is less traffic on the network, but traffic has not been an issue for us so far. Also, a complete mirror of all involved repositories will be much larger than just the exported tar archives (e.g. Linux kernel repo is 770MB, while the tar.gz is just 96MB). It was a really nice feature of GIT and it is just too bad that it is no longer available. Regards, Manfred -- 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] cleanup precompose_utf8
Remove extraneous parentheses and braces
Remove redundant NUL-termination
Check result of unlink when probing for decomposed file names
Signed-off-by: Robin Rosenberg robin.rosenb...@dewire.com
---
compat/precompose_utf8.c | 11 ---
1 fil ändrad, 4 tillägg(+), 7 borttagningar(-)
diff --git a/compat/precompose_utf8.c b/compat/precompose_utf8.c
index d40d1b3..9563760 100644
--- a/compat/precompose_utf8.c
+++ b/compat/precompose_utf8.c
@@ -21,11 +21,10 @@ static size_t has_utf8(const char *s, size_t maxlen, size_t
*strlen_c)
size_t strlen_chars = 0;
size_t ret = 0;
- if ((!utf8p) || (!*utf8p)) {
+ if (!utf8p || !*utf8p)
return 0;
- }
- while((*utf8p) maxlen) {
+ while(*utf8p maxlen) {
if (*utf8p 0x80)
ret++;
strlen_chars++;
@@ -46,21 +45,19 @@ void probe_utf8_pathname_composition(char *path, int len)
int output_fd;
if (precomposed_unicode != -1)
return; /* We found it defined in the global config, respect it
*/
- path[len] = 0;
strcpy(path + len, auml_nfc);
output_fd = open(path, O_CREAT|O_EXCL|O_RDWR, 0600);
if (output_fd =0) {
close(output_fd);
- path[len] = 0;
strcpy(path + len, auml_nfd);
/* Indicate to the user, that we can configure it to true */
if (0 == access(path, R_OK))
git_config_set(core.precomposeunicode, false);
/* To be backward compatible, set precomposed_unicode
to 0 */
precomposed_unicode = 0;
- path[len] = 0;
strcpy(path + len, auml_nfc);
- unlink(path);
+ if (unlink(path))
+ die_errno(_(failed to unlink '%s'), path);
}
}
--
1.7.12.rc3.4.ga867a5c
--
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
Problems with new location of submodule's GIT_DIR
Hi all, I have encountered some difficulties with the new location of the metainformation directory (GIT_DIR) of submodules. The change of location happened in 1.7.8: * When populating a new submodule directory with git submodule init, the $GIT_DIR metainformation directory for submodules is created inside $GIT_DIR/modules/name/ directory of the superproject and referenced via the gitfile mechanism. This is to make it possible to switch between commits in the superproject that has and does not have the submodule in the tree without re-cloning. Which problems it causes: 1) You cannot move submodule easily (change the path to submodule). You can either remove the submodule and then add it again to different path, or move the submodule directory and then edit path in its .git, change path in superproject's .git/modules dir and in .git/config. This is quite difficult in comparisson with previous behaviour when you can just move the submodule and then stash changes. 2) This change introduced many difficulties on Windows platform, because there is limitation to path length and the way how paths are now composed leads to strange errors when project with submodules is in user's dir. 3) Submodules became dependent on superproject. This is quite bad if you are using submodules a lot (e.g. versioning the whole working space), because you cannot move or copy them out of the superproject now. I honestly don't know why this change was introduced because I have never seen git removing any submodule while walking through the history. I have seen only the message saying that directory is not empty and so git will not remove it. Or is there another reason why this change was added to git? Thanks Cheers Daniel -- 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 feature request: --amend older commit
With git's commit frequently style, I often find that I end up with a commit that includes a typo in a comment or I forgot one call site when updating functions or something. And it's a few commits later before I notice the simple oops. This is of course fixable by making a commit, rebase -i HEAD~4 (or whatever), and marking the fixup for squashing into the previous commit. But it would be really handy if there were a one-step command for doing this. Something like git commit --fixup HEAD~3, where git commit --fixup HEAD would be equivalent to git commit --amend. It would be fine if it were implemented using rebase -i and you had to use git rebase --continue to recover from a conflict. And history had to be linear from the fixup point to HEAD. The only thing I'd wish for, that rebase -i doesn't support, is a commit with a dirty tree. (Because often the typo is noticed in the middle of further development.) But if I have to manually stash pop, that would be good enough. Talking with some friends, they all say yeah, I would really use that feature. So I figured I'd mention it here. -- 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
[BUG] filter-branch --parent-filter in bare repository
Using git version 1.7.12.rc2.18.g61b472e (1.7.9 has the same problem) If I run (directly in the bare repository) git filter-branch -d ../localrewrite --parent-filter cat I get this error message on the last line, nothing unusual before: error: Untracked working tree file 'AUTHORS' would be overwritten by merge. but if I run (directly in the bare repository) git filter-branch -d .localrewrite --parent-filter cat everything works fine. Depending on the path of the temporary directory, the error may also point to some other file. AUTHORS is in the root directory, but it is never untracked. If I do a clone and run the same command in the clone, it also works with any temp directory. And this only happens with one specific repository - a KDE game, converted with svn2git. No other game has this problem. git fsck only finds dangling tags. The resulting repositories are identical, so I can ignore the error message for now. But still - why can't I run this in the bare repository? git help filter-branch does not mention something like that. You can get the repository here: http://www.rohdewald.de/oss/tst.tbz Maybe related: I run this directly in the bare repository. If the command succeeds, I find a checkout directly there (everything was clean before), so I have all this intermixed - IMHO a bug. branches description HEAD hooks info objects refs PLUS all directories and files right in there: AUTHORS History.hksokobanui.rc MapDelta.hPathFinder.cpp Bookmark.cpp hooksLevelCollection.cpp Map.h PathFinder.h Bookmark.h HtmlPrinter.cpp LevelCollection.h Messages.sh PlayField.cpp branches HtmlPrinter.hLevelMap.cpp ModalLabel.cppPlayField.h CMakeLists.txt ImageData.cppLevelMap.h ModalLabel.h Queue.h config-ksokoban.h.cmake ImageData.h levels Move.cpp README data images main.cpp Move.h refs description indexMainWindow.cpp MoveSequence.cpp StaticImage.cpp doc info MainWindow.h MoveSequence.hStaticImage.h HEAD InternalCollections.cpp Map.cpp NEWS TODO History.cpp InternalCollections.hMapDelta.cpp objects -- Wolfgang -- 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: Problems with new location of submodule's GIT_DIR
Am 17.08.2012 17:28, schrieb Daniel Milde: Hi all, I have encountered some difficulties with the new location of the metainformation directory (GIT_DIR) of submodules. The change of location happened in 1.7.8: * When populating a new submodule directory with git submodule init, the $GIT_DIR metainformation directory for submodules is created inside $GIT_DIR/modules/name/ directory of the superproject and referenced via the gitfile mechanism. This is to make it possible to switch between commits in the superproject that has and does not have the submodule in the tree without re-cloning. Which problems it causes: 1) You cannot move submodule easily (change the path to submodule). You can either remove the submodule and then add it again to different path, or move the submodule directory and then edit path in its .git, change path in superproject's .git/modules dir and in .git/config. This is quite difficult in comparisson with previous behaviour when you can just move the submodule and then stash changes. Unfortunately that is currently the case. Plans are to have something like a git submodule mv, which will do all the magic and make moving submodules easy again. 2) This change introduced many difficulties on Windows platform, because there is limitation to path length and the way how paths are now composed leads to strange errors when project with submodules is in user's dir. Hmm, this sounds more like the problems we had with c: and /c, which are fixed in current git. What version are you using? 3) Submodules became dependent on superproject. This is quite bad if you are using submodules a lot (e.g. versioning the whole working space), because you cannot move or copy them out of the superproject now. Okay, that use case is new to me. What is the intention when you move a submodule out of the work tree? Couldn't you just as easily clone the upstream repo again at the new place? I honestly don't know why this change was introduced because I have never seen git removing any submodule while walking through the history. I have seen only the message saying that directory is not empty and so git will not remove it. Or is there another reason why this change was added to git? But that is just the same as when a submodules appears and you check out a commit before the submodule was added. It should be removed but currently isn't, which we can change in a future git version now the git directory lives in a safe place. Other reasons are: *) Converting a directory tree into a submodules (or the other way round) is currently virtually impossible to handle. But that'll work just fine in the near future, which will make a lot of users happy. *) It is easy to accidentally throw away the submodules history and unpushed changes when removing it from the work tree (e.g. because you don't work on that part of the tree anymore), which should only contain tracked content and not repository data like it did. So we did that change to make submodule handling easier and to be able to support valid use cases which we couldn't. Sorry for the hassle, but we believe it is worth it in the long run. -- 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: Git feature request: --amend older commit
On 08/17/2012 05:47 PM, George Spelvin wrote: With git's commit frequently style, I often find that I end up with a commit that includes a typo in a comment or I forgot one call site when updating functions or something. And it's a few commits later before I notice the simple oops. This is of course fixable by making a commit, rebase -i HEAD~4 (or whatever), and marking the fixup for squashing into the previous commit. But it would be really handy if there were a one-step command for doing this. Something like git commit --fixup HEAD~3, where git commit --fixup HEAD would be equivalent to git commit --amend. [...] Have you tried git rebase --autosquash? It does part of what you are asking for and additionally allows multiple fixup commits to be queued up and processed in a single rebase. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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: [RFC PATCH 1/2] rm: don't fail when removing populated submodules
Am 16.08.2012 23:56, schrieb Junio C Hamano: Jens Lehmann jens.lehm...@web.de writes: Am 09.07.2012 21:38, schrieb Junio C Hamano: Jens Lehmann jens.lehm...@web.de writes: Cool, so let's drop this patch and I'll teach rm to handle populated submodules according to what we do for regular files: Make sure there are no modifications which could get lost (unless -f) and remove all tracked files and the gitfile from the work tree (unless --cached) before removing the submodule from the index. If the submodule uses the old layout with the .git directory instead of a gitfile we error out just like we do today. Alternatively we could mv .git directory out of the way and the next git checkout of a branch that still has the submodule can make a gitfile to point there, no? Yup. That would mean a smooth transition for legacy .git-dir submodules into the new gitfile world. And we didn't talk about untracked or ignored files which may live inside the submodules work tree so far, but according to what a rm -r does in the superproject they should still be around after using rm on a populated submodule, right? Until we add the precious class, untracked and ignored files are expendable, so if a submodule working tree has no modification and only has leftover *.o files, they can be nuked as part of submodule removal, but if it has an untracked and unignored *.c file for example, the rm operation without -f should be stopped, no? Ok, untracked files mark the submodule modified while ignored files which are not tracked won't. Thanks for this discussion, I'll start hacking on that. A mild ping on seemingly stalled topic. I'm almost there. The only thing left is to check if a nested submodule is using a git directory. In that case I expect rm to fail even when -f is used to protect the submodule's history. I still need to find a suitable command for recursing the submodules and doing that check. -- 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: [PATCH v2] rev-list docs: clarify --topo-order description
Thomas Rast tr...@inf.ethz.ch writes: However, suppose we knew generation numbers. I haven't actually looked into the old threads again, but my understanding was that they are numbers g(C) attached to each commit C such that g(C) = 1 + max(g(P) for P a parent of C) for non-root commits g(C) = 0 for root commits They are invariant given the commit, so they can be cached. ... I hope I got that right. The order of commits is still entirely determined by the choice of any tentative source, but the algorithm should now stream nicely once the generation numbers are known. That matches the definition of generation number I remember from the old discussion. Now look at the illustration in this discussion again: ---A---B---C---D \ ---1---2---3---4---* = HEAD and an excerpt from the message you are respoding to: Think of the sample history above, and imagine that the numbered ones are based on the current 'master', but that the alphabet ones are based on an ancient maintenance release that is 1000 generations behind (think of me running the command after finishing the day's integration cycle, sitting at the tip of 'pu', where the last topic merged is meant to be eventually merged to maint-1.7.9). All of the commits depicted in the picture will have the commit timestamps in the past few hours. Ancestors of A and 1, not drawn in the picture, were made yesterday or before. The numbered commits 1 2 3 4 are building on top of recent master, while alphabetized A B C D are building on aged maintenance track. The difference in generation numbers between 1 and 2, 2 and 3,... A and B, B and C, C and D are all one, and HEAD (the tip of 'pu') would have generation number of commit 4 plus 1, as commit 4's generation number would be a thousand or more ahead of that of commit D. And there are a thousand ancestors of '1' with larger generation numbers than 'D'. When the user runs git log (i.e. the casual the last few commit macthes), the expectation of the user is I want to see what I did recently. If you substituted the commit timestamp with such a generation number, how would that expectation satisified? Generation numbers is a clean solution to avoid giving an incorrect range result when there are clock skews (cf. the use of SLOP in revision.c::still_interesting()), but it is not a good substitute when the user is more interested in absolutely correct topology (in other words, the user is more interested in both rougly wallclock time order and seeing the result soon --- which brings us back to the original short latency is vastly preferred _as long as_ it produces the result the user wants to see). -- 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: [PATCH v3] contrib: add win32 credential-helper
Erik Faye-Lund kusmab...@gmail.com writes: As far as I'm concerned, I consider this complete from my point of view. Should I send out a new version with the fixup squashed in? I've already queued them as one commit. Thanks. -- 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: [PATCH] cleanup precompose_utf8
Thanks. -- 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: [PATCH] cleanup precompose_utf8
Robin Rosenberg robin.rosenb...@dewire.com writes: Remove extraneous parentheses and braces Remove redundant NUL-termination Check result of unlink when probing for decomposed file names Signed-off-by: Robin Rosenberg robin.rosenb...@dewire.com --- Thanks. I've found and fixed a bit more style violations while we are at it. -- 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: [PATCH v2] rev-list docs: clarify --topo-order description
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@inf.ethz.ch writes:
However, suppose we knew generation numbers. I haven't actually looked
into the old threads again, but my understanding was that they are
numbers g(C) attached to each commit C such that
g(C) = 1 + max(g(P) for P a parent of C) for non-root commits
g(C) = 0 for root commits
They are invariant given the commit, so they can be cached.
...
I hope I got that right. The order of commits is still entirely
determined by the choice of any tentative source, but the algorithm
should now stream nicely once the generation numbers are known.
That matches the definition of generation number I remember from the
old discussion. Now look at the illustration in this discussion
again:
---A---B---C---D
\
---1---2---3---4---* = HEAD
[...]
The numbered commits 1 2 3 4 are building on top of recent master,
while alphabetized A B C D are building on aged maintenance track.
The difference in generation numbers between 1 and 2, 2 and 3,... A
and B, B and C, C and D are all one, and HEAD (the tip of 'pu') would
have generation number of commit 4 plus 1, as commit 4's generation
number would be a thousand or more ahead of that of commit D. And
there are a thousand ancestors of '1' with larger generation numbers
than 'D'.
When the user runs git log (i.e. the casual the last few commit
macthes), the expectation of the user is I want to see what I did
recently. If you substituted the commit timestamp with such a
generation number, how would that expectation satisified?
Umm, have you looked at the algorithm I proposed?
It does not substitute the generation numbers for anything, let alone
the date. It merely uses them to determine a point where it knows
enough of the history to be able to emit the next commit; that is,
where it can use the generation numbers to prove that no unknown commit
can be a descendant of what it wants to emit next.
It does *not* have to use the generation numbers in the final ordering
of the commits. That final order is determined by how the algorithm
chooses the next candidate commit. If you use a stack, it winds up
being --topo-order. If you use a date-ordered priority queue, it
becomes --date-order.
So really, this is only about modifying the algorithm that generates the
existing order to allow for streaming output as it reads through
history.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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: Problems with new location of submodule's GIT_DIR
On Fri, Aug 17, 2012 at 12:40 PM, Jens Lehmann jens.lehm...@web.de wrote: Am 17.08.2012 17:28, schrieb Daniel Milde: Hi all, I have encountered some difficulties with the new location of the metainformation directory (GIT_DIR) of submodules. The change of location happened in 1.7.8: * When populating a new submodule directory with git submodule init, the $GIT_DIR metainformation directory for submodules is created inside $GIT_DIR/modules/name/ directory of the superproject and referenced via the gitfile mechanism. This is to make it possible to switch between commits in the superproject that has and does not have the submodule in the tree without re-cloning. Which problems it causes: 3) Submodules became dependent on superproject. This is quite bad if you are using submodules a lot (e.g. versioning the whole working space), because you cannot move or copy them out of the superproject now. Okay, that use case is new to me. What is the intention when you move a submodule out of the work tree? Couldn't you just as easily clone the upstream repo again at the new place? Not all git projects have upstreams. Maybe this is a local project only. In any case, cloning the upstream anew does not preserve local history. Maybe the future 'git submodule mv' can be smart about moving a submodule to a new location outside of a superproject. Maybe it can do so explicitly with the --export switch. Phil -- 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: [PATCH v2] rev-list docs: clarify --topo-order description
Thomas Rast tr...@inf.ethz.ch writes: I hope I got that right. The order of commits is still entirely determined by the choice of any tentative source, but the algorithm should now stream nicely once the generation numbers are known. Thanks for an intereseting read. Even though generation numbers are not always a good subsitute for timestamps depending on the use (see the other message), the algorithm to compute topo-order can take advantage of the generation numbers when they are available, as you illustrated in your message. We may want to think about adding a new field to the commit object, with a fallback mechanism to an external cache that is generated on-demand. Once the mechanism is in place so that any caller of parse_commit() can depend on having a reliable .generation field in the commit object it receives from the function, we can start updating various traversal algorithms to take advantage of this new information. -- 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: Is there a way to find out which commit git rebase --skip skipped?
Luke Diamand l...@diamand.org writes: All I need is to be able to get the commit *immediately* after the failed 'git rebase'. It looks like .git/ORIG_HEAD has exactly what I need. Depends on what you meant by commit that was skipped, but the above makes me nervous. ORIG_HEAD is set to the tip of the branch being rebased at the very beginning, and updated to the current HEAD (i.e. the result of the last successful step) before --skip is given. I do not think it ever points into the commits in the original history that is being replayed. -- 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: [PATCH v2 1/2] test: git-stash conflict sets up rerere
On Thu, Aug 16, 2012 at 6:00 PM, Junio C Hamano gits...@pobox.com wrote: Phil Hord phil.h...@gmail.com writes: So, the next roll will remove the tests for MERGE_RR and will be more explicit about the potential for mergetool confusion and/or the fact that it is not explicitly tested here. I'll wait a little longer for any further comments. Mild ping to a seemingly stalled topic. I was going to say the same thing. Patch v3 series is here: http://permalink.gmane.org/gmane.comp.version-control.git/201282 http://permalink.gmane.org/gmane.comp.version-control.git/201283 I assume these were missed because I sent them during some critical point in the release cycle. But maybe it was because I missed some step in the submission-revision protocol. If the latter, please let me know and I will try to learn to do better next time. Phil ~ resent due to missed ReplyAll button -- 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: [PATCH v3 1/2] test: git-stash conflict sets up rerere
Phil Hord ho...@cisco.com writes: Add a failing test to confirm a conflicted stash apply invokes rerere to record the conflicts and resolve the the files it can. mergetool may be confused by a left-over state from previous rerere activity causing it to think no files have conflicts even though they do. This condition is not verified by this test since a subsequent commit will change the behavior to enable rerere for stash conflicts. Also, the next test expected us to finish up with a reset, which is impossible to do if we fail (as we must) and it's an unreasonable expectation anyway. Begin the next test with a reset of his own instead. Signed-off-by: Phil Hord ho...@cisco.com --- t/t7610-mergetool.sh | 38 ++ 1 file changed, 38 insertions(+) diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh index f5e16fc..725f316 100755 --- a/t/t7610-mergetool.sh +++ b/t/t7610-mergetool.sh ... test_expect_success 'mergetool takes partial path' ' +git reset --hard I'll add at the end and queue. Thanks. git config rerere.enabled false git checkout -b test12 branch1 git submodule update -N -- 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: [PATCH v2 1/2] test: git-stash conflict sets up rerere
Phil Hord phil.h...@gmail.com writes: On Thu, Aug 16, 2012 at 6:00 PM, Junio C Hamano gits...@pobox.com wrote: Phil Hord phil.h...@gmail.com writes: So, the next roll will remove the tests for MERGE_RR and will be more explicit about the potential for mergetool confusion and/or the fact that it is not explicitly tested here. I'll wait a little longer for any further comments. Mild ping to a seemingly stalled topic. I was going to say the same thing. Patch v3 series is here: http://permalink.gmane.org/gmane.comp.version-control.git/201282 http://permalink.gmane.org/gmane.comp.version-control.git/201283 I assume these were missed because I sent them during some critical point in the release cycle. But maybe it was because I missed some step in the submission-revision protocol. If the latter, please let me know and I will try to learn to do better next time. Thanks; they were just lost in the noise of the traffic. Will replace and requeue. -- 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: [RFC PATCH 1/2] rm: don't fail when removing populated submodules
On Fri, Aug 17, 2012 at 12:44 PM, Jens Lehmann jens.lehm...@web.de wrote: I'm almost there. The only thing left is to check if a nested submodule is using a git directory. In that case I expect rm to fail even when -f is used to protect the submodule's history. I still need to find a suitable command for recursing the submodules and doing that check. I suppose the style of this is wrong, but this seems to work for me. git submodule foreach --recursive '! test -f .git' -- 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: [PATCH v2] rev-list docs: clarify --topo-order description
Thomas Rast tr...@student.ethz.ch writes: Umm, have you looked at the algorithm I proposed? ... So really, this is only about modifying the algorithm that generates the existing order to allow for streaming output as it reads through history. Sorry, I thought you were optimizing sort_in_topological_order() found in commit.c, not the callchain that forms get_revision() in revision.c. -- 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: Re* [PATCH] man: git pull -r is a short for --rebase
From: Junio C Hamano gits...@pobox.com Sent: Friday, August 17, 2012 7:19 AM Philip Oakley philipoak...@iee.org writes: From: Junio C Hamano gits...@pobox.com Sent: Thursday, August 16, 2012 9:23 PM Philip Oakley philipoak...@iee.org writes: I wasn't aware of the abbreviated options capability. Is meant to be in the man pages as I couldn't find it, or is it described differently? $ git help gitcli is the closest that comes to mind. If it is not reachable from git help git, we may want to sprinkle some more linkgit:gitfoo[$n] around the documentation sources. I didn't check. I eventually found a reference in the parse-options API to the fact that 'Long options may be abbreviated, as long as the abbreviation is unambiguous.' It may be worth bringing some of those parse-options API basics bullets' forward into the gitcli page, if appropriate. OK, how about doing this? Sort of killing two birds with one stone. -- 8 -- Subject: [PATCH] gitcli: describe abbreviation of long options Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/gitcli.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index ea17f7a..3e72a5d 100644 --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -62,6 +62,14 @@ scripting git: `git log -1 HEAD` but write `git log -1 HEAD --`; the former will not work if you happen to have a file called `HEAD` in the work tree. + * many commands allow a long option --option to be abbreviated + only to their unique prefix (e.g. if there is no other option + whose name begins with opt, you may be able to spell --opt to + invoke the --option flag), but you should fully spell them out + when writing your scripts; later versions of Git may introduce a + new option whose name shares the same prefix, e.g. --optimize, + to make a short prefix that used to be unique no longer unique. + ENHANCED OPTION PARSER -- -- 1.7.12.rc3.2.gbd120e3 Acked-by: Philip Oakley philipoak...@iee.org I'd also suggest a patch to the 'git' page to bring out the command line interface man page, including an emphasis on each of the other information pages, along the lines of (probably managled/see attached): -- 8 -- From 655c6e968fc4bb497e7ade90f2d879aadec795d9 Mon Sep 17 00:00:00 2001 From: Philip Oakley philipoak...@iee.org Date: Fri, 17 Aug 2012 17:53:48 +0100 Subject: Include 'see gitcli' link, and separate the other links Provide a link to the git command line interface information, and separate for readability, the differing Tutorial, User-manual, and CVS instruction links. Signed-off-by: Philip Oakley philipoak...@iee.org --- Documentation/git.txt | 12 +++- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/Documentation/git.txt b/Documentation/git.txt index ca85d1d..75b35ce 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -22,11 +22,13 @@ unusually rich command set that provides both high-level operations and full access to internals. See linkgit:gittutorial[7] to get started, then see -link:everyday.html[Everyday Git] for a useful minimum set of commands, and -man git-commandname for documentation of each command. CVS users may -also want to read linkgit:gitcvs-migration[7]. See -the link:user-manual.html[Git User's Manual] for a more in-depth -introduction. +link:everyday.html[Everyday Git] for a useful minimum set of commands. +Use man git-commandname for documentation of each command, or git help. + +CVS users may also want to read linkgit:gitcvs-migration[7]. + +See the link:user-manual.html[Git User's Manual] for a more in-depth +introduction, and linkgit:gitcli[7] for details of git's command line interface. The 'command' is either a name of a Git command (see below) or an alias as defined in the configuration file (see linkgit:git-config[1]). -- 1.7.8.msysgit.0 0001-Include-see-gitcli-link-and-separate-the-other-links.patch Description: Binary data
Re: Re* [PATCH] man: git pull -r is a short for --rebase
Philip Oakley philipoak...@iee.org writes: diff --git a/Documentation/git.txt b/Documentation/git.txt index ca85d1d..75b35ce 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -22,11 +22,13 @@ unusually rich command set that provides both high-level operations and full access to internals. See linkgit:gittutorial[7] to get started, then see -link:everyday.html[Everyday Git] for a useful minimum set of commands, and -man git-commandname for documentation of each command. CVS users may -also want to read linkgit:gitcvs-migration[7]. See -the link:user-manual.html[Git User's Manual] for a more in-depth -introduction. +link:everyday.html[Everyday Git] for a useful minimum set of commands. +Use man git-commandname for documentation of each command, or git help. + +CVS users may also want to read linkgit:gitcvs-migration[7]. + +See the link:user-manual.html[Git User's Manual] for a more in-depth +introduction, and linkgit:gitcli[7] for details of git's command line interface. The 'command' is either a name of a Git command (see below) or an alias as defined in the configuration file (see linkgit:git-config[1]). I would prefer to keep the description section of git(1) not overly long. The first paragraph (not much shown above) concisely describes what Git is, so that people who were interested in other git can quickly tell that this is not a page to read about it. I think it is in good shape. The purpose of the second paragraph is to guide people who are not ready to dive into this page and refer them to other pages with the introductory material, and also tell them that they can come back to this page to learn the set of commands Git offers once they are familiar with the concepts. And then, before going into the list of commands, we should tell them what we are listing, and where they can find more information. So in that sense, we would really want to keep the second paragraph short and to the point. Referring migrating CVS users to another page before they get acquainted with Git like the current page does is a mistake. On the other hand, gitcli may deserve to be mentioned in the third paragraph that gives the reader the sense of the overall structure of the documentation. The mention of cvs migration used to be more important in earlier days, but I think it was out of place to have it early in the document even back then. It probably can be moved down to the FURTHER DOCUMENTATION section. So how about doing it this way? -- 8 -- Subject: [PATCH] Documentation: update the introductory section The second paragraph in the git(1) description section were meant to guide people who are not ready to dive into this page away from here. Referring migrating CVS users to another page before they get acquainted with Git was somewhat out of place. Move the reference to the FURTHER DOCUMENTATION section and push that section down. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/git.txt | 60 +++ 1 file changed, 32 insertions(+), 28 deletions(-) diff --git a/Documentation/git.txt b/Documentation/git.txt index eb6b2c0..33028a9 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -22,18 +22,17 @@ unusually rich command set that provides both high-level operations and full access to internals. See linkgit:gittutorial[7] to get started, then see -link:everyday.html[Everyday Git] for a useful minimum set of commands, and -man git-commandname for documentation of each command. CVS users may -also want to read linkgit:gitcvs-migration[7]. See -the link:user-manual.html[Git User's Manual] for a more in-depth -introduction. +link:everyday.html[Everyday Git] for a useful minimum set of +commands. The link:user-manual.html[Git User's Manual] has a more +in-depth introduction. -The 'command' is either a name of a Git command (see below) or an alias -as defined in the configuration file (see linkgit:git-config[1]). +After you mastered the basic concepts, you can come back to this +page to learn what commands git offers. You can learn more about +individual git commands with git help command. linkgit:gitcli[7] +manual page gives you an overview of the command line command syntax. -Formatted and hyperlinked version of the latest git -documentation can be viewed at -`http://git-htmldocs.googlecode.com/git/git.html`. +Formatted and hyperlinked version of the latest git documentation +can be viewed at `http://git-htmldocs.googlecode.com/git/git.html`. ifdef::stalenotes[] [NOTE] @@ -406,24 +405,6 @@ help ...`. linkgit:git-replace[1] for more information. -FURTHER DOCUMENTATION -- - -See the references above to get started using git. The following is -probably more detail than necessary for a first-time user. - -The link:user-manual.html#git-concepts[git concepts chapter of the -user-manual] and linkgit:gitcore-tutorial[7] both provide
Re: Re* [PATCH] man: git pull -r is a short for --rebase
From: Junio C Hamano gits...@pobox.com Sent: Friday, August 17, 2012 8:48 PM Philip Oakley philipoak...@iee.org writes: diff --git a/Documentation/git.txt b/Documentation/git.txt index ca85d1d..75b35ce 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -22,11 +22,13 @@ unusually rich command set that provides both high-level operations and full access to internals. See linkgit:gittutorial[7] to get started, then see -link:everyday.html[Everyday Git] for a useful minimum set of commands, and -man git-commandname for documentation of each command. CVS users may -also want to read linkgit:gitcvs-migration[7]. See -the link:user-manual.html[Git User's Manual] for a more in-depth -introduction. +link:everyday.html[Everyday Git] for a useful minimum set of commands. +Use man git-commandname for documentation of each command, or git help. + +CVS users may also want to read linkgit:gitcvs-migration[7]. + +See the link:user-manual.html[Git User's Manual] for a more in-depth +introduction, and linkgit:gitcli[7] for details of git's command line interface. The 'command' is either a name of a Git command (see below) or an alias as defined in the configuration file (see linkgit:git-config[1]). I would prefer to keep the description section of git(1) not overly long. The first paragraph (not much shown above) concisely describes what Git is, so that people who were interested in other git can quickly tell that this is not a page to read about it. I think it is in good shape. The purpose of the second paragraph is to guide people who are not ready to dive into this page and refer them to other pages with the introductory material, and also tell them that they can come back to this page to learn the set of commands Git offers once they are familiar with the concepts. And then, before going into the list of commands, we should tell them what we are listing, and where they can find more information. So in that sense, we would really want to keep the second paragraph short and to the point. Referring migrating CVS users to another page before they get acquainted with Git like the current page does is a mistake. On the other hand, gitcli may deserve to be mentioned in the third paragraph that gives the reader the sense of the overall structure of the documentation. Certainly for those learning and in need of help, keeping paragraphs short, to the point, and easy to read is a definate advantage. Once they have found the right command then the documentation can become terse man pages providing precise details. Your arrangement makes sense. The mention of cvs migration used to be more important in earlier days, but I think it was out of place to have it early in the document even back then. It probably can be moved down to the FURTHER DOCUMENTATION section. True. At some point (in the future) the method of accessing the guides/articles (rather than the commands) should be mentioned (somewhere). e.g. that gittutorial can be accessed via 'git tutorial --help' or 'git help tutorial', along with 'git k' etc. So how about doing it this way? I'm on msysgit so don't have the ascii docs tool chain, so I'm visualising. Ack. -- 8 -- Subject: [PATCH] Documentation: update the introductory section The second paragraph in the git(1) description section were meant to guide people who are not ready to dive into this page away from here. Referring migrating CVS users to another page before they get acquainted with Git was somewhat out of place. Move the reference to the FURTHER DOCUMENTATION section and push that section down. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/git.txt | 60 +++ 1 file changed, 32 insertions(+), 28 deletions(-) diff --git a/Documentation/git.txt b/Documentation/git.txt index eb6b2c0..33028a9 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -22,18 +22,17 @@ unusually rich command set that provides both high-level operations and full access to internals. See linkgit:gittutorial[7] to get started, then see -link:everyday.html[Everyday Git] for a useful minimum set of commands, and -man git-commandname for documentation of each command. CVS users may -also want to read linkgit:gitcvs-migration[7]. See -the link:user-manual.html[Git User's Manual] for a more in-depth -introduction. +link:everyday.html[Everyday Git] for a useful minimum set of +commands. The link:user-manual.html[Git User's Manual] has a more +in-depth introduction. -The 'command' is either a name of a Git command (see below) or an alias -as defined in the configuration file (see linkgit:git-config[1]). +After you mastered the basic concepts, you can come back to this +page to learn what commands git offers. You can learn more about +individual git commands with git help command. linkgit:gitcli[7] +manual page gives you an overview of the command line command syntax. -Formatted and hyperlinked version of the
[PATCH/RFC v4 01/16] GSOC remote-svn
Hi! Thanks for the reviews! This series contains the follwing improvements. I decided to summarize them here, sorted by topic instead of attaching them to the patches. all: - remove all merge garbage and debugging legacy (hopefully). - reviews: style - reorder patches remote-svn: - review: refactor (fct - fn), style - fix command batch detection - setup_git_dir, make non-gentle. - die on unknown commands, instead of warning contrib/svn-fe/Makefile, symlink: - remove symlink-creating commit - create symlink after linking remote-svn in Makefile - the makefile is meant as a temporary solution. Therefore, it chooses openssl/sha1.h unconditionally. argv_array: - new patch: add argv_array_detach and argv_array_free_detached transport-helper: - use those new functions - free argv always after finish_command. - remove patch that containing unconditional activation of --export-marks --import-marks on fast-import command line. remote-svn: - instead use fast-import's 'feature' command to activate marks import/export. - use a more decriptive path for storing marks files. Florian [PATCH/RFC v4 01/16] Implement a remote helper for svn in C. [PATCH/RFC v4 02/16] Integrate remote-svn into svn-fe/Makefile. [PATCH/RFC v4 03/16] Add svndump_init_fd to allow reading dumps from [PATCH/RFC v4 04/16] Add argv_array_detach and [PATCH/RFC v4 05/16] Connect fast-import to the remote-helper via [PATCH/RFC v4 06/16] Add documentation for the 'bidi-import' [PATCH/RFC v4 07/16] When debug==1, start fast-import with --stats [PATCH/RFC v4 08/16] remote-svn, vcs-svn: Enable fetching to private [PATCH/RFC v4 09/16] Allow reading svn dumps from files via file:// [PATCH/RFC v4 10/16] vcs-svn: add fast_export_note to create notes [PATCH/RFC v4 11/16] Create a note for every imported commit [PATCH/RFC v4 12/16] remote-svn: Activate import/export-marks for [PATCH/RFC v4 13/16] remote-svn: add incremental import. [PATCH/RFC v4 14/16] Add a svnrdump-simulator replaying a dump file [PATCH/RFC v4 15/16] remote-svn: add marks-file regeneration. [PATCH/RFC v4 16/16] Add a test script for remote-svn. -- 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/RFC v4 01/16] Implement a remote helper for svn in C.
Enable basic fetching from subversion repositories. When processing
remote URLs starting with svn::, git invokes this remote-helper.
It starts svnrdump to extract revisions from the subversion repository
in the 'dump file format', and converts them to a git-fast-import stream
using the functions of vcs-svn/.
Imported refs are created in a private namespace at
refs/svn/remote-name/master.
The revision history is imported linearly (no branch detection) and
completely, i.e. from revision 0 to HEAD.
The 'bidi-import' capability is used. The remote-helper expects data
from fast-import on its stdin. It buffers a batch of 'import' command
lines in a string_list before starting to process them.
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
---
contrib/svn-fe/remote-svn.c | 174 +++
1 file changed, 174 insertions(+)
create mode 100644 contrib/svn-fe/remote-svn.c
diff --git a/contrib/svn-fe/remote-svn.c b/contrib/svn-fe/remote-svn.c
new file mode 100644
index 000..b853d54
--- /dev/null
+++ b/contrib/svn-fe/remote-svn.c
@@ -0,0 +1,174 @@
+#include cache.h
+#include remote.h
+#include strbuf.h
+#include url.h
+#include exec_cmd.h
+#include run-command.h
+#include svndump.h
+#include notes.h
+#include argv-array.h
+
+static const char *url;
+static const char *private_ref;
+static const char *remote_ref = refs/heads/master;
+
+static int cmd_capabilities(const char *line);
+static int cmd_import(const char *line);
+static int cmd_list(const char *line);
+
+typedef int (*input_command_handler)(const char *);
+struct input_command_entry {
+ const char *name;
+ input_command_handler fn;
+ unsigned char batchable;/* whether the command starts or is
part of a batch */
+};
+
+static const struct input_command_entry input_command_list[] = {
+ { capabilities, cmd_capabilities, 0 },
+ { import, cmd_import, 1 },
+ { list, cmd_list, 0 },
+ { NULL, NULL }
+};
+
+static int cmd_capabilities(const char *line) {
+ printf(import\n);
+ printf(bidi-import\n);
+ printf(refspec %s:%s\n\n, remote_ref, private_ref);
+ fflush(stdout);
+ return 0;
+}
+
+static void terminate_batch(void)
+{
+ /* terminate a current batch's fast-import stream */
+ printf(done\n);
+ fflush(stdout);
+}
+
+static int cmd_import(const char *line)
+{
+ int code;
+ int dumpin_fd;
+ unsigned int startrev = 0;
+ struct argv_array svndump_argv = ARGV_ARRAY_INIT;
+ struct child_process svndump_proc;
+
+ memset(svndump_proc, 0, sizeof(struct child_process));
+ svndump_proc.out = -1;
+ argv_array_push(svndump_argv, svnrdump);
+ argv_array_push(svndump_argv, dump);
+ argv_array_push(svndump_argv, url);
+ argv_array_pushf(svndump_argv, -r%u:HEAD, startrev);
+ svndump_proc.argv = svndump_argv.argv;
+
+ code = start_command(svndump_proc);
+ if (code)
+ die(Unable to start %s, code %d, svndump_proc.argv[0], code);
+ dumpin_fd = svndump_proc.out;
+
+ svndump_init_fd(dumpin_fd, STDIN_FILENO);
+ svndump_read(url, private_ref);
+ svndump_deinit();
+ svndump_reset();
+
+ close(dumpin_fd);
+ code = finish_command(svndump_proc);
+ if (code)
+ warning(%s, returned %d, svndump_proc.argv[0], code);
+ argv_array_clear(svndump_argv);
+
+ return 0;
+}
+
+static int cmd_list(const char *line)
+{
+ printf(? %s\n\n, remote_ref);
+ fflush(stdout);
+ return 0;
+}
+
+static int do_command(struct strbuf *line)
+{
+ const struct input_command_entry *p = input_command_list;
+ static struct string_list batchlines = STRING_LIST_INIT_DUP;
+ static const struct input_command_entry *batch_cmd;
+ /*
+* commands can be grouped together in a batch.
+* Batches are ended by \n. If no batch is active the program ends.
+* During a batch all lines are buffered and passed to the handler
function
+* when the batch is terminated.
+*/
+ if (line-len == 0) {
+ if (batch_cmd) {
+ struct string_list_item *item;
+ for_each_string_list_item(item, batchlines)
+ batch_cmd-fn(item-string);
+ terminate_batch();
+ batch_cmd = NULL;
+ string_list_clear(batchlines, 0);
+ return 0; /* end of the batch, continue reading
other commands. */
+ }
+ return 1; /* end of command stream, quit */
+ }
+ if (batch_cmd) {
+ if (prefixcmp(batch_cmd-name, line-buf))
+ die(Active %s batch interrupted by %s,
batch_cmd-name, line-buf);
+ /* buffer batch lines */
+ string_list_append(batchlines, line-buf);
+ return 0;
[PATCH/RFC v4 06/16] Add documentation for the 'bidi-import' capability of remote-helpers.
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com --- Documentation/git-remote-helpers.txt | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index f5836e4..5faa48e 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -98,6 +98,20 @@ advertised with this capability must cover all refs reported by the list command. If no 'refspec' capability is advertised, there is an implied `refspec *:*`. +'bidi-import':: + The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers +to retrieve information about blobs and trees that already exist in +fast-import's memory. This requires a channel from fast-import to the +remote-helper. +If it is advertised in addition to import, git establishes a pipe from + fast-import to the remote-helper's stdin. + It follows that git and fast-import are both connected to the + remote-helper's stdin. Because git can send multiple commands to + the remote-helper it is required that helpers that use 'bidi-import' + buffer all 'import' commands of a batch before sending data to fast-import. +This is to prevent mixing commands and fast-import responses on the +helper's stdin. + Capabilities for Pushing 'connect':: @@ -286,7 +300,12 @@ terminated with a blank line. For each batch of 'import', the remote helper should produce a fast-import stream terminated by a 'done' command. + -Supported if the helper has the import capability. +Note that if the 'bidi-import' capability is used the complete batch +sequence has to be buffered before starting to send data to fast-import +to prevent mixing of commands and fast-import responses on the helper's +stdin. ++ +Supported if the helper has the 'import' capability. 'connect' service:: Connects to given service. Standard input and standard output -- 1.7.9.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/RFC v4 08/16] remote-svn, vcs-svn: Enable fetching to private refs.
The reference to update by the fast-import stream is hard-coded.
When fetching from a remote the remote-helper shall update refs
in a private namespace, i.e. a private subdir of refs/.
This namespace is defined by the 'refspec' capability, that the
remote-helper advertises as a reply to the 'capablilities' command.
Extend svndump and fast-export to allow passing the target ref.
Update svn-fe to be compatible.
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
---
contrib/svn-fe/svn-fe.c |2 +-
test-svn-fe.c |2 +-
vcs-svn/fast_export.c |4 ++--
vcs-svn/fast_export.h |2 +-
vcs-svn/svndump.c | 14 +++---
vcs-svn/svndump.h |2 +-
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/contrib/svn-fe/svn-fe.c b/contrib/svn-fe/svn-fe.c
index 35db24f..c796cc0 100644
--- a/contrib/svn-fe/svn-fe.c
+++ b/contrib/svn-fe/svn-fe.c
@@ -10,7 +10,7 @@ int main(int argc, char **argv)
{
if (svndump_init(NULL))
return 1;
- svndump_read((argc 1) ? argv[1] : NULL);
+ svndump_read((argc 1) ? argv[1] : NULL, refs/heads/master);
svndump_deinit();
svndump_reset();
return 0;
diff --git a/test-svn-fe.c b/test-svn-fe.c
index 83633a2..cb0d80f 100644
--- a/test-svn-fe.c
+++ b/test-svn-fe.c
@@ -40,7 +40,7 @@ int main(int argc, char *argv[])
if (argc == 2) {
if (svndump_init(argv[1]))
return 1;
- svndump_read(NULL);
+ svndump_read(NULL, refs/heads/master);
svndump_deinit();
svndump_reset();
return 0;
diff --git a/vcs-svn/fast_export.c b/vcs-svn/fast_export.c
index 1f04697..11f8f94 100644
--- a/vcs-svn/fast_export.c
+++ b/vcs-svn/fast_export.c
@@ -72,7 +72,7 @@ static char gitsvnline[MAX_GITSVN_LINE_LEN];
void fast_export_begin_commit(uint32_t revision, const char *author,
const struct strbuf *log,
const char *uuid, const char *url,
- unsigned long timestamp)
+ unsigned long timestamp, const char *local_ref)
{
static const struct strbuf empty = STRBUF_INIT;
if (!log)
@@ -84,7 +84,7 @@ void fast_export_begin_commit(uint32_t revision, const char
*author,
} else {
*gitsvnline = '\0';
}
- printf(commit refs/heads/master\n);
+ printf(commit %s\n, local_ref);
printf(mark :%PRIu32\n, revision);
printf(committer %s %s@%s %ld +\n,
*author ? author : nobody,
diff --git a/vcs-svn/fast_export.h b/vcs-svn/fast_export.h
index 8823aca..17eb13b 100644
--- a/vcs-svn/fast_export.h
+++ b/vcs-svn/fast_export.h
@@ -11,7 +11,7 @@ void fast_export_delete(const char *path);
void fast_export_modify(const char *path, uint32_t mode, const char *dataref);
void fast_export_begin_commit(uint32_t revision, const char *author,
const struct strbuf *log, const char *uuid,
- const char *url, unsigned long timestamp);
+ const char *url, unsigned long timestamp, const char
*local_ref);
void fast_export_end_commit(uint32_t revision);
void fast_export_data(uint32_t mode, off_t len, struct line_buffer *input);
void fast_export_blob_delta(uint32_t mode,
diff --git a/vcs-svn/svndump.c b/vcs-svn/svndump.c
index d81a078..288bb42 100644
--- a/vcs-svn/svndump.c
+++ b/vcs-svn/svndump.c
@@ -299,22 +299,22 @@ static void handle_node(void)
node_ctx.text_length, input);
}
-static void begin_revision(void)
+static void begin_revision(const char *remote_ref)
{
if (!rev_ctx.revision) /* revision 0 gets no git commit. */
return;
fast_export_begin_commit(rev_ctx.revision, rev_ctx.author.buf,
rev_ctx.log, dump_ctx.uuid.buf, dump_ctx.url.buf,
- rev_ctx.timestamp);
+ rev_ctx.timestamp, remote_ref);
}
-static void end_revision(void)
+static void end_revision()
{
if (rev_ctx.revision)
fast_export_end_commit(rev_ctx.revision);
}
-void svndump_read(const char *url)
+void svndump_read(const char *url, const char *local_ref)
{
char *val;
char *t;
@@ -353,7 +353,7 @@ void svndump_read(const char *url)
if (active_ctx == NODE_CTX)
handle_node();
if (active_ctx == REV_CTX)
- begin_revision();
+ begin_revision(local_ref);
if (active_ctx != DUMP_CTX)
end_revision();
active_ctx = REV_CTX;
@@ -366,7 +366,7 @@ void svndump_read(const char *url)
if (active_ctx == NODE_CTX)
handle_node();
if (active_ctx
[PATCH/RFC v4 09/16] Allow reading svn dumps from files via file:// urls.
For testing as well as for importing large, already
available dumps, it's useful to bypass svnrdump and
replay the svndump from a file directly.
Add support for file:// urls in the remote url.
e.g. svn::file:///path/to/dump
When the remote helper finds an url starting with
file:// it tries to open that file instead of invoking svnrdump.
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
---
contrib/svn-fe/remote-svn.c | 55 ---
1 file changed, 36 insertions(+), 19 deletions(-)
diff --git a/contrib/svn-fe/remote-svn.c b/contrib/svn-fe/remote-svn.c
index b853d54..80a089a 100644
--- a/contrib/svn-fe/remote-svn.c
+++ b/contrib/svn-fe/remote-svn.c
@@ -9,6 +9,7 @@
#include argv-array.h
static const char *url;
+static int dump_from_file;
static const char *private_ref;
static const char *remote_ref = refs/heads/master;
@@ -53,29 +54,38 @@ static int cmd_import(const char *line)
struct argv_array svndump_argv = ARGV_ARRAY_INIT;
struct child_process svndump_proc;
- memset(svndump_proc, 0, sizeof(struct child_process));
- svndump_proc.out = -1;
- argv_array_push(svndump_argv, svnrdump);
- argv_array_push(svndump_argv, dump);
- argv_array_push(svndump_argv, url);
- argv_array_pushf(svndump_argv, -r%u:HEAD, startrev);
- svndump_proc.argv = svndump_argv.argv;
-
- code = start_command(svndump_proc);
- if (code)
- die(Unable to start %s, code %d, svndump_proc.argv[0], code);
- dumpin_fd = svndump_proc.out;
-
+ if (dump_from_file) {
+ dumpin_fd = open(url, O_RDONLY);
+ if(dumpin_fd 0) {
+ die_errno(Couldn't open svn dump file %s., url);
+ }
+ }
+ else {
+ memset(svndump_proc, 0, sizeof(struct child_process));
+ svndump_proc.out = -1;
+ argv_array_push(svndump_argv, svnrdump);
+ argv_array_push(svndump_argv, dump);
+ argv_array_push(svndump_argv, url);
+ argv_array_pushf(svndump_argv, -r%u:HEAD, startrev);
+ svndump_proc.argv = svndump_argv.argv;
+
+ code = start_command(svndump_proc);
+ if (code)
+ die(Unable to start %s, code %d,
svndump_proc.argv[0], code);
+ dumpin_fd = svndump_proc.out;
+ }
svndump_init_fd(dumpin_fd, STDIN_FILENO);
svndump_read(url, private_ref);
svndump_deinit();
svndump_reset();
close(dumpin_fd);
- code = finish_command(svndump_proc);
- if (code)
- warning(%s, returned %d, svndump_proc.argv[0], code);
- argv_array_clear(svndump_argv);
+ if(!dump_from_file) {
+ code = finish_command(svndump_proc);
+ if (code)
+ warning(%s, returned %d, svndump_proc.argv[0], code);
+ argv_array_clear(svndump_argv);
+ }
return 0;
}
@@ -149,8 +159,15 @@ int main(int argc, const char **argv)
remote = remote_get(argv[1]);
url_in = (argc == 3) ? argv[2] : remote-url[0];
- end_url_with_slash(buf, url_in);
- url = strbuf_detach(buf, NULL);
+ if (!prefixcmp(url_in, file://)) {
+ dump_from_file = 1;
+ url = url_decode(url_in + sizeof(file://)-1);
+ }
+ else {
+ dump_from_file = 0;
+ end_url_with_slash(buf, url_in);
+ url = strbuf_detach(buf, NULL);
+ }
strbuf_addf(buf, refs/svn/%s/master, remote-name);
private_ref = strbuf_detach(buf, NULL);
--
1.7.9.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/RFC v4 11/16] Create a note for every imported commit containing svn metadata.
To provide metadata from svn dumps for further processing, e.g.
branch detection, attach a note to each imported commit that
stores additional information.
The notes are currently hard-coded in refs/notes/svn/revs.
Currently the following lines from the svn dump are directly
accumulated in the note. This can be refined on purpose, of course.
- Revision-number
- Node-path
- Node-kind
- Node-action
- Node-copyfrom-path
- Node-copyfrom-rev
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
---
vcs-svn/fast_export.c | 14 --
vcs-svn/fast_export.h |2 ++
vcs-svn/svndump.c | 21 +++--
3 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/vcs-svn/fast_export.c b/vcs-svn/fast_export.c
index 1ecae4b..a84fa17 100644
--- a/vcs-svn/fast_export.c
+++ b/vcs-svn/fast_export.c
@@ -3,8 +3,7 @@
* See LICENSE for details.
*/
-#include git-compat-util.h
-#include strbuf.h
+#include cache.h
#include quote.h
#include fast_export.h
#include repo_tree.h
@@ -68,6 +67,17 @@ void fast_export_modify(const char *path, uint32_t mode,
const char *dataref)
putchar('\n');
}
+void fast_export_begin_note(uint32_t revision, const char *author,
+ const char *log, unsigned long timestamp)
+{
+ size_t loglen = strlen(log);
+ printf(commit refs/notes/svn/revs\n);
+ printf(committer %s %s@%s %ld +\n, author, author, local,
timestamp);
+ printf(data %PRIuMAX\n, loglen);
+ fwrite(log, loglen, 1, stdout);
+ fputc('\n', stdout);
+}
+
void fast_export_note(const char *committish, const char *dataref)
{
printf(N %s %s\n, dataref, committish);
diff --git a/vcs-svn/fast_export.h b/vcs-svn/fast_export.h
index 9b32f1e..c2f6f11 100644
--- a/vcs-svn/fast_export.h
+++ b/vcs-svn/fast_export.h
@@ -10,6 +10,8 @@ void fast_export_deinit(void);
void fast_export_delete(const char *path);
void fast_export_modify(const char *path, uint32_t mode, const char *dataref);
void fast_export_note(const char *committish, const char *dataref);
+void fast_export_begin_note(uint32_t revision, const char *author,
+ const char *log, unsigned long timestamp);
void fast_export_begin_commit(uint32_t revision, const char *author,
const struct strbuf *log, const char *uuid,
const char *url, unsigned long timestamp, const char
*local_ref);
diff --git a/vcs-svn/svndump.c b/vcs-svn/svndump.c
index 288bb42..cd65b51 100644
--- a/vcs-svn/svndump.c
+++ b/vcs-svn/svndump.c
@@ -48,7 +48,7 @@ static struct {
static struct {
uint32_t revision;
unsigned long timestamp;
- struct strbuf log, author;
+ struct strbuf log, author, note;
} rev_ctx;
static struct {
@@ -77,6 +77,7 @@ static void reset_rev_ctx(uint32_t revision)
rev_ctx.timestamp = 0;
strbuf_reset(rev_ctx.log);
strbuf_reset(rev_ctx.author);
+ strbuf_reset(rev_ctx.note);
}
static void reset_dump_ctx(const char *url)
@@ -310,8 +311,15 @@ static void begin_revision(const char *remote_ref)
static void end_revision()
{
- if (rev_ctx.revision)
+ struct strbuf mark = STRBUF_INIT;
+ if (rev_ctx.revision) {
fast_export_end_commit(rev_ctx.revision);
+ fast_export_begin_note(rev_ctx.revision, remote-svn,
+ Note created by remote-svn.,
rev_ctx.timestamp);
+ strbuf_addf(mark, :%PRIu32, rev_ctx.revision);
+ fast_export_note(mark.buf, inline);
+ fast_export_buf_to_data(rev_ctx.note);
+ }
}
void svndump_read(const char *url, const char *local_ref)
@@ -358,6 +366,7 @@ void svndump_read(const char *url, const char *local_ref)
end_revision();
active_ctx = REV_CTX;
reset_rev_ctx(atoi(val));
+ strbuf_addf(rev_ctx.note, %s\n, t);
break;
case sizeof(Node-path):
if (constcmp(t, Node-))
@@ -369,10 +378,12 @@ void svndump_read(const char *url, const char *local_ref)
begin_revision(local_ref);
active_ctx = NODE_CTX;
reset_node_ctx(val);
+ strbuf_addf(rev_ctx.note, %s\n, t);
break;
}
if (constcmp(t + strlen(Node-), kind))
continue;
+ strbuf_addf(rev_ctx.note, %s\n, t);
if (!strcmp(val, dir))
node_ctx.type = REPO_MODE_DIR;
else if (!strcmp(val, file))
@@ -383,6 +394,7 @@ void svndump_read(const char *url, const char *local_ref)
case sizeof(Node-action):
if (constcmp(t, Node-action))
[PATCH/RFC v4 14/16] Add a svnrdump-simulator replaying a dump file for testing.
To ease testing without depending on a reachable svn server, this
compact python script mimics parts of svnrdumps behaviour.
It requires the remote url to start with sim://.
Start and end revisions are evaluated.
If the requested revision doesn't exist, as it is the case with
incremental imports, if no new commit was added, it returns 1
(like svnrdump).
To allow using the same dump file for simulating multiple
incremental imports the highest revision can be limited by setting
the environment variable SVNRMAX to that value. This simulates the
situation where higher revs don't exist yet.
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
---
contrib/svn-fe/svnrdump_sim.py | 53
1 file changed, 53 insertions(+)
create mode 100755 contrib/svn-fe/svnrdump_sim.py
diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
new file mode 100755
index 000..ab4ccf1
--- /dev/null
+++ b/contrib/svn-fe/svnrdump_sim.py
@@ -0,0 +1,53 @@
+#!/usr/bin/python
+
+Simulates svnrdump by replaying an existing dump from a file, taking care
+of the specified revision range.
+To simulate incremental imports the environment variable SVNRMAX can be set
+to the highest revision that should be available.
+
+import sys, os
+
+
+def getrevlimit():
+ var = 'SVNRMAX'
+ if os.environ.has_key(var):
+ return os.environ[var]
+ return None
+
+def writedump(url, lower, upper):
+ if url.startswith('sim://'):
+ filename = url[6:]
+ if filename[-1] == '/': filename = filename[:-1] #remove
terminating slash
+ else:
+ raise ValueError('sim:// url required')
+ f = open(filename, 'r');
+ state = 'header'
+ wroterev = False
+ while(True):
+ l = f.readline()
+ if l == '': break
+ if state == 'header' and l.startswith('Revision-number: '):
+ state = 'prefix'
+ if state == 'prefix' and l == 'Revision-number: %s\n' % lower:
+ state = 'selection'
+ if not upper == 'HEAD' and state == 'selection' and l ==
'Revision-number: %s\n' % upper:
+ break;
+
+ if state == 'header' or state == 'selection':
+ if state == 'selection': wroterev = True
+ sys.stdout.write(l)
+ return wroterev
+
+if __name__ == __main__:
+ if not (len(sys.argv) in (3, 4, 5)):
+ print usage: %s dump URL -rLOWER:UPPER
+ sys.exit(1)
+ if not sys.argv[1] == 'dump': raise NotImplementedError('only dump is
suppported.')
+ url = sys.argv[2]
+ r = ('0', 'HEAD')
+ if len(sys.argv) == 4 and sys.argv[3][0:2] == '-r':
+ r = sys.argv[3][2:].lstrip().split(':')
+ if not getrevlimit() is None: r[1] = getrevlimit()
+ if writedump(url, r[0], r[1]): ret = 0
+ else: ret = 1
+ sys.exit(ret)
--
1.7.9.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/RFC v4 13/16] remote-svn: add incremental import.
Search for a note attached to the ref to update and read it's
'Revision-number:'-line. Start import from the next svn revision.
If there is no next revision in the svn repo, svnrdump terminates
with a message on stderr an non-zero return value. This looks a
little weird, but there is no other way to know whether there is
a new revision in the svn repo.
On the start of an incremental import, the parent of the first commit
in the fast-import stream is set to the branch name to update. All
following commits specify their parent by a mark number. Previous
mark files are currently not reused.
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
---
contrib/svn-fe/remote-svn.c | 67 +--
contrib/svn-fe/svn-fe.c |3 +-
test-svn-fe.c |2 +-
vcs-svn/fast_export.c | 10 +--
vcs-svn/fast_export.h |6 ++--
vcs-svn/svndump.c | 10 +++
vcs-svn/svndump.h |2 +-
7 files changed, 84 insertions(+), 16 deletions(-)
diff --git a/contrib/svn-fe/remote-svn.c b/contrib/svn-fe/remote-svn.c
index 0643a4c..b385682 100644
--- a/contrib/svn-fe/remote-svn.c
+++ b/contrib/svn-fe/remote-svn.c
@@ -12,7 +12,8 @@ static const char *url;
static int dump_from_file;
static const char *private_ref;
static const char *remote_ref = refs/heads/master;
-static const char *marksfilename;
+static const char *marksfilename, *notes_ref;
+struct rev_note { unsigned int rev_nr; };
static int cmd_capabilities(const char *line);
static int cmd_import(const char *line);
@@ -47,14 +48,70 @@ static void terminate_batch(void)
fflush(stdout);
}
+/* NOTE: 'ref' refers to a git reference, while 'rev' refers to a svn
revision. */
+static char *read_ref_note(const unsigned char sha1[20]) {
+ const unsigned char *note_sha1;
+ char *msg = NULL;
+ unsigned long msglen;
+ enum object_type type;
+ init_notes(NULL, notes_ref, NULL, 0);
+ if( (note_sha1 = get_note(NULL, sha1)) == NULL ||
+ !(msg = read_sha1_file(note_sha1, type, msglen)) ||
+ !msglen || type != OBJ_BLOB) {
+ free(msg);
+ return NULL;
+ }
+ free_notes(NULL);
+ return msg;
+}
+
+static int parse_rev_note(const char *msg, struct rev_note *res) {
+ const char *key, *value, *end;
+ size_t len;
+ while(*msg) {
+ end = strchr(msg, '\n');
+ len = end ? end - msg : strlen(msg);
+
+ key = Revision-number: ;
+ if(!prefixcmp(msg, key)) {
+ long i;
+ value = msg + strlen(key);
+ i = atol(value);
+ if(i 0 || i UINT32_MAX)
+ return 1;
+ res-rev_nr = i;
+ }
+ msg += len + 1;
+ }
+ return 0;
+}
+
static int cmd_import(const char *line)
{
int code;
int dumpin_fd;
- unsigned int startrev = 0;
+ char *note_msg;
+ unsigned char head_sha1[20];
+ unsigned int startrev;
struct argv_array svndump_argv = ARGV_ARRAY_INIT;
struct child_process svndump_proc;
+ if(read_ref(private_ref, head_sha1))
+ startrev = 0;
+ else {
+ note_msg = read_ref_note(head_sha1);
+ if(note_msg == NULL) {
+ warning(No note found for %s., private_ref);
+ startrev = 0;
+ }
+ else {
+ struct rev_note note = { 0 };
+ parse_rev_note(note_msg, note);
+ startrev = note.rev_nr + 1;
+ free(note_msg);
+ }
+ }
+
if (dump_from_file) {
dumpin_fd = open(url, O_RDONLY);
if(dumpin_fd 0) {
@@ -80,7 +137,7 @@ static int cmd_import(const char *line)
feature export-marks=%s\n, marksfilename,
marksfilename);
svndump_init_fd(dumpin_fd, STDIN_FILENO);
- svndump_read(url, private_ref);
+ svndump_read(url, private_ref, notes_ref);
svndump_deinit();
svndump_reset();
@@ -177,6 +234,9 @@ int main(int argc, const char **argv)
strbuf_addf(buf, refs/svn/%s/master, remote-name);
private_ref = strbuf_detach(buf, NULL);
+ strbuf_addf(buf, refs/notes/%s/revs, remote-name);
+ notes_ref = strbuf_detach(buf, NULL);
+
strbuf_addf(buf, %s/info/fast-import/remote-svn/%s.marks,
get_git_dir(), remote-name);
marksfilename = strbuf_detach(buf, NULL);
@@ -196,6 +256,7 @@ int main(int argc, const char **argv)
strbuf_release(buf);
free((void*)url);
free((void*)private_ref);
+ free((void*)notes_ref);
free((void*)marksfilename);
return 0;
}
diff --git
[RFC 3/5] vcs-svn/svndump: restructure node_ctx, rev_ctx handling
As a preparation for handling branches in svndumps, make rev_ctx
and node_ctx more flexible.
Add the object to work on to the arguments of reset_*_ctx() and to
handle_node() to allow for multiple *_ctx objects.
Convert the static global node_ctx to a linked list ofsuch objects
to be able to accumulate all Node data of a revision in memory
before processing it.
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
---
vcs-svn/svndump.c | 207 +++--
vcs-svn/svndump.h |2 +
2 files changed, 124 insertions(+), 85 deletions(-)
diff --git a/vcs-svn/svndump.c b/vcs-svn/svndump.c
index 296be8c..2fca9f8 100644
--- a/vcs-svn/svndump.c
+++ b/vcs-svn/svndump.c
@@ -38,42 +38,81 @@
static struct line_buffer input = LINE_BUFFER_INIT;
-static struct node_ctx_t node_ctx;
+static struct node_ctx_t *node_ctx;
static struct rev_ctx_t rev_ctx;
static struct dump_ctx_t dump_ctx;
+static const char *current_ref;
+static struct node_ctx_t *node_list, *node_list_tail;
-static void reset_node_ctx(char *fname)
+static struct node_ctx_t *new_node_ctx(char *fname)
{
- node_ctx.type = 0;
- node_ctx.action = NODEACT_UNKNOWN;
- node_ctx.prop_length = -1;
- node_ctx.text_length = -1;
- strbuf_reset(node_ctx.src);
- node_ctx.srcRev = 0;
- strbuf_reset(node_ctx.dst);
+ struct node_ctx_t *node = xmalloc(sizeof(struct node_ctx_t));
+ trace_printf(new_node_ctx %p\n, node);
+ node-type = 0;
+ node-action = NODEACT_UNKNOWN;
+ node-prop_length = -1;
+ node-text_length = -1;
+ strbuf_init(node-src, 4096);
+ node-srcRev = 0;
+ strbuf_init(node-dst, 4096);
if (fname)
- strbuf_addstr(node_ctx.dst, fname);
- node_ctx.text_delta = 0;
- node_ctx.prop_delta = 0;
+ strbuf_addstr(node-dst, fname);
+ node-text_delta = 0;
+ node-prop_delta = 0;
+ node-dataref = NULL;
+ node-next = NULL;
+ return node;
}
-static void reset_rev_ctx(uint32_t revision)
+static void free_node_ctx(struct node_ctx_t *node)
{
- rev_ctx.revision = revision;
- rev_ctx.timestamp = 0;
- strbuf_reset(rev_ctx.log);
- strbuf_reset(rev_ctx.author);
- strbuf_reset(rev_ctx.note);
+ trace_printf(free_node_ctx %p\n, node);
+ strbuf_release(node-src);
+ strbuf_release(node-dst);
+ free((char*)node-dataref);
+ free(node);
}
-static void reset_dump_ctx(const char *url)
+static void free_node_list()
{
- strbuf_reset(dump_ctx.url);
+ struct node_ctx_t *p = node_list, *n;
+ trace_printf(free_node_list head %p tail %p\n, node_list,
node_list_tail);
+ while (p) {
+ n = p-next;
+ free_node_ctx(p);
+ p = n;
+ }
+ node_list = node_list_tail = NULL;
+}
+
+static void append_node_list(struct node_ctx_t *n)
+{
+ trace_printf(append_node_list %p head %p tail %p\n, n, node_list,
node_list_tail);
+ if (!node_list)
+ node_list = node_list_tail = n;
+ else {
+ node_list_tail-next = n;
+ node_list_tail = n;
+ }
+}
+
+static void reset_rev_ctx(struct rev_ctx_t *rev, uint32_t revision)
+{
+ rev-revision = revision;
+ rev-timestamp = 0;
+ strbuf_reset(rev-log);
+ strbuf_reset(rev-author);
+ strbuf_reset(rev-note);
+}
+
+static void reset_dump_ctx(struct dump_ctx_t *dump, const char *url)
+{
+ strbuf_reset(dump-url);
if (url)
- strbuf_addstr(dump_ctx.url, url);
- dump_ctx.version = 1;
- strbuf_reset(dump_ctx.uuid);
+ strbuf_addstr(dump-url, url);
+ dump-version = 1;
+ strbuf_reset(dump-uuid);
}
static void handle_property(const struct strbuf *key_buf,
@@ -121,11 +160,11 @@ static void handle_property(const struct strbuf *key_buf,
die(invalid dump: sets type twice);
}
if (!val) {
- node_ctx.type = REPO_MODE_BLB;
+ node_ctx-type = REPO_MODE_BLB;
return;
}
*type_set = 1;
- node_ctx.type = keylen == strlen(svn:executable) ?
+ node_ctx-type = keylen == strlen(svn:executable) ?
REPO_MODE_EXE :
REPO_MODE_LNK;
}
@@ -193,11 +232,11 @@ static void read_props(void)
}
}
-static void handle_node(void)
+static void handle_node(struct node_ctx_t *node)
{
- const uint32_t type = node_ctx.type;
- const int have_props = node_ctx.prop_length != -1;
- const int have_text = node_ctx.text_length != -1;
+ const uint32_t type = node-type;
+ const int have_props = node-prop_length != -1;
+ const int have_text = node-text_length != -1;
/*
* Old text for this node:
[RFC 4/5] vcs-svn/svndump: rewrite handle_node(), begin|end_revision()
Split the decision of what to do and actually doing it in
handle_node() to allow for detection of branches from svn nodes.
Split it into handle_node() and apply_node().
svn dumps are structured in revisions, which contain multiple nodes.
Nodes represent operations on data. Currently the function
handle_node() strongly mixes the interpretation of the node data
with the output of processed data to fast-import.
In a fast-import stream a commit object requires a branch name to
which the new commit is added at its beginning.
We want to detect branches in svn. This can only be done by analyzing
node operations, like copyfrom. This conflicts with the current
implementation, where at the beginning of each new revision in the svn
dump, a new commit on a hard-coded git branch is created, before even
reading the first node.
To allow analyzing the nodes before deciding on which branch the commit
will be placed, store the node metadata of one complete revision, and
create a commit from it, when it ends.
Each node can have file data appended. It's desirable to not store the
actual file data, as it is unbounded.
fast-import has a 'blob' command that allows writing blobs, independent
of commits. Use this feature instead of sending data inline and send
the actual file data immediately when it is read in.
Use the previously added SHA1 calculation feature of fast_export_data
and fast_export_blob_delta to retrieve the SHA1 of the written blob
and reference it later. fast-import's marks can not be used for that,
because they are already used for marking commits, where the mark
number corresponds to exactly one svn revision.
Change handle_node() to interpret the node data, store it in a node_ctx,
send blobs to fast-import, and append the new node_ctx to the list of
node_ctx.
Do this until the end of a revision.
Just clear the list of note_ctx in begin_revision().
At end_revision() all node metadata is available in the node_ctx list.
Future's branch detectors can decide what branches are to be changed.
Then, call apply_node() for each of them to actually create a commit
and change/add/delete files according to the node_ctx using the already
added blobs.
This can also be used to create commits if the node metadata does not
come from a svndump, but is stored in e.g. notes, for later branch
detection.
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
---
vcs-svn/svndump.c | 165 ++---
1 file changed, 107 insertions(+), 58 deletions(-)
diff --git a/vcs-svn/svndump.c b/vcs-svn/svndump.c
index 2fca9f8..6feedd9 100644
--- a/vcs-svn/svndump.c
+++ b/vcs-svn/svndump.c
@@ -48,7 +48,6 @@ static struct node_ctx_t *node_list, *node_list_tail;
static struct node_ctx_t *new_node_ctx(char *fname)
{
struct node_ctx_t *node = xmalloc(sizeof(struct node_ctx_t));
- trace_printf(new_node_ctx %p\n, node);
node-type = 0;
node-action = NODEACT_UNKNOWN;
node-prop_length = -1;
@@ -67,7 +66,6 @@ static struct node_ctx_t *new_node_ctx(char *fname)
static void free_node_ctx(struct node_ctx_t *node)
{
- trace_printf(free_node_ctx %p\n, node);
strbuf_release(node-src);
strbuf_release(node-dst);
free((char*)node-dataref);
@@ -77,7 +75,6 @@ static void free_node_ctx(struct node_ctx_t *node)
static void free_node_list()
{
struct node_ctx_t *p = node_list, *n;
- trace_printf(free_node_list head %p tail %p\n, node_list,
node_list_tail);
while (p) {
n = p-next;
free_node_ctx(p);
@@ -88,7 +85,6 @@ static void free_node_list()
static void append_node_list(struct node_ctx_t *n)
{
- trace_printf(append_node_list %p head %p tail %p\n, n, node_list,
node_list_tail);
if (!node_list)
node_list = node_list_tail = n;
else {
@@ -246,23 +242,10 @@ static void handle_node(struct node_ctx_t *node)
static const char *const empty_blob = ::empty::;
const char *old_data = NULL;
uint32_t old_mode = REPO_MODE_BLB;
+ unsigned char data_sha1[20];
+ struct strbuf sb = STRBUF_INIT;
+
- if (node-action == NODEACT_DELETE) {
- if (have_text || have_props || node-srcRev)
- die(invalid dump: deletion node has
- copyfrom info, text, or properties);
- repo_delete(node-dst.buf);
- return;
- }
- if (node-action == NODEACT_REPLACE) {
- repo_delete(node-dst.buf);
- node-action = NODEACT_ADD;
- }
- if (node-srcRev) {
- repo_copy(node-srcRev, node-src.buf, node-dst.buf);
- if (node-action == NODEACT_ADD)
- node-action = NODEACT_CHANGE;
- }
if (have_text type == REPO_MODE_DIR)
die(invalid dump: directories cannot have text attached);
@@ -270,28 +253,61 @@ static void
Re: Temporary merge branch 2 Conflicts
- Original Message - From: Stephen Bash b...@genarts.com Sent: Friday, August 17, 2012 9:48:45 AM Subject: Temporary merge branch 2 Conflicts Given this branch history: -M--M---M--- dev \ / / / -- v1-maint \ \ \ M---M--- v1.5-maint I am attempting to merge v1.5-maint into dev. Turns out (not surprisingly) the graph is not that simple. I have multiple (disjoint) merge bases: $ git merge-base --all dev v1.5-maint ad9ed6c207fba9419b10a394e3721333d0d73e81 5ff4cb0927188fb7246a0eff22d7ffed1a91fe2d $ git rev-list --ancestry-path 5ff4cb0..ad9ed6c $ A little investigation of 5ff4cb0 shows the branch structure looks more like: A-C- v1-maint / |\ o | \ \ | \ B | \ |\|\ --|-M---|-M--- v1.5-maint | | --M-M- dev B is 5ff4cb0 and C is ad9ed6c (with several months and commits separating them). A and B are tree-same (the only difference is the commit time and the log message). Again, I'm attempting to merge v1.5-maint into dev. Googling around I found a few mentions of these temporary merge branches, e.g. $gmane/157591, but I don't think we have any criss-cross merges. And now I'm convinced I do have some form of degenerate merge case. I made several attempts to dig myself out of this hole, but failed. What is the recommended method for resolving this sort of merge? kdiff3 obviously doesn't understand the situation. Do the working tree files contain all the conflicts? If so, I can just go through by hand and resolve the conflicts the old fashion way. Separately, is mergetool passing the correct base file to the external tool if I'm seeing Temporary merge branch conflicts in it? (I'm using git 1.7.11.4) Thanks! Stephen -- 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: Temporary merge branch 2 Conflicts
Stephen Bash b...@genarts.com writes: What is the recommended method for resolving this sort of merge? kdiff3 obviously doesn't understand the situation. Do the working tree files contain all the conflicts? If so, I can just go through by hand and resolve the conflicts the old fashion way. Yes. External tools like kdiff3 may not understand the conflict in the working tree, but the files in the working tree should have resolved the naturally resolvable bits and only left the conflicted bits conflicted. Just resolve manually if you can, and then look at what both branches wanted to do to the file (git log -p --merge $that_path before you git add as the final sanity check would work nicely) to make sure your resolution makes sense. -- 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
Surprising tag selection by 'git describe --contains'
On Fri, 2012-08-17 at 06:22 -0700, Greg KH wrote: On Fri, Aug 17, 2012 at 09:18:44AM +0200, Daniel Vetter wrote: On Fri, Aug 17, 2012 at 1:18 AM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Aug 14, 2012 at 01:50:11AM -0400, Gregs git-bot wrote: commit: 5ab3633d6907018b0b830a720e877c3884d679c3 From: Hunt Xu mhun...@gmail.com Date: Sun, 1 Jul 2012 03:45:07 + Subject: drm/i915: make rc6 in sysfs functions conditional Commit 0136db586c028f71e7cc21cc183064ff0d5919c8 merges rc6 information into the power group. However, when compiled with CONFIG_PM not set, modprobing i915 would taint since power_group_name is defined as NULL. This patch makes these rc6 in sysfs functions conditional upon the definition of the CONFIG_PM macro to avoid the above-mentioned problem. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45181 Cc: sta...@vger.kernel.org Tested-by: Kris Karas bugs-...@moonlit-rail.com Signed-off-by: Hunt Xu mhun...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_sysfs.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) As commit 0136db586c028f71e7cc21cc183064ff0d5919c8 only first showed up in 3.6-rc1, is this patch still needed for the stable tree(s)? My git tag --contains claims it's in 3.5 already. Really? $ git describe --contains 0136db586c028f71e7cc21cc183064ff0d5919c8 v3.6-rc1~59^2~56^2~76 Do you see something else? 'git describe --contains' seems to choose the containing tag whose tree has the shortest path from the given tree-like. So, when some branch has relatively few changes after Linus pulls it for release N and before he pulls it for release N+1 *and* he pulls it later in the merge window for release N+1, commits include in v3.N-rc1 can still be closer to v3.(N+1)-rc1 because the extra merge commits on the path to v3.N-rc1 outweigh the extra non-merge commits on the path to v3.(N+1)-rc1. git certainly doesn't (and shouldn't) know anything about ordering of tag names, but I think that if one of the containing tags is the ancestor of all the others then 'git describe --contains' should prefer to use that. Or at least, there should be some way to request that behaviour. For now, if in doubt, 'git tag --contains' will tell you all the containing tags. Ben. And people have reported the regressions to prove it ;-) Ok, fair enough, I'll apply it. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part
Re: Git feature request: --amend older commit
On Fri, Aug 17, 2012 at 11:47:49AM -0400, George Spelvin wrote: Something like git commit --fixup HEAD~3, where git commit --fixup HEAD would be equivalent to git commit --amend. Aside from the ways others mentioned on how to do this, I think that a better interface if this were to be added would be to make the commit an optional parameter of --amend. Adding another parameter which effectively does a superset of --amend sounds unnecessary. I often want to amend a commit, but its simply too much work, so I usually commit it marking the message as something like fixup! Then, before I push, I make sure to rebase all of the commits marked as fixups. Clearly autosquash does this, but to have to override the editor as true is just a hassle. I feel like this is a common enough need that it deserves more first class support than relying on the rebase command and then using true as an editor. Either it should be supported natively or it should be possible to autosquash a rebase without --interactive, since at present --autosquash requires --interactive, which isn't nice for when the user does not want the rebase to be interactive. Such a simple task shouldn't require an interactive command. -- 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
