* [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
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Kalle Olavi Niemitalo @ 2012-11-09 21:52 UTC (permalink / raw)
To: git
In-Reply-To: <20121109192336.GA9401@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Comments welcome from people using unusual editors (e.g., a script that
> starts an editor in another window then blocks, waiting for the user to
> finish).
I often run a shell in Emacs in X, then start git commit in that
shell. $EDITOR is emacsclient --current-frame, which asks the
existing Emacs instance to load the file and waits until I press
C-x # in Emacs to mark the file done. If I want to abort the
commit, it is most intuitive to return to the *Shell* buffer in
Emacs and press C-c C-c (comint-interrupt-subjob) to send SIGINT
to git from there. (I see that "an empty message aborts the
commit", and indeed it does, but well, I prefer not to trust such
a feature if I can instead just interrupt the thing.)
With pf/editor-ignore-sigint, C-c C-c in the *Shell* buffer kills
neither git nor the emacsclient started by git. This is not good.
SIGQUIT from C-c C-\ (comint-quit-subjob) still works though.
^ permalink raw reply
* Re: Help requested - trying to build a tool doing whole-tree commits
From: Andreas Schwab @ 2012-11-09 21:50 UTC (permalink / raw)
To: Unknown; +Cc: git
In-Reply-To: <20121109182024.81074BC66D4@golux>
Unknown <unknown@unknown.invalid> writes:
> I need a command or command sequence that will commit an entire file
> tree to a repository...
>
> (a) Allowing me to specify committer and author metadata, and
>
> (b) deleting paths not present in the previous commit on the current
> branch, and
>
> (c) allowing me to specify merge links from other previous commits.
>
> git commit -a passes (a) and (b) but not (c).
git commit -a won't add new files, so you probably want to use git add
-A && git commit. I'm not quite sure what you mean with "merge links",
but if you want to create merge commits the you'll need to resort to
plumbing: git add -A && git write-tree && git commit-tree && git
update-ref.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: orphan blob or what?
From: Tomas Carnecky @ 2012-11-09 21:41 UTC (permalink / raw)
To: bruce; +Cc: git
In-Reply-To: <87625elg9r.fsf@intel.com>
On Fri, 09 Nov 2012 11:37:04 -0800, bruce <bruce.e.robertson@intel.com> wrote:
> Tomas Carnecky <tomas.carnecky@gmail.com> writes:
>
> Just idiocy on my part. Thanks.
>
> > On Thu, 08 Nov 2012 16:24:36 -0800, bruce <bruce.e.robertson@intel.com> wrote:
> >> In today's and older clones of https://github.com/mirrors/linux.git I
> >> find this object, 6fa98ea0ae40f9a38256f11e5dc270363f785aee, that I can't
> >> figure out how to eliminate^h^h^h^h^h^h^h^h^hget rid of. I don't see it
> >> in 'git fsck', 'git gc --aggressive --prune' doesn't seem to prune it,
> >> can't see it via 'git log'. And yet
> >>
> >> linux/.git/objects/pack$ git verify-pack -v *.idx | grep 6fa98ea0ae40f9a38256f11e5dc270363f785aee
> >> 6fa98ea0ae40f9a38256f11e5dc270363f785aee blob 1519697 124840 515299673
> >> 8231eaa31ce1107c1463deb6ec33f61618aedbb9 blob 67 63 515424513 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee
> >> f21a8c1b9d47736fa4e27def66f04b9fe2b4bc53 blob 90 83 515424576 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee
> >
> > Commit dee0bb9 (ASoC: Mark WM8962 Additional Control 4 register as volatile,
> > 2010-09-29) references this blob.
It wasn't easy to find the commit. First I figured out at which path that file
was stored. Using git log -S'wm8962_reg[WM8962_MAX_REGISTER + 1]' I quickly
determined that the file was somewhere in sound/, more specifically
sound/soc/codecs/wm8962-tables.c. However a 'git log --
sound/soc/codecs/wm8962-tables.c' did not show any commit. That was strange,
because 'git log -S'WM8962_MAX_REGISTER + 1' --name-status --
sound/soc/codecs/' clearly shows that the file existed at some point in the
past. The commit is hidden from a simple 'git log' due to 'History
Simplification'. See the git-log man page. I added --full-history -p to the log
command, and searched in the pager for '6fa98e'. That revealed the commit which
references that blob:
git log --full-history -p -- sound/soc/codecs/wm8962-tables.c
^ permalink raw reply
* Help requested - trying to build a tool doing whole-tree commits
From: Unknown, Eric S. Raymond @ 2012-11-09 18:20 UTC (permalink / raw)
To: git
(Apologies if this arrives twice. I'm on the road, with somewhat flaky email.)
Because of my work on reposurgeon, I am sometimes asked to produce git
repositories for very old projects that not only are still using CVS
but have ancient releases not in the CVS repository, preserved only
as tarballs. I have such a request currently pending from the
robotfindskitten project.
To automate this process, I am trying to write a tool that will take a
sequence of file trees and synthetic change comments in one end and
emit a git repository composing them into a DAG out the other. The
working name for this tool is 'gitpacker'.
I've already written the unpacking operation (git repo to tree
sequence plus log). This morning I discovered that git-commit
won't do quite what I need for the packing operation.
I'm requesting help.
I need a command or command sequence that will commit an entire file
tree to a repository...
(a) Allowing me to specify committer and author metadata, and
(b) deleting paths not present in the previous commit on the current
branch, and
(c) allowing me to specify merge links from other previous commits.
git commit -a passes (a) and (b) but not (c).
Advice on how to accomplish this is requested
Advice on a better name for the tool is also requested, as I'm
not happy with the way my use of 'pack' collides with existing
git use of the same verb.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
.. a government and its agents are under no general duty to
provide public services, such as police protection, to any
particular individual citizen...
-- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181)
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Junio C Hamano @ 2012-11-09 20:27 UTC (permalink / raw)
To: Jeff King; +Cc: Ralf Thielow, git
In-Reply-To: <20121109201057.GA11368@sigill.intra.peff.net>
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.
And it is not too late to do so; from the look of your "What's
cooking", you are doing pretty well ;-).
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Jeff King @ 2012-11-09 20:10 UTC (permalink / raw)
To: Ralf Thielow; +Cc: git
In-Reply-To: <CAN0XMOL1SS2iiJkZyt3HACoCRXE1nGrd52B2rscWyS1e7X0GWQ@mail.gmail.com>
On Fri, Nov 09, 2012 at 09:06:47PM +0100, Ralf Thielow wrote:
> > It seems that the repo doesn't contain the integration branches?!?
> >
> > $ git remote add peff git://github.com/peff/git.git
> > $ git fetch -v peff
> > From git://github.com/peff/git
> > * [new branch] maint -> peff/maint
> > * [new branch] master -> peff/master
> > * [new branch] next -> peff/next
> > * [new branch] pu -> peff/pu
> > * [new branch] todo -> peff/todo
> > $
>
> But "integration branches" means "master", "next" and "pu" than I haven't
> said anything. ;) Sorry for the noise.
Right. :)
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.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Ralf Thielow @ 2012-11-09 20:06 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <CAN0XMO+sgSgkqK7D6=5NL--rMYBwsGohgQ7v+ja4Twub20N1sQ@mail.gmail.com>
On Fri, Nov 9, 2012 at 9:01 PM, Ralf Thielow <ralf.thielow@gmail.com> wrote:
> On Fri, Nov 9, 2012 at 8:23 PM, Jeff King <peff@peff.net> wrote:
>>
>> You can find the changes described here in the integration branches of
>> my repository at:
>>
>> git://github.com/peff/git.git
>
> It seems that the repo doesn't contain the integration branches?!?
>
> $ git remote add peff git://github.com/peff/git.git
> $ git fetch -v peff
> From git://github.com/peff/git
> * [new branch] maint -> peff/maint
> * [new branch] master -> peff/master
> * [new branch] next -> peff/next
> * [new branch] pu -> peff/pu
> * [new branch] todo -> peff/todo
> $
But "integration branches" means "master", "next" and "pu" than I haven't
said anything. ;) Sorry for the noise.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Ralf Thielow @ 2012-11-09 20:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121109192336.GA9401@sigill.intra.peff.net>
On Fri, Nov 9, 2012 at 8:23 PM, Jeff King <peff@peff.net> wrote:
>
> You can find the changes described here in the integration branches of
> my repository at:
>
> git://github.com/peff/git.git
It seems that the repo doesn't contain the integration branches?!?
$ git remote add peff git://github.com/peff/git.git
$ git fetch -v peff
From git://github.com/peff/git
* [new branch] maint -> peff/maint
* [new branch] master -> peff/master
* [new branch] next -> peff/next
* [new branch] pu -> peff/pu
* [new branch] todo -> peff/todo
$
^ permalink raw reply
* Re: orphan blob or what?
From: bruce @ 2012-11-09 19:37 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git
In-Reply-To: <1352423287-ner-8337@calvin>
Tomas Carnecky <tomas.carnecky@gmail.com> writes:
Just idiocy on my part. Thanks.
> On Thu, 08 Nov 2012 16:24:36 -0800, bruce <bruce.e.robertson@intel.com> wrote:
>> In today's and older clones of https://github.com/mirrors/linux.git I
>> find this object, 6fa98ea0ae40f9a38256f11e5dc270363f785aee, that I can't
>> figure out how to eliminate^h^h^h^h^h^h^h^h^hget rid of. I don't see it
>> in 'git fsck', 'git gc --aggressive --prune' doesn't seem to prune it,
>> can't see it via 'git log'. And yet
>>
>> linux/.git/objects/pack$ git verify-pack -v *.idx | grep 6fa98ea0ae40f9a38256f11e5dc270363f785aee
>> 6fa98ea0ae40f9a38256f11e5dc270363f785aee blob 1519697 124840 515299673
>> 8231eaa31ce1107c1463deb6ec33f61618aedbb9 blob 67 63 515424513 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee
>> f21a8c1b9d47736fa4e27def66f04b9fe2b4bc53 blob 90 83 515424576 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee
>
> Commit dee0bb9 (ASoC: Mark WM8962 Additional Control 4 register as volatile,
> 2010-09-29) references this blob.
^ permalink raw reply
* What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Jeff King @ 2012-11-09 19:23 UTC (permalink / raw)
To: git
What's cooking in git.git (Nov 2012, #02; Fri, 9)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The fourth batch of topics has graduated to master. This should be my
last integration cycle, as Junio will be back to take over before the
next one.
You can find the changes described here in the integration branches of
my repository at:
git://github.com/peff/git.git
Until Junio returns, kernel.org and the other "usual" places will not be
updated.
--------------------------------------------------
[New Topics]
* cr/push-force-tag-update (2012-11-09) 5 commits
- push: update remote tags only with force
- push: flag updates that require force
- push: flag updates
- push: add advice for rejected tag reference
- push: return reject reasons via a mask
Require "-f" for push to update a tag, even if it is a fast-forward.
Needs review.
I'm undecided yet on whether the goal is the right thing to do, but it
does prevent some potential mistakes. I haven't looked closely at the
implementation itself; review from interested parties would be helpful.
* 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.
* mg/maint-pull-suggest-upstream-to (2012-11-08) 1 commit
- push/pull: adjust missing upstream help text to changed interface
Follow-on to the new "--set-upstream-to" topic from v1.8.0 to avoid
suggesting the deprecated "--set-upstream".
Will merge to 'next'.
* mh/alt-odb-string-list-cleanup (2012-11-08) 2 commits
- link_alt_odb_entries(): take (char *, len) rather than two pointers
- link_alt_odb_entries(): use string_list_split_in_place()
Cleanups in the alternates code. Fixes a potential bug and makes the
code much cleaner.
Will merge to 'next'.
* pf/editor-ignore-sigint (2012-11-08) 1 commit
- launch_editor: ignore SIGINT while the editor has control
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Comments welcome from people using unusual editors (e.g., a script that
starts an editor in another window then blocks, waiting for the user to
finish).
* pp/gitweb-config-underscore (2012-11-08) 1 commit
- gitweb: make remote_heads config setting work
The key "gitweb.remote_heads" is not legal git config; this maps it to
"gitweb.remoteheads".
Junio raised a good point about the implementation for three-level
variables.
Expecting a re-roll.
* pw/maint-p4-rcs-expansion-newline (2012-11-08) 1 commit
- git p4: RCS expansion should not span newlines
I do not have p4 to play with, but looks obviously correct to me.
Will merge to 'next'.
* rh/maint-gitweb-highlight-ext (2012-11-08) 1 commit
- gitweb.perl: fix %highlight_ext mappings
Fixes a clever misuse of perl's list interpretation.
Will merge to 'next'.
* rr/submodule-diff-config (2012-11-08) 3 commits
- submodule: display summary header in bold
- diff: introduce diff.submodule configuration variable
- Documentation: move diff.wordRegex from config.txt to diff-config.txt
Lets "git diff --submodule=log" become the default via configuration.
Seems like a good direction, though I had a few comments.
Expecting a re-roll.
--------------------------------------------------
[Graduated to "master"]
* fc/completion-send-email-with-format-patch (2012-10-16) 1 commit
(merged to 'next' on 2012-11-04 at 0a6366e)
+ completion: add format-patch options to send-email
Will merge to 'master' in the fourth batch.
* js/format-2047 (2012-10-18) 7 commits
(merged to 'next' on 2012-10-25 at 76d91fe)
+ format-patch tests: check quoting/encoding in To: and Cc: headers
+ format-patch: fix rfc2047 address encoding with respect to rfc822 specials
+ format-patch: make rfc2047 encoding more strict
+ format-patch: introduce helper function last_line_length()
+ format-patch: do not wrap rfc2047 encoded headers too late
+ format-patch: do not wrap non-rfc2047 headers too early
+ utf8: fix off-by-one wrapping of text
Fixes many rfc2047 quoting issues in the output from format-patch.
Will merge to 'master' in the fourth batch.
* km/send-email-compose-encoding (2012-10-25) 5 commits
(merged to 'next' on 2012-10-29 at d7d2bb4)
+ git-send-email: add rfc2047 quoting for "=?"
+ git-send-email: introduce quote_subject()
+ git-send-email: skip RFC2047 quoting for ASCII subjects
+ git-send-email: use compose-encoding for Subject
(merged to 'next' on 2012-10-25 at 5447367)
+ git-send-email: introduce compose-encoding
"git send-email --compose" can let the user create a non-ascii
cover letter message, but there was not a way to mark it with
appropriate content type before sending it out.
Further updates fix subject quoting.
Will merge to 'master' in the fourth batch.
* mh/maint-parse-dirstat-fix (2012-10-29) 1 commit
(merged to 'next' on 2012-11-04 at 852d609)
+ parse_dirstat_params(): use string_list to split comma-separated string
Cleans up some code and avoids a potential bug.
Will merge to 'master' in the fourth batch.
* mo/cvs-server-cleanup (2012-10-26) 11 commits
(merged to 'next' on 2012-10-29 at 4e70622)
+ Use character class for sed expression instead of \s
(merged to 'next' on 2012-10-25 at c70881d)
+ cvsserver status: provide real sticky info
+ cvsserver: cvs add: do not expand directory arguments
+ cvsserver: use whole CVS rev number in-process; don't strip "1." prefix
+ cvsserver: split up long lines in req_{status,diff,log}
+ cvsserver: clean up client request handler map comments
+ cvsserver: remove unused functions _headrev and gethistory
+ cvsserver update: comment about how we shouldn't remove a user-modified file
+ cvsserver: add comments about database schema/usage
+ cvsserver: removed unused sha1Or-k mode from kopts_from_path
+ cvsserver t9400: add basic 'cvs log' test
(this branch is tangled with mo/cvs-server-updates.)
Cleanups to prepare for mo/cvs-server-updates.
Will merge to 'master' in the fourth batch.
* nd/attr-match-optim-more (2012-10-15) 7 commits
(merged to 'next' on 2012-10-25 at 09f70ce)
+ attr: more matching optimizations from .gitignore
+ gitignore: make pattern parsing code a separate function
+ exclude: split pathname matching code into a separate function
+ exclude: fix a bug in prefix compare optimization
+ exclude: split basename matching code into a separate function
+ exclude: stricten a length check in EXC_FLAG_ENDSWITH case
+ Merge commit 'f9f6e2c' into nd/attr-match-optim-more
(this branch is used by as/check-ignore and nd/wildmatch.)
Start laying the foundation to build the "wildmatch" after we can
agree on its desired semantics.
Will merge to 'master' in the fourth batch.
* nd/builtin-to-libgit (2012-10-29) 7 commits
(merged to 'next' on 2012-11-04 at 06cbf9b)
+ fetch-pack: move core code to libgit.a
+ fetch-pack: remove global (static) configuration variable "args"
+ send-pack: move core code to libgit.a
+ Move setup_diff_pager to libgit.a
+ Move print_commit_list to libgit.a
+ Move estimate_bisect_steps to libgit.a
+ Move try_merge_command and checkout_fast_forward to libgit.a
Code cleanups so that libgit.a does not depend on anything in the
builtin/ directory.
Some of the code movement is pretty big, but there doesn't seem to be
any conflicts with topics in flight.
Will merge to 'master' in the fourth batch.
* nd/tree-walk-enum-cleanup (2012-10-19) 1 commit
(merged to 'next' on 2012-11-04 at 8ccdf98)
+ tree-walk: use enum interesting instead of integer
Will merge to 'master' in the fourth batch.
* ph/maint-submodule-status-fix (2012-10-29) 2 commits
(merged to 'next' on 2012-11-04 at d700e02)
+ submodule status: remove unused orig_* variables
+ t7407: Fix recursive submodule test
Cleans up some leftover bits from an earlier submodule change.
Will merge to 'master' in the fourth batch.
* rs/lock-correct-ref-during-delete (2012-10-16) 1 commit
(merged to 'next' on 2012-10-25 at 9341eea)
+ refs: lock symref that is to be deleted, not its target
When "update-ref -d --no-deref SYM" tried to delete a symbolic ref
SYM, it incorrectly locked the underlying reference pointed by SYM,
not the symbolic ref itself.
Will merge to 'master' in the fourth batch.
* sz/maint-curl-multi-timeout (2012-10-19) 1 commit
(merged to 'next' on 2012-11-04 at f696dd8)
+ Fix potential hang in https handshake
Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptors to wait on and the http
transport ended up sleeping for minutes in select(2) system call.
Detect this and reduce the wait timeout in such a case.
Will merge to 'master' in the fourth batch.
--------------------------------------------------
[Stalled]
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-10-07) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Waiting for comments.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
* mh/ceiling (2012-10-29) 8 commits
- string_list_longest_prefix(): remove function
- setup_git_directory_gently_1(): resolve symlinks in ceiling paths
- longest_ancestor_length(): require prefix list entries to be normalized
- longest_ancestor_length(): take a string_list argument for prefixes
- longest_ancestor_length(): use string_list_split()
- Introduce new function real_path_if_valid()
- real_path_internal(): add comment explaining use of cwd
- Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
--------------------------------------------------
[Cooking]
* mo/cvs-server-updates (2012-10-16) 10 commits
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
Needs review by folks interested in cvsserver.
* ta/doc-cleanup (2012-10-25) 6 commits
- Documentation: build html for all files in technical and howto
- Documentation/howto: convert plain text files to asciidoc
- Documentation/technical: convert plain text files to asciidoc
- Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
- Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
- Split over-long synopsis in git-fetch-pack.txt into several lines
Will merge to 'next'.
* lt/diff-stat-show-0-lines (2012-10-17) 1 commit
- Fix "git diff --stat" for interesting - but empty - file changes
We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
Needs some test updates.
* jc/prettier-pretty-note (2012-10-26) 11 commits
(merged to 'next' on 2012-11-04 at 40e3e48)
+ Doc User-Manual: Patch cover letter, three dashes, and --notes
+ Doc format-patch: clarify --notes use case
+ Doc notes: Include the format-patch --notes option
+ Doc SubmittingPatches: Mention --notes option after "cover letter"
+ Documentation: decribe format-patch --notes
+ format-patch --notes: show notes after three-dashes
+ format-patch: append --signature after notes
+ pretty_print_commit(): do not append notes message
+ pretty: prepare notes message at a centralized place
+ format_note(): simplify API
+ pretty: remove reencode_commit_message()
Now that Philip has submitted some documentation updates, this is
looking more ready.
Will merge to 'master' in the fifth batch.
* jc/same-encoding (2012-11-04) 1 commit
(merged to 'next' on 2012-11-04 at 54991f2)
+ reencode_string(): introduce and use same_encoding()
Various codepaths checked if two encoding names are the same using
ad-hoc code and some of them ended up asking iconv() to convert
between "utf8" and "UTF-8". The former is not a valid way to spell
the encoding name, but often people use it by mistake, and we
equated them in some but not all codepaths. Introduce a new helper
function to make these codepaths consistent.
Will merge to 'master' in the fifth batch.
* cr/cvsimport-local-zone (2012-11-04) 2 commits
(merged to 'next' on 2012-11-04 at 292f0b4)
+ cvsimport: work around perl tzset issue
+ git-cvsimport: allow author-specific timezones
Allows "cvsimport" to read per-author timezone from the author info
file.
Will merge to 'master' in the fifth batch.
* 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.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
- apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Extra set of eyeballs appreciated.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
- config: exit on error accessing any config file
- doc: advertise GIT_CONFIG_NOSYSTEM
- config: treat user and xdg config permission problems as errors
- config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT; I think a bit more refactored approach to consistently
address permission errors across config, exclude and attrs is
desirable. Don't we also need a check for an opposite situation
where we open .config/git/config or .gitattributes for reading but
they turn out to be directories?
* as/check-ignore (2012-11-08) 14 commits
- t0007: fix tests on Windows
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
Duy helped to reroll this.
Expecting a re-roll.
* so/prompt-command (2012-10-17) 4 commits
(merged to 'next' on 2012-10-25 at 79565a1)
+ coloured git-prompt: paint detached HEAD marker in red
+ Fix up colored git-prompt
+ show color hints based on state of the git tree
+ Allow __git_ps1 to be used in PROMPT_COMMAND
Updates __git_ps1 so that it can be used as $PROMPT_COMMAND,
instead of being used for command substitution in $PS1, to embed
color escape sequences in its output.
Will cook in 'next'.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* nd/wildmatch (2012-10-15) 13 commits
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
Will cook in 'next'.
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* nd/pretty-placeholder-with-color-option (2012-09-30) 9 commits
. pretty: support %>> that steal trailing spaces
. pretty: support truncating in %>, %< and %><
. pretty: support padding placeholders, %< %> and %><
. pretty: two phase conversion for non utf-8 commits
. utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
. utf8.c: move display_mode_esc_sequence_len() for use by other functions
. pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)
. pretty: split parsing %C into a separate function
. pretty: share code between format_decoration and show_decorations
This causes warnings with -Wuninitialized, so I've ejected it from pu
for the time being.
* jc/maint-fetch-tighten-refname-check (2012-10-19) 1 commit
(merged to 'next' on 2012-11-04 at eda85ef)
+ get_fetch_map(): tighten checks on dest refs
This was split out from discarded jc/maint-push-refs-all topic.
Will merge to 'master' in the fifth batch.
* jh/symbolic-ref-d (2012-10-21) 1 commit
(merged to 'next' on 2012-11-04 at b0762f5)
+ git symbolic-ref --delete $symref
Add "symbolic-ref -d SYM" to delete a symbolic ref SYM.
It is already possible to remove a symbolic ref with "update-ref -d
--no-deref", but it may be a good addition for completeness.
Will merge to 'master' in the fifth batch.
* jh/update-ref-d-through-symref (2012-10-21) 2 commits
- Fix failure to delete a packed ref through a symref
- t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
"update-ref -d --deref SYM" to delete a ref through a symbolic ref
that points to it did not remove it correctly.
* jk/config-ignore-duplicates (2012-10-29) 9 commits
(merged to 'next' on 2012-10-29 at 67fa0a2)
+ builtin/config.c: Fix a sparse warning
(merged to 'next' on 2012-10-25 at 233df08)
+ git-config: use git_config_with_options
+ git-config: do not complain about duplicate entries
+ git-config: collect values instead of immediately printing
+ git-config: fix regexp memory leaks on error conditions
+ git-config: remove memory leak of key regexp
+ t1300: test "git config --get-all" more thoroughly
+ t1300: remove redundant test
+ t1300: style updates
Drop duplicate detection from git-config; this lets it
better match the internal config callbacks, which clears up
some corner cases with includes.
Will cook in 'next'.
* ph/submodule-sync-recursive (2012-10-29) 2 commits
(merged to 'next' on 2012-11-04 at a000f78)
+ Add tests for submodule sync --recursive
+ Teach --recursive to submodule sync
Adds "--recursive" option to submodule sync.
Will merge to 'master' in the fifth batch.
* 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.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Needs review.
* jk/maint-diff-grep-textconv (2012-10-28) 1 commit
(merged to 'next' on 2012-11-04 at 790337b)
+ diff_grep: use textconv buffers for add/deleted files
(this branch is used by jk/pickaxe-textconv.)
Fixes inconsistent use of textconv with "git log -G".
Will merge to 'master' in the fifth batch.
* jk/pickaxe-textconv (2012-10-28) 2 commits
- pickaxe: use textconv for -S counting
- pickaxe: hoist empty needle check
(this branch uses jk/maint-diff-grep-textconv.)
Use textconv filters when searching with "log -S".
Waiting for a sanity check and review from Junio.
* as/maint-doc-fix-no-post-rewrite (2012-11-02) 1 commit
(merged to 'next' on 2012-11-09 at 117a91e)
+ commit: fixup misplacement of --no-post-rewrite description
Will merge to 'master' in the fifth batch.
* 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'.
* 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'.
* jk/maint-http-half-auth-fetch (2012-10-31) 2 commits
(merged to 'next' on 2012-11-09 at af69926)
+ remote-curl: retry failed requests for auth even with gzip
+ remote-curl: hoist gzip buffer size to top of post_rpc
Fixes fetch from servers that ask for auth only during the actual
packing phase. This is not really a recommended configuration, but it
cleans up the code at the same time.
Will merge to 'master' in the sixth batch.
* js/hp-nonstop (2012-10-30) 1 commit
(merged to 'next' on 2012-11-09 at fe58205)
+ fix 'make test' for HP NonStop
Will merge to 'master' in the fifth batch.
* kb/preload-index-more (2012-11-02) 1 commit
(merged to 'next' on 2012-11-09 at a750ebd)
+ update-index/diff-index: use core.preloadindex to improve performance
Use preloadindex in more places, which has a nice speedup on systems
with slow stat calls (and even on Linux).
Will merge to 'master' in the sixth batch.
* mh/notes-string-list (2012-11-08) 5 commits
(merged to 'next' on 2012-11-09 at 7a4c58c)
+ string_list_add_refs_from_colon_sep(): use string_list_split()
+ notes: fix handling of colon-separated values
+ combine_notes_cat_sort_uniq(): sort and dedup lines all at once
+ Initialize sort_uniq_list using named constant
+ string_list: add a function string_list_remove_empty_items()
Improve the asymptotic performance of the cat_sort_uniq notes merge
strategy.
Will merge to 'master' in the fifth batch.
* mh/strbuf-split (2012-11-04) 4 commits
(merged to 'next' on 2012-11-09 at fa984b1)
+ strbuf_split*(): document functions
+ strbuf_split*(): rename "delim" parameter to "terminator"
+ strbuf_split_buf(): simplify iteration
+ strbuf_split_buf(): use ALLOC_GROW()
Cleanups and documentation for strbuf_split.
Will merge to 'master' in the fifth batch.
* mm/maint-doc-commit-edit (2012-11-02) 1 commit
(merged to 'next' on 2012-11-09 at 8dab7f5)
+ Document 'git commit --no-edit' explicitly
Will merge to 'master' in the fifth batch.
^ permalink raw reply
* [PATCHv3 4/4] Add tests for git-status --sequencer
From: Phil Hord @ 2012-11-09 18:56 UTC (permalink / raw)
To: git
Cc: phil.hord, Jeff King, Junio C Hamano, konglu, Matthieu Moy,
Kong Lucien, Duperray Valentin, Jonas Franck, Nguy Thomas,
Phil Hord
In-Reply-To: <1352487385-5929-1-git-send-email-hordp@cisco.com>
Add t7061-status-sequence.sh with tests for the various
'git status --sequence' states.
I did not include tests for these states because I am not
sure how to induce these conditions organically yet:
conflicted am status
empty am status
rebase-interactive editing status
rebase-interactive splitting status
Signed-off-by: Phil Hord <hordp@cisco.com>
---
t/t7061-status-sequence.sh | 96 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 96 insertions(+)
create mode 100755 t/t7061-status-sequence.sh
diff --git a/t/t7061-status-sequence.sh b/t/t7061-status-sequence.sh
new file mode 100755
index 0000000..db99822
--- /dev/null
+++ b/t/t7061-status-sequence.sh
@@ -0,0 +1,96 @@
+#!/bin/sh
+
+test_description='sequencer state tokens'
+
+. ./test-lib.sh
+
+expect_tokens() {
+ for TOKEN in "$@" ; do
+ echo "## $TOKEN"
+ done | sort
+}
+
+status_has_only() {
+ expect_tokens "$@" >expect &&
+ git status -S | sort >actual &&
+ test_cmp expect actual
+}
+
+test_expect_success setup '
+ test_commit A &&
+ test_commit B oneside added &&
+ git checkout A^0 &&
+ test_commit C oneside created
+'
+
+test_expect_success 'status -S reports conflicted merge' '
+ git checkout B^0 &&
+ test_must_fail git merge C &&
+ status_has_only commit-pending conflicted merge
+'
+
+test_expect_success 'git reset --hard cleans up merge status' '
+ git reset --hard HEAD &&
+ status_has_only
+'
+
+test_expect_success 'status -S reports conflicted rebase' '
+ git reset --hard HEAD &&
+ git checkout B^0 &&
+ test_must_fail git rebase C &&
+ status_has_only conflicted rebase
+'
+
+test_expect_success 'git rebase --abort cleans up rebase status' '
+ git rebase --abort &&
+ status_has_only
+'
+
+test_expect_success 'status -S reports incomplete cherry-pick' '
+ git reset --hard HEAD &&
+ git checkout A &&
+ git cherry-pick --no-commit C &&
+ status_has_only commit-pending
+'
+
+test_expect_success 'completing commit cleans up pending commit status' '
+ git commit -mcompleted &&
+ status_has_only
+'
+
+test_expect_success 'status -S reports failed cherry-pick' '
+ git reset --hard HEAD &&
+ git checkout B &&
+ test_must_fail git cherry-pick C &&
+ status_has_only cherry-pick commit-pending conflicted
+'
+
+test_expect_success 'resolved conflicts clear conflicted status' '
+ git add oneside &&
+ status_has_only cherry-pick commit-pending
+'
+
+test_expect_success 'aborted cherry-pick clears cherry-pick status' '
+ git cherry-pick --abort &&
+ status_has_only
+'
+
+test_expect_success 'conflicted rebase-interactive status' '
+ git reset --hard HEAD &&
+ git checkout B &&
+ test_must_fail git rebase -i C &&
+ status_has_only rebase-interactive conflicted commit-pending
+'
+
+test_expect_success 'bisect status' '
+ git reset --hard HEAD &&
+ git bisect start &&
+ status_has_only bisect
+'
+
+test_expect_success 'bisect-reset clears bisect status' '
+ git bisect reset &&
+ status_has_only
+'
+
+test_done
--
1.8.0.3.gde9c7d5.dirty
^ permalink raw reply related
* [PATCHv3 3/4] git-status: show short sequencer state
From: Phil Hord @ 2012-11-09 18:56 UTC (permalink / raw)
To: git
Cc: phil.hord, Jeff King, Junio C Hamano, konglu, Matthieu Moy,
Kong Lucien, Duperray Valentin, Jonas Franck, Nguy Thomas,
Phil Hord
In-Reply-To: <1352487385-5929-1-git-send-email-hordp@cisco.com>
Teach git-status to report the sequencer state in short form
using a new --sequencer (-S) switch. Output zero or more
simple state token strings indicating the deduced state of the
git sequencer.
Sequencer state info tokens are displayed in "short"
form. 'git status --short -S' will show the normal short
status including the sequencer tokens. 'git status -S'
without --short will show only the new sequencer information
tokens in whatever the requested format is.
State token strings which may be emitted and their meanings:
merge a merge is in progress
am an am is in progress
am-is-empty the am patch is empty
rebase a rebase is in progress
rebase-interactive an interactive rebase is in progress
cherry-pick a cherry-pick is in progress
bisect a bisect is in progress
conflicted there are unresolved conflicts
commit-pending a commit operation is waiting to be completed
splitting interactive rebase, commit is being split
I also considered adding these tokens, but I decided it was not
appropriate since these changes are not sequencer-related. But
it is possible I am being too short-sighted or have chosen the
switch name poorly.
changed-index Changes exist in the index
changed-files Changes exist in the working directory
untracked New files exist in the working directory
Signed-off-by: Phil Hord <hordp@cisco.com>
---
Documentation/git-status.txt | 20 ++++++++++++++++++++
builtin/commit.c | 14 ++++++++++++++
wt-status.c | 34 ++++++++++++++++++++++++++++++++++
wt-status.h | 7 +++++++
4 files changed, 75 insertions(+)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 67e5f53..bdacf08 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -38,6 +38,26 @@ OPTIONS
across git versions and regardless of user configuration. See
below for details.
+-S::
+--sequence::
+ Show the git sequencer status. This shows zero or more words
+ describing the state of the git sequencer. If --short is also
+ given, the words are shown at the beginning of the short-format
+ display after the one-line branch information, if present. If
+ --short is not given, then only the sequencer words are shown
+ with no other status information.
++
+ merge a merge is in progress
+ am an am is in progress
+ am-is-empty the am patch is empty
+ rebase a rebase is in progress
+ rebase-interactive an interactive rebase is in progress
+ cherry-pick a cherry-pick is in progress
+ bisect a bisect is in progress
+ conflicted there are unresolved conflicts
+ commit-pending a commit operation is waiting to be completed
+ splitting interactive rebase, commit is being split
+
-u[<mode>]::
--untracked-files[=<mode>]::
Show untracked files.
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..bf16cc6 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1060,6 +1060,11 @@ static int parse_and_validate_options(int argc, const char *argv[],
if (s->null_termination && status_format == STATUS_FORMAT_LONG)
status_format = STATUS_FORMAT_PORCELAIN;
+ if (s->show_sequencer && status_format != STATUS_FORMAT_SHORT) {
+ s->show_sequencer = SHOW_SEQUENCER_ONLY;
+ if (status_format == STATUS_FORMAT_LONG)
+ status_format = STATUS_FORMAT_SHORT;
+ }
if (status_format != STATUS_FORMAT_LONG)
dry_run = 1;
@@ -1156,6 +1161,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
N_("show status concisely"), STATUS_FORMAT_SHORT),
OPT_BOOLEAN('b', "branch", &s.show_branch,
N_("show branch information")),
+ OPT_SET_INT('S', "sequencer", &s.show_sequencer,
+ N_("show sequencer state information"), SHOW_SEQUENCER_YES),
OPT_SET_INT(0, "porcelain", &status_format,
N_("machine-readable output"),
STATUS_FORMAT_PORCELAIN),
@@ -1188,6 +1195,11 @@ int cmd_status(int argc, const char **argv, const char *prefix)
if (s.null_termination && status_format == STATUS_FORMAT_LONG)
status_format = STATUS_FORMAT_PORCELAIN;
+ if (s.show_sequencer && status_format != STATUS_FORMAT_SHORT) {
+ s.show_sequencer = SHOW_SEQUENCER_ONLY;
+ if (status_format == STATUS_FORMAT_LONG)
+ status_format = STATUS_FORMAT_SHORT;
+ }
handle_untracked_files_arg(&s);
if (show_ignored_in_status)
@@ -1384,6 +1396,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
OPT_SET_INT(0, "short", &status_format, N_("show status concisely"),
STATUS_FORMAT_SHORT),
OPT_BOOLEAN(0, "branch", &s.show_branch, N_("show branch information")),
+ OPT_SET_INT(0, "sequencer", &s.show_sequencer,
+ N_("show sequencer state information"), SHOW_SEQUENCER_YES),
OPT_SET_INT(0, "porcelain", &status_format,
N_("machine-readable output"), STATUS_FORMAT_PORCELAIN),
OPT_BOOLEAN('z', "null", &s.null_termination,
diff --git a/wt-status.c b/wt-status.c
index a888120..71da1fb 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1201,6 +1201,33 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)
fputc(s->null_termination ? '\0' : '\n', s->fp);
}
+static void wt_print_token(struct wt_status *s, const char *token, int active)
+{
+ if (active) {
+ color_fprintf(s->fp, color(WT_STATUS_HEADER, s), "## %s", prefix, token);
+ fputc(s->null_termination ? '\0' : '\n', s->fp);
+ }
+}
+
+static void wt_sequencer_print(struct wt_status *s)
+{
+ struct wt_status_state state;
+
+ wt_status_get_state(s, &state);
+
+ wt_print_token(s, "merge", state.merge_in_progress);
+ wt_print_token(s, "am", state.am_in_progress);
+ wt_print_token(s, "rebase", state.rebase_in_progress);
+ wt_print_token(s, "rebase-interactive", state.rebase_interactive_in_progress);
+ wt_print_token(s, "cherry-pick", state.cherry_pick_in_progress);
+ wt_print_token(s, "bisect", state.bisect_in_progress);
+ wt_print_token(s, "am-empty", state.am_empty_patch);
+
+ wt_print_token(s, "conflicted", state.has_unmerged);
+ wt_print_token(s, "commit-pending", state.commit_is_pending);
+ wt_print_token(s, "splitting", state.split_in_progress);
+}
+
void wt_shortstatus_print(struct wt_status *s)
{
int i;
@@ -1208,6 +1235,13 @@ void wt_shortstatus_print(struct wt_status *s)
if (s->show_branch)
wt_shortstatus_print_tracking(s);
+ if (s->show_sequencer)
+ {
+ wt_sequencer_print(s);
+ if (s->show_sequencer == SHOW_SEQUENCER_ONLY)
+ return;
+ }
+
for (i = 0; i < s->change.nr; i++) {
struct wt_status_change_data *d;
struct string_list_item *it;
diff --git a/wt-status.h b/wt-status.h
index 0b866a2..df4b36d 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -24,6 +24,12 @@ enum untracked_status_type {
SHOW_ALL_UNTRACKED_FILES
};
+enum sequencer_status_type {
+ SHOW_SEQUENCER_NO=0,
+ SHOW_SEQUENCER_YES,
+ SHOW_SEQUENCER_ONLY
+};
+
/* from where does this commit originate */
enum commit_whence {
FROM_COMMIT, /* normal */
@@ -59,6 +65,7 @@ struct wt_status {
unsigned colopts;
int null_termination;
int show_branch;
+ enum sequencer_status_type show_sequencer;
/* These are computed during processing of the individual sections */
int commitable;
--
1.8.0.3.gde9c7d5.dirty
^ permalink raw reply related
* [PATCHv3 2/4] wt-status: Teach sequencer advice to use get_state
From: Phil Hord @ 2012-11-09 18:56 UTC (permalink / raw)
To: git
Cc: phil.hord, Jeff King, Junio C Hamano, konglu, Matthieu Moy,
Kong Lucien, Duperray Valentin, Jonas Franck, Nguy Thomas,
Phil Hord
In-Reply-To: <1352487385-5929-1-git-send-email-hordp@cisco.com>
wt_status_print_state retrieves some sequencer state information via
wt_status_get_state, but other state information it deduces on its
own. Replace these "local knowledge" deductions with wt_status
variables so we can share more common code in the future.
---
wt-status.c | 16 +++++++++-------
wt-status.h | 3 +++
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 760f52b..a888120 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -781,7 +781,7 @@ static void show_merge_in_progress(struct wt_status *s,
struct wt_status_state *state,
const char *color)
{
- if (has_unmerged(s)) {
+ if (state->has_unmerged) {
status_printf_ln(s, color, _("You have unmerged paths."));
if (advice_status_hints)
status_printf_ln(s, color,
@@ -867,9 +867,7 @@ static void show_rebase_in_progress(struct wt_status *s,
struct wt_status_state *state,
const char *color)
{
- struct stat st;
-
- if (has_unmerged(s)) {
+ if (state->has_unmerged) {
status_printf_ln(s, color, _("You are currently rebasing."));
if (advice_status_hints) {
status_printf_ln(s, color,
@@ -879,12 +877,12 @@ static void show_rebase_in_progress(struct wt_status *s,
status_printf_ln(s, color,
_(" (use \"git rebase --abort\" to check out the original branch)"));
}
- } else if (state->rebase_in_progress || !stat(git_path("MERGE_MSG"), &st)) {
+ } else if (state->rebase_in_progress || state->commit_is_pending) {
status_printf_ln(s, color, _("You are currently rebasing."));
if (advice_status_hints)
status_printf_ln(s, color,
_(" (all conflicts fixed: run \"git rebase --continue\")"));
- } else if (split_commit_in_progress(s)) {
+ } else if (state->split_in_progress) {
status_printf_ln(s, color, _("You are currently splitting a commit during a rebase."));
if (advice_status_hints)
status_printf_ln(s, color,
@@ -907,7 +905,7 @@ static void show_cherry_pick_in_progress(struct wt_status *s,
{
status_printf_ln(s, color, _("You are currently cherry-picking."));
if (advice_status_hints) {
- if (has_unmerged(s))
+ if (state->has_unmerged)
status_printf_ln(s, color,
_(" (fix conflicts and run \"git commit\")"));
else
@@ -955,6 +953,10 @@ static void wt_status_get_state(struct wt_status *s , struct wt_status_state *st
}
if (!stat(git_path("BISECT_LOG"), &st))
state->bisect_in_progress = 1;
+
+ state->has_unmerged = has_unmerged(s);
+ state->split_in_progress = split_commit_in_progress(s);
+ state->commit_is_pending = !stat(git_path("MERGE_MSG"), &st);
}
static void wt_status_print_state(struct wt_status *s)
diff --git a/wt-status.h b/wt-status.h
index 236b41f..0b866a2 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -79,6 +79,9 @@ struct wt_status_state {
int rebase_interactive_in_progress;
int cherry_pick_in_progress;
int bisect_in_progress;
+ int split_in_progress;
+ int has_unmerged;
+ int commit_is_pending;
};
void wt_status_prepare(struct wt_status *s);
--
1.8.0.3.gde9c7d5.dirty
^ permalink raw reply related
* [PATCHv3 1/4] Refactor print_state into get_state
From: Phil Hord @ 2012-11-09 18:56 UTC (permalink / raw)
To: git
Cc: phil.hord, Jeff King, Junio C Hamano, konglu, Matthieu Moy,
Kong Lucien, Duperray Valentin, Jonas Franck, Nguy Thomas,
Phil Hord
In-Reply-To: <1352487385-5929-1-git-send-email-hordp@cisco.com>
Recently git-status learned to display the state of the git
sequencer in long form to help the user remember an interrupted
command. This information is useful to other callers who do
not want it printed in the same way.
Split the new print_state function into separate get_state and
print_state functions so others can get this state info and
share common code.
Signed-off-by: Phil Hord <hordp@cisco.com>
---
wt-status.c | 31 +++++++++++++++++++------------
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 2a9658b..760f52b 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -928,34 +928,41 @@ static void show_bisect_in_progress(struct wt_status *s,
wt_status_print_trailer(s);
}
-static void wt_status_print_state(struct wt_status *s)
+static void wt_status_get_state(struct wt_status *s , struct wt_status_state *state)
{
- const char *state_color = color(WT_STATUS_HEADER, s);
- struct wt_status_state state;
struct stat st;
- memset(&state, 0, sizeof(state));
+ memset(state, 0, sizeof(*state));
+ /* Determine sequencer activity */
if (!stat(git_path("MERGE_HEAD"), &st)) {
- state.merge_in_progress = 1;
+ state->merge_in_progress = 1;
} else if (!stat(git_path("rebase-apply"), &st)) {
if (!stat(git_path("rebase-apply/applying"), &st)) {
- state.am_in_progress = 1;
+ state->am_in_progress = 1;
if (!stat(git_path("rebase-apply/patch"), &st) && !st.st_size)
- state.am_empty_patch = 1;
+ state->am_empty_patch = 1;
} else {
- state.rebase_in_progress = 1;
+ state->rebase_in_progress = 1;
}
} else if (!stat(git_path("rebase-merge"), &st)) {
if (!stat(git_path("rebase-merge/interactive"), &st))
- state.rebase_interactive_in_progress = 1;
+ state->rebase_interactive_in_progress = 1;
else
- state.rebase_in_progress = 1;
+ state->rebase_in_progress = 1;
} else if (!stat(git_path("CHERRY_PICK_HEAD"), &st)) {
- state.cherry_pick_in_progress = 1;
+ state->cherry_pick_in_progress = 1;
}
if (!stat(git_path("BISECT_LOG"), &st))
- state.bisect_in_progress = 1;
+ state->bisect_in_progress = 1;
+}
+
+static void wt_status_print_state(struct wt_status *s)
+{
+ const char *state_color = color(WT_STATUS_HEADER, s);
+ struct wt_status_state state;
+
+ wt_status_get_state(s, &state);
if (state.merge_in_progress)
show_merge_in_progress(s, &state, state_color);
--
1.8.0.3.gde9c7d5.dirty
^ permalink raw reply related
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