Re: What's cooking in git.git (May 2013, #05; Mon, 20)
Junio C Hamano gits...@pobox.com writes:
* tr/test-v-and-v-subtest-only (2013-05-16) 6 commits
- test-lib: support running tests under valgrind in parallel
- test-lib: allow prefixing a custom string before ok N etc.
- test-lib: valgrind for only tests matching a pattern
- test-lib: verbose mode for only tests matching a pattern
- test-lib: refactor $GIT_SKIP_TESTS matching
- test-lib: enable MALLOC_* for the actual tests
Allows N instances of tests run in parallel, each running 1/N parts
of the test suite under Valgrind, to speed things up.
The tip one may be useful in practice but is a tad ugly ;-)
I was hoping for some success stories ;-)
I think Peff (who I stupidly managed to not Cc in the series, there's
another git-send-email usability issue there) asked for the third from
the tip, which lets you run valgrind only on a certain test. (For
example, if you've already had two coffees while your computer found out
which test it was, this is a much faster way of seeing if the failure
disappeared.)
So one obvious way of going forward is cooking this for a while and
seeing whether people find the one-test-only or the massively-parallel
feature useful (or maybe both).
[To anyone who just reads this, but did not see the original series, I
should also point out that this only applies within a t-foo.sh test
file. You can already parallelize a full valgrind test run much better
than the above.]
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Contributing to git: cleaner git -rm add configuration options
[+CC: Matthieu Moy] Mathieu Liénard--Mayor wrote: -Cleaner error message when git rm fails with multiple files Should be fairly straightforward to implement. Just collect the errors and print them out at once. -Add configuration options for some commonly used command-line options I'd really like status.short, status.branch, am.scissors and am.3way. Should be fairly straightforward to implement, although others might have different opinions on the names of the configuration variables. Also, I've taken the liberty to remove three ideas from the list: jk/fetch-always-update-tracking, vv/help-unknown-ref, and rr/rebase-autostash are already in `pu` and will hit `master` soon. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
From: Junio C Hamano gits...@pobox.com
Sent: Monday, May 20, 2013 11:22 PM
Philip Oakley philipoak...@iee.org writes:
So we can have a branch whose remote is '.'
_and_ a remote whose URL is '.'
Yes, and they are two separate concepts.
Thank you of the confirmation.
git fetch while on mywork branch with this:
[branch mywork]
remote = git://git.k.org/pub/scm/git/git.git
merge = refs/heads/master
without having any named remote whose remote.$name.url is set to
that URL may happen to work but it is by accident as far as I know.
Interesting. Any thoughts on which way it should be
documented/deprecated?
As you do not copy to any remote tracking branches, @{u} would not
work, so it is not something useful. But on the other hand
[branch mywork]
remote = .
merge = refs/heads/master
works _as if_ you have
Thank you of the confirmation.
[remote .]
url = .
;; no fetch refspec like +refs/heads/*:refs/heads/*
;; no push refspec like +refs/heads/*:refs/heads/*
so in that sense, you _could_ think of branch.$name.remote as a
(generic) URL or a name of a (special) remote, but it is easier to
think about it as the latter.
Yes.
And remote.$name.url = . for any name, e.g.
[remote here]
url = .
is a special case of local repository that is named with a relative
filesystem path.
Can there be a clash with a named remote that is actually '.', where
the push/fetch is actually a no-op?
Nobody sane would do it in the first place, so...
Oh I don't know. I don't think 'sanity' comes into it any more than
'common sense' is common. It's easy to fall into the inverse
Kruger-Dunning mode where those in the know don't realise how much they
know, and how 'stupid' those that don't can be (that'd be me;-).
All this 'what's a dot-repo and where can I use it' came about because
of an answer that give it's use as a 'trick'.
On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder jrnie...@gmail.com
wrote:
Another trick is to use git push:
git push . $production_sha1:refs/heads/master
and
Filipe gave 'git fetch .' in [PATCH 1/3] fetch: add --allow-local
option, 16 May 2013
Philip
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash
On Mon, May 20, 2013 at 03:36:58PM -0700, Junio C Hamano wrote: Dmitry Marakasov amd...@amdmi3.ru writes: Use /bin/sh interpreter instead of /bin/bash for contrib/git-subtree: it's required for systems which don't use bash by default (for example, FreeBSD), while there seem to be no bashisms in the script (confirmed by looking through the source and tesing subtree functionality with FreeBSD's /bin/sh) to require specifically bash and not the generic posix shell. Has anybody audited to make sure that the script itself is free of bash-isms? I somehow had an impression that in the past it was littered with bash-isms like function local variables and array variables and assumed that the #!/bin/bash was necessary. I did a quick eyeballing and did not see anything glaringly bash-only, but I may have missed something (the coding style is so different from the core part of Git Porcelains and distracting for me to efficiently do a good job of scanning). I ran the test suite with dash and everything passed. checkbashisms doesn't find any problems either. Signed-off-by: Dmitry Marakasov amd...@amdmi3.ru --- contrib/subtree/git-subtree.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index 8a23f58..5701376 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -1,4 +1,4 @@ -#!/bin/bash +#!/bin/sh # # git-subtree.sh: split/join git repositories in subdirectories of this one # -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Workflow Help
On Tue, May 21, 2013 at 10:59:17AM +1000, Quilkey, Tony wrote: I am looking at formulating and then documenting our vcs workflow using Git at work. I have an idea of how I want things to work, but am a little hazy on some of the details. Our basic workflow will be based around: http://nvie.com/posts/a-successful-git-branching-model, with a few exceptions. We would like to create our release-* branches from the last release tag. From there, we would like the ability to cherry pick (or take the complete diff) commits from the develop branch. So, we are after is: 1) Create topic (feature) branches from develop, and merge back into develop when complete. 2) Once it is decided we are packaging a release, make a release-* branch from the previous release tag. 3) Cherry pick/merge/whatever any commits we want from develop into the new release-* until it is complete. 4) Merge the new release-* branch into master and tag it. Repeat as necessary. At the moment I am a little stuck on how exactly we can cherry pick stuff from develop into a release-* branch. I'm not even sure this approach is exactly what we should be doing. Having been involved in a couple of projects that use cherry-pick like this, I strongly advise against doing this. It makes it much harder than it needs to be to find out which branches contain a particular commit. The workflow described in the URL above does the more sensible thing of periodically merging the release branch(es) back into master (or develop). This is similar to the workflow Junio uses to develop Git itself, which is described in gitworkflows(7). The idea is to start your topic branch from the oldest release to which a bugfix must be applied, then merge it into the appropriate release branches. Then you merge this branch upwards into the later release branches and your development branch. So your development branch always contains all release branches (not just similar commits, but the *same* commits so that each release branch tip is an ancestor of the development branch's tip). This means that you can use git branch --contains or git describe --contains to answer the question which release(s) contain this commit?, whereas with cherry picking there is no easy and reliable way to do so. Our main concern is that at this stage, there is no guarantee that all commits within develop can be pulled into a release. One advantage of starting a bugfix topic branch from the oldest release it applies to is that you are developing and testing that fix on the release code. If it doesn't apply cleanly to the development branch then you fix the conflict when merging. Of course you may start a bugfix branch from the wrong place, in which case you would have to cherry pick the commits back to an older branch, but this should be a rare occurrence and will sort itself out as you merge the fix upwards. In regards to how we can achieve the above results any input would be much appreciated. Or if there are any other better options available, I'm all ears. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Fix invalid revision error messages for 1.8.3
Hi,
Seeing other patches on the list, I decided that I should do something
for 1.8.3 as well (as opposed to constantly writing new features). So
here's my contribution.
The first error message has annoyed me endlessly, and I took this
opportunity to fix it. Interested people can sprinkle in some advice
later. The second one is a low-hanging while we're there.
Thanks.
Ramkumar Ramachandra (2):
sha1_name: fix error message for @{u}
sha1_name: fix error message for @{N}, @{date}
sha1_name.c | 17 +++--
t/t1507-rev-parse-upstream.sh | 15 +--
2 files changed, 16 insertions(+), 16 deletions(-)
--
1.8.3.rc3.6.ga9126d5.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] sha1_name: fix error message for @{u}
Currently, when no (valid) upstream is configured for a branch, we get
an error like:
$ git show @{u}
error: No upstream configured for branch 'upstream-error'
error: No upstream configured for branch 'upstream-error'
fatal: ambiguous argument '@{u}': unknown revision or path not in the working
tree.
Use '--' to separate paths from revisions, like this:
'git command [revision...] -- [file...]'
The error: line actually appears twice, and the rest of the error
message is useless. In sha1_name.c:interpret_branch_name(), there is
really no point in processing further if @{u} couldn't be resolved, and
we might as well die() instead of returning an error(). After making
this change, you get:
$ git show @{u}
fatal: No upstream configured for branch 'upstream-error'
Also tweak a few tests in t1507 to expect this output.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 13 +++--
t/t1507-rev-parse-upstream.sh | 15 +--
2 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 3820f28..416a673 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -1033,14 +1033,15 @@ int interpret_branch_name(const char *name, struct
strbuf *buf)
* points to something different than a branch.
*/
if (!upstream)
- return error(_(HEAD does not point to a branch));
+ die(_(HEAD does not point to a branch));
if (!upstream-merge || !upstream-merge[0]-dst) {
if (!ref_exists(upstream-refname))
- return error(_(No such branch: '%s'), cp);
- if (!upstream-merge)
- return error(_(No upstream configured for branch
'%s'),
-upstream-name);
- return error(
+ die(_(No such branch: '%s'), cp);
+ if (!upstream-merge) {
+ die(_(No upstream configured for branch '%s'),
+ upstream-name);
+ }
+ die(
_(Upstream branch '%s' not stored as a remote-tracking
branch),
upstream-merge[0]-src);
}
diff --git a/t/t1507-rev-parse-upstream.sh b/t/t1507-rev-parse-upstream.sh
index b27a720..2a19e79 100755
--- a/t/t1507-rev-parse-upstream.sh
+++ b/t/t1507-rev-parse-upstream.sh
@@ -129,8 +129,7 @@ test_expect_success 'branch@{u} works when tracking a local
branch' '
test_expect_success 'branch@{u} error message when no upstream' '
cat expect -EOF
- error: No upstream configured for branch ${sq}non-tracking${sq}
- fatal: Needed a single revision
+ fatal: No upstream configured for branch ${sq}non-tracking${sq}
EOF
error_message non-tracking@{u} 2actual
test_i18ncmp expect actual
@@ -138,8 +137,7 @@ test_expect_success 'branch@{u} error message when no
upstream' '
test_expect_success '@{u} error message when no upstream' '
cat expect -EOF
- error: No upstream configured for branch ${sq}master${sq}
- fatal: Needed a single revision
+ fatal: No upstream configured for branch ${sq}master${sq}
EOF
test_must_fail git rev-parse --verify @{u} 2actual
test_i18ncmp expect actual
@@ -147,8 +145,7 @@ test_expect_success '@{u} error message when no upstream' '
test_expect_success 'branch@{u} error message with misspelt branch' '
cat expect -EOF
- error: No such branch: ${sq}no-such-branch${sq}
- fatal: Needed a single revision
+ fatal: No such branch: ${sq}no-such-branch${sq}
EOF
error_message no-such-branch@{u} 2actual
test_i18ncmp expect actual
@@ -156,8 +153,7 @@ test_expect_success 'branch@{u} error message with misspelt
branch' '
test_expect_success '@{u} error message when not on a branch' '
cat expect -EOF
- error: HEAD does not point to a branch
- fatal: Needed a single revision
+ fatal: HEAD does not point to a branch
EOF
git checkout HEAD^0
test_must_fail git rev-parse --verify @{u} 2actual
@@ -166,8 +162,7 @@ test_expect_success '@{u} error message when not on a
branch' '
test_expect_success 'branch@{u} error message if upstream branch not fetched' '
cat expect -EOF
- error: Upstream branch ${sq}refs/heads/side${sq} not stored as a
remote-tracking branch
- fatal: Needed a single revision
+ fatal: Upstream branch ${sq}refs/heads/side${sq} not stored as a
remote-tracking branch
EOF
error_message bad-upstream@{u} 2actual
test_i18ncmp expect actual
--
1.8.3.rc3.6.ga9126d5.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] sha1_name: fix error message for @{N}, @{date}
Currently, when we try to resolve @{N} or @{date} when the reflog
for the current branch doesn't go back far enough, we get errors like:
$ git show @{1}
fatal: Log for '' only has 7 entries.
$ git show @{1.days.ago}
warning: Log for '' only goes back to Tue, 21 May 2013 14:14:45 +0530.
...
The empty string '' looks ugly and inconsistent with the output of
branch@{N}. Replace it with the string 'current branch'.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 4
1 file changed, 4 insertions(+)
diff --git a/sha1_name.c b/sha1_name.c
index 416a673..683b4bd 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -517,6 +517,10 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
}
if (read_ref_at(real_ref, at_time, nth, sha1, NULL,
co_time, co_tz, co_cnt)) {
+ if (!len) {
+ str = current branch;
+ len = strlen(current branch);
+ }
if (at_time)
warning(Log for '%.*s' only goes
back to %s., len, str,
--
1.8.3.rc3.6.ga9126d5.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: your mail
On Friday, May 17, 2013 at 14:02 EDT, ASHISH VERMA ashunew1...@gmail.com wrote: Hi, i am using git to push my code from eclipse to heroku , but recently iam getting error like:: master:master rejected:non fast forward and i am not able to resolve it .I tried a git pull but that says - conflicts shud be resolved before git pull can be implemented.I can;t find the solution Please help ASAP... Resolve the conflicts by either hand-editing the files (you'll see the markers where the conflicts are) add running 'git add' to tell git that you're done resolving them, or set up Git to use a graphical tool like kdiff3. When you're done, run 'git commit' to create the merge commit. After that you'll be able to push to your upstream (unless things have moved again while you were resolving the initial conflict). This guide to merge conflicts looks pretty good: http://gitguru.com/2009/02/22/integrating-git-with-a-visual-merge-tool/ -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Workflow Help
On Monday, May 20, 2013 at 20:59 EDT, Quilkey, Tony t...@thorpesystems.com wrote: I am looking at formulating and then documenting our vcs workflow using Git at work. I have an idea of how I want things to work, but am a little hazy on some of the details. Our basic workflow will be based around: http://nvie.com/posts/a-successful-git-branching-model, with a few exceptions. We would like to create our release-* branches from the last release tag. From there, we would like the ability to cherry pick (or take the complete diff) commits from the develop branch. It would probably be easier to comment on your proposal if you motivated why you want to diverge. So, we are after is: 1) Create topic (feature) branches from develop, and merge back into develop when complete. 2) Once it is decided we are packaging a release, make a release-* branch from the previous release tag. 3) Cherry pick/merge/whatever any commits we want from develop into the new release-* until it is complete. The point of having a release branch is typically to slow down the development pace and reduce risk by only adding changes that you really need. By starting the branch for release N+1 from the branch for release N it seems you have three ways forward: - Cherrypick a small number of commits from develop. That'll give you release N+0.1 rather than N+1. - Cherrypick many (if not most) commits from develop. That might give you a real release, but with a lot of work. Who should select which commits to cherrypick? How do you keep track of dependencies? Why would you want to move from a known state (develop, where people spend most of their time) to an unknown state? - Merge from develop to the release branch. What's the benefit compared to cutting the release branch directly from develop? As another poster has pointed out, with merging instead of cherrypicking the standard Git tools will be able to do a better job at helping you track which corrections are made where. [...] -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Workflow Help
On 2013-05-21 02:59, Quilkey, Tony wrote: Hi, I am looking at formulating and then documenting our vcs workflow using Git at work. I have an idea of how I want things to work, but am a little hazy on some of the details. Our basic workflow will be based around: http://nvie.com/posts/a-successful-git-branching-model, with a few exceptions. We would like to create our release-* branches from the last release tag. From there, we would like the ability to cherry pick (or take the complete diff) commits from the develop branch. So, we are after is: 1) Create topic (feature) branches from develop, and merge back into develop when complete. 2) Once it is decided we are packaging a release, make a release-* branch from the previous release tag. 3) Cherry pick/merge/whatever any commits we want from develop into the new release-* until it is complete. This will drive you crazy. If you have any sort of tempo on development and separate your commits into small series, it will be close to impossible to track all related changes. I know, as some colleagues tried it not long ago. A better workflow is to use topic-branches for pretty much everything. If the branch is mainly a bugfix, although the bug has to be fixed by refactoring or remodeling something, it gets merged to whatever maint branch you have (in your case I'd imagine that would be release-X something). Then you merge the release-branch into develop and take the other topics directly into develop. We do something like this: * work, work, work (mostly on master) * cut a release by setting a tag and creating a maint-branch for it (actually, it's a beta-release that goes off to QA, but whatever) * maint branches are 100% test-driven development * bugfixes (with their test-cases, as well as test-cases for other affected areas) go directly to maint (although possibly via a topic-branch if the change is bigger than trivial). * maint is merged to master * repeat as necessary It works reasonably well and ensures a high code quality with very little overhead. Sometimes people commit bugfixes to master by mistake. In that case, we simply cherry-pick the fix to 'maint' and then merge maint back to master as usual. It does require some sort of stability between projects and the libs shipped by and used by the project though, but assuming you haven't done things horribly wrong at the design stage, this model should work reasonably well while avoiding the whole where are the bugfixes and in which order do I need to apply them? issue. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (May 2013, #04; Wed, 15)
Thomas Rast tr...@inf.ethz.ch writes: Junio C Hamano gits...@pobox.com writes: In addition to your topic, it may be a good idea to notice this at the Porcelain level (e.g. checkout -b and branch, but not at the update-ref level) and warn or even die if a Porcelain tries to create a branch with such a name. But if we're going there and deprecating some ways of naming refs, This is not about deprecating but is discouraging a confusing use at the Porcelain level (i.e. enforcing one policy decision that may not apply to those who wrote their own workflow using plumbing commands, knowing and following the full 40-hex is taken as an object name, not a dwimmed ref rule---to them there is no ambiguities). I think I see where you are going and I do not necessarily disagree with that, but it is a separate topic. please also disallow some other funny things in the same go. Michael suggested this earlier in some thread: the fewer ways we have of legally spelling refnames, the more syntax is available for revision syntax. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (May 2013, #05; Mon, 20)
Johan Herland jo...@herland.net writes: On Tue, May 21, 2013 at 2:15 AM, Junio C Hamano gits...@pobox.com wrote: * jh/shorten-refname (2013-05-07) 4 commits - t1514: refname shortening is done after dereferencing symbolic refs - shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin - t1514: Demonstrate failure to correctly shorten refs/remotes/origin/HEAD - t1514: Add tests of shortening refnames in strict/loose mode When remotes/origin/HEAD is not a symbolic ref, rev-parse --abbrev-ref remotes/origin/HEAD ought to show origin, not origin/HEAD, which is fixed with this series (if it is a symbolic ref that points at remotes/origin/something, then it should show origin/something and it already does). I think this is being rerolled using strbuf_expand(). Actually, that was not on my TODO. Sure, my other series ([PATCHv2 00/10] Prepare for alternative remote-tracking branch location) builds on top of this one, and changes a lot of the same code, but I considered jh/shorten-refname a good set of changes in its own right, and I didn't want it to be held up by the much longer (and probably much longer-running) series. On the other hand, this itself is fixing the case nobody encounters in real life, and in that sense it is not urgent at all even though it may be a correct fix, no? When was the last time you saw a refs/remotes/*/HEAD that is not a symbolic ref? If it makes it is easier for you to work on the follow-on series to have this shorter one already cast in stone, I do not mind merging this early post 1.8.3 cycle at all. If on the other hand you are hit by a realization that this part could be done in a different and a better way (I am not saying that that is the likely outcome) when you will look at redoing the follow-on series using strbuf_expand post 1.8.3, we would regret it if we cast this part in stone too early. I think we can go either way, and the above I think this is being rerolld was primarily keeping the options open. The strbuf_expand refactoring is nice, but not really necessary until we start using multi-wildcard patterns. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (May 2013, #05; Mon, 20)
Thomas Rast tr...@inf.ethz.ch writes: Junio C Hamano gits...@pobox.com writes: * tr/test-v-and-v-subtest-only (2013-05-16) 6 commits - test-lib: support running tests under valgrind in parallel - test-lib: allow prefixing a custom string before ok N etc. - test-lib: valgrind for only tests matching a pattern - test-lib: verbose mode for only tests matching a pattern - test-lib: refactor $GIT_SKIP_TESTS matching - test-lib: enable MALLOC_* for the actual tests Allows N instances of tests run in parallel, each running 1/N parts of the test suite under Valgrind, to speed things up. The tip one may be useful in practice but is a tad ugly ;-) I was hoping for some success stories ;-) I think Peff (who I stupidly managed to not Cc in the series, there's another git-send-email usability issue there) asked for the third from the tip, which lets you run valgrind only on a certain test. (For Yes, I think that that change is a very good thing to do. example, if you've already had two coffees while your computer found out which test it was, this is a much faster way of seeing if the failure disappeared.) So one obvious way of going forward is cooking this for a while and seeing whether people find the one-test-only or the massively-parallel feature useful (or maybe both). [To anyone who just reads this, but did not see the original series, I should also point out that this only applies within a t-foo.sh test file. You can already parallelize a full valgrind test run much better than the above.] -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
Sent: Monday, May 20, 2013 11:22 PM
Philip Oakley philipoak...@iee.org writes:
So we can have a branch whose remote is '.'
_and_ a remote whose URL is '.'
Yes, and they are two separate concepts.
Thank you of the confirmation.
git fetch while on mywork branch with this:
[branch mywork]
remote = git://git.k.org/pub/scm/git/git.git
merge = refs/heads/master
without having any named remote whose remote.$name.url is set to
that URL may happen to work but it is by accident as far as I know.
Interesting. Any thoughts on which way it should be
documented/deprecated?
If leave it as-is is not an option, I personally would prefer
mentioning this happens to work, but do not rely on it in the
passing. I do not see any immediate need to break things for people
discovered that this happens to work and who decided that they have
no need for a remote tracking branch for the particular remote this
branch happens to integrate with. By making that choice, they may
be forgoing the use of @{u}, but they won't be inconvenienced as
git fetch will leave what they need @{u} for in FETCH_HEAD, i.e.
instead of doing
git fetch
git log [-p] ..@{u}
git merge @{u} ;# or git rebase @{u}
as a verify in the middle replacement for git pull [--rebase],
they can do
git fetch
git log [-p] ..FETCH_HEAD
git merge FETCH_HEAD ;# or git rebase FETCH_HEAD
just fine.
The do not rely on it is primarily because there are more familiar
ways invented later (namely, use a named remote instead of writing a
real URL, with remote tracking branches). I do not think we would
want to deliberately sabotage the people who currently use such a
setting, but I do not see a strong reason to recommend it to people
who are new to Git, either, *unless* they need to fetch from many
different places and do not want to have remote tracking branches
because the only time they care about the state of their remotes is
immediately after they fetched.
Can there be a clash with a named remote that is actually '.', where
the push/fetch is actually a no-op?
Nobody sane would do it in the first place, so...
Oh I don't know. I don't think 'sanity' comes into it any more than
common sense' is common. It's easy to fall into the inverse
Kruger-Dunning mode where those in the know don't realise how much
they know, and how 'stupid' those that don't can be (that'd be me;-).
How would you even express such a remote named . in the first
place? git remote add would not let you say:
$ git remote add . git://some.where.xz/some/repo.git
fatal: '.' is not a valid remote name
and even if you add configuration variables by hand, it would not
look like this:
[remote .]
fetch = +refs/heads/*:refs/remotes/./*
You would want some real token between refs/remotes/ and the
trailing /* instead, so...
All this 'what's a dot-repo and where can I use it' came about because
of an answer that give it's use as a 'trick'.
On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder jrnie...@gmail.com
wrote:
Another trick is to use git push:
git push . $production_sha1:refs/heads/master
It all falls out naturally from the Git is distributed and no
repository is special principle. I think that word trick merely
refers to those who do not realize that the local repository is not
all that special and merely is _a_ repository just like anybody
else's may not realize they can do this, nothing more.
Filipe gave 'git fetch .' in [PATCH 1/3] fetch: add --allow-local
option, 16 May 2013
That patch came from a mistaken suggestion from me that was
retracted with
http://article.gmane.org/gmane.comp.version-control.git/224729
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix invalid revision error messages for 1.8.3
Ramkumar Ramachandra artag...@gmail.com writes: Seeing other patches on the list, I decided that I should do something for 1.8.3 as well Fixes to something that are broken the same way between 'master' and older release versions are the same as enhancements (which you can view as fix to lack of feature). They are not regression fixes and not for 1.8.3 at this point in the cycle, deep into -rc. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sha1_name: fix error message for @{u}
Ramkumar Ramachandra artag...@gmail.com writes:
Currently, when no (valid) upstream is configured for a branch, we get
an error like:
$ git show @{u}
error: No upstream configured for branch 'upstream-error'
error: No upstream configured for branch 'upstream-error'
fatal: ambiguous argument '@{u}': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions, like this:
'git command [revision...] -- [file...]'
The error: line actually appears twice, and the rest of the error
message is useless. In sha1_name.c:interpret_branch_name(), there is
really no point in processing further if @{u} couldn't be resolved, and
we might as well die() instead of returning an error(). After making
this change, you get:
$ git show @{u}
fatal: No upstream configured for branch 'upstream-error'
Also tweak a few tests in t1507 to expect this output.
Does a failure in interpret-branch-name that issue these error
messages always followed by die() in the caller? I know you looked
at the cases you noticed as an end-user (like the above git show @{u}
example), but if some codepaths did this:
if (interpret-branch-name()) {
you do not seem to have upstream defined,
so I will helpfully do something else that
you probably have meant.
}
this patch will break that codepath you did not look.
I do not offhand know if there is such a codepath, so if you did a
code audit and know this patch is regression-free, please say that
in the log message. I ran all the tests and they passed is not
good enough.
Other than that, the idea sounds OK.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 13 +++--
t/t1507-rev-parse-upstream.sh | 15 +--
2 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 3820f28..416a673 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -1033,14 +1033,15 @@ int interpret_branch_name(const char *name, struct
strbuf *buf)
* points to something different than a branch.
*/
if (!upstream)
- return error(_(HEAD does not point to a branch));
+ die(_(HEAD does not point to a branch));
if (!upstream-merge || !upstream-merge[0]-dst) {
if (!ref_exists(upstream-refname))
- return error(_(No such branch: '%s'), cp);
- if (!upstream-merge)
- return error(_(No upstream configured for branch
'%s'),
- upstream-name);
- return error(
+ die(_(No such branch: '%s'), cp);
+ if (!upstream-merge) {
+ die(_(No upstream configured for branch '%s'),
+ upstream-name);
+ }
+ die(
_(Upstream branch '%s' not stored as a remote-tracking
branch),
upstream-merge[0]-src);
}
diff --git a/t/t1507-rev-parse-upstream.sh b/t/t1507-rev-parse-upstream.sh
index b27a720..2a19e79 100755
--- a/t/t1507-rev-parse-upstream.sh
+++ b/t/t1507-rev-parse-upstream.sh
@@ -129,8 +129,7 @@ test_expect_success 'branch@{u} works when tracking a
local branch' '
test_expect_success 'branch@{u} error message when no upstream' '
cat expect -EOF
- error: No upstream configured for branch ${sq}non-tracking${sq}
- fatal: Needed a single revision
+ fatal: No upstream configured for branch ${sq}non-tracking${sq}
EOF
error_message non-tracking@{u} 2actual
test_i18ncmp expect actual
@@ -138,8 +137,7 @@ test_expect_success 'branch@{u} error message when no
upstream' '
test_expect_success '@{u} error message when no upstream' '
cat expect -EOF
- error: No upstream configured for branch ${sq}master${sq}
- fatal: Needed a single revision
+ fatal: No upstream configured for branch ${sq}master${sq}
EOF
test_must_fail git rev-parse --verify @{u} 2actual
test_i18ncmp expect actual
@@ -147,8 +145,7 @@ test_expect_success '@{u} error message when no upstream'
'
test_expect_success 'branch@{u} error message with misspelt branch' '
cat expect -EOF
- error: No such branch: ${sq}no-such-branch${sq}
- fatal: Needed a single revision
+ fatal: No such branch: ${sq}no-such-branch${sq}
EOF
error_message no-such-branch@{u} 2actual
test_i18ncmp expect actual
@@ -156,8 +153,7 @@ test_expect_success 'branch@{u} error message with
misspelt branch' '
test_expect_success '@{u} error message when not on a branch' '
cat expect -EOF
- error: HEAD does not point to a branch
- fatal: Needed a single revision
+ fatal: HEAD does not point to a branch
EOF
git checkout HEAD^0
test_must_fail git rev-parse --verify @{u} 2actual
Re: [PATCH 2/2] sha1_name: fix error message for @{N}, @{date}
Ramkumar Ramachandra artag...@gmail.com writes:
Currently, when we try to resolve @{N} or @{date} when the reflog
for the current branch doesn't go back far enough, we get errors like:
$ git show @{1}
fatal: Log for '' only has 7 entries.
$ git show @{1.days.ago}
warning: Log for '' only goes back to Tue, 21 May 2013 14:14:45 +0530.
...
The empty string '' looks ugly and inconsistent with the output of
branch@{N}. Replace it with the string 'current branch'.
Wouldn't that be '*the* current branch'?
More importantly, doesn't real_ref have the name of the branch?
Suppose the user said git show @{1} instead of git show
master@{1} while on 'master'.
It could be argued that it may look nicer to say your current
branch does not have enough update history instead of saying
master does not... (i.e. different input to ask for the same
thing, different output depending on the way the user asked). It
also could be argued that they should produce the same diagnosis
that is more informative.
I am slightly leaning toward the latter.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 4
1 file changed, 4 insertions(+)
diff --git a/sha1_name.c b/sha1_name.c
index 416a673..683b4bd 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -517,6 +517,10 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
}
if (read_ref_at(real_ref, at_time, nth, sha1, NULL,
co_time, co_tz, co_cnt)) {
+ if (!len) {
+ str = current branch;
+ len = strlen(current branch);
+ }
if (at_time)
warning(Log for '%.*s' only goes
back to %s., len, str,
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] transport-helper: check if the dry-run is supported
Felipe Contreras felipe.contre...@gmail.com writes:
Certain remote-helpers (the ones with 'export') would try to push
regardless.
Obviously this is not what the user wants.
Also, add a check for the 'dry-run' option, so remote-helpers can
implement it.
This sounds like a good thing to do. Perhaps the refspec mapping
can be handled the same way as a backend feature so that you do not
have to unconditionally disable it in the other patch.
Will queue both but not for 1.8.3.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
transport-helper.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/transport-helper.c b/transport-helper.c
index 522d791..c8c39fc 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -789,6 +789,11 @@ static int push_refs_with_export(struct transport
*transport,
struct string_list revlist_args = STRING_LIST_INIT_NODUP;
struct strbuf buf = STRBUF_INIT;
+ if (flags TRANSPORT_PUSH_DRY_RUN) {
+ if (set_helper_option(transport, dry-run, true) != 0)
+ die(helper %s does not support dry-run, data-name);
+ }
+
helper = get_helper(transport);
write_constant(helper-in, export\n);
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] remote-hg: fix configuration notes
Will apply for 1.8.3. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/WIP 0/9] for-each-ref format improvements
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: This series introduces: - %(current), which either shows * if the ref is pointed by HEAD or a space. Junio called it %(headness). I don't like that. I don't like %(current) either but we have to start somewhere. Name suggestion? %(marker)?? marker will paint us into a corner we cannot get out of when we want to mark refs with different criteria later. At least current tells you what kind of marker we are talking about and is 1000 times better. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/17] cmd_diff(): use an object_array for holding trees
Michael Haggerty mhag...@alum.mit.edu writes:
Change cmd_diff() to use a (struct object_array) for holding the trees
that it accumulates, rather than rolling its own equivalent.
A significant detail missing here is that this lifts the hardcoded
100 tree limit in combined diff but that does not matter in
practice, I would suppose ;-).
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/diff.c | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/builtin/diff.c b/builtin/diff.c
index ba68c6c..72d99c0 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -252,8 +252,8 @@ int cmd_diff(int argc, const char **argv, const char
*prefix)
{
int i;
struct rev_info rev;
- struct object_array_entry ent[100];
- int ents = 0, blobs = 0, paths = 0;
+ struct object_array ent = OBJECT_ARRAY_INIT;
+ int blobs = 0, paths = 0;
const char *path = NULL;
struct blobinfo blob[2];
int nongit;
@@ -350,13 +350,8 @@ int cmd_diff(int argc, const char **argv, const char
*prefix)
if (obj-type == OBJ_COMMIT)
obj = ((struct commit *)obj)-tree-object;
if (obj-type == OBJ_TREE) {
- if (ARRAY_SIZE(ent) = ents)
- die(_(more than %d trees given: '%s'),
- (int) ARRAY_SIZE(ent), name);
obj-flags |= flags;
- ent[ents].item = obj;
- ent[ents].name = name;
- ents++;
+ add_object_array(obj, name, ent);
continue;
}
if (obj-type == OBJ_BLOB) {
@@ -380,7 +375,7 @@ int cmd_diff(int argc, const char **argv, const char
*prefix)
/*
* Now, do the arguments look reasonable?
*/
- if (!ents) {
+ if (!ent.nr) {
switch (blobs) {
case 0:
result = builtin_diff_files(rev, argc, argv);
@@ -401,22 +396,26 @@ int cmd_diff(int argc, const char **argv, const char
*prefix)
}
else if (blobs)
usage(builtin_diff_usage);
- else if (ents == 1)
+ else if (ent.nr == 1)
result = builtin_diff_index(rev, argc, argv);
- else if (ents == 2)
- result = builtin_diff_tree(rev, argc, argv, ent[0], ent[1]);
- else if (ent[0].item-flags UNINTERESTING) {
+ else if (ent.nr == 2)
+ result = builtin_diff_tree(rev, argc, argv,
+ent.objects[0], ent.objects[1]);
+ else if (ent.objects[0].item-flags UNINTERESTING) {
/*
* diff A...B where there is at least one merge base
- * between A and B. We have ent[0] == merge-base,
- * ent[ents-2] == A, and ent[ents-1] == B. Show diff
- * between the base and B. Note that we pick one
- * merge base at random if there are more than one.
+ * between A and B. We have ent.objects[0] ==
+ * merge-base, ent.objects[ents-2] == A, and
+ * ent.objects[ents-1] == B. Show diff between the
+ * base and B. Note that we pick one merge base at
+ * random if there are more than one.
*/
- result = builtin_diff_tree(rev, argc, argv, ent[0],
ent[ents-1]);
+ result = builtin_diff_tree(rev, argc, argv,
+ent.objects[0],
+ent.objects[ent.nr-1]);
} else
result = builtin_diff_combined(rev, argc, argv,
-ent, ents);
+ent.objects, ent.nr);
result = diff_result_code(rev.diffopt, result);
if (1 rev.diffopt.skip_stat_unmatch)
refresh_index_quietly();
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/17] revision: split some overly-long lines
Michael Haggerty mhag...@alum.mit.edu writes:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
revision.c | 20 ++--
revision.h | 32 +---
2 files changed, 35 insertions(+), 17 deletions(-)
Looks obviously good for *.c file, but I am on the fence for *.h
one, as the reason we kept these long single lines in *.h files was
to help those who want to grep in *.h files to let them view the
full function signature. It probably is OK to tell them to use
git grep -A$n instead, though.
diff --git a/revision.c b/revision.c
index 25e424c..8ac88d6 100644
--- a/revision.c
+++ b/revision.c
@@ -70,7 +70,8 @@ static int show_path_truncated(FILE *out, const struct
name_path *path)
return ours || emitted;
}
-void show_object_with_name(FILE *out, struct object *obj, const struct
name_path *path, const char *component)
+void show_object_with_name(FILE *out, struct object *obj,
+const struct name_path *path, const char *component)
{
struct name_path leaf;
leaf.up = (struct name_path *)path;
@@ -186,7 +187,9 @@ void mark_parents_uninteresting(struct commit *commit)
}
}
-static void add_pending_object_with_mode(struct rev_info *revs, struct
object *obj, const char *name, unsigned mode)
+static void add_pending_object_with_mode(struct rev_info *revs,
+ struct object *obj,
+ const char *name, unsigned mode)
{
if (!obj)
return;
@@ -209,7 +212,8 @@ static void add_pending_object_with_mode(struct rev_info
*revs, struct object *o
add_object_array_with_mode(obj, name, revs-pending, mode);
}
-void add_pending_object(struct rev_info *revs, struct object *obj, const
char *name)
+void add_pending_object(struct rev_info *revs,
+ struct object *obj, const char *name)
{
add_pending_object_with_mode(revs, obj, name, S_IFINVALID);
}
@@ -226,7 +230,9 @@ void add_head_to_pending(struct rev_info *revs)
add_pending_object(revs, obj, HEAD);
}
-static struct object *get_reference(struct rev_info *revs, const char *name,
const unsigned char *sha1, unsigned int flags)
+static struct object *get_reference(struct rev_info *revs, const char *name,
+ const unsigned char *sha1,
+ unsigned int flags)
{
struct object *object;
@@ -247,7 +253,8 @@ void add_pending_sha1(struct rev_info *revs, const char
*name,
add_pending_object(revs, object, name);
}
-static struct commit *handle_commit(struct rev_info *revs, struct object
*object, const char *name)
+static struct commit *handle_commit(struct rev_info *revs,
+ struct object *object, const char *name)
{
unsigned long flags = object-flags;
@@ -368,7 +375,8 @@ static void file_change(struct diff_options *options,
DIFF_OPT_SET(options, HAS_CHANGES);
}
-static int rev_compare_tree(struct rev_info *revs, struct commit *parent,
struct commit *commit)
+static int rev_compare_tree(struct rev_info *revs,
+ struct commit *parent, struct commit *commit)
{
struct tree *t1 = parent-tree;
struct tree *t2 = commit-tree;
diff --git a/revision.h b/revision.h
index 01bd2b7..9628465 100644
--- a/revision.h
+++ b/revision.h
@@ -195,19 +195,23 @@ struct setup_revision_opt {
};
extern void init_revisions(struct rev_info *revs, const char *prefix);
-extern int setup_revisions(int argc, const char **argv, struct rev_info
*revs, struct setup_revision_opt *);
+extern int setup_revisions(int argc, const char **argv, struct rev_info
*revs,
+struct setup_revision_opt *);
extern void parse_revision_opt(struct rev_info *revs, struct parse_opt_ctx_t
*ctx,
- const struct option *options,
- const char * const usagestr[]);
+const struct option *options,
+const char * const usagestr[]);
#define REVARG_CANNOT_BE_FILENAME 01
#define REVARG_COMMITTISH 02
-extern int handle_revision_arg(const char *arg, struct rev_info *revs, int
flags, unsigned revarg_opt);
+extern int handle_revision_arg(const char *arg, struct rev_info *revs,
+int flags, unsigned revarg_opt);
extern void reset_revision_walk(void);
extern int prepare_revision_walk(struct rev_info *revs);
extern struct commit *get_revision(struct rev_info *revs);
-extern char *get_revision_mark(const struct rev_info *revs, const struct
commit *commit);
-extern void put_revision_mark(const struct rev_info *revs, const struct
commit *commit);
+extern char *get_revision_mark(const struct rev_info *revs,
+const struct commit *commit);
+extern void
Re: [PATCH 10/17] get_revision_internal(): make check less mysterious
Michael Haggerty mhag...@alum.mit.edu writes:
The condition under which gc_boundary() is called was previously
if (alloc = nr)
. But by construction, nr can never exceed alloc, so the check looks
unnecessarily mysterious. In fact, the purpose of the check is to try
to avoid a realloc() call by shrinking the array if possible if it is
at its allocation limit when a new element is about to be added. So
change the check to
if (nr == alloc)
and add a comment to explain what's going on.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Please check that I have properly described the purpose of this check.
The way the code is written, it looks like a bad pattern of growth and
shrinkage of the array (namely, just under the resize limit) could
cause gc_boundary() to be called over and over again with (most of)
the same data. I hope that the author had some reason to believe that
such a pattern is unlikely.
That is about comparing with alloc, not having high and low
watermarks, right?
I do not see alloc = nr is mysterious at all; it is merely being
defensive.
revision.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/revision.c b/revision.c
index 2e0992b..19c59f4 100644
--- a/revision.c
+++ b/revision.c
@@ -2573,8 +2573,10 @@ static struct commit *get_revision_internal(struct
rev_info *revs)
if (p-flags (CHILD_SHOWN | SHOWN))
continue;
p-flags |= CHILD_SHOWN;
- if (revs-boundary_commits.alloc = revs-boundary_commits.nr)
+ if (revs-boundary_commits.nr == revs-boundary_commits.alloc) {
+ /* Try to make space and thereby avoid a realloc(): */
gc_boundary(revs-boundary_commits);
+ }
add_object_array(p, NULL, revs-boundary_commits);
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/17] gc_boundary(): move the check alloc = nr to caller
Michael Haggerty mhag...@alum.mit.edu writes:
There is no logical reason for this test to be here. At the caller we
might be able to figure out its meaning.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
I do not think this change is justified, *unless* the caller later
in the series gains a better heuristics than what can be done with
information in the object_array (namely, alloc and nr) to decide
when to trigger gc.
And I was hoping to see such a cleverness added to the caller, but I
do not think I saw any.
I would have to say gc_boundary() knows better when it needs to gc
with the code at this point in the series, and that is true also in
the final code after all the patches in this series.
If we keep the when to gc logic inside gc, in 11/17 this caller
can no longer call directly to object_array_filter(). It should
call gc_boundary(), but I see it as a merit, not a downside. The
gc function can later be taught the high/low watermark logic you
alluded to in 10/17, and the growth/shrinkage characteristic you
would take advantage of while doing gc is specific to this
codepath. And the logic still does not have to have access to
anything only the caller has access to; gc can work on what can be
read from the object_array-{alloc,nr} that is given to it.
revision.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/revision.c b/revision.c
index 8ac88d6..2e0992b 100644
--- a/revision.c
+++ b/revision.c
@@ -2437,23 +2437,19 @@ static struct commit *get_revision_1(struct rev_info
*revs)
static void gc_boundary(struct object_array *array)
{
- unsigned nr = array-nr;
- unsigned alloc = array-alloc;
+ unsigned nr = array-nr, i, j;
struct object_array_entry *objects = array-objects;
- if (alloc = nr) {
- unsigned i, j;
- for (i = j = 0; i nr; i++) {
- if (objects[i].item-flags SHOWN)
- continue;
- if (i != j)
- objects[j] = objects[i];
- j++;
- }
- for (i = j; i nr; i++)
- objects[i].item = NULL;
- array-nr = j;
+ for (i = j = 0; i nr; i++) {
+ if (objects[i].item-flags SHOWN)
+ continue;
+ if (i != j)
+ objects[j] = objects[i];
+ j++;
}
+ for (i = j; i nr; i++)
+ objects[i].item = NULL;
+ array-nr = j;
}
static void create_boundary_commit_list(struct rev_info *revs)
@@ -2577,7 +2573,8 @@ static struct commit *get_revision_internal(struct
rev_info *revs)
if (p-flags (CHILD_SHOWN | SHOWN))
continue;
p-flags |= CHILD_SHOWN;
- gc_boundary(revs-boundary_commits);
+ if (revs-boundary_commits.alloc = revs-boundary_commits.nr)
+ gc_boundary(revs-boundary_commits);
add_object_array(p, NULL, revs-boundary_commits);
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix invalid revision error messages for 1.8.3
Junio C Hamano wrote:
Fixes to something that are broken the same way between 'master' and
older release versions are the same as enhancements (which you can
view as fix to lack of feature). They are not regression fixes
and not for 1.8.3 at this point in the cycle, deep into -rc.
If we view them as enhancements, well and good. Let's polish them
until we're really happy with them: they're written with the minimal,
but correct philosophy, because the -rc3 window is too small for a
review.
Just to share opinion, they looked like bugs to me, because it's not
about improving the error messages; it's about correcting a defect.
The author could not have possibly intended two error: lines in the
first one, or an empty string in the second one. At some point in the
past, the behavior must have been different (a feature must have
introduced these problems: like implicit HEAD for @{N}): the
regression was introduced in the version after that. So, is it
because that version was too long ago that we don't consider it a
regression (do we backport fixes)?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] sha1_name: fix error message for @{N}, @{date}
On 21/05/2013 19:52, Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
The empty string '' looks ugly and inconsistent with the output of
branch@{N}. Replace it with the string 'current branch'.
Wouldn't that be '*the* current branch'?
More importantly, doesn't real_ref have the name of the branch?
Suppose the user said git show @{1} instead of git show
master@{1} while on 'master'.
It could be argued that it may look nicer to say your current
branch does not have enough update history instead of saying
master does not... (i.e. different input to ask for the same
thing, different output depending on the way the user asked). It
also could be argued that they should produce the same diagnosis
that is more informative.
I am slightly leaning toward the latter.
That would also avoid the complaint I was about to make that putting
'current branch' in scare quotes would be annoying.
Kevin
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sha1_name: fix error message for @{u}
Junio C Hamano wrote:
Does a failure in interpret-branch-name that issue these error
messages always followed by die() in the caller? I know you looked
at the cases you noticed as an end-user (like the above git show @{u}
example), but if some codepaths did this:
if (interpret-branch-name()) {
you do not seem to have upstream defined,
so I will helpfully do something else that
you probably have meant.
}
this patch will break that codepath you did not look.
How can that ever happen in a non end-user case? That failure
requires a string containing @{u} to be constructed and passed as an
argument. Why would we ever programmatically construct @{u} to find
the upstream?
To put it another way: unless an end-user facing application finds an
@{u} while parsing argv and passes it on to interpret-branch-name,
isn't it impossible for an @{u} to end up in the argument?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix invalid revision error messages for 1.8.3
Ramkumar Ramachandra artag...@gmail.com writes: So, is it because that version was too long ago that we don't consider it a regression (do we backport fixes)? The regression fixes pre-release -rc period is for is to make sure to avoid unwanted/unintended behaviour changes between releases. People have _already_ seen and lived with these issues in released versions. Changing it may or may not be getting it back to the state to that of an even older release, but at that point the differences do not matter. It is a fix, too late for the kind of regression fixes we focus during _this_ -rc period, which is about regressions between v1.8.2 and 'master'. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sha1_name: fix error message for @{u}
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Does a failure in interpret-branch-name that issue these error
messages always followed by die() in the caller? I know you looked
at the cases you noticed as an end-user (like the above git show @{u}
example), but if some codepaths did this:
if (interpret-branch-name()) {
you do not seem to have upstream defined,
so I will helpfully do something else that
you probably have meant.
}
this patch will break that codepath you did not look.
How can that ever happen in a non end-user case? That failure
requires a string containing @{u} to be constructed and passed as an
argument. Why would we ever programmatically construct @{u} to find
the upstream?
To put it another way: unless an end-user facing application finds an
@{u} while parsing argv and passes it on to interpret-branch-name,
isn't it impossible for an @{u} to end up in the argument?
So did you or did you not audit the codepath?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sha1_name: fix error message for @{u}
Junio C Hamano wrote: So did you or did you not audit the codepath? No; I was explaining why I didn't in the first place. Going through it now. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sha1_name: fix error message for @{u}
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: So did you or did you not audit the codepath? No; I was explaining why I didn't in the first place. Going through it now. I did not mean You must do so or we should discard the patch. I just wanted to make sure the log messages say how firmly the change is backed. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] sha1_name: fix error message for @{N}, @{date}
Junio C Hamano wrote:
More importantly, doesn't real_ref have the name of the branch?
Suppose the user said git show @{1} instead of git show
master@{1} while on 'master'.
My stupidity, sorry.
It could be argued that it may look nicer to say your current
branch does not have enough update history instead of saying
master does not... (i.e. different input to ask for the same
thing, different output depending on the way the user asked). It
also could be argued that they should produce the same diagnosis
that is more informative.
Yeah, I wanted to discuss this: the problem is that even something as
low-level as rev-list will print this pretty error. It's certainly
useful for porcelain. How do we achieve this? An extra
is-porcelain argument?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix invalid revision error messages for 1.8.3
Junio C Hamano wrote: People have _already_ seen and lived with these issues in released versions. Changing it may or may not be getting it back to the state to that of an even older release, but at that point the differences do not matter. It is a fix, too late for the kind of regression fixes we focus during _this_ -rc period, which is about regressions between v1.8.2 and 'master'. Makes sense. On a related note, I really wonder why people run anything master git; it's so easy to compile and use from ~. The idea isn't insane at all: most people run a -p ruby from ~ using things like rbenv (yes, it compiles from source). (ofcourse servers have to run a release) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Fixing volatile HEAD in push.default = current
There's still a lot to think about. [3/3] is the big itch: [1/2] and [2/2] are just setup patches. Ramkumar Ramachandra (3): push: factor out the detached HEAD error message push: fail early with detached HEAD and current push: don't push the volatile HEAD with current builtin/push.c | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) -- 1.8.3.rc3.7.gc1ff30b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] push: factor out the detached HEAD error message
With push.default set to upstream or simple, and a detached HEAD, git
push prints the following error:
$ git push
fatal: You are not currently on a branch.
To push the history leading to the current (detached HEAD)
state now, use
git push ram HEAD:name-of-remote-branch
This error is not unique to upstream or simple: current cannot push with
a detached HEAD either. So, factor out the error string in preparation
for using it in current.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/push.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/builtin/push.c b/builtin/push.c
index 909c34d..ef3aa97 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -113,17 +113,19 @@ static NORETURN int die_push_simple(struct branch
*branch, struct remote *remote
remote-name, branch-name, advice_maybe);
}
+static const char message_detached_head_die[] =
+ N_(You are not currently on a branch.\n
+ To push the history leading to the current (detached HEAD)\n
+ state now, use\n
+ \n
+ git push %s HEAD:name-of-remote-branch\n);
+
static void setup_push_upstream(struct remote *remote, int simple)
{
struct strbuf refspec = STRBUF_INIT;
struct branch *branch = branch_get(NULL);
if (!branch)
- die(_(You are not currently on a branch.\n
- To push the history leading to the current (detached
HEAD)\n
- state now, use\n
- \n
- git push %s HEAD:name-of-remote-branch\n),
- remote-name);
+ die(_(message_detached_head_die), remote-name);
if (!branch-merge_nr || !branch-merge || !branch-remote_name)
die(_(The current branch %s has no upstream branch.\n
To push the current branch and set the remote as upstream,
use\n
--
1.8.3.rc3.7.gc1ff30b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] push: fail early with detached HEAD and current
Setting push.default to current adds the refspec HEAD for the
transport layer to handle. If HEAD doesn't resolve to a branch (and
since no refspec rhs is specified), the push fails after some time with
a cryptic error message:
$ git push
error: unable to push to unqualified destination: HEAD
The destination refspec neither matches an existing ref on the remote nor
begins with refs/, and we are unable to guess a prefix based on the source
ref.
error: failed to push some refs to 'g...@github.com:artagnon/git'
Fail early with a nicer error message:
$ git push
fatal: You are not currently on a branch.
To push the history leading to the current (detached HEAD)
state now, use
git push ram HEAD:name-of-remote-branch
Just like in the upstream and simple cases.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/push.c | 4
1 file changed, 4 insertions(+)
diff --git a/builtin/push.c b/builtin/push.c
index ef3aa97..a79038c 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -175,6 +175,8 @@ static void
warn_unspecified_push_default_configuration(void)
static void setup_default_push_refspecs(struct remote *remote)
{
+ struct branch *branch = branch_get(NULL);
+
switch (push_default) {
default:
case PUSH_DEFAULT_UNSPECIFIED:
@@ -194,6 +196,8 @@ static void setup_default_push_refspecs(struct remote
*remote)
break;
case PUSH_DEFAULT_CURRENT:
+ if (!branch)
+ die(_(message_detached_head_die), remote-name);
add_refspec(HEAD);
break;
--
1.8.3.rc3.7.gc1ff30b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] push: don't push the volatile HEAD with current
Since a push does not lock the HEAD ref, there is no guarantee that it will remain the same for the entire operation of the push. Practically, this means that with push.default set to current: # on branch push-current-head $ git push # on another terminal $ git checkout master # return to the first terminal # the push tried to push master! Avoid this confusion by adding the branch that HEAD resolves to as the refspec to push (as opposed to the literal HEAD). With this change, the output of the push changes subtly from: $ git push ... * [new branch] HEAD - push-current-head to: $ git push ... * [new branch] push-current-head - push-current-head Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- builtin/push.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/push.c b/builtin/push.c index a79038c..d819487 100644 --- a/builtin/push.c +++ b/builtin/push.c @@ -198,7 +198,7 @@ static void setup_default_push_refspecs(struct remote *remote) case PUSH_DEFAULT_CURRENT: if (!branch) die(_(message_detached_head_die), remote-name); - add_refspec(HEAD); + add_refspec(branch-name); break; case PUSH_DEFAULT_NOTHING: -- 1.8.3.rc3.7.gc1ff30b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/17] Remove assumptions about refname lifetimes
Johan Herland jo...@herland.net writes: On Mon, May 20, 2013 at 6:37 PM, Junio C Hamano gits...@pobox.com wrote: ... That backing out can be made more intelligently than just dying with compare and swap failed--please retry message, e.g. you at that point notice what you started with, what the other party did while you were working on (i.e. updating refs/tags/), and three-way merge the refs tree, and in cases where all refs recorded as loose refs scheme wouldn't have resulted in problematic conflict, such a three-way merge would resolve trivially (you updated refs/heads/ and the update by the other process to refs/tags/ would not conflict with what you did). But the same three-way merge scheme can be employed with the current flat single packed-refs scheme, can't it? Yes. (albeit without reusing the machinery we already have for doing three-way merges) I do not think that is relevant, as you do *not* want to reuse the usual three-way xdiff merge machinery that leaves = markers for this usage anyway. But that is not the primary reason why I am beating this dead horse; it is the following. Your version of packed-refs file, and his version of packed-refs file, and the original you started with, are all sorted in a known order. You just look at lines from all and merge them line by line. I think that logic should become a new blob-level merge driver that can be reused for normal in-working-tree objects that are sorted. For that kind of sorted wordlist file, conflicts that may artificially arise only because two sides updated adjacent lines in the list and you used the normal xdiff merge machinery is unwanted, and users would benefit by having such a specialized merge driver outside the context of merging two proposed list of refs. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current
Ramkumar Ramachandra artag...@gmail.com writes: There's still a lot to think about. Is there? I do not think volatile is particularly a good description for this, but showing what is pushed as a concrete branch name feels like a good improvement to me, at least in principle. I haven't picked them up, and I won't be picking them up today, as I suspect this series may conflict with the pre-2.0 preparation and 2.0 transition patches and I may end up having to fix conflicts unnecessarily (resolving is eventually needed before 2.0 happens, but resolving them, or even having to worry about the possibility that I may have to do so, do not have to steal time from me today). Thanks. [3/3] is the big itch: [1/2] and [2/2] are just setup patches. Ramkumar Ramachandra (3): push: factor out the detached HEAD error message push: fail early with detached HEAD and current push: don't push the volatile HEAD with current builtin/push.c | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/3] Begin replacing OpenSSL with CommonCrypto
On 2013-05-21 00.52, Junio C Hamano wrote: Thanks, will replace da/darwin with this round. (May be late response, not sure if this is the right email thread. I eventually managed to compile under 10.6, what we have on pu) One minor nit, or 2: imap-send.c: In function ‘cram’: imap-send.c:913: warning: statement with no effect This fixes it: diff --git a/imap-send.c b/imap-send.c index 8ea180f..11577c9 100644 --- a/imap-send.c +++ b/imap-send.c @@ -35,7 +35,7 @@ typedef void *SSL; #define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len) #define HMAC_Update CCHmacUpdate #define HMAC_Final(hmac, hash, ptr) CCHmacFinal(hmac, hash) -#define HMAC_CTX_cleanup +#define HMAC_CTX_cleanup(c) #define EVP_md5() kCCHmacAlgMD5 #else #include openssl/evp.h (And I think there are more minor nits: #define HMAC_Final(hmac, hash, ptr) CCHmacFinal(hmac, hash) could be written as #define HMAC_Final(hmac, hash, ptr) CCHmacFinal((hmac), (hash)) (Use paranthese around each parameter) Similar change for HMAC_Init() /Torsten -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sha1_name: fix error message for @{u}
Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
So did you or did you not audit the codepath?
No; I was explaining why I didn't in the first place. Going through it now.
So, this is what I have:
interpret_branch_name - interpret_branch_name (recursion)
- get_sha1_basic - get_sha1 [context] (end-user data)
- substitute_branch_name - dwim (end-user data)
- strbuf_branchname (callers pass a branch name; no @{u})
- revision.c:add_pending_object [with_mode] (end-user
data)
[die_]verify_filename - builtin/rev-parse.c (end-user)
- builtin/reset.c (end-user)
- builtin/grep.c:cmd_grep (end-user)
- revision.c:setup_revisions (end-user data)
We used to die in die_verify_filename() earlier, but we die in
interpret_branch_name() after the patch. Do we have to dig deeper?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/3] Begin replacing OpenSSL with CommonCrypto
Torsten Bögershausen wrote: One minor nit, or 2: imap-send.c: In function ‘cram’: imap-send.c:913: warning: statement with no effect This fixes it: diff --git a/imap-send.c b/imap-send.c index 8ea180f..11577c9 100644 --- a/imap-send.c +++ b/imap-send.c @@ -35,7 +35,7 @@ typedef void *SSL; #define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len) #define HMAC_Update CCHmacUpdate #define HMAC_Final(hmac, hash, ptr) CCHmacFinal(hmac, hash) -#define HMAC_CTX_cleanup +#define HMAC_CTX_cleanup(c) #define EVP_md5() kCCHmacAlgMD5 #else #include openssl/evp.h Good catch. Thanks. (And I think there are more minor nits: #define HMAC_Final(hmac, hash, ptr) CCHmacFinal(hmac, hash) could be written as #define HMAC_Final(hmac, hash, ptr) CCHmacFinal((hmac), (hash)) (Use paranthese around each parameter) Similar change for HMAC_Init() Not needed --- the comma operator has lower precedence than any other, and any expression containing commas would have to already be surrounded by parentheses to be an argument to this function-like macro. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current
Junio C Hamano wrote: Is there? I do not think volatile is particularly a good description for this, but showing what is pushed as a concrete branch name feels like a good improvement to me, at least in principle. Okay. I used volatile, because push does not lock HEAD when the operation begins, even though it performs a super-late resolution (in the transport-layer); HEAD is not guaranteed to remain invariant in that time. Suggest nicer wording? I haven't picked them up, and I won't be picking them up today, as I suspect this series may conflict with the pre-2.0 preparation and 2.0 transition patches and I may end up having to fix conflicts unnecessarily (resolving is eventually needed before 2.0 happens, but resolving them, or even having to worry about the possibility that I may have to do so, do not have to steal time from me today). We're at 1.8.3; isn't it a little early to be thinking of 2.0? Is it conflicting with jc/push-2.0-default-to-simple in pu? I should re-send after this topic graduates to master in 2.0? I have no problems re-sending at a convenient time (provided you tell me how to determine that convenient time), but reviews don't have to wait: it's fresh in my memory now. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sha1_name: fix error message for @{u}
Ramkumar Ramachandra artag...@gmail.com writes:
Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
So did you or did you not audit the codepath?
No; I was explaining why I didn't in the first place. Going through it now.
So, this is what I have:
interpret_branch_name - interpret_branch_name (recursion)
- get_sha1_basic - get_sha1 [context] (end-user data)
- substitute_branch_name - dwim (end-user data)
- strbuf_branchname (callers pass a branch name; no @{u})
- revision.c:add_pending_object [with_mode] (end-user
data)
[die_]verify_filename - builtin/rev-parse.c (end-user)
- builtin/reset.c (end-user)
- builtin/grep.c:cmd_grep (end-user)
- revision.c:setup_revisions (end-user data)
It seems that you are digging in the wrong direction? I was worried
about the callers of interpret_branch_name().
But whatever.
I looked at the callers myself while waiting for the test suite to
pass for five integration branches and I think the patch is safe.
There were some silent error returns from the function but your
patch did not touch them (which is good).
We used to die in die_verify_filename() earlier, but we die in
interpret_branch_name() after the patch.
I think that is a desired outcome. Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sha1_name: fix error message for @{u}
Junio C Hamano wrote:
interpret_branch_name - interpret_branch_name (recursion)
- get_sha1_basic - get_sha1 [context] (end-user data)
- substitute_branch_name - dwim (end-user data)
- strbuf_branchname (callers pass a branch name; no
@{u})
- revision.c:add_pending_object [with_mode] (end-user
data)
[die_]verify_filename - builtin/rev-parse.c (end-user)
- builtin/reset.c (end-user)
- builtin/grep.c:cmd_grep (end-user)
- revision.c:setup_revisions (end-user data)
It seems that you are digging in the wrong direction? I was worried
about the callers of interpret_branch_name().
Um, aren't interpret_branch_name, get_sha1_basic,
substitute_branch_name, strbuf_branchname, and add_pending_object the
five callers of interpret_branch_name? I've tried to show how they
are called with either end-user data or programmatic data without a
@{u}. What am I missing?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: Is there? I do not think volatile is particularly a good description for this, but showing what is pushed as a concrete branch name feels like a good improvement to me, at least in principle. Okay. I used volatile, because push does not lock HEAD when the operation begins, even though it performs a super-late resolution (in the transport-layer); HEAD is not guaranteed to remain invariant in that time. Suggest nicer wording? In general, when a command is working in your repository with a working tree, we do not make any such promise that it keeps operationg normally when you pull the rug under its feet from another terminal (git checkout maint running at the same time git pull would not have a chance to work correctly). Some are safe (like git push racing with git checkout maint that would not have to look at what the current branch is) and some are not (like git push github racing with git checkout maint git push origin HEAD:preview). I view the value of this topic purely as showing a real branch name when that is what we actually pushed is a lot more preferrable than showing HEAD, especially because the user may see it in the terminal scrollback buffer hours after it happened. Explaining this patch as we avoid issues from simultaneously flipping HEAD by resolving early gives a false sense of security to the reader, as early has to happen early enough for the patch to really avoid the issue, but you are not in control of when the user does that flipping in the other terminal. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sha1_name: fix error message for @{u}
Ramkumar Ramachandra artag...@gmail.com writes:
@{u}. What am I missing?
You draw the arrow the other way around, that is what made the text
confusing.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] transport-helper: barf when user tries old:new
On Tue, May 21, 2013 at 11:32 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: I won't bother rationalizing if this makes sense for 'master' As this is a change to an old code/behaviour that was with us with many released versions, it hardly is for 'master' during -rc period. Probably. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] transport-helper: check if the dry-run is supported
On Tue, May 21, 2013 at 11:55 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Certain remote-helpers (the ones with 'export') would try to push regardless. Obviously this is not what the user wants. Also, add a check for the 'dry-run' option, so remote-helpers can implement it. This sounds like a good thing to do. Perhaps the refspec mapping can be handled the same way as a backend feature so that you do not have to unconditionally disable it in the other patch. With my patch the remote helper doesn't need to know about the refspec handling at all, it just works magically. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Reading commit objects
Hello, I'm building a library to manipulate git repositories (interacting directly with the filesystem). Currently, we're trying to parse commit objects. After decompressing the contents of a commit object file we got the following output: commit 191 author Francisco Sokol chico.so...@gmail.com 1369140112 -0300 committer Francisco Sokol chico.so...@gmail.com 1369140112 -0300 first commit We hoped to get the same output of a git cat-file -p sha1, but that didn't happened. From a commit object, how can I find tree object hash of this commit? Thanks, -- Chico Sokol -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reading commit objects
On Tue, May 21, 2013 at 4:21 PM, Chico Sokol chico.so...@gmail.com wrote: Hello, I'm building a library to manipulate git repositories (interacting directly with the filesystem). Currently, we're trying to parse commit objects. After decompressing the contents of a commit object file we got the following output: commit 191 author Francisco Sokol chico.so...@gmail.com 1369140112 -0300 committer Francisco Sokol chico.so...@gmail.com 1369140112 -0300 first commit We hoped to get the same output of a git cat-file -p sha1, but that didn't happened. From a commit object, how can I find tree object hash of this commit? git rev-parse sha1: -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reading commit objects
On Tue, May 21, 2013 at 5:21 PM, Chico Sokol chico.so...@gmail.com wrote:
Hello,
I'm building a library to manipulate git repositories (interacting
directly with the filesystem).
Currently, we're trying to parse commit objects. After decompressing
the contents of a commit object file we got the following output:
commit 191
author Francisco Sokol chico.so...@gmail.com 1369140112 -0300
committer Francisco Sokol chico.so...@gmail.com 1369140112 -0300
first commit
Does `git cat-file -p sha1` show a tree object? FWIW, I expected to
see a tree line there, so maybe this object was created without a
tree? I also don't see a parent listed.
I did this on one of my repos:
buf = open('.git/objects/cd/da219e4d7beceae55af73c44cb3c9e1ec56802',
'rb').read()
import zlib
zlib.decompress(buf)
'commit 246\x00tree 2abfe1a7bedb29672a223a5c5f266b7dc70a8d87\nparent
0636e7ff6b79470b0cd53ceacea88e7796f202ce\nauthor John Szakmeister
j...@szakmeister.net 1369168481 -0400\ncommitter John Szakmeister
j...@szakmeister.net 1369168481 -0400\n\nGot a file listing.\n'
So at least creating the commits with Git, I see a tree. How was the
commit you're referencing created? Perhaps something is wrong with
that process?
We hoped to get the same output of a git cat-file -p sha1, but
that didn't happened. From a commit object, how can I find tree object
hash of this commit?
I'd expect that too.
-John
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reading commit objects
Ok, we discovered that the commit object actually contains the tree
object's sha1, by reading its contents with python zlib library.
So the bug must be with our java code (we're building a java lib).
Is there any non-standard issue in git's zlib compression? We're
decompressing its contents with java default zlib api, so it should
work normally, here's our code, that's printing that wrong output:
import java.io.File;
import java.io.FileInputStream;
import java.util.zip.InflaterInputStream;
import org.apache.commons.io.IOUtils;
...
File obj = new File(.git/objects/25/0f67ef017fcb97b5371a302526872cfcadad21);
InflaterInputStream inflaterInputStream = new InflaterInputStream(new
FileInputStream(obj));
System.out.println(IOUtils.readLines(inflaterInputStream));
I know that here it's not the right place to ask about java issues,
but we would appreciate any help any help.
--
Chico Sokol
On Tue, May 21, 2013 at 6:37 PM, John Szakmeister j...@szakmeister.net wrote:
On Tue, May 21, 2013 at 5:21 PM, Chico Sokol chico.so...@gmail.com wrote:
Hello,
I'm building a library to manipulate git repositories (interacting
directly with the filesystem).
Currently, we're trying to parse commit objects. After decompressing
the contents of a commit object file we got the following output:
commit 191
author Francisco Sokol chico.so...@gmail.com 1369140112 -0300
committer Francisco Sokol chico.so...@gmail.com 1369140112 -0300
first commit
Does `git cat-file -p sha1` show a tree object? FWIW, I expected to
see a tree line there, so maybe this object was created without a
tree? I also don't see a parent listed.
I did this on one of my repos:
buf = open('.git/objects/cd/da219e4d7beceae55af73c44cb3c9e1ec56802',
'rb').read()
import zlib
zlib.decompress(buf)
'commit 246\x00tree 2abfe1a7bedb29672a223a5c5f266b7dc70a8d87\nparent
0636e7ff6b79470b0cd53ceacea88e7796f202ce\nauthor John Szakmeister
j...@szakmeister.net 1369168481 -0400\ncommitter John Szakmeister
j...@szakmeister.net 1369168481 -0400\n\nGot a file listing.\n'
So at least creating the commits with Git, I see a tree. How was the
commit you're referencing created? Perhaps something is wrong with
that process?
We hoped to get the same output of a git cat-file -p sha1, but
that didn't happened. From a commit object, how can I find tree object
hash of this commit?
I'd expect that too.
-John
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reading commit objects
Chico Sokol chico.so...@gmail.com writes: Hello, I'm building a library to manipulate git repositories (interacting directly with the filesystem). Currently, we're trying to parse commit objects. After decompressing the contents of a commit object file we got the following output: Who wrote this commit object you are trying to read? Us, or your library (this question is to see if you are chasing the right problem)? commit 191 author Francisco Sokol chico.so...@gmail.com 1369140112 -0300 committer Francisco Sokol chico.so...@gmail.com 1369140112 -0300 first commit We hoped to get the same output of a git cat-file -p sha1, but that didn't happened. From a commit object, how can I find tree object hash of this commit? If you care about the byte-for-byte compatibility, never use cat-file -p. That is meant for human consumption. git cat-file commit sha1 gives you the raw representation after inflating and stripping out the first type SP length LF line. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reading commit objects
Chico Sokol chico.so...@gmail.com writes: Ok, we discovered that the commit object actually contains the tree object's sha1, by reading its contents with python zlib library. So the bug must be with our java code (we're building a java lib). Why aren't you using jgit? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
From: Felipe Contreras felipe.contre...@gmail.com Sent: Tuesday, May 21, 2013 10:21 PM On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano gits...@pobox.com wrote: Philip Oakley philipoak...@iee.org writes: On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder jrnie...@gmail.com wrote: Another trick is to use git push: git push . $production_sha1:refs/heads/master It all falls out naturally from the Git is distributed and no repository is special principle. I think that word trick merely refers to those who do not realize that the local repository is not all that special and merely is _a_ repository just like anybody else's may not realize they can do this, nothing more. Nobody cares. The value of the trick was acknowledged as now being in use http://article.gmane.org/gmane.comp.version-control.git/223572 Not sure if that was the caring you were commenting on. My patch was to make it better known and that it (the dot repository) isn't a 'trick'. I'll refresh them after v1.8.3. Filipe gave 'git fetch .' in [PATCH 1/3] fetch: add --allow-local option, 16 May 2013 That patch came from a mistaken suggestion from me that was retracted with You say it's mistaken, but you are not the arbiter of truth; the fact that you say it's so doesn't make it so. It's just rhetoric. You haven't shown that it's indeed mistaken. An aside: in some domains (e.g. Human Error taxonomy) a 'mistake' is a planned action which later turns out to not be the action that would now have, in retrospect, been chosen. The intent was good, but is later classed (within the taxonomy) as a 'mistake'. (It is not related to 'blame'). If I understand the extended thread correctly, the approach moved on and alternatives were found, so in that sense the intent was good. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reading commit objects
It was git who created that object. We're trying to build a improved java library focused in our needs (jgit has a really confusing api focused in solving egit needs). But we're about to get into their code to discover how to decompress git objects. -- Chico Sokol On Tue, May 21, 2013 at 7:22 PM, Junio C Hamano gits...@pobox.com wrote: Chico Sokol chico.so...@gmail.com writes: Ok, we discovered that the commit object actually contains the tree object's sha1, by reading its contents with python zlib library. So the bug must be with our java code (we're building a java lib). Why aren't you using jgit? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/3] Begin replacing OpenSSL with CommonCrypto
On Tue, May 21, 2013 at 12:19 PM, Torsten Bögershausen tbo...@web.de wrote: On 2013-05-21 00.52, Junio C Hamano wrote: Thanks, will replace da/darwin with this round. (May be late response, not sure if this is the right email thread. I eventually managed to compile under 10.6, what we have on pu) One minor nit, or 2: imap-send.c: In function ‘cram’: imap-send.c:913: warning: statement with no effect This fixes it: diff --git a/imap-send.c b/imap-send.c index 8ea180f..11577c9 100644 --- a/imap-send.c +++ b/imap-send.c @@ -35,7 +35,7 @@ typedef void *SSL; #define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len) #define HMAC_Update CCHmacUpdate #define HMAC_Final(hmac, hash, ptr) CCHmacFinal(hmac, hash) -#define HMAC_CTX_cleanup +#define HMAC_CTX_cleanup(c) #define EVP_md5() kCCHmacAlgMD5 #else #include openssl/evp.h Thanks. This change compiles fine on Mountain Lion (10.8) as well. -- David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prompt: fix show upstream with svn and zsh
Hi,
On Tue, May 21, 2013 at 10:54:27PM +0200, Thomas Gummerer wrote:
Currently the __git_ps1 git prompt gives the following error with a
repository converted by git-svn, when used with zsh:
__git_ps1_show_upstream:19: bad pattern: svn_remote[
This was introduced by 6d158cba (bash completion: Support divergence
from upstream messages in __git_ps1), when the script was for bash
only. Make it compatible with zsh.
What is the actual cause of this problem/incompatibility and how/why do
these changes fix it?
- svn_remote[ $((${#svn_remote[@]} + 1)) ]=$value
+ svn_remote[$((${#svn_remote[@]} + 1))]=$value
I mean, did zsh really complained because of the space after the '[' ?!
@@ -146,8 +146,8 @@ __git_ps1_show_upstream ()
svn*)
# get the upstream from the git-svn-id: ... in a commit
message
# (git-svn uses essentially the same procedure internally)
- local svn_upstream=($(git log --first-parent -1 \
- --grep=^git-svn-id:
\(${svn_url_pattern#??}\) 2/dev/null))
+ set -a svn_upstream $(git log --first-parent -1 \
+ --grep=^git-svn-id:
\(${svn_url_pattern#??}\) 2/dev/null)
if [[ 0 -ne ${#svn_upstream[@]} ]]; then
svn_upstream=${svn_upstream[ ${#svn_upstream[@]} - 2 ]}
If so, then what about this one?
Best,
Gábor
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
On Tue, May 21, 2013 at 5:33 PM, Philip Oakley philipoak...@iee.org wrote: From: Felipe Contreras felipe.contre...@gmail.com Sent: Tuesday, May 21, 2013 10:21 PM On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano gits...@pobox.com wrote: Philip Oakley philipoak...@iee.org writes: On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder jrnie...@gmail.com wrote: Another trick is to use git push: git push . $production_sha1:refs/heads/master It all falls out naturally from the Git is distributed and no repository is special principle. I think that word trick merely refers to those who do not realize that the local repository is not all that special and merely is _a_ repository just like anybody else's may not realize they can do this, nothing more. Nobody cares. The value of the trick was acknowledged as now being in use http://article.gmane.org/gmane.comp.version-control.git/223572 How is that more useful than 'git branch -f master $sha1'? Not sure if that was the caring you were commenting on. My point is that nobody uses '.' as a remote. Yes, you can find the occasional esoteric person in the Git mailing list that might find some weird command useful, but that's the fringe user-base. You say it's mistaken, but you are not the arbiter of truth; the fact that you say it's so doesn't make it so. It's just rhetoric. You haven't shown that it's indeed mistaken. An aside: in some domains (e.g. Human Error taxonomy) a 'mistake' is a planned action which later turns out to not be the action that would now have, in retrospect, been chosen. The intent was good, but is later classed (within the taxonomy) as a 'mistake'. (It is not related to 'blame'). Yeah, that's what a mistake is, in my mind. If I understand the extended thread correctly, the approach moved on and alternatives were found, so in that sense the intent was good. No, the approach didn't move on, there are no better alternatives, the intent is irrelevant, the approach is good, there is no mistake. Junio simply ignored the fact that he was proven wrong. I still haven't received a response: which makes more sense? a) % git checkout svn-ext % git fetch From . * branchmaster - FETCH_HEAD # oops % git fetch git-svn % git log ..FETCH_HEAD % git merge FETCH_HEAD b) % git checkout svn-ext % git fetch From git://git.kernel.org/pub/scm/git/git 680ed3e..de3a5c6 master - origin/master # oops % git fetch svn-ext % git log ..FETCH_HEAD % git merge FETCH_HEAD -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prompt: fix show upstream with svn and zsh
On Tue, May 21, 2013 at 5:41 PM, SZEDER Gábor sze...@ira.uka.de wrote: On Tue, May 21, 2013 at 10:54:27PM +0200, Thomas Gummerer wrote: Currently the __git_ps1 git prompt gives the following error with a repository converted by git-svn, when used with zsh: __git_ps1_show_upstream:19: bad pattern: svn_remote[ This was introduced by 6d158cba (bash completion: Support divergence from upstream messages in __git_ps1), when the script was for bash only. Make it compatible with zsh. What is the actual cause of this problem/incompatibility and how/why do these changes fix it? I think the commit message makes that very clear. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Felipe Contreras felipe.contre...@gmail.com writes:
I still haven't received a response: which makes more sense?
a)
% git checkout svn-ext
% git fetch
From .
* branchmaster - FETCH_HEAD
# oops
% git fetch git-svn
% git log ..FETCH_HEAD
% git merge FETCH_HEAD
b)
% git checkout svn-ext
% git fetch
From git://git.kernel.org/pub/scm/git/git
680ed3e..de3a5c6 master - origin/master
# oops
% git fetch svn-ext
% git log ..FETCH_HEAD
% git merge FETCH_HEAD
I think with the scenario you are following, a) would prepare the
FETCH_HEAD with her local git-svn branch which is her svn-ext topic
is based on, but you illustrated it to fetch 'master', which I think
is a minor typo.
Modulo that typo, the step before the #oops makes perfect sense. It
fetched where she told Git her work on svn-ext is based on.
But the step after that does not make much sense in that flow.
git fetch git-svn to get from Eric might make sense but running
log with FETCH_HEAD while she is on her svn-ext does not make any
sense, let alone merging with it. Her svn-ext is based on her local
git-svn branch for a reason---her branches are cascaded this way:
Eric -- her local git-svn -- her local svn-ext
Hecking out her git-svn to update/rebase it on top of Eric's latest
and then update her svn-ext that is based on her git-svn may make
sense. But fetching from Eric and merging it into her svn-ext
directly does not.
And what happens before #oops in b) is an utter nonsense. Her
svn-ext is not even related to my tree. I think the step after that
is a typo of git fetch git-svn to fetch from Eric, but again,
because svn-ext is fork from her local git-svn (which is ahead of
Eric's tree with her own changes, but the changes are not related
to her svn-ext work), these fetch from Eric, integrate svn-ext directly
with it makes no sense.
So, the short answer is neither, but a) can be fixed (not in code
but in the typescript) to make more sense, perhaps like this:
% git checkout svn-ext
% git fetch
% git log ..FETCH_HEAD
% git rebase FETCH_HEAD
# The last three can be git pull --rebase.
# ok, did Eric do something in the meantime?
% git checkout git-svn
% git fetch
From git://git.bogomips.org/git-svn.git/
* branch master - git-svn/master
% git rebase FETCH_HEAD
# now let's rebuild the svn-ext on top
% git checkout svn-ext
% git pull --rebase
The last step can be git rebase git-svn, and the step to update
git-svn from Eric after checking it out can be git pull --rebase,
but the whole point of having @{u}, even for branches that fork from
a local branch, is so that the user does not have to remember what
forks from what, so I did not force her to say git rebase git-svn
in that step.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (May 2013, #06; Tue, 21)
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 final version of 1.8.3 is expected to be tagged late this week.
I have kept many late topics outside 'next' during the -rc period
primarily because the original plan was to keep the -rc period short
for this cycle, and because rebuilding 'next' after the release will
make it a lot more cumbersome to maintain the What's cooking
report if we have many topics on 'next' already. But we ended up
having to do an extra -rc3 so I merged a bunch of topics including
the late ones to 'next' with this pushout.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[New Topics]
* dm/unbash-subtree (2013-05-21) 1 commit
- contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash
* fc/transport-helper-no-refspec (2013-05-21) 2 commits
- transport-helper: check if the dry-run is supported
- transport-helper: barf when user tries old:new
* rr/die-on-missing-upstream (2013-05-21) 2 commits
- sha1_name: fix error message for @{N}, @{date}
- sha1_name: fix error message for @{u}
When a reflog notation is used for implicit current branch, we
did not say which branch and worse said branch ''.
* jc/show-branch (2013-05-21) 5 commits
- show-branch: use commit slab to represent bitflags of arbitrary width
- show-branch.c: remove all_mask
- show-branch.c: abstract out flags operation
- show-branch.c: lift all_mask/all_revs to a global static
- show-branch.c: update comment style
(this branch uses jk/commit-info-slab.)
--
[Stalled]
* rj/mingw-cygwin (2013-05-08) 2 commits
- cygwin: Remove the CYGWIN_V15_WIN32API build variable
- mingw: rename WIN32 cpp macro to GIT_WINDOWS_NATIVE
Update build for Cygwin 1.[57]. There seems to have been some
discussion but did anything concrete come out of it???
* mh/multimail (2013-04-21) 1 commit
- git-multimail: a replacement for post-receive-email
Waiting for the initial history to pull from.
$gmane/223564
* jc/format-patch (2013-04-22) 2 commits
- format-patch: --inline-single
- format-patch: rename no_inline field
A new option to send a single patch to the standard output to be
appended at the bottom of a message. I personally have no need for
this, but it was easy enough to cobble together. Tests, docs and
stripping out more MIMEy stuff are left as exercises to interested
parties.
Not ready for inclusion.
* jk/gitweb-utf8 (2013-04-08) 4 commits
- gitweb: Fix broken blob action parameters on blob/commitdiff pages
- gitweb: Don't append ';js=(0|1)' to external links
- gitweb: Make feed title valid utf8
- gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain,
and patch
Various fixes to gitweb.
Waiting for a reroll after a review.
* jk/commit-info-slab (2013-04-19) 3 commits
- commit-slab: introduce a macro to define a slab for new type
- commit-slab: avoid large realloc
- commit: allow associating auxiliary info on-demand
(this branch is used by jc/show-branch.)
Technology demonstration to show a way we could use unbound number
of flag bits on commit objects.
* jn/config-ignore-inaccessible (2013-04-15) 1 commit
(merged to 'next' on 2013-05-07 at 4f09e24)
+ config: allow inaccessible configuration under $HOME
When $HOME is misconfigured to point at an unreadable directory, we
used to complain and die. This loosens the check.
--
[Cooking]
* fc/remote-bzr (2013-05-16) 6 commits
- remote-bzr: trivial cleanups
- remote-bzr: change global repo
- remote-bzr: delay cloning/pulling
- remote-bzr: simplify get_remote_branch()
- remote-bzr: fix for files with spaces
- remote-bzr: recover from failed clones
The ones near the tip conflicted with the hotfix for 1.8.3 so I
discarded them for now.
* jx/clean-interactive (2013-05-20) 15 commits
- test: add t7301 for git-clean--interactive
- git-clean: add documentation for interactive git-clean
- git-clean: add ask each interactive action
- git-clean: add select by numbers interactive action
- git-clean: add filter by pattern interactive action
- git-clean: use a git-add-interactive compatible UI
- git-clean: add colors to interactive git-clean
- git-clean: show items of del_list in columns
- git-clean: add support for -i/--interactive
- git-clean: refactor git-clean into two phases
- Refactor write_name_quoted_relative, remove unused params
- Refactor quote_path_relative, remove unused params
- quote.c: remove path_relative, use relative_path instead
- path.c: refactor relative_path(), not only strip prefix
- test: add test cases for relative_path
* tr/test-v-and-v-subtest-only (2013-05-16) 6 commits
- test-lib:
Re: Reading commit objects
Chico Sokol wrote: We're trying to build a improved java library focused in our needs (jgit has a really confusing api focused in solving egit needs). JGit is also open to contributions, including contributions that add less confusing API calls. :) See http://wiki.eclipse.org/JGit/User_Guide http://wiki.eclipse.org/EGit/Contributor_Guide#JGit http://wiki.eclipse.org/EGit/Contributor_Guide#Using_Gerrit_at_https:.2F.2Fgit.eclipse.org.2Fr https://dev.eclipse.org/mailman/listinfo/jgit-dev Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prompt: fix show upstream with svn and zsh
On Tue, May 21, 2013 at 06:04:35PM -0500, Felipe Contreras wrote: On Tue, May 21, 2013 at 5:41 PM, SZEDER Gábor sze...@ira.uka.de wrote: On Tue, May 21, 2013 at 10:54:27PM +0200, Thomas Gummerer wrote: Currently the __git_ps1 git prompt gives the following error with a repository converted by git-svn, when used with zsh: __git_ps1_show_upstream:19: bad pattern: svn_remote[ This was introduced by 6d158cba (bash completion: Support divergence from upstream messages in __git_ps1), when the script was for bash only. Make it compatible with zsh. What is the actual cause of this problem/incompatibility and how/why do these changes fix it? I think the commit message makes that very clear. If that were the case I wouldn't have asked in the first place. Hth, Gábor -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prompt: fix show upstream with svn and zsh
On Tue, May 21, 2013 at 07:03:09PM -0500, Felipe Contreras wrote: On Tue, May 21, 2013 at 6:36 PM, SZEDER Gábor sze...@ira.uka.de wrote: On Tue, May 21, 2013 at 06:04:35PM -0500, Felipe Contreras wrote: On Tue, May 21, 2013 at 5:41 PM, SZEDER Gábor sze...@ira.uka.de wrote: On Tue, May 21, 2013 at 10:54:27PM +0200, Thomas Gummerer wrote: Currently the __git_ps1 git prompt gives the following error with a repository converted by git-svn, when used with zsh: __git_ps1_show_upstream:19: bad pattern: svn_remote[ This was introduced by 6d158cba (bash completion: Support divergence from upstream messages in __git_ps1), when the script was for bash only. Make it compatible with zsh. What is the actual cause of this problem/incompatibility and how/why do these changes fix it? I think the commit message makes that very clear. If that were the case I wouldn't have asked in the first place. You are not the authority on what *I think*, or if you meant s/If that were the case/If the message was clear/, still; you are not the authority on what is or is not true. Only on what is your opinion. I would have preferred a more constructive reply, perhaps with answers to the questions I asked earlier... Bye, Gábor -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] transport-helper: check if the dry-run is supported
Felipe Contreras felipe.contre...@gmail.com writes: On Tue, May 21, 2013 at 11:55 AM, Junio C Hamano gits...@pobox.com wrote: This sounds like a good thing to do. Perhaps the refspec mapping can be handled the same way as a backend feature so that you do not have to unconditionally disable it in the other patch. With my patch the remote helper doesn't need to know about the refspec handling at all, it just works magically. The consumers of git fast-export do not need to know how to flip refspecs when consuming output from git fast-export, because you taught git fast-export to do the mapping. But doesn't that coin have a flip side? When somebody else (not git) generates a fast-import stream, because these consumers are not prepared to flip refspecs, they cannot rename while importing. All the producers have to be taught to do the ref mapping. I do not know if this matters in real life, and even if it did, in the eventual ideal world, both importers and exporters would learn to do so. So I do not think what you did in your patch is a bad design in that sense. It is a half step in the right direction. I however found it somewhat ugly that the interface to specify set of refs to traverse history to find the set of objects to export stays the same as before, and the ref-mapping arguments are bolted on to the machinery, without having any relationship between them. The user is free to tell it to export only 'next', while telling it to map 'master' to 'trunk', for example. This is an external interface that is exposed to any users of git fast-export, so if we go that route, we would have to keep that interface working forever, even when later somebody else wants to add an interface that only requires ref-mapping arguments (and infer what is exported from the left hand side of the refspecs). That part is what I found is less than ideal in the patch. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Felipe Contreras felipe.contre...@gmail.com writes: On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: I still haven't received a response: which makes more sense? a) % git checkout svn-ext % git fetch From . * branchmaster - FETCH_HEAD # oops % git fetch git-svn % git log ..FETCH_HEAD % git merge FETCH_HEAD b) % git checkout svn-ext % git fetch From git://git.kernel.org/pub/scm/git/git 680ed3e..de3a5c6 master - origin/master # oops % git fetch svn-ext % git log ..FETCH_HEAD % git merge FETCH_HEAD I think with the scenario you are following, a) would prepare the FETCH_HEAD with her local git-svn branch which is her svn-ext topic is based on, but you illustrated it to fetch 'master', which I think is a minor typo. Modulo that typo, the step before the #oops makes perfect sense. It fetched where she told Git her work on svn-ext is based on. But the step after that does not make much sense in that flow. You don't get to decide what Sally (I'm naming her) does, all you get to decide is what Git does. Sally wants to fetch from the true upstream: svn-ext, but in the process does by mistake a 'git fetch' *without arguments* (WHICH IS WHAT THIS WHOLE DISCUSSION IS ABOUT). So now is the time you answer: a) or b). Heh, that was my example. In any case, my pick is still a). She *TOLD* Git that her local git-svn branch is what forms the base of her local svn-ext work. I won't even read the remainder. You are not even worth wasting time on discussing this. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v13 01/15] test: add test cases for relative_path
Add subcommand relative_path in test-path-utils, and add test cases
in t0060.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
t/t0060-path-utils.sh | 26 ++
test-path-utils.c | 25 +
2 files changed, 51 insertions(+)
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index 09a42..2199b 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -12,6 +12,11 @@ norm_path() {
test \\$(test-path-utils normalize_path_copy '$1')\ = '$2'
}
+relative_path() {
+ test_expect_success $4 relative path: $1 $2 = $3 \
+ test \\$(test-path-utils relative_path '$1' '$2')\ = '$3'
+}
+
# On Windows, we are using MSYS's bash, which mangles the paths.
# Absolute paths are anchored at the MSYS installation directory,
# which means that the path / accounts for this many characters:
@@ -183,4 +188,25 @@ test_expect_success SYMLINKS 'real path works on symlinks'
'
test $sym = $(test-path-utils real_path $dir2/syml)
'
+relative_path /a/b/c/ /a/b/ c/
+relative_path /a/b/c/ /a/bc/
+relative_path /a//b//c///a/b// c/
+relative_path /a/b /a/b.
+relative_path /a/b//a/b.
+relative_path /a /a/b/a
+relative_path //a/b/ /
+relative_path /a/c /a/b/ /a/c
+relative_path /a/c /a/b/a/c
+relative_path /a/b empty /a/b
+relative_path /a/b null/a/b
+relative_path empty/a/b(empty)
+relative_path emptyempty (empty)
+relative_path emptynull(empty)
+relative_path null empty (null)
+relative_path null null(null)
+
+test_expect_failure 'relative path: null /a/b = segfault' '
+ test-path-utils relative_path null /a/b
+'
+
test_done
diff --git a/test-path-utils.c b/test-path-utils.c
index 0092cb..dcc530 100644
--- a/test-path-utils.c
+++ b/test-path-utils.c
@@ -28,6 +28,19 @@ static int normalize_ceiling_entry(struct string_list_item
*item, void *unused)
return 1;
}
+static void normalize_argv_string(const char **var, const char *input)
+{
+ if (!strcmp(input, null))
+ *var = NULL;
+ else if (!strcmp(input, empty))
+ *var = ;
+ else
+ *var = input;
+
+ if (*var (**var == '' || **var == '('))
+ die(Bad value: %s\n, input);
+}
+
int main(int argc, char **argv)
{
if (argc == 3 !strcmp(argv[1], normalize_path_copy)) {
@@ -103,6 +116,18 @@ int main(int argc, char **argv)
return 0;
}
+ if (argc == 4 !strcmp(argv[1], relative_path)) {
+ const char *abs, *base, *rel;
+ normalize_argv_string(abs, argv[2]);
+ normalize_argv_string(base, argv[3]);
+ rel = relative_path(abs, base);
+ if (!rel)
+ puts((null));
+ else
+ puts(strlen(rel) 0 ? rel : (empty));
+ return 0;
+ }
+
fprintf(stderr, %s: unknown function name: %s\n, argv[0],
argv[1] ? argv[1] : (there was none));
return 1;
--
1.8.3.rc3.368.g7c798dd
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v13 02/15] path.c: refactor relative_path(), not only strip prefix
Original design of relative_path() is simple, just strip the prefix
(*base) from the absolute path (*abs). In most cases, we need a real
relative path, such as: ../foo, ../../bar. That's why there is another
reimplementation (path_relative()) in quote.c.
Refactor relative_path() in path.c to return real relative path, so
that user can reuse this function without reimplement his/her own.
I will use this method for interactive git-clean later. Some of the
implementations are borrowed from path_relative() in quote.c.
Different results for relative_path() before and after this refactor:
abs path base path relative (original) relative (refactor)
= === ===
/a/b/c/ /a/b c/ c/
/a/b//c/ //a///b/ c/ c/
/a/b /a/b ../
/a/b/ /a/b ../
/a/a/b/ /a ../
/ /a/b/ /../../
/a/c /a/b/ /a/c ../c
/a/b (empty)/a/b /a/b
/a/b (null) /a/b /a/b
(empty) /a/b (empty) ./
(null)(empty)(null) ./
(null)/a/b (segfault) ./
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
cache.h | 2 +-
path.c| 112 +++---
setup.c | 5 ++-
t/t0060-path-utils.sh | 27 ++--
test-path-utils.c | 4 +-
5 files changed, 107 insertions(+), 43 deletions(-)
diff --git a/cache.h b/cache.h
index 94ca1..4016c 100644
--- a/cache.h
+++ b/cache.h
@@ -737,7 +737,7 @@ int is_directory(const char *);
const char *real_path(const char *path);
const char *real_path_if_valid(const char *path);
const char *absolute_path(const char *path);
-const char *relative_path(const char *abs, const char *base);
+const char *relative_path(const char *abs, const char *base, struct strbuf
*sb);
int normalize_path_copy(char *dst, const char *src);
int longest_ancestor_length(const char *path, struct string_list *prefixes);
char *strip_path_suffix(const char *path, const char *suffix);
diff --git a/path.c b/path.c
index 04ff..0174d 100644
--- a/path.c
+++ b/path.c
@@ -441,42 +441,104 @@ int adjust_shared_perm(const char *path)
return 0;
}
-const char *relative_path(const char *abs, const char *base)
+/*
+ * Give path as relative to prefix.
+ *
+ * The strbuf may or may not be used, so do not assume it contains the
+ * returned path.
+ */
+const char *relative_path(const char *abs, const char *base,
+ struct strbuf *sb)
{
- static char buf[PATH_MAX + 1];
- int i = 0, j = 0;
-
- if (!base || !base[0])
+ int abs_off, base_off, i, j;
+ int abs_len, base_len;
+
+ abs_len = abs ? strlen(abs) : 0;
+ base_len = base ? strlen(base) : 0;
+ abs_off = 0;
+ base_off = 0;
+ i = 0;
+ j = 0;
+
+ if (!abs_len)
+ return ./;
+ else if (!base_len)
return abs;
- while (base[i]) {
+
+ while (i base_len j abs_len base[i] == abs[j]) {
if (is_dir_sep(base[i])) {
- if (!is_dir_sep(abs[j]))
- return abs;
while (is_dir_sep(base[i]))
i++;
while (is_dir_sep(abs[j]))
j++;
- continue;
- } else if (abs[j] != base[i]) {
+ base_off = i;
+ abs_off = j;
+ } else {
+ i++;
+ j++;
+ }
+ }
+
+ if (
+ /* base seems like prefix of abs */
+ i = base_len
+ /*
+* but /foo is not a prefix of /foobar
+* (i.e. base not end with '/')
+*/
+ base_off base_len) {
+ if (j = abs_len) {
+ /* abs=/a/b, base=/a/b */
+ abs_off = abs_len;
+ } else if (is_dir_sep(abs[j])) {
+ /* abs=/a/b/c, base=/a/b */
+ while (is_dir_sep(abs[j]))
+ j++;
+ abs_off = j;
+ } else {
+ /* abs=/a/bbb/c, base=/a/b */
+ i = base_off;
+ }
+ } else if (
+ /* abs is short than base (prefix of base) */
+ j = abs_len
+ /* abs not end with '/' */
+ abs_off abs_len) {
+ if (is_dir_sep(base[i])) {
+ /* abs=/a/b, base=/a/b/c/ */
+ while (is_dir_sep(base[i]))
+
[PATCH v13 03/15] quote.c: remove path_relative, use relative_path instead
Since there is an enhanced version of relative_path() in path.c,
remove duplicate counterpart path_relative() in quote.c.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
quote.c | 55 ++-
1 file changed, 2 insertions(+), 53 deletions(-)
diff --git a/quote.c b/quote.c
index 91122..64ff3 100644
--- a/quote.c
+++ b/quote.c
@@ -312,75 +312,24 @@ void write_name_quotedpfx(const char *pfx, size_t pfxlen,
fputc(terminator, fp);
}
-static const char *path_relative(const char *in, int len,
-struct strbuf *sb, const char *prefix,
-int prefix_len);
-
void write_name_quoted_relative(const char *name, size_t len,
const char *prefix, size_t prefix_len,
FILE *fp, int terminator)
{
struct strbuf sb = STRBUF_INIT;
- name = path_relative(name, len, sb, prefix, prefix_len);
+ name = relative_path(name, prefix, sb);
write_name_quoted(name, fp, terminator);
strbuf_release(sb);
}
-/*
- * Give path as relative to prefix.
- *
- * The strbuf may or may not be used, so do not assume it contains the
- * returned path.
- */
-static const char *path_relative(const char *in, int len,
-struct strbuf *sb, const char *prefix,
-int prefix_len)
-{
- int off, i;
-
- if (len 0)
- len = strlen(in);
- if (prefix_len 0) {
- if (prefix)
- prefix_len = strlen(prefix);
- else
- prefix_len = 0;
- }
-
- off = 0;
- i = 0;
- while (i prefix_len i len prefix[i] == in[i]) {
- if (prefix[i] == '/')
- off = i + 1;
- i++;
- }
- in += off;
- len -= off;
-
- if (i = prefix_len)
- return in;
-
- strbuf_reset(sb);
- strbuf_grow(sb, len);
-
- while (i prefix_len) {
- if (prefix[i] == '/')
- strbuf_addstr(sb, ../);
- i++;
- }
- strbuf_add(sb, in, len);
-
- return sb-buf;
-}
-
/* quote path as relative to the given prefix */
char *quote_path_relative(const char *in, int len,
struct strbuf *out, const char *prefix)
{
struct strbuf sb = STRBUF_INIT;
- const char *rel = path_relative(in, len, sb, prefix, -1);
+ const char *rel = relative_path(in, prefix, sb);
strbuf_reset(out);
quote_c_style_counted(rel, strlen(rel), out, NULL, 0);
strbuf_release(sb);
--
1.8.3.rc3.368.g7c798dd
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v13 04/15] Refactor quote_path_relative, remove unused params
After substitute path_relative() in quote.c with relative_path() from
path.c, parameters (such as len and prefix_len) are obsolete in function
quote_path_relative(). Remove unused parameters and change the order of
parameters for quote_path_relative() function.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/clean.c| 18 +-
builtin/grep.c | 5 ++---
builtin/ls-files.c | 2 +-
quote.c| 7 ++-
quote.h| 4 ++--
wt-status.c| 17 -
6 files changed, 24 insertions(+), 29 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 04e39..f77f95 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -56,7 +56,7 @@ static int remove_dirs(struct strbuf *path, const char
*prefix, int force_flag,
if ((force_flag REMOVE_DIR_KEEP_NESTED_GIT)
!resolve_gitlink_ref(path-buf, HEAD,
submodule_head)) {
if (!quiet) {
- quote_path_relative(path-buf, strlen(path-buf),
quoted, prefix);
+ quote_path_relative(path-buf, prefix, quoted);
printf(dry_run ? _(msg_would_skip_git_dir) :
_(msg_skip_git_dir),
quoted.buf);
}
@@ -70,7 +70,7 @@ static int remove_dirs(struct strbuf *path, const char
*prefix, int force_flag,
/* an empty dir could be removed even if it is unreadble */
res = dry_run ? 0 : rmdir(path-buf);
if (res) {
- quote_path_relative(path-buf, strlen(path-buf),
quoted, prefix);
+ quote_path_relative(path-buf, prefix, quoted);
warning(_(msg_warn_remove_failed), quoted.buf);
*dir_gone = 0;
}
@@ -94,7 +94,7 @@ static int remove_dirs(struct strbuf *path, const char
*prefix, int force_flag,
if (remove_dirs(path, prefix, force_flag, dry_run,
quiet, gone))
ret = 1;
if (gone) {
- quote_path_relative(path-buf,
strlen(path-buf), quoted, prefix);
+ quote_path_relative(path-buf, prefix, quoted);
string_list_append(dels, quoted.buf);
} else
*dir_gone = 0;
@@ -102,10 +102,10 @@ static int remove_dirs(struct strbuf *path, const char
*prefix, int force_flag,
} else {
res = dry_run ? 0 : unlink(path-buf);
if (!res) {
- quote_path_relative(path-buf,
strlen(path-buf), quoted, prefix);
+ quote_path_relative(path-buf, prefix, quoted);
string_list_append(dels, quoted.buf);
} else {
- quote_path_relative(path-buf,
strlen(path-buf), quoted, prefix);
+ quote_path_relative(path-buf, prefix, quoted);
warning(_(msg_warn_remove_failed), quoted.buf);
*dir_gone = 0;
ret = 1;
@@ -127,7 +127,7 @@ static int remove_dirs(struct strbuf *path, const char
*prefix, int force_flag,
if (!res)
*dir_gone = 1;
else {
- quote_path_relative(path-buf, strlen(path-buf),
quoted, prefix);
+ quote_path_relative(path-buf, prefix, quoted);
warning(_(msg_warn_remove_failed), quoted.buf);
*dir_gone = 0;
ret = 1;
@@ -262,7 +262,7 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
if (remove_dirs(directory, prefix, rm_flags,
dry_run, quiet, gone))
errors++;
if (gone !quiet) {
- qname =
quote_path_relative(directory.buf, directory.len, buf, prefix);
+ qname =
quote_path_relative(directory.buf, prefix, buf);
printf(dry_run ? _(msg_would_remove) :
_(msg_remove), qname);
}
}
@@ -272,11 +272,11 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
continue;
res = dry_run ? 0 : unlink(ent-name);
if (res) {
- qname = quote_path_relative(ent-name, -1,
buf, prefix);
+ qname = quote_path_relative(ent-name, prefix,
buf);
warning(_(msg_warn_remove_failed), qname);
errors++;
[PATCH v13 07/15] git-clean: add support for -i/--interactive
Show what would be done and the user must confirm before actually
cleaning.
Would remove ...
Would remove ...
Would remove ...
Remove [y/n]?
Press y to start cleaning, and press n if you want to abort.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-clean.txt | 10 ++--
builtin/clean.c | 57 +
2 files changed, 60 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index bdc3a..186e34 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -8,7 +8,7 @@ git-clean - Remove untracked files from the working tree
SYNOPSIS
[verse]
-'git clean' [-d] [-f] [-n] [-q] [-e pattern] [-x | -X] [--] path...
+'git clean' [-d] [-f] [-i] [-n] [-q] [-e pattern] [-x | -X] [--] path...
DESCRIPTION
---
@@ -34,7 +34,13 @@ OPTIONS
-f::
--force::
If the Git configuration variable clean.requireForce is not set
- to false, 'git clean' will refuse to run unless given -f or -n.
+ to false, 'git clean' will refuse to run unless given -f, -n or
+ -i.
+
+-i::
+--interactive::
+ Show what would be done and the user must confirm before actually
+ cleaning.
-n::
--dry-run::
diff --git a/builtin/clean.c b/builtin/clean.c
index 77ec1..698fb 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -15,10 +15,11 @@
#include quote.h
static int force = -1; /* unset */
+static int interactive;
static struct string_list del_list = STRING_LIST_INIT_DUP;
static const char *const builtin_clean_usage[] = {
- N_(git clean [-d] [-f] [-n] [-q] [-e pattern] [-x | -X] [--]
paths...),
+ N_(git clean [-d] [-f] [-i] [-n] [-q] [-e pattern] [-x | -X] [--]
paths...),
NULL
};
@@ -143,6 +144,50 @@ static int remove_dirs(struct strbuf *path, const char
*prefix, int force_flag,
return ret;
}
+static void interactive_main_loop(void)
+{
+ struct strbuf confirm = STRBUF_INIT;
+ struct strbuf buf = STRBUF_INIT;
+ struct string_list_item *item;
+ const char *qname;
+
+ while (del_list.nr) {
+ putchar('\n');
+ for_each_string_list_item(item, del_list) {
+ qname = quote_path_relative(item-string, NULL, buf);
+ printf(_(msg_would_remove), qname);
+ }
+ putchar('\n');
+
+ printf(_(Remove [y/n]? ));
+ if (strbuf_getline(confirm, stdin, '\n') != EOF) {
+ strbuf_trim(confirm);
+ } else {
+ /* Ctrl-D is the same as quit */
+ string_list_clear(del_list, 0);
+ putchar('\n');
+ printf_ln(Bye.);
+ break;
+ }
+
+ if (confirm.len) {
+ if (!strncasecmp(confirm.buf, yes, confirm.len)) {
+ break;
+ } else if (!strncasecmp(confirm.buf, no, confirm.len)
||
+ !strncasecmp(confirm.buf, quit,
confirm.len)) {
+ string_list_clear(del_list, 0);
+ printf_ln(Bye.);
+ break;
+ } else {
+ continue;
+ }
+ }
+ }
+
+ strbuf_release(buf);
+ strbuf_release(confirm);
+}
+
int cmd_clean(int argc, const char **argv, const char *prefix)
{
int i, res;
@@ -162,6 +207,7 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
OPT__QUIET(quiet, N_(do not print names of files removed)),
OPT__DRY_RUN(dry_run, N_(dry run)),
OPT__FORCE(force, N_(force)),
+ OPT_BOOL('i', interactive, interactive, N_(interactive
cleaning)),
OPT_BOOLEAN('d', NULL, remove_directories,
N_(remove whole directories)),
{ OPTION_CALLBACK, 'e', exclude, exclude_list, N_(pattern),
@@ -188,12 +234,12 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
if (ignored ignored_only)
die(_(-x and -X cannot be used together));
- if (!dry_run !force) {
+ if (!interactive !dry_run !force) {
if (config_set)
- die(_(clean.requireForce set to true and neither -n
nor -f given;
+ die(_(clean.requireForce set to true and neither -i,
-n nor -f given;
refusing to clean));
else
- die(_(clean.requireForce defaults to true and neither
-n nor -f given;
+ die(_(clean.requireForce defaults to true and neither
-i, -n nor -f given;
[PATCH v13 06/15] git-clean: refactor git-clean into two phases
Before introducing interactive git-clean, refactor git-clean operations
into two phases:
* hold cleaning items in del_list,
* and remove them in a separate loop at the end.
We will introduce interactive git-clean between the two phases. The
interactive git-clean will show what would be done and must confirm
before do real cleaning.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/clean.c | 64 -
1 file changed, 45 insertions(+), 19 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index f77f95..77ec1 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -15,6 +15,7 @@
#include quote.h
static int force = -1; /* unset */
+static struct string_list del_list = STRING_LIST_INIT_DUP;
static const char *const builtin_clean_usage[] = {
N_(git clean [-d] [-f] [-n] [-q] [-e pattern] [-x | -X] [--]
paths...),
@@ -148,12 +149,13 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
int dry_run = 0, remove_directories = 0, quiet = 0, ignored = 0;
int ignored_only = 0, config_set = 0, errors = 0, gone = 1;
int rm_flags = REMOVE_DIR_KEEP_NESTED_GIT;
- struct strbuf directory = STRBUF_INIT;
+ struct strbuf abs_path = STRBUF_INIT;
struct dir_struct dir;
static const char **pathspec;
struct strbuf buf = STRBUF_INIT;
struct string_list exclude_list = STRING_LIST_INIT_NODUP;
struct exclude_list *el;
+ struct string_list_item *item;
const char *qname;
char *seen = NULL;
struct option options[] = {
@@ -223,6 +225,7 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
int matches = 0;
struct cache_entry *ce;
struct stat st;
+ const char *rel;
/*
* Remove the '/' at the end that directory
@@ -242,13 +245,8 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
continue; /* Yup, this one exists unmerged */
}
- /*
-* we might have removed this as part of earlier
-* recursive directory removal, so lstat() here could
-* fail with ENOENT.
-*/
if (lstat(ent-name, st))
- continue;
+ die_errno(Cannot lstat '%s', ent-name);
if (pathspec) {
memset(seen, 0, argc 0 ? argc : 1);
@@ -257,33 +255,61 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
}
if (S_ISDIR(st.st_mode)) {
- strbuf_addstr(directory, ent-name);
if (remove_directories || (matches == MATCHED_EXACTLY))
{
- if (remove_dirs(directory, prefix, rm_flags,
dry_run, quiet, gone))
- errors++;
- if (gone !quiet) {
- qname =
quote_path_relative(directory.buf, prefix, buf);
- printf(dry_run ? _(msg_would_remove) :
_(msg_remove), qname);
- }
+ rel = relative_path(ent-name, prefix, buf);
+ string_list_append(del_list, rel);
}
- strbuf_reset(directory);
} else {
if (pathspec !matches)
continue;
- res = dry_run ? 0 : unlink(ent-name);
+ rel = relative_path(ent-name, prefix, buf);
+ string_list_append(del_list, rel);
+ }
+ }
+
+ /* TODO: do interactive git-clean here, which will modify del_list */
+
+ for_each_string_list_item(item, del_list) {
+ struct stat st;
+
+ if (prefix)
+ strbuf_addstr(abs_path, prefix);
+
+ strbuf_addstr(abs_path, item-string);
+
+ /*
+* we might have removed this as part of earlier
+* recursive directory removal, so lstat() here could
+* fail with ENOENT.
+*/
+ if (lstat(abs_path.buf, st))
+ continue;
+
+ if (S_ISDIR(st.st_mode)) {
+ if (remove_dirs(abs_path, prefix, rm_flags, dry_run,
quiet, gone))
+ errors++;
+ if (gone !quiet) {
+ qname = quote_path_relative(item-string, NULL,
buf);
+ printf(dry_run ? _(msg_would_remove) :
_(msg_remove), qname);
+ }
+ } else {
+ res = dry_run ? 0 :
[PATCH v13 08/15] git-clean: show items of del_list in columns
When there are lots of items to be cleaned, it is hard to see them all
in one screen. Show them in columns will solve this problem.
Signed-off-by: Jiang Xin worldhello@gmail.com
Comments-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/config.txt | 4
builtin/clean.c | 49 +++-
2 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6e53f..e031b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -955,6 +955,10 @@ column.branch::
Specify whether to output branch listing in `git branch` in columns.
See `column.ui` for details.
+column.clean::
+ Specify the layout when list items in `git clean -i`, which always
+ shows files and directories in columns. See `column.ui` for details.
+
column.status::
Specify whether to output untracked files in `git status` in columns.
See `column.ui` for details.
diff --git a/builtin/clean.c b/builtin/clean.c
index 698fb..75cc6 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -13,10 +13,12 @@
#include refs.h
#include string-list.h
#include quote.h
+#include column.h
static int force = -1; /* unset */
static int interactive;
static struct string_list del_list = STRING_LIST_INIT_DUP;
+static unsigned int colopts;
static const char *const builtin_clean_usage[] = {
N_(git clean [-d] [-f] [-i] [-n] [-q] [-e pattern] [-x | -X] [--]
paths...),
@@ -31,8 +33,13 @@ static const char *msg_warn_remove_failed = N_(failed to
remove %s);
static int git_clean_config(const char *var, const char *value, void *cb)
{
- if (!strcmp(var, clean.requireforce))
+ if (!prefixcmp(var, column.))
+ return git_column_config(var, value, clean, colopts);
+
+ if (!strcmp(var, clean.requireforce)) {
force = !git_config_bool(var, value);
+ return 0;
+ }
return git_default_config(var, value, cb);
}
@@ -144,21 +151,46 @@ static int remove_dirs(struct strbuf *path, const char
*prefix, int force_flag,
return ret;
}
-static void interactive_main_loop(void)
+static void pretty_print_dels(void)
{
- struct strbuf confirm = STRBUF_INIT;
- struct strbuf buf = STRBUF_INIT;
+ struct string_list list = STRING_LIST_INIT_DUP;
struct string_list_item *item;
+ struct strbuf buf = STRBUF_INIT;
const char *qname;
+ struct column_options copts;
+
+ for_each_string_list_item(item, del_list) {
+ qname = quote_path_relative(item-string, NULL, buf);
+ string_list_append(list, qname);
+ }
+
+ /*
+* always enable column display, we only consult column.*
+* about layout strategy and stuff
+*/
+ colopts = (colopts ~COL_ENABLE_MASK) | COL_ENABLED;
+ memset(copts, 0, sizeof(copts));
+ copts.indent = ;
+ copts.padding = 2;
+ print_columns(list, colopts, copts);
+ putchar('\n');
+ strbuf_release(buf);
+ string_list_clear(list, 0);
+}
+
+static void interactive_main_loop(void)
+{
+ struct strbuf confirm = STRBUF_INIT;
while (del_list.nr) {
putchar('\n');
- for_each_string_list_item(item, del_list) {
- qname = quote_path_relative(item-string, NULL, buf);
- printf(_(msg_would_remove), qname);
- }
+ printf_ln(Q_(Would remove the following item:,
+Would remove the following items:,
+del_list.nr));
putchar('\n');
+ pretty_print_dels();
+
printf(_(Remove [y/n]? ));
if (strbuf_getline(confirm, stdin, '\n') != EOF) {
strbuf_trim(confirm);
@@ -184,7 +216,6 @@ static void interactive_main_loop(void)
}
}
- strbuf_release(buf);
strbuf_release(confirm);
}
--
1.8.3.rc3.368.g7c798dd
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v13 09/15] git-clean: add colors to interactive git-clean
Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables, such as color.interactive and
color.interactive.slot for command `git-add--interactive`.
Signed-off-by: Jiang Xin worldhello@gmail.com
Comments-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/config.txt | 17 +--
builtin/clean.c | 73 +++-
2 files changed, 81 insertions(+), 9 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e031b..83613 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -876,16 +876,17 @@ The values of these variables may be specified as in
color.branch.slot.
color.interactive::
When set to `always`, always use colors for interactive prompts
- and displays (such as those used by git-add --interactive).
- When false (or `never`), never. When set to `true` or `auto`, use
- colors only when the output is to the terminal. Defaults to false.
+ and displays (such as those used by git-add --interactive and
+ git-clean --interactive). When false (or `never`), never.
+ When set to `true` or `auto`, use colors only when the output is
+ to the terminal. Defaults to false.
color.interactive.slot::
- Use customized color for 'git add --interactive'
- output. `slot` may be `prompt`, `header`, `help` or `error`, for
- four distinct types of normal output from interactive
- commands. The values of these variables may be specified as
- in color.branch.slot.
+ Use customized color for 'git add --interactive' and 'git clean
+ --interactive' output. `slot` may be `prompt`, `header`, `help`
+ or `error`, for four distinct types of normal output from
+ interactive commands. The values of these variables may be
+ specified as in color.branch.slot.
color.pager::
A boolean to enable/disable colored output when the pager is in
diff --git a/builtin/clean.c b/builtin/clean.c
index 75cc6..dfa99b 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -14,6 +14,7 @@
#include string-list.h
#include quote.h
#include column.h
+#include color.h
static int force = -1; /* unset */
static int interactive;
@@ -31,16 +32,82 @@ static const char *msg_skip_git_dir = N_(Skipping
repository %s\n);
static const char *msg_would_skip_git_dir = N_(Would skip repository %s\n);
static const char *msg_warn_remove_failed = N_(failed to remove %s);
+static int clean_use_color = -1;
+static char clean_colors[][COLOR_MAXLEN] = {
+ GIT_COLOR_RESET,
+ GIT_COLOR_NORMAL, /* PLAIN */
+ GIT_COLOR_BOLD_BLUE,/* PROMPT */
+ GIT_COLOR_BOLD, /* HEADER */
+ GIT_COLOR_BOLD_RED, /* HELP */
+ GIT_COLOR_BOLD_RED, /* ERROR */
+};
+enum color_clean {
+ CLEAN_COLOR_RESET = 0,
+ CLEAN_COLOR_PLAIN = 1,
+ CLEAN_COLOR_PROMPT = 2,
+ CLEAN_COLOR_HEADER = 3,
+ CLEAN_COLOR_HELP = 4,
+ CLEAN_COLOR_ERROR = 5,
+};
+
+static int parse_clean_color_slot(const char *var)
+{
+ if (!strcasecmp(var, reset))
+ return CLEAN_COLOR_RESET;
+ if (!strcasecmp(var, plain))
+ return CLEAN_COLOR_PLAIN;
+ if (!strcasecmp(var, prompt))
+ return CLEAN_COLOR_PROMPT;
+ if (!strcasecmp(var, header))
+ return CLEAN_COLOR_HEADER;
+ if (!strcasecmp(var, help))
+ return CLEAN_COLOR_HELP;
+ if (!strcasecmp(var, error))
+ return CLEAN_COLOR_ERROR;
+ return -1;
+}
+
static int git_clean_config(const char *var, const char *value, void *cb)
{
if (!prefixcmp(var, column.))
return git_column_config(var, value, clean, colopts);
+ /* honors the color.interactive* config variables which also
+ applied in git-add--interactive and git-stash */
+ if (!strcmp(var, color.interactive)) {
+ clean_use_color = git_config_colorbool(var, value);
+ return 0;
+ }
+ if (!prefixcmp(var, color.interactive.)) {
+ int slot = parse_clean_color_slot(var +
+ strlen(color.interactive.));
+ if (slot 0)
+ return 0;
+ if (!value)
+ return config_error_nonbool(var);
+ color_parse(value, var, clean_colors[slot]);
+ return 0;
+ }
+
if (!strcmp(var, clean.requireforce)) {
force = !git_config_bool(var, value);
return 0;
}
- return git_default_config(var, value, cb);
+
+ /* inspect the color.ui config variable and others */
+ return git_color_default_config(var, value, cb);
+}
+
+static const char *clean_get_color(enum color_clean ix)
+{
+ if (want_color(clean_use_color))
+
[PATCH v13 10/15] git-clean: use a git-add-interactive compatible UI
Rewrite menu using a new method `list_and_choose`, which is borrowed
from `git-add--interactive.perl`. We will use this framework to add
new actions for interactive git-clean later.
Please NOTE:
* Method `list_and_choose` return an array of integers, and
* it is up to you to free the allocated memory of the array.
* The array ends with EOF.
* If user pressed CTRL-D (i.e. EOF), no selection returned.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/clean.c | 456
1 file changed, 427 insertions(+), 29 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index dfa99b..df887 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -50,6 +50,36 @@ enum color_clean {
CLEAN_COLOR_ERROR = 5,
};
+#define MENU_OPTS_SINGLETON01
+#define MENU_OPTS_IMMEDIATE02
+#define MENU_OPTS_LIST_ONLY04
+
+struct menu_opts {
+ const char *header;
+ const char *prompt;
+ int flags;
+};
+
+#define MENU_RETURN_NO_LOOP10
+
+struct menu_item {
+ char hotkey;
+ const char *title;
+ int selected;
+ int (*fn)();
+};
+
+enum menu_stuff_type {
+ MENU_STUFF_TYPE_STRING_LIST = 1,
+ MENU_STUFF_TYPE_MENU_ITEM
+};
+
+struct menu_stuff {
+ enum menu_stuff_type type;
+ int nr;
+ void *stuff;
+};
+
static int parse_clean_color_slot(const char *var)
{
if (!strcasecmp(var, reset))
@@ -240,54 +270,422 @@ static void pretty_print_dels(void)
copts.indent = ;
copts.padding = 2;
print_columns(list, colopts, copts);
- putchar('\n');
strbuf_release(buf);
string_list_clear(list, 0);
}
-static void interactive_main_loop(void)
+static void pretty_print_menus(struct string_list *menu_list)
+{
+ unsigned int local_colopts = 0;
+ struct column_options copts;
+
+ local_colopts = COL_ENABLED | COL_ROW;
+ memset(copts, 0, sizeof(copts));
+ copts.indent = ;
+ copts.padding = 2;
+ print_columns(menu_list, local_colopts, copts);
+}
+
+static void prompt_help_cmd(int singleton)
+{
+ clean_print_color(CLEAN_COLOR_HELP);
+ printf_ln(singleton ?
+ _(Prompt help:\n
+ 1 - select a numbered item\n
+ foo- select item based on unique prefix\n
+ - (empty) select nothing) :
+ _(Prompt help:\n
+ 1 - select a single item\n
+ 3-5- select a range of items\n
+ 2-3,6-9- select multiple ranges\n
+ foo- select item based on unique prefix\n
+ -... - unselect specified items\n
+ * - choose all items\n
+ - (empty) finish selecting));
+ clean_print_color(CLEAN_COLOR_RESET);
+}
+
+/*
+ * display menu stuff with number prefix and hotkey highlight
+ */
+static void print_highlight_menu_stuff(struct menu_stuff *stuff, int **chosen)
+{
+ struct string_list menu_list = STRING_LIST_INIT_DUP;
+ struct strbuf menu = STRBUF_INIT;
+ struct strbuf buf = STRBUF_INIT;
+ struct menu_item *menu_item;
+ struct string_list_item *string_list_item;
+ int i;
+
+ switch (stuff-type) {
+ default:
+ die(Bad type of menu_staff when print menu);
+ case MENU_STUFF_TYPE_MENU_ITEM:
+ menu_item = (struct menu_item *)stuff-stuff;
+ for (i = 0; i stuff-nr; i++, menu_item++) {
+ const char *p;
+ int highlighted = 0;
+
+ p = menu_item-title;
+ if ((*chosen)[i] 0)
+ (*chosen)[i] = menu_item-selected ? 1 : 0;
+ strbuf_addf(menu, %s%2d: , (*chosen)[i] ? * : ,
i+1);
+ for (; *p; p++) {
+ if (!highlighted *p == menu_item-hotkey) {
+ strbuf_addstr(menu,
clean_get_color(CLEAN_COLOR_PROMPT));
+ strbuf_addch(menu, *p);
+ strbuf_addstr(menu,
clean_get_color(CLEAN_COLOR_RESET));
+ highlighted = 1;
+ } else {
+ strbuf_addch(menu, *p);
+ }
+ }
+ string_list_append(menu_list, menu.buf);
+ strbuf_reset(menu);
+ }
+ break;
+ case MENU_STUFF_TYPE_STRING_LIST:
+ i = 0;
+ for_each_string_list_item(string_list_item, (struct string_list
*)stuff-stuff) {
+ if ((*chosen)[i] 0)
+
[PATCH v13 11/15] git-clean: add filter by pattern interactive action
Add a new action for interactive git-clean: filter by pattern. When the
user chooses this action, user can input space-separated patterns (the
same syntax as gitignore), and each clean candidate that matches with
one of the patterns will be excluded from cleaning. When the user feels
it's OK, presses ENTER and backs to the confirmation dialog.
Signed-off-by: Jiang Xin worldhello@gmail.com
Suggested-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/clean.c | 68 +
1 file changed, 68 insertions(+)
diff --git a/builtin/clean.c b/builtin/clean.c
index df887..36369 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -614,6 +614,72 @@ static int clean_cmd(void)
return MENU_RETURN_NO_LOOP;
}
+static int filter_by_patterns_cmd(void)
+{
+ struct dir_struct dir;
+ struct strbuf confirm = STRBUF_INIT;
+ struct strbuf **ignore_list;
+ struct string_list_item *item;
+ struct exclude_list *el;
+ int changed = -1, i;
+
+ for (;;) {
+ if (!del_list.nr)
+ break;
+
+ if (changed)
+ pretty_print_dels();
+
+ clean_print_color(CLEAN_COLOR_PROMPT);
+ printf(_(Input ignore patterns ));
+ clean_print_color(CLEAN_COLOR_RESET);
+ if (strbuf_getline(confirm, stdin, '\n') != EOF)
+ strbuf_trim(confirm);
+ else
+ putchar('\n');
+
+ /* quit filter_by_pattern mode if press ENTER or Ctrl-D */
+ if (!confirm.len)
+ break;
+
+ memset(dir, 0, sizeof(dir));
+ el = add_exclude_list(dir, EXC_CMDL, manual exclude);
+ ignore_list = strbuf_split_max(confirm, ' ', 0);
+
+ for (i = 0; ignore_list[i]; i++) {
+ strbuf_trim(ignore_list[i]);
+ if (!ignore_list[i]-len)
+ continue;
+
+ add_exclude(ignore_list[i]-buf, , 0, el, -(i+1));
+ }
+
+ changed = 0;
+ for_each_string_list_item(item, del_list) {
+ int dtype = DT_UNKNOWN;
+
+ if (is_excluded(dir, item-string, dtype)) {
+ *item-string = '\0';
+ changed++;
+ }
+ }
+
+ if (changed) {
+ string_list_remove_empty_items(del_list, 0);
+ } else {
+ clean_print_color(CLEAN_COLOR_ERROR);
+ printf_ln(_(WARNING: Cannot find items matched by:
%s), confirm.buf);
+ clean_print_color(CLEAN_COLOR_RESET);
+ }
+
+ strbuf_list_free(ignore_list);
+ clear_directory(dir);
+ }
+
+ strbuf_release(confirm);
+ return 0;
+}
+
static int quit_cmd(void)
{
string_list_clear(del_list, 0);
@@ -626,6 +692,7 @@ static int help_cmd(void)
clean_print_color(CLEAN_COLOR_HELP);
printf_ln(_(
clean - start cleaning\n
+ filter by pattern - exclude items from deletion\n
quit- stop cleaning\n
help- this screen\n
? - help for prompt selection
@@ -641,6 +708,7 @@ static void interactive_main_loop(void)
struct menu_stuff menu_stuff;
struct menu_item menus[] = {
{'c', clean, 0, clean_cmd},
+ {'f', filter by pattern, 0,
filter_by_patterns_cmd},
{'q', quit, 0, quit_cmd},
{'h', help, 0, help_cmd},
};
--
1.8.3.rc3.368.g7c798dd
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v13 12/15] git-clean: add select by numbers interactive action
Draw a multiple choice menu using `list_and_choose` to select items
to be deleted by numbers.
User can input:
* 1,5-7 : select 1,5,6,7 items to be deleted
* * : select all items to be deleted
* -*: unselect all, nothing will be deleted
*: (empty) finish selecting, and return back to main menu
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/clean.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/builtin/clean.c b/builtin/clean.c
index 36369..643a5e 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -680,6 +680,43 @@ static int filter_by_patterns_cmd(void)
return 0;
}
+static int select_by_numbers_cmd(void)
+{
+ struct menu_opts menu_opts;
+ struct menu_stuff menu_stuff;
+ struct string_list_item *items;
+ int *chosen;
+ int i, j;
+
+ menu_opts.header = NULL;
+ menu_opts.prompt = N_(Select items to delete);
+ menu_opts.flags = 0;
+
+ menu_stuff.type = MENU_STUFF_TYPE_STRING_LIST;
+ menu_stuff.stuff = del_list;
+ menu_stuff.nr = del_list.nr;
+
+ chosen = list_and_choose(menu_opts, menu_stuff);
+ items = del_list.items;
+ for (i = 0, j = 0; i del_list.nr; i++) {
+ if (i chosen[j]) {
+ *(items[i].string) = '\0';
+ } else if (i == chosen[j]) {
+ /* delete selected item */
+ j++;
+ continue;
+ } else {
+ /* end of chosen (chosen[j] == EOF), won't delete */
+ *(items[i].string) = '\0';
+ }
+ }
+
+ string_list_remove_empty_items(del_list, 0);
+
+ free(chosen);
+ return 0;
+}
+
static int quit_cmd(void)
{
string_list_clear(del_list, 0);
@@ -693,6 +730,7 @@ static int help_cmd(void)
printf_ln(_(
clean - start cleaning\n
filter by pattern - exclude items from deletion\n
+ select by numbers - select items to be deleted by
numbers\n
quit- stop cleaning\n
help- this screen\n
? - help for prompt selection
@@ -709,6 +747,7 @@ static void interactive_main_loop(void)
struct menu_item menus[] = {
{'c', clean, 0, clean_cmd},
{'f', filter by pattern, 0,
filter_by_patterns_cmd},
+ {'s', select by numbers, 0,
select_by_numbers_cmd},
{'q', quit, 0, quit_cmd},
{'h', help, 0, help_cmd},
};
--
1.8.3.rc3.368.g7c798dd
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v13 14/15] git-clean: add documentation for interactive git-clean
Add new section Interactive mode for documentation of interactive git-clean. Signed-off-by: Jiang Xin worldhello@gmail.com Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/git-clean.txt | 65 +++-- 1 file changed, 63 insertions(+), 2 deletions(-) diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt index 186e34..5bf76 100644 --- a/Documentation/git-clean.txt +++ b/Documentation/git-clean.txt @@ -39,8 +39,8 @@ OPTIONS -i:: --interactive:: - Show what would be done and the user must confirm before actually - cleaning. + Show what would be done and clean files interactively. See + ``Interactive mode'' for details. -n:: --dry-run:: @@ -69,6 +69,67 @@ OPTIONS Remove only files ignored by Git. This may be useful to rebuild everything from scratch, but keep manually created files. +Interactive mode + +When the command enters the interactive mode, it shows the +files and directories to be cleaned, and goes into its +interactive command loop. + +The command loop shows the list of subcommands available, and +gives a prompt What now . In general, when the prompt ends +with a single '', you can pick only one of the choices given +and type return, like this: + + +*** Commands *** +1: clean2: filter by pattern3: select by numbers +4: ask each 5: quit 6: help +What now 1 + + +You also could say `c` or `clean` above as long as the choice is unique. + +The main command loop has 6 subcommands. + +clean:: + + Start cleaning files and directories, and then quit. + +filter by pattern:: + + This shows the files and directories to be deleted and issues an + Input ignore patterns prompt. You can input space-seperated + patterns to exclude files and directories from deletion. + E.g. *.c *.h will excludes files end with .c and .h from + deletion. When you are satisfied with the filtered result, press + ENTER (empty) back to the main menu. + +select by numbers:: + + This shows the files and directories to be deleted and issues an + Select items to delete prompt. When the prompt ends with double + '' like this, you can make more than one selection, concatenated + with whitespace or comma. Also you can say ranges. E.g. 2-5 7,9 + to choose 2,3,4,5,7,9 from the list. If the second number in a + range is omitted, all remaining patches are taken. E.g. 7- to + choose 7,8,9 from the list. You can say '*' to choose everything. + Also when you are satisfied with the filtered result, press ENTER + (empty) back to the main menu. + +ask each:: + + This will start to clean, and you must confirm one by one in order + to delete items. Please note that this action is not as efficient + as the above two actions. + +quit:: + + This lets you quit without do cleaning. + +help:: + + Show brief usage of interactive git-clean. + SEE ALSO linkgit:gitignore[5] -- 1.8.3.rc3.368.g7c798dd -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v13 13/15] git-clean: add ask each interactive action
Add a new action for interactive git-clean: ask each. It's just like
the rm -i command, that the user must confirm one by one for each
file or directory to be cleaned.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/clean.c | 36
1 file changed, 36 insertions(+)
diff --git a/builtin/clean.c b/builtin/clean.c
index 643a5e..bf03a 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -717,6 +717,40 @@ static int select_by_numbers_cmd(void)
return 0;
}
+static int ask_each_cmd(void)
+{
+ struct strbuf confirm = STRBUF_INIT;
+ struct strbuf buf = STRBUF_INIT;
+ struct string_list_item *item;
+ const char *qname;
+ int changed = 0, eof = 0;
+
+ for_each_string_list_item(item, del_list) {
+ /* Ctrl-D should stop removing files */
+ if (!eof) {
+ qname = quote_path_relative(item-string, NULL, buf);
+ printf(_(remove %s? ), qname);
+ if (strbuf_getline(confirm, stdin, '\n') != EOF) {
+ strbuf_trim(confirm);
+ } else {
+ putchar('\n');
+ eof = 1;
+ }
+ }
+ if (!confirm.len || strncasecmp(confirm.buf, yes,
confirm.len)) {
+ *item-string = '\0';
+ changed++;
+ }
+ }
+
+ if (changed)
+ string_list_remove_empty_items(del_list, 0);
+
+ strbuf_release(buf);
+ strbuf_release(confirm);
+ return MENU_RETURN_NO_LOOP;
+}
+
static int quit_cmd(void)
{
string_list_clear(del_list, 0);
@@ -731,6 +765,7 @@ static int help_cmd(void)
clean - start cleaning\n
filter by pattern - exclude items from deletion\n
select by numbers - select items to be deleted by
numbers\n
+ ask each- confirm each deletion (like \rm
-i\)\n
quit- stop cleaning\n
help- this screen\n
? - help for prompt selection
@@ -748,6 +783,7 @@ static void interactive_main_loop(void)
{'c', clean, 0, clean_cmd},
{'f', filter by pattern, 0,
filter_by_patterns_cmd},
{'s', select by numbers, 0,
select_by_numbers_cmd},
+ {'a', ask each, 0, ask_each_cmd},
{'q', quit, 0, quit_cmd},
{'h', help, 0, help_cmd},
};
--
1.8.3.rc3.368.g7c798dd
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v13 15/15] test: add t7301 for git-clean--interactive
Add test cases for git-clean--interactive. Signed-off-by: Jiang Xin worldhello@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t7301-clean-interactive.sh | 439 +++ 1 file changed, 439 insertions(+) create mode 100755 t/t7301-clean-interactive.sh diff --git a/t/t7301-clean-interactive.sh b/t/t7301-clean-interactive.sh new file mode 100755 index 0..4e605 --- /dev/null +++ b/t/t7301-clean-interactive.sh @@ -0,0 +1,439 @@ +#!/bin/sh + +test_description='git clean -i basic tests' + +. ./test-lib.sh + +test_expect_success 'setup' ' + + mkdir -p src + touch src/part1.c Makefile + echo build .gitignore + echo \*.o .gitignore + git add . + git commit -m setup + touch src/part2.c README + git add . + +' + +test_expect_success 'git clean -i (clean)' ' + + mkdir -p build docs + touch a.out src/part3.c src/part3.h src/part4.c src/part4.h \ + docs/manual.txt obj.o build/lib.so + echo c | git clean -i + test -f Makefile + test -f README + test -f src/part1.c + test -f src/part2.c + test ! -f a.out + test -f docs/manual.txt + test ! -f src/part3.c + test ! -f src/part3.h + test ! -f src/part4.c + test ! -f src/part4.h + test -f obj.o + test -f build/lib.so + +' + +test_expect_success 'git clean -i (quit)' ' + + mkdir -p build docs + touch a.out src/part3.c src/part3.h src/part4.c src/part4.h \ + docs/manual.txt obj.o build/lib.so + echo q | git clean -i + test -f Makefile + test -f README + test -f src/part1.c + test -f src/part2.c + test -f a.out + test -f docs/manual.txt + test -f src/part3.c + test -f src/part3.h + test -f src/part4.c + test -f src/part4.h + test -f obj.o + test -f build/lib.so + +' + +test_expect_success 'git clean -i (Ctrl+D)' ' + + mkdir -p build docs + touch a.out src/part3.c src/part3.h src/part4.c src/part4.h \ + docs/manual.txt obj.o build/lib.so + echo \04 | git clean -i + test -f Makefile + test -f README + test -f src/part1.c + test -f src/part2.c + test -f a.out + test -f docs/manual.txt + test -f src/part3.c + test -f src/part3.h + test -f src/part4.c + test -f src/part4.h + test -f obj.o + test -f build/lib.so + +' + +test_expect_success 'git clean -id (filter all)' ' + + mkdir -p build docs + touch a.out src/part3.c src/part3.h src/part4.c src/part4.h \ + docs/manual.txt obj.o build/lib.so + (echo f; echo *; echo; echo c) | \ + git clean -id + test -f Makefile + test -f README + test -f src/part1.c + test -f src/part2.c + test -f a.out + test -f docs/manual.txt + test -f src/part3.c + test -f src/part3.h + test -f src/part4.c + test -f src/part4.h + test -f obj.o + test -f build/lib.so + +' + +test_expect_success 'git clean -id (filter patterns)' ' + + mkdir -p build docs + touch a.out src/part3.c src/part3.h src/part4.c src/part4.h \ + docs/manual.txt obj.o build/lib.so + (echo f; echo part3.* *.out; echo; echo c) | \ + git clean -id + test -f Makefile + test -f README + test -f src/part1.c + test -f src/part2.c + test -f a.out + test ! -f docs/manual.txt + test -f src/part3.c + test -f src/part3.h + test ! -f src/part4.c + test ! -f src/part4.h + test -f obj.o + test -f build/lib.so + +' + +test_expect_success 'git clean -id (filter patterns 2)' ' + + mkdir -p build docs + touch a.out src/part3.c src/part3.h src/part4.c src/part4.h \ + docs/manual.txt obj.o build/lib.so + (echo f; echo * !*.out; echo; echo c) | \ + git clean -id + test -f Makefile + test -f README + test -f src/part1.c + test -f src/part2.c + test ! -f a.out + test -f docs/manual.txt + test -f src/part3.c + test -f src/part3.h + test -f src/part4.c + test -f src/part4.h + test -f obj.o + test -f build/lib.so + +' + +test_expect_success 'git clean -id (select - all)' ' + + mkdir -p build docs + touch a.out src/part3.c src/part3.h src/part4.c src/part4.h \ + docs/manual.txt obj.o build/lib.so + (echo s; echo *; echo; echo c) | \ + git clean -id + test -f Makefile + test -f README + test -f src/part1.c + test -f src/part2.c + test ! -f a.out + test ! -f docs/manual.txt + test ! -f src/part3.c + test ! -f src/part3.h + test ! -f src/part4.c + test ! -f src/part4.h + test -f obj.o + test -f build/lib.so + +' +
[PATCH v13 05/15] Refactor write_name_quoted_relative, remove unused params
After substitute path_relative() in quote.c with relative_path() from
path.c, parameters (such as len and prefix_len) are obsolete in function
write_name_quoted_relative(). Remove unused parameters from
write_name_quoted_relative() and related functions.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/ls-files.c | 14 --
quote.c| 3 +--
quote.h| 3 +--
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index 00f07..6acff4 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -46,10 +46,12 @@ static const char *tag_modified = ;
static const char *tag_skip_worktree = ;
static const char *tag_resolve_undo = ;
-static void write_name(const char* name, size_t len)
+static void write_name(const char *name)
{
- write_name_quoted_relative(name, len, prefix, prefix_len, stdout,
- line_terminator);
+
+ /* turn off prefix, if run with --full-name */
+ write_name_quoted_relative(name, prefix_len ? prefix : NULL,
+ stdout, line_terminator);
}
static void show_dir_entry(const char *tag, struct dir_entry *ent)
@@ -63,7 +65,7 @@ static void show_dir_entry(const char *tag, struct dir_entry
*ent)
return;
fputs(tag, stdout);
- write_name(ent-name, ent-len);
+ write_name(ent-name);
}
static void show_other_files(struct dir_struct *dir)
@@ -163,7 +165,7 @@ static void show_ce_entry(const char *tag, struct
cache_entry *ce)
find_unique_abbrev(ce-sha1,abbrev),
ce_stage(ce));
}
- write_name(ce-name, ce_namelen(ce));
+ write_name(ce-name);
if (debug_mode) {
printf( ctime: %d:%d\n, ce-ce_ctime.sec, ce-ce_ctime.nsec);
printf( mtime: %d:%d\n, ce-ce_mtime.sec, ce-ce_mtime.nsec);
@@ -196,7 +198,7 @@ static void show_ru_info(void)
printf(%s%06o %s %d\t, tag_resolve_undo, ui-mode[i],
find_unique_abbrev(ui-sha1[i], abbrev),
i + 1);
- write_name(path, len);
+ write_name(path);
}
}
}
diff --git a/quote.c b/quote.c
index ebb8..5c880 100644
--- a/quote.c
+++ b/quote.c
@@ -312,8 +312,7 @@ void write_name_quotedpfx(const char *pfx, size_t pfxlen,
fputc(terminator, fp);
}
-void write_name_quoted_relative(const char *name, size_t len,
- const char *prefix, size_t prefix_len,
+void write_name_quoted_relative(const char *name, const char *prefix,
FILE *fp, int terminator)
{
struct strbuf sb = STRBUF_INIT;
diff --git a/quote.h b/quote.h
index 5610159..ed110 100644
--- a/quote.h
+++ b/quote.h
@@ -60,8 +60,7 @@ extern void quote_two_c_style(struct strbuf *, const char *,
const char *, int);
extern void write_name_quoted(const char *name, FILE *, int terminator);
extern void write_name_quotedpfx(const char *pfx, size_t pfxlen,
const char *name, FILE *, int terminator);
-extern void write_name_quoted_relative(const char *name, size_t len,
- const char *prefix, size_t prefix_len,
+extern void write_name_quoted_relative(const char *name, const char *prefix,
FILE *fp, int terminator);
/* quote path as relative to the given prefix */
--
1.8.3.rc3.368.g7c798dd
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] guilt: skip empty line after from: line in patch descriptoin
Commit 2cc8d353d7ecb broke manually written patch descriptions of the
form:
Frobnozzle: this is a patch subject
From: Fred McNurk f...@mcnurt.foo
This is the patch description
Commit 8f88f953580a0 partially fixed things by filtering out the From:
field, but it did not filter out the empty line (if present) after the
From: field, so it resulted in commit bodies which looked like this:
Frobnozzle: this is a patch subject
This is the patch description
instead of
Frobnozzle: this is a patch subject
This is the patch description
The ext4 patch queue has used this format for years, and this change
should not break other patches which look like mail headers and
bodies.
Signed-off-by: Theodore Ts'o ty...@mit.edu
---
guilt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/guilt b/guilt
index 4edd1ad..309437a 100755
--- a/guilt
+++ b/guilt
@@ -365,7 +365,7 @@ do_get_header()
BEGIN{body=0; subj=0}
/^Subject:/ (body == 0 subj == 0){subj=1; print substr($0, 10) \n;
next}
/^(Subject:|Author:|Date:|commit)/ (body == 0){next}
-/^From:/ {next}
+/^From:/ {body=0; next}
/^(Commit-ID:|Gitweb:|AuthorDate:|Committer:CommitDate:)/ (body == 0){next}
/^[ \t\f\n\r\v]*$/ (body==0){next}
/^.*$/ (body==0){body=1}
--
1.7.12.rc0.22.gcdd159b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] guilt: force the use of bare branches
To make it harder to accidentally do git push with a guilt patch applied, guilt push changes branch from e.g. master to guilt/master starting with commit 67d3af63f422. This is a feature which I use for ext4 development; I actually *do* want to be able to push patches to the dev branch, which is a rewindable branch much like git's pu branch. Allow the use of the environment variable GUILT_FORCE_BARE_BRANCH which disables the new behavior introduced by commit 67d3af63f422. Signed-off-by: Theodore Ts'o ty...@mit.edu Cc: Per Cederqvist ced...@opera.com --- guilt | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/guilt b/guilt index 309437a..9953bdf 100755 --- a/guilt +++ b/guilt @@ -914,13 +914,22 @@ else die Unsupported operating system: $UNAME_S fi -if [ $branch = $raw_git_branch ] [ -n `get_top 2/dev/null` ] -then -# This is for compat with old repositories that still have a -# pushed patch without the new-style branch prefix. +if [ -n `get_top 2/dev/null` ]; then + # + # If we have repositories patches pushed, then use whatever scheme + # is currently in use + # + if [ $branch = $raw_git_branch ]; then old_style_prefix=true + else +old_style_prefix=false + fi else + if [ -n $GUILT_FORCE_BARE_BRANCH ]; then +old_style_prefix=true + else old_style_prefix=false + fi fi _main $@ -- 1.7.12.rc0.22.gcdd159b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
On Tue, May 21, 2013 at 7:50 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: I still haven't received a response: which makes more sense? a) % git checkout svn-ext % git fetch From . * branchmaster - FETCH_HEAD # oops % git fetch git-svn % git log ..FETCH_HEAD % git merge FETCH_HEAD b) % git checkout svn-ext % git fetch From git://git.kernel.org/pub/scm/git/git 680ed3e..de3a5c6 master - origin/master # oops % git fetch svn-ext % git log ..FETCH_HEAD % git merge FETCH_HEAD I think with the scenario you are following, a) would prepare the FETCH_HEAD with her local git-svn branch which is her svn-ext topic is based on, but you illustrated it to fetch 'master', which I think is a minor typo. Modulo that typo, the step before the #oops makes perfect sense. It fetched where she told Git her work on svn-ext is based on. But the step after that does not make much sense in that flow. You don't get to decide what Sally (I'm naming her) does, all you get to decide is what Git does. Sally wants to fetch from the true upstream: svn-ext, but in the process does by mistake a 'git fetch' *without arguments* (WHICH IS WHAT THIS WHOLE DISCUSSION IS ABOUT). So now is the time you answer: a) or b). Heh, that was my example. In any case, my pick is still a). She *TOLD* Git that her local git-svn branch is what forms the base of her local svn-ext work. She told Git that her local svn-branch was the basis for svn-next. She DIT NOT TELL Git to fetch from there. She told Git to fetch from any location Git thought best to fetch from, either a) or b) would fetch from the wrong location, but a) would be wronger, you just don't want to admit it. You are, once again, *assuming* that if a user sets up an upstream, he wants to fetch from there. All you answers are based on assumptions. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] transport-helper: check if the dry-run is supported
On Tue, May 21, 2013 at 7:47 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Tue, May 21, 2013 at 11:55 AM, Junio C Hamano gits...@pobox.com wrote: This sounds like a good thing to do. Perhaps the refspec mapping can be handled the same way as a backend feature so that you do not have to unconditionally disable it in the other patch. With my patch the remote helper doesn't need to know about the refspec handling at all, it just works magically. The consumers of git fast-export do not need to know how to flip refspecs when consuming output from git fast-export, because you taught git fast-export to do the mapping. But doesn't that coin have a flip side? When somebody else (not git) generates a fast-import stream, because these consumers are not prepared to flip refspecs, they cannot rename while importing. All the producers have to be taught to do the ref mapping. Not true. There can be an intermediary in between. I do not know if this matters in real life, and even if it did, in the eventual ideal world, both importers and exporters would learn to do so. No. Only one side *needs* to learn that. So I do not think what you did in your patch is a bad design in that sense. It is a half step in the right direction. What is the other step, and how would that benefit anyone? I however found it somewhat ugly that the interface to specify set of refs to traverse history to find the set of objects to export stays the same as before, and the ref-mapping arguments are bolted on to the machinery, without having any relationship between them. The user is free to tell it to export only 'next', while telling it to map 'master' to 'trunk', for example. This is an external interface that is exposed to any users of git fast-export, so if we go that route, we would have to keep that interface working forever, even when later somebody else wants to add an interface that only requires ref-mapping arguments (and infer what is exported from the left hand side of the refspecs). Not true. We don't *have* to keep anything forever, we are free to decide anything we want, and live with the consequences. If a better approach is found, we can remove this interface in v2.0, or v3.0, or even v10.0. Why are we shooting ourselves in the foot in the meantime? We already have something that works perfectly fine. Now, I specifically asked if such an interface would make sense, because there are too many warts, and I did not receive a satisfactory answer in my opinion. I will explore this interface once more, but I never received any positive feedback from yours that we indeed want to teach 'fast-export' to parse refspecs, it's just that the interface to do so was not ideal; you explicitly said you thought it made more sense on the other side; the receiver. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prompt: fix show upstream with svn and zsh
On Tue, May 21, 2013 at 3:54 PM, Thomas Gummerer t.gumme...@gmail.com wrote: Currently the __git_ps1 git prompt gives the following error with a repository converted by git-svn, when used with zsh: __git_ps1_show_upstream:19: bad pattern: svn_remote[ This was introduced by 6d158cba (bash completion: Support divergence from upstream messages in __git_ps1), when the script was for bash only. Make it compatible with zsh. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com This patch is fine by me. I would like to see an example of how to trigger the issue with a standalone command in the commit message, but it's not necessary. It would also make sense to address the comment from Szeder that does raise questions about other places in the code where 'array[ $foo ]' is used, maybe there's a caveat we are not considering, or maybe your use-case did not execute that code. And finally, I don't recall seen 'set -a' used elsewhere in the code. If memory serves well, we have replaced 'local -a foo=value' with 'local -a foo\nfoo=value' before to fix zsh issues, I think that would be safer. But this patch is needed regardless, that, or the patch that broke things should be reverted for v1.8.3. Thomas, if you don't have time, let me know and I can take a look. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] guilt: fix date parsing
If the date field has a space in it, such as:
Date: Tue, 14 May 2013 18:37:15 +0200
previously guilt would go belly up:
+ export GIT_AUTHOR_DATE=Tue, 14 May 2013 18:37:15 +0200
/usr/local/bin/guilt: 571: export: 14: bad variable name
Fix this.
Signed-off-by: Theodore Ts'o ty...@mit.edu
---
guilt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/guilt b/guilt
index 9953bdf..6e8d542 100755
--- a/guilt
+++ b/guilt
@@ -568,7 +568,7 @@ commit()
author_date_str=`sed -n -e '/^Date:/ { s/^Date:
//; p; q; }; /^(diff |---$|--- )/ q' $p`
fi
if [ ! -z $author_date_str ]; then
- export GIT_AUTHOR_DATE=`echo $author_date_str`
+ export GIT_AUTHOR_DATE=$author_date_str
fi
fi
--
1.7.12.rc0.22.gcdd159b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] guilt: force the use of bare branches
On Tue, May 21, 2013 at 10:55:57PM -0400, Theodore Ts'o wrote: To make it harder to accidentally do git push with a guilt patch applied, guilt push changes branch from e.g. master to guilt/master starting with commit 67d3af63f422. This is a feature which I use for ext4 development; I actually *do* want to be able to push patches to the dev branch, which is a rewindable branch much like git's pu branch. Allow the use of the environment variable GUILT_FORCE_BARE_BRANCH which disables the new behavior introduced by commit 67d3af63f422. Would it make sense to make it git-config-able instead? As an added bonus, one can then make the decision on per-repository basis. Jeff. Signed-off-by: Theodore Ts'o ty...@mit.edu Cc: Per Cederqvist ced...@opera.com --- guilt | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/guilt b/guilt index 309437a..9953bdf 100755 --- a/guilt +++ b/guilt @@ -914,13 +914,22 @@ else die Unsupported operating system: $UNAME_S fi -if [ $branch = $raw_git_branch ] [ -n `get_top 2/dev/null` ] -then -# This is for compat with old repositories that still have a -# pushed patch without the new-style branch prefix. +if [ -n `get_top 2/dev/null` ]; then + # + # If we have repositories patches pushed, then use whatever scheme + # is currently in use + # + if [ $branch = $raw_git_branch ]; then old_style_prefix=true + else +old_style_prefix=false + fi else + if [ -n $GUILT_FORCE_BARE_BRANCH ]; then +old_style_prefix=true + else old_style_prefix=false + fi fi _main $@ -- 1.7.12.rc0.22.gcdd159b -- Linux, n.: Generous programmers from around the world all join forces to help you shoot yourself in the foot for free. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] guilt: fix date parsing
I applied this one and the guilt: skip empty line after... patch.
Jeff.
On Tue, May 21, 2013 at 11:13:31PM -0400, Theodore Ts'o wrote:
If the date field has a space in it, such as:
Date: Tue, 14 May 2013 18:37:15 +0200
previously guilt would go belly up:
+ export GIT_AUTHOR_DATE=Tue, 14 May 2013 18:37:15 +0200
/usr/local/bin/guilt: 571: export: 14: bad variable name
Fix this.
Signed-off-by: Theodore Ts'o ty...@mit.edu
---
guilt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/guilt b/guilt
index 9953bdf..6e8d542 100755
--- a/guilt
+++ b/guilt
@@ -568,7 +568,7 @@ commit()
author_date_str=`sed -n -e '/^Date:/ { s/^Date:
//; p; q; }; /^(diff |---$|--- )/ q' $p`
fi
if [ ! -z $author_date_str ]; then
- export GIT_AUTHOR_DATE=`echo $author_date_str`
+ export GIT_AUTHOR_DATE=$author_date_str
fi
fi
--
1.7.12.rc0.22.gcdd159b
--
The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers.
- Bill Gates, The Road Ahead, pg. 265
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
java zlib woes (was: Reading commit objects)
On Tue, 21 May 2013 19:18:35 +, Chico Sokol wrote: Ok, we discovered that the commit object actually contains the tree object's sha1, by reading its contents with python zlib library. So the bug must be with our java code (we're building a java lib). That's interesting. We ran in a similar problem: We had a fetch with jget hanging within the zlib deflater code in what looked like a busy loop. Unfortunately we don't yet have a publishable repo on which this happens. Andreas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reading commit objects
On Tue, May 21, 2013 at 3:33 PM, Chico Sokol chico.so...@gmail.com wrote: It was git who created that object. We're trying to build a improved java library focused in our needs (jgit has a really confusing api focused in solving egit needs). JGit code... is confusing because its fast. We spent a lot of time trying to make things fast on the JVM, and somewhat comparable with C Git even though its not in C. Some of the low-level APIs are fast because they bypass conventional Java wisdom and just tell the #@!* machine what to do, with no pretty bits about it. Make it pretty, it goes slower. Or uses more RAM. Java likes RAM. Good luck making an improved library. JGit of course is also interested in contributions. The api package has been trying to make a simpler calling convention for common use cases that match the command line interface user are familiar with, but its still incomplete and hides some optimizations that are possible with the lower-level calls. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: java zlib woes (was: Reading commit objects)
On Tue, May 21, 2013 at 9:51 PM, Andreas Krey a.k...@gmx.de wrote: On Tue, 21 May 2013 19:18:35 +, Chico Sokol wrote: Ok, we discovered that the commit object actually contains the tree object's sha1, by reading its contents with python zlib library. So the bug must be with our java code (we're building a java lib). That's interesting. We ran in a similar problem: We had a fetch with jget hanging within the zlib deflater code in what looked like a busy loop. Unfortunately we don't yet have a publishable repo on which this happens. This was with JGit? A stack trace and JGit version (so we can correlate line numbers) would be a much more useful bug report than nothing at all. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
