Re: git-diff-index man page
Junio C Hamano wrote: --- a/Documentation/git-diff-index.txt +++ b/Documentation/git-diff-index.txt @@ -3,7 +3,7 @@ git-diff-index(1) NAME -git-diff-index - Compares content and mode of blobs between the index and repository +git-diff-index - Compare a tree and the working tree or the index Looks good. I think it scans better with the second the left out: git diff-index - Compare a tree to the working tree or index [...] @@ -13,11 +13,12 @@ SYNOPSIS DESCRIPTION --- -Compares the content and mode of the blobs found via a tree +Compare the content and mode of the blobs found in a tree object I think this s/Compares/Compare/ is a regression: traditionally the DESCRIPTION sections of manpages describe what a command does in the present indicative (When paths are specified, compares only those named paths), freeing up the imperative for cases where it is useful to instruct the user about what to do. The s/via/in/ looks fine. -object with the content of the current index and, optionally +with the corresponding tracked file in the working tree, or with the Since they are being compared to blobs, file should be files here. -ignoring the stat state of the file on disk. When paths are -specified, compares only those named paths. Otherwise all -entries in the index are compared. +corresponding paths in the index. When paths are specified, +compares only those named paths. Otherwise all entries in the index +are compared. The path parameters to git diff-index are pathspecs and not literal paths. This should say somewhere that this only looks at paths in the index and that untracked files are ignored. Perhaps something as simple as s/entries in the index/tracked files/ would do the trick. Thanks and hope that helps, Jonathan diff --git i/Documentation/git-diff-index.txt w/Documentation/git-diff-index.txt index 58308e15..a86cf62e 100644 --- i/Documentation/git-diff-index.txt +++ w/Documentation/git-diff-index.txt @@ -3,7 +3,7 @@ git-diff-index(1) NAME -git-diff-index - Compare a tree and the working tree or the index +git-diff-index - Compare a tree to the working tree or index SYNOPSIS @@ -13,12 +13,11 @@ SYNOPSIS DESCRIPTION --- - -Compare the content and mode of the blobs found in a tree object -with the corresponding tracked file in the working tree, or with the -corresponding paths in the index. When paths are specified, -compares only those named paths. Otherwise all entries in the index -are compared. +Compares the content and mode of the blobs found in a tree object +with the corresponding tracked files in the working tree, or with the +corresponding paths in the index. When path arguments are present, +compares only paths matching those patterns. Otherwise all tracked +files are compared. OPTIONS --- -- 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: Outdated and broken online versions of user-manual.html
Philip Oakley wrote: From: Thomas Ackermann th.ac...@arcor.de (5) Large overlapping with the tutorials. IMHO all of the tutorials should be blended into user-manual [...] I would be a little cautious of your point 5 if it squoze everything into one overlong document at the expense of losing the shorter documents - one can't eat a whole melon in one bite ;-) Yes. Once there was a lovely file at Documentation/howto/isolate-bugs-with-bisect.txt explaining how to use git bisect to find which commit caused a kernel regression. That it was a small independent file that didn't assume the reader had read much before was very helpful, since it meant people could easily point novices to that page and say It's easy! when asking them to track down a bug. Nowadays that content is gracefully included in the user-manual under the heading [[using-bisect]]. But I never point people to it any more; I just write out the steps by hand, to avoid intimidating them. Ideally this content would be in an EXAMPLE or TUTORIAL section of the git-bisect(1) manpage for easier reference. Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] patch-ids: check modified paths before calculating diff
On Sun, May 19, 2013 at 11:36:23PM -0700, Jonathan Nieder wrote: I don't know what it should mean to try to use --cherry without --no-merges or --first-parent, so I guess this is harmless. Currently --no-merges doesn't actually get passed down this far. We do the patch ID calculations without taking that into account. -- 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 0/6] t5000: add test for pax extended header generation
This series adds a test that exercises git archive's pax header code. It checks for tar versions that don't support pax headers and works around their deficiency. The first five patches are cleanups and refactorings to centralize tar calls into a helper function. The last patch adds the workaround at this central place and a file to the test archive whose name is too long to fit into the path field of a standard tar header, making a pax extended header necessary. René Scharfe (6): t5000: integrate export-subst tests into regular tests t5000, t5003: create directories for extracted files lazily t5000: factor out check_tar t5000: use check_tar for prefix test t5000: simplify tar-tree tests t5000: test long filenames t/t5000-tar-tree.sh| 160 + t/t5000/pax.tar| Bin 0 - 10240 bytes t/t5003-archive-zip.sh | 2 +- 3 files changed, 84 insertions(+), 78 deletions(-) create mode 100644 t/t5000/pax.tar -- 1.8.2.3 -- 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 5/6] t5000: simplify tar-tree tests
Just compare the archives created by git tar-tree with the ones created using git archive with the equivalent options, whose contents are checked already, instead of extracting them again. Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx --- t/t5000-tar-tree.sh | 31 --- 1 file changed, 8 insertions(+), 23 deletions(-) diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh index 5a9b570..a1f35d2 100755 --- a/t/t5000-tar-tree.sh +++ b/t/t5000-tar-tree.sh @@ -115,14 +115,6 @@ test_expect_success 'git-archive --prefix=olde-' ' check_tar with_olde-prefix olde- -test_expect_success \ -'git tar-tree' \ -'git tar-tree HEAD b2.tar' - -test_expect_success \ -'git archive vs. git tar-tree' \ -'test_cmp b.tar b2.tar' - test_expect_success 'git archive on large files' ' test_config core.bigfilethreshold 1 git archive HEAD b3.tar @@ -158,22 +150,15 @@ test_expect_success \ 'git get-tar-commit-id b.tar b.commitid test_cmp .git/$(git symbolic-ref HEAD) b.commitid' -test_expect_success \ -'git tar-tree with prefix' \ -'git tar-tree HEAD prefix c.tar' - -test_expect_success \ -'extract tar archive with prefix' \ -'(mkdir c cd c $TAR xf -) c.tar' - -test_expect_success \ -'validate filenames with prefix' \ -'(cd c/prefix/a find .) | sort c.lst - test_cmp a.lst c.lst' +test_expect_success 'git tar-tree' ' + git tar-tree HEAD tar-tree.tar + test_cmp b.tar tar-tree.tar +' -test_expect_success \ -'validate file contents with prefix' \ -'diff -r a c/prefix/a' +test_expect_success 'git tar-tree with prefix' ' + git tar-tree HEAD prefix tar-tree_with_prefix.tar + test_cmp with_prefix.tar tar-tree_with_prefix.tar +' test_expect_success 'git archive with --output, override inferred format' ' git archive --format=tar --output=d4.zip HEAD -- 1.8.2.3 -- 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 3/6] t5000: factor out check_tar
Create a helper function that extracts a tar archive and checks its
contents, modelled after check_zip in t5003.
Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx
---
t/t5000-tar-tree.sh | 35 ++-
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 41cd609..8337a1f 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -30,6 +30,26 @@ GUNZIP=${GUNZIP:-gzip -d}
SUBSTFORMAT=%H%n
+check_tar() {
+ tarfile=$1.tar
+ listfile=$1.lst
+ dir=$1
+ dir_with_prefix=$dir/$2
+
+ test_expect_success ' extract tar archive' '
+ (mkdir $dir cd $dir $TAR xf -) $tarfile
+ '
+
+ test_expect_success ' validate filenames' '
+ (cd ${dir_with_prefix}a find .) | sort $listfile
+ test_cmp a.lst $listfile
+ '
+
+ test_expect_success ' validate file contents' '
+ diff -r a ${dir_with_prefix}a
+ '
+}
+
test_expect_success \
'populate workdir' \
'mkdir a
@@ -81,6 +101,8 @@ test_expect_success \
'git archive' \
'git archive HEAD b.tar'
+check_tar b
+
test_expect_success \
'git tar-tree' \
'git tar-tree HEAD b2.tar'
@@ -125,19 +147,6 @@ test_expect_success \
test_cmp .git/$(git symbolic-ref HEAD) b.commitid'
test_expect_success \
-'extract tar archive' \
-'(mkdir b cd b $TAR xf -) b.tar'
-
-test_expect_success \
-'validate filenames' \
-'(cd b/a find .) | sort b.lst
- test_cmp a.lst b.lst'
-
-test_expect_success \
-'validate file contents' \
-'diff -r a b/a'
-
-test_expect_success \
'git tar-tree with prefix' \
'git tar-tree HEAD prefix c.tar'
--
1.8.2.3
--
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 4/6] t5000: use check_tar for prefix test
Perform the full range of checks against all archived files instead of looking only at the file type of a few of them. Also add a test of a git archive with a prefix ending in with a slash, i.e. adding a full directory level. Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx --- t/t5000-tar-tree.sh | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh index 8337a1f..5a9b570 100755 --- a/t/t5000-tar-tree.sh +++ b/t/t5000-tar-tree.sh @@ -103,6 +103,18 @@ test_expect_success \ check_tar b +test_expect_success 'git archive --prefix=prefix/' ' + git archive --prefix=prefix/ HEAD with_prefix.tar +' + +check_tar with_prefix prefix/ + +test_expect_success 'git-archive --prefix=olde-' ' + git archive --prefix=olde- HEAD with_olde-prefix.tar +' + +check_tar with_olde-prefix olde- + test_expect_success \ 'git tar-tree' \ 'git tar-tree HEAD b2.tar' @@ -180,18 +192,6 @@ test_expect_success 'clients cannot access unreachable commits' ' test_must_fail git archive --remote=. $sha1 remote.tar ' -test_expect_success 'git-archive --prefix=olde-' ' - git archive --prefix=olde- h.tar HEAD - ( - mkdir h - cd h - $TAR xf - ../h.tar - ) - test -d h/olde-a - test -d h/olde-a/bin - test -f h/olde-a/bin/sh -' - test_expect_success 'setup tar filters' ' git config tar.tar.foo.command tr ab ba git config tar.bar.command tr ab ba -- 1.8.2.3 -- 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 6/6] t5000: test long filenames
Add a file with a long name to the test archive in order to check
entries with pax extended headers. Also add a check for tar versions
that doen't understand this format. Those versions should extract the
headers as a regular files. Add code to check_tar() to interpret the
path header if present, so that our tests work even with those tar
versions.
It's important to use the fallback code only if needed to still be
able to detect git archive errorously creating pax headers as regular
file entries (with a suitable tar version, of course).
The archive used to check for pax header support in tar was generated
using GNU tar 1.26 and its option --format=pax.
Tested successfully on NetBSD 6.1, which has a tar version lacking pax
header support.
Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx
---
t/t5000-tar-tree.sh | 46 ++
t/t5000/pax.tar | Bin 0 - 10240 bytes
2 files changed, 46 insertions(+)
create mode 100644 t/t5000/pax.tar
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index a1f35d2..c2023b1 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -30,6 +30,32 @@ GUNZIP=${GUNZIP:-gzip -d}
SUBSTFORMAT=%H%n
+test_lazy_prereq TAR_NEEDS_PAX_FALLBACK '
+ (
+ mkdir pax
+ cd pax
+ $TAR xf $TEST_DIRECTORY/t5000/pax.tar
+ test -f PaxHeaders.1791/file
+ )
+'
+
+get_pax_header() {
+ file=$1
+ header=$2=
+
+ while read len rest
+ do
+ if test $len = $(echo $len $rest | wc -c)
+ then
+ case $rest in
+ $header*)
+ echo ${rest#$header}
+ ;;
+ esac
+ fi
+ done $file
+}
+
check_tar() {
tarfile=$1.tar
listfile=$1.lst
@@ -40,6 +66,24 @@ check_tar() {
(mkdir $dir cd $dir $TAR xf -) $tarfile
'
+ test_expect_success TAR_NEEDS_PAX_FALLBACK ' interpret pax headers' '
+ (
+ cd $dir
+ for header in *.paxheader
+ do
+ data=${header%.paxheader}.data
+ if test -h $data -o -e $data
+ then
+ path=$(get_pax_header $header path)
+ if test -n $path
+ then
+ mv $data $path
+ fi
+ fi
+ done
+ )
+ '
+
test_expect_success ' validate filenames' '
(cd ${dir_with_prefix}a find .) | sort $listfile
test_cmp a.lst $listfile
@@ -54,6 +98,8 @@ test_expect_success \
'populate workdir' \
'mkdir a
echo simple textfile a/a
+ ten=0123456789 hundred=$ten$ten$ten$ten$ten$ten$ten$ten$ten$ten
+ echo long filename a/four$hundred
mkdir a/bin
cp /bin/sh a/bin
printf A\$Format:%s\$O $SUBSTFORMAT a/substfile1
diff --git a/t/t5000/pax.tar b/t/t5000/pax.tar
new file mode 100644
index
..d91173714991fded560fcd6a8aaec6aa6ec7f5e8
GIT binary patch
literal 10240
zcmeIy%?g4*5Ww+0_Y^*X3@?Sp?k+(L29F*2+YXGPl*s(6d@sk|6W#S)Sdakm@cv
zvkB!sRJT7LN5=eb5OG`X;!?h^Yh?xL+x+Gv-HHCB5i+IVkN(#%@Lz{llx~$rg
z2GWzmuipCRCcpUG2dyNR`g93vZSz%O3b*p9Sn-kpDoKIhx%KXMfulr%w}@f7;`7
zyU`e%|LjgG5=zmO1_@SxRf~Zp8x84tbJTc^pGH_qWm2pU!{O2LS{SKmY**5I_I{
l1Q0*~0R#|0009ILKmY**5I_I{1Q0*~0R#|00D-}cmml}KZ5`O
literal 0
HcmV?d1
--
1.8.2.3
--
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 2/6] t5000, t5003: create directories for extracted files lazily
Create the directories b and c just before they are needed instead of
up front. For t5003 it turns out we don't need them at all. For t5000
it makes the coming modifications easier.
Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx
---
t/t5000-tar-tree.sh| 6 +++---
t/t5003-archive-zip.sh | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 68b5698..41cd609 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -32,7 +32,7 @@ SUBSTFORMAT=%H%n
test_expect_success \
'populate workdir' \
-'mkdir a b c
+'mkdir a
echo simple textfile a/a
mkdir a/bin
cp /bin/sh a/bin
@@ -126,7 +126,7 @@ test_expect_success \
test_expect_success \
'extract tar archive' \
-'(cd b $TAR xf -) b.tar'
+'(mkdir b cd b $TAR xf -) b.tar'
test_expect_success \
'validate filenames' \
@@ -143,7 +143,7 @@ test_expect_success \
test_expect_success \
'extract tar archive with prefix' \
-'(cd c $TAR xf -) c.tar'
+'(mkdir c cd c $TAR xf -) c.tar'
test_expect_success \
'validate filenames with prefix' \
diff --git a/t/t5003-archive-zip.sh b/t/t5003-archive-zip.sh
index 4e7b05d..c72f71e 100755
--- a/t/t5003-archive-zip.sh
+++ b/t/t5003-archive-zip.sh
@@ -37,7 +37,7 @@ check_zip() {
test_expect_success \
'populate workdir' \
-'mkdir a b c
+'mkdir a
echo simple textfile a/a
mkdir a/bin
cp /bin/sh a/bin
--
1.8.2.3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/17] Remove assumptions about refname lifetimes
On Sun, May 19, 2013 at 10:26 PM, Michael Haggerty mhag...@alum.mit.edu wrote: Recently a number of race conditions related to references have been discovered. There is likely to be a two-pronged solution to the races: * For traditional, filesystem-based references, there will have to be more checks that the ref caches are still up-to-date at the time of their use (see, for example, [1]). If not, the ref cache will have to be invalidated and reloaded. Assuming that the invalidation of the old cache includes freeing its memory, such an invalidation will cause lots of refname strings to be freed even though callers might still hold references to them. * For server-class installations, filesystem-based references might not be robust enough for 100% reliable operation, because the reading of the complete set of references is not an atomic operation. If another reference storage mechanism is developed, there is no reason to expect the refnames strings to have long lifetimes. (Sorry for going slightly off-topic and returning to the general discussion on how to resolve the race conditions...) For server-class installations we need ref storage that can be read (and updated?) atomically, and the current system of loose + packed files won't work since reading (and updating) more than a single file is not an atomic operation. Trivially, one could resolve this by dropping loose refs, and always using a single packed-refs file, but that would make it prohibitively expensive to update refs (the entire packed-refs file must be rewritten for every update). Now, observe that we don't have these race conditions in the object database, because it is an add-only immutable data store. What if we stored the refs as a tree object in the object database, referenced by a single (loose) ref? There would be a _single_ (albeit highly contentious) file outside the object database that represent the current state of the refs, but hopefully we can guarantee atomicity when reading (and updating?) that one file. Transactions can be done by: 1. Recording the tree id holding the refs before starting manipulation. 2. Creating a new tree object holding the manipulated state. 3. Re-checking the tree id before replacing the loose ref. If unchanged: commit, else: rollback/error out. All readers would trivially have access to a consistent refs view, since the state of the entire refs hierarchy is held in the tree id read from that single loose ref. It seems to me this should be somewhat less prohibitively expensive than maintaining all refs in a single packed-refs file. That said, we do end up producing a few new objects for every single ref update, most of which would be thrown away by a future gc. This might bog things down, but I'm not sure how much. I'm sure someone must have had this idea before (although I don't remember this alternative being raised at the Git Merge conference), so please enlighten me as to why this won't work... ;) ...Johan PS: Keeping reflogs is just a matter of wrapping the ref tree in a commit object using the previous state of the ref tree as its parent. -- Johan Herland, jo...@herland.net www.herland.net -- 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-submodule nested subrepo bug (Segmentation fault)
On Mon, May 20, 2013 at 09:32:21AM +0400, Kirill Berezin wrote: When you trying to add submodule, that already has submodule, it craches. For example you could try: git clone --recursive http://github.com/Exsul/al_server Which version of Git were you using? I was not able to reproduce this with 1.8.3-rc3. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 16/17] object_array_entry: copy name before storing in name field
On Sun, May 19, 2013 at 10:27 PM, Michael Haggerty mhag...@alum.mit.edu wrote: This is the culmination of the last few commits. Since some callers want to store refnames in the name field of object_array elements, but we don't want those callers to assume that the refnames that they got from for_each_ref() have infinite lifetime, the easiest thing to do is have object_array make a copy of the names before writing them in the entries, and to free the names for entries that are no longer in use. This change fixes the problem, but has some disadvantages: * It requires extra copies to be made of strings that are already copies, for example when the results of path_name(path, name) are used as a name in revision.c:add_object(). This might be rare enough that it can be ignored (though the original result of path_name() would have to be freed, which this patch doesn't do so there is a memory leak). * Many callers store the empty string () as the name; for example, most of the entries created during a run of rev-list have as their name. This means that lots of needless copies of are being made. I think that the best solution to this problem would be to store NULL rather than for such entries, but I haven't figured out all of the places where the name is used. Use strbufs? No allocation (except for the strbuf object itself) is needed for empty strings, and string ownership and be transferred to and from it to prevent extra copies. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- 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 0/6] t5000: add test for pax extended header generation
Am 20.05.2013 11:58, schrieb René Scharfe: This series adds a test that exercises git archive's pax header code. It checks for tar versions that don't support pax headers and works around their deficiency. The first five patches are cleanups and refactorings to centralize tar calls into a helper function. The last patch adds the workaround at this central place and a file to the test archive whose name is too long to fit into the path field of a standard tar header, making a pax extended header necessary. Forgot to mention that the last patch was prompted by Thomas' recent test coverage patches. René -- 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
Storing refs in the odb (was: Re: [PATCH 00/17] Remove assumptions about refname lifetimes)
On Mon, May 20, 2013 at 2:15 PM, Michael Haggerty mhag...@alum.mit.edu wrote: This is a very interesting idea. It's turtles all the way down. :) On 05/20/2013 12:28 PM, Johan Herland wrote: For server-class installations we need ref storage that can be read (and updated?) atomically, and the current system of loose + packed files won't work since reading (and updating) more than a single file is not an atomic operation. Trivially, one could resolve this by dropping loose refs, and always using a single packed-refs file, but that would make it prohibitively expensive to update refs (the entire packed-refs file must be rewritten for every update). Correct, or the packed-refs file would have to be updated in place using some database-style approach for locking/transactions/whatever. Now, observe that we don't have these race conditions in the object database, because it is an add-only immutable data store. Except for prune, of course, which can cause race conditions WRT to writers. Yes, but that is a different race, in need of a different solution. E.g. that race is concerned with pruning unreachable objects that are about to become reachable by a concurrent operation, which is AFAICS independent from the ref update race that we're discussing here. What if we stored the refs as a tree object in the object database, referenced by a single (loose) ref? There would be a _single_ (albeit highly contentious) file outside the object database that represent the current state of the refs, but hopefully we can guarantee atomicity when reading (and updating?) that one file. Transactions can be done by: 1. Recording the tree id holding the refs before starting manipulation. 2. Creating a new tree object holding the manipulated state. 3. Re-checking the tree id before replacing the loose ref. If unchanged: commit, else: rollback/error out. There are two closely related possibilities and I'm not sure which one you mean: * Effectively treat all of the refs as loose refs, but stored not in the filesystem but rather in a hierarchical tree structure in the object database. E.g., all of the refs directly under refs/heads would be in one tree object, those in refs/remotes/foo in a second, those for refs/remotes/bar in another etc. and all of them linked up together in a tree object representing refs. * Effectively treat all of the refs as packed refs, but store the single packed-refs file as a single object in the object database. (The first alternative sounds more practical to me. I also guess that's what you mean, since down below you say that each change would require producing a few objects.) The first alternative is what I had in mind. Initially I thought to record it as if one were to record a new tree using .git/refs as the root of your worktree (having exploded all packed-refs into loose refs). I.e. you would have heads, tags, remotes as subtrees of reference tree, and then e.g. in the heads subtree, there would be an entry named master pointing to a _blob_, and the contents of that blob would be the commit id of the current tip of the master branch. Obviously the next optimization would be to drop the master - blob - commit indirection, and use master - commit instead, i.e. the master tree entry corresponds directly to the commit to which it points (symrefs would naturally be recorded as symlinks). This would automatically provide reachability for all refs, but as you correctly observe: Of course in either case we couldn't use a tree object directly, because these new reference tree objects would refer not only to blobs and other trees but also to commits and tags. Indeed. I don't know if the best solution would be to actually _allow_ that (which would complicate the object parsing code somewhat; a tree entry pointing to a commit is usually interpreted as a submodule, but that is not what we'd want for the ref tree, and a tree entry pointing at a tag has AFAIK not yet been done), or whether it means we need to come up with a different kind of structure. [I know this is not what you are suggesting, but I am reminded of Subversion, which stores trunk, branches, and tags in the same tree space as the contents of the working trees. A Subversion commit references a gigantic tree encompassing all branches of development and all files on all of those branches (with cheap copies to reduce the redundancy): / /trunk/ /trunk/Makefile /trunk/src/ /trunk/src/foo.c /branches/ /branches/next/ /branches/next/Makefile /branches/next/src/ /branches/next/src/foo.c /branches/pu/ /branches/pu/Makefile /branches/pu/src/ /branches/pu/src/foo.c /tags/ /tags/v1.8.2/ /tags/v1.8.2/Makefile /tags/v1.8.2/src/ /tags/v1.8.2/src/foo.c etc... A Subversion commit thus describes the state of *every* branch and tag at that moment in time. The model is conceptually very simple (in
Re: [RFC 16/17] object_array_entry: copy name before storing in name field
On 05/20/2013 12:33 PM, Johan Herland wrote: On Sun, May 19, 2013 at 10:27 PM, Michael Haggerty mhag...@alum.mit.edu wrote: This is the culmination of the last few commits. Since some callers want to store refnames in the name field of object_array elements, but we don't want those callers to assume that the refnames that they got from for_each_ref() have infinite lifetime, the easiest thing to do is have object_array make a copy of the names before writing them in the entries, and to free the names for entries that are no longer in use. This change fixes the problem, but has some disadvantages: * It requires extra copies to be made of strings that are already copies, for example when the results of path_name(path, name) are used as a name in revision.c:add_object(). This might be rare enough that it can be ignored (though the original result of path_name() would have to be freed, which this patch doesn't do so there is a memory leak). * Many callers store the empty string () as the name; for example, most of the entries created during a run of rev-list have as their name. This means that lots of needless copies of are being made. I think that the best solution to this problem would be to store NULL rather than for such entries, but I haven't figured out all of the places where the name is used. Use strbufs? No allocation (except for the strbuf object itself) is needed for empty strings, and string ownership and be transferred to and from it to prevent extra copies. That would cost two extra size_t per object_array_entry. I have the feeling that this structure is used often enough that the extra overhead would be a disadvantage, but I'm not sure. The obvious alternative would be to teach users to deal with NULL and either add another constructor alternative that transfers string ownership or *always* transfer string ownership and change the callers to call xstrdup() if they don't already own the name string. I think I will try that approach first. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
-- 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: What's cooking in git.git (May 2013, #04; Wed, 15)
Duy Nguyen pclo...@gmail.com writes: On Thu, May 16, 2013 at 6:42 AM, Junio C Hamano gits...@pobox.com wrote: * nd/warn-ambiguous-object-name (2013-05-07) 1 commit - get_sha1: improve ambiguity warning regarding SHA-1 and ref names git cmd name, when name happens to be a 40-hex string, directly uses the 40-hex string as an object name, even if a ref refs/some hierarchy/name exists. This disambiguation order is unlikely to change, but we should warn about the ambiguity just like we warn when more than one refs/ hierachies share the same name. The message needs to be fixed up, as this is not refname is ambiguous. hm.. how should the message be rephrased? ambiguity of 40-hex string and a ref path? At that point, the user gave us a full object name and we are going to treat it as a full object name, no? Wouldn't it be necessary to let the user know that it is different from having two ambiguous refs? Think why the user has such a hard to type ref in the first place. The user may have done this previously, thinking that he is detaching the HEAD to fix an earlier mistake in a branch: $ BAD_COMMIT=$(git rev-parse nd/magic~8) $ git checkout $BAD_COMMIT but by mistake gave a -b after checkout, i.e. $ git checkout -b $BAD_COMMIT After this, commands that want to work on branch name would still work as expected, with the expectation being the user would be working on the refs/heads/$BAD_COMMIT branch, e.g. $ git checkout $BAD_COMMIT $ git branch -m $BAD_COMMIT nd/magic-fix but commands that want to work on commit object name will resolve it to the $BAD_COMMIT object (i.e. nd/magic~8), e.g. $ git log $BAD_COMMIT and needs disambiguation if the user wants to work on the commit at the tip of the branch, e.g. $ git log heads/$BAD_COMMIT So we really do want the users to notice and take corrective action, and one way to attract the attention of the users is to phrase the message more explicitly to let them know what is going on. In addition to your topic, it may be a good idea to notice this at the Porcelain level (e.g. checkout -b and branch, but not at the update-ref level) and warn or even die if a Porcelain tries to create a branch with such a name. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/17] Remove assumptions about refname lifetimes
Johan Herland jo...@herland.net writes: For server-class installations we need ref storage that can be read (and updated?) atomically, and the current system of loose + packed files won't work since reading (and updating) more than a single file is not an atomic operation. Trivially, one could resolve this by dropping loose refs, and always using a single packed-refs file, but that would make it prohibitively expensive to update refs (the entire packed-refs file must be rewritten for every update). Now, observe that we don't have these race conditions in the object database, because it is an add-only immutable data store. What if we stored the refs as a tree object in the object database, referenced by a single (loose) ref? What is the cost of updating a single branch with that scheme? Doesn't it end up recording roughly the same amount of information as updating a single packed-refs file that is flat, but with the need to open a few tree objects (top-level, refs/, and refs/heads/), writing out a blob that stores the object name at the tip, computing the updated trees (refs/heads/, refs/ and top-level), and then finally doing the compare-and-swap of that single loose ref? You may guarantee atomicity but it is the same granularity of atomicity as a single packed-refs file. When you are updating a branch while somebody else is updating a tag, of course you do not have to look at refs/tags/ in your operation and you can write out your final packed-refs equivalent tree to the object database without racing with the other process, but the top-level you come up with and the top-level the other process comes up with (which has an up-to-date refs/tags/ part, but has a stale refs/heads/ part from your point of view) have to race to update that single loose ref, and one of you have to back out. That backing out can be made more intelligently than just dying with compare and swap failed--please retry message, e.g. you at that point notice what you started with, what the other party did while you were working on (i.e. updating refs/tags/), and three-way merge the refs tree, and in cases where all refs recorded as loose refs scheme wouldn't have resulted in problematic conflict, such a three-way merge would resolve trivially (you updated refs/heads/ and the update by the other process to refs/tags/ would not conflict with what you did). But the same three-way merge scheme can be employed with the current flat single packed-refs scheme, can't it? Even worse, what is the cost of looking up the value of a single branch? You would need to open a few tree objects and the leaf blob that records the object name the ref points at, wouldn't you? Right now, such a look-up is either opening a single small file and reading the first 41 bytes off of it, and falling back (when the ref in question is packed) to read a single packed-refs file and finding the ref you want from it. So... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 16/17] object_array_entry: copy name before storing in name field
On Mon, May 20, 2013 at 04:42:38PM +0200, Michael Haggerty wrote: * Many callers store the empty string () as the name; for example, most of the entries created during a run of rev-list have as their name. This means that lots of needless copies of are being made. I think that the best solution to this problem would be to store NULL rather than for such entries, but I haven't figured out all of the places where the name is used. Use strbufs? No allocation (except for the strbuf object itself) is needed for empty strings, and string ownership and be transferred to and from it to prevent extra copies. That would cost two extra size_t per object_array_entry. I have the feeling that this structure is used often enough that the extra overhead would be a disadvantage, but I'm not sure. The obvious alternative would be to teach users to deal with NULL and either add another constructor alternative that transfers string ownership or *always* transfer string ownership and change the callers to call xstrdup() if they don't already own the name string. I think I will try that approach first. You could use the same trick that strbuf does: instead of NULL, point to a well-known empty string literal. Readers do not have to care about this optimization at all; only writers need to recognize the well-known pointer value. And since we do not update in place but only eventually free, it really is just that anyone calling free() would do if (name != well_known_empty_string). -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 00/17] Remove assumptions about refname lifetimes
On Mon, May 20, 2013 at 09:37:30AM -0700, Junio C Hamano wrote: Johan Herland jo...@herland.net writes: For server-class installations we need ref storage that can be read (and updated?) atomically, and the current system of loose + packed files won't work since reading (and updating) more than a single file is not an atomic operation. Trivially, one could resolve this by dropping loose refs, and always using a single packed-refs file, but that would make it prohibitively expensive to update refs (the entire packed-refs file must be rewritten for every update). Now, observe that we don't have these race conditions in the object database, because it is an add-only immutable data store. What if we stored the refs as a tree object in the object database, referenced by a single (loose) ref? What is the cost of updating a single branch with that scheme? Yeah, I had the same thoughts as you here; I don't think this is really much better than updating a single packed-refs file. You may only have to touch log(N) of the entries to update the trees along the path to your ref (assuming you have a bushy refs/ tree; in practice, of course, you have a lot of entries in refs/heads/, so you do not quite get log behavior). So algorithmically it may be slightly better, but you pay a much higher constant, in that you are creating many tree objects along the path (and reading them on lookup). But more importantly, it introduces contention between two unrelated refs that are being updated. Even if we reconcile the differences automatically (e.g., with a merge-and-retry strategy), that is going to be a serious performance regression for a busy repository, as we repeatedly try to reconcile the serialized updates to the refs/ root tree. Any transactional solution needs to have the equivalent of ref-level locking (i.e., row-level locking in a relational setting). It is OK for two simultaneous updates to different rows to happen in random order; we don't care about that level of atomicity. The important thing is that the _readers_ see transactions in consistent order; if we know that update B started after update A finished, then we must never see update A without update B reflected. And I think that is more or less a solved problem in the database world. That is what prevents: git update-ref A B git update-ref -d B from creating a view where the reader sees neither A nor B (which is what can happen with the current filesystem view). -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 00/17] Remove assumptions about refname lifetimes
On Mon, May 20, 2013 at 6:37 PM, Junio C Hamano gits...@pobox.com wrote: Johan Herland jo...@herland.net writes: For server-class installations we need ref storage that can be read (and updated?) atomically, and the current system of loose + packed files won't work since reading (and updating) more than a single file is not an atomic operation. Trivially, one could resolve this by dropping loose refs, and always using a single packed-refs file, but that would make it prohibitively expensive to update refs (the entire packed-refs file must be rewritten for every update). Now, observe that we don't have these race conditions in the object database, because it is an add-only immutable data store. What if we stored the refs as a tree object in the object database, referenced by a single (loose) ref? What is the cost of updating a single branch with that scheme? Doesn't it end up recording roughly the same amount of information as updating a single packed-refs file that is flat, but with the need to open a few tree objects (top-level, refs/, and refs/heads/), writing out a blob that stores the object name at the tip, computing the updated trees (refs/heads/, refs/ and top-level), and then finally doing the compare-and-swap of that single loose ref? Yes, except that when you update packed-refs, you have to write out the _entire_ file, whereas with this scheme you only have to write out the part of the refs hierarchy you actually touched (e.g. rewriting refs/heads/foo would not have to write out anything inside refs/tags/*). If you have small number of branches, and a huge number of tags, this scheme might end up being cheaper than writing the entire packed-refs. But in general, it's probably much more expensive to go via the odb. You may guarantee atomicity but it is the same granularity of atomicity as a single packed-refs file. Yes, as I argued elsewhere in this thread: It seems that _any_ filesystem-based solution must resort to having all updates depend on a single file in order to guarantee atomicity. When you are updating a branch while somebody else is updating a tag, of course you do not have to look at refs/tags/ in your operation and you can write out your final packed-refs equivalent tree to the object database without racing with the other process, but the top-level you come up with and the top-level the other process comes up with (which has an up-to-date refs/tags/ part, but has a stale refs/heads/ part from your point of view) have to race to update that single loose ref, and one of you have to back out. True. That backing out can be made more intelligently than just dying with compare and swap failed--please retry message, e.g. you at that point notice what you started with, what the other party did while you were working on (i.e. updating refs/tags/), and three-way merge the refs tree, and in cases where all refs recorded as loose refs scheme wouldn't have resulted in problematic conflict, such a three-way merge would resolve trivially (you updated refs/heads/ and the update by the other process to refs/tags/ would not conflict with what you did). But the same three-way merge scheme can be employed with the current flat single packed-refs scheme, can't it? Yes. (albeit without reusing the machinery we already have for doing three-way merges) Even worse, what is the cost of looking up the value of a single branch? You would need to open a few tree objects and the leaf blob that records the object name the ref points at, wouldn't you? Yes. Probably a showstopper, although single branch/ref lookup might not be so common on server side, as it is on the user side. Right now, such a look-up is either opening a single small file and reading the first 41 bytes off of it, and falling back (when the ref in question is packed) to read a single packed-refs file and finding the ref you want from it. So... Yep... ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/17] Remove assumptions about refname lifetimes
On Mon, May 20, 2013 at 6:59 PM, Jeff King p...@peff.net wrote: On Mon, May 20, 2013 at 09:37:30AM -0700, Junio C Hamano wrote: Johan Herland jo...@herland.net writes: For server-class installations we need ref storage that can be read (and updated?) atomically, and the current system of loose + packed files won't work since reading (and updating) more than a single file is not an atomic operation. Trivially, one could resolve this by dropping loose refs, and always using a single packed-refs file, but that would make it prohibitively expensive to update refs (the entire packed-refs file must be rewritten for every update). Now, observe that we don't have these race conditions in the object database, because it is an add-only immutable data store. What if we stored the refs as a tree object in the object database, referenced by a single (loose) ref? What is the cost of updating a single branch with that scheme? Yeah, I had the same thoughts as you here; I don't think this is really much better than updating a single packed-refs file. You may only have to touch log(N) of the entries to update the trees along the path to your ref (assuming you have a bushy refs/ tree; in practice, of course, you have a lot of entries in refs/heads/, so you do not quite get log behavior). So algorithmically it may be slightly better, but you pay a much higher constant, in that you are creating many tree objects along the path (and reading them on lookup). True. But more importantly, it introduces contention between two unrelated refs that are being updated. Even if we reconcile the differences automatically (e.g., with a merge-and-retry strategy), that is going to be a serious performance regression for a busy repository, as we repeatedly try to reconcile the serialized updates to the refs/ root tree. Any transactional solution needs to have the equivalent of ref-level locking (i.e., row-level locking in a relational setting). It is OK for two simultaneous updates to different rows to happen in random order; we don't care about that level of atomicity. The important thing is that the _readers_ see transactions in consistent order; if we know that update B started after update A finished, then we must never see update A without update B reflected. And I think that is more or less a solved problem in the database world. That is what prevents: git update-ref A B git update-ref -d B from creating a view where the reader sees neither A nor B (which is what can happen with the current filesystem view). All true. Just a last spasm from the dying notion that we could solve this in the filesystem, without using proper database... ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- 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: Storing refs in the odb
Johan Herland jo...@herland.net writes: Of course in either case we couldn't use a tree object directly, because these new reference tree objects would refer not only to blobs and other trees but also to commits and tags. Indeed. I don't know if the best solution would be to actually _allow_ that (which would complicate the object parsing code somewhat; a tree entry pointing to a commit is usually interpreted as a submodule, but that is not what we'd want for the ref tree, and a tree entry pointing at a tag has AFAIK not yet been done), or whether it means we need to come up with a different kind of structure. You can disallow that only by giving up on being able to express Linus's kernel repository, which has an oddball v2.6.11-tree tag. I do not think that that particular tag in the particular repository is too big a show-stopper; if it is only Linus, we can ask him to drop that tag (he has v2.6.11 tag object that points at the tree, so the users do not lose anything) and be done with it. But if there are other repositories that tag trees in a similar way, that would be a real regression. We cannot just go ask people to change their workflow that depended on using refs that directly point at trees overnight. -- 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: Storing refs in the odb
On Mon, May 20, 2013 at 7:21 PM, Junio C Hamano gits...@pobox.com wrote: Johan Herland jo...@herland.net writes: Of course in either case we couldn't use a tree object directly, because these new reference tree objects would refer not only to blobs and other trees but also to commits and tags. Indeed. I don't know if the best solution would be to actually _allow_ that (which would complicate the object parsing code somewhat; a tree entry pointing to a commit is usually interpreted as a submodule, but that is not what we'd want for the ref tree, and a tree entry pointing at a tag has AFAIK not yet been done), or whether it means we need to come up with a different kind of structure. You can disallow that only by giving up on being able to express Linus's kernel repository, which has an oddball v2.6.11-tree tag. I do not think that that particular tag in the particular repository is too big a show-stopper; if it is only Linus, we can ask him to drop that tag (he has v2.6.11 tag object that points at the tree, so the users do not lose anything) and be done with it. But if there are other repositories that tag trees in a similar way, that would be a real regression. We cannot just go ask people to change their workflow that depended on using refs that directly point at trees overnight. I wasn't considering disallowing _anything_, rather open up to the idea that a tree object might refer to tag objects as well as commits/trees/blobs. E.g. in my suggested-but-pretty-much-retracted scheme, I was considering whether the tree entry at the virtual path refs/tags/v1.0 should look like this: 100644 blob 123456... v1.0 where the blob at 123456... contains the object id of the v1.0 tag object, or whether we should allow the crazyness that is: ?? tag 987654... v1.0 Just a thought experiment... ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/2] config doc: add dot-repository note
Jonathan Nieder jrnie...@gmail.com writes:
Philip Oakley wrote:
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -734,6 +734,8 @@ branch.name.remote::
overridden by `branch.name.pushremote`. If no remote is
configured, or if you are not on any branch, it defaults to
`origin` for fetching and `remote.pushdefault` for pushing.
+Additionally, a `.` (period) means the current local repository
+(a dot-repository), see `branch.name.merge`'s final note below.
Does this accept an arbitrary git URL, or only remote names?
The branch.name.remote variable refers to remote names, and '.'
often appears as a special name to refer to the local repository.
I think you can define it as URL and your git fetch (no args) will
do the right thing in that it would:
(1) fetch the history leading to the tip branch.name.merge branch
from there; and
(2) leave the result in FETCH_HEAD, so that git merge FETCH_HEAD
can conclude the git pull you split into two manually by
running git fetch first,
but I do not think there is a while we create this branch side
effect UI like --set-upstream-to for doing so, except for setting
it to '.' when you set upstream to a branch in the local repository.
I.e.
git checkout -t -b mywork master
git branch --set-upstream-to master mywork
Also I think setting it to arbitrary URL would mean that you would
not see any remote tracking ref (they are to be defined as a
property of named remote with remote.name.fetch refspecs), so it
is unclear how @{u} would work. @{u} works when the variable is set
to '.', though.
For the above reasons, describing '.' as a special value for the
variable that the end users are likely to see is a reasonable white
lie for this part of the documentation.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Jonathan Nieder jrnie...@gmail.com writes: --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -59,6 +59,10 @@ working tree. After running `git add hello.c; rm hello.c`, you will _not_ see `hello.c` in your working tree with the former, but with the latter you will. +Just as, by convention, the filesystem '.' refers to the current directory, +using a '.' (period) as a repository name in Git (a dot-repository) refers +to your local repository. Good idea, but I fear that no one would find it there. Also I think it would be better without , by convention,. If you say '.' == current directory is a convention, you have to start saying that by convention, hello.c refers to the file in the current directory of that name, which may be technically correct but make the phrase by convention meaningless. A dot . is *the* name for the current directory, just like hello.c is the name for that file. Just like '.' refers to the current directory in the filesystem, '.' refers to the current repository. would be sufficient. Would it make sense to put this in Documentation/urls.txt (aka the GIT URLS section of git-fetch(1) and git-clone(1)), where other URL schemes are documented? Yes, the '.' described above is a special case of giving a repository URL as a relative-path on the filesystem. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/17] Remove assumptions about refname lifetimes
Jeff King p...@peff.net writes: But more importantly, it introduces contention between two unrelated refs that are being updated. Even if we reconcile the differences automatically (e.g., with a merge-and-retry strategy), that is going to be a serious performance regression for a busy repository, as we repeatedly try to reconcile the serialized updates to the refs/ root tree. I think we are on the same page. Any transactional solution needs to have the equivalent of ref-level locking (i.e., row-level locking in a relational setting). Not necessarily if we can exploit assumptions such as deletion is far rare compared to update and creation which in turn are far rare compared to lookup. I've been wondering if we can find a cheap reader-writer lock mechanism, use a single instance of it to govern the whole repository, and have everybody but ref deleters and git pack-ref take the read side of the lock. Then only while ref deletion or ref packing is going on, everybody need to stall, but otherwise the most common read or update recently touched refs (aka loose refs) will be taking the reader side of that cheap read-write lock and reading a single loose ref file. Perhaps such a cheap on reader side reader-write lock is hard to come by? -- 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] remote-hg: set stdout to binary mode on win32
Felipe Contreras felipe.contre...@gmail.com writes: On Sun, May 19, 2013 at 6:53 AM, Felipe Contreras felipe.contre...@gmail.com wrote: From: Amit Bakshi ambak...@gmail.com git clone hangs on windows, and file.write would return errno 22 inside of mercurial's windows.winstdout wrapper class. This patch sets stdout's mode to binary, fixing both issues. Forgot: [fc: cleaned up] Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Thanks, sounds like this is meant for 'master'? -- 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: Storing refs in the odb
Johan Herland jo...@herland.net writes: I wasn't considering disallowing _anything_, rather open up to the idea that a tree object might refer to tag objects as well as commits/trees/blobs. E.g. in my suggested-but-pretty-much-retracted scheme, I was considering whether the tree entry at the virtual path refs/tags/v1.0 should look like this: 100644 blob 123456... v1.0 where the blob at 123456... contains the object id of the v1.0 tag object, or whether we should allow the crazyness that is: ?? tag 987654... v1.0 Just a thought experiment... I was reacting to this part of your earlier message: Of course in either case we couldn't use a tree object directly, because these new reference tree objects would refer not only to blobs and other trees but also to commits and tags. Indeed. I don't know if the best solution would be to actually _allow_ that (which would complicate the object parsing code somewhat; a tree You cannot disambiguate, with the thought-experiment in your message I am responding to, between these two: ?? tree 987654... v2.6.11-tree ?? tree 987654... sub where the former is a light-weight tag for that tree, while the latter is merely a subhierarchy in refs/sub/hier/archy, but if you disallow v2.6.11-tree, and if you know this kind of tree is only to express the ref hierarchy, then everything is unambiguous (a commit is not a submodule but is a ref that points at a commit, a blob is a ref that points at a blob like refs/tags/junio-gpg-pub, and tag is a ref that points at the tag). So it was workable alternative implementation of refs (I am not saying it is an improvement, with the atomicity and performance implications we already discussed), if we did not have to worry about a light-weight tag that directly point at a tree. -- 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: Storing refs in the odb
On Mon, May 20, 2013 at 8:28 PM, Junio C Hamano gits...@pobox.com wrote: Johan Herland jo...@herland.net writes: I wasn't considering disallowing _anything_, rather open up to the idea that a tree object might refer to tag objects as well as commits/trees/blobs. E.g. in my suggested-but-pretty-much-retracted scheme, I was considering whether the tree entry at the virtual path refs/tags/v1.0 should look like this: 100644 blob 123456... v1.0 where the blob at 123456... contains the object id of the v1.0 tag object, or whether we should allow the crazyness that is: ?? tag 987654... v1.0 Just a thought experiment... I was reacting to this part of your earlier message: Of course in either case we couldn't use a tree object directly, because these new reference tree objects would refer not only to blobs and other trees but also to commits and tags. Indeed. I don't know if the best solution would be to actually _allow_ that (which would complicate the object parsing code somewhat; a tree You cannot disambiguate, with the thought-experiment in your message I am responding to, between these two: ?? tree 987654... v2.6.11-tree ?? tree 987654... sub where the former is a light-weight tag for that tree, while the latter is merely a subhierarchy in refs/sub/hier/archy, but if you disallow v2.6.11-tree, and if you know this kind of tree is only to express the ref hierarchy, then everything is unambiguous (a commit is not a submodule but is a ref that points at a commit, a blob is a ref that points at a blob like refs/tags/junio-gpg-pub, and tag is a ref that points at the tag). So it was workable alternative implementation of refs (I am not saying it is an improvement, with the atomicity and performance implications we already discussed), if we did not have to worry about a light-weight tag that directly point at a tree. True, unless we were to abuse the mode bits to differentiate between regular-subtree and ref-to-tree cases... ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- 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 3/6] t5000: factor out check_tar
On Mon, May 20, 2013 at 5:58 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Create a helper function that extracts a tar archive and checks its
contents, modelled after check_zip in t5003.
Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx
---
t/t5000-tar-tree.sh | 35 ++-
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 41cd609..8337a1f 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -30,6 +30,26 @@ GUNZIP=${GUNZIP:-gzip -d}
SUBSTFORMAT=%H%n
+check_tar() {
+ tarfile=$1.tar
+ listfile=$1.lst
+ dir=$1
+ dir_with_prefix=$dir/$2
+
+ test_expect_success ' extract tar archive' '
s/' extract/'extract/
+ (mkdir $dir cd $dir $TAR xf -) $tarfile
+ '
+
+ test_expect_success ' validate filenames' '
s/' validate/'validate/
+ (cd ${dir_with_prefix}a find .) | sort $listfile
+ test_cmp a.lst $listfile
+ '
+
+ test_expect_success ' validate file contents' '
s/' validate/'validate/
+ diff -r a ${dir_with_prefix}a
+ '
+}
+
test_expect_success \
'populate workdir' \
'mkdir a
@@ -81,6 +101,8 @@ test_expect_success \
'git archive' \
'git archive HEAD b.tar'
+check_tar b
+
test_expect_success \
'git tar-tree' \
'git tar-tree HEAD b2.tar'
@@ -125,19 +147,6 @@ test_expect_success \
test_cmp .git/$(git symbolic-ref HEAD) b.commitid'
test_expect_success \
-'extract tar archive' \
-'(mkdir b cd b $TAR xf -) b.tar'
-
-test_expect_success \
-'validate filenames' \
-'(cd b/a find .) | sort b.lst
- test_cmp a.lst b.lst'
-
-test_expect_success \
-'validate file contents' \
-'diff -r a b/a'
-
-test_expect_success \
'git tar-tree with prefix' \
'git tar-tree HEAD prefix c.tar'
--
1.8.2.3
--
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
--
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 3/6] t5000: factor out check_tar
Am 20.05.2013 21:54, schrieb Eric Sunshine:
On Mon, May 20, 2013 at 5:58 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
+check_tar() {
+ tarfile=$1.tar
+ listfile=$1.lst
+ dir=$1
+ dir_with_prefix=$dir/$2
+
+ test_expect_success ' extract tar archive' '
s/' extract/'extract/
It might be a bit hackish, but I added that single space here and in the
three other cases intentionally in order to designate sub-tests.
René
--
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] contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash
Use /bin/sh interpreter instead of /bin/bash for contrib/git-subtree: it's required for systems which don't use bash by default (for example, FreeBSD), while there seem to be no bashisms in the script (confirmed by looking through the source and tesing subtree functionality with FreeBSD's /bin/sh) to require specifically bash and not the generic posix shell. Signed-off-by: Dmitry Marakasov amd...@amdmi3.ru --- contrib/subtree/git-subtree.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index 8a23f58..5701376 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -1,4 +1,4 @@ -#!/bin/bash +#!/bin/sh # # git-subtree.sh: split/join git repositories in subdirectories of this one # -- 1.8.2.3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/2] config doc: add dot-repository note
From: Junio C Hamano gits...@pobox.com
Sent: Monday, May 20, 2013 6:50 PM
Jonathan Nieder jrnie...@gmail.com writes:
Philip Oakley wrote:
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -734,6 +734,8 @@ branch.name.remote::
overridden by `branch.name.pushremote`. If no remote is
configured, or if you are not on any branch, it defaults to
`origin` for fetching and `remote.pushdefault` for pushing.
+ Additionally, a `.` (period) means the current local repository
+ (a dot-repository), see `branch.name.merge`'s final note below.
Does this accept an arbitrary git URL, or only remote names?
The branch.name.remote variable refers to remote names, and '.'
often appears as a special name to refer to the local repository.
Initially I thought that the '.' wasn't going to be acceptable as a URL,
and that the '.' would only apply to the defined name of the remote
within the branch section.
I think you can define it as URL and your git fetch (no args) will
do the right thing in that it would:
(1) fetch the history leading to the tip branch.name.merge branch
from there; and
(2) leave the result in FETCH_HEAD, so that git merge FETCH_HEAD
can conclude the git pull you split into two manually by
running git fetch first,
but I do not think there is a while we create this branch side
effect UI like --set-upstream-to for doing so, except for setting
it to '.' when you set upstream to a branch in the local repository.
I.e.
git checkout -t -b mywork master
git branch --set-upstream-to master mywork
Also I think setting it to arbitrary URL would mean that you would
not see any remote tracking ref (they are to be defined as a
property of named remote with remote.name.fetch refspecs), so it
is unclear how @{u} would work. @{u} works when the variable is set
to '.', though.
For the above reasons, describing '.' as a special value for the
variable that the end users are likely to see is a reasonable white
lie for this part of the documentation.
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: [RFC 16/17] object_array_entry: copy name before storing in name field
On 05/20/2013 06:44 PM, Jeff King wrote: On Mon, May 20, 2013 at 04:42:38PM +0200, Michael Haggerty wrote: * Many callers store the empty string () as the name; for example, most of the entries created during a run of rev-list have as their name. This means that lots of needless copies of are being made. I think that the best solution to this problem would be to store NULL rather than for such entries, but I haven't figured out all of the places where the name is used. Use strbufs? No allocation (except for the strbuf object itself) is needed for empty strings, and string ownership and be transferred to and from it to prevent extra copies. That would cost two extra size_t per object_array_entry. I have the feeling that this structure is used often enough that the extra overhead would be a disadvantage, but I'm not sure. The obvious alternative would be to teach users to deal with NULL and either add another constructor alternative that transfers string ownership or *always* transfer string ownership and change the callers to call xstrdup() if they don't already own the name string. I think I will try that approach first. You could use the same trick that strbuf does: instead of NULL, point to a well-known empty string literal. Readers do not have to care about this optimization at all; only writers need to recognize the well-known pointer value. And since we do not update in place but only eventually free, it really is just that anyone calling free() would do if (name != well_known_empty_string). Yes, that sounds like the best solution. Ultimately there is only one writer, add_object_array_with_mode(), and it can do if (!name) entry-name = NULL; else if (!*name) entry-name = well_known_empty_string; else entry-name = xstrdup(name); This should be a lot less intrusive than what I was trying: to change callers who wrote name= to write name=NULL instead. But it is a nightmare to find all of the code that reads name and decide whether they need to do entry-name ? entry-name : because that in turn depends on whether the code that wrote into the same object_array always/never/sometimes wrote strings vs. NULL to the name field. Blech, encapsulation is tough in C. While I was chasing down callers, I came across other gems like builtin/checkout.c: add_pending_object(revs, object, sha1_to_hex(object-sha1)); revision.c: add_pending_object(revs, object, sha1_to_hex(object-sha1)); submodule.c: add_pending_object(rev, list-item-object, sha1_to_hex(list-item-object.sha1)); so apparently I wasn't the only one befuddled by the lifetime and ownership of the name field of object_array_entry. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/2] Doc rebase: Describe rebase as excluding merge commits
From: Junio C Hamano gits...@pobox.com Sent: Monday, May 20, 2013 5:43 AM Jonathan Nieder jrnie...@gmail.com writes: Philip Oakley wrote: Describe rebase in the description section. It already does that. :) I think you mean start with a summary, which is a valuable improvement. It indeed is a good idea to give the high-level introduction at the very beginning, but I do not think it should describe only one of the three major modes of git rebase (i.e. no -m, no -i), like the proposed patch text does. We should instead say what it is used for and why the user would want to use it that is common across these modes at a very high level. That would repeat the NAME issue (of trying too hard to be exact precise). This introductory text is that summary. The patch 2/2 should be the one for the extra detail of the various whys and wherefores - at least that was my intent. DESCRIPTION --- brief description of the purpose of the command, including some token mention of *why* a user would want to use it (e.g., so that the patches apply cleanly to their new base). Exactly. -- -- 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] git-svn: introduce --parents parameter for commands branch and tag
Tobias Schulte tobias.schu...@gliderpilot.de wrote: This parameter is equivalent to the parameter --parents on svn cp commands and is useful for non-standard repository layouts. Signed-off-by: Tobias Schulte tobias.schu...@gliderpilot.de Signed-off-by: Eric Wong normalper...@yhbt.net Applied and pushed, 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: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Philip Oakley philipoak...@iee.org writes:
So we can have a branch whose remote is '.'
_and_ a remote whose URL is '.'
Yes, and they are two separate concepts.
git fetch while on mywork branch with this:
[branch mywork]
remote = git://git.k.org/pub/scm/git/git.git
merge = refs/heads/master
without having any named remote whose remote.$name.url is set to
that URL may happen to work but it is by accident as far as I know.
As you do not copy to any remote tracking branches, @{u} would not
work, so it is not something useful. But on the other hand
[branch mywork]
remote = .
merge = refs/heads/master
works _as if_ you have
[remote .]
url = .
;; no fetch refspec like +refs/heads/*:refs/heads/*
;; no push refspec like +refs/heads/*:refs/heads/*
so in that sense, you _could_ think of branch.$name.remote as a
(generic) URL or a name of a (special) remote, but it is easier to
think about it as the latter.
And remote.$name.url = . for any name, e.g.
[remote here]
url = .
is a special case of local repository that is named with a relative
filesystem path.
Can there be a clash with a named remote that is actually '.', where
the push/fetch is actually a no-op?
Nobody sane would do it in the first place, so...
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/2] Doc rebase: Describe rebase as excluding merge commits
Philip Oakley philipoak...@iee.org writes: From: Junio C Hamano gits...@pobox.com Sent: Monday, May 20, 2013 5:43 AM Jonathan Nieder jrnie...@gmail.com writes: Philip Oakley wrote: Describe rebase in the description section. It already does that. :) I think you mean start with a summary, which is a valuable improvement. It indeed is a good idea to give the high-level introduction at the very beginning, but I do not think it should describe only one of the three major modes of git rebase (i.e. no -m, no -i), like the proposed patch text does. We should instead say what it is used for and why the user would want to use it that is common across these modes at a very high level. That would repeat the NAME issue (of trying too hard to be exact precise). This introductory text is that summary. If that is summary, it should never talk about skips merges, which only applies to the mode without -m, no? The highest level view of what the command is for (the motivation why the user would want to consider learning how to use the command) is You have a history built on top of some commit, and you want to rebuild the history on top of another commit, e.g. you earlier built on the tip of a branch that has some other work, and you want to rebuild the history on top of the updated tip of that other branch. The details of how the history is rebuilt can differ while using various modes of operation. Some may skip merges, some may try to preserve the topology, some may even let you insert new commits by letting you tell it to stop in the middle. That is not summary but is part of mode specific description. -- 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] contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash
Dmitry Marakasov amd...@amdmi3.ru writes: Use /bin/sh interpreter instead of /bin/bash for contrib/git-subtree: it's required for systems which don't use bash by default (for example, FreeBSD), while there seem to be no bashisms in the script (confirmed by looking through the source and tesing subtree functionality with FreeBSD's /bin/sh) to require specifically bash and not the generic posix shell. Has anybody audited to make sure that the script itself is free of bash-isms? I somehow had an impression that in the past it was littered with bash-isms like function local variables and array variables and assumed that the #!/bin/bash was necessary. I did a quick eyeballing and did not see anything glaringly bash-only, but I may have missed something (the coding style is so different from the core part of Git Porcelains and distracting for me to efficiently do a good job of scanning). Signed-off-by: Dmitry Marakasov amd...@amdmi3.ru --- contrib/subtree/git-subtree.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index 8a23f58..5701376 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -1,4 +1,4 @@ -#!/bin/bash +#!/bin/sh # # git-subtree.sh: split/join git repositories in subdirectories of this one # -- 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] git-svn: introduce --parents parameter for commands branch and tag
Eric Wong normalper...@yhbt.net writes: Tobias Schulte tobias.schu...@gliderpilot.de wrote: This parameter is equivalent to the parameter --parents on svn cp commands and is useful for non-standard repository layouts. Signed-off-by: Tobias Schulte tobias.schu...@gliderpilot.de Signed-off-by: Eric Wong normalper...@yhbt.net Applied and pushed, thanks. Thanks; is it a good time for me to pull? -- 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] git-svn: introduce --parents parameter for commands branch and tag
Junio C Hamano gits...@pobox.com wrote: Thanks; is it a good time for me to pull? Yes, I think so. Thanks! The following changes since commit de3a5c6da194928868b5eee4a9c4d538b4194727: Git 1.8.3-rc3 (2013-05-17 12:19:20 -0700) are available in the git repository at: git://git.bogomips.org/git-svn.git master for you to fetch changes up to f4f4c7fc00e8acf91150c717cf005fc36c1dd120: git-svn: introduce --parents parameter for commands branch and tag (2013-05-20 22:05:54 +) Jonathan Nieder (1): git-svn: clarify explanation of --destination argument Nathan Gray (1): git-svn: multiple fetch/branches/tags keys are supported Tobias Schulte (1): git-svn: introduce --parents parameter for commands branch and tag Documentation/git-svn.txt| 36 git-svn.perl | 19 - t/t9167-git-svn-cmd-branch-subproject.sh | 48 3 files changed, 97 insertions(+), 6 deletions(-) create mode 100755 t/t9167-git-svn-cmd-branch-subproject.sh -- Eric Wong -- 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 0/2] remote-helpers: test fixes
Felipe Contreras felipe.contre...@gmail.com writes: Hi, I've setup a project in Travis CI for continuous integration with very good results, however, I had to apply a couple of fixes. I'm not sure if this is v1.8.3 material, but here they are. Thanks; I'll queue them at the tip of fc/remote-hg to graduate soon after 1.8.3, then. https://travis-ci.org/felipec/git/builds/7262886 Felipe Contreras (2): remote-helpers: tests: use python directly remote-hg: tests: fix hg merge contrib/remote-helpers/test-bzr.sh | 2 +- contrib/remote-helpers/test-hg-bidi.sh | 2 +- contrib/remote-helpers/test-hg-hg-git.sh | 11 ++- contrib/remote-helpers/test-hg.sh| 2 +- 4 files changed, 9 insertions(+), 8 deletions(-) -- 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-diff-index man page
Jonathan Nieder jrnie...@gmail.com writes: Thanks and hope that helps, Jonathan Thanks, the result reads much better, I think. Albert? diff --git i/Documentation/git-diff-index.txt w/Documentation/git-diff-index.txt index 58308e15..a86cf62e 100644 --- i/Documentation/git-diff-index.txt +++ w/Documentation/git-diff-index.txt @@ -3,7 +3,7 @@ git-diff-index(1) NAME -git-diff-index - Compare a tree and the working tree or the index +git-diff-index - Compare a tree to the working tree or index SYNOPSIS @@ -13,12 +13,11 @@ SYNOPSIS DESCRIPTION --- - -Compare the content and mode of the blobs found in a tree object -with the corresponding tracked file in the working tree, or with the -corresponding paths in the index. When paths are specified, -compares only those named paths. Otherwise all entries in the index -are compared. +Compares the content and mode of the blobs found in a tree object +with the corresponding tracked files in the working tree, or with the +corresponding paths in the index. When path arguments are present, +compares only paths matching those patterns. Otherwise all tracked +files are compared. OPTIONS --- -- 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 0/6] t5000: add test for pax extended header generation
Thanks, will queue. -- 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 v12 00/15] Interactive git-clean
Will replace what has been queued on 'pu' with trivial style fixups (haven't had a chance to make time to read it through). 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
Workflow Help
Hi, I am looking at formulating and then documenting our vcs workflow using Git at work. I have an idea of how I want things to work, but am a little hazy on some of the details. Our basic workflow will be based around: http://nvie.com/posts/a-successful-git-branching-model, with a few exceptions. We would like to create our release-* branches from the last release tag. From there, we would like the ability to cherry pick (or take the complete diff) commits from the develop branch. So, we are after is: 1) Create topic (feature) branches from develop, and merge back into develop when complete. 2) Once it is decided we are packaging a release, make a release-* branch from the previous release tag. 3) Cherry pick/merge/whatever any commits we want from develop into the new release-* until it is complete. 4) Merge the new release-* branch into master and tag it. Repeat as necessary. At the moment I am a little stuck on how exactly we can cherry pick stuff from develop into a release-* branch. I'm not even sure this approach is exactly what we should be doing. Our main concern is that at this stage, there is no guarantee that all commits within develop can be pulled into a release. In regards to how we can achieve the above results any input would be much appreciated. Or if there are any other better options available, I'm all ears. Thanks, Tony Quilkey -- 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] transport-helper: barf when user tries old:new
Otherwise with certain remote helpers (the ones that support 'export'),
the users will be pushing to the wrong branch:
git push topic:master
Will push the topic branch, as if the user typed:
git push topic
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
I did fix this properly, but was beaten by shoots from the hip[1]. I won't
bother rationalizing if this makes sense for 'master', or writing tests. This
patch can't possibly make anything worst. If somebody is interested, there's
proper fix: [1], with explanation, tests, and everything.
[1] http://article.gmane.org/gmane.comp.version-control.git/223706
transport-helper.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 522d791..a782a9b 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -813,9 +813,11 @@ static int push_refs_with_export(struct transport
*transport,
die(remote-helpers do not support ref deletion);
}
- if (ref-peer_ref)
+ if (ref-peer_ref) {
+ if (strcmp(ref-peer_ref-name, ref-name))
+ die(remote-helpers do not support old:new
syntax);
string_list_append(revlist_args, ref-peer_ref-name);
-
+ }
}
if (get_exporter(transport, exporter, revlist_args))
--
1.8.3.rc3.1.gf572ce5.dirty
--
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
Fw:จับได้ว่า Ambranews ใช้ศาสนาเป็นอาวุธ
จับได้ว่า Ambranews ใช้ศาสนาเป็นอาวุธ
เมื่อต้นเดือนพฤษภาคมที่ผ่านมานี้ เวปไซต์ ambranews จัดตั้งและดำเนินงานอยู่
ในประเทศมาเลเซีย ได้นำเสนอข่าวเป็นภาษามาเลเซียโจมตีการทำงานของเจ้าหน้าที่ไทย
โดยใช้คำว่า คนมาลายู แทนคนไทยมุสลิมในจังหวัดชายแดนภาคใต้ต่อกรณียิงกราด 6
ศพว่าเป็นการกระทำของเจ้าหน้าที่ เพียงเพราะคนร้ายสวมกางเกงลายพรางแบบที่ทหาร
ใช้กันอยู่เท่านั้นเอง นอกจากนี้ยังได้เสนอบทความที่สร้างความแตกแยกระหว่างคนไทย
มุสลิมกับคนไทยพุทธว่า งานประเพณีของคนไทยขัดต่อหลักศาสนาอิสลาม โดย
ยกตัวอย่างงานกาชาดว่า ทำให้ คนมาลายู ไม่สบายใจเนื่องจากงานกาชาดมีดนตรีและ
การเต้นรำ มีผู้หญิงนุ่งสั้นขัดต่อหลักศาสนาอิสลาม ในพุทธศาสนาก็เช่นเดียวกัน
เห็นว่า
สถานที่ไม่ควรเข้าใกล้จัดอยู่ในประเภท อโคจร เหมือนกันก็แค่การเตือนสติไม่ได้นำไป
สร้างความแตกแยก เวปไซต์ ambranews นี้ อาศัยศาสนามาโฆษณาชวนเชื่อสร้างความ
แตกแยกให้กับคนไทยด้วยกัน เป้าหมายเดียวคือแบ่งแยกดินแดน จังหวัดชายแดนภาคใต้
ต้องปกครองด้วยหลักการของศาสนาอิสลามเท่านั้น แต่อย่าลืมไปซิว่าประเทศมาเลเซียเอง
ก็มีบ่อนคาสิโนถูกกฎหมาย มีสปาร์ คลับบาร์ มีเหล้ามีไวน์ขาย
ทำไมเวปไซต์นี้ไม่เสนอข่าว
ที่เรื่องเหล่านี้ของมาเลเซียว่าขัดต่อหลักศาสนา
หรือว่าเขาให้คุณกินอยู่แล้วมานั่งด่า
ประเทศไทยตามันมืดมองไม่เห็น
เป็นที่น่าเสียใจเป็นอย่างยิ่งที่ประเทศเป็นตัวกลางในการ
เจรจาแก้ปัญหาภาคใต้อย่างมาเลเซียยังปล่อยให้เวปไซต์นี้ นำเสนอข่าวสร้างความ
แตกแยกของคนไทยด้วยกันต่อไป
Nงฒๆ์rธy๚ุ่bฒXฌถวงvุ^)�บ{.nว+ท ุงถก�จ}ฉฒฦ
zฺj:+vจพซ๊็zZ+ส+zfฃขทhง~ญ�i�๛เzน ฎwฅขธ?จ่ญฺข)฿ขf
[PATCH 0/2] remote-hg: fix configuration notes
Hi, For 'master'. Felipe Contreras (2): remote-hg: trivial configuration note cleanup remote-hg: fix order of configuration comments contrib/remote-helpers/git-remote-hg | 8 1 file changed, 4 insertions(+), 4 deletions(-) -- 1.8.3.rc3.1.gf11a2b7.dirty -- 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 2/2] remote-hg: fix order of configuration comments
The other configurations were added in the wrong place. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-helpers/git-remote-hg | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index 88db7c4..198b962 100755 --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -25,9 +25,6 @@ import atexit import urlparse, hashlib # -# If you want to switch to hg-git compatibility mode: -# git config --global remote-hg.hg-git-compat true -# # If you are not in hg-git-compat mode and want to disable the tracking of # named branches: # git config --global remote-hg.track-branches false @@ -38,6 +35,9 @@ import urlparse, hashlib # If you want the equivalent of hg's clone/pull--insecure option: # git config --global remote-hg.insecure true # +# If you want to switch to hg-git compatibility mode: +# git config --global remote-hg.hg-git-compat true +# # git: # Sensible defaults for git. # hg bookmarks are exported as git branches, hg branches are prefixed -- 1.8.3.rc3.1.gf11a2b7.dirty -- 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
Contributing to git: cleaner git -rm add configuration options
Hello everyone, I'm Mathieu LIENARD--MAYOR, a french student at Ensimag - Grenoble INP, and together with my fellow student Jorge GARCIA we will try to contribute to git as our school project. As of now, we are considering the implementation of the following two features: -Cleaner error message when git rm fails with multiple files (https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#Cleaner_error_message_when_.22git_rm.22_fails_with_multiple_files) -Add configuration options for some commonly used command-line options (https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#Add_configuration_options_for_some_commonly_used_command-line_options) Please let us know if you think those features are interesting choices, or if you have some ideas about how we should do it, or even if you have any comment at all. Best regards, Mathieu LIENARD--MAYOR Jorge GARCIA -- 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
