There is only one "break" statement within the loop, which jumps to
the code after the loop that handles the case of a file that holds a
SHA-1. So move that code from below the loop into the if statement
where the break was previously located. This makes the logic flow
more local.
Signed-off-by:
The nesting was getting a bit out of hand, and it's about to get
worse.
Signed-off-by: Michael Haggerty
---
refs.c | 56 +++-
1 file changed, 35 insertions(+), 21 deletions(-)
diff --git a/refs.c b/refs.c
index 42a7e17..ab1f99e 100644
--- a/re
This is v2 of mh/loose-refs-race-with-pack-ref
I took Peff's suggestion to use gotos rather than an infinite loop in
the last patch, which means that there is no need for the old patch
03/04.
Michael Haggerty (3):
resolve_ref_unsafe(): extract function handle_missing_loose_ref()
resolve_ref_u
We read loose references in two steps. The code is roughly:
lstat()
if error ENOENT:
loose ref is missing; look for corresponding packed ref
else if S_ISLNK:
readlink()
if error:
report failure
else if S_ISDIR:
report failure
else
Am 6/19/2013 8:09, schrieb Ramkumar Ramachandra:
> Johannes Sixt wrote:
>> I haven't followed the topic closely, but I wonder why there are so many
>> explicit assignments to GIT_REFLOG_ACTION. Is calling set_reflog_action
>> (defined in git-sh-setup) the wrong thing to do?
>
> Does this answer yo
Hi,
Richard Hansen wrote:
> --- a/Documentation/glossary-content.txt
> +++ b/Documentation/glossary-content.txt
> @@ -82,6 +82,17 @@ to point at the new commit.
> to the top <> of the stored
> revision.
>
> +[[def_committish]]committish (also commit-ish)::
> + A <> pointing to a
Johannes Sixt wrote:
> I haven't followed the topic closely, but I wonder why there are so many
> explicit assignments to GIT_REFLOG_ACTION. Is calling set_reflog_action
> (defined in git-sh-setup) the wrong thing to do?
Does this answer your question?
set_reflog_action() {
if [ -z "${GIT
Richard Hansen wrote:
> On 2013-06-19 00:19, Ramkumar Ramachandra wrote:
>> Is master~3 a committish? What about :/foomery?
>
> Yes; as documented, both of those are refs that point to a commit.
>From gitglossary(7):
ref
A 40-byte hex representation of a SHA-1 or a name that denotes a
pa
On 06/18/2013 08:13 PM, Ramsay Jones wrote:
> Michael Haggerty wrote:
>> On 06/15/2013 10:13 PM, Ramsay Jones wrote:
>>> Now, turning to the new code, t3211-peel-ref.sh test #7 now works, but
>>> test #8 still fails...
>
> [ ... ]
>
>> It should be impossible, because the current proc
Am 6/18/2013 17:53, schrieb Martin von Zweigbergk:
> On Tue, Jun 18, 2013 at 12:28 AM, Johannes Sixt wrote:
>> Knowing that the tests would take their time to complete on Windows,
>
> I'm curious just how slow it is. Are we talking minutes?
D:\Src\mingw-git\t>bash -c "time make t342[15]*"
...
r
Veres Lajos writes:
> I am trying to convert this pull request:
> https://github.com/git/git/pull/42
> to a proper patch email
Use "git format-patch" and/or "git send-email" to get the proper
formatting.
> (Sorry If I miss something about the process.)
Yes, your patch doesn't have exactly the
small misspellings fixes
Signed-off-by: Veres Lajos
---
diff --git a/git-p4.py b/git-p4.py
index 911bbce..88fcf23 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -3168,7 +3168,7 @@ class P4Rebase(Command):
if os.system("git update-index --refresh") != 0:
die("Some files in your wo
Alexander Nestorov writes:
> How about that:
>
> +Reset only files who's content changed (instead of mtime modification)::
Much better, yes. I'd say "stat information" instead of mtime (that's
what used in the description of update-index --refresh, and is a bit
more accurate since Git also check
Am 6/18/2013 20:55, schrieb Ramkumar Ramachandra:
> Now that the "checkout" invoked internally from "rebase" knows to honor
> GIT_REFLOG_ACTION, we can start to use it to write a better reflog
> message when "rebase anotherbranch", "rebase --onto branch",
> etc. internally checks out the new fork p
On Tue, Jun 18, 2013 at 07:43:49PM -0700, Brandon Casey wrote:
> From: Brandon Casey
>
> Curl older than 7.17 (RHEL 4.X provides 7.12 and RHEL 5.X provides
> 7.15) requires that we manage any strings that we pass to it as
> pointers. So, we really shouldn't be modifying this strbuf after we
> h
On Tue, Jun 18, 2013 at 6:55 PM, W. Trevor King wrote:
> From: "W. Trevor King"
>
> The 3.x tree has been out for a while now. The -2.6 repository name
> survived the initial release [1], but kernel.org now only lists
> 'linux.git' (for aegl as well as torvalds) [2].
>
> [1]: http://article.gman
On 2013-06-19 00:19, Ramkumar Ramachandra wrote:
> Is master~3 a committish? What about :/foomery?
Yes; as documented, both of those are refs that point to a commit.
> Look at the other forms in gitrevisions(7); master:quuxery,
> master^{tree} are notable exceptions.
gitrevisions(7) says that m
Richard Hansen wrote:
> +[[def_committish]]committish (also commit-ish)::
Good.
> + A <> pointing to an <> that
> + can be recursively dereferenced to a
> + <>.
> + The following are all committishes:
> + a ref pointing to a commit object,
> + a ref pointing to
Veres Lajos wrote:
> Subject: small misspelling fixes
Good.
> I am trying to convert this pull request:
> https://github.com/git/git/pull/42
> to a proper patch email
> (Sorry If I miss something about the process.)
This does not belong in the commit message: you don't want this to be
shown when
Junio C Hamano wrote:
>> Oh, okay. Then just tweak before applying, if you don't mind?
>
> Sorry, you've already used my time allotment for this week.
No worries, I'll re-roll.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
I need to partner with you to get something done, please contact me.
--
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
From: "W. Trevor King"
Bring the docs back up to date with the real world ;). Patches are
against the current gitster/maint. The commit messages may be to
chatty, so let me know if you'd like a trimmed down version.
W. Trevor King (2):
Documentation: Update 'linux-2.6.git' -> 'linux.git'
u
From: "W. Trevor King"
They've grown since d19fbc3 (Documentation: add git user's manual,
2007-01-07) when the stats were initially added. I've rounded
download sizes up to the nearest power of ten MiB to decrease the
precision and give a bit of growing room. Exact sizes:
$ git clone git://g
From: "W. Trevor King"
The 3.x tree has been out for a while now. The -2.6 repository name
survived the initial release [1], but kernel.org now only lists
'linux.git' (for aegl as well as torvalds) [2].
[1]: http://article.gmane.org/gmane.linux.kernel/1147422
On 2011-05-30 01:47:57 GMT, Linus
From: Brandon Casey
Curl older than 7.17 (RHEL 4.X provides 7.12 and RHEL 5.X provides
7.15) requires that we manage any strings that we pass to it as
pointers. So, we really shouldn't be modifying this strbuf after we
have passed it to curl.
Our interaction with curl is currently safe (before
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
---
Documentation/glossary-content.txt | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/Documentation/glo
If possible, will be dereferenced even if it is not a tag type
(e.g., commit dereferenced to a tree).
Signed-off-by: Richard Hansen
---
Documentation/revisions.txt | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisi
The documentation contains a mix of the two spellings, and including
both makes it possible for users to search the glossary with their
spelling of choice.
Signed-off-by: Richard Hansen
---
Documentation/glossary-content.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Doc
On Tue, Jun 18, 2013 at 3:13 PM, Jeff King wrote:
> On Tue, Jun 18, 2013 at 12:29:03PM -0700, Brandon Casey wrote:
>> > It could be a problem when we have multiple handles in play
>> > simultaneously (we invalidate the pointer that another simultaneous
>> > handle is using, but do not immediately
Signed-off-by: Richard Hansen
---
Documentation/glossary-content.txt | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index 01365d9..a3cc003 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation
The documentation for the ^{} syntax (e.g.,
v1.8.3.1^{tree}) needed some fixing, and while I was at it I thought
I'd be pedantic about tree-ish. Oh, and let's welcome "committish" to
the party!
-Richard
Richard Hansen (4):
glossary: add 'treeish' as a synonym for 'tree-ish'
glossary: define
gitrevisions(7) implies that ^{tag} should work, but before now
it did not:
$ git rev-parse --verify v1.8.3.1^{tag}
fatal: Needed a single revision
This commit fixes the omission:
$ git rev-parse --verify v1.8.3.1^{tag}
4bc068950abec778a02ebf3ee73cf0735affabb4
Other object type
Hi,
I am trying to convert this pull request:
https://github.com/git/git/pull/42
to a proper patch email
(Sorry If I miss something about the process.)
I found a few trivial misspellings.
Signed-off-by: Veres Lajos
---
diff --git a/git-p4.py b/git-p4.py
index 911bbce..88fcf23 100755
--- a/git-p
On Tue, Jun 18, 2013 at 11:12:59PM +0200, Mark Abraham wrote:
> > In general, I think one can assume 1-to-1 correspondence between whole
> > regular diffs and whole word-diffs, but not below that (i.e., neither a
> > correspondence between hunks nor between lines).
> [...]
> My choice of "permit"
Ben Walton writes:
> Solaris' tr (both /usr/bin/ and /usr/xpg4/bin) fail to handle the case
> where the first argument is a multi-character set and the second is a
> single null character.
Almost all the tr invocations look like converting LF to NUL, except
for two that squash a colon ':', HT an
On Tue, Jun 18, 2013 at 12:29:03PM -0700, Brandon Casey wrote:
> > 1. Older versions of curl (and I do not recall which version off-hand,
> > but it is not important) stored just the pointer. Calling code was
> > required to manage the string lifetime itself.
>
> Daniel mentions that
Solaris' tr (both /usr/bin/ and /usr/xpg4/bin) fail to handle the case
where the first argument is a multi-character set and the second is a
single null character. Use perl to perform these substitutions
instead. Now that we're using perl for the transliteration, we might
as well replace the sed in
On Tue, Jun 18, 2013 at 7:23 PM, Jeff King wrote:
> On Tue, Jun 18, 2013 at 09:22:16AM +0200, Thomas Rast wrote:
>
>> [I don't seem to have received a copy of the original mail, so I can
>> only guess...]
>
> Yes, the original doesn't seem to have made it to the list. Sorry, I
> don't have a copy
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Why did this have to change back from branch-reflog-test to branch1
>> (which I used by mistake in "how about this" patch, but fixed in the
>> version queued on 'pu')?
>>
>> The reason I did not use 'branch1' in the version I queued on 'pu'
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
We are at the beginning of week #3 of this cycle, which is expected
to end around mid August. There are some patches on the list that I
didn't
Junio C Hamano wrote:
> Why did this have to change back from branch-reflog-test to branch1
> (which I used by mistake in "how about this" patch, but fixed in the
> version queued on 'pu')?
>
> The reason I did not use 'branch1' in the version I queued on 'pu'
> is because rr/rebase-sha1-by-string-
Ramkumar Ramachandra writes:
> Now that the "checkout" invoked internally from "rebase" knows to honor
> GIT_REFLOG_ACTION, we can start to use it to write a better reflog
> message when "rebase anotherbranch", "rebase --onto branch",
> etc. internally checks out the new fork point. We will writ
Junio C Hamano wrote:
> Sounds like making "make test" build it is a more correct approach,
> at least to me. What am I missing?
How exactly? I'm not exactly competent in make, but this is what I
understood from what you said (and it's obviously wrong):
diff --git a/Makefile b/Makefile
index 03
Ramkumar Ramachandra writes:
> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
> index 79e8d3c..f7d0147 100755
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -934,6 +934,21 @@ test_expect_success 'rebase --edit-todo can be used to
> mo
Ramkumar Ramachandra writes:
> What this means is that git-remote-testpy is not built by default (when
> 'make' is invoked), but t5800 runs by default (like every other test in
> t/). As a result, a new contributor cloning git.git and running 'make
> test' for the first time will notice test fai
416fda6 (build: do not install git-remote-testpy, 2013-05-24) added
git-remote-testpy to NO_INSTALL, with the intent of excluding it from
the default install. This is typically meant for scripts in contrib/
with their own testsuite and Makefile (e.g. git remote-bzr, git
remote-hg). Unfortunately,
* Junio C Hamano [2013-06-18 09:48:28 -0700]:
> SZEDER Gábor writes:
>
> > This patch series eliminates many command substitutions and commands
> > in __git_ps1() from top to bottom by replacing them with bash builtins
> > or consolidating them. A few timing results are shown in the log
> > me
Am 18.06.2013 01:42, schrieb Junio C Hamano:
But the need to go all the way up in the recursive callframes to get
the union of bitmask to get conflicts looks somewhat ugly.
Yes, that's not pretty. It's like make_traverse_path in that regard,
though, so it fits in somehow.
I suspect the *rea
On Mon, Jun 17, 2013 at 10:19 PM, Jeff King wrote:
> On Mon, Jun 17, 2013 at 07:00:40PM -0700, Brandon Casey wrote:
>
>> Curl requires that we manage any strings that we pass to it as pointers.
>> So, we should not be overwriting this strbuf after we've passed it to
>> curl.
>
> My understanding o
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index fd9a1d5..6c3bafe 100644
--- a/contrib/completion/git-completion
Junio C Hamano wrote:
> strbuf_addf(&sb, "%s: fast-forward", action_name(opts))
Agreed. Can you just fix it up locally?
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kern
Now that the "checkout" invoked internally from "rebase -i" knows to
honor GIT_REFLOG_ACTION, we can start to use it to write a better reflog
message when "rebase -i anotherbranch", "rebase -i --onto branch",
etc. internally checks out the new fork point. We will write:
rebase -i (start): check
b397ea4 (status: show more info than "currently not on any branch",
2013-03-13) attempted to make the output of 'git status' richer in
the case of a detached HEAD. Before this patch, with a detached
HEAD, we saw:
$ git status
# Not currently on any branch.
But after the patch, we see:
$ g
Now that the "checkout" invoked internally from "rebase" knows to honor
GIT_REFLOG_ACTION, we can start to use it to write a better reflog
message when "rebase anotherbranch", "rebase --onto branch",
etc. internally checks out the new fork point. We will write:
rebase: checkout master
instead
GIT_REFLOG_ACTION is an environment variable specifying the reflog
message to write after an action is completed. Several other commands
including merge, reset, and commit respect it.
Fix the failing tests in t/checkout-last by making checkout respect it
too. You can now expect
$ git checkout
From: Junio C Hamano
b397ea (status: show more info than "currently not on any branch",
2013-03-13) wanted to make sure that after a checkout to detach HEAD,
the user can see where the HEAD was originally detached from. The last
test added by that commit to t/status-help shows one example,
immed
The struct grab_1st_switch_cbdata has the field "found", which is
set in grab_1st_switch() when a match is found. This information is
redundant and unused by any code. The return value of the function
serves to communicate this information anyway.
Remove the field.
Signed-off-by: Ramkumar Ramac
In this iteration, I've redone [6/7] and [7/7] to address the "do not
leak GIT_REFLOG_ACTION" problem that Junio talked about. Predictably,
I couldn't convince myself to take Junio's subshell approach.
Instead, I've reworked the entire logic to have two variables:
GIT_REFLOG_ACTION and base_reflog
$ git checkout -
does not work as expected after a rebase. This is because the
reflog records "checkout" made by "rebase" as its implementation
detail the same way as end-user initiated "checkout", and makes it
count as the branch that was previously checked out.
Add four failing tests documen
Ramkumar Ramachandra writes:
> The following command
>
> $ git cherry-pick --ff b8bb3f
>
> writes the following uninformative message to the reflog
>
> cherry-pick
>
> Improve it to
>
> cherry-pick: fast-forward to b8bb3f
>
> Signed-off-by: Ramkumar Ramachandra
> ---
Perhaps, but a few qu
Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> At present, 'git show-ref' ignores any attempt to set config
>> variables (e.g. core.checkstat) from the command line using
>> the -c option to git.
>
> I think what you really want to see is not giving "-c" and have it
> honored.
>
> "git
Michael Haggerty wrote:
> Thanks for all of the information.
>
> On 06/15/2013 10:13 PM, Ramsay Jones wrote:
>> Michael Haggerty wrote:
>>> *This patch series must be built on top of mh/reflife.*
[ ... ]
>> You may be wondering why clear_packed_ref_cache() is called? Well, that
>> is because sta
The following command
$ git cherry-pick --ff b8bb3f
writes the following uninformative message to the reflog
cherry-pick
Improve it to
cherry-pick: fast-forward to b8bb3f
Signed-off-by: Ramkumar Ramachandra
---
sequencer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
Phil Hord wrote:
> Reviewed-by: Jonathan Nieder
Yep, still looks good from a quick glance.
Thanks for the quick turnaround.
--
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/majo
Thomas Rast writes:
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 4fa141a..e99b0ea 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -369,8 +369,15 @@ test_run_ () {
> return "$eval_ret"
> }
>
> -test_skip () {
> +test_start_ () {
> test_count=$(($test_count+1))
> +}
>
Thomas Ackermann wrote:
> When I want to tweak the html generation rules I also have to tweak the pdf
> generation rules because html and pdf should be as similiar to each other as
> possible.
Ah, *that's* what I missed. Thanks for explaining.
I think it's fine for the html and pdf to look diff
Chico Sokol writes:
> What is the encoding of the filename?
Git just considers filename a bunch of bytes that form a posix filename
(i.e., may not contain '/' and '\0'). So depending on your point of
view, it's either "no encoding" or "whatever you put into it".
--
Thomas Rast
trast@{inf,stud
Documentation and some comments still refer to files in builtin/
as 'builtin-*.[cho]'. Update these to show the correct location.
Signed-off-by: Phil Hord
Reviewed-by: Jonathan Nieder
Assisted-by: Junio C Hamano
---
Documentation/git-log.txt | 4 ++--
Documentation/techni
>
> If I understood the original commit message correctly, you were saying
> the XML file was not suitable for html generation and you wanted to
> tweak it, and were dropping the PDF target to avoid breaking it. Now
> if I understand correctly you are saying the XML file actually *is*
> suitable
Martin Fick writes:
> ... So, what
> if we could simply add a dummy object to the file to cause
> it to deserve a name change?
>
> So the idea would be, have git-repack detect the conflict in
> filenames and have it repack the new file with an additional
> dummy (unused) object in it, and the
On Tue, Jun 18, 2013 at 09:22:16AM +0200, Thomas Rast wrote:
> [I don't seem to have received a copy of the original mail, so I can
> only guess...]
Yes, the original doesn't seem to have made it to the list. Sorry, I
don't have a copy (I am in the habit of deleting direct mails that are
cc'd to
The describe logic is convoluted and unclean:
1. Reading .git/HEAD by hand and using the first 7 characters, of the
SHA-1 does not guarantee an unambiguous output; we can use rev-parse
--short in its place to get a unique SHA-1.
2. Use the --always option of describe to automatically output
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-name-rev.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index 5cd0d0d..67f0487 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation/g
236157 (Teach git-describe how to run name-rev, 2007-05-21) introduced
`git name-rev --name-only`, with the intent of using it to implement
`git describe --contains`. According to the message, users wanted to
use describe to figure out which tags contains a specific commit.
name-rev already did th
Hi,
I discovered --contains --all in describe, and found out that it
doesn't work as advertised for a deep historical reason. [3/5] is
super-important and addresses this issue; everything else is
decoration.
Thanks.
Ramkumar Ramachandra (5):
prompt: clean up describe logic
prompt: do not do
When GIT_PS1_SHOWCOLORHINTS is turned on, there is no need to put a
detached HEAD within parenthesis: the color can be used to discriminate
the detached HEAD.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-prompt.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff
236157 (Teach git-describe how to run name-rev, 2007-05-21) introduced
`git name-rev --name-only`, with the intent of using it to implement
`git describe --contains`. According to the message, one of the primary
objectives of --name-only was to make the output of name-rev match that
of describe.
László Lajos Jánszky writes:
> There is a git extension called git ftp, written by René:
> https://github.com/resmo in bash. This extension uses git to push only
> the changed files to the ftp server. Currently this extension uses
> grep to decide which file is ignored by upload.
Two possibilit
Ramkumar Ramachandra writes:
> Fix the failing tests in t/checkout-last by making checkout respect it
> too. You can now expect
>
> $ git checkout -
>
> to work as expected after any a rebase [-i]. It will also work with any
> other scripts provided they set an appropriate GIT_REFLOG_ACTION i
Phil Hord writes:
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index e831cc2..2483700 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -4256,7 +4256,7 @@ no longer need to call `setup_pager()` directly).
> Nowadays, `git lo
How about that:
+Reset only files who's content changed (instead of mtime modification)::
++
+
+$ git update-index --refresh <1>
+$ git reset --hard <2>
+
++
+<1> Make git realize which files actually changed instead of
+checking out al
I have been trying to think of ways to fix git-repack so
that it no longer momentarily makes the objects in a repo
inaccessible to all processes when it replaces packfiles
with the same objects in them as an already existing pack
file. To be more explicit, I am talking about the way it
moves
Junio C Hamano wrote:
> By the way, please stop doing "t/checkout-last" which I have to
> manually fix-up every time to its actual prefix (i.e. I cannot
> review with "less t/checkout-last*" to see what the log message is
> talking about; I can with "less t/t2012-checkout-last*").
Ah, I didn't rea
SZEDER Gábor writes:
> This patch series eliminates many command substitutions and commands
> in __git_ps1() from top to bottom by replacing them with bash builtins
> or consolidating them. A few timing results are shown in the log
> message of patch 10.
Nice. I think I saw Peff's comment and
Hi folks,
On Fri, Apr 27, 2012 at 08:28:40AM +, Eric Wong wrote:
> Matthijs Kooijman wrote:
> > This allows git-svn to prompt for a keyring unlock password, when a
> > the needed gnome keyring is locked.
> >
> > This requires changes in the subversion perl bindings which have been
> > commit
Junio C Hamano wrote:
> Apply the test change without the "do not leak" part in the fix-up
> (queued as a single "SQUASH???" commit on 'pu') to what you posted
> earlier and see how it breaks.
>
> --- expect 2013-06-18 16:09:21.0 +
> +++ actual 2013-06-18 16:09:21.
This allows git-svn to prompt for a keyring unlock password, when a
the needed gnome keyring is locked.
This requires changes in the subversion perl bindings which have been
committed to svn trunk (r1241554 and some followup commits) and are
first available in the 1.8.0 release.
---
perl/Git/SVN/
Ramkumar Ramachandra writes:
> Please excuse my stupidity and drop this patch.
Heh, we always have brain-fart every once in a while. Your
stupidity is always gladly excused ;-)
> I got mislead by your SQUASH??? patch which took care to set the
> environment variable and call checkout in a su
Thanks, makes sense. 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
Mathieu Liénard--Mayor writes:
> Le 2013-06-17 20:37, Junio C Hamano a écrit :
> ...
>> Extend wt_status_state structure to hold the necessary info, query
>> the state from the filesystem in that function, and display the info
>> (but not collect info) in show_rebase_in_progress(), to keep the
>>
Hi,
Phil Hord wrote:
> Documentation and some comments still refer to files in builtin/
> as 'builtin-*.[cho]'. Update these to show the correct location.
Yeah, good call.
[...]
> --- a/builtin/help.c
> +++ b/builtin/help.c
> @@ -1,5 +1,5 @@
> /*
> - * builtin-help.c
> + * builtin/help.c
>
Matthieu Moy writes:
> The obvious use-case is to copy-paste a list of addresses from an email.
> ...
> This could be mentionned in the commit message.
OK.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info
Thomas Ackermann wrote:
>> Would generating different XML files
>> for the PDF and for other purposes (with different names) work as a
>> way to achieve that without losing the printable manual?
>
> This would be even worse when we have to create different xml depen
Pete Wyckoff writes:
> Thanks for finding and fixing this. Great explanation. I
> tested it locally too.
>
> Acked-by: Pete Wyckoff
Thanks, both. Queued.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo in
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
>> index a58406d..c175ef1 100755
>> --- a/t/t3404-rebase-interactive.sh
>> +++ b/t/t3404-rebase-interactive.sh
>> @@ -934,6 +934,21 @@ test_expect_success 'rebase --e
Documentation and some comments still refer to files in builtin/
as 'builtin-*.[cho]'. Update these to show the correct location.
Signed-off-by: Phil Hord
---
Documentation/git-log.txt | 4 ++--
Documentation/technical/api-builtin.txt | 2 +-
Documentation/technical/
Alexander Nestorov writes:
> I'm home,
> https://github.com/alexandernst/git/commit/61f0a7d558e3cbae308fabdff66bd87569d6aa18
> Is that good?
Please, post your patches inline, it eases review. More generally, read
Documentation/SubmittingPatches.
+Ignore file permissions::
It's not only about
On Tue, Jun 18, 2013 at 12:28 AM, Johannes Sixt wrote:
>
> The recently introduced tests used uppercase letters to denote
> cherry-picks of commits having the corresponding lowercase letter names.
> The helper functions also set up tags with the names of the commits.
>
> But this constellation fai
I'm home,
https://github.com/alexandernst/git/commit/61f0a7d558e3cbae308fabdff66bd87569d6aa18
Is that good? Should I PR?
--
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-
Junio C Hamano wrote:
> - There is no mechanism for you to affect environment of your
>parent process.
Please excuse my stupidity and drop this patch. I got mislead by your
SQUASH??? patch which took care to set the environment variable and
call checkout in a subshell.
--
To unsubscribe from
1 - 100 of 194 matches
Mail list logo
