* t9350-fast-export.sh broken on peff/pu under Mac OS X
From: Torsten Bögershausen @ 2012-11-10 14:37 UTC (permalink / raw)
To: felipe.contreras, Git Mailing List; +Cc: Torsten Bögershausen
The short version:
echo -n doesn't seem to be portable.
The following works for me:
(And is this a typo: test_expect_success 'test biridectionality' ')
/Torsten
diff ../../git.peff/t/t9350-fast-export.sh t9350-fast-export.sh
444,445c444,445
< echo -n > marks-cur &&
< echo -n > marks-new &&
---
> > marks-cur &&
> > marks-new &&
464c464
< echo -n > tmp-marks &&
---
> > tmp-marks &&
474c474
< echo -n > expected &&
---
> > expected &&
^ permalink raw reply
* t5801-remote-helpers.sh fails
From: Torsten Bögershausen @ 2012-11-10 13:48 UTC (permalink / raw)
To: felipe.contreras, Git Mailing List; +Cc: Torsten Bögershausen
Hej,
on peff/pu t5801 fails, the error is in git-remote-testgit, please see below.
That's on my Mac OS X box.
I haven't digged further into the test case, but it looks as if
"[-+]A make NAMEs associative arrays"
is not supported on this version of bash.
/Torsten
/Users/tb/projects/git/git.peff/git-remote-testgit: line 64: declare: -A: invalid option
declare: usage: declare [-afFirtx] [-p] [name[=value] ...]
/Users/tb/projects/git/git.peff/git-remote-testgit: line 66: refs/heads/master: division by 0 (error token is "/master")
error: fast-export died of signal 13
fatal: Error while running fast-export
^ permalink raw reply
* Re: Workflow for templates?
From: Philip Oakley @ 2012-11-10 13:44 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Git List, Josef Wolf
In-Reply-To: <7f1bbe94-b3f6-4728-960d-19e89e8e4166@zcs>
From: "Enrico Weigelt" <enrico.weigelt@vnc.biz> Sent: Saturday, November
10, 2012 10:29 AM
>> This is often the key point that requires the 'new mindset'. Most
>> folk
>> use/used the directory heirarchy (subtle distinction with the .git
>> 'repo' directory heirarchy to be noted) as a way of separating
>> ownership
>> between groups. They find it very hard to undo the old mindset and
>> use
>> branches _instead of_ directories for the different group
>> configurations.
>
> hmm, is this really a psychological issue ?
Oh absolutely. It is very very hard to unlearn stuff, especially bad
habits that have had to become ingrained to make them work adequately!
It's like re-learning an alternative to a well loved mnemonic. "CLAP".
>
> well, many years ago, i've seen a talk about git (maybe by linus
> himself),
> which started with something like "forget everything you know abozt
> scm" ...
Most folk don't know why the old way used to be right, and is now so
wrong, so they can't rationalize the change. Hence find the change very
difficult.
[Other than git..] Current SCM methods were established before the
Titanic sank and are based on drawing office practice, and were
transfered and applied to code printouts (which are simply machining
instructions to a compiler). The modern zero cost replication of
"Master" drawings/code printouts has destroyed the original reasons for
the old practices (protect the aluable unique master). Similarly the new
paradigm of "how can I verify that this is a proper copy of the master"
isn't understood.
Definately a psychological issue when your whole world is being turned
upside down ;-)
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: SZEDER Gábor @ 2012-11-10 12:32 UTC (permalink / raw)
To: Jeff King; +Cc: Felipe Contreras, git, Sverre Rabbelier
In-Reply-To: <20121110003331.GA12567@sigill.intra.peff.net>
Hi,
On Fri, Nov 09, 2012 at 07:33:31PM -0500, Jeff King wrote:
> On Sat, Nov 10, 2012 at 12:21:48AM +0100, Felipe Contreras wrote:
> > > * fc/completion-test-simplification (2012-10-29) 2 commits
> > > - completion: simplify __gitcomp test helper
> > > - completion: refactor __gitcomp related tests
> > >
> > > Clean up completion tests.
> > >
> > > There were some comments on the list.
> > >
> > > Expecting a re-roll.
> >
> > The second patch I can re-roll, but the first patch needs some
> > external input. My preference is that tests should also be simple and
> > maintainable, SZEDER's preference is that tests are better being
> > explicit and verbose (even if harder to maintain) to minimize possible
> > issues in the tests.
>
> I think it is better to keep the tests simple and maintainable.
Maintainable? There is nothing to maintain here. Users' completion
scripts depend on __gitcomp(), so its behavior shouldn't be changed.
It can only be extended by a fifth parameter or by quoting words when
necessary, but these future changes must not alter the current
behavior checked by these tests, therefore even then these tests must
be left intact.
Simple? Currently you only need to look at __gitcomp() and the test
itself to understand what's going on. With this series you'll also
need to look at test_gitcomp(), figure out what its parameters are
supposed to mean, and possibly get puzzled on the way why __gitcomp()
is now seemingly called with only one parameter.
So, I don't see much benefit in this series (except the part to use
print_comp instead of "change IFS && echo", but that's already done in
this patch:
http://article.gmane.org/gmane.comp.version-control.git/207927).
OTOH, this series has some serious drawbacks.
It makes debugging more difficult. While working on the quoting
issues I managed to break completion tests many-many times lately. In
normal tests I could add a few debugging instructions to the failed
test to find out where the breakage lies, without affecting other
tests. However, if the failed test uses the test_completion() helper,
then I have to add debugging instructions to test_completion() itself,
too. This is bad, because many tests use this helper function and are
therefore affected by the debugging instructions, producing truckloads
of output making it difficult to dig out the relevant parts, or, worse
yet, causing breakages in other tests. With this series the same
difficulties will come to __gitcomp() tests, too.
It can also encourage writing bad tests, similar to those that managed
to cram many test_completion() lines into a single tests, giving me
headaches to figure out what went wrong this time.
Best,
Gábor
^ permalink raw reply
* Re: Bizarre problem cloning repo from Codeplex
From: John Szakmeister @ 2012-11-10 12:15 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Jeremy Morton, git
In-Reply-To: <6c843260-6190-469a-aa53-243ac440b0fd@zcs>
On Sat, Nov 10, 2012 at 2:49 AM, Enrico Weigelt <enrico.weigelt@vnc.biz> wrote:
[snip]
> Their webserver seems to be configured quite restrictively
> (eg. cannot access files like 'packed-refs').
>
> Is there a way to trace the actual HTTP calls ?
Try GIT_CURL_VERBOSE=1. GIT_TRACE_PACKET=1 can be helpful too.
-John
PS Sorry for the duplicate. I meant to respond to the list as well.
^ permalink raw reply
* git-status: Use "-sb" options by default?
From: Jason Timrod @ 2012-11-10 11:04 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
I've been rooting around the "git-config" man page as well as the "git-status" man page, but couldn't find the following, which suggests it's not (yet) possible.
I'm looking for a way to make the "-sb" options to git-status the default somehow. That is, I would like the short form of git-status to be the default when typing in "git status". I appreciate I am able to do this in an indirect way using aliases, but this is slightly suboptimal for me.
If this isn't possible directly, would someone mind considering this a feature request?
Out of interest, would this be done via the git-config system, most likely?
Thanks kindly,
Jason
^ permalink raw reply
* Re: [PATCH] cache-tree: invalidate i-t-a paths after writing trees
From: Nguyen Thai Ngoc Duy @ 2012-11-10 11:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Jonathon Mah
In-Reply-To: <7vy5ibouo4.fsf@alter.siamese.dyndns.org>
On Fri, Nov 9, 2012 at 6:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> diff --git a/cache-tree.c b/cache-tree.c
>> index 28ed657..30a8018 100644
>> --- a/cache-tree.c
>> +++ b/cache-tree.c
>> @@ -381,6 +381,9 @@ int cache_tree_update(struct cache_tree *it,
>> i = update_one(it, cache, entries, "", 0, flags);
>> if (i < 0)
>> return i;
>> + for (i = 0; i < entries; i++)
>> + if (cache[i]->ce_flags & CE_INTENT_TO_ADD)
>> + cache_tree_invalidate_path(it, cache[i]->name);
>> return 0;
>> }
>
> I notice there is another special case for CE_REMOVE but there is
> nothing that adjusts the cache-tree for these entries in the current
> codebase.
>
> I suspect the original code before we (perhaps incorrectly) updated
> the code not to error out upon I-T-A entries was fine only because
> we do not attempt to fully populate the cache-tree during a merge in
> the unpack-trees codepath, which will mark the index entries that
> are to be removed with CE_REMOVE in the resulting index.
>
> The solution implemented with this patch will break if we start
> updating the cache tree after a successful merge in unpack-trees, I
> suspect.
I don't understand. I thought we handled CE_REMOVE correctly (i.e. no
CE_REMOVE entries in cache tree even after a successful merge). Or
should we keep CE_REMOVE in cache tree after a successful merge?
> An alternative might be to add a "phoney" bit next to "used" in the
> cache_tree structure, mark the cache tree as phoney when we skip an
> entry marked as CE_REMOVE or CE_ITA, and make the postprocessing
> loop this patch adds aware of that bit, instead of iterating over
> the index entries; instead, it would recurse the resulting cache
> tree and invalidate parts of the tree that have subtrees with the
> "phoney" bit set, or something.
Yeah, that sounds better.
--
Duy
^ permalink raw reply
* Re: bare vs non-bare <1.7 then >=1.7 ?
From: Philip Oakley @ 2012-11-10 10:37 UTC (permalink / raw)
To: Enrico Weigelt, Mihamina Rakotomandimby; +Cc: Git Issues
In-Reply-To: <e4dc73e8-69f9-4695-b8f7-cbc0f04e8197@zcs>
From: "Enrico Weigelt" <enrico.weigelt@vnc.biz> Sent: Saturday, November
10, 2012 8:23 AM
> Wait, there *is* an usecase for such things, deploying trees (eg.
> webapps)
> some server:
>
> * application is developed in git
> * the final production-system tree is maintained in certian branch
> * a post-update hook acts on a specific production branch and does
> something like git checkout --detach <treeish>
>
I have an alternative use-case for un-trained collegues :
The network shared drive has master checked out, and the .git directory
is hidden. Untrained colleagues don't know I have it as a git remote.
Even if they show hidden directories they will tend to ignore it as
being just another spurious directory.
I develop on my own box (local directory) on my own branch 'Philip' and
features therefrom. I push my development history back to the network
remote to act as a backup. Because I don't touch master I can normally
push to it quite happily.
When I have some finished work I can change to 'working' on the network
drive, and merge or rebase my 'Philip' branch into master, and update
the network's working tree. The untrained folk now see the new updated
files as if I'd simply worked on / copied into the network share and
they are non the wiser (yet) that I do have proper (micro managed)
history.
I can also capture any changes they made to the network share so can go
back to a point in history when required. It's in matlab and is not a
big code base.
Philip
^ permalink raw reply
* Re: Workflow for templates?
From: Enrico Weigelt @ 2012-11-10 10:29 UTC (permalink / raw)
To: Philip Oakley; +Cc: Git List, Josef Wolf
In-Reply-To: <F9FF8107FA8F4CBD8C3D87B907BAE9E3@PhilipOakley>
> This is often the key point that requires the 'new mindset'. Most
> folk
> use/used the directory heirarchy (subtle distinction with the .git
> 'repo' directory heirarchy to be noted) as a way of separating
> ownership
> between groups. They find it very hard to undo the old mindset and
> use
> branches _instead of_ directories for the different group
> configurations.
hmm, is this really a psychological issue ?
well, many years ago, i've seen a talk about git (maybe by linus himself),
which started with something like "forget everything you know abozt scm" ...
> > By the way: you really should use non-conflicting tag names (eg.
> > adding some <site>+"/" or <site>+"-" prefix), otherwise you'll
> > easiy run into conflicts, because per default retrieved and local
> > tags will all be in some namespace
> > Better consider tag names to be really global.
>
> Definitely.
Well, you *could* setup special fetch rules, which put tags from separate
repos to separate namespaces, but i'd really advice against that, as it's
too easy to forget something and again mess it up.
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* Re: Workflow for templates?
From: Philip Oakley @ 2012-11-10 9:56 UTC (permalink / raw)
To: Enrico Weigelt, Josef Wolf; +Cc: Git List
In-Reply-To: <bbc40624-f95d-48c9-83ed-fd70430226a4@zcs>
From: "Enrico Weigelt" <enrico.weigelt@vnc.biz> Sent: Saturday, November
10, 2012 7:13 AM
I've picked out Enrico's key points.
>> Maybe I should try to explain the problem in terms of repository
>> hierarchy. Let's assume, there is this hierarchy of repositories:
>
> Let's talk about branches instead - repos are just containers for
> branches (and tags, etc).
This is often the key point that requires the 'new mindset'. Most folk
use/used the directory heirarchy (subtle distinction with the .git
'repo' directory heirarchy to be noted) as a way of separating ownership
between groups. They find it very hard to undo the old mindset and use
branches _instead of_ directories for the different group
configurations.
Teaching git is easy. Undoing the old mindset is hard hard hard. [it's
still hard]
> By the way: you really should use non-conflicting tag names (eg.
> adding some <site>+"/" or <site>+"-" prefix), otherwise you'll
> easiy run into conflicts, because per default retrieved and local
> tags will all be in some namespace
> Better consider tag names to be really global.
Definitely.
Apologies if it's a bit of bike-shedding.
Philip
^ permalink raw reply
* git-reset man page
From: Angelo Borsotti @ 2012-11-10 9:55 UTC (permalink / raw)
To: git
Hi
the man page of git-reset, synopsys, does not allow for an
argumentless call, and the description does not tell either what is
the meaning of it.
Suggested changes:
first line of synopsis:
gitt reset [-q] [<commit>] [ [--] <pathspec> ...]
Description: append to the end of the first paragraph:
"If no <pathspecs> are specified, all the index entries are reset."
I would suggest to change <paths> with <pathspec> in all the man page
because paths in the glossary are called pathspecs.
-Angelo Borsotti
^ permalink raw reply
* Re: Support for a series of patches, i.e. patchset or changeset?
From: Eric Miao @ 2012-11-10 9:08 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Michael J Gruber, git, Jeff King
In-Reply-To: <6df0df49-afb9-4faf-9a2d-6f397f3a167a@zcs>
Yeah, that's a very clean way I'd always want to follow, yet the
kernel upstream isn't doing so.
On Sat, Nov 10, 2012 at 4:52 PM, Enrico Weigelt <enrico.weigelt@vnc.biz> wrote:
> <snip>
>
> yet another idea:
>
> you coud always put your patchsets into separate branches,
> rebase them ontop target branch before merging, and then
> do an non-ff-merge, which will make the history look like:
>
> * merged origin/feature_foo
> |\
> | * first preparation fo feature foo
> | * part a
> | * part b
> |/
> * merged origin/bugfix_blah
> |\
> | * fixing bug blah
> |/
> *
>
>
> cu
> --
> Mit freundlichen Grüßen / Kind regards
>
> Enrico Weigelt
> VNC - Virtual Network Consult GmbH
> Head Of Development
>
> Pariser Platz 4a, D-10117 Berlin
> Tel.: +49 (30) 3464615-20
> Fax: +49 (30) 3464615-59
>
> enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* Re: Support for a series of patches, i.e. patchset or changeset?
From: Enrico Weigelt @ 2012-11-10 8:52 UTC (permalink / raw)
To: Eric Miao; +Cc: Michael J Gruber, git, Jeff King
In-Reply-To: <CAMPhdO8Sy8ZuXyWbvch+fXzbSVdmwC69a-KaLBRBGX8MVGxv_A@mail.gmail.com>
<snip>
yet another idea:
you coud always put your patchsets into separate branches,
rebase them ontop target branch before merging, and then
do an non-ff-merge, which will make the history look like:
* merged origin/feature_foo
|\
| * first preparation fo feature foo
| * part a
| * part b
|/
* merged origin/bugfix_blah
|\
| * fixing bug blah
|/
*
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* Re: bare vs non-bare <1.7 then >=1.7 ?
From: Enrico Weigelt @ 2012-11-10 8:23 UTC (permalink / raw)
To: Mihamina Rakotomandimby; +Cc: Git Issues
In-Reply-To: <509B8552.4080303@rktmb.org>
> When experimenting in order to train some colleagues, I saw that If I
> clone a repository, I couldn't push to it because it was a non-bare
> one.
> Searchin for some explanations, I found this ressource:
> http://www.bitflop.com/document/111
That's just a precaution (technically it's not necessary, just stops
you from doing some dumb things). Suppose the following scenario:
* non-bare repository A, with branch 'master' currently checked out.
* clone B -> somebody's working on branch 'master' (which was forked
from A's master)
* on A, somebody did some local changes
* meanwhile somebody pushes the branch 'master' from B to A
* after that, on A, new commit to 'master'.
Weird things can happen, eg. the changes coming from B completely
reverted by the new commit in A.
Unless nobody pushes to the branch currently checked and later somebody
doing local changes after that, there shouldn't be any real technical
problem. But then, you most likely wont need an worktree anyways.
Wait, there *is* an usecase for such things, deploying trees (eg. webapps)
some server:
* application is developed in git
* the final production-system tree is maintained in certian branch
* a post-update hook acts on a specific production branch and does
something like git checkout --detach <treeish>
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* [PATCH] t9402: sed -i is not portable
From: Torsten Bögershausen @ 2012-11-10 8:01 UTC (permalink / raw)
To: git; +Cc: mmogilvi_git, tboegi
The command line
sed -i -e "s/foo/bar/" filename
works as expected under GNU/Linux:
all "foo" are replaced by "bar" in the file "filename"
sed on other systems like e.g. Mac OS X creates a backup file
called filename-e, because the -i must be followed by a file name.
As the -i is not in POSIX either, avoid it completely
Improve check_end_tree() and check_end_full_tree() to use test_cmp,
and use the && between each line.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
This must be applied on peff/pu
t/t9402-git-cvsserver-refs.sh | 44 ++++++++++++++++++++++---------------------
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/t/t9402-git-cvsserver-refs.sh b/t/t9402-git-cvsserver-refs.sh
index 858ef0f..5138f14 100755
--- a/t/t9402-git-cvsserver-refs.sh
+++ b/t/t9402-git-cvsserver-refs.sh
@@ -28,27 +28,26 @@ check_file() {
}
check_end_tree() {
- sandbox="$1"
- expectCount=$(wc -l < "$WORKDIR/check.list")
- cvsCount=$(find "$sandbox" -name CVS -prune -o -type f -print | wc -l)
- test x"$cvsCount" = x"$expectCount"
- stat=$?
- echo "check_end $sandbox : $stat cvs=$cvsCount expect=$expectCount" \
- >> "$WORKDIR/check.log"
- return $stat
+ sandbox="$1" &&
+ wc -l < "$WORKDIR/check.list" > expected &&
+ find "$sandbox" -type f | grep -v "/CVS" > "$WORKDIR/check.cvsCount" &&
+ wc -l < "$WORKDIR/check.cvsCount" >actual &&
+ test_cmp expected actual &&
+ rm expected actual &&
+ sort < "$WORKDIR/check.list" > expected &&
+ sort < "$WORKDIR/check.cvsCount" | sed -e "s%cvswork/%%" >actual &&
+ test_cmp expected actual &&
+ rm expected actual
}
check_end_full_tree() {
- sandbox="$1"
- ver="$2"
- expectCount=$(wc -l < "$WORKDIR/check.list")
- cvsCount=$(find "$sandbox" -name CVS -prune -o -type f -print | wc -l)
- gitCount=$(git ls-tree -r "$2" | wc -l)
- test x"$cvsCount" = x"$expectCount" -a x"$gitCount" = x"$expectCount"
- stat=$?
- echo "check_end $sandbox : $stat cvs=$cvsCount git=$gitCount expect=$expectCount" \
- >> "$WORKDIR/check.log"
- return $stat
+ sandbox="$1" &&
+ sort < "$WORKDIR/check.list" >expected &&
+ find "$sandbox" -name CVS -prune -o -type f -print | sed -e "s%$sandbox/%%" | sort >act1 &&
+ test_cmp expected act1 &&
+ git ls-tree -r "$2" | sed -e "s/^.*blob [0-9a-fA-F]*[ ]*//" | sort > act2 &&
+ test_cmp expected act2 &&
+ rm expected act1 act2
}
#########
@@ -155,7 +154,8 @@ test_expect_success 'cvs co b1 [cvswork3]' '
test_expect_success 'edit cvswork3 and save diff' '
( cd cvswork3 &&
- sed -i -e "s/line1/line1 - data/" adir/afile &&
+ sed -e "s/line1/line1 - data/" adir/afile >adir/afileNEW &&
+ mv -f adir/afileNEW adir/afile &&
echo "afile5" > adir/afile5 &&
rm t2 &&
cvs -f add adir/afile5 &&
@@ -168,7 +168,8 @@ test_expect_success 'setup v1.2 on b1' '
git checkout b1 &&
echo "new v1.2" > t3 &&
rm t2 &&
- sed -i -e "s/line3/line3 - more data/" adir/afile &&
+ sed -e "s/line3/line3 - more data/" adir/afile >adir/afileNEW &&
+ mv -f adir/afileNEW adir/afile &&
rm adir/a2file &&
echo "a3file" >> adir/a3file &&
echo "bfile line 3" >> adir/bdir/bfile &&
@@ -300,7 +301,8 @@ test_expect_success 'root dir rm file [cvswork2]' '
test_expect_success 'subdir edit/add/rm files [cvswork2' '
( cd cvswork2 &&
- sed -i -e "s/line 1/line 1 (v2)/" adir/bdir/bfile &&
+ sed -e "s/line 1/line 1 (v2)/" adir/bdir/bfile >adir/bdir/bfileNEW &&
+ mv -f adir/bdir/bfileNEW adir/bdir/bfile &&
rm adir/bdir/b2file &&
cd adir &&
cvs -f rm bdir/b2file &&
--
1.7.12
^ permalink raw reply related
* Re: git-svn with ignore-paths misses/skips some revisions during fetch
From: Enrico Weigelt @ 2012-11-10 7:57 UTC (permalink / raw)
To: Matt McHenry; +Cc: git
In-Reply-To: <D377A9280DB18546A2471214D5CBB0E9054C25E071@exchdb01>
> The problem is that the 'ignore-paths' approach sometimes
> misses commits during a fetch, and then at some later time
> will "realize" it and squash those changes onto some other,
> unrelated commit. (I've never seen this happen with the
> per-subdir 'fetch' approach.) Here are three commits in
> SVN:
Could it be that certain files spent parts of their historical lifetime
inside the ignored paths ?
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* Re: Bizarre problem cloning repo from Codeplex
From: Enrico Weigelt @ 2012-11-10 7:49 UTC (permalink / raw)
To: Jeremy Morton; +Cc: git
In-Reply-To: <508B133D.3090300@game-point.net>
> I'm trying to clone the following repository from Codeplex:
>
> https://git01.codeplex.com/entityframework.git
>
> git downloads all the objects, creates the directory
> "entityframework",
> then displays "error: RPC failed; result=56, HTTP code = 200" and
> immediately deletes the directory.
>
> I can clone other HTTPS repos with this git installation, for example
> from Bitbucket and Github. It's git 1.7.10.4 on Debian.
reproduced it on Ubuntu precise, git-1.7.9.5
When starting with an empty repo, adding the url as remote and calling
git remote update origin:
> Fetching origin
> WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-5cWq1d/pkcs11: No such file or directory
> remote: Counting objects: 21339, done.
> remote: Compressing objects: 100% (3778/3778), done.
> remote: Total 21339 (delta 17180), reused 21339 (delta 17180)
> Receiving objects: 100% (21339/21339), 11.24 MiB | 1.04 MiB/s, done.
> error: RPC failed; result=56, HTTP code = 200
> Resolving deltas: 100% (17180/17180), done.
> error: Could not fetch origin
But: refs/remotes/origin/master is added and looks sane (git fsck
shows no errors).
Subsequent 'git remote update' calls look good:
> Fetching origin
Even after manually removing the ref and re-running update,
everything look fine:
> Fetching origin
> WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-5cWq1d/pkcs11: No such file or directory
> From https://git01.codeplex.com/entityframework
> * [new branch] master -> origin/master
Their webserver seems to be configured quite restrictively
(eg. cannot access files like 'packed-refs').
Is there a way to trace the actual HTTP calls ?
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* Re: Workflow for templates?
From: Enrico Weigelt @ 2012-11-10 7:27 UTC (permalink / raw)
To: Holger Hellmuth (IKS); +Cc: Josef Wolf, git
In-Reply-To: <509A863B.4090805@ira.uka.de>
> Let me ask a different question: What is wrong with cherry-picking
> downstream changes to your upstream branch? Without rebasing it to
> downstream.
Naah, dont rebase the upstream ontop of downstream - this doenst make
any sense (yeah, my devs sometimes doing exatly this wong ;-o).
Instead, as you just said, cherry-pick the good commits into your
upstream branch and rebase your downstreams ontop of that. (doesnt
make any difference if this is done by different people or in different
administrative domains).
> That might mean there is a rather useless merge downstream later on,
> but that's the price you pay for not doing the change in a development
> branch.
That's one of the things rebase is for: not having your history filled
up with merges at all, but always have your local cutomizations added
ontop of the current upstream.
By the way: I'm also using this hierachy for package maintenance to
different target distros:
upstream branch
|
|----> upstream release tag X.Y.Z
|
\ /
bugfix branch (maint-X-Y-Z) => general (eg. distro-agnostig) fixes go here
|
|-----> maintenance release tag X.Y.Z.A
|
\ /
dist branch (mydist-X-Y-Z) => distro-specific customizations (eg.
| packaging control files, etc) go here
|------> dist package release tags X.Y.Z.A-B
Usually I do quick hotfixes in the dist branch (and assigning new dist version number),
then copy the dist branch into some topic-branch, rebase into latest bugfix branch,
cherry-pick the interesting commit(s) into the bugfix branch. When I do a new bugfix
release (from by bugfix branch), I rebase the dist branch ontop the latest bugfix
release tag, fix dist-package version numbers and run the dist-specific build and
testing pipeline.
Here's some example for it: https://github.com/vnc-biz/redmine-core
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* Re: Workflow for templates?
From: Enrico Weigelt @ 2012-11-10 7:13 UTC (permalink / raw)
To: Josef Wolf; +Cc: git
In-Reply-To: <20121031104403.GC28437@raven.wolf.lan>
> I am somewhat unsure whether it would work this way. After all, there
> seems to
> be an unbreakable rule with git: never rebase published branches.
I dont see a big problem if you just tell the downstreams to rebase
instead of merge downwards.
That's eg. my default approach for handling things like local
customizations. The fine thing here is that you'll always have a
clear separation between upstream development and your customizations.
Let's say, you have once forked at release tag v1.2.3, added 3
customization commits and later rebase onto v1.2.4, you'll still
have your 3 customization commits ontop of the upstream release.
With merge, you'll get more and more merge commits mixed later
coming customizations, and a migh higher chance of repeating conflicts.
I'd suggest some general rules:
* strict branch hierachy
* downstreams always rebase instead of merge
* probably use --onto rebase
* development is always happening in topic-branches, that will be
rebased before merge into their upstream --> fast-forward only
> Maybe I should try to explain the problem in terms of repository
> hierarchy. Let's assume, there is this hierarchy of repositories:
Let's talk about branches instead - repos are just containers for
branches (and tags, etc). If all people are practically in the same
administrative domain (or sort of), you can even use one single
repo for that (not counting developer's and target system's local
clones).
> upstream: central repository, containing the generic template
>
> foo-site: repository for site foo. Here we have localizations for a
> specific
> administrative entity named foo (say, google).
> This is where clones for production are made from, and
> production
> boxes pull from here to be kept up-to-date.
Only the non-customized boxes will pull from here - if there's any bit
that needs to be changed, add separate branches for them.
And "pull" always means rebase.
When a new upstream release comes out (and is properly validated), it
will be rebased ontop of that.
> foo-devA: A clone of foo-site to make development, releases, and
> whatever for foo.
> foo-devB: One more clone of foo-site, Developer B is working here.
Developers should use topic branches, which are regularily rebased
ontop of their upstream, especially before commit and final validation.
> Further, foo-devA might be the same person as bar-devA.
He'll use separate branches anyways. Everything else is just a matter
of proper naming scheme.
For example, if you're using a central (bare) repository (again: not
counting the developer's locl clones), you could use something like
an <site>+"/" branch name prefix.
By the way: you really should use non-conflicting tag names (eg.
adding some <site>+"/" or <site>+"-" prefix), otherwise you'll
easiy run into conflicts, because per default retrieved and local
tags will all be in some namespace - you'll probably dont like to
set up separate namespaces for individual remotes (which is quite
easy to forget ;-o). Better consider tag names to be really global.
> So when foo-devA pulls from foo-devB, then foo-devB will create
> problems when he rebases after that pull.
pull (or probably: remote update) is different from merge or rebase
essentially, pull is a combination of remote update and an automatic
merge from or rebase onto (depending on the configuration) the
coresponding upstream branch.
> What I am trying to achieve, is to extend the workflow from
> development to
> deployment across multiple administrative entities. As a picture:
>
> upstream (templates only).
> ^
> |
> v
> development (configured, might contain experimental changes)
> ^
> |
> v
> deployment (configured)
>
> This workflow should not stop at administrative borders. Just replace
> foo by
> google and bar by Microsoft to get an idea of what I am trying to
> achieve.
We're talking about two entirely different things here:
a) repositories: container that hold references to histories
(branches, tags, etc)
b) branches and their semantic releations
Repositories:
As git is fully distributed, it doesnt really matter where repositories
are. Developers (and other parties accessing the code) will most likely
have their own local clone. But "clone of X" means nothing more than just
happens to have some remote attachment to repo X.
So, the semantics of
git clone /path/to/my/funny-project
is the same like:
( git init funny-project && \
cd cd funny-project && \
git remote add origin /path/to/my/funny-project && \
git remote update origin && \
git checkout origin/master -b master )
So, let's look at the individual steps:
#1: git init funny-project
--> ( mkdir funny-project && cd funny-dir && git init )
--> creates an empty repository
#2: git remote add origin /path/to/my/funny-project
--> configures an remote called "origin" with url "/path/to/my/funnly-project"
and confgures it to sync the remote-side's references from refs/heads/*
to locally refs/remotes/origin/*, and remote-side's refs/tags/* to
locally refs/tags (without overwriting existing tag references)
#3: git remote update origin
--> do the actual syncing from remote "origin", get the remote ref list,
download all yet objects (that are required for the refs to be synced)
and adds/updates the refs into the according target namespaces
(BTW: if a branch was removed on remote side, the local copy in
refs/remotes/<remote-name>/* wont be deleted - you'll need to call
git remote prune <remote-name> for that)
#4: git checkout origin/master -b master
--> copies the current refs/remotes/origin/master ref to refs/heads/master
and checks out that new local branch (IOW: sets the refs/HEAD symbolic
ref to refs/heads/master and copies index and working tree from the
head commit)
Branches are something completely different:
Logically, a branch is a history of commits with parent-child-relationship
(mathematically spoken, it's an directed acyclic graph): each commit may
have a variable number of parent commits.
Technically, what we usally call "branch" is in fact an name (reference
in refs/heads/* namespace) which point at the head commit of that local
branch. When you do git commit, it creates a new commit object from the
index, adds some metadata (eg. your commit message) and sets the current
branch reference (usually that one where the symbolic reference refs/HEAD
points to) to the new commit object's SHA-key. IOW: you add a new object
in front of the DAG and move the pointer one step forward in the line.
When you do a merge (no matter if the source is remote or local - it just
needs to be an locally available object), there're essentially two things
that can happen:
a) your source is an direct descendant of the target branch (IOW: the
target's current head commit appears somewhere in the source's history),
it will just move the current branch forward to the merge source
(moves the head pointer and updates index and worktree)
this is called "fast-forward" (in fact, it the fastest kind of merge)
b) your source is not direct descendant: source tree will be actually
merged into index/worktree, possibly make break when there're conflicts
to be resolved manually, and create a new commit containing the current
(now merged) index and two parent poiters, to source and to previous
merge target.
Now what is rebase ?
A rebase rewrites history in various ways (in fact, you can do a lot more
things than just simple rebasing, eg. edit or drop older commits, etc).
For example 'git rebase origin/master' will look for the latest common
ancestor of both the current and the target treeish (eg. refs/remotes/master),
start from that tree'ish and apply the changes that happend from the last
common ancestor until your current branch head ontop of that treeish,
(possibly asking the user to manually resolve some conflicts), and then
replaces the current branch head by the final head.
As it changes history, it should be used wisely.
A common problem with using rebase and public branches is:
* upstream changes history (eg. because he rebased onto his upstream)
* downstream (per default) merges this upstream into his branch
--> git will see two entirely different branches get merged, so
there's some good change of nasty conflicts, and history will
easily get really ugly
So, if you do rebase your public branch, downstreams should also do so
(rebase their local branches ontop of your public branch instead of
merging yours into theirs).
By the way: there are several more kinds of rebases, which are very
interesting for complex or sophisticated workflows, eg:
* --ontop rebase: instead of letting git find out the starting point
of commit sequence to apply on target treeish, you'll define it
explicitly (eg. if you want it to forget about things previous to
the starting treeish).
* interactive rebase:
a) is able to reconstruct merges
b) allows to cut into the sequence and change, drop or add new commits
These operations are very useful for cleaning up the history, especially
with things like topic-branch workflow (eg. if you originally have some
hackish and unclean commits and you wanna put an clean and self-consistant
one into your mainline instead).
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* Re: Rename edge case...
From: John Szakmeister @ 2012-11-10 2:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121109160925.GA19725@sigill.intra.peff.net>
On Fri, Nov 9, 2012 at 11:09 AM, Jeff King <peff@peff.net> wrote:
[snip]
> Right. If the source didn't go away, it would be a copy. We can do copy
> detection, but it is not quite as obvious what a merge should do with a
> copy (apply the change to the original? To the copy? In both places? You
> would really want hunk-level copy detection for it to make any sense).
Yeah, I wasn't advocating that. More along the lines of what you're
talking about below...
> Usually git deals with this double-rename case through the use of
> "break" or "rewrite" detection. We notice that the old "foo.txt" and the
> new "foo.txt" do not look very much like each other, and break the
> modification apart into an add and a delete. That makes each side
> eligible for rename detection, and we can end up finding the pairs of
> renames above.
I did try using the -B option, and it did detect that foo.txt was
renamed to fooOld.txt, but it didn't show fooNew.txt being renamed to
foo.txt. I'm running git 1.7.12.3. It could be that 1.8.0 does
better, but I haven't tried.
> So in theory it just as simple as a one-liner to turn on break-detection
> in merge-recursive. Sadly, that only reveals more issues with how
> merge-recursive handles renames. See this thread, which has pointers to
> the breakages at the end:
>
> http://thread.gmane.org/gmane.comp.version-control.git/169944
Thank you. I'll definitely read up on this.
> I've become convinced that the best way forward with merge-recursive is
> to scrap and rewrite it. It tries to do things in a muddled order, which
> makes it very brittle to changes like this. I think it needs to have an
> internal representation of the tree that can represent all of the
> conflicts, and then follow a few simple phases:
>
> 1. "structural" 3-way merge handling renames, breaks, typechanges,
> etc. Each path in tree might show things like D/F conflicts, or it
> might show content-level merges that still need to happen, even if
> the content from those merges is not coming from the same paths in
> the source trees.
>
> 2. Resolve content-level 3-way merges at each path.
>
> 3. Compare the proposed tree to the working tree and list any problems
> (e.g., untracked files or local modifications that will be
> overwritten).
>
> Right now it tries to do these things interleaved as it processes paths,
> and as a result we've had many bugs (e.g., the content-level merge
> conflating the content originally at a path and something that was
> renamed into place, and missing corner cases where we actually overwrite
> untracked files that should be considered precious).
>
> But that is just off the top of my head. I haven't looked at the topic
> in quite a while (and I haven't even started working on any such
> rewrite).
That certainly sounds like a better approach.
>> So I played locally with a few ideas, and was surprised to find out
>> that even breaking up the two renames into two separate commits git
>> still didn't follow it.
>
> Right, because the merge only looks at the end points. Try doing a
> "diff -M" between your endpoints with and without "-B". We do not have
> any double-renames in git.git, but you can find "-B" helping a similar
> case: most of a file's content is moved elsewhere, but some small amount
> remains. For example, try this in git.git, with and without -B:
>
> git show -M --stat --summary --patch 043a449
>
> It finds the rename only with "-B", which would help a merge (it also
> makes the diff shorter and more readable, as you can see what was
> changed as the content migrated to the new file).
I've played with the -B option before, and it's definitely nice in
certain cases.
Thank you for taking the time to write all this up. It was very informative!
-John
^ permalink raw reply
* Re: [PATCH v2 0/5] push: update remote tags only with force
From: Chris Rorvick @ 2012-11-10 1:15 UTC (permalink / raw)
To: Jeff King
Cc: git, Felipe Contreras, Michael Haggerty, Angelo Borsotti,
Philip Oakley, Johannes Sixt, Kacper Kornet
In-Reply-To: <20121109183834.GB22164@sigill.intra.peff.net>
On Fri, Nov 9, 2012 at 12:38 PM, Jeff King <peff@peff.net> wrote:
> On Sun, Nov 04, 2012 at 09:08:23PM -0600, Chris Rorvick wrote:
>
>> Patch series to prevent push from updating remote tags w/o forcing them.
>> Split out original patch to ease review.
>>
>> Chris Rorvick (5):
>> push: return reject reasons via a mask
>> push: add advice for rejected tag reference
>> push: flag updates
>> push: flag updates that require force
>> push: update remote tags only with force
>>
>> Documentation/git-push.txt | 10 +++++-----
>> builtin/push.c | 24 +++++++++++++++---------
>> builtin/send-pack.c | 6 ++++++
>> cache.h | 7 ++++++-
>> remote.c | 39 +++++++++++++++++++++++++++++++--------
>> t/t5516-fetch-push.sh | 30 +++++++++++++++++++++++++++++-
>> transport-helper.c | 6 ++++++
>> transport.c | 25 +++++++++++++++----------
>> transport.h | 10 ++++++----
>> 9 files changed, 119 insertions(+), 38 deletions(-)
>
> I have not looked carefully at this topic yet, but I did try merging it
> to "pu" and found that it had some textual conflicts with the
> nd/builtin-to-libgit topic, which moves some builtin/send-pack.c code to
> send-pack.c. Since I am graduating that topic to master, I went ahead
> and just rebased your topic on top.
>
> If you do a re-roll, please use an updated master, and feel free to
> grab (and double-check!) the rebase I am about to send out in 'pu'. I
> also included the minor signed/unsigned pointer warning fixup in the
> rebase, too.
>
> -Peff
Thanks, I've rebased and checked against the changes in pu. Looks
good to me. I have a couple of other minor fixes (see below for
details.) I'll include these in an update if there is sufficient
interest in this.
Chris
-- 8< --
diff --git a/remote.c b/remote.c
index fde2a79..b025a38 100644
--- a/remote.c
+++ b/remote.c
@@ -1351,9 +1351,8 @@ void set_ref_status_for_push(struct ref
*remote_refs, int send
if (ref->update) {
ref->nonfastforward =
- ref->update &&
- (!has_sha1_file(ref->old_sha1)
- || !ref_newer(ref->new_sha1, ref->old_sha1));
+ !has_sha1_file(ref->old_sha1)
+ || !ref_newer(ref->new_sha1, ref->old_sha1);
if (!ref->forwardable) {
ref->requires_force = 1;
diff --git a/transport.c b/transport.c
index c183971..a380ad7 100644
--- a/transport.c
+++ b/transport.c
@@ -749,7 +749,7 @@ void transport_print_push_status(const char *dest,
struct ref *r
else
*reject_mask |= REJECT_NON_FF_OTHER;
} else if (ref->status == REF_STATUS_REJECT_ALREADY_EXISTS) {
- *reject_mask |= REJECT_ALREADY_EXISTS;
+ *reject_mask |= REJECT_ALREADY_EXISTS;
}
}
}
^ permalink raw reply related
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Felipe Contreras @ 2012-11-10 0:44 UTC (permalink / raw)
To: Jeff King; +Cc: git, SZEDER Gábor, Sverre Rabbelier
In-Reply-To: <20121110003331.GA12567@sigill.intra.peff.net>
On Sat, Nov 10, 2012 at 1:33 AM, Jeff King <peff@peff.net> wrote:
> On Sat, Nov 10, 2012 at 12:21:48AM +0100, Felipe Contreras wrote:
>
>> > * fc/fast-export-fixes (2012-11-08) 14 commits
>> > - fast-export: don't handle uninteresting refs
>> > - fast-export: make sure updated refs get updated
>> > - fast-export: fix comparison in tests
>> > - fast-export: trivial cleanup
>> > - remote-testgit: make clear the 'done' feature
>> > - remote-testgit: report success after an import
>> > - remote-testgit: exercise more features
>> > - remote-testgit: cleanup tests
>> > - remote-testgit: remove irrelevant test
>> > - remote-testgit: get rid of non-local functionality
>> > - Add new simplified git-remote-testgit
>> > - Rename git-remote-testgit to git-remote-testpy
>> > - remote-testgit: fix direction of marks
>> > - fast-export: avoid importing blob marks
>> >
>> > Improvements to fix fast-export bugs, including how refs pointing to
>> > already-seen commits are handled. An earlier 4-commit version of this
>> > series looked good to me, but this much-expanded version has not seen
>> > any comments.
>> >
>> > Needs review.
>>
>> I can send the previous 4-commit version if needed, the only thing
>> that changed is the commit messages.
>
> In the actual code, perhaps, but aren't there significant changes to the
> git-remote-testgit infrastructure that were not originally present? That
> could use some review.
>
> I also seem to recall that the tests in this version rely on the presence of bash;
> don't we still need to mark the tests with a prerequisite?
I meant in the 4-commits.
>> > * fc/completion-test-simplification (2012-10-29) 2 commits
>> > - completion: simplify __gitcomp test helper
>> > - completion: refactor __gitcomp related tests
>> >
>> > Clean up completion tests.
>> >
>> > There were some comments on the list.
>> >
>> > Expecting a re-roll.
>>
>> The second patch I can re-roll, but the first patch needs some
>> external input. My preference is that tests should also be simple and
>> maintainable, SZEDER's preference is that tests are better being
>> explicit and verbose (even if harder to maintain) to minimize possible
>> issues in the tests.
>
> I think it is better to keep the tests simple and maintainable. If there
> are multiple ways to do things and they all need testing, then that
> should be clear from the tests, not done haphazardly because some tests
> happen to use a different way of doing things.
Good, that's what my first patch does; no functional changes, just
refactor code into a single function.
> I seem to recall there was a one-liner fix that needed to be rolled in,
> which is why I held it out of next.
Yes, that I can reroll.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Jeff King @ 2012-11-10 0:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ralf Thielow, git
In-Reply-To: <7vr4o2plmw.fsf@alter.siamese.dyndns.org>
On Fri, Nov 09, 2012 at 12:27:35PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I have not been pushing the individual topic branches to make life
> > easier for people who usually just track Junio's kernel.org repository,
> > and would not welcome suddenly getting a hundred extra remote branches.
> > I can make them public if it makes life easier for people, but it may
> > not be worth it at this point, with Junio returning soon.
>
> What we should have arranged was to have https://github.com/git/git
> (which is not even owned by me, but I asked somebody at GitHub to
> assign me a write privilege) writable by the interim maintainer, so
> that normal people would keep pulling from there, while the interim
> maintainer can choose to publish broken-out branches to his
> repository.
Yes, I have write access to that repository, too, but I intentionally
held off from updating it out of a sense of nervousness. I figured if I
screwed up anything too badly, people who were clued-in enough to switch
to pulling from my repository would be clued-in enough to rebase across
any too-horrible mistake I made. ;)
I think if we do this again, I will make the same split you do (git/git
for integration branches, peff/git as a mirror of my private repo).
> And it is not too late to do so; from the look of your "What's
> cooking", you are doing pretty well ;-).
Any fool can merge topics to master. The real test will be how many
regressions people report in the next two weeks. :)
By the way, I did not touch 'maint' at all while you were gone. I don't
know what your usual method is for keeping track of maint-worthy topics
after they have gone to master. The usual "what's cooking" workflow
keeps track of things going to master, but no more; I'd guess you
probably just merge to maint when you delete them from last cycle's
"graduated to master" list.
I just let them stew in master for a bit longer, and we can easily find
and merge them with "git branch --no-merged maint | grep maint".
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Jeff King @ 2012-11-10 0:33 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, SZEDER Gábor, Sverre Rabbelier
In-Reply-To: <CAMP44s3yVtQ4wGqVTyHN-VfAM7iRo9WfNnAu+ns7Zkc_cPBH3g@mail.gmail.com>
On Sat, Nov 10, 2012 at 12:21:48AM +0100, Felipe Contreras wrote:
> > * fc/fast-export-fixes (2012-11-08) 14 commits
> > - fast-export: don't handle uninteresting refs
> > - fast-export: make sure updated refs get updated
> > - fast-export: fix comparison in tests
> > - fast-export: trivial cleanup
> > - remote-testgit: make clear the 'done' feature
> > - remote-testgit: report success after an import
> > - remote-testgit: exercise more features
> > - remote-testgit: cleanup tests
> > - remote-testgit: remove irrelevant test
> > - remote-testgit: get rid of non-local functionality
> > - Add new simplified git-remote-testgit
> > - Rename git-remote-testgit to git-remote-testpy
> > - remote-testgit: fix direction of marks
> > - fast-export: avoid importing blob marks
> >
> > Improvements to fix fast-export bugs, including how refs pointing to
> > already-seen commits are handled. An earlier 4-commit version of this
> > series looked good to me, but this much-expanded version has not seen
> > any comments.
> >
> > Needs review.
>
> I can send the previous 4-commit version if needed, the only thing
> that changed is the commit messages.
In the actual code, perhaps, but aren't there significant changes to the
git-remote-testgit infrastructure that were not originally present? That
could use some review.
I also seem to recall that the tests in this version rely on the presence of bash;
don't we still need to mark the tests with a prerequisite?
> > * fc/completion-test-simplification (2012-10-29) 2 commits
> > - completion: simplify __gitcomp test helper
> > - completion: refactor __gitcomp related tests
> >
> > Clean up completion tests.
> >
> > There were some comments on the list.
> >
> > Expecting a re-roll.
>
> The second patch I can re-roll, but the first patch needs some
> external input. My preference is that tests should also be simple and
> maintainable, SZEDER's preference is that tests are better being
> explicit and verbose (even if harder to maintain) to minimize possible
> issues in the tests.
I think it is better to keep the tests simple and maintainable. If there
are multiple ways to do things and they all need testing, then that
should be clear from the tests, not done haphazardly because some tests
happen to use a different way of doing things.
I seem to recall there was a one-liner fix that needed to be rolled in,
which is why I held it out of next.
> > * fc/remote-bzr (2012-11-08) 5 commits
> > - remote-bzr: update working tree
> > - remote-bzr: add support for remote repositories
> > - remote-bzr: add support for pushing
> > - remote-bzr: add simple tests
> > - Add new remote-bzr transport helper
> >
> > New remote helper for bzr.
> >
> > Will merge to 'next'.
>
> I already have a newer version of this with support for special modes:
> executable files, symlinks, etc. I think a reroll would make sense.
Thanks for letting me know.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Felipe Contreras @ 2012-11-09 23:21 UTC (permalink / raw)
To: Jeff King; +Cc: git, SZEDER Gábor, Sverre Rabbelier
In-Reply-To: <20121109192336.GA9401@sigill.intra.peff.net>
Hi,
On Fri, Nov 9, 2012 at 8:23 PM, Jeff King <peff@peff.net> wrote:
> * fc/fast-export-fixes (2012-11-08) 14 commits
> - fast-export: don't handle uninteresting refs
> - fast-export: make sure updated refs get updated
> - fast-export: fix comparison in tests
> - fast-export: trivial cleanup
> - remote-testgit: make clear the 'done' feature
> - remote-testgit: report success after an import
> - remote-testgit: exercise more features
> - remote-testgit: cleanup tests
> - remote-testgit: remove irrelevant test
> - remote-testgit: get rid of non-local functionality
> - Add new simplified git-remote-testgit
> - Rename git-remote-testgit to git-remote-testpy
> - remote-testgit: fix direction of marks
> - fast-export: avoid importing blob marks
>
> Improvements to fix fast-export bugs, including how refs pointing to
> already-seen commits are handled. An earlier 4-commit version of this
> series looked good to me, but this much-expanded version has not seen
> any comments.
>
> Needs review.
I can send the previous 4-commit version if needed, the only thing
that changed is the commit messages.
I think it's unfortunate that 4-commit version would not be mentioning
that it fixes the above tests, but hey; I did what I could.
> * fc/zsh-completion (2012-10-29) 3 commits
> - completion: add new zsh completion
> - completion: add new __gitcompadd helper
> - completion: get rid of empty COMPREPLY assignments
>
> There were some comments on this, but I wasn't clear on the outcome.
>
> Need to take a closer look.
SZEDER should probably take a look. I think it should be better than
the previous series.
> * fc/completion-test-simplification (2012-10-29) 2 commits
> - completion: simplify __gitcomp test helper
> - completion: refactor __gitcomp related tests
>
> Clean up completion tests.
>
> There were some comments on the list.
>
> Expecting a re-roll.
The second patch I can re-roll, but the first patch needs some
external input. My preference is that tests should also be simple and
maintainable, SZEDER's preference is that tests are better being
explicit and verbose (even if harder to maintain) to minimize possible
issues in the tests.
> * fc/remote-testgit-feature-done (2012-10-29) 1 commit
> - remote-testgit: properly check for errors
>
> Needs review.
Sverre probably should reply. I think I already addressed his comments
and the patch should be OK to push.
But probably it's not that important considering the testgit
refactoring, and also I'm thinking that we need to actually check the
status of the process[1] because the situation is still not OK with
pushing, and I'm learning it the hard way with a buggy remote helper.
> * fc/remote-bzr (2012-11-08) 5 commits
> - remote-bzr: update working tree
> - remote-bzr: add support for remote repositories
> - remote-bzr: add support for pushing
> - remote-bzr: add simple tests
> - Add new remote-bzr transport helper
>
> New remote helper for bzr.
>
> Will merge to 'next'.
I already have a newer version of this with support for special modes:
executable files, symlinks, etc. I think a reroll would make sense.
> * fc/remote-hg (2012-11-04) 16 commits
> - remote-hg: the author email can be null
> - remote-hg: add option to not track branches
> - remote-hg: add extra author test
> - remote-hg: add tests to compare with hg-git
> - remote-hg: add bidirectional tests
> - test-lib: avoid full path to store test results
> - remote-hg: add basic tests
> - remote-hg: fake bookmark when there's none
> - remote-hg: add compat for hg-git author fixes
> - remote-hg: add support for hg-git compat mode
> - remote-hg: match hg merge behavior
> - remote-hg: make sure the encoding is correct
> - remote-hg: add support to push URLs
> - remote-hg: add support for remote pushing
> - remote-hg: add support for pushing
> - Add new remote-hg transport helper
>
> New remote helper for hg.
>
> Will merge to 'next'.
:)
I have a few patches on top of this, but they can probably wait.
Cheers.
[1] http://article.gmane.org/gmane.comp.version-control.git/208139
--
Felipe Contreras
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox