Re: [PATCH 2/2] format-patch: give --reroll-count a short synonym -v
Junio C Hamano writes: > "Philip Oakley" writes: > >>> +test_expect_success 'reroll count (-v)' ' >>> + rm -fr patches && >>> + git format-patch -o patches --cover-letter -v 4 master..side >list >>> && >> >> Shouldn't this be using the sticked form -v4 as described in the >> commit message and gitcli? > > I personally do not care too deeply either way. Actually, I do care. And in this case both should work. Separating argument from the option ~~~ You can write the mandatory option parameter to an option as a separate word on the command line. That means that all the following uses work: $ git foo --long-opt=Arg $ git foo --long-opt Arg $ git foo -oArg $ git foo -o Arg As "reroll-count" must always be followed by nth (in other words, it is not optional), the following does not apply. However, this is *NOT* allowed for switches with an optional value, where the 'sticked' form must be used: -- 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 2/2] format-patch: give --reroll-count a short synonym -v
From: "Junio C Hamano" Sent: Wednesday, January 02,
2013 10:42 PM
Accept "-v" as a synonym to "--reroll-count", so that users can say
"git format-patch -v4 master", instead of having to fully spell it
out as "git format-patch --reroll-count=4 master".
Signed-off-by: Junio C Hamano
---
* As I do not think of a reason why users would want to tell the
command to be "verbose", I think it may be OK to squat on the
short and sweet single letter option, but I do not mind dropping
it.
Documentation/git-format-patch.txt | 3 ++-
builtin/log.c | 2 +-
t/t4014-format-patch.sh| 8
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-format-patch.txt
b/Documentation/git-format-patch.txt
index 736d8bf..ae3212e 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -18,7 +18,7 @@ SYNOPSIS
[--start-number ] [--numbered-files]
[--in-reply-to=Message-Id] [--suffix=.]
[--ignore-if-in-upstream]
-[--subject-prefix=Subject-Prefix] [--reroll-count ]
+[--subject-prefix=Subject-Prefix] [(--reroll-count|-v) ]
[--to=] [--cc=]
[--cover-letter] [--quiet]
[]
@@ -166,6 +166,7 @@ will want to ensure that threading is disabled for
`git send-email`.
allows for useful naming of a patch series, and can be
combined with the `--numbered` option.
+-v ::
--reroll-count=::
Mark the series as the -th iteration of the topic. The
output filenames have `v` pretended to them, and the
diff --git a/builtin/log.c b/builtin/log.c
index e101498..08e8a9d 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1081,7 +1081,7 @@ int cmd_format_patch(int argc, const char
**argv, const char *prefix)
N_("use instead of '.patch'")),
OPT_INTEGER(0, "start-number", &start_number,
N_("start numbering patches at instead of 1")),
- OPT_INTEGER(0, "reroll-count", &reroll_count,
+ OPT_INTEGER('v', "reroll-count", &reroll_count,
N_("mark the series as Nth re-roll")),
{ OPTION_CALLBACK, 0, "subject-prefix", &rev, N_("prefix"),
N_("Use [] instead of [PATCH]"),
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 0ff9958..03b8e51 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -245,6 +245,14 @@ test_expect_success 'reroll count' '
! grep -v "^Subject: \[PATCH v4 [0-3]/3\] " subjects
'
+test_expect_success 'reroll count (-v)' '
+ rm -fr patches &&
+ git format-patch -o patches --cover-letter -v 4 master..side >list
&&
Shouldn't this be using the sticked form -v4 as described in the commit
message and gitcli?
Or is this being too picky?
+ ! grep -v "^patches/v4-000[0-3]-" list &&
+ sed -n -e "/^Subject: /p" $(cat list) >subjects &&
+ ! grep -v "^Subject: \[PATCH v4 [0-3]/3\] " subjects
+'
+
check_threading () {
expect="$1" &&
shift &&
--
1.8.0.9.g5e84801
--
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
Fwd: Git hangs after resolving deltas when using NTLM proxy on Windows
Hi, Git is authenticating to my corporate proxy correctly, but is hanging after "resolving deltas". This is when cloning via HTTPS. Apologies for linking to a Gist, but I'm having difficulty getting this list to accept a log file attachment. See https://gist.github.com/4448684 for the curl log. Regards, Adam -- 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 2/2] format-patch: give --reroll-count a short synonym -v
"Philip Oakley" writes: >> +test_expect_success 'reroll count (-v)' ' >> + rm -fr patches && >> + git format-patch -o patches --cover-letter -v 4 master..side >list >> && > > Shouldn't this be using the sticked form -v4 as described in the > commit message and gitcli? I personally do not care too deeply either way. Both styles seem to work, and if/when we break parse-options API implementation, this test will break and we will notice, which might be an added plus ;-) -- 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: Pretty pictures of git merge conflicts
On Thu, Jan 3, 2013 at 11:37 AM, Michael Haggerty wrote: > Hi, > > I've been thinking lately about how to attack difficult git merge > conflicts. The first step is to visualize them. I have written some > articles [1,2,3] describing a way to atomize a complicated merge and > efficiently compute diagrams that show which pairwise commits cause the > merge to go awry. I hope you find them interesting; feedback would be > very welcome. > > I am working on some more articles (including software) that I plan to > grow into tools to help users perform git merges that would otherwise > seem hopeless. Interesting work Michael! Interestingly, I've taken such an approach in a few real life situations. It was a real help it trying to get the conflicts resolved, so I'm eager to see the tools you come up with! -John -- 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: Lockless Refs? (Was [PATCH] refs: do not use cached refs in repack_without_ref)
Any thoughts on this idea? Is it flawed? I am trying to write it up in a more formal generalized manner and was hoping to get at least one "it seems sane" before I do. Thanks, -Martin On Monday, December 31, 2012 03:30:53 am Martin Fick wrote: > On Thursday, December 27, 2012 04:11:51 pm Martin Fick wrote: > > It concerns me that git uses any locking at all, even > > for refs since it has the potential to leave around > > stale locks. > > ... > > [a previous not so great attempt to fix this] > > ... > > I may have finally figured out a working loose ref update > mechanism which I think can avoid stale locks. > Unfortunately it requires atomic directory renames and > universally unique identifiers (uuids). These may be > no-go criteria? But I figure it is worth at least > exploring this idea because of the potential benefits? > > The general approach is to setup a transaction and either > commit or abort it. A transaction can be setup by > renaming an appropriately setup directory to the > "ref.lock" name. If the rename succeeds, the transaction > is begun. Any actor can abort the transaction (up until > it is committed) by simply deleting the "ref.lock" > directory, so it is not at risk of going stale. However, > once the actor who sets up the transaction commits it, > deleting the "ref.lock" directory simply aids in cleaning > it up for the next transaction (instead of aborting it). > > One important piece of the transaction is the use of > uuids. The uuids provide a mechanism to tie the atomic > commit pieces to the transactions and thus to prevent > long sleeping process from inadvertently performing > actions which could be out of date when they wake finally > up. In each case, the atomic commit piece is the > renaming of a file. For the create and update pieces, a > file is renamed from the "ref.lock" dir to the "ref" file > resulting in an update to the sha for the ref. However, > in the delete case, the "ref" file is instead renamed to > end up in the "ref.lock" directory resulting in a delete > of the ref. This scheme does not affect the way refs are > read today, > > To prepare for a transaction, an actor first generates a > uuid (an exercise I will delay for now). Next, a tmp > directory named after the uuid is generated in the parent > directory for the ref to be updated, perhaps something > like: ".lock_uuid". In this directory is places either a > file or a directory named after the uuid, something like: > ".lock_uuid/,uuid". In the case of a create or an > update, the new sha is written to this file. In the case > of a delete, it is a directory. > > Once the tmp directory is setup, the initiating actor > attempts to start the transaction by renaming the tmp > directory to "ref.lock". If the rename fails, the update > fails. If the rename succeeds, the actor can then attempt > to commit the transaction (before another actor aborts > it). > > In the case of a create, the actor verifies that "ref" > does not currently exist, and then renames the now named > "ref.lock/uuid" file to "ref". On success, the ref was > created. > > In the case of an update, the actor verifies that "ref" > currently contains the old sha, and then also renames the > now named "ref.lock/uuid" file to "ref". On success, the > ref was updated. > > In the case of a delete, the actor may verify that "ref" > currently contains the sha to "prune" if it needs to, and > then renames the "ref" file to "ref.lock/uuid/delete". On > success, the ref was deleted. > > Whether successful or not, the actor may now simply delete > the "ref.lock" directory, clearing the way for a new > transaction. Any other actor may delete this directory at > any time also, likely either on conflict (if they are > attempting to initiate a transaction), or after a grace > period just to cleanup the FS. Any actor may also safely > cleanup the tmp directories, preferably also after a grace > period. > > One neat part about this scheme is that I believe it would > be backwards compatible with the current locking > mechanism since the transaction directory will simply > appear to be a lock to older clients. And the old lock > file should continue to lock out these newer > transactions. > > Due to this backwards compatibility, I believe that this > could be incrementally employed today without affecting > very much. It could be deployed in place of any updates > which only hold ref.locks to update the loose ref. So > for example I think it could replace step 4a below from > Michael Haggerty's description of today's loose ref > pruning during > > ref packing: > > * Pack references: > ... > > > 4. prune_refs(): for each ref in the ref_to_prune list, > > > > call prune_ref(): > > a. Lock the reference using lock_ref_sha1(), > > verifying that the recorded SHA1 is still valid. If > > it is, unlink the loose reference file then free > > the lock; otherwise leave the loose reference file > > untouched
Re: [PATCH v3] git-clean: Display more accurate delete messages
> The updated code structure is much nicer than the previous round, > but I am somewhat puzzled how return value of remove_dirs() and > &gone relate to each other. Surely when gone is set to zero, > remove_dirs() is reporting that the directory it was asked to remove > recursively did not go away, so it must report failure, no? Having > the &gone flag looks redundant and checking for gone in some places > while checking for the return value for others feels like an > invitation for future bugs. The return value of remove_dirs() has an overall effect on the exit code of git-clean, and &gone indicates whether the directory we asked remove_dirs() to delete was actually removed. If all goes well in remove_dirs() the return code is 0 and gone flag is 1. If file or subdirectory delete fails return code is 1 and the gone flag is set to 0. The special case is when remove_dirs() is asked to remove an untracked git repo that should be ignored. In this case remove_dirs() is not going to remove the directory so the gone flag is set to zero but it is not an error so the return value will be set to zero too. > Also the remove_dirs() function seems to replace the use of > remove_dir_recurse() from dir.c by copying large part of it, with > error message sprinkled. Does remove_dir_recurse() still get used > by other codepaths? If so, do the remaining callsites benefit from > using this updated version? In dir.c the remove_dir_recurse() is a private function that is called by the public remove_dir_recursively() wrapper function. The remove_dir_recursively() function is called from the following places: builtin/clone.c:387: builtin/clone.c:392: builtin/rm.c:349: notes-merge.c:771: refs.c:1527: sequencer.c:27: transport.c:247: transport.c:393: The messages that remove_dirs() prints out are very specific to git-clean and they are not really relevant in the above places where remove_dir_recursively() is called from. Also, the remove logic for files is slightly different in remove_dirs() when it comes to handling a failed file delete. While remove_dirs() continues removing other files in the same directory upon failure, remove_dir_recurse() will stop at the first error. So perhaps having the remove_dirs() in builtin/clean.c is OK. -- 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: [BUG] two-way read-tree can write null sha1s into index
Jeff King writes: > Oh, I agree it's insane to try to carry through unmerged entries. I'm > just concerned that not all code paths are careful enough to check. I would actually be surprised if some code path do assume somebody might give them an index with conflicting entries in it and guard against it. We have been coding under the "index must exactly match the second tree when three-way unpack_trees() begin" requirement since day one. An conflicted entry will appear as "index and HEAD not matching" and will cause reject_merge() early in threeway_merge() anyway, no? -- 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 0/2] DEFAULT_DOC_TARGET
On Thu, Jan 03, 2013 at 02:20:31PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Not surprising for such a large refactoring, but this has conflicts with > > what's in next. Here's the patch to apply on top of the conflicted tree > > you get from merging this with "next": > > Yeah, verifying the manual fixup is a bit tricky indeed. The output from > > $ git blame -C HEAD^.. -- config.mak.uname | grep '^[^^]' > > shows only the first line of the resulting file, and the output from > > $ git blame --reverse -C HEAD^.. -- Makefile | grep '^^' > > shows only the three-line "Platform specific tweaks" comment, which > was replaced by your version in config.mak.uname, so nothing extra > was added and nothing important was lost between the two, it seems. Yeah, it's probably easier to do than verify. I knew that my patch was a straight copy/paste move of the big if/else block, replacing it with the include. So the obvious resolution is to mechanically move the "theirs" block from next in the same way. And then the resulting diff shows the fixup (which you can verify does not do anything fancy). It's really the same logic that merge-recursive uses for full-file renames, except that git is not smart enough to figure out that it was a 500-line block that moved, not the whole file. It comes up rarely enough that it is probably not worth trying to teach the merge machinery about code block movement. But it would be cool. :) -Peff -- 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 0/2] DEFAULT_DOC_TARGET
Jeff King writes: > Not surprising for such a large refactoring, but this has conflicts with > what's in next. Here's the patch to apply on top of the conflicted tree > you get from merging this with "next": Yeah, verifying the manual fixup is a bit tricky indeed. The output from $ git blame -C HEAD^.. -- config.mak.uname | grep '^[^^]' shows only the first line of the resulting file, and the output from $ git blame --reverse -C HEAD^.. -- Makefile | grep '^^' shows only the three-line "Platform specific tweaks" comment, which was replaced by your version in config.mak.uname, so nothing extra was added and nothing important was lost between the two, it seems. 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 v2 0/2] DEFAULT_DOC_TARGET
On Thu, Jan 03, 2013 at 04:05:41PM -0500, Jeff King wrote: > On Thu, Jan 03, 2013 at 03:32:22PM -0500, Jeff King wrote: > > > I think the usefulness is that it can be set by default for a particular > > uname, so people on Windows can just type "make install-doc" without > > having to care about setting anything (though to be honest, I do not > > even know what they build by default; maybe they do build manpages). > > Except that in the original thread: > > > > > > > > http://thread.gmane.org/gmane.comp.version-control.git/207193/focus=207201 > > > > it became clear that to do that we would also want to hoist the uname > > automagic defaults into their own file that could be read from > > Documentation/Makefile. > > IOW, this (on the current master), which I think is a nice cleanup > regardless of this series: > > -- >8 -- > Subject: [PATCH] Makefile: hoist uname autodetection to config.mak.uname Not surprising for such a large refactoring, but this has conflicts with what's in next. Here's the patch to apply on top of the conflicted tree you get from merging this with "next": diff --cc Makefile index 5e4ee47,f37fb24..000 --- a/Makefile +++ b/Makefile diff --git a/config.mak.uname b/config.mak.uname index f9de18e..bea34f0 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -425,6 +425,7 @@ ifeq ($(uname_S),NONSTOP_KERNEL) # Added manually, see above. NEEDS_SSL_WITH_CURL = YesPlease HAVE_LIBCHARSET_H = YesPlease + HAVE_STRINGS_H = YesPlease NEEDS_LIBICONV = YesPlease NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease NO_SYS_SELECT_H = UnfortunatelyYes @@ -520,3 +521,19 @@ endif NO_CURL = YesPlease endif endif +ifeq ($(uname_S),QNX) + COMPAT_CFLAGS += -DSA_RESTART=0 + HAVE_STRINGS_H = YesPlease + NEEDS_SOCKET = YesPlease + NO_FNMATCH_CASEFOLD = YesPlease + NO_GETPAGESIZE = YesPlease + NO_ICONV = YesPlease + NO_MEMMEM = YesPlease + NO_MKDTEMP = YesPlease + NO_MKSTEMPS = YesPlease + NO_NSEC = YesPlease + NO_PTHREADS = YesPlease + NO_R_TO_GCC_LINKER = YesPlease + NO_STRCASESTR = YesPlease + NO_STRLCPY = YesPlease +endif -- 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 0/2] DEFAULT_DOC_TARGET
On Thu, Jan 03, 2013 at 03:32:22PM -0500, Jeff King wrote: > I think the usefulness is that it can be set by default for a particular > uname, so people on Windows can just type "make install-doc" without > having to care about setting anything (though to be honest, I do not > even know what they build by default; maybe they do build manpages). > Except that in the original thread: > > > http://thread.gmane.org/gmane.comp.version-control.git/207193/focus=207201 > > it became clear that to do that we would also want to hoist the uname > automagic defaults into their own file that could be read from > Documentation/Makefile. IOW, this (on the current master), which I think is a nice cleanup regardless of this series: -- >8 -- Subject: [PATCH] Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King --- I'm happy to call it "config.mak.autodetect" if you prefer. My rationale was that we might eventually have several levels of autodetection, and we would want to be able to order them individually (in fact, we already do; config.mak.autogen is another form that should take precedence over uname detection, and it is already split out). Makefile | 526 +-- config.mak.uname | 522 ++ 2 files changed, 523 insertions(+), 525 deletions(-) create mode 100644 config.mak.uname diff --git a/Makefile b/Makefile index 736ecd4..5e4ee47 100644 --- a/Makefile +++ b/Makefile @@ -326,19 +326,6 @@ GIT-VERSION-FILE: FORCE @$(SHELL_PATH) ./GIT-VERSION-GEN -include GIT-VERSION-FILE -uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not') -uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not') -uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not') -uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not') -uname_P := $(shell sh -c 'uname -p 2>/dev/null || echo not') -uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not') - -ifdef MSVC - # avoid the MingW and Cygwin configuration sections - uname_S := Windows - uname_O := Windows -endif - # CFLAGS and LDFLAGS are for the users to override from the command line. CFLAGS = -g -O2 -Wall @@ -937,518 +924,7 @@ GIT_USER_AGENT = git/$(GIT_VERSION) GIT_USER_AGENT = git/$(GIT_VERSION) -# -# Platform specific tweaks -# - -# We choose to avoid "if .. else if .. else .. endif endif" -# because maintaining the nesting to match is a pain. If -# we had "elif" things would have been much nicer... - -ifeq ($(uname_M),x86_64) - XDL_FAST_HASH = YesPlease -endif -ifeq ($(uname_S),OSF1) - # Need this for u_short definitions et al - BASIC_CFLAGS += -D_OSF_SOURCE - SOCKLEN_T = int - NO_STRTOULL = YesPlease - NO_NSEC = YesPlease -endif -ifeq ($(uname_S),Linux) - NO_STRLCPY = YesPlease - NO_MKSTEMPS = YesPlease - HAVE_PATHS_H = YesPlease - LIBC_CONTAINS_LIBINTL = YesPlease - HAVE_DEV_TTY = YesPlease -endif -ifeq ($(uname_S),GNU/kFreeBSD) - NO_STRLCPY = YesPlease - NO_MKSTEMPS = YesPlease - HAVE_PATHS_H = YesPlease - DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease - LIBC_CONTAINS_LIBINTL = YesPlease -endif -ifeq ($(uname_S),UnixWare) - CC = cc - NEEDS_SOCKET = YesPlease - NEEDS_NSL = YesPlease - NEEDS_SSL_WITH_CRYPTO = YesPlease - NEEDS_LIBICONV = YesPlease - SHELL_PATH = /usr/local/bin/bash - NO_IPV6 = YesPlease - NO_HSTRERROR = YesPlease - NO_MKSTEMPS = YesPlease - BASIC_CFLAGS += -Kthread - BASIC_CFLAGS += -I/usr/local/include - BASIC_LDFLAGS += -L/usr/local/lib - INSTALL = ginstall - TAR = gtar - NO_STRCASESTR = YesPlease - NO_MEMMEM = YesPlease -endif -ifeq ($(uname_S),SCO_SV) - ifeq ($(uname_R),3.2) - CFLAGS = -O2 - endif - ifeq
Suggested improvements to the git-p4 documentation (branch-related)
Hi,
While struggling to get git-p4 to work properly with branches, I
thought the documentation on http://git-scm.com/docs/git-p4 could use
some improvements:
1. At the end of the "Branch detection" section, the following
commands are provided (for when you want to explicitly provide branch
mappings to git-p4):
git config git-p4.branchList main:branch1
git p4 clone --detect-branches //depot@all
The second command should end with a dot (".") because the first
command only works if you are already in a git-initialized folder.
Thus I would also suggest to add "git init" as first command to type.
2. Even though having a "main" branch is standard in Perforce, it
would be worth mentioning what happens when you don't: there is a
message "Could not detect main branch. No checkout/master branch
created" output by the "git p4 clone" command. However, it will still
work if you manually set the master branch ("git checkout -b master
remotes/p4/my_custom_main_branch").
3. I don't know what I missed for that one, but I haven't been able to
get the example for the --branch option to work. It says that after
"git init", we can import a p4 branch with:
git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2
However, after doing this, followed by "git checkout -b proj2
remotes/p4/proj2", I am unable to properly use "git p4 sync" or "git
p4 submit" from this branch, as git complains about a missing
refs/remotes/p4/master.
Maybe it only works if "git clone" has been used before? But then why
have "git init" first?
NB: it's quite possible some of my problems were caused by me not
properly understanding the doc / how git/p4 works. My apologies if
that's the case.
-=- Olivier
--
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: cvsps, parsecvs, svn2git and the CVS exporter mess
Michael Haggerty : > There are two good reasons that the output is written to two separate files: Those are good reasons to write to a pair of tempfiles, and I was able to deduce in advance most of what your explanation would be from the bare fact that you did it that way. They are *not* good reasons for having an interface that exposes this implementation detail to the caller - that choice I consider a failure of interface-design judgment. But I know how to fix this in a simple and backward-compatible way, and will do so when I have time to write you a patch. Next week or the week after, most likely. Also, the cvs2git manual page is still rather half-baked and careless, with several fossil references to cvs2svn that shouldn't be there and obviously incomplete feature coverage. Fixing these bugs is also on my to-do list for sometime this month. I'd be willing to put in this work anyway, but it still in the back of my mind that if cvs2git wins the test-suite competition I might officially end-of-life both cvsps and parsecvs. One of the features of the new git-cvsimport is direct support for using cvs2git as a conversion engine. > A potentially bigger problem is that if you want to handle such > blob/dump output, you have to deal with git-fast-import format's "blob" > command as opposed to only handling inline blobs. Not a problem. All of the main potential consumers for this output, including reposurgeon, handle the blob command just fine. > cvs2git does not currently support incremental conversions; therefore, a > cvsps-based option (if it would actually work, that is) would have at > least one advantage over cvs2git. Yes. The reason I didn't ship the replacement patch Junio was expecting yesterday is that I don't have test coverage for the incremental case. I'm working on that now. > cvs2svn has an extensive test suite which includes tests derived from > bug reports that we have received over the years. I adapted a few of > its test repositories to create the git test suite additions that I made > in Feb 2009, but there are many more in our project. I've merged those into my tree. > I think it would be great to have a way to test across tools, though > please realize that the inference of the most plausible "true" CVS > history is partly objective but also often a matter of heuristics and > taste. Moreover, the choice of how to represent the inferred history in > git, which has rather a different model than CVS/Subversion, is also > non-obvious and somewhat controversial. I expect that there will be a > number of simple CVS repositories for which we can all agree about the > correct git output, but not far away will be a vast number for which the > "correct" answer is unclear. Many of the interesting tests would fall > into the latter category. I'm aware of the problem. One of the interesting questions is how much further into the weird cases everybody can agree on what correct translation looks like. We won't know until we push it. > It's not clear what you want me to sign off on. If you're not willing to use the new suite, my spending the effort required to genericize it gets much less interesting. I needed Junio's agreement because I wanted to move the old git-cvsimport tests from the git tree to the new test suite; they're not really tests of the wrapper script at all but of the conversion engines. > I guess you want to > replace (or augment?) the cvs2svn test suite with one based on your > framework? Augment, not replace - and just as importantly, commit to writing new tests into the new generic framework when they don't involve a tool-specific option. It would be silly and duplicative for us *not* to be sharing as many tests as we can. > * We definitely want to continue testing the Subversion output of > cvs2svn. A test suite that only tests the git output could at best be > an addition to the current test suite, not a replacement for it. (That > being said, the addition of good tests of the 2git output would be great.) Agreed. > * A test suite that tests only the easy cases wouldn't really be > interesting, because the difficult cases are where the potential > problems lie. Yes, I know. I'm arguing that we should be doing that exploration jointly rather than separately. > * It would be unfortunate if the cvs2svn test suite would grow another > run-time dependency or if we would have to invest a lot of time > synchronizing with another project, though if the gain were big enough > we could consider it. I know how to keep the friction cost low. You'll see more about this when I split off the test suite and announce it. > * The licenses obviously have to be compatible to the extent required by > the level of coupling. I don't think this will be a problem. You own the copyright on your tests and I own it on mine, so we can relicense under whatever common license we choose. I'm not fussy about what we use; AS
Re: git filter-branch doesn't dereference annotated tags
On Thu, Jan 3, 2013 at 2:33 AM, Johannes Sixt wrote: > Am 03.01.2013 10:50, schrieb Grégory Pakosz: >>> >>> IOW, if the command was something like >>> >>> git filter-branch ...filter options... -- v1.0 master ... >>> >>> and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be >>> deleted if the commit it points to goes away. But if the commit did not >>> go away, but was rewritten, then it is equally reasonable to expect that >>> the tag is also rewritten. But I don't think that we currently do the >>> latter. >>> >> When the commit doesn't go away, the tag is currently being rewritten >> properly. > > Indeed, but only if a --tag-name-filter was specified. > >>> Therefore, IMO, a change that implements the former behavior should also >>> implement the latter behavior. >>> >> The patch in my latest email does both. (yet lacks unit tests for now) > > If it deletes a tag only when --tag-name-filter was specified, than that > should be fine. Hmm, if a tag name filter _other_ than 'cat' is supplied, I think a user will expect that the original tags will _not_ be touched, and especially not deleted. Rather than blindly deleting the original tag ref, maybe we should still call the user's tag name filter, and then attempt to delete the "new" name provided by the filter, if it exists. If the filter was 'cat', then the new and old names will be the same. -Brandon -- 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 v2] Documentation: update "howto maintain git"
The flow described in the document is still correct, but over time I have automated various parts of the workflow with tools and their use was not explained at all. Update it and outline the use of two key scripts from the 'todo' branch, "Reintegrate" and "cook". Signed-off-by: Junio C Hamano --- * I sent an incomplete preview some time ago; this is an update. The old one is at: http://thread.gmane.org/gmane.comp.version-control.git/210632 Antoine Cc'ed because this is a more detailed answer to his question in: http://thread.gmane.org/gmane.comp.version-control.git/212127/focus=212333 Documentation/howto/maintain-git.txt | 314 +-- 1 file changed, 225 insertions(+), 89 deletions(-) diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt index 8823a37..a4ec3cb 100644 --- a/Documentation/howto/maintain-git.txt +++ b/Documentation/howto/maintain-git.txt @@ -8,20 +8,20 @@ Abstract: Imagine that git development is racing along as usual, when our friend The maintainer's git time is spent on three activities. - - Communication (60%) + - Communication (45%) Mailing list discussions on general design, fielding user questions, diagnosing bug reports; reviewing, commenting on, suggesting alternatives to, and rejecting patches. - - Integration (30%) + - Integration (50%) Applying new patches from the contributors while spotting and correcting minor mistakes, shuffling the integration and testing branches, pushing the results out, cutting the releases, and making announcements. - - Own development (10%) + - Own development (5%) Scratching my own itch and sending proposed patch series out. @@ -35,6 +35,9 @@ The policy. contain bugfixes and enhancements in any area, including functionality, performance and usability, without regression. + - One release cycle for a feature release is expected to last for + eight to ten weeks. + - Maintenance releases are numbered as vX.Y.Z.W and are meant to contain only bugfixes for the corresponding vX.Y.Z feature release and earlier maintenance releases vX.Y.Z.V (V < W). @@ -58,12 +61,15 @@ The policy. - 'pu' branch is used to publish other proposed changes that do not yet pass the criteria set for 'next'. - - The tips of 'master', 'maint' and 'next' branches will always - fast-forward, to allow people to build their own - customization on top of them. + - The tips of 'master' and 'maint' branches will not be rewound to + allow people to build their own customization on top of them. + Early in a new development cycle, 'next' is rewound to the tip of + 'master' once, but otherwise it will not be rewound until the end + of the cycle. - - Usually 'master' contains all of 'maint', 'next' contains all - of 'master' and 'pu' contains all of 'next'. + - Usually 'master' contains all of 'maint' and 'next' contains all + of 'master'. 'pu' contains all the topics merged to 'next', but + is rebuilt directly on 'master'. - The tip of 'master' is meant to be more stable than any tagged releases, and the users are encouraged to follow it. @@ -76,11 +82,16 @@ The policy. A typical git day for the maintainer implements the above policy by doing the following: - - Scan mailing list and #git channel log. Respond with review - comments, suggestions etc. Kibitz. Collect potentially - usable patches from the mailing list. Patches about a single - topic go to one mailbox (I read my mail in Gnus, and type - \C-o to save/append messages in files in mbox format). + - Scan mailing list. Respond with review comments, suggestions + etc. Kibitz. Collect potentially usable patches from the + mailing list. Patches about a single topic go to one mailbox (I + read my mail in Gnus, and type \C-o to save/append messages in + files in mbox format). + + - Write his own patches to address issues raised on the list but + nobody has stepped up solving. Send it out just like other + contributors do, and pick them up just like patches from other + contributors (see above). - Review the patches in the saved mailboxes. Edit proposed log message for typofixes and clarifications, and add Acks @@ -96,40 +107,32 @@ by doing the following: - Obviously correct fixes that pertain to the tip of 'master' are directly applied to 'master'. + - Other topics are not handled in this step. + This step is done with "git am". $ git checkout master;# or "git checkout maint" - $ git am -3 -s mailbox + $ git am -sc3 mailbox $ make test - - Merge downwards (maint->master): - - $ git checkout master - $ git merge maint - $ make test + In practice, almost no patch directly goes to 'master' or + 'maint'. - Review the last issue of "What's cooking" message, review the - topics scheduled for merging upwards (topic->master and - topic->maint), a
Re: [PATCH v2 0/2] DEFAULT_DOC_TARGET
On Thu, Jan 03, 2013 at 03:32:22PM -0500, Jeff King wrote: > On Thu, Jan 03, 2013 at 11:05:18AM -0800, Junio C Hamano wrote: > > > This allows things like: > > > > $ DEFAULT_DOC_TARGET=html make doc > > $ DEFAULT_DOC_INSTALL_TARGET=html make install-doc > > > > on a platform that does not have manpage viewer. Which is not very > > useful, given that you can already say > > > > $ make install-html > > > > on such a platform, and these install-$format targets will not go > > away. > > I think the usefulness is that it can be set by default for a particular > uname, so people on Windows can just type "make install-doc" without > having to care about setting anything (though to be honest, I do not > even know what they build by default; maybe they do build manpages). I also notice that we have DEFAULT_HELP_FORMAT (which is "html" on Windows). Wouldn't that be a sane default for DEFAULT_DOC_TARGET if it is set? I guess we can set all three independently for maximum flexibility, though, but it seems like a sane fallback. -Peff -- 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: [BUG] two-way read-tree can write null sha1s into index
On Thu, Jan 03, 2013 at 12:34:27PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Or are you suggesting that the three-way case should always be protected > > by checking that there are no unmerged entries before we start it? That > > seems sane to me, but I haven't confirmed that that is the case. > > I think the normal (and hopefully only) "-m -u O A B" use case of > threeway is the bog-standard "git merge", which requires even more: > your index must exactly match HEAD, even though you are allowed to > have local changes in the working tree. > > That requirement is not likely to change, as cleanly merged paths > are automatically added to the index, so "diff --cached" should show > only the changes from cleanly merged part, while "diff" should show > paths that still needs user's help. > > If we allowed local modification to the index (let alone conflicted > entries in it) before the merge begins, the users would not be able > to tell which paths are in what state after a half-merge stops and > asks for help. Updated paths may not have anything to do with the > merge (i.e. earlier "git add" before the merge started), conflicting > paths may not have anything to do with the merge (i.e. leftover > conflicts before the merge started). Oh, I agree it's insane to try to carry through unmerged entries. I'm just concerned that not all code paths are careful enough to check. They probably are, though, as a null sha1 in your index would be the least of your worries, and somebody would have noticed in the last 7 years. -Peff -- 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: [BUG] two-way read-tree can write null sha1s into index
Jeff King writes: > Or are you suggesting that the three-way case should always be protected > by checking that there are no unmerged entries before we start it? That > seems sane to me, but I haven't confirmed that that is the case. I think the normal (and hopefully only) "-m -u O A B" use case of threeway is the bog-standard "git merge", which requires even more: your index must exactly match HEAD, even though you are allowed to have local changes in the working tree. That requirement is not likely to change, as cleanly merged paths are automatically added to the index, so "diff --cached" should show only the changes from cleanly merged part, while "diff" should show paths that still needs user's help. If we allowed local modification to the index (let alone conflicted entries in it) before the merge begins, the users would not be able to tell which paths are in what state after a half-merge stops and asks for help. Updated paths may not have anything to do with the merge (i.e. earlier "git add" before the merge started), conflicting paths may not have anything to do with the merge (i.e. leftover conflicts before the merge started). -- 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 0/2] DEFAULT_DOC_TARGET
On Thu, Jan 03, 2013 at 11:05:18AM -0800, Junio C Hamano wrote: > This allows things like: > > $ DEFAULT_DOC_TARGET=html make doc > $ DEFAULT_DOC_INSTALL_TARGET=html make install-doc > > on a platform that does not have manpage viewer. Which is not very > useful, given that you can already say > > $ make install-html > > on such a platform, and these install-$format targets will not go > away. I think the usefulness is that it can be set by default for a particular uname, so people on Windows can just type "make install-doc" without having to care about setting anything (though to be honest, I do not even know what they build by default; maybe they do build manpages). Except that in the original thread: > http://thread.gmane.org/gmane.comp.version-control.git/207193/focus=207201 it became clear that to do that we would also want to hoist the uname automagic defaults into their own file that could be read from Documentation/Makefile. > The real motivation behind this was to let me say: > > $ git checkout $some_old_fork_point > $ DEFAULT_DOC_TARGET=git-push.1 make doc > > while updating the sources to the documentation for the maintainance > track, without having to format everything else that is different > between the old fork point and the primary branch I usually work on. I still don't see how this is any advantage over: make -C Documentation git-push.1 > The first one was discussed some time ago on the list and all the > fixes mentioned on the thread already squashed in. The second one > is merely for completeness. I wonder...do we really need DEFAULT_DOC_INSTALL_TARGET? Why isn't it the same as DEFAULT_DOC_TARGET? I realize that right now we build html and manpages by default, but only install man. But then why do we bother building html then? -Peff -- 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: [BUG] two-way read-tree can write null sha1s into index
On Thu, Jan 03, 2013 at 07:34:53AM -0800, Junio C Hamano wrote:
> > Good point; I was just thinking about the --reset case.
> >
> > With "-m", though, we could in theory carry over the unmerged entries
> > (again, assuming that "old" and "new" are the same; otherwise it is an
> > obvious reject). But those entries would be confused with any new
> > unmerged entries we create. It seems we already protect against this,
> > though: "read-tree -m" will not run at all if you have unmerged entries.
> >
> > Likewise, "checkout" seems to have similar protections.
> >
> > So I think it may be a non-issue.
>
> Yeah. Also earlier in the thread you mentioned three-way case, but
> I do not think we ever would want --reset with three trees, so I
> think that too is a non-issue for the same reason.
Yeah, agreed; we should always reject in the three-way case. I would
worry more that it has a bug where something is _not_ rejected, and we
end up putting a bogus null sha1 entry into the index (which is the
actual problem with twoway_merge). IOW, if we have the bogus sha1 in the
index (because we marked it with CE_CONFLICTED), and the two sides and
the common ancestor are all the same, would we blindly carry through the
bogus conflicted entry (which we would prefer, because it has the
up-to-date stat information)?
Or are you suggesting that the three-way case should always be protected
by checking that there are no unmerged entries before we start it? That
seems sane to me, but I haven't confirmed that that is the case.
> I would still feel safer if we expressed the expectation of
> the callee in the code, perhaps like this in the two-way case:
>
> if (current->ce_flags & CE_CONFLICTED) {
> if (!o->reset) {
> ... either die or fail ...
> } else {
> ... your fix ...
> }
> }
Agreed. I looked at that, but it seemed like it was going to involve
repeating a lot of the "are the two trees the same" logic. Let me see if
I can refactor it to avoid that.
-Peff
--
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: [RFH] NetBSD 6?
On 01/03/2013 07:27 PM, Greg Troxel wrote: > > Junio C Hamano writes: > >> I forgot to mention that we also ship configure (and keep track of >> configure.ac) so that optionally people can let autoconf machinery >> to create config.mak.autogen to be included at the same place as >> handcrafted config.mak in their build process. I do not offhand >> know if we do "for p in python python2.6 python2.7; do ..." kind of >> thing, though. > > pkgsrc uses the configure method, but it seems not to output a > PYTHON_PATH. It looks like automake's python.m4 is not used by git's > configure.ac. > That is not surprising, since Git build system doesn't use Automake :-) In addition, it's worth nothing that Automake's python support (both in its m4 and make components) is intended as an help to install python *modules* from Autotools-based packages; using it for mere stand-alone scripts would be overkill. In the case of Git, an adapted version of something like this might be enough: AC_CHECK_PROGS([PYTHON], [python python2.7 python2.6 python2.5]) if test -z "$PYTHON"; then AC_MSG_WARNING([python not found]) fi $PYTHON -c 'check-not-py3k' || AC_MSG_WARNING([Python 3 is not supported]) $PYTHON -c 'check-its-version' || AC_MSG_WARNING([python is too old]) (Automake itself uses, in its own build system, a similar idiom to look for a Perl interpreter at configure runtime). Not my itch so far, but I will happily review a patch if anyone is willing to write it. > But pkgsrc passes PYTHON_PATH in the environment to make, > so it works out currently. > >> It refers to the type of the second parameter to iconv(); OLD_ICONV >> makes it take "const char *", as opposed to "char *", the latter of >> which matches >> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html > > Thanks - I now see our extra const and am looking into it. Regards, Stefano -- 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
What's cooking in git.git (Jan 2013, #02; Thu, 3)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The post 1.8.1 cycle has started, and about a dozen topics (mostly
fixes) have graduated to the 'master' branch. The second batch will
follow shortly.
As usual, this cycle is expected to last for 8 to 10 weeks. To
ensure the quality of the end result, let's merge topics in flight
earlier than previous cycles to 'next' and fix issues in-tree.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[New Topics]
* jn/less-reconfigure (2013-01-02) 1 commit
(merged to 'next' on 2013-01-02 at e5cd6cf)
+ build: do not automatically reconfigure unless configure.ac changed
When autoconf is used, any build on a different commit always ran
"config.status --recheck" even when unnecessary.
* ap/merge-stop-at-prepare-commit-msg-failure (2013-01-03) 1 commit
- merge: Honor prepare-commit-msg return code
"git merge" started calling prepare-commit-msg hook like "git
commit" does some time ago, but forgot to pay attention to the exit
status of the hook. t7505 may want a general clean-up but that is
a different topic.
Will merge to 'next'.
* tb/test-shell-lint (2013-01-02) 1 commit
- test: Add check-non-portable-shell.pl
Check for common mistakes in the test scripts, based on simple
pattern-matching.
Will merge to 'next'.
* jk/enable-test-lint-by-default (2013-01-03) 1 commit
- tests: turn on test-lint by default
We had two simple and quick tests to catch common mistakes when
writing test scripts, but they weren't run by default when running
tests.
Will merge to 'next'.
--
[Graduated to "master"]
* as/test-tweaks (2012-12-20) 7 commits
(merged to 'next' on 2012-12-22 at 7312c6c)
+ tests: paint unexpectedly fixed known breakages in bold red
+ tests: test the test framework more thoroughly
+ tests: refactor mechanics of testing in a sub test-lib
+ tests: change info messages from yellow/brown to cyan
+ tests: paint skipped tests in blue
+ tests: paint known breakages in yellow
+ tests: test number comes first in 'not ok $count - $message'
Output from the tests is coloured using "green is okay, yellow is
questionable, red is bad and blue is informative" scheme.
* da/p4merge-mktemp (2012-12-26) 1 commit
(merged to 'next' on 2012-12-26 at 036938a)
+ mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder
Create an empty file in $TMPDIR instead of using an empty file in
the local directory.
* dm/port (2012-12-19) 4 commits
(merged to 'next' on 2012-12-22 at 8adc198)
+ git-compat-util.h: do not #include by default
+ Generalize the inclusion of strings.h
+ Detect when the passwd struct is missing pw_gecos
+ Support builds when sys/param.h is missing
(this branch is used by mk/qnx.)
Add a few more knobs for new platform ports can tweak.
* jc/maint-fbsd-sh-ifs-workaround (2012-12-10) 1 commit
(merged to 'next' on 2012-12-11 at 6659fdc)
+ sh-setup: work around "unset IFS" bug in some shells
Some shells do not behave correctly when IFS is unset; work it
around by explicitly setting it to the default value.
* jc/maint-fnmatch-old-style-definition (2012-12-19) 1 commit
(merged to 'next' on 2012-12-22 at 540df2c)
+ compat/fnmatch: update old-style definition to ANSI
Update old-style function definition "int foo(bar) int bar; {}"
to "int foo(int bar) {}".
* jc/maint-test-portability (2012-12-19) 3 commits
(merged to 'next' on 2012-12-22 at daeed53)
+ t4014: fix arguments to grep
+ t9502: do not assume GNU tar
+ t0200: "locale" may not exist
(this branch is used by jc/test-portability.)
Minor test fixes noticed while running our tests on OpenBSD 5.2,
applicable to 'maint'.
* jc/mkstemp-more-careful-error-reporting (2012-12-18) 1 commit
(merged to 'next' on 2012-12-22 at 18cdaf0)
+ xmkstemp(): avoid showing truncated template more carefully
After failing to create a temporary file using mkstemp(), failing
pathname was not reported correctly on some platforms.
* jc/same-encoding (2012-12-10) 1 commit
(merged to 'next' on 2012-12-17 at 86b41c7)
+ format_commit_message(): simplify calls to logmsg_reencode()
Finishing touches to the series to unify "Do we need to reencode
between these two encodings?" logic.
* jc/test-cvs-no-init-in-existing-dir (2012-12-24) 1 commit
(merged to 'next' on 2012-12-26 at 3b93f37)
+ t9200: let "cvs init" create the test repository
t9200 runs "cvs init" on a directory that already exists, but a
platform can configure this fail for the current user (e.g. you
need to be in the cvsadmin group on NetBSD 6.0).
* jc/test-portability (2012-12-19) 3 commits
(merged to 'next' on 2012-12-22 at 123041b)
+ t9020: use configured Python to
[PATCH v2 2/2] Allow installing a non-default set of documentation
In a fashion similar to the previous DEFAULT_DOC_TARGET patch, teach the build procedure to allow installing the documentation sets specified via DEFAULT_DOC_INSTALL_TARGET. These two symbols must be separate, as we should allow formatting more than what will be installed. The default has been to format both html and manpages, and to install only the latter. $ make DEFAULT_DOC_INSTALL_TARGET='html man' install-doc will format and install both html and manpages. Signed-off-by: Junio C Hamano --- Documentation/Makefile | 3 ++- Makefile | 5 - 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 0f8fdf8..bd7800d 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -69,6 +69,7 @@ endif -include ../config.mak DEFAULT_DOC_TARGET ?= html man +DEFAULT_DOC_INSTALL_TARGET ?= $(DEFAULT_DOC_TARGET) # # For docbook-xsl ... @@ -171,7 +172,7 @@ info: git.info gitman.info pdf: user-manual.pdf -install: install-man +install: $(patsubst %,install-%,$(DEFAULT_DOC_INSTALL_TARGET)) install-man: man $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir) diff --git a/Makefile b/Makefile index 71655a7..422a15f 100644 --- a/Makefile +++ b/Makefile @@ -287,6 +287,8 @@ all:: # DEFAULT_DOC_TARGET='man html info pdf' # DEFAULT_DOC_TARGET='html' # +# DEFAULT_DOC_INSTALL_TARGET can be used in a similar way. +# # Define COMPUTE_HEADER_DEPENDENCIES to "yes" if you want dependencies on # header files to be automatically computed, to avoid rebuilding objects when # an unrelated header file changes. Define it to "no" to use the hard-coded @@ -1428,6 +1430,7 @@ ifneq (,$(SOCKLEN_T)) endif DEFAULT_DOC_TARGET ?= html man +DEFAULT_DOC_INSTALL_TARGET ?= man ifeq ($(uname_S),Darwin) ifndef NO_FINK @@ -2379,7 +2382,7 @@ $(XDIFF_LIB): $(XDIFF_OBJS) $(VCSSVN_LIB): $(VCSSVN_OBJS) $(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(VCSSVN_OBJS) -export DEFAULT_EDITOR DEFAULT_PAGER DEFAULT_DOC_TARGET +export DEFAULT_EDITOR DEFAULT_PAGER DEFAULT_DOC_TARGET DEFAULT_DOC_INSTALL_TARGET doc: $(MAKE) -C Documentation all -- 1.8.1.293.g4a210a9 -- 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 v2 1/2] Allow generating a non-default set of documentation
By default, "make doc" generates the manpages and htmldocs in the Documentation directory, but you may want to change this depending on the target environment, e.g. to include 'pdf'. Introduce a new Makefile variable DEFAULT_DOC_TARGET to allow customizing this. The primary motivation is to let us check documentation patches with $ DEFAULT_DOC_TARGET=git-push.1 make doc but it is not so far-fetched to imagine that Windows users may want to omit manpages with $ DEFAULT_DOC_TARGET=html make doc or somesuch. It won't be useful without additional support to tweak the format installed by default via DEFAULT_DOC_INSTALL_TARGET, though. Signed-off-by: Junio C Hamano --- Documentation/Makefile | 7 ++- Makefile | 10 +- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 063fa69..0f8fdf8 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -1,3 +1,6 @@ +# The default target of this Makefile is... +all:: + MAN1_TXT= \ $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ $(wildcard git-*.txt)) \ @@ -65,6 +68,8 @@ endif -include ../config.mak.autogen -include ../config.mak +DEFAULT_DOC_TARGET ?= html man + # # For docbook-xsl ... # -1.68.1,no extra settings are needed? @@ -151,7 +156,7 @@ ifndef V endif endif -all: html man +all:: $(DEFAULT_DOC_TARGET) html: $(DOC_HTML) diff --git a/Makefile b/Makefile index 6b0c961..71655a7 100644 --- a/Makefile +++ b/Makefile @@ -281,6 +281,12 @@ all:: # DEFAULT_EDITOR='$GIT_FALLBACK_EDITOR', # DEFAULT_EDITOR='"C:\Program Files\Vim\gvim.exe" --nofork' # +# You can define DEFAULT_DOC_TARGET to change it from the built-in +# default of generating manpages and htmldocs. e.g. +# +# DEFAULT_DOC_TARGET='man html info pdf' +# DEFAULT_DOC_TARGET='html' +# # Define COMPUTE_HEADER_DEPENDENCIES to "yes" if you want dependencies on # header files to be automatically computed, to avoid rebuilding objects when # an unrelated header file changes. Define it to "no" to use the hard-coded @@ -1421,6 +1427,8 @@ ifneq (,$(SOCKLEN_T)) BASIC_CFLAGS += -Dsocklen_t=$(SOCKLEN_T) endif +DEFAULT_DOC_TARGET ?= html man + ifeq ($(uname_S),Darwin) ifndef NO_FINK ifeq ($(shell test -d /sw/lib && echo y),y) @@ -2371,7 +2379,7 @@ $(XDIFF_LIB): $(XDIFF_OBJS) $(VCSSVN_LIB): $(VCSSVN_OBJS) $(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(VCSSVN_OBJS) -export DEFAULT_EDITOR DEFAULT_PAGER +export DEFAULT_EDITOR DEFAULT_PAGER DEFAULT_DOC_TARGET doc: $(MAKE) -C Documentation all -- 1.8.1.293.g4a210a9 -- 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 v2 0/2] DEFAULT_DOC_TARGET
This allows things like: $ DEFAULT_DOC_TARGET=html make doc $ DEFAULT_DOC_INSTALL_TARGET=html make install-doc on a platform that does not have manpage viewer. Which is not very useful, given that you can already say $ make install-html on such a platform, and these install-$format targets will not go away. The real motivation behind this was to let me say: $ git checkout $some_old_fork_point $ DEFAULT_DOC_TARGET=git-push.1 make doc while updating the sources to the documentation for the maintainance track, without having to format everything else that is different between the old fork point and the primary branch I usually work on. The first one was discussed some time ago on the list and all the fixes mentioned on the thread already squashed in. The second one is merely for completeness. For previous round, see: http://thread.gmane.org/gmane.comp.version-control.git/207193/focus=207201 Junio C Hamano (2): Allow generating a non-default set of documentation Allow installing a non-default set of documentation Documentation/Makefile | 10 -- Makefile | 13 - 2 files changed, 20 insertions(+), 3 deletions(-) -- 1.8.1.293.g4a210a9 -- 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: [RFH] NetBSD 6?
Junio C Hamano writes: > I forgot to mention that we also ship configure (and keep track of > configure.ac) so that optionally people can let autoconf machinery > to create config.mak.autogen to be included at the same place as > handcrafted config.mak in their build process. I do not offhand > know if we do "for p in python python2.6 python2.7; do ..." kind of > thing, though. pkgsrc uses the configure method, but it seems not to output a PYTHON_PATH. It looks like automake's python.m4 is not used by git's configure.ac. But pkgsrc passes PYTHON_PATH in the environment to make, so it works out currently. > It refers to the type of the second parameter to iconv(); OLD_ICONV > makes it take "const char *", as opposed to "char *", the latter of > which matches > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html Thanks - I now see our extra const and am looking into it. pgpgVxwiC7ZH_.pgp Description: PGP signature
Re: [PATCH] merge: Honor prepare-commit-msg return code
> Oh, that wasn't meant as a complaint. I am tempted to rewrite the
> log message like so, though:
>
> 65969d4 (merge: honor prepare-commit-msg hook, 2011-02-14) tried to
> make "git commit" and "git merge" consistent, because a merge that
> required user assistance has to be concluded with "git commit", but
> only "git commit" triggered prepare-commit-msg hook. When it added
> a call to run the prepare-commit-msg hook, however, it forgot to
> check the exit code from the hook like "git commit" does, and ended
> up replacing one inconsistency with another.
That's fine with me
>>> diff --git a/t/t7505-prepare-commit-msg-hook.sh
>>> b/t/t7505-prepare-commit-msg-hook.sh
>>> index bc497bc..3573751 100755
>>> --- a/t/t7505-prepare-commit-msg-hook.sh
>>> +++ b/t/t7505-prepare-commit-msg-hook.sh
>>> @@ -172,11 +172,12 @@ test_expect_success 'with failing hook (merge)' '
>>> git checkout -B other HEAD@{1} &&
>>> echo "more" >> file &&
>>> git add file &&
>>> - chmod -x $HOOK &&
>>> + rm -f "$HOOK" &&
>>> git commit -m other &&
>>> - chmod +x $HOOK &&
>>> + write_script "$HOOK" <<-EOF
>>> + exit 1
>>> + EOF
>>> git checkout - &&
>>> - head=`git rev-parse HEAD` &&
>>> test_must_fail git merge other
>>>
>>> '
>>
>> What about moving the hook file then ? Not very important to me, just
>> a suggestion as it would keep the shebang.
>
> Strictly speaking, the way $HOOK is prepared in the original is
> wrong. The script is always run under "#!/bin/sh" instead of the
> shell the user told us to use with $SHELL_PATH. For a simple one
> liner that only exits with 1, it does not matter, though.
>
> Many test scripts got this wrong and that was the reason we later
> added write_script helper function to the test suite.
So let's keep your suggestion and squash the 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
Pretty pictures of git merge conflicts
Hi, I've been thinking lately about how to attack difficult git merge conflicts. The first step is to visualize them. I have written some articles [1,2,3] describing a way to atomize a complicated merge and efficiently compute diagrams that show which pairwise commits cause the merge to go awry. I hope you find them interesting; feedback would be very welcome. I am working on some more articles (including software) that I plan to grow into tools to help users perform git merges that would otherwise seem hopeless. Michael [1] http://softwareswirl.blogspot.de/2012/12/the-conflict-frontier-of-nightmare-merge.html [2] http://softwareswirl.blogspot.de/2012/12/mapping-merge-conflict-frontier.html [3] http://softwareswirl.blogspot.de/2012/12/real-world-conflict-diagrams.html -- 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: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.
On 01/03/2013 04:22 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>>> Doesn't Python come with a standard subprocess module that lets you
>>> spawn external programs safely, similar to the way Perl's list form
>>> open(), e.g. "open($fh, "-|", 'git', @args)", works?
>
> ... and of course a more boring "system('git', $subcmd, @args)", as well.
Python's os.system() takes exactly one argument, which must be a string,
and executes it in a subshell. subprocess is indeed the way to go.
>> You mean something like this:
>>
>> p1 = subprocess.Popen([backend.command()], stdout=subprocess.PIPE)
>> subprocess.Popen(["git", "fast-import", "--quiet"] + gitopts,
>> cwd=outdir, stdin=p1.stdout)
>>
>> Assuming gitopts is a list rather than a string. (care must be taken
>> with backend.command() also)
>
> Yes.
>
> I vaguely recall that the subprocess module once used to be one
> portability issue but that was between Python 2.3 and 2.4 or some
> ancient history, and it should no longer be relevant.
subprocess was added in Python 2.4, and the above example should work
fine in any version >= 2.4. But please note that other functions have
been added to the module since then, like check_call() (v2.5),
check_output (v2.7), and some methods were added to the Popen object in
v2.6.
Such things are documented pretty reliably in the Python library
documentation [1]; when in doubt, one can view older versions of the
library documentation, which are all available online [2].
Michael
[1] http://docs.python.org/2/library/
[2] http://www.python.org/doc/versions/
--
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: [RFH] NetBSD 6?
Greg Troxel writes: > Junio C Hamano writes: > >> Greg Troxel writes: >> >>> I realize a README.foo file for N different systems could be clutter, >>> but having these checked in would provide the concise help that people >>> on any of those platforms need. >> >> Our Makefile documents knobs people on various platforms can tweak >> (PYTHON_PATH and OLD_ICONV are two examples of them), sets default >> values for them based on $(uname -S), then includes config.mak file >> the user can optionally create to override these platform defaults. >> This infrastructure is used across platforms, not just for NetBSD. > > If you have to choose a single PYTHON_PATH, the one you picked is right > (for now, and likely will be right for a long time). > > But as a general rule, I think configure tests are preferable to > OS-specific variables. I forgot to mention that we also ship configure (and keep track of configure.ac) so that optionally people can let autoconf machinery to create config.mak.autogen to be included at the same place as handcrafted config.mak in their build process. I do not offhand know if we do "for p in python python2.6 python2.7; do ..." kind of thing, though. > A large number of people on NetBSD use git, but almost all of them get > it via pkgsrc (which is also where they get perl, emacs, svn, and > everything else you didn't find in /usr/bin). The exception would be > people that want to hack on git itself. Yeah, that much I figured ;-) > People who want gnu libiconv can install the libiconv package from > pkgsrc. (I'm guessing OLD_ICONV means "POSIX iconv", without GNU > extensions (iconvctl?).) It refers to the type of the second parameter to iconv(); OLD_ICONV makes it take "const char *", as opposed to "char *", the latter of which matches http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html > So, it doesn't matter too much for pkgsrc what you change, because it > can be patched anyway (once, for all users). Yes. The values in the Makefile are fallback defaults, and matters only to people who build from the source. -- 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 v3 5/5] format-patch: pick up branch description when no ref is specified
We only try to get branch name in "format-patch origin" case or
similar and not "format-patch -22" where HEAD is automatically
added. Without correct branch name, branch description cannot be
added. Make sure we always get branch name.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
On Thu, Jan 3, 2013 at 10:49 PM, Junio C Hamano wrote:
> You could (and I think you should) do something like this:
>
> if (0 <= positive) {
> ref = rev->cmdline.rev[positive].name;
> tip_sha1 = rev->cmdline.rev[positive].item->sha1;
> } else if (... defaulted to implied HEAD? ...) {
> ref = "HEAD";
> tip_sha1 = rev->pending.objects[0].item->sha1;
> } else {
> return NULL;
> }
>
> if (dwim_ref(...) && !prefixcmp(full_ref, "refs/heads/") &&
> !hashcmp(tip_sha1, branch_sha1))
>
> to preserve that safety instead.
Good idea. Done.
builtin/log.c | 18 +++---
t/t4014-format-patch.sh | 7 +++
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 039bf67..72a368a 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1016,6 +1016,7 @@ static char *find_branch_name(struct rev_info *rev)
{
int i, positive = -1;
unsigned char branch_sha1[20];
+ const unsigned char *tip_sha1;
const char *ref;
char *full_ref, *branch = NULL;
@@ -1027,12 +1028,23 @@ static char *find_branch_name(struct rev_info *rev)
else
return NULL;
}
- if (positive < 0)
+ if (0 <= positive) {
+ ref = rev->cmdline.rev[positive].name;
+ tip_sha1 = rev->cmdline.rev[positive].item->sha1;
+ } else if (!rev->cmdline.nr && rev->pending.nr == 1 &&
+ !strcmp(rev->pending.objects[0].name, "HEAD")) {
+ /*
+* No actual ref from command line, but "HEAD" from
+* rev->def was added in setup_revisions()
+* e.g. format-patch --cover-letter -12
+*/
+ ref = "HEAD";
+ tip_sha1 = rev->pending.objects[0].item->sha1;
+ } else
return NULL;
- ref = rev->cmdline.rev[positive].name;
if (dwim_ref(ref, strlen(ref), branch_sha1, &full_ref) &&
!prefixcmp(full_ref, "refs/heads/") &&
- !hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1))
+ !hashcmp(tip_sha1, branch_sha1))
branch = xstrdup(full_ref + strlen("refs/heads/"));
free(full_ref);
return branch;
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 903a797..7e52941 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -998,4 +998,11 @@ test_expect_success 'cover letter using branch description
(5)' '
grep hello actual >/dev/null
'
+test_expect_success 'cover letter using branch description (6)' '
+ git checkout rebuild-1 &&
+ test_config branch.rebuild-1.description hello &&
+ git format-patch --stdout --cover-letter -2 >actual &&
+ grep hello actual >/dev/null
+'
+
test_done
--
1.8.0.rc2.23.g1fb49df
--
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: cvsps, parsecvs, svn2git and the CVS exporter mess
On Sat, Dec 22, 2012 at 12:36 PM, Eric S. Raymond wrote: > It is pure accident that I now maintain two of these. Maintainership is always temporary. > Having three different tools for this job seems to me duplicative and > pointless; two of them should probably be let die an honorable death. Perhaps just maintain the code that serves your goals. That way, you don't need long trolly emails nor approval from anyone. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- 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 5/5] format-patch: pick up branch description when no ref is specified
Nguyễn Thái Ngọc Duy writes:
> We only try to get branch name in "format-patch origin" case or
> similar and not "format-patch -22" where HEAD is automatically
> added. Without correct branch name, branch description cannot be
> added. Make sure we always get branch name.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/log.c | 16 +---
> t/t4014-format-patch.sh | 7 +++
> 2 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/log.c b/builtin/log.c
> index 039bf67..81683f6 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -1027,12 +1027,22 @@ static char *find_branch_name(struct rev_info *rev)
> else
> return NULL;
> }
> - if (positive < 0)
> + if (positive >= 0)
> + ref = rev->cmdline.rev[positive].name;
> + else if (!rev->cmdline.nr && rev->pending.nr == 1 &&
> + !strcmp(rev->pending.objects[0].name, "HEAD"))
> + /*
> + * No actual ref from command line, but "HEAD" from
> + * rev->def was added in setup_revisions()
> + * e.g. format-patch --cover-letter -12
> + */
> + ref = "HEAD";
> + else
> return NULL;
> - ref = rev->cmdline.rev[positive].name;
> if (dwim_ref(ref, strlen(ref), branch_sha1, &full_ref) &&
> !prefixcmp(full_ref, "refs/heads/") &&
> - !hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1))
> + (positive < 0 ||
> + !hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1)))
This hashcmp() is to make sure that the tip we _guessed_ with
dwim_ref() that the user meant matches what we are going to use, so
I do not think disabling the check is a good idea.
You could (and I think you should) do something like this:
if (0 <= positive) {
ref = rev->cmdline.rev[positive].name;
tip_sha1 = rev->cmdline.rev[positive].item->sha1;
} else if (... defaulted to implied HEAD? ...) {
ref = "HEAD";
tip_sha1 = rev->pending.objects[0].item->sha1;
} else {
return NULL;
}
if (dwim_ref(...) && !prefixcmp(full_ref, "refs/heads/") &&
!hashcmp(tip_sha1, branch_sha1))
to preserve that safety instead.
--
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: cvsps, parsecvs, svn2git and the CVS exporter mess
On 12/22/2012 06:36 PM, Eric S. Raymond wrote:
> * One is Michael Haggerty's cvs2git. I had bad experiences with the
> cvs2svn code it's derived from in the past, but Michael believes those
> problems have been fixed and I will accept that - at least until I can
> test for myself. Its documented interface is not quite good enough
> yet; as the documentation says, "The data that should be fed to git
> fast-import are written to two files, which have to be loaded into git
> fast-import manually."
There are two good reasons that the output is written to two separate files:
1. The files are generated during different passes of cvs2git, and since
the cvs2git conversion is restartable pass-by-pass, the first file might
only need to be generated once even while the user is iterating on
adjustments to other conversion options.
2. The first ("blobfile") contains blob definitions for file revisions,
which are read out of the RCS files in the order they are held in the
RCS file. This is vastly faster than reading the file revisions in the
order that they are needed for git commits because (1) all revisions for
a file can be computed from one serial read of the RCS file; (2) there
is no need to jump around from rcsfile to rcsfile. The second
("dumpfile") stitches the blobs together into git commits by referring
to the blobs that are needed. This file is smaller because it doesn't
contain the actual file contents. Another advantage of this approach is
that a blob need only appear once in the blobfile even if it is used
multiple times in the git history.
Anyway, surely cat'ing two output files together is not such a difficult
problem?
A potentially bigger problem is that if you want to handle such
blob/dump output, you have to deal with git-fast-import format's "blob"
command as opposed to only handling inline blobs. However, if that is a
problem, it is possible to configure cvs2git to write the blobs inline
with the rest of the dumpfile (this mode is supported because "hg
fast-import" doesn't support detached blobs). You would have to create
an options file that uses GitRevisionInlineWriter, similar to what is
done in cvs2hg-example.options.
> [...]
> Having three different tools for this job seems to me duplicative and
> pointless; two of them should probably be let die an honorable death.
> I don't actually care which of the three survives - and, in
> particular, if I determine that cvs2git is doing the best job of the
> three I am quite willing to declare end-of-life for cvsps and
> parsecvs. It's not like I don't have plenty of other projects to work
> on.
cvs2git does not currently support incremental conversions; therefore, a
cvsps-based option (if it would actually work, that is) would have at
least one advantage over cvs2git.
> I presently know of three test suites other than mine. One was built
> by Heiko to test cvsps, another lives in the git t/ directory, and the
> third is cvs2git's. I haven't looked at cv2git's yet, but the others
> are not in their present form suited to where I am taking cvsps and
> parsecvs. Heiko's relies on the default human-readable cvsps format,
> which I consider obsolete and uninteresting. The git tests are
> dependent on details of porcelain behavior. I think it would be
> better to test import-stream output.
cvs2svn has an extensive test suite which includes tests derived from
bug reports that we have received over the years. I adapted a few of
its test repositories to create the git test suite additions that I made
in Feb 2009, but there are many more in our project.
A lot of our test suite deals with additional conversion features, like:
* Re-encoding filenames, usernames, and log messages from whatever
happens to have been used in the CVS repository into UTF-8
* Fixing CVS branches, tags, and mixed branch/tag messes according to
user wishes; renaming branches and tags
* Allowing the user to influence the choice of which branch should serve
as the source for another branch/tag (CVS records this information very
ambiguously)
* Fixing binary vs. text files, expanding/contracting CVS keywords, etc.
* Removing lots of synthetic revisions and other cruft generated by CVS
to fit within the RCS file format
* Dealing with vendor branches in a sensible way, especially considering
that very many users misuse vendor branches for initial imports
* Dealing with various common types of CVS repository corruption
See our list of features [1] for more details. Presumably many of these
features would not be covered by your test framework, and are not
supported by the other conversion tools.
Unfortunately, our tests are mostly based on cvs2svn (i.e., not 2git);
that is, the conversion is done with cvs2svn and checked by verifying
the contents of the resulting Subversion repository.
The script contrib/verify-cvs2svn.py is another kind of test; it checks
every branch and tag out of CVS and the destination repository and
verifies that their contents are identical.
Re: [BUG] two-way read-tree can write null sha1s into index
Jeff King writes:
> On Tue, Jan 01, 2013 at 02:24:46PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > So I think we need to update twoway_merge to recognize unmerged entries,
>> > which gives us two options:
>> >
>> > 1. Reject the merge.
>> >
>> > 2. Throw away the current unmerged entry in favor of the "new" entry
>> > (when old and new are the same, of course; otherwise we would
>> > reject).
>> >
>> > I think (2) is the right thing.
>>
>> As "--reset" in "read-tree --reset -u A B" is a way to say "we know
>> we are based on A and we want to go to B no matter what", I agree we
>> should not reject the merge.
>>
>> With -m instead of --reset, I am not sure what the right semantics
>> should be, though.
>
> Good point; I was just thinking about the --reset case.
>
> With "-m", though, we could in theory carry over the unmerged entries
> (again, assuming that "old" and "new" are the same; otherwise it is an
> obvious reject). But those entries would be confused with any new
> unmerged entries we create. It seems we already protect against this,
> though: "read-tree -m" will not run at all if you have unmerged entries.
>
> Likewise, "checkout" seems to have similar protections.
>
> So I think it may be a non-issue.
Yeah. Also earlier in the thread you mentioned three-way case, but
I do not think we ever would want --reset with three trees, so I
think that too is a non-issue for the same reason.
I would still feel safer if we expressed the expectation of
the callee in the code, perhaps like this in the two-way case:
if (current->ce_flags & CE_CONFLICTED) {
if (!o->reset) {
... either die or fail ...
} else {
... your fix ...
}
}
--
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] Replace git-cvsimport with a rewrite that fixes major bugs.
Antoine Pelisse writes:
>> Doesn't Python come with a standard subprocess module that lets you
>> spawn external programs safely, similar to the way Perl's list form
>> open(), e.g. "open($fh, "-|", 'git', @args)", works?
... and of course a more boring "system('git', $subcmd, @args)", as well.
> You mean something like this:
>
> p1 = subprocess.Popen([backend.command()], stdout=subprocess.PIPE)
> subprocess.Popen(["git", "fast-import", "--quiet"] + gitopts,
> cwd=outdir, stdin=p1.stdout)
>
> Assuming gitopts is a list rather than a string. (care must be taken
> with backend.command() also)
Yes.
I vaguely recall that the subprocess module once used to be one
portability issue but that was between Python 2.3 and 2.4 or some
ancient history, and it should no longer be relevant.
--
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 v2 5/5] format-patch: pick up branch description when no ref is specified
We only try to get branch name in "format-patch origin" case or
similar and not "format-patch -22" where HEAD is automatically
added. Without correct branch name, branch description cannot be
added. Make sure we always get branch name.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/log.c | 16 +---
t/t4014-format-patch.sh | 7 +++
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 039bf67..81683f6 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1027,12 +1027,22 @@ static char *find_branch_name(struct rev_info *rev)
else
return NULL;
}
- if (positive < 0)
+ if (positive >= 0)
+ ref = rev->cmdline.rev[positive].name;
+ else if (!rev->cmdline.nr && rev->pending.nr == 1 &&
+!strcmp(rev->pending.objects[0].name, "HEAD"))
+ /*
+* No actual ref from command line, but "HEAD" from
+* rev->def was added in setup_revisions()
+* e.g. format-patch --cover-letter -12
+*/
+ ref = "HEAD";
+ else
return NULL;
- ref = rev->cmdline.rev[positive].name;
if (dwim_ref(ref, strlen(ref), branch_sha1, &full_ref) &&
!prefixcmp(full_ref, "refs/heads/") &&
- !hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1))
+ (positive < 0 ||
+!hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1)))
branch = xstrdup(full_ref + strlen("refs/heads/"));
free(full_ref);
return branch;
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 903a797..7e52941 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -998,4 +998,11 @@ test_expect_success 'cover letter using branch description
(5)' '
grep hello actual >/dev/null
'
+test_expect_success 'cover letter using branch description (6)' '
+ git checkout rebuild-1 &&
+ test_config branch.rebuild-1.description hello &&
+ git format-patch --stdout --cover-letter -2 >actual &&
+ grep hello actual >/dev/null
+'
+
test_done
--
1.8.0.rc2.23.g1fb49df
--
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 v2 4/5] format-patch: pick up correct branch name from symbolic ref
find_branch_name() assumes to take refs/heads/. But we also
have symbolic refs, such as HEAD, that can point to a valid branch in
refs/heads and do not follow refs/heads/ syntax. Remove the
assumption and apply normal ref resolution. After all it would be
confusing if rev machinery resolves a ref in one way and
find_branch_name() another.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/log.c | 21 +
t/t4014-format-patch.sh | 14 ++
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index e7b7db1..039bf67 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1016,8 +1016,8 @@ static char *find_branch_name(struct rev_info *rev)
{
int i, positive = -1;
unsigned char branch_sha1[20];
- struct strbuf buf = STRBUF_INIT;
- const char *branch;
+ const char *ref;
+ char *full_ref, *branch = NULL;
for (i = 0; i < rev->cmdline.nr; i++) {
if (rev->cmdline.rev[i].flags & UNINTERESTING)
@@ -1029,16 +1029,13 @@ static char *find_branch_name(struct rev_info *rev)
}
if (positive < 0)
return NULL;
- strbuf_addf(&buf, "refs/heads/%s", rev->cmdline.rev[positive].name);
- branch = resolve_ref_unsafe(buf.buf, branch_sha1, 1, NULL);
- if (!branch ||
- prefixcmp(branch, "refs/heads/") ||
- hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1))
- branch = NULL;
- strbuf_release(&buf);
- if (branch)
- return xstrdup(rev->cmdline.rev[positive].name);
- return NULL;
+ ref = rev->cmdline.rev[positive].name;
+ if (dwim_ref(ref, strlen(ref), branch_sha1, &full_ref) &&
+ !prefixcmp(full_ref, "refs/heads/") &&
+ !hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1))
+ branch = xstrdup(full_ref + strlen("refs/heads/"));
+ free(full_ref);
+ return branch;
}
int cmd_format_patch(int argc, const char **argv, const char *prefix)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index ec9ef9e..903a797 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -984,4 +984,18 @@ test_expect_success 'cover letter using branch description
(3)' '
grep hello actual >/dev/null
'
+test_expect_success 'cover letter using branch description (4)' '
+ git checkout rebuild-1 &&
+ test_config branch.rebuild-1.description hello &&
+ git format-patch --stdout --cover-letter master.. >actual &&
+ grep hello actual >/dev/null
+'
+
+test_expect_success 'cover letter using branch description (5)' '
+ git checkout rebuild-1 &&
+ test_config branch.rebuild-1.description hello &&
+ git format-patch --stdout --cover-letter -2 HEAD >actual &&
+ grep hello actual >/dev/null
+'
+
test_done
--
1.8.0.rc2.23.g1fb49df
--
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 v2 3/5] t4014: a few more tests on cover letter using branch description
Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t4014-format-patch.sh | 21 + 1 file changed, 21 insertions(+) diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh index 16a4ca1..ec9ef9e 100755 --- a/t/t4014-format-patch.sh +++ b/t/t4014-format-patch.sh @@ -963,4 +963,25 @@ test_expect_success 'format patch ignores color.ui' ' test_cmp expect actual ' +test_expect_success 'cover letter using branch description (1)' ' + git checkout rebuild-1 && + test_config branch.rebuild-1.description hello && + git format-patch --stdout --cover-letter master >actual && + grep hello actual >/dev/null +' + +test_expect_success 'cover letter using branch description (2)' ' + git checkout rebuild-1 && + test_config branch.rebuild-1.description hello && + git format-patch --stdout --cover-letter rebuild-1~2..rebuild-1 >actual && + grep hello actual >/dev/null +' + +test_expect_success 'cover letter using branch description (3)' ' + git checkout rebuild-1 && + test_config branch.rebuild-1.description hello && + git format-patch --stdout --cover-letter ^master rebuild-1 >actual && + grep hello actual >/dev/null +' + test_done -- 1.8.0.rc2.23.g1fb49df -- 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 v2 2/5] branch: delete branch description if it's empty
Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/branch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/branch.c b/builtin/branch.c index 1ec9c02..873f624 100644 --- a/builtin/branch.c +++ b/builtin/branch.c @@ -725,7 +725,7 @@ static int edit_branch_description(const char *branch_name) stripspace(&buf, 1); strbuf_addf(&name, "branch.%s.description", branch_name); - status = git_config_set(name.buf, buf.buf); + status = git_config_set(name.buf, buf.len ? buf.buf : NULL); strbuf_release(&name); strbuf_release(&buf); -- 1.8.0.rc2.23.g1fb49df -- 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 v2 1/5] config.txt: a few lines about branch..description
Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/config.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index bf8f911..ee64846 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -735,6 +735,12 @@ branch..rebase:: it unless you understand the implications (see linkgit:git-rebase[1] for details). +branch..description:: + Branch description, can be edited with + `git branch --edit-description`. Branch description is + automatically added in the format-patch cover letter or + request-pull summary. + browser..cmd:: Specify the command to invoke the specified browser. The specified command is evaluated in shell with the URLs passed -- 1.8.0.rc2.23.g1fb49df -- 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 v2 0/5] nd/maint-branch-desc-doc reroll
- move the comment in 5/5 into the commented code block - resolve branch name for "HEAD" in 4/5 Nguyễn Thái Ngọc Duy (5): config.txt: a few lines about branch..description branch: delete branch description if it's empty t4014: a few more tests on cover letter using branch description format-patch: pick up correct branch name from symbolic ref format-patch: pick up branch description when no ref is specified Documentation/config.txt | 6 ++ builtin/branch.c | 2 +- builtin/log.c| 33 - t/t4014-format-patch.sh | 42 ++ 4 files changed, 69 insertions(+), 14 deletions(-) -- 1.8.0.rc2.23.g1fb49df -- 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: [RFH] NetBSD 6?
Junio C Hamano writes: > Greg Troxel writes: > >> I realize a README.foo file for N different systems could be clutter, >> but having these checked in would provide the concise help that people >> on any of those platforms need. > > Our Makefile documents knobs people on various platforms can tweak > (PYTHON_PATH and OLD_ICONV are two examples of them), sets default > values for them based on $(uname -S), then includes config.mak file > the user can optionally create to override these platform defaults. > This infrastructure is used across platforms, not just for NetBSD. If you have to choose a single PYTHON_PATH, the one you picked is right (for now, and likely will be right for a long time). But as a general rule, I think configure tests are preferable to OS-specific variables. > The part shown in the patch was to update the platform default for > NetBSD. The setting we have been shipping in our Makefile seemed to > be different from what I needed on my NetBSD 6 install, and I was > wondering if we have no real users of Git on the platorm (which > would explain why we didn't get any complaints or patches to update > this part). Or there are some optional packages all real NetBSD > users install, but being a NetBSD newbie I didn't, that makes the > values I showed in the patch inappropriate for them (e.g. Perhaps > there is a mechanism other than pkgsrc that installs perl and python > under /usr/bin? Perhaps an optional libi18n package that gives > iconv(3) with new function signature?), in which case I definitely > should not apply that patch to my tree, as it would only be an > improvement for one person and a regression for existing users at > the same time. A large number of people on NetBSD use git, but almost all of them get it via pkgsrc (which is also where they get perl, emacs, svn, and everything else you didn't find in /usr/bin). The exception would be people that want to hack on git itself. People who want gnu libiconv can install the libiconv package from pkgsrc. (I'm guessing OLD_ICONV means "POSIX iconv", without GNU extensions (iconvctl?).) The git package doesn't depend on GNU iconv, though (perhaps it should but we tend to avoid dependencies that arren't really needed). There are no mechanisms to install python/perl in /usr/bin, and doing so would be viewed as bizarre. /usr/bin belongs to the base system, /usr/pkg to pkgsrc and /usr/local to the user. So, it doesn't matter too much for pkgsrc what you change, because it can be patched anyway (once, for all users). It's probably better to make a straightforward build from source come out right. But, if the build respects the PYTHON_PATH environment variable, that's easier (and more robust against changes) than patching. pgprVh_UkXPeb.pgp Description: PGP signature
Re: git filter-branch doesn't dereference annotated tags
Am 03.01.2013 10:50, schrieb Grégory Pakosz: >> >> IOW, if the command was something like >> >> git filter-branch ...filter options... -- v1.0 master ... >> >> and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be >> deleted if the commit it points to goes away. But if the commit did not >> go away, but was rewritten, then it is equally reasonable to expect that >> the tag is also rewritten. But I don't think that we currently do the >> latter. >> > When the commit doesn't go away, the tag is currently being rewritten > properly. Indeed, but only if a --tag-name-filter was specified. >> Therefore, IMO, a change that implements the former behavior should also >> implement the latter behavior. >> > The patch in my latest email does both. (yet lacks unit tests for now) If it deletes a tag only when --tag-name-filter was specified, than that should be fine. -- 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: [RFD] annnotating a pair of commit objects?
Am 03.01.2013 08:03, schrieb Junio C Hamano: > The intended use case is to "go beyond rerere". Given a history of > this shape: > > o---o---o---I mainline >/ > O---o---X---o---Atopic A >\ > o---Y---o---o---B topic B > > Suppose in the original O we had a function "distimmed_doshes()" to > tell if doshes are already distimmed, with some call sites. On the > branch leading to A, at commit X, this function was renamed to > "doshes_are_distimmed()", and all existing call sites were adjusted. > On the side branch leading to B, however, at commit Y, a new call > site to the old function was added in a file that was not touched > between O..A at all. > > When merging either the topic A or the topic B (but not both) to the > integration branch that did not touch this function or use of it, no > special care needs to be taken, but when merging the second topic > after merging the other one, we need to resolve a semantic conflict. > Namely, the callsite to "distimmed_doshes()" introduced by commit Y > needs to be adjusted to call "doshes_are_distimmed()" instead. I guess this issue comes up when you rebuild pu. Perhaps you (and other integrators with a similar workflow) are sufficiently served with something that resembles rebase -p --first-parent, as proposed here: http://thread.gmane.org/gmane.comp.version-control.git/198125/focus=198483 (A proposal of the same idea appeared already years earlier: http://thread.gmane.org/gmane.comp.version-control.git/62782/focus=62794 but its implementation only re-did the merge, which would not help your case.) -- 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: [RFD] annnotating a pair of commit objects?
On 01/03/2013 08:03 AM, Junio C Hamano wrote: > I'd like a datastore that maps a pair of commit object names to > another object name, such that: > > * When looking at two commits A and B, efficiently query all data >associated with a pair of commits where X is contained in >the range A..B and not in B..A, and Y is contained in the range >B..A and not in A..B. > > * When is registered in the datastore, and X is rewritten to >X' and/or Y is rewritten to Y', the mapping is updated so that it >can be queried with as a new key, similar to the way a >notes tree that maps object X can be updated to map object X' >when such a rewrite happens. > > The intended use case is to "go beyond rerere". Given a history of > this shape: > > o---o---o---I mainline >/ > O---o---X---o---Atopic A >\ > o---Y---o---o---B topic B If we ignore rewriting for a moment, the information that you want to record is essentially the merge M of X and Y, no? Namely, X and Y conflict logically with each other (though perhaps not textually) and you, the human, want to record how to reconcile them: o---o---o---I mainline / O---o---X---o---Atopic A \ \ \ M \ / o---Y---o---o---B topic B However, you don't necessarily want to go to the trouble to make a branch to point at M, nor to do the bookkeeping manually that would be required to take the information stored in M into account when merging A and B later. Suppose we had M; how could we make use of it in future merges? > [...] and can create a merge J without semantic adjustment. > > o---o---o---I---J mainline >/ / > O---o---X---o---Atopic A >\ > o---Y---o---o---B topic B That would become o---o---o---I---J mainline / / O---o---X---o---Atopic A \ \ \ M \ / o---Y---o---o---B topic B > When I later merge topic B to the integration branch, however, [...] > to notice that we need to be careful when creating the merge K: > > o---o---o---I---J---K mainline >/ / / > O---o---X---o---A /topic A >\ / > o---Y---o---o---B topic B When doing this merge, I think your goal is equivalent to discovering that M includes part of the merge of J and B, and adding M as an (implicit or explicit) third parent to the merge: o---o---o---I---J---K mainline / /. / O---o---X---o---A. /topic A \ \ . / \ M. / \ / / o---Y---o---o---Btopic B How could M be stored? Assuming that these type of premerge merges are sparse, then Jeff's analysis seems good. Concretely, one could simply store pointers to M from both X and Y; e.g., * Add a note to X with the information "when merging this commit with Y, use premerge M" * Add a note to Y with the information "when merging this commit with X, use premerge M" Then, when merging, create the set J..B, scan all of the commits on B..J for these "premerge" notes (O(|B..J|)), and for each one, look in the set J..B to see if it is present. The effort should scale like O( |J..B| + |B..J| * lg(|J..B|) ) where, of course J and B could be exchanged for either aesthetic or performance reasons. (One would also need a mechanism for preventing M from being garbage-collected.) Incidentally, this is just the sort of thing I have been thinking about using to implement a kind of "incremental merge"; I've started writing up my thoughts on my blog [1,2,3] (including how to make pretty pictures of merge conflicts). Michael [1] http://softwareswirl.blogspot.de/2012/12/the-conflict-frontier-of-nightmare-merge.html [2] http://softwareswirl.blogspot.de/2012/12/mapping-merge-conflict-frontier.html [3] http://softwareswirl.blogspot.de/2012/12/real-world-conflict-diagrams.html -- 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: git filter-branch doesn't dereference annotated tags
> > IOW, if the command was something like > > git filter-branch ...filter options... -- v1.0 master ... > > and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be > deleted if the commit it points to goes away. But if the commit did not > go away, but was rewritten, then it is equally reasonable to expect that > the tag is also rewritten. But I don't think that we currently do the > latter. > When the commit doesn't go away, the tag is currently being rewritten properly. > Therefore, IMO, a change that implements the former behavior should also > implement the latter behavior. > The patch in my latest email does both. (yet lacks unit tests for now) Gregory -- 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 filter-branch doesn't dereference annotated tags
Am 03.01.2013 00:19, schrieb Junio C Hamano: > Grégory Pakosz writes: > >> So we have an annotated tag that points to a commit that is rewritten >> to nothing as the result of the filtering. What should happen? > > If the user asked to filter that tag itself, it may make sense to > remove it, rather than keeping it pointing at the original commit, > because the commit it used to point at no longer exists in the > alternate history being created by filter-branch. IOW, if the command was something like git filter-branch ...filter options... -- v1.0 master ... and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be deleted if the commit it points to goes away. But if the commit did not go away, but was rewritten, then it is equally reasonable to expect that the tag is also rewritten. But I don't think that we currently do the latter. Therefore, IMO, a change that implements the former behavior should also implement the latter behavior. -- 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: [BUG] two-way read-tree can write null sha1s into index
On Tue, Jan 01, 2013 at 02:24:46PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > So I think we need to update twoway_merge to recognize unmerged entries, > > which gives us two options: > > > > 1. Reject the merge. > > > > 2. Throw away the current unmerged entry in favor of the "new" entry > > (when old and new are the same, of course; otherwise we would > > reject). > > > > I think (2) is the right thing. > > As "--reset" in "read-tree --reset -u A B" is a way to say "we know > we are based on A and we want to go to B no matter what", I agree we > should not reject the merge. > > With -m instead of --reset, I am not sure what the right semantics > should be, though. Good point; I was just thinking about the --reset case. With "-m", though, we could in theory carry over the unmerged entries (again, assuming that "old" and "new" are the same; otherwise it is an obvious reject). But those entries would be confused with any new unmerged entries we create. It seems we already protect against this, though: "read-tree -m" will not run at all if you have unmerged entries. Likewise, "checkout" seems to have similar protections. So I think it may be a non-issue. -Peff -- 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: [RFD] annnotating a pair of commit objects?
On Wed, Jan 02, 2013 at 11:03:00PM -0800, Junio C Hamano wrote:
> I'd like a datastore that maps a pair of commit object names to
> another object name, such that:
>
> * When looking at two commits A and B, efficiently query all data
>associated with a pair of commits where X is contained in
>the range A..B and not in B..A, and Y is contained in the range
>B..A and not in A..B.
> [...]
> Obviously, with O(cnt(A..B))*O(cnt(B..A)) complexity, this can be
> trivially coded, by trying all pairs in symmetric difference.
>
> But I am hoping we can do better than that.
>
> Ideas?
Just thinking out loud, the problem can be generalized in math terms as:
- you have a universe of elements, `U` (i.e., all commits)
- you have two sets, `X` and `Y`, such that each is a subset of `U`
(these correspond to the two sides of the range, but we can think of
them just as sets of commits). We happen to know that the sets are
disjoint, but I don't know if that is helpful here.
- you have a set of sets `M` that is a subset of the cartesian product
`U x U` (i.e., its elements are "{x,y}" pairs, and membership in
that set is your "bit"; you could also think of it as a mapping if
you wanted more than a bit).
- you want to know the intersection of `X x Y` and `M` (which of your
pairs are in the mapping set).
Without doing any careful analysis, my gut says that in the worst case,
you are going to be stuck with `O(|X|*|Y|)` (i.e., what you are trying
to do better than above). But if we assume that `M` is relatively sparse
(which it should be; you only create entries when you do a merge between
two commits, and even then, only when it is tricky), we can probably do
better in practice.
For example, consider this naive way of doing it. Store `M` as a mapping
of commits to sets of commits, with fast lookup (a hash, or sorted
list). For each element of `X`, look it up in `M`; call its value `V`
(which, remember, is a set itself). For each element of `Y`, look it up
in `V`. The complexity would be:
O(|X| * lg(|M|) * |Y| * lg(V_avg))
where "V_avg" is the average cardinality of each of the value sets we
map in the first step. But imagine we pre-sort `Y`, and then in the
second step, rather than looking up each `Y` in `V`, we instead look up
each `V` in `Y`. Then we have:
O(|X| * lg(|M|) * V_avg * lg(|Y|))
IOW, we get to apply the log to |Y|. This is a win if we expect that
V_avg is going to be much smaller than |Y|. Which I think it would be,
since we would only have entries for merges we've done before[1].
That's just off the top of my head. This seems like it should be a
classic databases problem (since the cartesian product here is really
just a binary relation), but I couldn't find anything obvious online
(and I never paid attention in class, either).
-Peff
[1] You can do the same inversion trick for looking up elements of `M`
in `X` instead of vice versa. It would probably buy you less, as you
have a lot of commits that have merges at all (i.e., `M` is big),
but only a few matching partners for each entry (i.e., `V` is
small).
--
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
