* Re: [PATCH] branch: borrow --sort and --count from for-each-ref
From: Junio C Hamano @ 2012-01-17 20:12 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1326805907-19416-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Some time ago, I posted a patch that added date sort to git-branch
> and Peff pointed me to for-each-ref. I did not look at it closely.
> Now it does not seem hard to lend some code from for-each-ref to
> git-branch. I can list 10 most recently touched branches with
>
> git branch --sort=-committerdate -v --count=10
>
> kind of cool. I don't think adding --format is necessary because
> git-branch already has its own formatting.
Why do we even need this for "git branch", when "git for-each-ref
refs/heads" already does this?
^ permalink raw reply
* Re: Suggestion: rebase [--onto <newbase>] [<upstream>][..[<branch>]]
From: Junio C Hamano @ 2012-01-17 20:17 UTC (permalink / raw)
To: Hallvard Breien Furuseth; +Cc: git
In-Reply-To: <hbf.20120117gdfh@bombur.uio.no>
Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no> writes:
> I think
> git rebase [--onto <newbase>] [<upstream>][..[<branch>]]
> would be a more readable syntax for what rebase is doing. Easier
> to see which argument means what without staring at the manpage.
> "..[<branch>]" without <upstream> implies --root.
I do not offhand see a huge issue if you come up with a patch that allows
users to additionally say:
$ git rebase upstream..topic
$ git rebase --onto there upstream..topic
what they express with
$ git rebase upstream topic
$ git rebase --onto there upstream topic
today.
However, "git rebase ..topic" to mean "everything down to root from topic"
is not OK; lack of one side in dotted range defaults to HEAD everywhere
else and such a change will introduce a huge discrepancy.
^ permalink raw reply
* [PATCH v2] test-lib: add the test_pause convenience function
From: Jens Lehmann @ 2012-01-17 21:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Git Mailing List, Pete Wyckoff
In-Reply-To: <7vboq2rvhl.fsf@alter.siamese.dyndns.org>
Since 781f76b15 (test-lib: redirect stdin of tests) you can't simply put a
"bash &&" into a test for debugging purposes anymore. Instead you'll have
to use "bash <&6 >&3 2>&4".
As that invocation is not that easy to remember add the test_pause
convenience function. It invokes "$SHELL_PATH" to provide a sane shell
for the user.
This function also checks if the -v flag is given and will error out if
that is not the case instead of letting the test hang until ^D is pressed.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Am 17.01.2012 20:15, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
> What I cared was more about the hardcoded "bash". Believe it or not, there
> are boxes that lack it, and there are people who prefer other shells for
> their interactive work. At the very least, invoke "$SHELL_PATH" instead of
> bash there, perhaps?
Sure, I changed that in this version and explained it in the commit
message.
> If we wanted to allow an ad-hoc debugging of test scripts to sprinkle
> "test_pause $cmd", we might need to do something like:
>
>> +test_pause () {
>> + if test "$verbose" = t; then
>> + bash <&6 >&3 2>&4
> ${1-"$SHELL_PATH"} <&6 >&3 2>&4
>> + else
>> + error >&5 "test_pause requires --verbose"
>> + fi
>> +}
>
> but I do not think that is worth it. The debugging developer should easily
> be able to run gdb or whatever from the interactive shell you are giving
> here.
That's what I always do, so I'm fine with what this patch provides. And
now the fact that you can temporarily pause a test and explore the trash
directory is documented too ;-)
t/README | 13 +++++++++++++
t/test-lib.sh | 13 +++++++++++++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/t/README b/t/README
index c85abaf..c09c582 100644
--- a/t/README
+++ b/t/README
@@ -548,6 +548,19 @@ library for your script to use.
...
'
+ - test_pause
+
+ This command is useful for writing and debugging tests and must be
+ removed before submitting. It halts the execution of the test and
+ spawns a shell in the trash directory. Exit the shell to continue
+ the test. Example:
+
+ test_expect_success 'test' '
+ git do-something >actual &&
+ test_pause &&
+ test_cmp expected actual
+ '
+
Prerequisites
-------------
diff --git a/t/test-lib.sh b/t/test-lib.sh
index a65dfc7..709a300 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -329,6 +329,19 @@ test_tick () {
export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
}
+# Stop execution and start a shell. This is useful for debugging tests and
+# only makes sense together with "-v".
+#
+# Be sure to remove all invocations of this command before submitting.
+
+test_pause () {
+ if test "$verbose" = t; then
+ "$SHELL_PATH" <&6 >&3 2>&4
+ else
+ error >&5 "test_pause requires --verbose"
+ fi
+}
+
# Call test_commit with the arguments "<message> [<file> [<contents>]]"
#
# This will commit a file with the given contents and the given commit
--
1.7.9.rc1.1.g8dae2
^ permalink raw reply related
* Re: Interactive rebase with submodules
From: Jens Lehmann @ 2012-01-17 21:29 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <4F15C22C.3020902@metanate.com>
Am 17.01.2012 19:47, schrieb John Keeping:
> I've encountered a scenario where git rebase --interactive drops a commit which contains a modification to a submodule but no other changes.
>
> This occurs when there is a conflict when applying the commit (for example if the submodule's history has been rewritten and you are rewriting the parent repository to match the new version of the submodule).
>
> To clarify:
>
> git rebase -i
> # Edit a commit, switching submodule to an unrelated commit
> git rebase --continue
> # Conflict in submodule, checkout the correct submodule commit
> git add path/to/submodule
> # Only change in index is updated submodule
> git rebase --continue
> # No commit is created for the submodule change
>
>
> This appears to be because the git-rebase--interactive script inspects whether there is anything to commit when `rebase --continue` is invoked by running:
>
> git diff-index --cached --quiet --ignore-submodules HEAD --
Thanks for pinning that down.
> Is there a reason for the `--ignore-submodules` in this command? Removing that option results in the expected behaviour.
Yes, removing it will help your use case but break others. The reason
for that is that because submodules are not updated during a rebase
it doesn't make sense to compare their HEAD to what is recorded in
the superproject, as that might have been changed by an earlier
commit. And as the submodules HEAD hasn't been updated back then,
it is stale and will always show up as modified (even if it wasn't).
> I can understand not updating submodules while running the rebase, but I expected that having resolved a conflict and added my change to the index it would be applied by `git rebase --continue`, as indeed it is if there happen to be other (non-submodule) changes in the same commit.
The irony is that you would have to update submodules (or at least
their HEAD and use "--ignore-submodules=dirty") while running rebase
to make that work in all cases ;-)
But just updating the HEAD would be dangerous as you would have to be
very careful to restore the submodules HEAD after the rebase, or the
submodule's work tree will be out of sync.
I suspect in the long run a rebase should, e.g. when invoked with
--recurse-submodules, update the submodules too and won't use the
--ignore-submodule option for diff anymore ... then everything
should Just Work. But until that happens, I don't see a solution
for your problem.
^ permalink raw reply
* Re: [PATCH 2/3] git-p4: Search for parent commit on branch creation
From: Pete Wyckoff @ 2012-01-17 22:18 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git
In-Reply-To: <CAOpHH-XUj7tF4O_kXfxq2e9Y4VmybNLCqGku_-9H1X+c7v=xwQ@mail.gmail.com>
vitor.hda@gmail.com wrote on Tue, 17 Jan 2012 00:10 +0000:
> On Mon, Jan 16, 2012 at 11:41 PM, Vitor Antunes <vitor.hda@gmail.com> wrote:
> > On Mon, Jan 16, 2012 at 6:57 PM, Pete Wyckoff <pw@padd.com> wrote:
> >> 1. Move the tempBranch commit outside of the "for blob" loop.
> >> It can have no parent, and the diff-tree will still tell you
> >> if you found the same contents. Instead of a ref for
> >> each blob inspected for each change, you'll just have one ref
> >> per change. Only one checkpoint() after the tempBranch
> >> commit should be needed.
> >
> > You're right. Completely oversaw that. Will improve the code
> > accordingly.
>
> Apparently I did not oversee it. Assume you have added a new file to
> HEAD of parent branch, but you branched from a previous commit. When the
> new branch is committed over HEAD the new file will, incorrectly, be
> part of it and diff-tree will not work as expected.
I don't get it. This algorithm works on the fact that a "branch"
in p4 creates a new change that looks exactly like a previous
change.
The git-p4 sync step, when it detects a branch, starts by saving
the change in a commit with parent = null, so it is its own new
branch, an orphan, with no parents.
Now the task is to find some commit that has an identical tree to
this temporary one. You walk back all known p4 commits to try to
find one that is the same. It doesn't matter if any of those p4
commits have other commits on top of them.
At each step in the backward walk, the comparison is against the
unchanged orphan commit.
An ascii-art picture might help me. Or even a test case.
> I should avoid taking 6 months to submit a patch to avoid forgetting why
> I did what I did :)
Yeah, and now you have to explain it all over to me again too. :)
-- Pete
^ permalink raw reply
* Re: [PATCH 1/4] git-p4: handle p4 branches and labels containing shell chars
From: Pete Wyckoff @ 2012-01-17 22:39 UTC (permalink / raw)
To: Luke Diamand; +Cc: git
In-Reply-To: <1326755689-3344-2-git-send-email-luke@diamand.org>
luke@diamand.org wrote on Mon, 16 Jan 2012 23:14 +0000:
> Don't use shell expansion when detecting branches, as it will
> fail if the branch name contains a shell metachar. Similarly
> for labels.
>
> Add additional test for branches with shell metachars.
Nice. There will be a fixup on a command in Vitor's series,
depending on which goes first. He'll have a couple of
un-listified read_pipe{,_lines} that we should treat similarly.
> @@ -1758,7 +1758,7 @@ class P4Sync(Command, P4UserMap):
> def getLabels(self):
> self.labels = {}
>
> - l = p4CmdList("labels %s..." % ' '.join (self.depotPaths))
> + l = p4CmdList(["labels", "%s..." % ' '.join (self.depotPaths)])
> if len(l) > 0 and not self.silent:
> print "Finding files belonging to labels in %s" % `self.depotPaths`
I suspect the command "p4" "labels" "//depot/foo/... //depot/bar/..."
might confuse p4, but haven't tested. Maybe tuck each one in its
own argument?
["labels"] + ["%s..." % p for p in self.depotPaths]
What happened to your failing test? It's fun to keep the broken
ones around to inspire others to fix them.
-- Pete
^ permalink raw reply
* Using signed tag in pull requests
From: Junio C Hamano @ 2012-01-17 22:53 UTC (permalink / raw)
To: git; +Cc: linux-kernel
This document will appear in Documentation/howto of Git release v1.7.9; I
am sending it out for an early review.
Thanks.
-- >8 --
Using signed tag in pull requests
=================================
A typical distributed workflow using Git is for a contributor to fork a
project, build on it, publish the result to her public repository, and ask
the "upstream" person (often the owner of the project where she forked
from) to pull from her public repository. Requesting such a "pull" is made
easy by the `git request-pull` command.
Earlier, a typical pull request may have started like this:
------------
The following changes since commit 406da78032179...:
Froboz 3.2 (2011-09-30 14:20:57 -0700)
are available in the git repository at:
example.com:/git/froboz.git for-xyzzy
------------
followed by a shortlog of the changes and a diffstat.
The request was for a branch name (e.g. `for-xyzzy`) in the public
repository of the contributor, and even though it stated where the
contributor forked her work from, the message did not say anything about
the commit to expect at the tip of the for-xyzzy branch. If the site that
hosts the public repository of the contributor cannot be fully trusted, it
was unnecessarily hard to make sure what was pulled by the integrator was
genuinely what the contributor had produced for the project. Also there
was no easy way for third-party auditors to later verify the resulting
history.
Starting from Git release v1.7.9, a contributor can add a signed tag to
the commit at the tip of the history and ask the integrator to pull that
signed tag. When the integrator runs `git pull`, the signed tag is
automatically verified to assure that the history is not tampered with.
In addition, the resulting merge commit records the content of the signed
tag, so that other people can verify that the branch merged by the
contributor was signed by the contributor, without fetching the signed tag
used to validate the pull request separately and keeping it in the refs
namespace.
This document describes the workflow between the contributor and the
integrator, using Git v1.7.9 or later.
A contributor or a lieutenant
-----------------------------
After preparing her work to be pulled, the contributor uses `git tag -s`
to create a signed tag [*1*]:
------------
$ git checkout work
$ ... "git pull" from sublieutenants, "git commit" your own work ...
$ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work
------------
and pushes the tag out to her publishing repository [*2*]. There is no
need to push the `work` branch or anything else:
------------
$ git push example.com:/git/froboz.git/ +frotz-for-xyzzy
------------
Then the contributor prepares a message to request a "pull":
------------
$ git request-pull v3.2 example.com:/git/froboz.git/ frotz-for-xyzzy >msg.txt
------------
The arguments are:
. the version of the integrator's commit the contributor based her work on;
. the URL of the repository, to which the contributor has pushed what she
wants to get pulled; and
. the name of the tag the contributor wants to get pulled (earlier, she could
write only a branch name here).
The resulting msg.txt file begins like so:
------------
The following changes since commit 406da78032179...:
Froboz 3.2 (2011-09-30 14:20:57 -0700)
are available in the git repository at:
example.com:/git/froboz.git frotz-for-xyzzy
for you to fetch changes up to 703f05ad5835c...:
Add tests and documentation for frotz (2011-12-02 10:02:52 -0800)
-----------------------------------------------
Completed frotz feature
-----------------------------------------------
------------
followed by a shortlog of the changes and a diffstat. Comparing this with
the earlier illustration of the output from the traditional `git request-pull`
command, the reader should notice that:
. The tip commit to expect is shown to the integrator; and
. The signed tag message is shown prominently between the dashed lines
before the shortlog.
The latter is why the contributor would want to justify why pulling her
work is worthwhile when creating the signed tag. The contributor then
opens her favorite MUA, reads msg.txt, edits and sends it to her upstream
integrator.
Integrator
----------
After receiving such a pull request message, the integrator fetches and
integrates the tag named in the request, with:
------------
$ git pull example.com:/git/froboz.git/ frotz-for-xyzzy
------------
This operation will always open an editor to allow the integrator to fine
tune the commit log message when merging a signed tag. Also, pulling a
signed tag will always create a merge commit even when the integrator does
not have any new commits since the contributor's work forked (i.e. 'fast
forward'), so that the integrator can properly explain what the merge is
about and why it was made.
In the editor, the integrator will see something like this:
------------
Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/
Completed frotz feature
# gpg: Signature made Fri 02 Dec 2011 10:03:01 AM PST using RSA key ID 96AFE6CB
# gpg: Good signature from "Con Tributor <nitfol@example.com>"
------------
provided if the signature in the signed tag verifies correctly. Notice
that the message recorded in the signed tag "Completed frotz feature"
appears here, and again that is why it is important for the contributor
to explain her work well when creating the signed tag.
As usual, the lines commented with `#` are stripped out. The resulting
commit records the signed tag used for this validation in a hidden field
so that it can later be used by others to audit the history. There is no
need for the integrator to keep a separate copy of the tag in his
repository (i.e. `git tag -l` won't list frotz-for-xyzzy tag in the above
example), and there is no need to publish the tag to his public
repository, either.
After the integrator responds to the pull request and her work becomes
part of the permanent history, the contributor can remove the tag from the
publishing repository, if she chooses, in order to keep the tag namespace
of her public repository clean, with:
------------
$ git push example.com:/git/froboz.git :frotz-for-xyzzy
------------
Auditors
--------
The `--show-signature` option can be given to `git log` or `git show` and
shows the verification status of the embedded signed tag in merge commits
created when the integrator responded to a pull request of a signed tag.
A typical output from `git show --show-signature` may look like this:
------------
$ git show --show-signature
commit 02306ef6a3498a39118aef9df7975bdb50091585
merged tag 'frotz-for-xyzzy'
gpg: Signature made Fri 06 Jan 2012 12:41:49 PM PST using RSA key ID 96AFE6CB
gpg: Good signature from "Con Tributor <nitfol@example.com>"
Merge: 406da78 703f05a
Author: Inte Grator <xyzzy@example.com>
Date: Tue Jan 17 13:49:41 2012 -0800
Merge tag 'frotz-for-xyzzy'
Completed frotz feature
* tag 'frotz-for-xyzzy' (100 commits)
Add tests and documentation for frotz
...
------------
There is no need to fetch and keep a signed tag like `frotz-for-xyzzy`
that is used for frequent "pull" exchange in the long term just for such
auditing purposes, as the signature is recorded as part of the merge
commit.
Footnotes
---------
*1* This example uses the `-m` option to create a signed tag with just a
single liner message, but this is for illustration purposes only. It is
advisable to compose a well-written explanation of what the topic does to
justify why it is worthwhile for the integrator to pull it, as this
message will eventually become part of the final history after the
integrator responds to the pull request.
*2* The example uses plus at the beginning of `+frotz-for-xyzzy` to allow
forcing the update of a tag, as the same contributor may want to reuse a
signed tag with the same name after the previous pull request has already
been responded to.
^ permalink raw reply
* Re: [PATCH] bash-completion: don't add quoted space for ZSH (fix regression)
From: Felipe Contreras @ 2012-01-17 23:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vzkdmqebh.fsf@alter.siamese.dyndns.org>
On Tue, Jan 17, 2012 at 10:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Tue, Jan 17, 2012 at 9:18 PM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> On Sat, Jan 14, 2012 at 8:55 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>>>> Commit a31e626 (completion: optimize refs completion) introduced a
>>>> regression for ZSH users: ref names were completed with a quoted trailing
>>>> space (i.e. "git checkout ma" completes to "git checkout master\ "). The
>>>> space is convenient for bash users since we use "-o nospace", but a
>>>> quoted space is worse than nothing. The absence of trailing space for ZSH
>>>> is a long-standing issue, that this patch is not fixing. We just fix the
>>>> regression by not appending a space when the shell is ZSH.
>>>
>>> I have this issue with the script from v1.7.8.3, and I think it
>>> started with a zsh update.
>>
>> Yeah, works fine with zsh 4.3.11, not 4.3.14 or 15.
>
> As I was planning to queue Matthieu's patch as-is as a regression fix
> before v1.7.9-rc2, I would appreciate if you can clarify this report a
> bit. Do you mean with the patch more recent versions of zsh still does not
> like the workaround and adds quoted space at the end?
I am saying I am seeing the issue (or at least the same symptom) even
before a31e626 with recent zsh versions. I will try a patched version
of the script and a31e626, but I'm guessing the result would be the
same.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] pulling signed tag: add howto document
From: Junio C Hamano @ 2012-01-17 23:29 UTC (permalink / raw)
To: git
In-Reply-To: <7vehuyosaa.fsf@alter.siamese.dyndns.org>
This time in a proper patch format...
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* We may want to update Documentation/Makefile in such a way that we
do not have to manually maintain a subset of howto/ files that need to
be added to SP_ARTICLES list (i.e. asciidoc formatted). They are all
marked with "Content-type: text/asciidoc" so a trivial $(shell grep -l)
might be all it takes. Hint, hint...
Documentation/Makefile | 5 +-
.../howto/using-signed-tag-in-pull-request.txt | 221 ++++++++++++++++++++
2 files changed, 225 insertions(+), 1 deletions(-)
create mode 100644 Documentation/howto/using-signed-tag-in-pull-request.txt
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 116f175..d40e211 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -20,7 +20,10 @@ ARTICLES += everyday
ARTICLES += git-tools
ARTICLES += git-bisect-lk2009
# with their own formatting rules.
-SP_ARTICLES = howto/revert-branch-rebase howto/using-merge-subtree user-manual
+SP_ARTICLES = user-manual
+SP_ARTICLES += howto/revert-branch-rebase
+SP_ARTICLES += howto/using-merge-subtree
+SP_ARTICLES += howto/using-signed-tag-in-pull-request
API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
SP_ARTICLES += $(API_DOCS)
SP_ARTICLES += technical/api-index
diff --git a/Documentation/howto/using-signed-tag-in-pull-request.txt b/Documentation/howto/using-signed-tag-in-pull-request.txt
new file mode 100644
index 0000000..a057f9a
--- /dev/null
+++ b/Documentation/howto/using-signed-tag-in-pull-request.txt
@@ -0,0 +1,221 @@
+From: Junio C Hamano <gitster@pobox.com>
+Date: Tue, 17 Jan 2011 13:00:00 -0800
+Subject: Using signed tag in pull requests
+Abstract: Beginning v1.7.9, a contributor can push a signed tag to her
+ publishing repository and ask her integrator to pull it. This assures the
+ integrator that the pulled history is authentic and allows others to
+ later validate it.
+Content-type: text/asciidoc
+
+Using signed tag in pull requests
+=================================
+
+A typical distributed workflow using Git is for a contributor to fork a
+project, build on it, publish the result to her public repository, and ask
+the "upstream" person (often the owner of the project where she forked
+from) to pull from her public repository. Requesting such a "pull" is made
+easy by the `git request-pull` command.
+
+Earlier, a typical pull request may have started like this:
+
+------------
+ The following changes since commit 406da78032179...:
+
+ Froboz 3.2 (2011-09-30 14:20:57 -0700)
+
+ are available in the git repository at:
+
+ example.com:/git/froboz.git for-xyzzy
+------------
+
+followed by a shortlog of the changes and a diffstat.
+
+The request was for a branch name (e.g. `for-xyzzy`) in the public
+repository of the contributor, and even though it stated where the
+contributor forked her work from, the message did not say anything about
+the commit to expect at the tip of the for-xyzzy branch. If the site that
+hosts the public repository of the contributor cannot be fully trusted, it
+was unnecessarily hard to make sure what was pulled by the integrator was
+genuinely what the contributor had produced for the project. Also there
+was no easy way for third-party auditors to later verify the resulting
+history.
+
+Starting from Git release v1.7.9, a contributor can add a signed tag to
+the commit at the tip of the history and ask the integrator to pull that
+signed tag. When the integrator runs `git pull`, the signed tag is
+automatically verified to assure that the history is not tampered with.
+In addition, the resulting merge commit records the content of the signed
+tag, so that other people can verify that the branch merged by the
+contributor was signed by the contributor, without fetching the signed tag
+used to validate the pull request separately and keeping it in the refs
+namespace.
+
+This document describes the workflow between the contributor and the
+integrator, using Git v1.7.9 or later.
+
+
+A contributor or a lieutenant
+-----------------------------
+
+After preparing her work to be pulled, the contributor uses `git tag -s`
+to create a signed tag [*1*]:
+
+------------
+ $ git checkout work
+ $ ... "git pull" from sublieutenants, "git commit" your own work ...
+ $ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work
+------------
+
+and pushes the tag out to her publishing repository [*2*]. There is no
+need to push the `work` branch or anything else:
+
+------------
+ $ git push example.com:/git/froboz.git/ +frotz-for-xyzzy
+------------
+
+Then the contributor prepares a message to request a "pull":
+
+------------
+ $ git request-pull v3.2 example.com:/git/froboz.git/ frotz-for-xyzzy >msg.txt
+------------
+
+The arguments are:
+
+. the version of the integrator's commit the contributor based her work on;
+. the URL of the repository, to which the contributor has pushed what she
+ wants to get pulled; and
+. the name of the tag the contributor wants to get pulled (earlier, she could
+ write only a branch name here).
+
+The resulting msg.txt file begins like so:
+
+------------
+ The following changes since commit 406da78032179...:
+
+ Froboz 3.2 (2011-09-30 14:20:57 -0700)
+
+ are available in the git repository at:
+
+ example.com:/git/froboz.git frotz-for-xyzzy
+
+ for you to fetch changes up to 703f05ad5835c...:
+
+ Add tests and documentation for frotz (2011-12-02 10:02:52 -0800)
+
+ -----------------------------------------------
+ Completed frotz feature
+ -----------------------------------------------
+------------
+
+followed by a shortlog of the changes and a diffstat. Comparing this with
+the earlier illustration of the output from the traditional `git request-pull`
+command, the reader should notice that:
+
+. The tip commit to expect is shown to the integrator; and
+. The signed tag message is shown prominently between the dashed lines
+ before the shortlog.
+
+The latter is why the contributor would want to justify why pulling her
+work is worthwhile when creating the signed tag. The contributor then
+opens her favorite MUA, reads msg.txt, edits and sends it to her upstream
+integrator.
+
+
+Integrator
+----------
+
+After receiving such a pull request message, the integrator fetches and
+integrates the tag named in the request, with:
+
+------------
+ $ git pull example.com:/git/froboz.git/ frotz-for-xyzzy
+------------
+
+This operation will always open an editor to allow the integrator to fine
+tune the commit log message when merging a signed tag. Also, pulling a
+signed tag will always create a merge commit even when the integrator does
+not have any new commits since the contributor's work forked (i.e. 'fast
+forward'), so that the integrator can properly explain what the merge is
+about and why it was made.
+
+In the editor, the integrator will see something like this:
+
+------------
+ Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/
+
+ Completed frotz feature
+ # gpg: Signature made Fri 02 Dec 2011 10:03:01 AM PST using RSA key ID 96AFE6CB
+ # gpg: Good signature from "Con Tributor <nitfol@example.com>"
+------------
+
+provided if the signature in the signed tag verifies correctly. Notice
+that the message recorded in the signed tag "Completed frotz feature"
+appears here, and again that is why it is important for the contributor
+to explain her work well when creating the signed tag.
+
+As usual, the lines commented with `#` are stripped out. The resulting
+commit records the signed tag used for this validation in a hidden field
+so that it can later be used by others to audit the history. There is no
+need for the integrator to keep a separate copy of the tag in his
+repository (i.e. `git tag -l` won't list frotz-for-xyzzy tag in the above
+example), and there is no need to publish the tag to his public
+repository, either.
+
+After the integrator responds to the pull request and her work becomes
+part of the permanent history, the contributor can remove the tag from the
+publishing repository, if she chooses, in order to keep the tag namespace
+of her public repository clean, with:
+
+------------
+ $ git push example.com:/git/froboz.git :frotz-for-xyzzy
+------------
+
+
+Auditors
+--------
+
+The `--show-signature` option can be given to `git log` or `git show` and
+shows the verification status of the embedded signed tag in merge commits
+created when the integrator responded to a pull request of a signed tag.
+
+A typical output from `git show --show-signature` may look like this:
+
+------------
+ $ git show --show-signature
+ commit 02306ef6a3498a39118aef9df7975bdb50091585
+ merged tag 'frotz-for-xyzzy'
+ gpg: Signature made Fri 06 Jan 2012 12:41:49 PM PST using RSA key ID 96AFE6CB
+ gpg: Good signature from "Con Tributor <nitfol@example.com>"
+ Merge: 406da78 703f05a
+ Author: Inte Grator <xyzzy@example.com>
+ Date: Tue Jan 17 13:49:41 2012 -0800
+
+ Merge tag 'frotz-for-xyzzy'
+
+ Completed frotz feature
+
+ * tag 'frotz-for-xyzzy' (100 commits)
+ Add tests and documentation for frotz
+ ...
+------------
+
+There is no need to fetch and keep a signed tag like `frotz-for-xyzzy`
+that is used for frequent "pull" exchange in the long term just for such
+auditing purposes, as the signature is recorded as part of the merge
+commit.
+
+
+Footnotes
+---------
+
+*1* This example uses the `-m` option to create a signed tag with just a
+single liner message, but this is for illustration purposes only. It is
+advisable to compose a well-written explanation of what the topic does to
+justify why it is worthwhile for the integrator to pull it, as this
+message will eventually become part of the final history after the
+integrator responds to the pull request.
+
+*2* The example uses plus at the beginning of `+frotz-for-xyzzy` to allow
+forcing the update of a tag, as the same contributor may want to reuse a
+signed tag with the same name after the previous pull request has already
+been responded to.
--
1.7.9.rc1.32.g0f516
^ permalink raw reply related
* Re: [PATCH] bash-completion: don't add quoted space for ZSH (fix regression)
From: Junio C Hamano @ 2012-01-17 23:42 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Matthieu Moy, git
In-Reply-To: <CAMP44s3GMGMD5Y9Z=Uu_e55_eZOG2zY76u8B=ORKsMx6yoXW5Q@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
>> As I was planning to queue Matthieu's patch as-is as a regression fix
>> before v1.7.9-rc2, I would appreciate if you can clarify this report a
>> bit. Do you mean with the patch more recent versions of zsh still does not
>> like the workaround and adds quoted space at the end?
>
> I am saying I am seeing the issue (or at least the same symptom) even
> before a31e626 with recent zsh versions. I will try a patched version
> of the script and a31e626, but I'm guessing the result would be the
> same.
OK, so the issue the patch addresses may not be a regression in the
upcoming v1.7.9 we want to fix quickly, but if you tried the patch we
might see improvements, or we might not see any improvements.
I'll hold onto Matthieu's patch for now, then. It would be nice to get
this minor detail fixed before the release, though, as any fix would be
of limited scope, affecting zsh users for which it is already broken.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/3] git-p4: Search for parent commit on branch creation
From: Vitor Antunes @ 2012-01-17 23:43 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20120117221830.GA366@padd.com>
On Tue, Jan 17, 2012 at 10:18 PM, Pete Wyckoff <pw@padd.com> wrote:
> vitor.hda@gmail.com wrote on Tue, 17 Jan 2012 00:10 +0000:
>> On Mon, Jan 16, 2012 at 11:41 PM, Vitor Antunes <vitor.hda@gmail.com> wrote:
>> > On Mon, Jan 16, 2012 at 6:57 PM, Pete Wyckoff <pw@padd.com> wrote:
>> >> 1. Move the tempBranch commit outside of the "for blob" loop.
>> >> It can have no parent, and the diff-tree will still tell you
>> >> if you found the same contents. Instead of a ref for
>> >> each blob inspected for each change, you'll just have one ref
>> >> per change. Only one checkpoint() after the tempBranch
>> >> commit should be needed.
>> >
>> > You're right. Completely oversaw that. Will improve the code
>> > accordingly.
>>
>> Apparently I did not oversee it. Assume you have added a new file to
>> HEAD of parent branch, but you branched from a previous commit. When the
>> new branch is committed over HEAD the new file will, incorrectly, be
>> part of it and diff-tree will not work as expected.
>
> I don't get it. This algorithm works on the fact that a "branch"
> in p4 creates a new change that looks exactly like a previous
> change.
>
> The git-p4 sync step, when it detects a branch, starts by saving
> the change in a commit with parent = null, so it is its own new
> branch, an orphan, with no parents.
>
> Now the task is to find some commit that has an identical tree to
> this temporary one. You walk back all known p4 commits to try to
> find one that is the same. It doesn't matter if any of those p4
> commits have other commits on top of them.
>
> At each step in the backward walk, the comparison is against the
> unchanged orphan commit.
>
> An ascii-art picture might help me. Or even a test case.
I can see now that I did not understand the "no parent" in your original
reply. What you just explained makes sense. So, let me try that and I'll
update you tomorrow.
Vitor
^ permalink raw reply
* found some code...
From: Ron Eggler @ 2012-01-18 1:02 UTC (permalink / raw)
To: git
Hi There,
Some mishap had happened with my project:
I found a piece of code that is the most recent one that never got commited to
the repository. It is dated December 5th and it definitely is the most recent
piece of code.
Now in the mean time I switched computers so I had to reinstall git and get
create new local folders. Now this directory with the most recent code, shows
every file as unversioned which should not be true.
Only a couple, maybe 3 files had changed with that last change. Now when I commit
this now, is that gonna mess up my old repo or can I safely gio ahead and commit
that most recent code (even tho it might commit the whole folder) - it almost
seems like it forgot which files
were in the repo vs. which files were in my local folder...
Thanks for hints and suggestions how I get myself cleanly out of this mess!
Thanks,
Ron
^ permalink raw reply
* Re: Using signed tag in pull requests
From: Andrew Ardill @ 2012-01-18 1:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vehuyosaa.fsf@alter.siamese.dyndns.org>
Looks pretty good Junio, though one of the lines was a bit confusing:
On 18 January 2012 09:53, Junio C Hamano <gitster@pobox.com> wrote:
> Starting from Git release v1.7.9, a contributor can add a signed tag to
> the commit at the tip of the history and ask the integrator to pull that
> signed tag. When the integrator runs `git pull`, the signed tag is
> automatically verified to assure that the history is not tampered with.
> In addition, the resulting merge commit records the content of the signed
> tag, so that other people can verify that the branch merged by the
> contributor was signed by the contributor, without fetching the signed tag
I think you mean to say 'the branch merged by the integrator was signed
by the contributor'. If you are talking about two separate contributors, or
the same contributor merging one of her own branches, the wording can
likely be improved.
> used to validate the pull request separately and keeping it in the refs
> namespace.
Overall it was easy to understand and makes the whole workflow quite clear.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: found some code...
From: Andrew Ardill @ 2012-01-18 1:16 UTC (permalink / raw)
To: Ron Eggler; +Cc: git
In-Reply-To: <loom.20120118T015734-175@post.gmane.org>
Hi Ron,
On 18 January 2012 12:02, Ron Eggler <ron.eggler@gmail.com> wrote:
> Hi There,
>
> Some mishap had happened with my project:
> I found a piece of code that is the most recent one that never got commited to
> the repository. It is dated December 5th and it definitely is the most recent
> piece of code.
> Now in the mean time I switched computers so I had to reinstall git and get
> create new local folders. Now this directory with the most recent code, shows
> every file as unversioned which should not be true.
> Only a couple, maybe 3 files had changed with that last change. Now when I commit
> this now, is that gonna mess up my old repo or can I safely gio ahead and commit
> that most recent code (even tho it might commit the whole folder) - it almost
> seems like it forgot which files
> were in the repo vs. which files were in my local folder...
>
> Thanks for hints and suggestions how I get myself cleanly out of this mess!
> Thanks,
> Ron
>
Out of interest, how did you transfer the existing code onto the new
machine? In particular, did you clone the existing repository using
git clone, or using some other method (such as zipping/emailing)? If
it was not via clone, did you copy the .git subdirectory, or did you
recreate it?
Is the old repository (on the old computer) still available?
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [PATCH] branch: borrow --sort and --count from for-each-ref
From: Nguyen Thai Ngoc Duy @ 2012-01-18 1:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvcoaqe9h.fsf@alter.siamese.dyndns.org>
2012/1/18 Junio C Hamano <gitster@pobox.com>:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>> ---
>> Some time ago, I posted a patch that added date sort to git-branch
>> and Peff pointed me to for-each-ref. I did not look at it closely.
>> Now it does not seem hard to lend some code from for-each-ref to
>> git-branch. I can list 10 most recently touched branches with
>>
>> git branch --sort=-committerdate -v --count=10
>>
>> kind of cool. I don't think adding --format is necessary because
>> git-branch already has its own formatting.
>
> Why do we even need this for "git branch", when "git for-each-ref
> refs/heads" already does this?
coloring, current branch marking, "branch -v", more accessible command
(I did not know about for-each-ref until Jeff told me)
--
Duy
^ permalink raw reply
* Re: git-grep while excluding files in a blacklist
From: Nguyen Thai Ngoc Duy @ 2012-01-18 1:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dov Grobgeld, git
In-Reply-To: <7v4nvurszj.fsf@alter.siamese.dyndns.org>
On Wed, Jan 18, 2012 at 3:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> On Tue, Jan 17, 2012 at 4:14 PM, Dov Grobgeld <dov.grobgeld@gmail.com> wrote:
>>> Does git-grep allow searching for a pattern in all files *except*
>>> files matching a pattern. E.g. in our project we have multiple DLL's
>>> in git, but when searching I would like to exclude these for speed. Is
>>> that possible with git-grep?
>>
>> Not from command line, no. You can put "*.dll" to .gitignore file then
>> "git grep --exclude-standard".
>
> No rush, but is this something we would eventually want to handle with the
> negative pathspec?
Definitely. But because I'm stuck at adding "seen" feature from
match_pathspec_depth to tree_entry_interesting, that probably won't
happen this year. Adding "--exclude=<pattern>" to git-grep is a more
plausible option.
--
Duy
^ permalink raw reply
* Re: Using signed tag in pull requests
From: Junio C Hamano @ 2012-01-18 1:47 UTC (permalink / raw)
To: Andrew Ardill; +Cc: git, linux-kernel
In-Reply-To: <CAH5451nSMcJ50fu2qtMkw4zPpx-Kg-k-jqCcpryu+pkC8JX8rw@mail.gmail.com>
Andrew Ardill <andrew.ardill@gmail.com> writes:
>> Starting from Git release v1.7.9, a contributor can add a signed tag to
>> the commit at the tip of the history and ask the integrator to pull that
>> signed tag. When the integrator runs `git pull`, the signed tag is
>> automatically verified to assure that the history is not tampered with.
>> In addition, the resulting merge commit records the content of the signed
>> tag, so that other people can verify that the branch merged by the
>> contributor was signed by the contributor, without fetching the signed tag
>
> I think you mean to say 'the branch merged by the integrator was signed
> by the contributor'.
Definitely. I'll update my local copy.
Thanks for spotting this.
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Sitaram Chamarty @ 2012-01-18 1:48 UTC (permalink / raw)
To: Gelonida N; +Cc: git
In-Reply-To: <20111217101009.GA19248@sita-lt.atc.tcs.com>
On Sat, Dec 17, 2011 at 3:40 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On Sat, Dec 10, 2011 at 01:26:32PM +0100, Gelonida N wrote:
>> Hi,
>>
>> What is the best way to fastforward all fastforwardable tracking
>> branches after a git fetch?
>
> I know this is a somewhat closed topic, but I took some time to
> clean up a program I have been using for a while, including some
A month later and I find I have modified this program
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Sitaram Chamarty @ 2012-01-18 1:50 UTC (permalink / raw)
To: Nazri Ramliy; +Cc: Gelonida N, git
In-Reply-To: <CAEY4ZpPKLrWQpEUYkwST8Fh40JwrjxvD+6yML6A+=XpsYmPevg@mail.gmail.com>
(sorry about that previous email; hit send in error. Here's the complete one)
On Mon, Dec 19, 2011 at 12:01 PM, Nazri Ramliy <ayiehere@gmail.com> wrote:
> On Sat, Dec 17, 2011 at 6:11 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
>> oops; forgot the program...
>
> This is nice!
>
> Stick it on github, or somewhere, please, so that I can always get the
> latest and greatest?
>
> Thanks.
>
> nazri
ok; it's on github: http://github.com/sitaramc/git-tools (they're all
standalone tools; you don't have to use the others)
The output is now colorised, and it will now also tell you, for each
remote you have, what branches you are hiding from them and what they
have which you have not started tracking locally.
a "screenshot" is at
http://sitaramc.github.com/git-tools/index.html#index_git_branch_check_
I notice I'm using it more and more, often even as a replacement for
'git status'... at least for repos where I'm juggling multiple
remotes.
^ permalink raw reply
* Re: Using signed tag in pull requests
From: Andrew Ardill @ 2012-01-18 2:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vwr8pok7w.fsf@alter.siamese.dyndns.org>
On 18 January 2012 12:47, Junio C Hamano <gitster@pobox.com> wrote:
> Andrew Ardill <andrew.ardill@gmail.com> writes:
>
>>> Starting from Git release v1.7.9, a contributor can add a signed tag to
>>> the commit at the tip of the history and ask the integrator to pull that
>>> signed tag. When the integrator runs `git pull`, the signed tag is
>>> automatically verified to assure that the history is not tampered with.
>>> In addition, the resulting merge commit records the content of the signed
>>> tag, so that other people can verify that the branch merged by the
>>> contributor was signed by the contributor, without fetching the signed tag
>>
>> I think you mean to say 'the branch merged by the integrator was signed
>> by the contributor'.
>
> Definitely. I'll update my local copy.
>
> Thanks for spotting this.
No worries. That's the whole point right? :D
^ permalink raw reply
* Re: found some code...
From: Ron Eggler @ 2012-01-18 2:49 UTC (permalink / raw)
To: Andrew Ardill; +Cc: git
In-Reply-To: <CAH5451k4bMJtMLsaFi6g_uRGTL0OdQ5Z1Pss3xuMdWYs+6VcLQ@mail.gmail.com>
On January 18, 2012 12:16:49 PM Andrew Ardill wrote:
> Hi Ron,
>
> On 18 January 2012 12:02, Ron Eggler <ron.eggler@gmail.com> wrote:
> > Hi There,
> >
> > Some mishap had happened with my project:
> > I found a piece of code that is the most recent one that never got
> > commited to the repository. It is dated December 5th and it definitely
> > is the most recent piece of code.
> > Now in the mean time I switched computers so I had to reinstall git and
> > get create new local folders. Now this directory with the most recent
> > code, shows every file as unversioned which should not be true.
> > Only a couple, maybe 3 files had changed with that last change. Now when
> > I commit this now, is that gonna mess up my old repo or can I safely
> > gio ahead and commit that most recent code (even tho it might commit
> > the whole folder) - it almost seems like it forgot which files
> > were in the repo vs. which files were in my local folder...
> >
> > Thanks for hints and suggestions how I get myself cleanly out of this
> > mess! Thanks,
> > Ron
>
> Out of interest, how did you transfer the existing code onto the new
> machine? In particular, did you clone the existing repository using
> git clone, or using some other method (such as zipping/emailing)? If
> it was not via clone, did you copy the .git subdirectory, or did you
> recreate it?
I copied the whole directory (incl .git) onto a thumb drive.
> Is the old repository (on the old computer) still available?
No, unfortunately not
--
Ron
^ permalink raw reply
* Re: [PATCH 2/2] diff --word-diff: use non-whitespace regex by default
From: Tay Ray Chuan @ 2012-01-18 7:32 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <87ipkhqnr8.fsf@thomas.inf.ethz.ch>
On Thu, Jan 12, 2012 at 5:22 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> [snip]
> Case in point, consider my patch sent out yesterday
>
> http://article.gmane.org/gmane.comp.version-control.git/188391
>
> It consists of a one-hunk doc update. word-diff is not brilliant:
>
> -k::
> Usually the program [-'cleans up'-]{+removes email cruft from+} the Subject:
> header line to extract the title line for the commit log
> [-message,-]
> [- among which (1) remove 'Re:' or 're:', (2) leading-]
> [- whitespaces, (3) '[' up to ']', typically '[PATCH]', and-]
> [- then prepends "[PATCH] ".-]{+message.+} This [-flag forbids-]{+option prevents+} this munging, and is most
> useful when used to read back 'git format-patch -k' output.
> [snip the rest as it's only {+}]
>
> But character-diff tries too hard to find common subsequences:
>
> $ g show HEAD^^ --word-diff-regex='[^[:space:]]' | xsel
>[snip]
> w-]{+. T+}hi[-te-]s[-paces, (3) '[' up t-] o[-']', ty-]p[
>
> is just line noise? The colors don't even help as most of it is removed
> (red).
You missed the '+' quantifier, as in
[^[:space:]]+
Using that regex, that abomination of a word-diff that you mentioned
disappears, like this:
-k::
Usually the program [-'cleans up'-]{+removes email cruft from+} the Subject:
header line to extract the title line for the commit log
[-message,-]
[- among which (1) remove 'Re:' or 're:', (2) leading-]
[- whitespaces, (3) '[' up to ']', typically '[PATCH]', and-]
[- then prepends "[PATCH] ".-]{+message.+} This [-flag
forbids-]{+option prevents+} this munging, and is most
useful when used to read back 'git format-patch -k' output.
> [snip]
> That being said, I can see some arguments for changing the default to
> split punctuation into a separate word. That is, whereas the current
> default is semantically equivalent to a wordRegex of
>
> [^[:space:]]*
>
> (but has a faster code path)
Oh right, there *is* a sensible default implemented in. Somehow I was
under the impression that there wasn't.
I wonder which is faster, using the non-whitespace regex, or the
isspace() calls...
> and your proposal is equivalent to
>
> [^[:space:]]|UTF_8_GUARD
>
> I think there is a case to be made for a default of
>
> [^[:space:]]|([[:alnum:]]|UTF_8_GUARD)+
>
> or some such. There's a lot of bikeshedding lurking in the (non)extent
> of the [[:alnum:]] here, however.
Care to explain further? Not to sure what you mean here.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] bash-completion: don't add quoted space for ZSH (fix regression)
From: Matthieu Moy @ 2012-01-18 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, git
In-Reply-To: <7v1uqxq4jm.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> OK, so the issue the patch addresses may not be a regression in the
> upcoming v1.7.9 we want to fix quickly,
I'm running ZSH 4.3.10 (Debian stable), and for me it is a regression.
It seems there is another bug elsewhere affecting more recent ZSH (I
don't have a recent ZSH version installed to test), but fixing the
regression for old ZSH is still worth it. I'm not even sur the issue
with recent ZSH is related.
At worse, my patch is not intrusive and can easily be reworked later.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH v2 2/2] tree_entry_interesting: make recursive mode default
From: Nguyen Thai Ngoc Duy @ 2012-01-18 8:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonathan Nieder, Linus Torvalds
In-Reply-To: <7v1uqzwaxs.fsf@alter.siamese.dyndns.org>
On Mon, Jan 16, 2012 at 02:15:59PM -0800, Junio C Hamano wrote:
> Yeah, the logic of this correction is very clear. Because diff_cache is
> about walking a flat index, the "recursive pathspec" that allows us to
> look into deeper levels in directory hierarchy should be set, and also we
> should not be limiting the depth of the match in any way by setting the
> max_depth to "unlimited".
For the record, enabling wildcard in git-log is just as simple. But I
guess you don't want more changes this late in rc cycles.
-- 8< --
diff --git a/revision.c b/revision.c
index 064e351..c426271 100644
--- a/revision.c
+++ b/revision.c
@@ -1816,6 +1816,8 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s
if (revs->prune_data.nr) {
diff_tree_setup_paths(revs->prune_data.raw, &revs->pruning);
+ revs->pruning.pathspec.recursive = 1;
+ revs->pruning.pathspec.max_depth = -1;
/* Can't prune commits with rename following: the paths change.. */
if (!DIFF_OPT_TST(&revs->diffopt, FOLLOW_RENAMES))
revs->prune = 1;
-- 8< --
--
Duy
^ permalink raw reply related
* Re: found some code...
From: Holger Hellmuth @ 2012-01-18 9:56 UTC (permalink / raw)
To: Ron Eggler; +Cc: Andrew Ardill, git
In-Reply-To: <2918969.0SyTOLELv0@reg-desktop>
On 18.01.2012 03:49, Ron Eggler wrote:
> On January 18, 2012 12:16:49 PM Andrew Ardill wrote:
>> Hi Ron,
>>
>> On 18 January 2012 12:02, Ron Eggler<ron.eggler@gmail.com> wrote:
>>> Hi There,
>>>
>>> Some mishap had happened with my project:
>>> I found a piece of code that is the most recent one that never got
>>> commited to the repository. It is dated December 5th and it definitely
>>> is the most recent piece of code.
>>> Now in the mean time I switched computers so I had to reinstall git and
>>> get create new local folders. Now this directory with the most recent
>>> code, shows every file as unversioned which should not be true.
>>> Only a couple, maybe 3 files had changed with that last change. Now when
>>> I commit this now, is that gonna mess up my old repo or can I safely
>>> gio ahead and commit that most recent code (even tho it might commit
>>> the whole folder) - it almost seems like it forgot which files
>>> were in the repo vs. which files were in my local folder...
Try "git update-index --refresh", more info in this recent thread
"http://comments.gmane.org/gmane.comp.version-control.git/188291"
If this doesn't help:
Human language is very ambiguous. What do you mean by "found a piece of
code"? Somewhere outside the repository, in a branch inside the
repository, in a subdirectory?
What do you mean by "get create new local folders"? Do you mean a folder
where you copied the repository or do you mean folders inside your
repository where you created new files with your editor?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox