Re: Officially start moving to the term 'staging area'
On Thu, Aug 29, 2013 at 11:01 AM, Felipe Contreras felipe.contre...@gmail.com wrote: It has been discussed many times in the past that 'index' is not an appropriate description for what the high-level user does with it, and it has been agreed that 'staging area' is the best term. I realize Git is not a democracy, but if the vote of a humble user counts for anything, I agree that index is a terrible name. I was very excited when Felipe first started this thread, since I thought Git might finally fix one of it's biggest long-standing usability problems. Calling this thing the index is like calling an important variable someValue. While the name may be technically correct, it's way too generic to be useful. A name like staging area may not capture the whole idea, but at least it provides a good clue about what it does and how you might use it. If we change this, I'm pretty sure most of the Internet will rejoice. Only a few old-timers will be grumpy, but that's just because they don't like change in general. I have never met anybody (outside this thread) who thought the current name was a good idea. -William -- 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
[Bug?] MERGE_HEAD lost with git checkout master
Hi,
At $dayjob we have some simple code quality checks that we run to
make sure that things are heading in the right direction. These are
usually run as part of our automated builds but people occasionally
run them when merging updates from other teams or preparing to merge
to the integration branch.
The typical invocation is something like
git checkout HEAD^
score1=$(script.sh)
git checkout master
score2=$(script.sh)
# compare scores ...
The problem is that if this is run after resolving merge conflicts but
before committing the changes (i.e. the merge resolution is in the
index) the fact that a merge was in progress is lost. I have modified
script.sh to check for a clean work tree but I'm wondering if this is
actually a bug worth fixing.
Here's a simple reproduction (apologies in advance for gmails wrapping)
$ git --version
git version 1.8.4.rc2
$ git init
$ for x in a b c d e f; do echo $x ${x}.txt; git add
${x}.txt; git commit -mAdd ${x}.txt; done
$ git checkout -b foo HEAD^^^
$ for x in d e f; do echo x ${x}.txt; git add ${x}.txt; git
commit -mAdd ${x}.txt; done
$ git checkout master
$ git merge foo
$ git mergetool
# At this point the conflict resolution is in the index as expected
$ git checkout HEAD^
error: Your local changes to the following files would be
overwritten by checkout:
f.txt
Please, commit your changes or stash them before you can switch branches.
Aborting
# OK so far so good. Checkout failed and we're still in a mergey state
$ ll .git
drwxr-xr-x 2 chrisp swdept 4096 Sep 4 17:47 info/
drwxr-xr-x 3 chrisp swdept 4096 Sep 4 17:49 logs/
-rw-r--r-- 1 chrisp swdept 41 Sep 4 17:51 MERGE_HEAD
-rw-r--r-- 1 chrisp swdept0 Sep 4 17:51 MERGE_MODE
-rw-r--r-- 1 chrisp swdept 52 Sep 4 17:51 MERGE_MSG
-rw-r--r-- 1 chrisp swdept 141 Sep 4 17:51 MERGE_RR
drwxr-xr-x 40 chrisp swdept 4096 Sep 4 17:52 objects/
-rw-r--r-- 1 chrisp swdept 41 Sep 4 17:51 ORIG_HEAD
$ git checkout master
M d.txt
M e.txt
M f.txt
Already on 'master'
# Hmm, that kind of indicates that it did something but Already on
'master' makes me think it was a noop
$ ll .git
drwxr-xr-x 2 chrisp swdept 4096 Sep 4 17:47 info/
drwxr-xr-x 3 chrisp swdept 4096 Sep 4 17:49 logs/
drwxr-xr-x 40 chrisp swdept 4096 Sep 4 17:52 objects/
-rw-r--r-- 1 chrisp swdept 41 Sep 4 17:51 ORIG_HEAD
# mergey state is lost but the changes are still in the index.
Cheers,
Chris
--
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
German translation errors
Hi, when I fetch from remote repositories, git tells me about new branches and tags by saying [neuer Branch] or [neuer Tag]. While Branch translates to Zweig in german, the german word Tag actually means day, so git is telling me something about a new day for every new tag. Should be neue Marke. Thanks... Dirk -- Dirk Heinrichs dirk.heinri...@altum.de Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinri...@altum.de signature.asc Description: This is a digitally signed message part.
Re: [PATCH v3 2/2] submodule: don't print status output with ignore=all
brian m. carlson sand...@crustytoothpaste.net writes: Tests are included which verify that this change has no effect on git submodule summary without the --for-status option. I still don't understand why this is needed. Why do we want git status and git submodule summary to display different information? Wasn't it a nice property that the part of git status about submodule is the same as git submodule summary? This should at least be explained in the commit message IMHO. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 v3] Teach git to change to a given directory using -C option
On Wed, Sep 4, 2013 at 6:46 AM, Junio C Hamano gits...@pobox.com wrote:
I do not care too deeply either way, but I am curious if there was a
reason why you changed the earlier directory to path? Somehow,
when we _know_ a path has to be a directory, I find it easier on the
readers to spell that out, instead of saying this is a path,
implying that it could be a directory, a regular file, or even
non-existent.
Eric made me do it :). Personally I prefer the non-ambiguous directory
over path. In fact, directory is used in the error message spat out
by git:
$ git --work-tree
No directory given for --work-tree.
...
$ git --git-dir
No directory given for --git-dir.
...
$
I think changing path to directory wherever appropriate in
git.txt would be an improvement. Tangent: dir is shorter but that
might not be easy on the translators.
+-C path::
+ Run as if git was started in path instead of the current working
+ directory. When multiple -C options are given, each subsequent
+ non-absolute -C path is interpreted relative to the preceding -C
+ path.
+
+ This option affects options that expect path name like --git-dir and
+ --work-tree in that their interpretations of the path names would be
+ made relative to the working directory caused by the -C option. For
+ example the following invocations are equivalent:
+
+ git --git-dir=a.git --work-tree=b -C c status
+ git --git-dir=c/a.git --work-tree=c/b status
+
Does the above format correctly without the usual second and
subsequent paragraphs are not indented, but has '+' in place of
a blank line?
No it doesn't. I'll fix it in the next reroll.
- if (!prefixcmp(cmd, --exec-path)) {
+ if (!strcmp(cmd, -C)) {
+ if (*argc 2) {
+ fprintf(stderr, No directory given for -C.\n
);
+ usage(git_usage_string);
+ }
+ if (chdir((*argv)[1]))
+ die_errno(Cannot change to '%s', (*argv)[1]);
+ if (envchanged)
+ *envchanged = 1;
+ (*argv)++;
+ (*argc)--;
+ } else if (!prefixcmp(cmd, --exec-path)) {
We usually do not prepend to an existing if/else if/ chain unless
there is a very good reason (e.g. the new if condition is very
often triggered and we are better off checking it early) exactly
because doing so would make a patch that is ugly like the above.
You are not touching the codepath that deal with --exec-path, but
the resulting patch makes it appear as if you are doing something to
it.
I agree with you here. I'll send the reroll later.
nazri
--
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 v3] Teach git to change to a given directory using -C option
On Wed, Sep 4, 2013 at 2:36 AM, Nazri Ramliy ayieh...@gmail.com wrote: On Wed, Sep 4, 2013 at 6:46 AM, Junio C Hamano gits...@pobox.com wrote: I do not care too deeply either way, but I am curious if there was a reason why you changed the earlier directory to path? Somehow, when we _know_ a path has to be a directory, I find it easier on the readers to spell that out, instead of saying this is a path, implying that it could be a directory, a regular file, or even non-existent. Eric made me do it :). Personally I prefer the non-ambiguous directory over path. In fact, directory is used in the error message spat out by git: $ git --work-tree No directory given for --work-tree. ... $ git --git-dir No directory given for --git-dir. ... $ I think changing path to directory wherever appropriate in git.txt would be an improvement. Tangent: dir is shorter but that might not be easy on the translators. Such a terminology change is orthogonal to the patch adding -C support, so if you do pursue it, the terminology change should be a separate patch (either preparatory or follow-up to the -C 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: Officially start moving to the term 'staging area'
Just wanted to point to a Dr. Dobb's article from Monday: http://www.drdobbs.com/tools/getting-started-with-git-the-fundamental/240160261?pgno=2 The author does not use the use the word index at all. Instead he writes in following way: --- Staging Changes One of Git's best features is that it offers a staging process. You can stage the modified files that you want to commit. Other version control systems await your one command before your files are changed in the repository — generally the remote repository for the entire team. When you commit files in Git, files are held in a staging area. You will later commit all the files from the staging area to the larger repository. So, let's say you wanted to make a change involving files A and B. You changed file A. You then remembered something unrelated to do with file Z and you modified that. Then you went back to your initial change, modifying file B. Git allows you to add files A and B to staging, while leaving file Z unstaged. Then you can push only the staged files to your repository. But you don't! You realize you need to make a change to file C as well. You add it. Now files A,B, and C are staged, and Z is still unstaged. You commit the staged changes only. [...] --- Sorry for not responding to your comments Drew, no time at the moment. -- Piotr Krukowiecki -- 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] add--interactive: fix external command invocation on Windows
From: Johannes Sixt j...@kdbg.org
Back in 21e9757e (Hack git-add--interactive to make it work with
ActiveState Perl, 2007-08-01), the invocation of external commands was
changed to use qx{} on Windows. The rationale was that the command
interpreter on Windows is not a POSIX shell, but rather Windows's CMD.
That patch was wrong to include 'msys' in the check whether to use qx{}
or not: 'msys' identifies MSYS perl as shipped with Git for Windows,
which does not need the special treatment; qx{} should be used only with
ActiveState perl, which is identified by 'MSWin32'.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
Am 9/2/2013 13:56, schrieb Duy Nguyen:
On Mon, Sep 2, 2013 at 5:41 PM, Johannes Sixt j.s...@viscovery.net wrote:
Which features do we lose on Windows with the previous patch and this fixup?
New pathspec magic :(glob), :(literal) and :(icase). You can still use
them via --*-pathspecs or equivalent env variables. You just can't
enable them per individual pathspec.
I think this here is the correct solution rather than the special cases
for Windows that you proposed. ActiveState perl users would still suffer,
but that is a problem of the run_cmd_pipe implementation, which would
need a smarter method to quote the arguments before it feeds them to qx{}.
git-add--interactive.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 75a991f..5156384 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -169,7 +169,7 @@ my %patch_modes = (
my %patch_mode_flavour = %{$patch_modes{stage}};
sub run_cmd_pipe {
- if ($^O eq 'MSWin32' || $^O eq 'msys') {
+ if ($^O eq 'MSWin32') {
my @invalid = grep {m/[:*]/} @_;
die $^O does not support: @invalid\n if @invalid;
my @args = map { m/ /o ? \$_\: $_ } @_;
--
1.8.4.1549.gc059550.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
Transfer notes when rebasing
Hello, When rebasing a branch which contains commits with notes onto another branch it happens that some commits are already presents in the target branch. In that case git-rebase correctly drops those (already present) commits but it also drops the notes associated with them. Can the notes be transfered somehow in the target branch on the already present commits ? Thanks -- Francis -- 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: Transfer notes when rebasing
On Wed, Sep 04, 2013 at 03:53:10AM -0400, Jeff King wrote: On Wed, Sep 04, 2013 at 09:51:26AM +0200, Francis Moreau wrote: When rebasing a branch which contains commits with notes onto another branch it happens that some commits are already presents in the target branch. In that case git-rebase correctly drops those (already present) commits but it also drops the notes associated with them. Can the notes be transfered somehow in the target branch on the already present commits ? Yes, see the notes.rewriteRef config option to enable this. Does that actually work for this case? It sounds like Francis has the notes copying correctly when commits are rewritten but the notes are not copied anywhere if the commit becomes empty. I suspect it is difficult to do that in general as there is no clear way to know which commit those notes should be copied to. -- 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] git send-email: include [anything]-by: signatures
On Tue, Sep 03, 2013 at 02:39:05PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: On Wed, Sep 04, 2013 at 12:01:49AM +0300, Michael S. Tsirkin wrote: The question of course is the first point Peff raised. I am not sure offhand what the right per-project customization interface would be. A starting point might be something like: --cc-trailer=signed-off-by,acked-by,reviewed-by tested-by, reported-by ... Yeah, I think having the list customizable is nice, but not allowing some pattern matching seems unfriendly, as it requires the user to enumerate a potentially long list. --cc-trailer='*-by' and an obvious configuration variable that gives the default for it. That would eventually allow us not to special case any fixed set of trailers like S-o-b like the current code does, which would be a big plus. What bothers me is that git normally uses gawk based patterns, but send-email is in perl so it has a different syntax for regexp. What do you suggest? Make a small binary to do the matching for us? Would fnmatch-style globbing (like *-by) be enough? That should be easy to do in perl. Web query finds File::FnMatch; I do not know if that is the most commonly used, or if it comes with the base distribution, though. It's also just a wrapper for the system's fnmatch - so I expect it doesn't work in the mingw environment. -- MST -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in git rebase --continue in v1.8.4
Christoph Mallon said: if I run rebase --continue (e.g. after a conflict resolution), then the rebase always ends with this error message: It seems that there is already a rebase-apply directory, and I wonder if you are in the middle of another rebase. If that is the case, please try git rebase (--continue | --abort | --skip) If that is not the case, please rm -fr /home/tron/gitRebaseTest/test/.git/rebase-apply and run me again. I am stopping in case you still have something valuable there. This happens on git v1.8.4 on FreeBSD. It is fine with v1.8.3.4. I observe exactly the same problem. I also use FreeBSD and the problem started with 1.8.4. Judging by the lack of followups, could this be a FreeBSD-specific problem? Any thoughts / suggestions? Thank you! It seems to be caused by a1549e1049439386b9fd643fae236ad3ba649650, specifically this hunk: --- a/git-rebase--am.sh +++ b/git-rebase--am.sh at at -7,12 +7,12 at at case $action in continue) git am --resolved --resolvemsg=$resolvemsg move_to_original_branch - exit + return ;; skip) git am --skip --resolvemsg=$resolvemsg -- Andriy Gapon -- 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] Reject non-ff pulls by default
On Tue, Sep 03, 2013 at 03:38:58PM -0700, Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio already sent a similar patch, but I think this is simpler. I agree that this is simpler, but I am not sure if the behaviour is necessarily better (note that this is different from saying I think the behaviour of this patch is worse). The motivation I read from the original discussion was that new people did git pull (no other parameters) to sync my tree with the central repository as if it were SVN, and because we are not SVN, projects that prefer rebases were unhappy, and the other one was to address *only* that use case. I do not personally like that special casing (i.e. only when no 'integrate with what from where' is given), and applying the you must be explicit between rebase and merge like this series does uniformly might (or might not) be a good thing. I dunno. As I already said; there's is essentially no difference between git pull and git pull origin. We know what you said earlier. That does not make it right or wrong, but I do not think it is in line with the original discussion (that is why John Keeping is kept on the Cc: line). I think there are two distinct uses for pull, which boil down to: (1) git pull (2) git pull $remote $branch For (1) a merge is almost always the wrong thing to do since it will be backwards and break --first-parent. But for (2) a merge is almost always the correct thing to do (in fact it may even be correct to create a merge commit even when this fast forwards) because this most likely comes for a pull request workflow. I do not think we know what we want is to affect git pull origin. I consider git pull $remote to be an artifact of the way git-pull is implemented on top of git-fetch; perhaps I'm missing something but I can't see a scenario where this is useful. In the series currently in next, we treat this as (2) above but that's primarily because it is difficult to differentiate these in git-pull.sh without adding code to understand all of the options to git-fetch (or at least those that can accept unstuck arguments). Changing this so that git pull $remote is treated as (1) would be better, but I think it is more important to avoid catching case (1) in the same net which is why jc/pull-training-wheel simply checks if $# is zero; the cost of getting this completely right outweighed the benefit of getting code in that will catch 99% of users. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in git rebase --continue in v1.8.4
[ Cc-ing Ram, as he is the author of the possibly guilty commit. ] Andriy Gapon a...@freebsd.org writes: Christoph Mallon said: if I run rebase --continue (e.g. after a conflict resolution), then the rebase always ends with this error message: It seems that there is already a rebase-apply directory, and I wonder if you are in the middle of another rebase. If that is the case, please try git rebase (--continue | --abort | --skip) If that is not the case, please rm -fr /home/tron/gitRebaseTest/test/.git/rebase-apply and run me again. I am stopping in case you still have something valuable there. This happens on git v1.8.4 on FreeBSD. It is fine with v1.8.3.4. I observe exactly the same problem. I also use FreeBSD and the problem started with 1.8.4. Judging by the lack of followups, could this be a FreeBSD-specific problem? I can't reproduce here (Debian GNU/Linux). Do the testsuite pass for you? If not, can you write a failing test? A minimalist script outside the testsuite may help too if you're not familiar with Git's testsuite. Any thoughts / suggestions? Thank you! It seems to be caused by a1549e1049439386b9fd643fae236ad3ba649650, specifically this hunk: --- a/git-rebase--am.sh +++ b/git-rebase--am.sh at at -7,12 +7,12 at at case $action in continue) git am --resolved --resolvemsg=$resolvemsg move_to_original_branch - exit + return ;; skip) git am --skip --resolvemsg=$resolvemsg -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: Transfer notes when rebasing
On Wed, Sep 04, 2013 at 08:59:41AM +0100, John Keeping wrote:
On Wed, Sep 04, 2013 at 03:53:10AM -0400, Jeff King wrote:
On Wed, Sep 04, 2013 at 09:51:26AM +0200, Francis Moreau wrote:
When rebasing a branch which contains commits with notes onto another
branch it happens that some commits are already presents in the target
branch.
In that case git-rebase correctly drops those (already present)
commits but it also drops the notes associated with them.
Can the notes be transfered somehow in the target branch on the
already present commits ?
Yes, see the notes.rewriteRef config option to enable this.
Does that actually work for this case? It sounds like Francis has the
notes copying correctly when commits are rewritten but the notes are not
copied anywhere if the commit becomes empty.
Ah, I misunderstood. If we are dropping commits from the rebase because
their counterpart is already applied upstream, then no, there isn't an
automatic way to do this.
If the commits are dropped because a commit with the same patch-id
already exists upstream, you could match them up by patch-id and copy
the notes. Annoyingly, while we have things like log --cherry-mark to
show which commits are already present on each side, I do not think
there is a way to correlate them commit for commit. So I think you are
stuck doing something in the shell like:
patch_ids() {
git rev-list $1 |
git diff-tree --stdin -p |
git patch-id |
sort
}
patch_ids $upstream..HEAD us
patch_ids HEAD..$upstream them
join us them |
cut -d' ' -f2-3 |
git notes copy --stdin
However, if the commit is dropped because we find while applying that it
becomes empty, there is not much we can do. It may have been obsoleted
by its counterpart patch that had a different patch-id, or it may even
have been obsoleted by unrelated patches. In the latter case, there is
nothing to copy to. In the former, you would have to trying to match up
the commit messages or similar to guess that the two commits correspond.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Transfer notes when rebasing
On Wed, Sep 4, 2013 at 10:28 AM, Jeff King p...@peff.net wrote:
On Wed, Sep 04, 2013 at 08:59:41AM +0100, John Keeping wrote:
On Wed, Sep 04, 2013 at 03:53:10AM -0400, Jeff King wrote:
On Wed, Sep 04, 2013 at 09:51:26AM +0200, Francis Moreau wrote:
When rebasing a branch which contains commits with notes onto another
branch it happens that some commits are already presents in the target
branch.
In that case git-rebase correctly drops those (already present)
commits but it also drops the notes associated with them.
Can the notes be transfered somehow in the target branch on the
already present commits ?
Yes, see the notes.rewriteRef config option to enable this.
Does that actually work for this case? It sounds like Francis has the
notes copying correctly when commits are rewritten but the notes are not
copied anywhere if the commit becomes empty.
Ah, I misunderstood. If we are dropping commits from the rebase because
their counterpart is already applied upstream, then no, there isn't an
automatic way to do this.
If the commits are dropped because a commit with the same patch-id
already exists upstream, you could match them up by patch-id and copy
the notes. Annoyingly, while we have things like log --cherry-mark to
show which commits are already present on each side, I do not think
there is a way to correlate them commit for commit. So I think you are
stuck doing something in the shell like:
patch_ids() {
git rev-list $1 |
git diff-tree --stdin -p |
git patch-id |
sort
}
patch_ids $upstream..HEAD us
patch_ids HEAD..$upstream them
join us them |
cut -d' ' -f2-3 |
git notes copy --stdin
However, if the commit is dropped because we find while applying that it
becomes empty, there is not much we can do. It may have been obsoleted
by its counterpart patch that had a different patch-id, or it may even
have been obsoleted by unrelated patches. In the latter case, there is
nothing to copy to. In the former, you would have to trying to match up
the commit messages or similar to guess that the two commits correspond.
Can't git-rebase at least handle the case where a patch and its
counterpart have the same patch-id ?
Also maybe git-rebase should warn when dropping a commit having a note
to tell the user that the note is dropped too.
--
Francis
--
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: Transfer notes when rebasing
On Wed, Sep 04, 2013 at 10:47:22AM +0200, Francis Moreau wrote: However, if the commit is dropped because we find while applying that it becomes empty, there is not much we can do. It may have been obsoleted by its counterpart patch that had a different patch-id, or it may even have been obsoleted by unrelated patches. In the latter case, there is nothing to copy to. In the former, you would have to trying to match up the commit messages or similar to guess that the two commits correspond. Can't git-rebase at least handle the case where a patch and its counterpart have the same patch-id ? Certainly it could. My point was only that it doesn't currently (and it does not even know what the counterpart is, only that there is one). Also maybe git-rebase should warn when dropping a commit having a note to tell the user that the note is dropped too. That might end up annoying, depending on what you use notes for. But I think if it were restricted to notes that would be rewritten via notes.rewriteRef, it probably makes sense. Patches welcome. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in git rebase --continue in v1.8.4
on 04/09/2013 11:18 Matthieu Moy said the following: [ Cc-ing Ram, as he is the author of the possibly guilty commit. ] Andriy Gapon a...@freebsd.org writes: Judging by the lack of followups, could this be a FreeBSD-specific problem? I can't reproduce here (Debian GNU/Linux). Do the testsuite pass for you? If not, can you write a failing test? A minimalist script outside the testsuite may help too if you're not familiar with Git's testsuite. Thank you for the suggestion. I've just tried it and it failed here: *** t3403-rebase-skip.sh *** ok 1 - setup ok 2 - rebase with git am -3 (default) ok 3 - rebase --skip can not be used with other options not ok 4 - rebase --skip with am -3 # # git rebase --skip # not ok 5 - rebase moves back to skip-reference # # test refs/heads/skip-reference = $(git symbolic-ref HEAD) # git branch post-rebase # git reset --hard pre-rebase # test_must_fail git rebase master # echo hello hello # git add hello # git rebase --continue # test refs/heads/skip-reference = $(git symbolic-ref HEAD) # git reset --hard post-rebase # ok 6 - checkout skip-merge ok 7 - rebase with --merge not ok 8 - rebase --skip with --merge # # git rebase --skip # ok 9 - merge and reference trees equal not ok 10 - moved back to branch correctly # # test refs/heads/skip-merge = $(git symbolic-ref HEAD) # # failed 4 among 10 test(s) Christoph has also suggested a small test script in his original email that started this thread: http://thread.gmane.org/gmane.comp.version-control.git/233516 -- Andriy Gapon -- 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 (Sep 2013, #01; Tue, 3)
On Tue, Sep 03, 2013 at 04:00:32PM -0700, Junio C Hamano wrote: * jk/duplicate-objects-in-packs (2013-08-24) 6 commits - default pack.indexDuplicates to false - index-pack: optionally reject packs with duplicate objects - test index-pack on packs with recoverable delta cycles - add tests for indexing packs with delta cycles - sha1-lookup: handle duplicate keys with GIT_USE_LOOKUP - test-sha1: add a binary output mode A packfile that stores the same object more than once is broken and will be rejected. Will merge to 'next'. Hmph. I happened to be looking at the write_idx_file code a few minutes ago, and noticed the results of commit 68be2fe (receive-pack, fetch-pack: reject bogus pack that records objects twice, 2011-11-16). Now I feel like a dunce for reimplementing the same thing a few lines above (and the reason I did not catch it in my tests is that index-pack --strict is not enabled by default). We should probably drop the two top commits. We may want to keep the test from the second-to-last, though, but change it to use index-pack --strict. Like this: -- 8 -- Subject: t5308: check that index-pack --strict detects duplicate objects Commit 68be2fe long ago taught index-pack to notice and reject duplicate objects if --strict is given (which it is for incoming packs, if transfer.fsckObjects is set). However, it never tested the code, because we did not have an easy way of generating such a bogus pack. Now that we have test infrastructure to handle this, let's confirm that it works. Signed-off-by: Jeff King p...@peff.net --- t/t5308-pack-detect-duplicates.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git a/t/t5308-pack-detect-duplicates.sh b/t/t5308-pack-detect-duplicates.sh index 04fe242..9c5a876 100755 --- a/t/t5308-pack-detect-duplicates.sh +++ b/t/t5308-pack-detect-duplicates.sh @@ -70,4 +70,11 @@ test_expect_success 'lookup in duplicated pack (GIT_USE_LOOKUP)' ' test_cmp expect actual ' +test_expect_success 'index-pack can reject packs with duplicates' ' + clear_packs + create_pack dups.pack 2 + test_must_fail git index-pack --strict --stdin dups.pack + test_expect_code 1 git cat-file -e $LO_SHA1 +' + test_done -- 1.8.4.2.g87d4a77 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in git rebase --continue in v1.8.4
This looks like bug in FreeBSD shell indeed. If a script is sourced within a function scope, then 'return' in the script causes the function to return. But it should cause the sourced script to return. I'll see what we can do about this. Sorry for distracting you. And thank you for the help! -- Andriy Gapon -- 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] Reject non-ff pulls by default
On Wed, Sep 04, 2013 at 09:10:47AM +0100, John Keeping wrote: I think there are two distinct uses for pull, which boil down to: (1) git pull (2) git pull $remote $branch For (1) a merge is almost always the wrong thing to do since it will be backwards and break --first-parent. Is it always wrong? You are assuming a topic-branch workflow where --first-parent is actually meaningful. What about a centralized workflow where everyone works on master? The correct thing to do on a non-ff push in that case is git pull git push. Some people would argue that the pull should rebase there, but I think there are valid arguments either way. We can discuss in that direction if you want. I can perhaps buy the argument that it is better to help people who are using a topic branch workflow (which we generally want to encourage) to avoid making backwards merges, and the cost is that people with sloppy workflows will have to do more work / configuration. But we should be clear that this is a tradeoff we are making. The patch in jc/pull-training-wheel talks about annoying old timers, but I think you may also be annoying clueless new users who simply want an svn-like workflow without thinking too hard about it. I do not think we know what we want is to affect git pull origin. I consider git pull $remote to be an artifact of the way git-pull is implemented on top of git-fetch; perhaps I'm missing something but I can't see a scenario where this is useful. Imagine a workflow where each topic is in its own repository instead of in its own branch inside a repository. Or where each developer has his or her own repository, but everybody just works on the master branch of their repository (or perhaps uses branches, but keeps master as a stable base). Alice is the integration manager; Bob tells her that he has work ready to integrate. She runs git pull ~bob/project, which will merge Bob's HEAD. This is not very different from the kernel workflow, where Linus may do a git pull $remote to fetch a sub-system maintainer's work, except that these days people typically mark the to-be-integrated work in a for-linus branch or tag. However, you can find many Merge git:// entries even in recent kernel history. I think this kind of pull would fall into the same situation as your (2) above. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Reject non-ff pulls by default
On Wed, Sep 04, 2013 at 05:25:27AM -0400, Jeff King wrote: On Wed, Sep 04, 2013 at 09:10:47AM +0100, John Keeping wrote: I think there are two distinct uses for pull, which boil down to: (1) git pull (2) git pull $remote $branch For (1) a merge is almost always the wrong thing to do since it will be backwards and break --first-parent. Is it always wrong? You are assuming a topic-branch workflow where --first-parent is actually meaningful. What about a centralized workflow where everyone works on master? The correct thing to do on a non-ff push in that case is git pull git push. Some people would argue that the pull should rebase there, but I think there are valid arguments either way. We can discuss in that direction if you want. I'm one of the people who argues that it should rebase there ;-) The point of jc/pull-training-wheel is to help users think about that. I can perhaps buy the argument that it is better to help people who are using a topic branch workflow (which we generally want to encourage) to avoid making backwards merges, and the cost is that people with sloppy workflows will have to do more work / configuration. But we should be clear that this is a tradeoff we are making. The patch in jc/pull-training-wheel talks about annoying old timers, but I think you may also be annoying clueless new users who simply want an svn-like workflow without thinking too hard about it. The scenario I have is a central repository where some developers use a topic branch workflow but others are less familiar with Git and don't really think about what they're doing. I do not think we know what we want is to affect git pull origin. I consider git pull $remote to be an artifact of the way git-pull is implemented on top of git-fetch; perhaps I'm missing something but I can't see a scenario where this is useful. Imagine a workflow where each topic is in its own repository instead of in its own branch inside a repository. Or where each developer has his or her own repository, but everybody just works on the master branch of their repository (or perhaps uses branches, but keeps master as a stable base). Alice is the integration manager; Bob tells her that he has work ready to integrate. She runs git pull ~bob/project, which will merge Bob's HEAD. This is not very different from the kernel workflow, where Linus may do a git pull $remote to fetch a sub-system maintainer's work, except that these days people typically mark the to-be-integrated work in a for-linus branch or tag. However, you can find many Merge git:// entries even in recent kernel history. I think this kind of pull would fall into the same situation as your (2) above. OK - so I was missing this. Given this, the jc/pull-training-wheel series is doing the right thing here. -- 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
My Proposal
Good day, I Am Chi Pui;Do not be surprised! I got your email contact via the World Email On-line Directory I am crediting officer at Sino Pac Bank Plc in Hong Kong and i have a deal of $17.3M to discuss with you urgently. Regards, Mr.Chi Pui -- 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: German translation errors
Hi, this is not an error but intention. From Git 1.8.4, the German translation switches from pure German to German+English. For me the most important reasons for that are that terms like Branch and Tag are well-known SCM/Git terms for many German people, and using Zweig and Marke could be more confusing than just use the english words. It's not just these two words, but also terms like remote-tracking, index and some such. The second reason is to get closer to books. The books I know do not translate Git/SCM terms, e.g. the Pro Git book [1] and also books you can buy on a store. I think it's better to read the same terms in Git messages as you read in books. Ralf [1] http://git-scm.com/book/de On Wed, Sep 4, 2013 at 8:24 AM, Dirk Heinrichs dirk.heinri...@altum.de wrote: Hi, when I fetch from remote repositories, git tells me about new branches and tags by saying [neuer Branch] or [neuer Tag]. While Branch translates to Zweig in german, the german word Tag actually means day, so git is telling me something about a new day for every new tag. Should be neue Marke. Thanks... Dirk -- Dirk Heinrichs dirk.heinri...@altum.de Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinri...@altum.de -- 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 (Sep 2013, #01; Tue, 3)
Junio C Hamano gits...@pobox.com writes: * mm/status-without-comment-char (2013-08-29) 5 commits - status: introduce status.displayCommentChar to disable display of # - SQUASH: do not fprintf() random strings - get rid of git submodule summary --for-status - wt-status: use argv_array API - builtin/stripspace.c: fix broken indentation Allow git status to omit the prefix to make its output a comment in a commit log editor, which is not necessary for human consumption. I'm waiting for the situation of git submodule --for-status to be settled to send a reroll. Don't merge this for now, and let bc/submodule-status-ignored converge. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in git rebase --continue in v1.8.4
Andriy Gapon a...@freebsd.org writes:
This looks like bug in FreeBSD shell indeed.
Yes: the testsuite would have caught it otherwise.
If a script is sourced within a function scope, then 'return' in the script
causes the function to return. But it should cause the sourced script to
return.
OK, so this is FreeBSD's fault. But that should not prevent us from
fixing Git to make it work with FreeBSD.
Does the patch below fix the testsuite for you?
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -167,13 +167,22 @@ You can run git stash pop or git stash drop at any
time.
rm -rf $state_dir
}
-run_specific_rebase () {
+run_specific_rebase_internal () {
if [ $interactive_rebase = implied ]; then
GIT_EDITOR=:
export GIT_EDITOR
autosquash=
fi
+ # On FreeBSD, the shell's return returns from the current
+ # function, not from the current file inclusion.
+ # run_specific_rebase_internal has the file inclusion as a
+ # last statement, so POSIX and FreeBSD's return will do the
+ # same thing.
. git-rebase--$type
+}
+
+run_specific_rebase () {
+ run_specific_rebase_internal
ret=$?
if test $ret -eq 0
then
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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] add--interactive: fix external command invocation on Windows
On Wed, Sep 4, 2013 at 2:24 PM, Johannes Sixt j.s...@viscovery.net wrote:
From: Johannes Sixt j...@kdbg.org
Back in 21e9757e (Hack git-add--interactive to make it work with
ActiveState Perl, 2007-08-01), the invocation of external commands was
changed to use qx{} on Windows. The rationale was that the command
interpreter on Windows is not a POSIX shell, but rather Windows's CMD.
That patch was wrong to include 'msys' in the check whether to use qx{}
or not: 'msys' identifies MSYS perl as shipped with Git for Windows,
which does not need the special treatment; qx{} should be used only with
ActiveState perl, which is identified by 'MSWin32'.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
Am 9/2/2013 13:56, schrieb Duy Nguyen:
On Mon, Sep 2, 2013 at 5:41 PM, Johannes Sixt j.s...@viscovery.net wrote:
Which features do we lose on Windows with the previous patch and this fixup?
New pathspec magic :(glob), :(literal) and :(icase). You can still use
them via --*-pathspecs or equivalent env variables. You just can't
enable them per individual pathspec.
I think this here is the correct solution rather than the special cases
for Windows that you proposed. ActiveState perl users would still suffer,
but that is a problem of the run_cmd_pipe implementation, which would
need a smarter method to quote the arguments before it feeds them to qx{}.
I admit this is cleaner than my patch. Let's see any users using
ActiveState Perl yell up, then we'll deal with the problem.
git-add--interactive.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 75a991f..5156384 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -169,7 +169,7 @@ my %patch_modes = (
my %patch_mode_flavour = %{$patch_modes{stage}};
sub run_cmd_pipe {
- if ($^O eq 'MSWin32' || $^O eq 'msys') {
+ if ($^O eq 'MSWin32') {
my @invalid = grep {m/[:*]/} @_;
die $^O does not support: @invalid\n if @invalid;
my @args = map { m/ /o ? \$_\: $_ } @_;
--
1.8.4.1549.gc059550.dirty
--
Duy
--
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 v3] Teach git to change to a given directory using -C option
On Wed, Sep 04, 2013 at 02:36:47PM +0800, Nazri Ramliy wrote:
On Wed, Sep 4, 2013 at 6:46 AM, Junio C Hamano gits...@pobox.com wrote:
Does the above format correctly without the usual second and
subsequent paragraphs are not indented, but has '+' in place of
a blank line?
No it doesn't. I'll fix it in the next reroll.
- if (!prefixcmp(cmd, --exec-path)) {
+ if (!strcmp(cmd, -C)) {
+ if (*argc 2) {
+ fprintf(stderr, No directory given for
-C.\n );
+ usage(git_usage_string);
+ }
+ if (chdir((*argv)[1]))
+ die_errno(Cannot change to '%s',
(*argv)[1]);
+ if (envchanged)
+ *envchanged = 1;
+ (*argv)++;
+ (*argc)--;
+ } else if (!prefixcmp(cmd, --exec-path)) {
We usually do not prepend to an existing if/else if/ chain unless
there is a very good reason (e.g. the new if condition is very
often triggered and we are better off checking it early) exactly
because doing so would make a patch that is ugly like the above.
You are not touching the codepath that deal with --exec-path, but
the resulting patch makes it appear as if you are doing something to
it.
I agree with you here. I'll send the reroll later.
Here it is.
Eric: Care to give your Reviewed-by: stamp?
nazri
-- 8 --
Subject: git: run in a directory given with -C option
This is similar in spirit to to make -C dir ... and tar -C dir
It takes more keypresses to invoke git command in a different
directory than the current one without leaving the current
directory:
1. (cd ~/foo git status)
git --git-dir=~/foo/.git --work-dir=~/foo status
GIT_DIR=~/foo/.git GIT_WORK_TREE=~/foo git status
2. (cd ../..; git grep foo)
3. for d in d1 d2 d3; do (cd $d git svn rebase); done
While doable the methods shown above are arguably more suitable for
scripting than quick command line invocations.
With this new option, the above can be done with fewer keystrokes:
1. git -C ~/foo status
2. git -C ../.. grep foo
3. for d in d1 d2 d3; do git -C $d svn rebase; done
A new test script is added to verify the behavior of this option with
other path-related options like --git-dir and --work-tree.
Signed-off-by: Nazri Ramliy ayieh...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git.txt | 16 +-
git.c | 13 +++-
t/t0056-git-C.sh | 82 +++
3 files changed, 109 insertions(+), 2 deletions(-)
create mode 100755 t/t0056-git-C.sh
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 83edf30..ae049da 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -9,7 +9,7 @@ git - the stupid content tracker
SYNOPSIS
[verse]
-'git' [--version] [--help] [-c name=value]
+'git' [--version] [--help] [-C path] [-c name=value]
[--exec-path[=path]] [--html-path] [--man-path] [--info-path]
[-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
[--git-dir=path] [--work-tree=path] [--namespace=name]
@@ -395,6 +395,20 @@ displayed. See linkgit:git-help[1] for more information,
because `git --help ...` is converted internally into `git
help ...`.
+-C path::
+ Run as if git was started in path instead of the current working
+ directory. When multiple -C options are given, each subsequent
+ non-absolute -C path is interpreted relative to the preceding -C
+ path.
++
+This option affects options that expect path name like --git-dir and
+--work-tree in that their interpretations of the path names would be
+made relative to the working directory caused by the -C option. For
+example the following invocations are equivalent:
+
+git --git-dir=a.git --work-tree=b -C c status
+git --git-dir=c/a.git --work-tree=c/b status
+
-c name=value::
Pass a configuration parameter to the command. The value
given will override values from configuration files.
diff --git a/git.c b/git.c
index 2025f77..a2d99a7 100644
--- a/git.c
+++ b/git.c
@@ -7,7 +7,7 @@
#include commit.h
const char git_usage_string[] =
- git [--version] [--help] [-c name=value]\n
+ git [--version] [--help] [-C path] [-c name=value]\n
[--exec-path[=path]] [--html-path] [--man-path]
[--info-path]\n
[-p|--paginate|--no-pager] [--no-replace-objects]
[--bare]\n
[--git-dir=path] [--work-tree=path]
[--namespace=name]\n
@@ -153,6 +153,17 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
set_alternate_shallow_file((*argv)[0]);
if (envchanged)
*envchanged = 1;
+ } else if (!strcmp(cmd, -C))
Re: German translation errors
Am Mittwoch, 4. September 2013, 13:11:39 schrieben Sie: this is not an error but intention. From Git 1.8.4, the German translation switches from pure German to German+English. For me the most important reasons for that are that terms like Branch and Tag are well-known SCM/Git terms for many German people, and using Zweig and Marke could be more confusing than just use the english words. Ah, OK. I must admit I also use the english words in day-to-day (german) conversations. However, in case of tags, when spoken, you have the ability to pronounce tag differently (long a when you mean day, short a for a git tag), which is not the case in a written conversation. How about using neues Tag instead of neuer Tag? Bye... Dirk -- Dirk Heinrichs dirk.heinri...@altum.de Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinri...@altum.de -- 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: Officially start moving to the term 'staging area'
On Wed, Sep 4, 2013 at 3:13 AM, Piotr Krukowiecki piotr.krukowie...@gmail.com wrote: Just wanted to point to a Dr. Dobb's article from Monday: http://www.drdobbs.com/tools/getting-started-with-git-the-fundamental/240160261?pgno=2 The author does not use the use the word index at all. Instead he writes in following way: --- DR DOBBS QUOTE --- Sorry for not responding to your comments Drew, no time at the moment. NP. What he writes [in that quote at least] is entirely reasonable. In fact, oddly enough (as I presume you meant it as a refutation), it can be seen to support my argument: don't mess with the core code much (if at all) but fix the documentation. That's all that I've been arguing since day one. We don't need to make big huge changes in every part of the Git metaphor set to better explain what is going on to newbies and casual users. (Aside from the fact that there's a huge body of existing documentation, tools, and usage patterns that depends on the currently predominant model.) I still argue that for a not insignificant group of users--people who are happy with the current paradigm and therefore aren't making a lot of noise--the current core metaphor is actually useful despite the name being more than just a tad bit unfortunate. Alas, for dealing with some of the advanced usage explanations it can be argued that the staging area metaphor (it implies _completed_ bundles ready to package into commits and ship--I envision shipping trailers being filled with _immutable_ boxes and attached to trucks) is actually harmful, but we can talk about that if there's a need. -- -Drew Northup -- As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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] git-gui: Modify push dialog to support Gerrit review
Problem: It is not possible to push for Gerrit review
as you will always try to push to /refs/heads/... on
the remote. As you should not be forced to work on a
branch with the same name as some branch on the remote,
some more flexibility in the selection of destination
branch is also needed.
Changes done:
Remove selection of branches to push - push always HEAD.
This can be justified by the fact that this far the most
common thing to do.
Specify both the remote repository to push to as well as
the specific branch on that remote. This gives the flexibility.
Add option to specify Gerrit review. If selected, replace
the traditional heads with the artificial for in the
destination ref spec. This is what actually solved the trigger
problem.
Limit the branches to select from to the known branches
for currently selected remote. This is motivated in better
usability. Works only when usettk is true - it is left for
further study how to change the values in tk_optionMenu on the
fly.
Signed-off-by: Joergen Edelbo j...@napatech.com
---
Hi there,
We are at Napatech A/S just about to roll out a Git/Gerrit/Jenkins
solution. It will really help the gui oriented people in pushing
commits if this can be done directly in git-gui.
BR
Joergen Edelbo
Napatech A/S
lib/transport.tcl | 184 +
1 file changed, 142 insertions(+), 42 deletions(-)
diff --git a/lib/transport.tcl b/lib/transport.tcl
index e5d211e..4c20ef7 100644
--- a/lib/transport.tcl
+++ b/lib/transport.tcl
@@ -59,20 +59,42 @@ proc push_to {remote} {
console::exec $w $cmd
}
-proc start_push_anywhere_action {w} {
- global push_urltype push_remote push_url push_thin push_tags
- global push_force
- global repo_config
-
- set is_mirror 0
- set r_url {}
+proc get_remote_rep {} {
+ global push_urltype push_remote push_url
+ set rep {}
switch -- $push_urltype {
- remote {
- set r_url $push_remote
- catch {set is_mirror $repo_config(remote.$push_remote.mirror)}
+ remote { set rep $push_remote }
+ url{ set rep $push_url }
}
- url {set r_url $push_url}
+ return $rep
+}
+
+proc get_remote_branch {} {
+ global push_branchtype push_branch push_new
+ set branch {}
+ switch -- $push_branchtype {
+ existing { set branch $push_branch }
+ create { set branch $push_new }
+ }
+ return $branch
+}
+
+proc get_remote_ref_spec {} {
+ global gerrit_review
+ set push_branch [get_remote_branch]
+ if {$gerrit_review} {
+ return refs/for/$push_branch
+ } else {
+ return refs/heads/$push_branch
}
+}
+
+proc start_push_anywhere_action {w} {
+ global push_thin push_tags push_force
+ global repo_config current_branch is_detached
+
+ set is_mirror 0
+ set r_url [get_remote_rep]
if {$r_url eq {}} return
set cmd [list git push]
@@ -87,28 +109,25 @@ proc start_push_anywhere_action {w} {
lappend cmd --tags
}
lappend cmd $r_url
+
+ catch {set is_mirror $repo_config(remote.$r_url.mirror)}
if {$is_mirror} {
set cons [console::new \
[mc push %s $r_url] \
[mc Mirroring to %s $r_url]]
} else {
- set cnt 0
- foreach i [$w.source.l curselection] {
- set b [$w.source.l get $i]
- lappend cmd refs/heads/$b:refs/heads/$b
- incr cnt
- }
- if {$cnt == 0} {
- return
- } elseif {$cnt == 1} {
- set unit branch
+ if {$is_detached} {
+ set src HEAD
} else {
- set unit branches
+ set src $current_branch
}
+ set dest [get_remote_ref_spec]
+
+ lappend cmd $src:$dest
set cons [console::new \
[mc push %s $r_url] \
- [mc Pushing %s %s to %s $cnt $unit $r_url]]
+ [mc Pushing %s to %s $src $dest]]
}
console::exec $cons $cmd
destroy $w
@@ -117,10 +136,58 @@ proc start_push_anywhere_action {w} {
trace add variable push_remote write \
[list radio_selector push_urltype remote]
+proc update_branchtype {br} {
+ global current_branch push_branch push_branchtype
+ if {$br eq {}} {
+ set push_branchtype create
+ set push_branch {}
+ } else {
+ set push_branchtype existing
+ if {[lsearch -sorted -exact $br $current_branch] != -1} {
+ set push_branch $current_branch
+ } elseif {[lsearch -sorted -exact $br master] != -1} {
+ set
[PATCH v4 8/8] update-ref: add test cases covering --stdin signature
Extend t/t1400-update-ref.sh to cover cases using the --stdin option.
Signed-off-by: Brad King brad.k...@kitware.com
---
t/t1400-update-ref.sh | 445 ++
1 file changed, 445 insertions(+)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index e415ee0..e8ba0d2 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -302,4 +302,449 @@ test_expect_success \
'git cat-file blob master@{2005-05-26 23:42}:F (expect OTHER)' \
'test OTHER = $(git cat-file blob master@{2005-05-26 23:42}:F)'
+a=refs/heads/a
+b=refs/heads/b
+c=refs/heads/c
+E=''
+pws='path with space'
+
+print_nul() {
+ while test $# -gt 0; do
+ printf -- $1
+ printf -- Q | q_to_nul
+ shift || return
+ done
+}
+
+test_expect_success '-z fails without --stdin' '
+ test_must_fail git update-ref -z $m $m $m 2err
+ grep usage: git update-ref err
+'
+
+test_expect_success 'stdin test setup' '
+ echo $pws $pws
+ git add -- $pws
+ git commit -m $pws
+'
+
+test_expect_success 'stdin works with no input' '
+ stdin
+ git update-ref --stdin stdin
+ git rev-parse --verify -q $m
+'
+
+test_expect_success 'stdin works with whitespace-only input' '
+ echo stdin
+ git update-ref --stdin stdin 2err
+ git rev-parse --verify -q $m
+'
+
+test_expect_success 'stdin fails on bad input line with only --' '
+ echo -- stdin
+ test_must_fail git update-ref --stdin stdin 2err
+ grep fatal: input line with no ref err
+'
+
+test_expect_success 'stdin fails on bad input line with only --bad-option' '
+ echo --bad-option stdin
+ test_must_fail git update-ref --stdin stdin 2err
+ grep fatal: unknown option --bad-option err
+'
+
+test_expect_success 'stdin fails on bad ref name' '
+ echo ~a $m stdin
+ test_must_fail git update-ref --stdin stdin 2err
+ grep fatal: invalid ref format: ~a err
+'
+
+test_expect_success 'stdin fails on badly quoted input' '
+ echo $a \master stdin
+ test_must_fail git update-ref --stdin stdin 2err
+ grep fatal: badly quoted argument: \\\master err
+'
+
+test_expect_success 'stdin fails on bad input line with too many arguments' '
+ echo $a $m $m $m stdin
+ test_must_fail git update-ref --stdin stdin 2err
+ grep fatal: too many arguments for ref $a err
+'
+
+test_expect_success 'stdin fails on bad input line with too few arguments' '
+ echo $a stdin
+ test_must_fail git update-ref --stdin stdin 2err
+ grep fatal: missing new value for ref $a err
+'
+
+test_expect_success 'stdin fails with duplicate refs' '
+ cat stdin -EOF
+ $a $m
+ $b $m
+ $a $m
+ EOF
+ test_must_fail git update-ref --stdin stdin 2err
+ grep fatal: Multiple updates for ref '''$a''' not allowed. err
+'
+
+test_expect_success 'stdin create ref works with no old value' '
+ echo $a $m stdin
+ git update-ref --stdin stdin
+ git rev-parse $m expect
+ git rev-parse $a actual
+ test_cmp expect actual
+'
+
+test_expect_success 'stdin create ref works with zero old value' '
+ echo $b $m $Z stdin
+ git update-ref --stdin stdin
+ git rev-parse $m expect
+ git rev-parse $b actual
+ test_cmp expect actual
+ git update-ref -d $b
+'
+
+test_expect_success 'stdin create ref works with empty old value' '
+ echo $b $m $E stdin
+ git update-ref --stdin stdin
+ git rev-parse $m expect
+ git rev-parse $b actual
+ test_cmp expect actual
+'
+
+test_expect_success 'stdin create ref works with path with space to blob' '
+ echo refs/blobs/pws \$m:$pws\ stdin
+ git update-ref --stdin stdin
+ git rev-parse $m:$pws expect
+ git rev-parse refs/blobs/pws actual
+ test_cmp expect actual
+ git update-ref -d refs/blobs/pws
+'
+
+test_expect_success 'stdin create ref fails with wrong old value' '
+ echo $c $m $m~1 stdin
+ test_must_fail git update-ref --stdin stdin 2err
+ grep fatal: Cannot lock the ref '''$c''' err
+ test_must_fail git rev-parse --verify -q $c
+'
+
+test_expect_success 'stdin create ref fails with bad old value' '
+ echo $c $m does-not-exist stdin
+ test_must_fail git update-ref --stdin stdin 2err
+ grep fatal: invalid old value for ref $c: does-not-exist err
+ test_must_fail git rev-parse --verify -q $c
+'
+
+test_expect_success 'stdin create ref fails with bad new value' '
+ echo $c does-not-exist stdin
+ test_must_fail git update-ref --stdin stdin 2err
+ grep fatal: invalid new value for ref $c: does-not-exist err
+ test_must_fail git rev-parse --verify -q $c
+'
+
+test_expect_success 'stdin update ref works with right old value' '
+ echo $b $m~1 $m stdin
+ git update-ref --stdin stdin
[PATCH v4 5/8] refs: add function to repack without multiple refs
Generalize repack_without_ref as repack_without_refs to support a list
of refs and implement the former in terms of the latter.
Signed-off-by: Brad King brad.k...@kitware.com
---
refs.c | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/refs.c b/refs.c
index ab9d22e..92d801c 100644
--- a/refs.c
+++ b/refs.c
@@ -2414,42 +2414,57 @@ static int curate_packed_ref_fn(struct ref_entry
*entry, void *cb_data)
return 0;
}
-static int repack_without_ref(const char *refname)
+static int repack_without_refs(const char **refnames, int n)
{
struct ref_dir *packed;
struct string_list refs_to_delete = STRING_LIST_INIT_DUP;
struct string_list_item *ref_to_delete;
+ int i, removed = 0;
+
+ /* Look for a packed ref */
+ for (i = 0; i n; i++)
+ if (get_packed_ref(refnames[i]))
+ break;
- if (!get_packed_ref(refname))
- return 0; /* refname does not exist in packed refs */
+ /* Avoid locking if we have nothing to do */
+ if (i == n)
+ return 0; /* no refname exists in packed refs */
if (lock_packed_refs(0)) {
unable_to_lock_error(git_path(packed-refs), errno);
- return error(cannot delete '%s' from packed refs, refname);
+ return error(cannot delete '%s' from packed refs,
refnames[i]);
}
packed = get_packed_refs(ref_cache);
- /* Remove refname from the cache: */
- if (remove_entry(packed, refname) == -1) {
+ /* Remove refnames from the cache */
+ for (i = 0; i n; i++)
+ if (remove_entry(packed, refnames[i]) != -1)
+ removed = 1;
+ if (!removed) {
/*
-* The packed entry disappeared while we were
+* All packed entries disappeared while we were
* acquiring the lock.
*/
rollback_packed_refs();
return 0;
}
- /* Remove any other accumulated cruft: */
+ /* Remove any other accumulated cruft */
do_for_each_entry_in_dir(packed, 0, curate_packed_ref_fn,
refs_to_delete);
for_each_string_list_item(ref_to_delete, refs_to_delete) {
if (remove_entry(packed, ref_to_delete-string) == -1)
die(internal error);
}
- /* Write what remains: */
+ /* Write what remains */
return commit_packed_refs();
}
+static int repack_without_ref(const char *refname)
+{
+ return repack_without_refs(refname, 1);
+}
+
static int delete_ref_loose(struct ref_lock *lock, int flag)
{
if (!(flag REF_ISPACKED) || flag REF_ISSYMREF) {
--
1.8.4.rc3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 6/8] refs: add update_refs for multiple simultaneous updates
Add 'struct ref_update' to encode the information needed to update or
delete a ref (name, new sha1, optional old sha1, no-deref flag). Add
function 'update_refs' accepting an array of updates to perform. First
sort the input array to order locks consistently everywhere and reject
multiple updates to the same ref. Then acquire locks on all refs with
verified old values. Then update or delete all refs accordingly. Fail
if any one lock cannot be obtained or any one old value does not match.
Though the refs themselves cannot be modified together in a single
atomic transaction, this function does enable some useful semantics.
For example, a caller may create a new branch starting from the head of
another branch and rewind the original branch at the same time. This
transfers ownership of commits between branches without risk of losing
commits added to the original branch by a concurrent process, or risk of
a concurrent process creating the new branch first.
Signed-off-by: Brad King brad.k...@kitware.com
---
refs.c | 100 +
refs.h | 20 +
2 files changed, 120 insertions(+)
diff --git a/refs.c b/refs.c
index 92d801c..46177ad 100644
--- a/refs.c
+++ b/refs.c
@@ -3237,6 +3237,106 @@ int update_ref(const char *action, const char *refname,
return update_ref_write(action, refname, sha1, lock, onerr);
}
+static int ref_update_compare(const void *r1, const void *r2)
+{
+ const struct ref_update * const *u1 = r1;
+ const struct ref_update * const *u2 = r2;
+ return strcmp((*u1)-ref_name, (*u2)-ref_name);
+}
+
+static int ref_update_reject_duplicates(struct ref_update **updates, int n,
+ enum action_on_err onerr)
+{
+ int i;
+ for (i = 1; i n; i++)
+ if (!strcmp(updates[i - 1]-ref_name, updates[i]-ref_name)) {
+ const char *str =
+ Multiple updates for ref '%s' not allowed.;
+ switch (onerr) {
+ case MSG_ON_ERR:
+ error(str, updates[i]-ref_name); break;
+ case DIE_ON_ERR:
+ die(str, updates[i]-ref_name); break;
+ case QUIET_ON_ERR:
+ break;
+ }
+ return 1;
+ }
+ return 0;
+}
+
+int update_refs(const char *action, const struct ref_update **updates_orig,
+ int n, enum action_on_err onerr)
+{
+ int ret = 0, delnum = 0, i;
+ struct ref_update **updates;
+ int *types;
+ struct ref_lock **locks;
+ const char **delnames;
+
+ if (!updates_orig || !n)
+ return 0;
+
+ /* Allocate work space */
+ updates = xmalloc(sizeof(*updates) * n);
+ types = xmalloc(sizeof(*types) * n);
+ locks = xcalloc(n, sizeof(*locks));
+ delnames = xmalloc(sizeof(*delnames) * n);
+
+ /* Copy, sort, and reject duplicate refs */
+ memcpy(updates, updates_orig, sizeof(*updates) * n);
+ qsort(updates, n, sizeof(*updates), ref_update_compare);
+ ret = ref_update_reject_duplicates(updates, n, onerr);
+ if (ret)
+ goto cleanup;
+
+ /* Acquire all locks while verifying old values */
+ for (i = 0; i n; i++) {
+ locks[i] = update_ref_lock(updates[i]-ref_name,
+ (updates[i]-have_old ?
+ updates[i]-old_sha1 : NULL),
+ updates[i]-flags,
+ types[i], onerr);
+ if (!locks[i]) {
+ ret = 1;
+ goto cleanup;
+ }
+ }
+
+ /* Perform updates first so live commits remain referenced */
+ for (i = 0; i n; i++)
+ if (!is_null_sha1(updates[i]-new_sha1)) {
+ ret = update_ref_write(action,
+ updates[i]-ref_name,
+ updates[i]-new_sha1,
+ locks[i], onerr);
+ locks[i] = NULL; /* freed by update_ref_write */
+ if (ret)
+ goto cleanup;
+ }
+
+ /* Perform deletes now that updates are safely completed */
+ for (i = 0; i n; i++)
+ if (locks[i]) {
+ delnames[delnum++] = locks[i]-ref_name;
+ ret |= delete_ref_loose(locks[i], types[i]);
+ }
+ ret |= repack_without_refs(delnames, delnum);
+ for (i = 0; i delnum; i++)
+ unlink_or_warn(git_path(logs/%s, delnames[i]));
+ clear_loose_ref_cache(ref_cache);
+
+cleanup:
+ for (i = 0; i n; i++)
+
[PATCH v4 7/8] update-ref: support multiple simultaneous updates
Add a --stdin signature to read update instructions from standard input
and apply multiple ref updates together. Use an input format that
supports any update that could be specified via the command-line,
including object names like branch:path with space.
Signed-off-by: Brad King brad.k...@kitware.com
---
Documentation/git-update-ref.txt | 22 +-
builtin/update-ref.c | 144 ++-
2 files changed, 164 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index 0df13ff..11dd9d3 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -8,7 +8,7 @@ git-update-ref - Update the object name stored in a ref safely
SYNOPSIS
[verse]
-'git update-ref' [-m reason] (-d ref [oldvalue] | [--no-deref] ref
newvalue [oldvalue])
+'git update-ref' [-m reason] (-d ref [oldvalue] | [--no-deref] ref
newvalue [oldvalue] | --stdin)
DESCRIPTION
---
@@ -58,6 +58,26 @@ archive by creating a symlink tree).
With `-d` flag, it deletes the named ref after verifying it
still contains oldvalue.
+With `--stdin`, update-ref reads instructions from standard input and
+performs all modifications together. Empty lines are ignored.
+Each non-empty line is parsed as whitespace-separated arguments.
+Quote arguments containing whitespace as if in C source code.
+Specify updates with lines of the form:
+
+ [--no-deref] [--] ref newvalue [oldvalue]
+
+Lines of any other format or a repeated ref produce an error.
+Specify a zero newvalue to delete a ref and/or a zero oldvalue
+to make sure that a ref not exist. Use either 40 0 or the
+empty string (written as ) to specify a zero value. Use `-z`
+to specify input with no whitespace, quoting, or escaping, and
+terminate each argument by NUL and each line by LF NUL.
+
+If all refs can be locked with matching oldvalues
+simultaneously, all modifications are performed. Otherwise, no
+modifications are performed. Note that while each individual
+ref is updated or deleted atomically, a concurrent reader may
+still see a subset of the modifications.
Logging Updates
---
diff --git a/builtin/update-ref.c b/builtin/update-ref.c
index 51d2684..9c348fb 100644
--- a/builtin/update-ref.c
+++ b/builtin/update-ref.c
@@ -2,23 +2,152 @@
#include refs.h
#include builtin.h
#include parse-options.h
+#include quote.h
+#include argv-array.h
static const char * const git_update_ref_usage[] = {
N_(git update-ref [options] -d refname [oldval]),
N_(git update-ref [options]refname newval [oldval]),
+ N_(git update-ref [options] --stdin [-z]),
NULL
};
+static int updates_alloc;
+static int updates_count;
+static const struct ref_update **updates;
+
+static void update_refs_stdin(int argc, const char **argv)
+{
+ struct ref_update *update;
+
+ /* Skip blank lines */
+ if (!argc)
+ return;
+
+ /* Allocate and zero-init a struct ref_update */
+ update = xcalloc(1, sizeof(*update));
+ ALLOC_GROW(updates, updates_count+1, updates_alloc);
+ updates[updates_count++] = update;
+
+ /* Process options */
+ while (argc 0 argv[0][0] == '-') {
+ const char *arg = argv[0];
+ --argc;
+ ++argv;
+ if (!strcmp(arg, --no-deref))
+ update-flags |= REF_NODEREF;
+ else if (!strcmp(arg, --))
+ break;
+ else
+ die(unknown option %s, arg);
+ }
+
+ /* Set the update ref_name */
+ if (argc 1)
+ die(input line with no ref!);
+ if (check_refname_format(argv[0], REFNAME_ALLOW_ONELEVEL))
+ die(invalid ref format: %s, argv[0]);
+ update-ref_name = xstrdup(argv[0]);
+
+ /* Set the update new_sha1 and, if specified, old_sha1 */
+ if (argc 2)
+ die(missing new value for ref %s, update-ref_name);
+ if (*argv[1] get_sha1(argv[1], update-new_sha1))
+ die(invalid new value for ref %s: %s,
+ update-ref_name, argv[1]);
+ if (argc = 3) {
+ update-have_old = 1;
+ if (*argv[2] get_sha1(argv[2], update-old_sha1))
+ die(invalid old value for ref %s: %s,
+ update-ref_name, argv[2]);
+ }
+
+ if (argc 3)
+ die(too many arguments for ref %s, update-ref_name);
+}
+
+static const char *update_refs_stdin_parse_arg(const char *next,
+ struct strbuf *arg)
+{
+ /* Skip leading whitespace */
+ while (isspace(*next))
+ ++next;
+
+ /* Return NULL when no argument is found */
+ if (!*next)
+ return NULL;
+
+ /* Parse the argument */
+ strbuf_reset(arg);
+ if (*next == '') {
+
[PATCH v4 1/8] reset: rename update_refs to reset_refs
The function resets refs rather than doing arbitrary updates.
Rename it to allow a future general-purpose update_refs function
to be added.
Signed-off-by: Brad King brad.k...@kitware.com
---
builtin/reset.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index afa6e02..789ee48 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -219,7 +219,7 @@ static const char **parse_args(const char **argv, const
char *prefix, const char
return argv[0] ? get_pathspec(prefix, argv) : NULL;
}
-static int update_refs(const char *rev, const unsigned char *sha1)
+static int reset_refs(const char *rev, const unsigned char *sha1)
{
int update_ref_status;
struct strbuf msg = STRBUF_INIT;
@@ -350,7 +350,7 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
if (!pathspec !unborn) {
/* Any resets without paths update HEAD to the head being
* switched to, saving the previous head in ORIG_HEAD before. */
- update_ref_status = update_refs(rev, sha1);
+ update_ref_status = reset_refs(rev, sha1);
if (reset_type == HARD !update_ref_status !quiet)
print_new_head_line(lookup_commit_reference(sha1));
--
1.8.4.rc3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/8] Multiple simultaneously locked ref updates
Hi Folks, Here is the fourth revision of a series to support locking multiple refs at the same time to update all of them consistently. The previous revisions of the series can be found at $gmane/233260, $gmane/233458, and $gmane/233647. Updates since the previous revision of the series: * Patches 1-4 are identical * Patches 5-7 no longer have : at the end of comments, a style I learned from the context of patch 5 but that I saw Junio squash out of patch 5 v2 when he queued it as 53237ae4. * Patch 7 has a re-organized parser and now defines a -z format for stdin that terminates arguments with NUL and lines with LF NUL: ... ref NUL newvalue NUL [ oldvalue NUL ] LF NUL * Patch 8 now has test cases for -z mode and updated error cases for the re-organized parser. Note to maintainer: * Patch 4 needs to be re-queued to replace c7c80f49 due to the tweak suggested in $gmane/233521 and made in v3 and kept in v4. Thanks, -Brad Brad King (8): reset: rename update_refs to reset_refs refs: report ref type from lock_any_ref_for_update refs: factor update_ref steps into helpers refs: factor delete_ref loose ref step into a helper refs: add function to repack without multiple refs refs: add update_refs for multiple simultaneous updates update-ref: support multiple simultaneous updates update-ref: add test cases covering --stdin signature Documentation/git-update-ref.txt | 22 +- branch.c | 2 +- builtin/commit.c | 2 +- builtin/fetch.c | 3 +- builtin/receive-pack.c | 3 +- builtin/reflog.c | 2 +- builtin/replace.c| 2 +- builtin/reset.c | 4 +- builtin/tag.c| 2 +- builtin/update-ref.c | 144 - fast-import.c| 2 +- refs.c | 195 ++--- refs.h | 22 +- sequencer.c | 3 +- t/t1400-update-ref.sh| 445 +++ 15 files changed, 812 insertions(+), 41 deletions(-) -- 1.8.4.rc3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/8] refs: report ref type from lock_any_ref_for_update
Expose lock_ref_sha1_basic's type_p argument to callers of
lock_any_ref_for_update. Update all call sites to ignore it by passing
NULL for now.
Signed-off-by: Brad King brad.k...@kitware.com
---
branch.c | 2 +-
builtin/commit.c | 2 +-
builtin/fetch.c| 3 ++-
builtin/receive-pack.c | 3 ++-
builtin/reflog.c | 2 +-
builtin/replace.c | 2 +-
builtin/tag.c | 2 +-
fast-import.c | 2 +-
refs.c | 7 ---
refs.h | 2 +-
sequencer.c| 3 ++-
11 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/branch.c b/branch.c
index c5c6984..f2d383f 100644
--- a/branch.c
+++ b/branch.c
@@ -291,7 +291,7 @@ void create_branch(const char *head,
hashcpy(sha1, commit-object.sha1);
if (!dont_change_ref) {
- lock = lock_any_ref_for_update(ref.buf, NULL, 0);
+ lock = lock_any_ref_for_update(ref.buf, NULL, 0, NULL);
if (!lock)
die_errno(_(Failed to lock ref for update));
}
diff --git a/builtin/commit.c b/builtin/commit.c
index 10acc53..be08f41 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1618,7 +1618,7 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
!current_head
? NULL
: current_head-object.sha1,
- 0);
+ 0, NULL);
nl = strchr(sb.buf, '\n');
if (nl)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index d784b2e..28e4025 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -246,7 +246,8 @@ static int s_update_ref(const char *action,
rla = default_rla.buf;
snprintf(msg, sizeof(msg), %s: %s, rla, action);
lock = lock_any_ref_for_update(ref-name,
- check_old ? ref-old_sha1 : NULL, 0);
+ check_old ? ref-old_sha1 : NULL,
+ 0, NULL);
if (!lock)
return errno == ENOTDIR ? STORE_REF_ERROR_DF_CONFLICT :
STORE_REF_ERROR_OTHER;
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index e3eb5fc..a323070 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -524,7 +524,8 @@ static const char *update(struct command *cmd)
return NULL; /* good */
}
else {
- lock = lock_any_ref_for_update(namespaced_name, old_sha1, 0);
+ lock = lock_any_ref_for_update(namespaced_name, old_sha1,
+ 0, NULL);
if (!lock) {
rp_error(failed to lock %s, name);
return failed to lock;
diff --git a/builtin/reflog.c b/builtin/reflog.c
index 54184b3..28d756a 100644
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
@@ -366,7 +366,7 @@ static int expire_reflog(const char *ref, const unsigned
char *sha1, int unused,
* we take the lock for the ref itself to prevent it from
* getting updated.
*/
- lock = lock_any_ref_for_update(ref, sha1, 0);
+ lock = lock_any_ref_for_update(ref, sha1, 0, NULL);
if (!lock)
return error(cannot lock ref '%s', ref);
log_file = git_pathdup(logs/%s, ref);
diff --git a/builtin/replace.c b/builtin/replace.c
index 59d3115..1ecae8d 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -105,7 +105,7 @@ static int replace_object(const char *object_ref, const
char *replace_ref,
else if (!force)
die(replace ref '%s' already exists, ref);
- lock = lock_any_ref_for_update(ref, prev, 0);
+ lock = lock_any_ref_for_update(ref, prev, 0, NULL);
if (!lock)
die(%s: cannot lock the ref, ref);
if (write_ref_sha1(lock, repl, NULL) 0)
diff --git a/builtin/tag.c b/builtin/tag.c
index af3af3f..2c867d2 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -577,7 +577,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (annotate)
create_tag(object, tag, buf, opt, prev, object);
- lock = lock_any_ref_for_update(ref.buf, prev, 0);
+ lock = lock_any_ref_for_update(ref.buf, prev, 0, NULL);
if (!lock)
die(_(%s: cannot lock the ref), ref.buf);
if (write_ref_sha1(lock, object, NULL) 0)
diff --git a/fast-import.c b/fast-import.c
index 23f625f..5c329f6 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1678,7 +1678,7 @@ static int update_branch(struct branch *b)
return 0;
if (read_ref(b-name, old_sha1))
hashclr(old_sha1);
- lock = lock_any_ref_for_update(b-name, old_sha1, 0);
+ lock = lock_any_ref_for_update(b-name, old_sha1, 0, NULL);
if (!lock)
[PATCH v4 4/8] refs: factor delete_ref loose ref step into a helper
Factor loose ref deletion into helper function delete_ref_loose to allow
later use elsewhere.
Signed-off-by: Brad King brad.k...@kitware.com
---
refs.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/refs.c b/refs.c
index 4347826..ab9d22e 100644
--- a/refs.c
+++ b/refs.c
@@ -2450,24 +2450,31 @@ static int repack_without_ref(const char *refname)
return commit_packed_refs();
}
+static int delete_ref_loose(struct ref_lock *lock, int flag)
+{
+ if (!(flag REF_ISPACKED) || flag REF_ISSYMREF) {
+ /* loose */
+ int err, i = strlen(lock-lk-filename) - 5; /* .lock */
+
+ lock-lk-filename[i] = 0;
+ err = unlink_or_warn(lock-lk-filename);
+ lock-lk-filename[i] = '.';
+ if (err errno != ENOENT)
+ return 1;
+ }
+ return 0;
+}
+
int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
{
struct ref_lock *lock;
- int err, i = 0, ret = 0, flag = 0;
+ int ret = 0, flag = 0;
lock = lock_ref_sha1_basic(refname, sha1, delopt, flag);
if (!lock)
return 1;
- if (!(flag REF_ISPACKED) || flag REF_ISSYMREF) {
- /* loose */
- i = strlen(lock-lk-filename) - 5; /* .lock */
- lock-lk-filename[i] = 0;
- err = unlink_or_warn(lock-lk-filename);
- if (err errno != ENOENT)
- ret = 1;
+ ret |= delete_ref_loose(lock, flag);
- lock-lk-filename[i] = '.';
- }
/* removing the loose one could have resurrected an earlier
* packed one. Also, if it was not loose we need to repack
* without it.
--
1.8.4.rc3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Reject non-ff pulls by default
John Keeping j...@keeping.me.uk writes: On Tue, Sep 03, 2013 at 03:38:58PM -0700, Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio already sent a similar patch, but I think this is simpler. I agree that this is simpler, but I am not sure if the behaviour is necessarily better (note that this is different from saying I think the behaviour of this patch is worse). The motivation I read from the original discussion was that new people did git pull (no other parameters) to sync my tree with the central repository as if it were SVN, and because we are not SVN, projects that prefer rebases were unhappy, and the other one was to address *only* that use case. I do not personally like that special casing (i.e. only when no 'integrate with what from where' is given), and applying the you must be explicit between rebase and merge like this series does uniformly might (or might not) be a good thing. I dunno. As I already said; there's is essentially no difference between git pull and git pull origin. We know what you said earlier. That does not make it right or wrong, but I do not think it is in line with the original discussion (that is why John Keeping is kept on the Cc: line). I think there are two distinct uses for pull, which boil down to: (1) git pull (2) git pull $remote $branch For (1) a merge is almost always the wrong thing to do since it will be backwards and break --first-parent. But for (2) a merge is almost always the correct thing to do (in fact it may even be correct to create a merge commit even when this fast forwards) because this most likely comes for a pull request workflow. I do not think we know what we want is to affect git pull origin. I didn't mean to limit this to with an explicit 'from where' without 'which branch', but it appears you took it that way. I should have added: I do not think we know what we want is to affect git pull origin master, either. to clarify. But it seems that Peff's later message in this thread already clarifies this point for me ;-) I consider git pull $remote to be an artifact of the way git-pull is implemented on top of git-fetch; perhaps I'm missing something but I can't see a scenario where this is useful. In the series currently in next, we treat this as (2) above but that's primarily because it is difficult to differentiate these in git-pull.sh without adding code to understand all of the options to git-fetch (or at least those that can accept unstuck arguments). Changing this so that git pull $remote is treated as (1) would be better, but I think it is more important to avoid catching case (1) in the same net which is why jc/pull-training-wheel simply checks if $# is zero; the cost of getting this completely right outweighed the benefit of getting code in that will catch 99% of users. -- 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/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Wed, Sep 04, 2013 at 09:47:12AM -0700, Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: test_cmp_rev follows the same order of arguments a diff -u and produces the same output as plain git diff. It's perfectly readable and normal. This is way off tangent, but I am somewhat sympathetic to Felipe's compare actual with expect, with reservations. This isn't an argument either way, but note that JUnit (and NUnit and PHPUnit) all have assertEquals methods that take the arguments in the order expect, actual. I've always assumed that Git's test framework was imitating that, although I have no idea why that particular order is chosen and is so common. -- 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 4/4] t: branch: improve test rollback
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Sep 3, 2013 at 5:59 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Sep 3, 2013 at 2:32 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
test_expect_success 'refuse --edit-description on unborn branch for now'
'
+ test_when_finished git checkout -
I am not sure if this is a good change. Depending on the outcome of
the git checkout in the test (it may succeed and set @{-1} to the
branch we were on when we entered the test, or it may fail and leave
@{-1} to the branch before we were on when we entered the test),
this will take us to a different place, no?
It is better than leaving Git in an unborn branch.
True, but it falls short of After every test the environment should
be as close as to how it was before as possible., doesn't it?
No it doesn't. Closer is closer.
Closer is not as close as ... possible.
I think the fix is just to use the name of a concrete branch we want
the next test to start on, instead of -, which could be far
quickly done than making excuses like that.
--
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/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
John Keeping j...@keeping.me.uk writes: On Wed, Sep 04, 2013 at 09:47:12AM -0700, Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: test_cmp_rev follows the same order of arguments a diff -u and produces the same output as plain git diff. It's perfectly readable and normal. This is way off tangent, but I am somewhat sympathetic to Felipe's compare actual with expect, with reservations. This isn't an argument either way, but note that JUnit (and NUnit and PHPUnit) all have assertEquals methods that take the arguments in the order expect, actual. I've always assumed that Git's test framework was imitating that,... No. See 82ebb0b6 (add test_cmp function for test scripts, 2008-03-12). The test_cmp was a replacement for diff -u, and the same order we fed diff -u, i.e. expect then actual, was carried over. -- 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: German translation errors
On Wed, Sep 4, 2013 at 3:20 PM, Dirk Heinrichs dirk.heinri...@altum.de wrote: Am Mittwoch, 4. September 2013, 13:11:39 schrieben Sie: this is not an error but intention. From Git 1.8.4, the German translation switches from pure German to German+English. For me the most important reasons for that are that terms like Branch and Tag are well-known SCM/Git terms for many German people, and using Zweig and Marke could be more confusing than just use the english words. Ah, OK. I must admit I also use the english words in day-to-day (german) conversations. However, in case of tags, when spoken, you have the ability to pronounce tag differently (long a when you mean day, short a for a git tag), which is not the case in a written conversation. How about using neues Tag instead of neuer Tag? I've looked at books and blogs to see what others use and both versions are used. Personally I prefer der Tag than das Tag because it feels more natural to me. But I agree that using das Tag is less confusing. I'm going to work on a patch for this. Thanks, Ralf Bye... Dirk -- Dirk Heinrichs dirk.heinri...@altum.de Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinri...@altum.de -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 7/8] update-ref: support multiple simultaneous updates
Brad King brad.k...@kitware.com writes: +With `--stdin`, update-ref reads instructions from standard input and +performs all modifications together. Empty lines are ignored. +Each non-empty line is parsed as whitespace-separated arguments. whitespace-separated implies that we may allow fields separated with not a single SP, but with double SPs or even HTs between them. I personally do not think we should be so loose; it is not like we are allowing the user to type these from the terminal, so limiting separated by a single SP may be perfectly adequate, and make it less error prone (e.g. there will not be a confusion Is 'A SP SP B' A followed by B, or A followed by an empty string followed by B?). +Quote arguments containing whitespace as if in C source code. Probably as if they were strings in C source code. +Specify updates with lines of the form: + + [--no-deref] [--] ref newvalue [oldvalue] + +Lines of any other format or a repeated ref produce an error. +Specify a zero newvalue to delete a ref and/or a zero oldvalue +to make sure that a ref not exist. Use either 40 0 or the +empty string (written as ) to specify a zero value. Use `-z` +to specify input with no whitespace, quoting, or escaping, and +terminate each argument by NUL and each line by LF NUL. This is a somewhat interesting choice of the record terminator. Do we have a precedent to use LF NUL elsewhere? If this is the first such case where we need to express variable number of NUL-separated fields in a record, I think I am fine with LF NUL (but I am sure other people would give us a better convention if we ask them politely ;-)), but I just want to make sure we do it the same way as other codepaths, if exist, that have to handle this kind of thing. -- 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/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Wed, Sep 04, 2013 at 10:38:03AM -0700, Junio C Hamano wrote: This is way off tangent, but I am somewhat sympathetic to Felipe's compare actual with expect, with reservations. This isn't an argument either way, but note that JUnit (and NUnit and PHPUnit) all have assertEquals methods that take the arguments in the order expect, actual. I've always assumed that Git's test framework was imitating that,... No. See 82ebb0b6 (add test_cmp function for test scripts, 2008-03-12). The test_cmp was a replacement for diff -u, and the same order we fed diff -u, i.e. expect then actual, was carried over. I don't think it was intentional at the time. But over the intervening 5 years, I have noticed that I certainly think of test_cmp A B as differences from A to B, and the order makes sense. IOW, the test_cmp is diff abstraction is leaky, and that is fine (if it were not leaky, then order would not matter at all, but it clearly does). But let's take a step back. This seems like an endian-ness issue to me. I.e., some people prefer one order for test assertions, and other people prefer the other. Is anyone actually right, or is this simply a matter of preference? And if it is simply a matter of preference, then why bother going through the pain of changing the current project standard? Though I prefer the current, I can certainly live and adapt to a changed standard, and I do not mind doing so if there is a good reason. But I've yet to see any argument beyond it is not what I like. Which to me argues for the status quo as the path of least resistance. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 7/7] glossary: fix and clarify the definition of 'ref'
Signed-off-by: Richard Hansen rhan...@bbn.com --- Documentation/glossary-content.txt | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 3466ce9..7ad13e1 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -395,10 +395,20 @@ should not be combined with other pathspec. to the result. [[def_ref]]ref:: - A 40-byte hex representation of a def_SHA1,SHA-1 or a name that - denotes a particular def_object,object. They may be stored in - a file under `$GIT_DIR/refs/` directory, or - in the `$GIT_DIR/packed-refs` file. + A name that begins with `refs/` (e.g. `refs/heads/master`) + that points to an def_object_name,object name or another + ref (the latter is called a def_symref,symbolic ref). + For convenience, a ref can sometimes be abbreviated when used + as an argument to a Git command; see linkgit:gitrevisions[7] + for details. + Refs are stored in the def_repository,repository. ++ +The ref namespace is hierarchical. +Different subhierarchies are used for different purposes (e.g. the +`refs/heads/` hierarchy is used to represent local branches). ++ +There are a few special-purpose refs that do not begin with `refs/`. +The most notable example is `HEAD`. [[def_reflog]]reflog:: A reflog shows the local history of a ref. In other words, -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/7] revisions.txt: fix and clarify rev^{type}
If possible, rev will be dereferenced even if it is not a tag type
(e.g., commit dereferenced to a tree).
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/revisions.txt | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index d477b3f..b0f4284 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -111,10 +111,14 @@ some output processing may assume ref names in UTF-8.
'rev{caret}\{type\}', e.g. 'v0.99.8{caret}\{commit\}'::
A suffix '{caret}' followed by an object type name enclosed in
- brace pair means the object
- could be a tag, and dereference the tag recursively until an
- object of that type is found or the object cannot be
- dereferenced anymore (in which case, barf). 'rev{caret}0'
+ brace pair means dereference the object at 'rev' recursively until
+ an object of type 'type' is found or the object cannot be
+ dereferenced anymore (in which case, barf).
+ For example, if 'rev' is a commit-ish, 'rev{caret}\{commit\}'
+ describes the corresponding commit object.
+ Similarly, if 'rev' is a tree-ish, 'rev{caret}\{tree\}'
+ describes the corresponding tree object.
+ 'rev{caret}0'
is a short-hand for 'rev{caret}\{commit\}'.
+
'rev{caret}\{object\}' can be used to make sure 'rev' names an
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/7] documentation cleanups for rev^{type}
On 2013-09-03 18:46, Junio C Hamano wrote:
I hate to say this after seeing you doing a thorough job in this
series, but because tree-ish and commit-ish are both made-up
words, I have a feeling that we are better off unifying to the
dashed form, which unfortunately is the other way around from what
your series does.
I thought you might say that so I held on to the commits that
standardize on tree-ish and commit-ish in my local repo. :)
This series still says tree-ish (also treeish) and commit-ish (also
committish) in gitglossary(7). Would you like me to eliminate the
(also ...) part?
I'm not 100% confident that these don't break translations, although
it still builds and make test passes.
Changes since v2:
* standardize on 'tree-ish' instead of 'treeish'
* standardize on 'commit-ish' instead of 'committish'
Richard Hansen (7):
glossary: mention 'treeish' as an alternative to 'tree-ish'
glossary: define commit-ish (a.k.a. committish)
use 'tree-ish' instead of 'treeish'
use 'commit-ish' instead of 'committish'
glossary: more precise definition of tree-ish (a.k.a. treeish)
revisions.txt: fix and clarify rev^{type}
glossary: fix and clarify the definition of 'ref'
Documentation/RelNotes/1.7.11.2.txt | 2 +-
Documentation/config.txt | 4 +--
Documentation/git-cat-file.txt | 2 +-
Documentation/git-describe.txt | 14 -
Documentation/git-fast-import.txt| 26 +++
Documentation/git-merge-tree.txt | 2 +-
Documentation/git-name-rev.txt | 2 +-
Documentation/git-push.txt | 2 +-
Documentation/gitcli.txt | 2 +-
Documentation/glossary-content.txt | 47 +++-
Documentation/howto/revert-branch-rebase.txt | 2 +-
Documentation/revisions.txt | 12 ---
builtin/describe.c | 4 +--
builtin/merge.c | 2 +-
contrib/examples/git-merge.sh| 2 +-
fast-import.c| 20 ++--
git-cvsserver.perl | 2 +-
po/da.po | 2 +-
po/de.po | 6 ++--
po/fr.po | 4 +--
po/git.pot | 4 +--
po/it.po | 2 +-
po/nl.po | 2 +-
po/pt_PT.po | 2 +-
po/sv.po | 6 ++--
po/vi.po | 6 ++--
po/zh_CN.po | 4 +--
sha1_name.c | 6 ++--
t/t9300-fast-import.sh | 6 ++--
test-match-trees.c | 4 +--
30 files changed, 118 insertions(+), 83 deletions(-)
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/7] glossary: define commit-ish (a.k.a. committish)
Signed-off-by: Richard Hansen rhan...@bbn.com --- Documentation/glossary-content.txt | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 0273095..47e901e 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -82,6 +82,18 @@ to point at the new commit. to the top def_directory,directory of the stored revision. +[[def_commit-ish]]commit-ish (also committish):: + A def_commit_object,commit object or an + def_object,object that can be recursively dereferenced to + a commit object. + The following are all commit-ishes: + a commit object, + a def_tag_object,tag object that points to a commit + object, + a tag object that points to a tag object that points to a + commit object, + etc. + [[def_core_git]]core Git:: Fundamental data structures and utilities of Git. Exposes only limited source code management tools. -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/7] glossary: mention 'treeish' as an alternative to 'tree-ish'
The documentation contains a mix of the two spellings, so include both in the glossary so that a search for either will lead to the definition. Signed-off-by: Richard Hansen rhan...@bbn.com --- Documentation/glossary-content.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index dba5062..0273095 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -486,7 +486,7 @@ should not be combined with other pathspec. with refs to the associated blob and/or tree objects. A def_tree,tree is equivalent to a def_directory,directory. -[[def_tree-ish]]tree-ish:: +[[def_tree-ish]]tree-ish (also treeish):: A def_ref,ref pointing to either a def_commit_object,commit object, a def_tree_object,tree object, or a def_tag_object,tag object pointing to a tag or commit or tree object. -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/7] glossary: more precise definition of tree-ish (a.k.a. treeish)
A tree-ish isn't a ref. Also, mention dereferencing, and that a commit dereferences to a tree, to support gitrevisions(7) and rev-parse's error messages. Signed-off-by: Richard Hansen rhan...@bbn.com --- Documentation/glossary-content.txt | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 47e901e..3466ce9 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -499,9 +499,18 @@ should not be combined with other pathspec. def_tree,tree is equivalent to a def_directory,directory. [[def_tree-ish]]tree-ish (also treeish):: - A def_ref,ref pointing to either a def_commit_object,commit - object, a def_tree_object,tree object, or a def_tag_object,tag - object pointing to a tag or commit or tree object. + A def_tree_object,tree object or an def_object,object + that can be recursively dereferenced to a tree object. + Dereferencing a def_commit_object,commit object yields the + tree object corresponding to the def_revision,revision's + top def_directory,directory. + The following are all tree-ishes: + a def_commit-ish,commit-ish, + a tree object, + a def_tag_object,tag object that points to a tree object, + a tag object that points to a tag object that points to a tree + object, + etc. [[def_unmerged_index]]unmerged index:: An def_index,index which contains unmerged -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/7] use 'commit-ish' instead of 'committish'
Replace 'committish' in documentation and comments with 'commit-ish' to match gitglossary(7) and to be consistent with 'tree-ish'. The only remaining instances of 'committish' are: * variable, function, and macro names * (also committish) in the definition of commit-ish in gitglossary[7] Signed-off-by: Richard Hansen rhan...@bbn.com --- Documentation/config.txt | 4 ++-- Documentation/git-describe.txt | 14 +++--- Documentation/git-fast-import.txt| 26 +- Documentation/git-name-rev.txt | 2 +- Documentation/git-push.txt | 2 +- Documentation/gitcli.txt | 2 +- Documentation/howto/revert-branch-rebase.txt | 2 +- builtin/describe.c | 4 ++-- builtin/merge.c | 2 +- contrib/examples/git-merge.sh| 2 +- fast-import.c| 16 po/da.po | 2 +- po/de.po | 6 +++--- po/fr.po | 4 ++-- po/git.pot | 4 ++-- po/it.po | 2 +- po/nl.po | 2 +- po/pt_PT.po | 2 +- po/sv.po | 6 +++--- po/vi.po | 6 +++--- po/zh_CN.po | 4 ++-- sha1_name.c | 6 +++--- t/t9300-fast-import.sh | 6 +++--- 23 files changed, 63 insertions(+), 63 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index ec57a15..1ccec22 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -170,8 +170,8 @@ advice.*:: pushNeedsForce:: Shown when linkgit:git-push[1] rejects an update that tries to overwrite a remote ref that points at an - object that is not a committish, or make the remote - ref point at an object that is not a committish. + object that is not a commit-ish, or make the remote + ref point at an object that is not a commit-ish. statusHints:: Show directions on how to proceed from the current state in the output of linkgit:git-status[1], in diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt index 9439cd6..d20ca40 100644 --- a/Documentation/git-describe.txt +++ b/Documentation/git-describe.txt @@ -9,7 +9,7 @@ git-describe - Show the most recent tag that is reachable from a commit SYNOPSIS [verse] -'git describe' [--all] [--tags] [--contains] [--abbrev=n] committish... +'git describe' [--all] [--tags] [--contains] [--abbrev=n] commit-ish... 'git describe' [--all] [--tags] [--contains] [--abbrev=n] --dirty[=mark] DESCRIPTION @@ -26,8 +26,8 @@ see the -a and -s options to linkgit:git-tag[1]. OPTIONS --- -committish...:: - Committish object names to describe. +commit-ish...:: + Commit-ish object names to describe. --dirty[=mark]:: Describe the working tree. @@ -57,7 +57,7 @@ OPTIONS --candidates=n:: Instead of considering only the 10 most recent tags as - candidates to describe the input committish consider + candidates to describe the input commit-ish consider up to n candidates. Increasing n above 10 will take slightly longer but may produce a more accurate result. An n of 0 will cause only exact matches to be output. @@ -145,7 +145,7 @@ be sufficient to disambiguate these commits. SEARCH STRATEGY --- -For each committish supplied, 'git describe' will first look for +For each commit-ish supplied, 'git describe' will first look for a tag which tags exactly that commit. Annotated tags will always be preferred over lightweight tags, and tags with newer dates will always be preferred over tags with older dates. If an exact match @@ -154,12 +154,12 @@ is found, its name will be output and searching will stop. If an exact match was not found, 'git describe' will walk back through the commit history to locate an ancestor commit which has been tagged. The ancestor's tag will be output along with an -abbreviation of the input committish's SHA-1. If '--first-parent' was +abbreviation of the input commit-ish's SHA-1. If '--first-parent' was specified then the walk will only consider the first parent of each commit. If multiple tags were found during the walk then the tag which -has the fewest commits different from the input committish will be +has the fewest commits different from the input commit-ish will be selected and output. Here fewest commits different is defined as the number of commits which would be shown by `git log tag..input` will be the
[PATCH v3 3/7] use 'tree-ish' instead of 'treeish'
Replace 'treeish' in documentation and comments with 'tree-ish' to
match gitglossary(7).
The only remaining instances of 'treeish' are:
* variable, function, and macro names
* (also treeish) in the definition of tree-ish in gitglossary(7)
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/RelNotes/1.7.11.2.txt | 2 +-
Documentation/git-cat-file.txt | 2 +-
Documentation/git-merge-tree.txt| 2 +-
fast-import.c | 4 ++--
git-cvsserver.perl | 2 +-
test-match-trees.c | 4 ++--
6 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/RelNotes/1.7.11.2.txt
b/Documentation/RelNotes/1.7.11.2.txt
index a0d24d1..f0cfd02 100644
--- a/Documentation/RelNotes/1.7.11.2.txt
+++ b/Documentation/RelNotes/1.7.11.2.txt
@@ -31,7 +31,7 @@ Fixes since v1.7.11.1
* git diff --no-index did not work with pagers correctly.
* git diff COPYING HEAD:COPYING gave a nonsense error message that
- claimed that the treeish HEAD did not have COPYING in it.
+ claimed that the tree-ish HEAD did not have COPYING in it.
* When git log gets --simplify-merges/by-decoration together with
--first-parent, the combination of these options makes the
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
index 10fbc6a..e468ceb 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-file.txt
@@ -54,7 +54,7 @@ OPTIONS
--textconv::
Show the content as transformed by a textconv filter. In this case,
- object has be of the form treeish:path, or :path in order
+ object has be of the form tree-ish:path, or :path in order
to apply the filter to the content recorded in the index at path.
--batch::
diff --git a/Documentation/git-merge-tree.txt b/Documentation/git-merge-tree.txt
index c5f84b6..58731c1 100644
--- a/Documentation/git-merge-tree.txt
+++ b/Documentation/git-merge-tree.txt
@@ -13,7 +13,7 @@ SYNOPSIS
DESCRIPTION
---
-Reads three treeish, and output trivial merge results and
+Reads three tree-ish, and output trivial merge results and
conflicting stages to the standard output. This is similar to
what three-way 'git read-tree -m' does, but instead of storing the
results in the index, the command outputs the entries to the
diff --git a/fast-import.c b/fast-import.c
index 23f625f..019be11 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2957,7 +2957,7 @@ static struct object_entry *dereference(struct
object_entry *oe,
case OBJ_TAG:
break;
default:
- die(Not a treeish: %s, command_buf.buf);
+ die(Not a tree-ish: %s, command_buf.buf);
}
if (oe-pack_id != MAX_PACK_ID) { /* in a pack being written */
@@ -3041,7 +3041,7 @@ static void parse_ls(struct branch *b)
struct tree_entry *root = NULL;
struct tree_entry leaf = {NULL};
- /* ls SP (treeish SP)? path */
+ /* ls SP (tree-ish SP)? path */
p = command_buf.buf + strlen(ls );
if (*p == '') {
if (!b)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index a0d796e..a9f6f8e 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -4338,7 +4338,7 @@ sub getAnyHead
=head2 getRevisionDirMap
A revision dir map contains all the plain-file filenames associated
-with a particular revision (treeish), organized by directory:
+with a particular revision (tree-ish), organized by directory:
$type = $out-{$dir}{$fullName}
diff --git a/test-match-trees.c b/test-match-trees.c
index a3c4688..2ef725e 100644
--- a/test-match-trees.c
+++ b/test-match-trees.c
@@ -12,10 +12,10 @@ int main(int ac, char **av)
die(cannot parse %s as an object name, av[2]);
one = parse_tree_indirect(hash1);
if (!one)
- die(not a treeish %s, av[1]);
+ die(not a tree-ish %s, av[1]);
two = parse_tree_indirect(hash2);
if (!two)
- die(not a treeish %s, av[2]);
+ die(not a tree-ish %s, av[2]);
shift_tree(one-object.sha1, two-object.sha1, shifted, -1);
printf(shifted: %s\n, sha1_to_hex(shifted));
--
1.8.4
--
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/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
Jeff King p...@peff.net writes: On Wed, Sep 04, 2013 at 10:38:03AM -0700, Junio C Hamano wrote: This is way off tangent, but I am somewhat sympathetic to Felipe's compare actual with expect, with reservations. This isn't an argument either way, but note that JUnit (and NUnit and PHPUnit) all have assertEquals methods that take the arguments in the order expect, actual. I've always assumed that Git's test framework was imitating that,... No. See 82ebb0b6 (add test_cmp function for test scripts, 2008-03-12). The test_cmp was a replacement for diff -u, and the same order we fed diff -u, i.e. expect then actual, was carried over. I don't think it was intentional at the time. I do not think so, either. The only thing we cared about was are they equal. And from the point of view of test_cmp exit status, that still the only thing we care about. Comparison to see which is greater is a superset of equality check we needed, and in that context, the order did not and does not matter. One only starts to notice the order of comparison when one starts thinking about the comparison in terms of what is subtracted from what, and at that point, one realizes that diff A B that gives us what was lost from A to B as - and what was gained in B relative to A as + is showing the result of subtracting A from B. And that subtraction is backwards from the cmp(A,B) that subtracts B from A, which is the usual convention. Though I prefer the current, I can certainly live and adapt to a changed standard, and I do not mind doing so if there is a good reason. But I've yet to see any argument beyond it is not what I like. Which to me argues for the status quo as the path of least resistance. As I think test_cmp is primarily about equality comparison, I do not think it is worth switching and adapting. Switching makes sense only in my dreams where we did not have to worry about in-flight topics and people's brains that are used to the current order. That is exactly where my with reservations came from. -- 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 v4 7/8] update-ref: support multiple simultaneous updates
Brad King brad.k...@kitware.com writes:
+static void update_refs_stdin_read_n()
+{
+ struct strbuf line = STRBUF_INIT;
+
+ while (strbuf_getline(line, stdin, '\n') != EOF)
+ update_refs_stdin_parse_line(line.buf);
+
+ strbuf_release(line);
+}
+
+static void update_refs_stdin_read_z()
+{
These need to be defined with explicit (void) argument list.
static void foo(void)
{
...
--
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 v4 7/8] update-ref: support multiple simultaneous updates
On 09/04/2013 03:17 PM, Junio C Hamano wrote: Brad King brad.k...@kitware.com writes: +static void update_refs_stdin_read_n() +static void update_refs_stdin_read_z() These need to be defined with explicit (void) argument list. Oops, fixed. Thanks, -Brad -- 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 (Sep 2013, #01; Tue, 3)
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: * mm/status-without-comment-char (2013-08-29) 5 commits - status: introduce status.displayCommentChar to disable display of # - SQUASH: do not fprintf() random strings - get rid of git submodule summary --for-status - wt-status: use argv_array API - builtin/stripspace.c: fix broken indentation Allow git status to omit the prefix to make its output a comment in a commit log editor, which is not necessary for human consumption. I'm waiting for the situation of git submodule --for-status to be settled to send a reroll. Don't merge this for now, and let bc/submodule-status-ignored converge. Thanks. I had an impression that bc/submodule-status-ignored was still being discussed. Has what I have in 'pu' settled? -- 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 v3 2/2] submodule: don't print status output with ignore=all
Am 03.09.2013 21:53, schrieb Junio C Hamano: Jens, I see 1/2 is the same as the previous one you already acked. Yep. Does this update to 2/2 look good to you? Sorry, but I lost track of the discussion that led to this reroll, hence a ping. v3 fixes the bug Matthieu noticed, I only had some remarks to the new test Brian added. If you could replace his patch to t7401 with the following diff it's an ack from me on this one too. -8--- diff --git a/t/t7401-submodule-summary.sh b/t/t7401-submodule-summary.sh index ac2434c..81ae7c9 100755 --- a/t/t7401-submodule-summary.sh +++ b/t/t7401-submodule-summary.sh @@ -104,6 +104,24 @@ EOF test_cmp expected actual +test_expect_success 'no ignore=all setting has any effect' + git config -f .gitmodules submodule.sm1.path sm1 + git config -f .gitmodules submodule.sm1.ignore all + git config submodule.sm1.ignore all + git config diff.ignoreSubmodules all + git submodule summary actual + cat expected -EOF +* sm1 $head1...$head2 (1): + Add foo3 + +EOF + test_cmp expected actual + git config --unset diff.ignoreSubmodules + git config --remove-section submodule.sm1 + git config -f .gitmodules --remove-section submodule.sm1 + + + commit_file sm1 head3=$( cd sm1 -- 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 v4 7/8] update-ref: support multiple simultaneous updates
On 09/04/2013 02:23 PM, Junio C Hamano wrote: whitespace-separated implies that we may allow fields separated with not a single SP, but with double SPs or even HTs between them. I personally do not think we should be so loose Okay, I will look at making it more strict. See proposed format below. +Quote arguments containing whitespace as if in C source code. Probably as if they were strings in C source code. Fixed. +terminate each argument by NUL and each line by LF NUL. This is a somewhat interesting choice of the record terminator. Do we have a precedent to use LF NUL elsewhere? If this is the first such case where we need to express variable number of NUL-separated fields in a record, I think I am fine with LF NUL (but I am sure other people would give us a better convention if we ask them politely ;-)), but I just want to make sure we do it the same way as other codepaths, if exist, that have to handle this kind of thing. Nothing else uses LF NUL. I chose it as a starting point for this very discussion, which I asked about in $gmane/233653. In this particular use case we know the last field will never be LF but that may not be so for future cases. There is no way to represent sentinel-terminated arbitrary variable-width records of NUL-terminated fields without some kind of escaping for the sentinel value, but the whole point of -z is to avoid escaping. Below is a survey of all mentions of NUL and \0 in documented formats as of v1.8.4. The summary is that most are fixed-width records but a few have variable width allowing n or n+1 fields. In all variable-width cases there is structured information in the first field that indicates the number of NUL-terminated fields to expect. In the motivating case here, we could use a --no-old or --have-old option to indicate in one field how many more to expect in the record, but that will be quite verbose. Side note: I'd like to reserve room for the leading options to include things like -m NUL reason NUL so we cannot keep them all in in a single NUL-terminated, SP-separated field. Another approach is to introduce a way to represent not here for the oldvalue argument that is not an otherwise valid value. This would make the non-option part of the record have a fixed width of 3 fields. For example, we could use SP in -z mode: [-opt NUL]... ref NUL new NUL (old|SP) NUL and the last field can be optional in non-z mode anyway: [-opt SP]... ref SP new [SP old] LF Or we could use a character like ~ (other ideas?): [-opt NUL]... ref NUL new NUL (old|~) NUL and make it available in non-z mode too: [-opt SP]... ref SP new [SP (old|~)] LF Thoughts? -Brad Survey of NUL in documented formats: * Documentation/diff-format.txt: The -z mode for --numstat prints NUL-terminated lines but there is exactly one path at the end of each entry and the earlier fields are separated by TAB because they are structured. * Documentation/diff-options.txt: The -z mode for diff-tree output prints structured SP/TAB-separated fields in a NUL-terminated field followed by either one or two NUL-terminated paths. This is variable width but the first field tells us how wide. * Documentation/git-apply.txt: The -z mode forwards to --numstat diff options. * Documentation/git-check-attr.txt: The -z mode for stdin reads NUL-terminated paths. * Documentation/git-check-ignore.txt: The -z mode for stdin reads NUL-terminated paths. The -z mode for output prints a fixed-width table with every group of four NUL-terminated fields forming a row. * Documentation/git-checkout-index.txt: The -z mode reads NUL-terminated paths. * Documentation/git-commit.txt: The -z mode forwards to git-status. * Documentation/git-grep.txt: The -z mode separates file names from the matched line by a NUL. Therefore NUL divides LF-terminated lines into two pieces. * Documentation/git-ls-files.txt: The -z mode prints NUL-terminated lines but there is exactly one path at the end of each entry and the earlier fields are separated by SP and TAB because they are structured. * Documentation/git-ls-tree.txt: The -z mode prints NUL-terminated lines but there is exactly one path at the end of each entry and the earlier fields are separated by SP and TAB because they are structured. * Documentation/git-mktree.txt: The -z mode reads NUL-terminated lines as output by ls-tree -z. * Documentation/git-status.txt: The -z mode of --porcelain separates a variable number of entries by NUL. The beginning of each entry allows one to know the number of NUL-terminated fields to expect (A = 1 total NUL, R = 2 total NULs, etc.). * Documentation/git-update-index.txt: The -z mode of --stdin separates paths by NUL. The -z mode of --index-info separates entries by NUL but there is exactly one path at the end of each entry and the earlier fields are separated by SP and TAB
Re: [PATCH v4 03/11] t6050-replace: test that objects are of the same type
Christian Couder chrisc...@tuxfamily.org writes:
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
t/t6050-replace.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index decdc33..5c352c4 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -263,4 +263,17 @@ test_expect_success 'not just commits' '
test_cmp file.replaced file
'
+test_expect_success 'replaced and replacement objects must be of the same
type' '
+ test_must_fail git replace mytag $HASH1 2err
+ grep mytag. points to a replaced object of type .tag err
+ grep $HASH1. points to a replacement object of type .commit err
Hmm, would these messages ever get translated? I think it is
sufficient to make sure that the proposed replacement fails for
these cases.
+ test_must_fail git replace HEAD^{tree} HEAD~1 2err
+ grep HEAD^{tree}. points to a replaced object of type .tree err
+ grep HEAD~1. points to a replacement object of type .commit err
+ BLOB=$(git rev-parse :file)
+ test_must_fail git replace HEAD^ $BLOB 2err
+ grep HEAD^. points to a replaced object of type .commit err
+ grep $BLOB. points to a replacement object of type .blob err
+'
+
test_done
--
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 v3 2/2] submodule: don't print status output with ignore=all
Jens Lehmann jens.lehm...@web.de writes: Am 03.09.2013 21:53, schrieb Junio C Hamano: Jens, I see 1/2 is the same as the previous one you already acked. Yep. Does this update to 2/2 look good to you? Sorry, but I lost track of the discussion that led to this reroll, hence a ping. v3 fixes the bug Matthieu noticed, I only had some remarks to the new test Brian added. If you could replace his patch to t7401 with the following diff it's an ack from me on this one too. -8--- diff --git a/t/t7401-submodule-summary.sh b/t/t7401-submodule-summary.sh index ac2434c..81ae7c9 100755 --- a/t/t7401-submodule-summary.sh +++ b/t/t7401-submodule-summary.sh @@ -104,6 +104,24 @@ EOF test_cmp expected actual +test_expect_success 'no ignore=all setting has any effect' + git config -f .gitmodules submodule.sm1.path sm1 + git config -f .gitmodules submodule.sm1.ignore all + git config submodule.sm1.ignore all + git config diff.ignoreSubmodules all + git submodule summary actual + cat expected -EOF +* sm1 $head1...$head2 (1): + Add foo3 + +EOF + test_cmp expected actual + git config --unset diff.ignoreSubmodules + git config --remove-section submodule.sm1 + git config -f .gitmodules --remove-section submodule.sm1 + + + commit_file sm1 head3=$( cd sm1 Thanks. The above patch makes the -EOF situation that already exists in this script worse. The only reason we would say -EOF not EOF is because we would want to indent the here-document to align with the rest of the command sequence, so we should either indent with HT, or drop the dash. I suspect the original did it that way fearing that someday the indentation of the submodule difference list might start using HT, but I do not think that is likely to happen, so my vote goes to keeping '-' and indenting. We need a clean-up patch after this series settles. -- 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 v4 07/11] Documentation/replace: tell that -f option bypasses the type check
Christian Couder chrisc...@tuxfamily.org writes: Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Documentation/git-replace.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index 736b48c..a2bd2ee 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -21,10 +21,12 @@ replaced. The content of the 'replace' reference is the SHA-1 of the replacement object. The replaced object and the replacement object must be of the same type. -There is no other restriction on them. +This restriction can be bypassed using `-f`. Unless `-f` is given, the 'replace' reference must not yet exist. +There is no other restriction on the replaced and replacement objects. + This is outside the scope of this topic, but I wonder if we want to restrict a replacement operation that causes a cycle in the object graph (a commit reaches itself after following its parent pointer, a tree reaches itself after looking into trees within, a tag reaches itself after following its object reference), and if we do want it, it is feasible to implement it. Replacement references will be used by default by all Git commands except those doing reachability traversal (prune, pack transfer and fsck). -- 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 (Sep 2013, #01; Tue, 3)
Am 04.09.2013 21:19, schrieb Junio C Hamano: Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: * mm/status-without-comment-char (2013-08-29) 5 commits - status: introduce status.displayCommentChar to disable display of # - SQUASH: do not fprintf() random strings - get rid of git submodule summary --for-status - wt-status: use argv_array API - builtin/stripspace.c: fix broken indentation Allow git status to omit the prefix to make its output a comment in a commit log editor, which is not necessary for human consumption. I'm waiting for the situation of git submodule --for-status to be settled to send a reroll. Don't merge this for now, and let bc/submodule-status-ignored converge. Thanks. I had an impression that bc/submodule-status-ignored was still being discussed. Has what I have in 'pu' settled? Almost (see my other mail concerning bc/submodule-status-ignored). If the removal of the --for-status option is reverted from patch #3 here (which I outlined in $gmane/233764) this series can be merged without really depending on bc/submodule-status-ignored (even though the temporarily unused --for-status option may look a bit strange until the latter is merged). -- 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 v4 06/11] replace: bypass the type check if -f option is used
Christian Couder chrisc...@tuxfamily.org writes: If -f option, which means '--force', is used, we can allow an object to be replaced with one of a different type, as the user should know what (s)he is doing. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- This does not matter in a larger picture, but between 1/11 and this patch, there is a window where an operation that has been useful in some workflows becomes unavailable to the user. For future reference, it would be better to do this as a part of 1/11, to make sure that there always is an escape hatch available to the users. builtin/replace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/replace.c b/builtin/replace.c index 9a94769..95736d9 100644 --- a/builtin/replace.c +++ b/builtin/replace.c @@ -103,7 +103,7 @@ static int replace_object(const char *object_ref, const char *replace_ref, obj_type = sha1_object_info(object, NULL); repl_type = sha1_object_info(repl, NULL); - if (obj_type != repl_type) + if (!force obj_type != repl_type) die(Objects must be of the same type.\n '%s' points to a replaced object of type '%s'\n while '%s' points to a replacement object of type '%s'., -- 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 v3 2/2] submodule: don't print status output with ignore=all
Am 04.09.2013 08:31, schrieb Matthieu Moy: brian m. carlson sand...@crustytoothpaste.net writes: Tests are included which verify that this change has no effect on git submodule summary without the --for-status option. I still don't understand why this is needed. To avoid a change in behavior for git submodule summary, as that never honored the submodule.*.ignore nor the diff.ignoreSubmodules setting (and I don't think it ever should). Why do we want git status and git submodule summary to display different information? Wasn't it a nice property that the part of git status about submodule is the same as git submodule summary? I changed that in 2010 (1.7.3) to make the output of status consistent, meaning that submodules that didn't show up in the regular status output don't appear in the summary part either. And I still believe it is the right thing to do for the target audience of the ignore settings, as they want to hide any changes in submodules that are either expensive to traverse or uninteresting for the developer until they explicitly use the submodule commands, which still behave as they always did (I might be wrong here as I'm not in that group myself, but so far no one spoke up). This should at least be explained in the commit message IMHO. Fine by me, what would you propose to clarify that? (Though I have the suspicion that the explanation will be three years late ;-) -- 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 v4 10/11] Documentation/replace: list long option names
Christian Couder chrisc...@tuxfamily.org writes: Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Documentation/git-replace.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index a2bd2ee..414000e 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -54,13 +54,16 @@ achieve the same effect as the `--no-replace-objects` option. OPTIONS --- -f:: +--force:: If an existing replace ref for the same object exists, it will be overwritten (instead of failing). -d:: +--delete:: Delete existing replace refs for the given objects. -l pattern:: +--list pattern:: List replace refs for objects that match the given pattern (or all if no pattern is given). Typing git replace without arguments, also lists all replace This should be in the same commit as what adds them. -- 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 v4 07/11] Documentation/replace: tell that -f option bypasses the type check
Christian Couder chrisc...@tuxfamily.org writes: Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Documentation/git-replace.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index 736b48c..a2bd2ee 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -21,10 +21,12 @@ replaced. The content of the 'replace' reference is the SHA-1 of the replacement object. The replaced object and the replacement object must be of the same type. -There is no other restriction on them. +This restriction can be bypassed using `-f`. Unless `-f` is given, the 'replace' reference must not yet exist. +There is no other restriction on the replaced and replacement objects. + Replacement references will be used by default by all Git commands except those doing reachability traversal (prune, pack transfer and fsck). And this should be in the same patch as the one that makes the code change. -- 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 v3 2/2] submodule: don't print status output with ignore=all
Am 04.09.2013 22:57, schrieb Junio C Hamano: Jens Lehmann jens.lehm...@web.de writes: Am 03.09.2013 21:53, schrieb Junio C Hamano: Does this update to 2/2 look good to you? Sorry, but I lost track of the discussion that led to this reroll, hence a ping. v3 fixes the bug Matthieu noticed, I only had some remarks to the new test Brian added. If you could replace his patch to t7401 with the following diff it's an ack from me on this one too. -8--- diff --git a/t/t7401-submodule-summary.sh b/t/t7401-submodule-summary.sh index ac2434c..81ae7c9 100755 --- a/t/t7401-submodule-summary.sh +++ b/t/t7401-submodule-summary.sh @@ -104,6 +104,24 @@ EOF test_cmp expected actual +test_expect_success 'no ignore=all setting has any effect' +git config -f .gitmodules submodule.sm1.path sm1 +git config -f .gitmodules submodule.sm1.ignore all +git config submodule.sm1.ignore all +git config diff.ignoreSubmodules all +git submodule summary actual +cat expected -EOF +* sm1 $head1...$head2 (1): + Add foo3 + +EOF +test_cmp expected actual +git config --unset diff.ignoreSubmodules +git config --remove-section submodule.sm1 +git config -f .gitmodules --remove-section submodule.sm1 + + + commit_file sm1 head3=$( cd sm1 Thanks. The above patch makes the -EOF situation that already exists in this script worse. The only reason we would say -EOF not EOF is because we would want to indent the here-document to align with the rest of the command sequence, so we should either indent with HT, or drop the dash. I suspect the original did it that way fearing that someday the indentation of the submodule difference list might start using HT, but I do not think that is likely to happen, so my vote goes to keeping '-' and indenting. We need a clean-up patch after this series settles. Ok, will do (unless someone else volunteers ;-). -- 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 v4 7/8] update-ref: support multiple simultaneous updates
Brad King brad.k...@kitware.com writes: Nothing else uses LF NUL. I chose it as a starting point for this very discussion, which I asked about in $gmane/233653. The primary reason why LF raised my eyebrow was because the reason why many subcommands use -z (and NUL) is often because the payload may have LF in a record and LF cannot be used as a record separator without escaping. And they use NUL knowing that the payload data in fields cannot contain a NUL. If we used LF as a signal to define the structure of the record, it pretty much defeats the whole point of defining -z format. The -m reason string will be made into a single liner deep in the codepath but it _can_ contain LF. I would have been more receptive to, say, double-NUL as a record terminator, while using a NUL as a field terminator, or something, but then we would need to have a way to express an empty field. In this particular use case we know the last field will never be LF but that may not be so for future cases. There is no way to represent sentinel-terminated arbitrary variable-width records of NUL-terminated fields without some kind of escaping for the sentinel value, but the whole point of -z is to avoid escaping. Indeed, but one escape hatch we have is that payload will not contain NUL anywhere, so whenever we see a NUL, we can trust that it defines the structure of the record, and is not a part of the payload. Stepping back a bit, here are some observations on the arguments update-ref can take: * -m reason is a reason given for this entire update. As the point of this new feature is to give an all-or-none update to one or more refs, I think we should not have to accept more than one reason (more specifically, the -m option does _not_ belong to a specific record that describes what happens to a single ref). * -d ref oldvalue is a way to delete a ref. oldvalue may be missing. * --no-deref ref newvalue oldvalue and ref newvalue oldvalue are ways to update or create a ref. Again oldvalue may be missing. So it looks to me that one possible format that is easy to generate by machine without ambiguity may be: * The first record could be m NUL reason strong NUL but it is optional. The reason string may contain LF but just like invocation from the command line, LF will eventually cleaned up into a SP. * Then a series of records of different kinds follow. - A delete record looks like this: d NUL ref NUL oldvalue NUL If you want to delete the ref without oldvalue protection, just say d NUL ref NUL NUL - A create/update record looks like one of these: u NUL ref NUL newvalue NUL oldvalue NUL n NUL ref NUL newvalue NUL oldvalue NUL Again, if you want to delete the ref without oldvalue protection, just say u NUL ref NUL newvalue NUL NUL n NUL ref NUL newvalue NUL NUL * EOF signals the end of the request. I am not saying the above is the best format, but the point is that the mode of the operation defines the structure, so unlike parsing xml or json where you first parse the structure and then interpret what each element means, you can define a simple format where the kind of element comes upfront to allow the parser/interpreter know what is expected to follow it. -- 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] Reject non-ff pulls by default
From: Junio C Hamano gits...@pobox.com John Keeping j...@keeping.me.uk writes: I think there are two distinct uses for pull, which boil down to: (1) git pull (2) git pull $remote $branch For (1) a merge is almost always the wrong thing to do since it will be backwards and break --first-parent. But for (2) a merge is almost always the correct thing to do (in fact it may even be correct to create a merge commit even when this fast forwards) because this most likely comes for a pull request workflow. Peff already covered (1)---it is highly doubtful that a merge is almost always wrong. In fact, if that _were_ the case, we should simply be defaulting to rebase, not failing the command and asking between merge and rebase like jc/pull-training-wheel topic did. We simply do not know what the user wants, as it heavily depends on the project, so we ask the user to choose one (and stick to it). We only offer a limited list. It won't be sufficient for all use cases. It wasn't for me. The ability to say 'stop' if it doen't match expectations, as the --no-ff option would give, would be a help, as the user can then decide what to do (read the manual or `google` the problem perhaps ;-). the option of having a hook (if suggested), while suitable for advanced users won't help those that need that help, rather a few simple safe options are needed. I generally support the ability to set an option to reject non-ff pulls. I am not sure about (2), either. Is it really almost always the correct thing to do? I tend to think myself that (2) is a lot more likely to prefer merging than (1) would, but I certainly wouldn't say almost always. Again if almost always were the case, wouldn't it make sense for that mode of invocation of the command to even defeat pull.rebase configuration and default to merge, unless explicitly told to pull --rebase from the command line? (the last question is rhetoric, if anybody is wondering). -- 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 v3 0/7] documentation cleanups for rev^{type}
Richard Hansen rhan...@bbn.com writes:
On 2013-09-03 18:46, Junio C Hamano wrote:
I hate to say this after seeing you doing a thorough job in this
series, but because tree-ish and commit-ish are both made-up
words, I have a feeling that we are better off unifying to the
dashed form, which unfortunately is the other way around from what
your series does.
I thought you might say that so I held on to the commits that
standardize on tree-ish and commit-ish in my local repo. :)
This series still says tree-ish (also treeish) and commit-ish (also
committish) in gitglossary(7). Would you like me to eliminate the
(also ...) part?
I'm not 100% confident that these don't break translations, although
it still builds and make test passes.
We will find out ;-)
Changes since v2:
* standardize on 'tree-ish' instead of 'treeish'
* standardize on 'commit-ish' instead of 'committish'
Richard Hansen (7):
glossary: mention 'treeish' as an alternative to 'tree-ish'
glossary: define commit-ish (a.k.a. committish)
use 'tree-ish' instead of 'treeish'
use 'commit-ish' instead of 'committish'
glossary: more precise definition of tree-ish (a.k.a. treeish)
revisions.txt: fix and clarify rev^{type}
glossary: fix and clarify the definition of 'ref'
Documentation/RelNotes/1.7.11.2.txt | 2 +-
Documentation/howto/revert-branch-rebase.txt | 2 +-
I generally prefer not to touch historical documents but the change
in this series is small enough that I think it is OK.
Thanks, will queue.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
typofix: commit is spelled with two ems
There are a handful of instances where we say commmit when we mean commit. Fix them. Signed-off-by: Junio C Hamano gits...@pobox.com --- notes-utils.h | 2 +- t/t3509-cherry-pick-merge-df.sh | 2 +- t/t6022-merge-rename.sh | 14 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/notes-utils.h b/notes-utils.h index b4cb1bf..564e30c 100644 --- a/notes-utils.h +++ b/notes-utils.h @@ -9,7 +9,7 @@ * Properties of the created commit: * - tree: the result of converting t to a tree object with write_notes_tree(). * - parents: the given parents OR (if NULL) the commit referenced by t-ref. - * - author/committer: the default determined by commmit_tree(). + * - author/committer: the default determined by commit_tree(). * - commit message: msg * * The resulting commit SHA1 is stored in result_sha1. diff --git a/t/t3509-cherry-pick-merge-df.sh b/t/t3509-cherry-pick-merge-df.sh index a5b6a5f..1e5b394 100755 --- a/t/t3509-cherry-pick-merge-df.sh +++ b/t/t3509-cherry-pick-merge-df.sh @@ -74,7 +74,7 @@ test_expect_success 'Setup rename with file on one side matching different dirna echo content sub/file echo foo othersub/whatever git add -A - git commit -m Common commmit + git commit -m Common commit git rm -rf othersub git mv sub/file othersub diff --git a/t/t6022-merge-rename.sh b/t/t6022-merge-rename.sh index c680f78..a89dfbe 100755 --- a/t/t6022-merge-rename.sh +++ b/t/t6022-merge-rename.sh @@ -259,7 +259,7 @@ test_expect_success 'setup for rename + d/f conflicts' ' printf 1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n sub/file echo foo dir/file-in-the-way git add -A - git commit -m Common commmit + git commit -m Common commit echo 11 sub/file echo more dir/file-in-the-way @@ -439,7 +439,7 @@ test_expect_success 'setup both rename source and destination involved in D/F co mkdir one echo stuff one/file git add -A - git commit -m Common commmit + git commit -m Common commit git mv one/file destdir git commit -m Renamed to destdir @@ -479,7 +479,7 @@ test_expect_success 'setup pair rename to parent of other (D/F conflicts)' ' echo stuff one/file echo other two/file git add -A - git commit -m Common commmit + git commit -m Common commit git rm -rf one git mv two/file one @@ -539,7 +539,7 @@ test_expect_success 'setup rename of one file to two, with directories in the wa echo stuff original git add -A - git commit -m Common commmit + git commit -m Common commit mkdir two two/file @@ -583,7 +583,7 @@ test_expect_success 'setup rename one file to two; directories moving out of the mkdir one two touch one/file two/file git add -A - git commit -m Common commmit + git commit -m Common commit git rm -rf one git mv original one @@ -618,7 +618,7 @@ test_expect_success 'setup avoid unnecessary update, normal rename' ' printf 1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n original git add -A - git commit -m Common commmit + git commit -m Common commit git mv original rename echo 11 rename @@ -649,7 +649,7 @@ test_expect_success 'setup to test avoiding unnecessary update, with D/F conflic mkdir df printf 1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n df/file git add -A - git commit -m Common commmit + git commit -m Common commit git mv df/file temp rm -rf df -- 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: Get back to me
i have a business proposal for you, write me back for more info. -Sent from my ipad. -- 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] add--interactive: fix external command invocation on Windows
From: Johannes Sixt j...@kdbg.org
Back in 21e9757e (Hack git-add--interactive to make it work with
ActiveState Perl, 2007-08-01), the invocation of external commands was
changed to use qx{} on Windows. The rationale was that the command
interpreter on Windows is not a POSIX shell, but rather Windows's CMD.
That patch was wrong to include 'msys' in the check whether to use qx{}
or not: 'msys' identifies MSYS perl as shipped with Git for Windows,
which does not need the special treatment; qx{} should be used only with
ActiveState perl, which is identified by 'MSWin32'.
Signed-off-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
git-add--interactive.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 75a991f..5156384 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -169,7 +169,7 @@ my %patch_modes = (
my %patch_mode_flavour = %{$patch_modes{stage}};
sub run_cmd_pipe {
- if ($^O eq 'MSWin32' || $^O eq 'msys') {
+ if ($^O eq 'MSWin32') {
my @invalid = grep {m/[:*]/} @_;
die $^O does not support: @invalid\n if @invalid;
my @args = map { m/ /o ? \$_\: $_ } @_;
--
1.8.2.83.gc99314b
--
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] pathspec: catch prepending :(prefix) on pathspec with short magic
:(prefix) is in the long form. Suppose people pass :!foo with '!'
being the short form of magic 'bar', the code will happily turn it to
:(prefix..)!foo, which makes '!' part of the path and no longer a magic.
The correct form must be ':(prefix..,bar)foo', but as so far we
haven't had any magic in short form yet (*), the code to convert from
short form to long one will be inactive anyway. Let's postpone it
until a real short form magic appears.
(*) The short form magic '/' is a special case and won't be caught by
this die(), which is correct. When '/' magic is detected, prefixlen is
set back to 0 and the whole if (prefixlen..) block is skipped.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
fixes on top of nd/magic-pathspec.
pathspec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/pathspec.c b/pathspec.c
index d9f4143..62fde50 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -231,7 +231,9 @@ static unsigned prefix_pathspec(struct pathspec_item *item,
const char *start = elt;
if (prefixlen !literal_global) {
/* Preserve the actual prefix length of each pattern */
- if (long_magic_end) {
+ if (short_magic)
+ die(BUG: prefixing on short magic is not
supported);
+ else if (long_magic_end) {
strbuf_add(sb, start, long_magic_end - start);
strbuf_addf(sb, ,prefix:%d, prefixlen);
start = long_magic_end;
--
1.8.2.83.gc99314b
--
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] add: lift the pathspec magic restriction on add -p
Since 480ca64 (convert run_add_interactive to use struct pathspec -
2013-07-14), we have unconditionally passed :(prefix)xxx to
add-interactive.perl. It implies that all commands
add-interactive.perl calls must be aware of pathspec magic, or
:(prefix) is barfed. The restriction to :/ only becomes unnecessary.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/add.c | 8 +---
builtin/checkout.c | 7 ---
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index 9d52fc7..b4035f6 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -270,13 +270,7 @@ int interactive_add(int argc, const char **argv, const
char *prefix, int patch)
{
struct pathspec pathspec;
- /*
-* git-add--interactive itself does not parse pathspec. It
-* simply passes the pathspec to other builtin commands. Let's
-* hope all of them support all magic, or we'll need to limit
-* the magic here.
-*/
- parse_pathspec(pathspec, PATHSPEC_ALL_MAGIC ~PATHSPEC_FROMTOP,
+ parse_pathspec(pathspec, 0,
PATHSPEC_PREFER_FULL |
PATHSPEC_SYMLINK_LEADING_PATH |
PATHSPEC_PREFIX_ORIGIN,
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 7ea1100..b235e04 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1149,13 +1149,6 @@ int cmd_checkout(int argc, const char **argv, const char
*prefix)
}
if (argc) {
- /*
-* In patch mode (opts.patch_mode != 0), we pass the
-* pathspec to an external program, git-add--interactive.
-* Do not accept any kind of magic that that program
-* cannot handle. Magic mask is pretty safe to be
-* lifted for new magic when opts.patch_mode == 0.
-*/
parse_pathspec(opts.pathspec, 0,
opts.patch_mode ? PATHSPEC_PREFIX_ORIGIN : 0,
prefix, argv);
--
1.8.2.83.gc99314b
--
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/23] pack v4: commit object encoding
On Tue, 3 Sep 2013, Duy Nguyen wrote: On Tue, Sep 3, 2013 at 1:30 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 3 Sep 2013, Duy Nguyen wrote: On Tue, Aug 27, 2013 at 11:25 AM, Nicolas Pitre n...@fluxnic.net wrote: This goes as follows: - Tree reference: either variable length encoding of the index into the SHA1 table or the literal SHA1 prefixed by 0 (see add_sha1_ref()). - Parent count: variable length encoding of the number of parents. This is normally going to occupy a single byte but doesn't have to. - List of parent references: a list of add_sha1_ref() encoded references, or nothing if the parent count was zero. With .pack v3 it's impossible to create delta cycles (3b910d0 add tests for indexing packs with delta cycles - 2013-08-23) but it is possible with .pack v4 (and therefore at least index-pack needs to detect and reject them), correct? Some malicious user can create commit A with parent ref 1, then make the SHA-1 table so that ref 1 is A. The same with the new tree representation. pack-index should validate the SHA1 of the object being pointed at. In that case I doubt you'll be able to actually construct an object which contains a SHA1 parent reference and make the SHA1 of this very object resolve to the same value. We could do that for commits. For trees, we need to look at the base's content to construct the current tree and cycles could happen. I think we could make a rule that base trees must appear in the pack before the tree being constructed (similar to delta-ofs). The exception is objects appended for fixing thin pack. I don't really like such artificial constraints. You never know when such constraints are going to prevent future legitimate pack layout optimizations or the like. It is simple enough to detect cycles during delta validation in index-pack anyway. Nicolas -- 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] Document pack v4 format
On Tue, 3 Sep 2013, Duy Nguyen wrote: On Tue, Sep 3, 2013 at 6:49 PM, Duy Nguyen pclo...@gmail.com wrote: On Tue, Sep 3, 2013 at 1:46 PM, Nicolas Pitre n...@fluxnic.net wrote: So... looks like pack v4 is now functional. However something is still wrong as it operates about 6 times slower than pack v3. Anyone wishes to investigate? You recurse in decode_entries too deep.I check the first 1 decode_entries() calls in pv4_get_tree(). The deepest level is 3491. And I was wrong, the call depth is not that deep, but the number of decode_entries calls triggered by one pv4_get_tree() is that many. This is on git.git and the tree being processed is t, which has 672 entries.. There are funny access patterns. This is the output of fprintf(stderr, [%d] %d - %d %u\n, call_depth, copy_start, copy_count, copy_objoffset); [1] 0 - 1 48838573 [2] 0 - 1 48826699 [3] 0 - 1 48820760 [4] 0 - 1 48814812 [5] 0 - 1 48805904 [6] 0 - 1 48797000 [7] 0 - 1 48794034 [8] 0 - 1 48791067 [9] 0 - 1 48788100 [10] 0 - 1 48785134 [11] 0 - 1 48776221 [12] 0 - 1 48764321 [13] 0 - 1 48503227 [14] 0 - 1 48485415 [15] 0 - 1 48473512 [16] 0 - 1 48443621 [17] 0 - 1 48401788 [18] 0 - 1 48377834 [19] 0 - 1 48371841 [20] 0 - 1 48341809 [21] 0 - 1 48260734 [22] 0 - 1 48236635 [23] 0 - 1 46845105 [24] 0 - 1 14603061 [25] 2 - 1 48838573 [2] 0 - 1 48826699 It goes through 20+ base trees just to get one tree entry, I think.. Yeah... that's true. The encoding should refer to the deepest tree directly in that case. Better delta heuristics will have to be worked out here. The code as it is now can't do that. There was also a bug that prevented larger copy sequences to be created which is now fixed. I added to packv4-create the ability to specify the minimum range of consecutive entries that can be represented by a copy sequence to allow experiments. However, even when the tree deltas are completely disabled (using --min-tree-copy=0 achieves that) the CPU usage is still much higher which is rather unexpected. In theory this shouldn't be the case. Many other bugs have now been fixed. A git.git repository with packs version 4 appears to be functional and passes git-fsck --full --strict. Nicolas -- 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] Document pack v4 format
On Thu, Sep 5, 2013 at 11:12 AM, Nicolas Pitre n...@fluxnic.net wrote: Many other bugs have now been fixed. A git.git repository with packs version 4 appears to be functional and passes git-fsck --full --strict. Yeah I was looking at the diff some minutes ago, saw changes in pack-check.c and wondering if fsck was working. I'll add v4 support to index-pack. Waiting to see the new, v4-aware tree walker interface with good rev-list --all --objects numbers from you. -- Duy -- 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] Document pack v4 format
On Thu, 5 Sep 2013, Duy Nguyen wrote: On Thu, Sep 5, 2013 at 11:12 AM, Nicolas Pitre n...@fluxnic.net wrote: Many other bugs have now been fixed. A git.git repository with packs version 4 appears to be functional and passes git-fsck --full --strict. Yeah I was looking at the diff some minutes ago, saw changes in pack-check.c and wondering if fsck was working. I'll add v4 support to index-pack. Beware that the tree delta encoding has changed a little. This saved up to 2% on some repos. I'll probably change the encoding to incorporate the escape hatch for path and name references as discussed previously. Waiting to see the new, v4-aware tree walker interface with good rev-list --all --objects numbers from you. Well, unfortunately I've put more time than I really had available into this project lately. I'm about to call for other people to take over it and pursue this work further. I really wanted to set the pack format direction since I've been toying with this for so many years. Now the tool to convert a pack is there, and the read side is also there, proving that the format does work and the encoding and decoding code is functional and may serve as reference. So that's about the extent of what I can contribute at this point. I'll be happy to provide design assistance and code review comments of course. But I won't be able to put the time to do the actual coding myself much longer. Nicolas -- 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] Document pack v4 format
On Thu, Sep 5, 2013 at 11:40 AM, Nicolas Pitre n...@fluxnic.net wrote: On Thu, 5 Sep 2013, Duy Nguyen wrote: On Thu, Sep 5, 2013 at 11:12 AM, Nicolas Pitre n...@fluxnic.net wrote: Many other bugs have now been fixed. A git.git repository with packs version 4 appears to be functional and passes git-fsck --full --strict. Yeah I was looking at the diff some minutes ago, saw changes in pack-check.c and wondering if fsck was working. I'll add v4 support to index-pack. Beware that the tree delta encoding has changed a little. This saved up to 2% on some repos. Thanks for the heads up. I'll probably change the encoding to incorporate the escape hatch for path and name references as discussed previously. Waiting to see the new, v4-aware tree walker interface with good rev-list --all --objects numbers from you. Well, unfortunately I've put more time than I really had available into this project lately. I'm about to call for other people to take over it and pursue this work further. I really wanted to set the pack format direction since I've been toying with this for so many years. Now the tool to convert a pack is there, and the read side is also there, proving that the format does work and the encoding and decoding code is functional and may serve as reference. So that's about the extent of what I can contribute at this point. I'll be happy to provide design assistance and code review comments of course. But I won't be able to put the time to do the actual coding myself much longer. You've done a great job in designing v4 and getting basic support in place. I think you'll need to post your series again so Junio can pick it up. Then we (at least I) will try to continue from there. I have high hopes that this will not drop out like the spit-blob series. -- Duy -- 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
