[PATCH v5 2/2] t7102: add 'reset -' tests
Add following test cases:
1) Confirm error message when git reset is used with no previous branch
2) Confirm git reset - works like git reset @{-1}
3) Confirm - is always treated as a commit unless the -- file option
is specified
4) Confirm git reset - works normally even when a file named @{-1} is
present
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Helped-by: Matthieu Moy matthieu@grenoble-inp.fr
Helped-by: David Aguilar dav...@gmail.com
Signed-off-by: Sudhanshu Shekhar sudshekha...@gmail.com
---
Eric: Thank you for pointing out the mistake. The '' after the Here Docs
was causing the issue. I have removed the concatenation from there, hope
that's okay.
Regarding the @{-1} test case, I created it as a check for Junio's comment
on the error message generated by git reset - when a file named @{-1} is
there.
Since, in this situation git reset @{-1} will return an error (but reset -
shouldn't).
I have renamed the folder to 'dash' as suggested by you, keeping the old name
only
where it made sense.
t/t7102-reset.sh | 158 +++
1 file changed, 158 insertions(+)
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 98bcfe2..18523c1 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -568,4 +568,162 @@ test_expect_success 'reset --mixed sets up work tree' '
test_cmp expect actual
'
+test_expect_success 'reset - with no previous branch fails' '
+ git init no_previous
+ test_when_finished rm -rf no_previous
+ (
+ cd no_previous
+ test_must_fail git reset - 2actual
+ )
+ test_i18ngrep ambiguous argument no_previous/actual
+'
+
+test_expect_success 'reset - while having file named - and no previous branch
fails' '
+ git init no_previous
+ test_when_finished rm -rf no_previous
+ (
+ cd no_previous
+ -
+ test_must_fail git reset - 2actual
+ )
+ test_i18ngrep ambiguous argument no_previous/actual
+'
+
+
+test_expect_success \
+ 'reset - in the presence of file named - with previous branch resets
commit' '
+ cat expect -EOF
+ Unstaged changes after reset:
+ M -
+ M file
+ EOF
+ git init dash
+ test_when_finished rm -rf dash
+ (
+ cd dash
+ -
+ file
+ git add file -
+ git commit -m add base files
+ git checkout -b new_branch
+ echo random -
+ echo wow file
+ git add file -
+ git reset - ../actual
+ )
+ test_cmp expect actual
+'
+test_expect_success \
+ 'reset - in the presence of file named - with -- option resets commit' '
+ cat expect -EOF
+ Unstaged changes after reset:
+ M -
+ M file
+ EOF
+ git init dash
+ test_when_finished rm -rf dash
+ (
+ cd dash
+ -
+ file
+ git add file -
+ git commit -m add base files
+ git checkout -b new_branch
+ echo random -
+ echo wow file
+ git add file -
+ git reset - -- ../actual
+ )
+ test_cmp expect actual
+'
+
+test_expect_success 'reset - in the presence of file named - with -- file
option resets file' '
+ cat expect -EOF
+ Unstaged changes after reset:
+ M -
+ EOF
+ git init dash
+ test_when_finished rm -rf dash
+ (
+ cd dash
+ -
+ file
+ git add file -
+ git commit -m add base files
+ git checkout -b new_branch
+ echo random -
+ echo wow file
+ git add file -
+ git reset -- - ../actual
+ )
+ test_cmp expect actual
+'
+test_expect_success \
+ 'reset - in the presence of file named - with both pre and post --
option resets file' '
+ cat expect -EOF
+ Unstaged changes after reset:
+ M -
+ EOF
+ git init dash
+ test_when_finished rm -rf dash
+ (
+ cd dash
+ -
+ file
+ git add file -
+ git commit -m add base files
+ git checkout -b new_branch
+ echo random -
+ echo wow file
+ git add file -
+ git reset - -- - ../actual
+ )
+ test_cmp expect actual
+'
+
+test_expect_success 'reset - works same as reset @{-1}' '
+ git init dash
+ test_when_finished rm -rf dash
+ (
+ cd dash
+ echo file1 file1
+ git add file1
+ git commit -m base commit
+ git checkout -b temp
+ echo new file file
+
[PATCH v5 1/2] reset: enable '-' short-hand for previous branch
git reset '-' will reset to the previous branch. To reset a file named
- use either git reset ./- or git reset -- -.
Change error message to treat single - as an ambigous revision or
path rather than a bad flag.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Helped-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Sudhanshu Shekhar sudshekha...@gmail.com
---
I have changed the logic to ensure argv[0] isn't changed at any point.
Creating a modified_argv0 variable let's me do that.
I couldn't think of any other way to achieve this, apart from changing things
directly in the sha1_name.c file (like Junio's changes). Please let me know
if some further changes are needed.
builtin/reset.c | 17 +
setup.c | 2 +-
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 4c08ddc..bc50e14 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -192,6 +192,7 @@ static void parse_args(struct pathspec *pathspec,
{
const char *rev = HEAD;
unsigned char unused[20];
+ const char *modified_argv0 = argv[0];
/*
* Possible arguments are:
*
@@ -205,10 +206,17 @@ static void parse_args(struct pathspec *pathspec,
*/
if (argv[0]) {
+ if (!strcmp(argv[0], -)) {
+ modified_argv0 = @{-1};
+ }
+ else {
+ modified_argv0 = argv[0];
+ }
+
if (!strcmp(argv[0], --)) {
argv++; /* reset to HEAD, possibly with paths */
} else if (argv[1] !strcmp(argv[1], --)) {
- rev = argv[0];
+ rev = modified_argv0;
argv += 2;
}
/*
@@ -216,14 +224,15 @@ static void parse_args(struct pathspec *pathspec,
* has to be unambiguous. If there is a single argument, it
* can not be a tree
*/
- else if ((!argv[1] !get_sha1_committish(argv[0], unused)) ||
-(argv[1] !get_sha1_treeish(argv[0], unused))) {
+ else if ((!argv[1] !get_sha1_committish(modified_argv0,
unused)) ||
+(argv[1] !get_sha1_treeish(modified_argv0,
unused))) {
/*
* Ok, argv[0] looks like a commit/tree; it should not
* be a filename.
*/
verify_non_filename(prefix, argv[0]);
- rev = *argv++;
+ rev = modified_argv0;
+ argv++;
} else {
/* Otherwise we treat this as a filename */
verify_filename(prefix, argv[0], 1);
diff --git a/setup.c b/setup.c
index 979b13f..b621b62 100644
--- a/setup.c
+++ b/setup.c
@@ -200,7 +200,7 @@ void verify_filename(const char *prefix,
int diagnose_misspelt_rev)
{
if (*arg == '-')
- die(bad flag '%s' used after filename, arg);
+ die(ambiguous argument '%s': unknown revision or path, arg);
if (check_filename(prefix, arg))
return;
die_verify_filename(prefix, arg, diagnose_misspelt_rev);
--
2.3.1.277.gd67f9d5.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-completion: add stashes for gitk
Thank you for the review.
I now understand that the commit message should have provided way more
context about my use case.
I used Bazaar almost exclusively until about a year ago. Git's ability
to put stuff in the index without committing and the power of git
rebase covers many of the use cases I would have used shelves
(stashes) for in Bazaar. But a stash is still, as far as I know Git,
the best solution in some cases.
A Bazaar shelve (stash) has a stable number. (Applying a shelve from
the middle of the list won't cause a renumbering) A git stash will
change its number when a new stash is added. (On the positive side
this allows stash@{2.hours.ago}) The renumbering makes it more
difficult to keep track of what is there. I therefore have more need
of a quick way to get an overview of the stashes in git than in
bazaar. You idea of using a stash's message to refer to it would solve
this.
In Bazaar I can quickly get an overview of the shelves (stashes) by
typing bzr qshelve and clicking on the View shelved changes tab.
Its has a list of my shelves including their number and message at the
top. Under it the diff of the currently selected shelve is displayed.
This makes it fast to get an overview of the shelves.
The objective the patch tries to achieve is to speed up getting an
overview of stashed changes in gitk. A big stash in git stash list
-p can force a user to read it slowly or risk skipping the next
stash. By typing gitk stash@{TAB all stashes are listed. The user
can then know if there are more stashes that haven't been viewed yet
and stop reading a stash when he knows what the current stash is. (If
I understand things right gitk stash@{.} would have the problem of
burying old stashed under the commits above it)
A bigger question is why this change is made to gitk completion. If
this completion were useful for gitk, wouoldn't it be equally
useful for git log?
I must admit that I didn't know that git log could display the
content of a stashed change. After trying git log -p -m stash@{0} I
would say that adding stashes for git log would be slightly less
useful. gitk stash@{0} allows me to look at the stashed change and
find out what it contains. git log -p (note: no -m since the user
don't know that a stash is a merge commit) won't let me do that.
Another reason is that git stash show -p stash@{0} already is
autocompleted for those that wish to view their stash diff on the
command line)
If there were a way for users to say The one I made to stash away
that change from the command line (I do not mean git stash list |
grep 'that change'), it would be good.
Great idea.
--
Helsing
Sveinung
The Lord requires of his saints confession of sins during their whole
lives, and that without ceasing, and promises pardon. How presumptuous,
then, to exempt them from sin, or when they have stumbled, to exclude them
altogether from grace? (sitat John Calvin)
--
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 v5 1/2] reset: enable '-' short-hand for previous branch
On Fri, Mar 13, 2015 at 2:18 PM, Sudhanshu Shekhar
sudshekha...@gmail.com wrote:
git reset '-' will reset to the previous branch. To reset a file named
- use either git reset ./- or git reset -- -.
Change error message to treat single - as an ambigous revision or
path rather than a bad flag.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Helped-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Sudhanshu Shekhar sudshekha...@gmail.com
---
I have changed the logic to ensure argv[0] isn't changed at any point.
Creating a modified_argv0 variable let's me do that.
I couldn't think of any other way to achieve this, apart from changing things
directly in the sha1_name.c file (like Junio's changes). Please let me know
if some further changes are needed.
diff --git a/builtin/reset.c b/builtin/reset.c
index 4c08ddc..bc50e14 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -192,6 +192,7 @@ static void parse_args(struct pathspec *pathspec,
{
const char *rev = HEAD;
unsigned char unused[20];
+ const char *modified_argv0 = argv[0];
This variable is only needed inside the 'if (argv[0])' block below, so
its declaration should be moved there. Also the initialization to
argv[0] is wasted since the assignment is overwritten below.
The variable name itself could be better. Unlike a name such as
'orig_arg0', modified doesn't tell us much. Modified how? Modified
to be what? Consideration where and how the variable is used, we can
see that it will be holding a value that _might_ be a rev. This
suggests a better name such as 'maybe_rev' or something similar.
/*
* Possible arguments are:
*
@@ -205,10 +206,17 @@ static void parse_args(struct pathspec *pathspec,
*/
if (argv[0]) {
+ if (!strcmp(argv[0], -)) {
+ modified_argv0 = @{-1};
+ }
+ else {
Style: cuddle the 'else' and braces: } else {
+ modified_argv0 = argv[0];
+ }
The unnecessary braces make this harder to read than it could be since
it is so spread out vertically. Dropping the braces would help. The
ternary operator ?: might improve readability (though it might also
make it worse).
if (!strcmp(argv[0], --)) {
argv++; /* reset to HEAD, possibly with paths */
} else if (argv[1] !strcmp(argv[1], --)) {
- rev = argv[0];
+ rev = modified_argv0;
argv += 2;
}
/*
@@ -216,14 +224,15 @@ static void parse_args(struct pathspec *pathspec,
* has to be unambiguous. If there is a single argument, it
* can not be a tree
*/
- else if ((!argv[1] !get_sha1_committish(argv[0], unused))
||
-(argv[1] !get_sha1_treeish(argv[0], unused))) {
+ else if ((!argv[1] !get_sha1_committish(modified_argv0,
unused)) ||
+(argv[1] !get_sha1_treeish(modified_argv0,
unused))) {
/*
* Ok, argv[0] looks like a commit/tree; it should not
* be a filename.
*/
verify_non_filename(prefix, argv[0]);
- rev = *argv++;
+ rev = modified_argv0;
+ argv++;
Good. This is much better than the previous rounds, and is the sort of
solution I had hoped to see when prodding you in previous reviews to
avoid argv[] kludges. Unlike the previous band-aid approach, this
demonstrates that you took the time to understand the overall logic
flow rather than merely plopping in a quick fix.
} else {
/* Otherwise we treat this as a filename */
verify_filename(prefix, argv[0], 1);
diff --git a/setup.c b/setup.c
index 979b13f..b621b62 100644
--- a/setup.c
+++ b/setup.c
@@ -200,7 +200,7 @@ void verify_filename(const char *prefix,
int diagnose_misspelt_rev)
{
if (*arg == '-')
- die(bad flag '%s' used after filename, arg);
+ die(ambiguous argument '%s': unknown revision or path, arg);
The conditional is only checking if the first character of 'arg' is
hyphen; it's not checking if 'arg' is exactly -. It's purpose is to
recognize -flags or --flags, so it's inappropriate to change the error
message like this. I think this also doesn't help the case when there
really is a file named -, since this conditional will just claim
that it's ambiguous.
It might or might not be appropriate to add a special case here to
allow an exact - to fall through to the check_filename() call below,
however, it would be necessary to thoroughly check for possible
Kedves: Webmail Előfizető
-- Kedves: Webmail Előfizető Felhívjuk figyelmét, hogy az e-mail fiók meghaladta tárolókapacitás. Ön nem tud küldeni és fogadni e-maileket és a e-mail fiókja törlésre kerül a szerverünkről. A probléma elkerülése érdekében, Kattintson ide frissítse a számla. http://mailupgafsd.jigsy.com/ Köszönöm. Rendszergazda E-mail System. Köszönjük az együttm?ködést! Levél a Web Team @ 2014 -- 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/GSoC/RFC] fetch: git fetch --deepen
On Fri, Mar 13, 2015 at 9:04 AM, Dongcan Jiang dongcan.ji...@gmail.com wrote:
This patch is just for discusstion. An option --deepen is added to
'git fetch'. When it comes to '--deepen', git should fetch N more
commits ahead the local shallow commit, where N is indicated by
'--depth=N'. [1]
[...]
Of course, as a patch for discussion, it remains a long way to go
before being complete.
[...]
Signed-off-by: Dongcan Jiang dongcan.ji...@gmail.com
---
diff --git a/fetch-pack.c b/fetch-pack.c
index 655ee64..6f4adca 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -295,6 +295,7 @@ static int find_common(struct fetch_pack_args *args,
if (no_done)strbuf_addstr(c, no-done);
if (use_sideband == 2) strbuf_addstr(c,
side-band-64k);
if (use_sideband == 1) strbuf_addstr(c,
side-band);
+ if (args-depth_deepen) strbuf_addstr(c,
depth_deepen);
For consistency, should this be depth-deepen rather than depth_deepen?
if (args-use_thin_pack) strbuf_addstr(c,
thin-pack);
if (args-no_progress) strbuf_addstr(c,
no-progress);
if (args-include_tag) strbuf_addstr(c,
include-tag);
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index d78f320..6738006 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -708,4 +708,15 @@ test_expect_success 'fetching a one-level ref works' '
)
'
+test_expect_success 'fetching deepen' '
+ git clone . deepen --depth=1
+ cd deepen
When this tests ends, the working directory will still be 'deepen',
which will likely break tests added after this one. If you wrap the
'cd' and following statements in a subshell via '(' and ')', then the
'cd' will affect the subshell but leave the parent shell's working
directory alone, and thus not negatively impact subsequent tests.
+ git fetch .. foo --depth=1
+ git show foo
+ test_must_fail git show foo~
+ git fetch .. foo --depth=1 --deepen
+ git show foo~
+ test_must_fail git show foo~2
Broken -chain throughout.
+'
+
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 v5 2/2] t7102: add 'reset -' tests
On Fri, Mar 13, 2015 at 2:18 PM, Sudhanshu Shekhar
sudshekha...@gmail.com wrote:
Add following test cases:
1) Confirm error message when git reset is used with no previous branch
2) Confirm git reset - works like git reset @{-1}
3) Confirm - is always treated as a commit unless the -- file option
is specified
4) Confirm git reset - works normally even when a file named @{-1} is
present
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Helped-by: Matthieu Moy matthieu@grenoble-inp.fr
Helped-by: David Aguilar dav...@gmail.com
Signed-off-by: Sudhanshu Shekhar sudshekha...@gmail.com
---
Eric: Thank you for pointing out the mistake. The '' after the Here
Docs was causing the issue. I have removed the concatenation from
there, hope that's okay.
The needs to go on the first line, not the last line of the here-doc.
However, that was not my main concern in the previous review. What
disturbed me was that the new tests, which were supposed to be
checking if - behaved as @{-1}, were succeeding even without patch
1/2 applied which implemented the - alias for @{-1}. That seems
wrong. I don't think you particularly addressed that issue in this
version (even though the first couple tests will now fail without 1/2
due to the changed error message).
Regarding the @{-1} test case, I created it as a check for Junio's
comment on the error message generated by git reset - when a file
named @{-1} is there. Since, in this situation git reset @{-1} will
return an error (but reset - shouldn't).
Reminder: Wrap commentary to about column 72, as you would the commit
message. (I re-wrapped it manually to reply to it.)
I have renamed the folder to 'dash' as suggested by you, keeping the
old name only where it made sense.
Considering that the test titles already tell us the intent of the
tests, I don't find that the directory name no_previous adds much
value to tests checking the behavior of - with no previous branch. A
single, consistent name used throughout all these tests would be less
surprising and place smaller cognitive load on the reader.
More below.
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 98bcfe2..18523c1 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -568,4 +568,162 @@ test_expect_success 'reset --mixed sets up work tree' '
test_cmp expect actual
'
+test_expect_success 'reset - with no previous branch fails' '
+ git init no_previous
+ test_when_finished rm -rf no_previous
+ (
+ cd no_previous
+ test_must_fail git reset - 2actual
+ )
+ test_i18ngrep ambiguous argument no_previous/actual
+'
+
+test_expect_success 'reset - while having file named - and no previous
branch fails' '
+ git init no_previous
+ test_when_finished rm -rf no_previous
+ (
+ cd no_previous
+ -
+ test_must_fail git reset - 2actual
+ )
+ test_i18ngrep ambiguous argument no_previous/actual
+'
+
+
Style: Unnecessary extra blank line.
+test_expect_success \
+ 'reset - in the presence of file named - with previous branch resets
commit' '
+ cat expect -EOF
Place the at the end of this line. Also, prefix EOF with a
backslash to indicate that you don't intend any interpolation to occur
within the here-doc. So:
cat expect -\EOF
Ditto for the remaining tests.
+ Unstaged changes after reset:
+ M -
+ M file
+ EOF
+ git init dash
+ test_when_finished rm -rf dash
+ (
+ cd dash
+ -
+ file
+ git add file -
+ git commit -m add base files
+ git checkout -b new_branch
+ echo random -
+ echo wow file
+ git add file -
+ git reset - ../actual
+ )
+ test_cmp expect actual
+'
+test_expect_success \
+ 'reset - in the presence of file named - with -- option resets
commit' '
+ cat expect -EOF
+ Unstaged changes after reset:
+ M -
+ M file
+ EOF
+ git init dash
+ test_when_finished rm -rf dash
+ (
+ cd dash
+ -
+ file
+ git add file -
+ git commit -m add base files
+ git checkout -b new_branch
+ echo random -
+ echo wow file
+ git add file -
+ git reset - -- ../actual
+ )
+ test_cmp expect actual
+'
+
+test_expect_success 'reset - in the presence of file named - with -- file
option resets file' '
+ cat expect -EOF
+ Unstaged changes after reset:
+ M -
+ EOF
+ git init dash
+ test_when_finished rm -rf dash
+ (
+ cd dash
+ -
+ file
+
Re: [PATCH v2] userdiff: funcname and word patterns for sh
Adrien Schildknecht adrien+...@schischi.me writes:
Add regexp based on the Shell Command Language specifications.
Because of the lax syntax of sh, some corner cases may not be
handled properly.
Signed-off-by: Adrien Schildknecht adrien+...@schischi.me
---
Those of you who helped in the first round of review, any comments,
This round looks good's, ...?
+PATTERNS(sh,
+ ^([ \t]*(function[ \t]+)?[a-zA-Z_][a-zA-Z0-9_]*[ \t]*\\([ \t]*\\).*)$,
+ /* -- */
I do not think it is wrong per-se to try to be as precise as
possible, but I wonder if it is sufficient to cheat and make these
what is a word? expressions a bit looser, by declaring that it is
OK if a simpler pattern allows something that are syntactically
illegal in shell, as long as it splits valid shell construct
correctly. For example:
+ [a-zA-Z0-9_]+
+ |[-+0-9]+
The first one matches an identifier (e.g. If you have frotz=a b c
and $frotz, two appearances of 'frotz' are matched) and the second
one I think is trying to catch possibly signed integers, but the
latter also matches 0+1+++2 which is already loose (but I do not
think it is a problem). Perhaps it is sufficient to collapse the
above into a single [-+a-zA-Z0-9_$]+?
+ |[-+*/%^|=!]=|=?|=?|\\+\\+|--|\\*\\*||\\|\\||\\[\\[|\\]\\]
+ |\\||[]+||-|;;),
Likewise. I wonder if something like [-~!@#%^*+=|;/]+ gives too
many false matches.
{ default, NULL, -1, { NULL, 0 } },
};
#undef PATTERNS
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-completion: add stashes for gitk
Sveinung Kvilhaugsvik sveinun...@users.sourceforge.net writes:
A bigger question is why this change is made to gitk completion. If
this completion were useful for gitk, wouoldn't it be equally
useful for git log?
I must admit that I didn't know that git log could display the
content of a stashed change. After trying git log -p -m stash@{0} I
would say that adding stashes for git log would be slightly less
useful.
Yeah, it would not be so useful to dig with log beyond the commit
that each stash entry is based on. But imagine git show stash@{}
or git log -g stash@{0}?
--
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/GSoC/RFC] fetch: git fetch --deepen
Dongcan Jiang dongcan.ji...@gmail.com writes:
This patch is just for discusstion. An option --deepen is added to
'git fetch'. When it comes to '--deepen', git should fetch N more
commits ahead the local shallow commit, where N is indicated by
'--depth=N'. [1]
e.g.
(upstream)
---o---o---o---A---B
(you)
A---B
After excuting git fetch --depth=1 --deepen, (you) get one more
tip and it becomes
(you)
o---A---B
'--deepen' is designed to be a boolean option in this patch, which
is a little different from [1]. It's designed in this way, because
it can reuse '--depth' in the program, and just costs one more bit
in some data structure, such as fetch_pack_args,
git_transport_options.
Of course, as a patch for discussion, it remains a long way to go
before being complete.
1) Documents should be completed.
2) More test cases, expecially corner cases, should be added.
3) No need to get remote refs when it comes to '--deepen' option.
4) Validity on options combination should be checked.
5) smart-http protocol remains to be supported. [2]
Besides, I still have one question:
What does (you) exactly mean in [1]? The local branch or the local
remote ref?
As this operation is not about moving _any_ refs, whether local
branches or remote-tracking branches, any ref that used to point at
commit B before you executed fetch --deepen would point at the
same commit after the command finishes.
The you does not explicitly depict any ref, because the picture is
meant to illustrate _everything_ the repository at the receiving end
of fetch has. It used to have two commits, A and B (and the tree
and blob objects necessary to complete these two commits). After
deepening the history by one commit, it then will have commit A^ and
its trees and blobs.
diff --git a/upload-pack.c b/upload-pack.c
index b531a32..8004f2f 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -31,6 +31,7 @@ static const char upload_pack_usage[] = git upload-pack
[--strict] [--timeout=
static unsigned long oldest_have;
+static int depth_deepen;
static int multi_ack;
static int no_done;
static int use_thin_pack, use_ofs_delta, use_include_tag;
@@ -563,11 +564,11 @@ static void receive_needs(void)
}
continue;
}
- if (starts_with(line, deepen )) {
+ if (starts_with(line, depth )) {
char *end;
- depth = strtol(line + 7, end, 0);
- if (end == line + 7 || depth = 0)
- die(Invalid deepen: %s, line);
+ depth = strtol(line + 6, end, 0);
+ if (end == line + 6 || depth = 0)
+ die(Invalid depth: %s, line);
continue;
}
if (!starts_with(line, want ) ||
I do not quite understand this hunk. What happens when this program
is talking to an existing fetch-pack that requested deepen?
@@ -577,6 +578,8 @@ static void receive_needs(void)
features = line + 45;
+ if (parse_feature_request(features, depth_deepen))
+ depth_deepen = 1;
if (parse_feature_request(features, multi_ack_detailed))
multi_ack = 2;
else if (parse_feature_request(features, multi_ack))
@@ -631,6 +634,10 @@ static void receive_needs(void)
struct object *object =
shallows.objects[i].item;
object-flags |= NOT_SHALLOW;
}
+ else if (depth_deepen)
+ backup = result =
+ get_shallow_commits(shallows, depth + 1,
+ SHALLOW, NOT_SHALLOW);
else
backup = result =
get_shallow_commits(want_obj, depth,
--
2.3.1.253.gb3fd89e
--
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 v2 07/10] diff: convert struct combine_diff_path to object_id
Also, convert a constant to GIT_SHA1_HEXSZ.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
combine-diff.c | 56
diff-lib.c | 10 +-
diff.h | 5 +++--
tree-diff.c| 10 +-
4 files changed, 41 insertions(+), 40 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 91edce5..8eb7278 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -44,9 +44,9 @@ static struct combine_diff_path *intersect_paths(struct
combine_diff_path *curr,
memset(p-parent, 0,
sizeof(p-parent[0]) * num_parent);
- hashcpy(p-sha1, q-queue[i]-two-sha1);
+ hashcpy(p-oid.hash, q-queue[i]-two-sha1);
p-mode = q-queue[i]-two-mode;
- hashcpy(p-parent[n].sha1, q-queue[i]-one-sha1);
+ hashcpy(p-parent[n].oid.hash, q-queue[i]-one-sha1);
p-parent[n].mode = q-queue[i]-one-mode;
p-parent[n].status = q-queue[i]-status;
*tail = p;
@@ -77,7 +77,7 @@ static struct combine_diff_path *intersect_paths(struct
combine_diff_path *curr,
continue;
}
- hashcpy(p-parent[n].sha1, q-queue[i]-one-sha1);
+ hashcpy(p-parent[n].oid.hash, q-queue[i]-one-sha1);
p-parent[n].mode = q-queue[i]-one-mode;
p-parent[n].status = q-queue[i]-status;
@@ -284,7 +284,7 @@ static struct lline *coalesce_lines(struct lline *base, int
*lenbase,
return base;
}
-static char *grab_blob(const unsigned char *sha1, unsigned int mode,
+static char *grab_blob(const struct object_id *oid, unsigned int mode,
unsigned long *size, struct userdiff_driver *textconv,
const char *path)
{
@@ -294,20 +294,20 @@ static char *grab_blob(const unsigned char *sha1,
unsigned int mode,
if (S_ISGITLINK(mode)) {
blob = xmalloc(100);
*size = snprintf(blob, 100,
-Subproject commit %s\n, sha1_to_hex(sha1));
- } else if (is_null_sha1(sha1)) {
+Subproject commit %s\n, oid_to_hex(oid));
+ } else if (is_null_oid(oid)) {
/* deleted blob */
*size = 0;
return xcalloc(1, 1);
} else if (textconv) {
struct diff_filespec *df = alloc_filespec(path);
- fill_filespec(df, sha1, 1, mode);
+ fill_filespec(df, oid-hash, 1, mode);
*size = fill_textconv(textconv, df, blob);
free_filespec(df);
} else {
- blob = read_sha1_file(sha1, type, size);
+ blob = read_sha1_file(oid-hash, type, size);
if (type != OBJ_BLOB)
- die(object '%s' is not a blob!, sha1_to_hex(sha1));
+ die(object '%s' is not a blob!, oid_to_hex(oid));
}
return blob;
}
@@ -389,7 +389,7 @@ static void consume_line(void *state_, char *line, unsigned
long len)
}
}
-static void combine_diff(const unsigned char *parent, unsigned int mode,
+static void combine_diff(const struct object_id *parent, unsigned int mode,
mmfile_t *result_file,
struct sline *sline, unsigned int cnt, int n,
int num_parent, int result_deleted,
@@ -897,7 +897,7 @@ static void show_combined_header(struct combine_diff_path
*elem,
int show_file_header)
{
struct diff_options *opt = rev-diffopt;
- int abbrev = DIFF_OPT_TST(opt, FULL_INDEX) ? 40 : DEFAULT_ABBREV;
+ int abbrev = DIFF_OPT_TST(opt, FULL_INDEX) ? GIT_SHA1_HEXSZ :
DEFAULT_ABBREV;
const char *a_prefix = opt-a_prefix ? opt-a_prefix : a/;
const char *b_prefix = opt-b_prefix ? opt-b_prefix : b/;
const char *c_meta = diff_get_color_opt(opt, DIFF_METAINFO);
@@ -914,11 +914,11 @@ static void show_combined_header(struct combine_diff_path
*elem,
, elem-path, line_prefix, c_meta, c_reset);
printf(%s%sindex , line_prefix, c_meta);
for (i = 0; i num_parent; i++) {
- abb = find_unique_abbrev(elem-parent[i].sha1,
+ abb = find_unique_abbrev(elem-parent[i].oid.hash,
abbrev);
printf(%s%s, i ? , : , abb);
}
- abb = find_unique_abbrev(elem-sha1, abbrev);
+ abb = find_unique_abbrev(elem-oid.hash, abbrev);
printf(..%s%s\n, abb, c_reset);
if (mode_differs) {
@@ -991,7 +991,7 @@ static void show_patch_diff(struct combine_diff_path *elem,
int num_parent,
/* Read the result of merge first */
if (!working_tree_file)
- result = grab_blob(elem-sha1,
[PATCH v2 04/10] archive.c: convert to use struct object_id
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
archive.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/archive.c b/archive.c
index 96057ed..d37c41d 100644
--- a/archive.c
+++ b/archive.c
@@ -101,7 +101,7 @@ static void setup_archive_check(struct git_attr_check
*check)
struct directory {
struct directory *up;
- unsigned char sha1[20];
+ struct object_id oid;
int baselen, len;
unsigned mode;
int stage;
@@ -177,7 +177,7 @@ static void queue_directory(const unsigned char *sha1,
d-stage = stage;
c-bottom = d;
d-len = sprintf(d-path, %.*s%s/, (int)base-len, base-buf,
filename);
- hashcpy(d-sha1, sha1);
+ hashcpy(d-oid.hash, sha1);
}
static int write_directory(struct archiver_context *c)
@@ -191,7 +191,7 @@ static int write_directory(struct archiver_context *c)
d-path[d-len - 1] = '\0'; /* no trailing slash */
ret =
write_directory(c) ||
- write_archive_entry(d-sha1, d-path, d-baselen,
+ write_archive_entry(d-oid.hash, d-path, d-baselen,
d-path + d-baselen, d-mode,
d-stage, c) != READ_TREE_RECURSIVE;
free(d);
@@ -354,7 +354,7 @@ static void parse_treeish_arg(const char **argv,
time_t archive_time;
struct tree *tree;
const struct commit *commit;
- unsigned char sha1[20];
+ struct object_id oid;
/* Remotes are only allowed to fetch actual refs */
if (remote !remote_allow_unreachable) {
@@ -362,15 +362,15 @@ static void parse_treeish_arg(const char **argv,
const char *colon = strchrnul(name, ':');
int refnamelen = colon - name;
- if (!dwim_ref(name, refnamelen, sha1, ref))
+ if (!dwim_ref(name, refnamelen, oid.hash, ref))
die(no such ref: %.*s, refnamelen, name);
free(ref);
}
- if (get_sha1(name, sha1))
+ if (get_sha1(name, oid.hash))
die(Not a valid object name);
- commit = lookup_commit_reference_gently(sha1, 1);
+ commit = lookup_commit_reference_gently(oid.hash, 1);
if (commit) {
commit_sha1 = commit-object.sha1;
archive_time = commit-date;
@@ -379,21 +379,21 @@ static void parse_treeish_arg(const char **argv,
archive_time = time(NULL);
}
- tree = parse_tree_indirect(sha1);
+ tree = parse_tree_indirect(oid.hash);
if (tree == NULL)
die(not a tree object);
if (prefix) {
- unsigned char tree_sha1[20];
+ struct object_id tree_oid;
unsigned int mode;
int err;
err = get_tree_entry(tree-object.sha1, prefix,
-tree_sha1, mode);
+tree_oid.hash, mode);
if (err || !S_ISDIR(mode))
die(current working directory is untracked);
- tree = parse_tree_indirect(tree_sha1);
+ tree = parse_tree_indirect(tree_oid.hash);
}
ar_args-tree = tree;
ar_args-commit_sha1 = commit_sha1;
--
2.2.1.209.g41e5f3a
--
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 v2 03/10] bisect.c: convert leaf functions to use struct object_id
Convert some constants to GIT_SHA1_HEXSZ.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
bisect.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/bisect.c b/bisect.c
index 8c6d843..10f5e57 100644
--- a/bisect.c
+++ b/bisect.c
@@ -15,7 +15,7 @@
static struct sha1_array good_revs;
static struct sha1_array skipped_revs;
-static unsigned char *current_bad_sha1;
+static struct object_id *current_bad_oid;
static const char *argv_checkout[] = {checkout, -q, NULL, --, NULL};
static const char *argv_show_branch[] = {show-branch, NULL, NULL};
@@ -404,8 +404,8 @@ static int register_ref(const char *refname, const unsigned
char *sha1,
int flags, void *cb_data)
{
if (!strcmp(refname, bad)) {
- current_bad_sha1 = xmalloc(20);
- hashcpy(current_bad_sha1, sha1);
+ current_bad_oid = xmalloc(sizeof(*current_bad_oid));
+ hashcpy(current_bad_oid-hash, sha1);
} else if (starts_with(refname, good-)) {
sha1_array_append(good_revs, sha1);
} else if (starts_with(refname, skip-)) {
@@ -564,7 +564,7 @@ static struct commit_list *skip_away(struct commit_list
*list, int count)
for (i = 0; cur; cur = cur-next, i++) {
if (i == index) {
- if (hashcmp(cur-item-object.sha1, current_bad_sha1))
+ if (hashcmp(cur-item-object.sha1,
current_bad_oid-hash))
return cur;
if (previous)
return previous;
@@ -607,7 +607,7 @@ static void bisect_rev_setup(struct rev_info *revs, const
char *prefix,
/* rev_argv.argv[0] will be ignored by setup_revisions */
argv_array_push(rev_argv, bisect_rev_setup);
- argv_array_pushf(rev_argv, bad_format, sha1_to_hex(current_bad_sha1));
+ argv_array_pushf(rev_argv, bad_format, oid_to_hex(current_bad_oid));
for (i = 0; i good_revs.nr; i++)
argv_array_pushf(rev_argv, good_format,
sha1_to_hex(good_revs.sha1[i]));
@@ -628,7 +628,7 @@ static void bisect_common(struct rev_info *revs)
}
static void exit_if_skipped_commits(struct commit_list *tried,
- const unsigned char *bad)
+ const struct object_id *bad)
{
if (!tried)
return;
@@ -637,12 +637,12 @@ static void exit_if_skipped_commits(struct commit_list
*tried,
The first bad commit could be any of:\n);
print_commit_list(tried, %s\n, %s\n);
if (bad)
- printf(%s\n, sha1_to_hex(bad));
+ printf(%s\n, oid_to_hex(bad));
printf(We cannot bisect more!\n);
exit(2);
}
-static int is_expected_rev(const unsigned char *sha1)
+static int is_expected_rev(const struct object_id *oid)
{
const char *filename = git_path(BISECT_EXPECTED_REV);
struct stat st;
@@ -658,7 +658,7 @@ static int is_expected_rev(const unsigned char *sha1)
return 0;
if (strbuf_getline(str, fp, '\n') != EOF)
- res = !strcmp(str.buf, sha1_to_hex(sha1));
+ res = !strcmp(str.buf, oid_to_hex(oid));
strbuf_release(str);
fclose(fp);
@@ -719,7 +719,7 @@ static struct commit **get_bad_and_good_commits(int *rev_nr)
struct commit **rev = xmalloc(len * sizeof(*rev));
int i, n = 0;
- rev[n++] = get_commit_reference(current_bad_sha1);
+ rev[n++] = get_commit_reference(current_bad_oid-hash);
for (i = 0; i good_revs.nr; i++)
rev[n++] = get_commit_reference(good_revs.sha1[i]);
*rev_nr = n;
@@ -729,8 +729,8 @@ static struct commit **get_bad_and_good_commits(int *rev_nr)
static void handle_bad_merge_base(void)
{
- if (is_expected_rev(current_bad_sha1)) {
- char *bad_hex = sha1_to_hex(current_bad_sha1);
+ if (is_expected_rev(current_bad_oid)) {
+ char *bad_hex = oid_to_hex(current_bad_oid);
char *good_hex = join_sha1_array_hex(good_revs, ' ');
fprintf(stderr, The merge base %s is bad.\n
@@ -750,7 +750,7 @@ static void handle_bad_merge_base(void)
static void handle_skipped_merge_base(const unsigned char *mb)
{
char *mb_hex = sha1_to_hex(mb);
- char *bad_hex = sha1_to_hex(current_bad_sha1);
+ char *bad_hex = sha1_to_hex(current_bad_oid-hash);
char *good_hex = join_sha1_array_hex(good_revs, ' ');
warning(the merge base between %s and [%s]
@@ -781,7 +781,7 @@ static void check_merge_bases(int no_checkout)
for (; result; result = result-next) {
const unsigned char *mb = result-item-object.sha1;
- if (!hashcmp(mb, current_bad_sha1)) {
+ if (!hashcmp(mb, current_bad_oid-hash)) {
[PATCH v2 10/10] apply: convert threeway_stage to object_id
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
builtin/apply.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 65b97ee..c2c8f39 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -208,7 +208,7 @@ struct patch {
struct patch *next;
/* three-way fallback result */
- unsigned char threeway_stage[3][20];
+ struct object_id threeway_stage[3];
};
static void free_fragment_list(struct fragment *list)
@@ -3424,11 +3424,11 @@ static int try_threeway(struct image *image, struct
patch *patch,
if (status) {
patch-conflicted_threeway = 1;
if (patch-is_new)
- hashclr(patch-threeway_stage[0]);
+ oidclr(patch-threeway_stage[0]);
else
- hashcpy(patch-threeway_stage[0], pre_sha1);
- hashcpy(patch-threeway_stage[1], our_sha1);
- hashcpy(patch-threeway_stage[2], post_sha1);
+ hashcpy(patch-threeway_stage[0].hash, pre_sha1);
+ hashcpy(patch-threeway_stage[1].hash, our_sha1);
+ hashcpy(patch-threeway_stage[2].hash, post_sha1);
fprintf(stderr, Applied patch to '%s' with conflicts.\n,
patch-new_name);
} else {
fprintf(stderr, Applied patch to '%s' cleanly.\n,
patch-new_name);
@@ -4184,14 +4184,14 @@ static void add_conflicted_stages_file(struct patch
*patch)
remove_file_from_cache(patch-new_name);
for (stage = 1; stage 4; stage++) {
- if (is_null_sha1(patch-threeway_stage[stage - 1]))
+ if (is_null_oid(patch-threeway_stage[stage - 1]))
continue;
ce = xcalloc(1, ce_size);
memcpy(ce-name, patch-new_name, namelen);
ce-ce_mode = create_ce_mode(mode);
ce-ce_flags = create_ce_flags(stage);
ce-ce_namelen = namelen;
- hashcpy(ce-sha1, patch-threeway_stage[stage - 1]);
+ hashcpy(ce-sha1, patch-threeway_stage[stage - 1].hash);
if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD) 0)
die(_(unable to add cache entry for %s),
patch-new_name);
}
--
2.2.1.209.g41e5f3a
--
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 v2 02/10] Define utility functions for object IDs.
There are several utility functions (hashcmp and friends) that are used
for comparing object IDs (SHA-1 values). Using these functions, which
take pointers to unsigned char, with struct object_id requires tiresome
access to the sha1 member, which bloats code and violates the desired
encapsulation. Provide wrappers around these functions for struct
object_id for neater, more maintainable code. Use the new constants to
avoid the hard-coded 20s and 40s throughout the original functions.
These functions simply call the underlying pointer-to-unsigned-char
versions to ensure that any performance improvements will be passed
through to the new functions.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
cache.h | 32
hex.c | 16 +---
2 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/cache.h b/cache.h
index 6582c35..95206a3 100644
--- a/cache.h
+++ b/cache.h
@@ -718,13 +718,13 @@ extern char *sha1_pack_name(const unsigned char *sha1);
extern char *sha1_pack_index_name(const unsigned char *sha1);
extern const char *find_unique_abbrev(const unsigned char *sha1, int);
-extern const unsigned char null_sha1[20];
+extern const unsigned char null_sha1[GIT_SHA1_RAWSZ];
static inline int hashcmp(const unsigned char *sha1, const unsigned char *sha2)
{
int i;
- for (i = 0; i 20; i++, sha1++, sha2++) {
+ for (i = 0; i GIT_SHA1_RAWSZ; i++, sha1++, sha2++) {
if (*sha1 != *sha2)
return *sha1 - *sha2;
}
@@ -732,20 +732,42 @@ static inline int hashcmp(const unsigned char *sha1,
const unsigned char *sha2)
return 0;
}
+static inline int oidcmp(const struct object_id *oid1, const struct object_id
*oid2)
+{
+ return hashcmp(oid1-hash, oid2-hash);
+}
+
static inline int is_null_sha1(const unsigned char *sha1)
{
return !hashcmp(sha1, null_sha1);
}
+static inline int is_null_oid(const struct object_id *oid)
+{
+ return !hashcmp(oid-hash, null_sha1);
+}
+
static inline void hashcpy(unsigned char *sha_dst, const unsigned char
*sha_src)
{
- memcpy(sha_dst, sha_src, 20);
+ memcpy(sha_dst, sha_src, GIT_SHA1_RAWSZ);
}
+
+static inline void oidcpy(struct object_id *dst, const struct object_id *src)
+{
+ hashcpy(dst-hash, src-hash);
+}
+
static inline void hashclr(unsigned char *hash)
{
- memset(hash, 0, 20);
+ memset(hash, 0, GIT_SHA1_RAWSZ);
}
+static inline void oidclr(struct object_id *oid)
+{
+ hashclr(oid-hash);
+}
+
+
#define EMPTY_TREE_SHA1_HEX \
4b825dc642cb6eb9a060e54bf8d69288fbee4904
#define EMPTY_TREE_SHA1_BIN_LITERAL \
@@ -952,8 +974,10 @@ extern int for_each_abbrev(const char *prefix,
each_abbrev_fn, void *);
* null-terminated string.
*/
extern int get_sha1_hex(const char *hex, unsigned char *sha1);
+extern int get_oid_hex(const char *hex, struct object_id *sha1);
extern char *sha1_to_hex(const unsigned char *sha1); /* static buffer
result! */
+extern char *oid_to_hex(const struct object_id *oid); /* same static buffer
as sha1_to_hex */
extern int read_ref_full(const char *refname, int resolve_flags,
unsigned char *sha1, int *flags);
extern int read_ref(const char *refname, unsigned char *sha1);
diff --git a/hex.c b/hex.c
index cfd9d72..899b74a 100644
--- a/hex.c
+++ b/hex.c
@@ -38,7 +38,7 @@ const signed char hexval_table[256] = {
int get_sha1_hex(const char *hex, unsigned char *sha1)
{
int i;
- for (i = 0; i 20; i++) {
+ for (i = 0; i GIT_SHA1_RAWSZ; i++) {
unsigned int val;
/*
* hex[1]=='\0' is caught when val is checked below,
@@ -56,15 +56,20 @@ int get_sha1_hex(const char *hex, unsigned char *sha1)
return 0;
}
+int get_oid_hex(const char *hex, struct object_id *oid)
+{
+ return get_sha1_hex(hex, oid-hash);
+}
+
char *sha1_to_hex(const unsigned char *sha1)
{
static int bufno;
- static char hexbuffer[4][41];
+ static char hexbuffer[4][GIT_SHA1_HEXSZ + 1];
static const char hex[] = 0123456789abcdef;
char *buffer = hexbuffer[3 ++bufno], *buf = buffer;
int i;
- for (i = 0; i 20; i++) {
+ for (i = 0; i GIT_SHA1_RAWSZ; i++) {
unsigned int val = *sha1++;
*buf++ = hex[val 4];
*buf++ = hex[val 0xf];
@@ -73,3 +78,8 @@ char *sha1_to_hex(const unsigned char *sha1)
return buffer;
}
+
+char *oid_to_hex(const struct object_id *oid)
+{
+ return sha1_to_hex(oid-hash);
+}
--
2.2.1.209.g41e5f3a
--
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 v2 09/10] patch-id: convert to use struct object_id
Convert some magic numbers to the new GIT_SHA1 constants.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
builtin/patch-id.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/builtin/patch-id.c b/builtin/patch-id.c
index 77db873..ba34dac 100644
--- a/builtin/patch-id.c
+++ b/builtin/patch-id.c
@@ -1,14 +1,14 @@
#include builtin.h
-static void flush_current_id(int patchlen, unsigned char *id, unsigned char
*result)
+static void flush_current_id(int patchlen, struct object_id *id, struct
object_id *result)
{
char name[50];
if (!patchlen)
return;
- memcpy(name, sha1_to_hex(id), 41);
- printf(%s %s\n, sha1_to_hex(result), name);
+ memcpy(name, oid_to_hex(id), GIT_SHA1_HEXSZ + 1);
+ printf(%s %s\n, oid_to_hex(result), name);
}
static int remove_space(char *line)
@@ -53,23 +53,23 @@ static int scan_hunk_header(const char *p, int *p_before,
int *p_after)
return 1;
}
-static void flush_one_hunk(unsigned char *result, git_SHA_CTX *ctx)
+static void flush_one_hunk(struct object_id *result, git_SHA_CTX *ctx)
{
- unsigned char hash[20];
+ unsigned char hash[GIT_SHA1_RAWSZ];
unsigned short carry = 0;
int i;
git_SHA1_Final(hash, ctx);
git_SHA1_Init(ctx);
/* 20-byte sum, with carry */
- for (i = 0; i 20; ++i) {
- carry += result[i] + hash[i];
- result[i] = carry;
+ for (i = 0; i GIT_SHA1_RAWSZ; ++i) {
+ carry += result-hash[i] + hash[i];
+ result-hash[i] = carry;
carry = 8;
}
}
-static int get_one_patchid(unsigned char *next_sha1, unsigned char *result,
+static int get_one_patchid(struct object_id *next_oid, struct object_id
*result,
struct strbuf *line_buf, int stable)
{
int patchlen = 0, found_next = 0;
@@ -77,7 +77,7 @@ static int get_one_patchid(unsigned char *next_sha1, unsigned
char *result,
git_SHA_CTX ctx;
git_SHA1_Init(ctx);
- hashclr(result);
+ oidclr(result);
while (strbuf_getwholeline(line_buf, stdin, '\n') != EOF) {
char *line = line_buf-buf;
@@ -93,7 +93,7 @@ static int get_one_patchid(unsigned char *next_sha1, unsigned
char *result,
else if (!memcmp(line, \\ , 2) 12 strlen(line))
continue;
- if (!get_sha1_hex(p, next_sha1)) {
+ if (!get_oid_hex(p, next_oid)) {
found_next = 1;
break;
}
@@ -143,7 +143,7 @@ static int get_one_patchid(unsigned char *next_sha1,
unsigned char *result,
}
if (!found_next)
- hashclr(next_sha1);
+ oidclr(next_oid);
flush_one_hunk(result, ctx);
@@ -152,15 +152,15 @@ static int get_one_patchid(unsigned char *next_sha1,
unsigned char *result,
static void generate_id_list(int stable)
{
- unsigned char sha1[20], n[20], result[20];
+ struct object_id oid, n, result;
int patchlen;
struct strbuf line_buf = STRBUF_INIT;
- hashclr(sha1);
+ oidclr(oid);
while (!feof(stdin)) {
- patchlen = get_one_patchid(n, result, line_buf, stable);
- flush_current_id(patchlen, sha1, result);
- hashcpy(sha1, n);
+ patchlen = get_one_patchid(n, result, line_buf, stable);
+ flush_current_id(patchlen, oid, result);
+ oidcpy(oid, n);
}
strbuf_release(line_buf);
}
--
2.2.1.209.g41e5f3a
--
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 00/10] Use a structure for object IDs.
On Wed, Mar 11, 2015 at 01:35:06PM -0700, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: 4. We continue to support working with SHA-1s declared to be (unsigned char *) in some performance-critical code, even as we migrate most other code to using SHA-1s embedded within a (struct object_id). This will cost some duplication of code. To accept this approach, we would need an idea of *how much* code duplication would be needed. E.g., how many functions will need both (unsigned char *) versions and (struct object_id *) versions? Ideally, only the ones that knows the underlying hash function is SHA-1 (i.e. anybody who mentions git_SHA_CTX), moves bytes from/to in-core object name field and raw range of bytes (e.g. sha1hash()); everybody else like hashcpy() and hashcmp() should be able to do its thing only on structs and a generic-looking constant that denotes how many bytes there are in the hash (or even sizeof(struct oid)). I do not know what kind of code duplication you are worried about, though. If a callee needs unsigned char *, the caller that has a struct object_id *o should pass o-hash to the callee. That's the plan. My goal (which may or may not be achievable) is to make hashcpy, hashcmp, and similar functions an implementation detail of struct object_id functions. If we have to use o-hash somewhere, okay. I'm much more interested in practicality than theoretical purity. I want these changes to provide easier-to-change, more maintainable code, not more complex and difficult code. And please do not suggest switching to C++; all it would do to overload these into a single name is to make the callers harder to read. I'm not considering that. I've attempted to compile git with g++ before as an idle curiosity, and I gave up almost immediately because it looked like a bunch of work. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
[PATCH v2 00/10] Use a structure for object IDs.
This is a patch series to convert some of the relevant uses of unsigned char [20] to struct object_id. The goal of this series to improve type-checking in the codebase and to make it easier to move to a different hash function if the project decides to do that. There should be no functional change from this patch series. I've tried to adopt most of the suggestions where possible without major reworking. Changes since v1: * Call the struct member hash. * Convert some additional magic numbers to be based off the constants GIT_SHA1_RAWSZ and GIT_SHA1_HEXSZ. Introduce variables where this makes sense. * Define GIT_SHA1_HEXSZ in terms of GIT_SHA1_RAWSZ. * Move the definition of struct object_id to cache.h. No new #includes are required as a result. * Use better names for arguments to oidcmp. * Convert one or two structs that were missed last time. You can see this series on the object-id branch (may be rebased) at https://github.com/bk2204/git.git https://git.crustytoothpaste.net/git/bmc/git.git Both repositories are pushed at the same time. brian m. carlson (10): Define a structure for object IDs. Define utility functions for object IDs. bisect.c: convert leaf functions to use struct object_id archive.c: convert to use struct object_id zip: use GIT_SHA1_HEXSZ for trailers bulk-checkin.c: convert to use struct object_id diff: convert struct combine_diff_path to object_id commit: convert parts to struct object_id patch-id: convert to use struct object_id apply: convert threeway_stage to object_id archive-zip.c | 4 ++-- archive.c | 22 ++--- bisect.c | 40 +++--- builtin/apply.c| 14 +++--- builtin/patch-id.c | 34 - bulk-checkin.c | 12 ++-- cache.h| 40 ++ combine-diff.c | 56 +++--- commit.c | 56 +- commit.h | 4 ++-- diff-lib.c | 10 +- diff.h | 5 +++-- hex.c | 16 +--- log-tree.c | 2 +- send-pack.c| 2 +- shallow.c | 8 tree-diff.c| 10 +- upload-pack.c | 2 +- 18 files changed, 192 insertions(+), 145 deletions(-) -- 2.2.1.209.g41e5f3a -- 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 v2 01/10] Define a structure for object IDs.
Many places throughout the code use unsigned char [20] to store object IDs
(SHA-1 values). This leads to lots of hardcoded numbers throughout the
codebase. It also leads to confusion about the purposes of a buffer.
Introduce a structure for object IDs. This allows us to obtain the benefits
of compile-time checking for misuse. The structure is expected to remain
the same size and have the same alignment requirements on all known
platforms, compared to the array of unsigned char, although this is not
required for correctness.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
cache.h | 8
1 file changed, 8 insertions(+)
diff --git a/cache.h b/cache.h
index 761c570..6582c35 100644
--- a/cache.h
+++ b/cache.h
@@ -43,6 +43,14 @@ int git_deflate_end_gently(git_zstream *);
int git_deflate(git_zstream *, int flush);
unsigned long git_deflate_bound(git_zstream *, unsigned long);
+/* The length in bytes and in hex digits of an object name (SHA-1 value). */
+#define GIT_SHA1_RAWSZ 20
+#define GIT_SHA1_HEXSZ (2 * GIT_SHA1_RAWSZ)
+
+struct object_id {
+ unsigned char hash[GIT_SHA1_RAWSZ];
+};
+
#if defined(DT_UNKNOWN) !defined(NO_D_TYPE_IN_DIRENT)
#define DTYPE(de) ((de)-d_type)
#else
--
2.2.1.209.g41e5f3a
--
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 v2 08/10] commit: convert parts to struct object_id
Convert struct commit_graft and necessary local parts of commit.c.
Also, convert several constants based on the hex length of an SHA-1 to
use GIT_SHA1_HEXSZ, and move several magic constants into variables for
readability.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
commit.c | 56 ++--
commit.h | 4 ++--
log-tree.c| 2 +-
send-pack.c | 2 +-
shallow.c | 8
upload-pack.c | 2 +-
6 files changed, 39 insertions(+), 35 deletions(-)
diff --git a/commit.c b/commit.c
index a8c7577..2d9de80 100644
--- a/commit.c
+++ b/commit.c
@@ -55,12 +55,12 @@ struct commit *lookup_commit(const unsigned char *sha1)
struct commit *lookup_commit_reference_by_name(const char *name)
{
- unsigned char sha1[20];
+ struct object_id oid;
struct commit *commit;
- if (get_sha1_committish(name, sha1))
+ if (get_sha1_committish(name, oid.hash))
return NULL;
- commit = lookup_commit_reference(sha1);
+ commit = lookup_commit_reference(oid.hash);
if (parse_commit(commit))
return NULL;
return commit;
@@ -99,7 +99,7 @@ static int commit_graft_alloc, commit_graft_nr;
static const unsigned char *commit_graft_sha1_access(size_t index, void *table)
{
struct commit_graft **commit_graft_table = table;
- return commit_graft_table[index]-sha1;
+ return commit_graft_table[index]-oid.hash;
}
static int commit_graft_pos(const unsigned char *sha1)
@@ -110,7 +110,7 @@ static int commit_graft_pos(const unsigned char *sha1)
int register_commit_graft(struct commit_graft *graft, int ignore_dups)
{
- int pos = commit_graft_pos(graft-sha1);
+ int pos = commit_graft_pos(graft-oid.hash);
if (0 = pos) {
if (ignore_dups)
@@ -138,22 +138,23 @@ struct commit_graft *read_graft_line(char *buf, int len)
/* The format is just Commit Parent1 Parent2 ...\n */
int i;
struct commit_graft *graft = NULL;
+ const int entry_size = GIT_SHA1_HEXSZ + 1;
while (len isspace(buf[len-1]))
buf[--len] = '\0';
if (buf[0] == '#' || buf[0] == '\0')
return NULL;
- if ((len + 1) % 41)
+ if ((len + 1) % entry_size)
goto bad_graft_data;
- i = (len + 1) / 41 - 1;
- graft = xmalloc(sizeof(*graft) + 20 * i);
+ i = (len + 1) / entry_size - 1;
+ graft = xmalloc(sizeof(*graft) + GIT_SHA1_RAWSZ * i);
graft-nr_parent = i;
- if (get_sha1_hex(buf, graft-sha1))
+ if (get_oid_hex(buf, graft-oid))
goto bad_graft_data;
- for (i = 40; i len; i += 41) {
+ for (i = GIT_SHA1_HEXSZ; i len; i += entry_size) {
if (buf[i] != ' ')
goto bad_graft_data;
- if (get_sha1_hex(buf + i + 1, graft-parent[i/41]))
+ if (get_sha1_hex(buf + i + 1, graft-parent[i/entry_size].hash))
goto bad_graft_data;
}
return graft;
@@ -302,39 +303,42 @@ int parse_commit_buffer(struct commit *item, const void
*buffer, unsigned long s
{
const char *tail = buffer;
const char *bufptr = buffer;
- unsigned char parent[20];
+ struct object_id parent;
struct commit_list **pptr;
struct commit_graft *graft;
+ const int tree_entry_len = GIT_SHA1_HEXSZ + 5;
+ const int parent_entry_len = GIT_SHA1_HEXSZ + 7;
if (item-object.parsed)
return 0;
item-object.parsed = 1;
tail += size;
- if (tail = bufptr + 46 || memcmp(bufptr, tree , 5) || bufptr[45] !=
'\n')
+ if (tail = bufptr + tree_entry_len + 1 || memcmp(bufptr, tree , 5) ||
+ bufptr[tree_entry_len] != '\n')
return error(bogus commit object %s,
sha1_to_hex(item-object.sha1));
- if (get_sha1_hex(bufptr + 5, parent) 0)
+ if (get_sha1_hex(bufptr + 5, parent.hash) 0)
return error(bad tree pointer in commit %s,
sha1_to_hex(item-object.sha1));
- item-tree = lookup_tree(parent);
- bufptr += 46; /* tree + hex sha1 + \n */
+ item-tree = lookup_tree(parent.hash);
+ bufptr += tree_entry_len + 1; /* tree + hex sha1 + \n */
pptr = item-parents;
graft = lookup_commit_graft(item-object.sha1);
- while (bufptr + 48 tail !memcmp(bufptr, parent , 7)) {
+ while (bufptr + parent_entry_len tail !memcmp(bufptr, parent ,
7)) {
struct commit *new_parent;
- if (tail = bufptr + 48 ||
- get_sha1_hex(bufptr + 7, parent) ||
- bufptr[47] != '\n')
+ if (tail = bufptr + parent_entry_len + 1 ||
+ get_sha1_hex(bufptr + 7, parent.hash) ||
+ bufptr[parent_entry_len] != '\n')
return
[PATCH v2 06/10] bulk-checkin.c: convert to use struct object_id
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
bulk-checkin.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/bulk-checkin.c b/bulk-checkin.c
index 0c4b8a7..c80e503 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -24,7 +24,7 @@ static struct bulk_checkin_state {
static void finish_bulk_checkin(struct bulk_checkin_state *state)
{
- unsigned char sha1[20];
+ struct object_id oid;
struct strbuf packname = STRBUF_INIT;
int i;
@@ -36,11 +36,11 @@ static void finish_bulk_checkin(struct bulk_checkin_state
*state)
unlink(state-pack_tmp_name);
goto clear_exit;
} else if (state-nr_written == 1) {
- sha1close(state-f, sha1, CSUM_FSYNC);
+ sha1close(state-f, oid.hash, CSUM_FSYNC);
} else {
- int fd = sha1close(state-f, sha1, 0);
- fixup_pack_header_footer(fd, sha1, state-pack_tmp_name,
-state-nr_written, sha1,
+ int fd = sha1close(state-f, oid.hash, 0);
+ fixup_pack_header_footer(fd, oid.hash, state-pack_tmp_name,
+state-nr_written, oid.hash,
state-offset);
close(fd);
}
@@ -48,7 +48,7 @@ static void finish_bulk_checkin(struct bulk_checkin_state
*state)
strbuf_addf(packname, %s/pack/pack-, get_object_directory());
finish_tmp_packfile(packname, state-pack_tmp_name,
state-written, state-nr_written,
- state-pack_idx_opts, sha1);
+ state-pack_idx_opts, oid.hash);
for (i = 0; i state-nr_written; i++)
free(state-written[i]);
--
2.2.1.209.g41e5f3a
--
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 v2 05/10] zip: use GIT_SHA1_HEXSZ for trailers
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net --- archive-zip.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/archive-zip.c b/archive-zip.c index 4bde019..b669e50 100644 --- a/archive-zip.c +++ b/archive-zip.c @@ -427,12 +427,12 @@ static void write_zip_trailer(const unsigned char *sha1) copy_le16(trailer.entries, zip_dir_entries); copy_le32(trailer.size, zip_dir_offset); copy_le32(trailer.offset, zip_offset); - copy_le16(trailer.comment_length, sha1 ? 40 : 0); + copy_le16(trailer.comment_length, sha1 ? GIT_SHA1_HEXSZ : 0); write_or_die(1, zip_dir, zip_dir_offset); write_or_die(1, trailer, ZIP_DIR_TRAILER_SIZE); if (sha1) - write_or_die(1, sha1_to_hex(sha1), 40); + write_or_die(1, sha1_to_hex(sha1), GIT_SHA1_HEXSZ); } static void dos_time(time_t *time, int *dos_date, int *dos_time) -- 2.2.1.209.g41e5f3a -- 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 6/7] t5541: move run_with_cmdline_limit to test-lib.sh
On Fri, Mar 13, 2015 at 12:53 AM, Jeff King p...@peff.net wrote:
We use this to test http pushing with a restricted
commandline. Other scripts (like t5551, which does http
fetching) will want to use it, too.
Signed-off-by: Jeff King p...@peff.net
---
As we discussed a while ago, this is the exact same code that
run_with_limited_stack uses in t7004. However, I think they are
conceptually two different things, and I could imagine a platform where
they have distinct implementations. So I did not refactor t7004 to make
use of this.
Perhaps this commentary should be moved to the commit message so that
the next person who notices that run_with_limited_stack() is the same
will understand why it was left alone.
t/t5541-http-push-smart.sh | 6 --
t/test-lib.sh | 6 ++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t5541-http-push-smart.sh b/t/t5541-http-push-smart.sh
index d2c681e..1ecb588 100755
--- a/t/t5541-http-push-smart.sh
+++ b/t/t5541-http-push-smart.sh
@@ -324,12 +324,6 @@ test_expect_success 'push into half-auth-complete
requires password' '
test_cmp expect actual
'
-run_with_limited_cmdline () {
- (ulimit -s 128 $@)
-}
-
-test_lazy_prereq CMDLINE_LIMIT 'run_with_limited_cmdline true'
-
test_expect_success CMDLINE_LIMIT 'push 2000 tags over http' '
sha1=$(git rev-parse HEAD)
test_seq 2000 |
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 7dd4b4d..9914d3e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1062,3 +1062,9 @@ test_lazy_prereq UNZIP '
$GIT_UNZIP -v
test $? -ne 127
'
+
+run_with_limited_cmdline () {
+ (ulimit -s 128 $@)
+}
+
+test_lazy_prereq CMDLINE_LIMIT 'run_with_limited_cmdline true'
--
2.3.2.472.geadab3c
--
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
Is it possible get the tag name of working copy in Git?
I want to use make file auto generate the revision number of working copy from the tag name in git. So as questioned in subject, I have tried to use 'git describe', it works well in most case, and the output is good match my requirement. Problem is: when there are multiple tags on same one commit, if check out one of these tag, the 'git describe' only be able to return the most new created tag name in that commit, instead of the real checked out tag. Seems 'git-describe' capture the most recent tag name by create sequence. I expect add an argument to 'git-describe' to make it get the most recent tag name according to checkout status when multiple tags on one commit. Is there any suggestion? Thanks! -- Chen Chang -- 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: [Documentation] Submitting Patches
Cody Taylor cody.tay...@maternityneighborhood.com writes: Anyway, this brings up the point that `git send-email` should at least get a mention in the Documentation/SubmittingPatches file. Likely the best place for this is a paragraph after `git format-patch` is mentioned in section 4 (Sending your patches.). [removed others who are not to be blamed for the lack of doc from cc] I very much agree with that---actually I am somewhat surprised that the documentation doesn't do so already. Perhaps something like this? -- 8 -- Subject: SubmittingPatches: nudge to use send-email In step (4) Sending your patches, we instruct users to do an inline patch, avoid breaking whitespaces, avoid attachments, use [PATCH v2] for second round, etc., all of which send-email knows how to do. Mention send-email at least once to gently nudge the user to (learn to) use it. Suggested-by: Cody Taylor cody.tay...@maternityneighborhood.com Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/SubmittingPatches | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index ef0eeb4..2b10569 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -154,7 +154,8 @@ you send off a message in the correct encoding. WARNING: Be wary of your MUAs word-wrap corrupting your patch. Do not cut-n-paste your patch; you can -lose tabs that way if you are not careful. +lose tabs that way if you are not careful. If you can use the +git send-email command, please do so. It is a common convention to prefix your subject line with [PATCH]. This lets people easily distinguish patches from other -- 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
[Documentation] Submitting Patches
Apologies for the poorly formatted e-mail. I realized after I sent the
message that the `git send-mail` command was an option. I was trying
to use python to modify the e-mail before sending it, and the three
different From fields got mumbled.
Anyway, this brings up the point that `git send-email` should at least
get a mention in the Documentation/SubmittingPatches file. Likely
the best place for this is a paragraph after `git format-patch` is
mentioned in section 4 (Sending your patches.).
On Fri, Mar 13, 2015 at 2:16 AM, Junio C Hamano gits...@pobox.com wrote:
Cody A Taylor cody.tay...@maternityneighborhood.com writes:
From c861d5cb401110ce7d86b76c1eaa8e89e80f484e Mon Sep 17 00:00:00 2001
From: Cody A Taylor codemiste...@yahoo.com
Date: Thu, 12 Mar 2015 20:36:44 -0400
Subject: [PATCH] git prompt: Use toplevel to find untracked files.
All of the above four lines are unwanted in the e-mail body.
* The first line is a separating line to make format-patch output
look like a mbox file, and does not even belong to this patch.
* From: line, when you are not relaying somebody else's patch,
should not be necessary, as long as you set up your MUA correctly
so that the e-mail shows a correct From: in its header.
* Date: is the same; unless you are relaying somebody else's patch,
in which case you might want to preserve the author timestamp,
the first time _we_ the recipients see your patch matters more,
which should be available from the e-mail header.
* Subject: should be in the e-mail header. Sometimes when sending
a patch to an ongoing discussion that has its own subject, it is
handy to be able to override the title with in-body Subject:, but
this patch submission is not such a case. The subjects are the
same in the fourth line in the body (which should be dropped) and
in the header anyway in this message, so please edit it out.
In short
(1) If you cannot convince your mailer to show your @yahoo.com
address on the e-mail header From: line, then having the
in-body From: line above (i.e. the second line) is OK as a
workaround. We however would prefer if you didn't.
(2) Edit the other three lines out.
The __git_ps1() prompt function would not show an untracked
state when the current working directory was not a parent of
the untracked file.
Good find, and nicely explained. I wonder if we can add a test
or two to t9903-bash-prompt.sh?
The patch itself makes sense. Thanks.
Signed-off-by: Cody A Taylor codemiste...@yahoo.com
---
contrib/completion/git-prompt.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index 214e859f99e7..f18aedc73be9 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -487,7 +487,7 @@ __git_ps1 ()
if [ -n ${GIT_PS1_SHOWUNTRACKEDFILES-} ]
[ $(git config --bool bash.showUntrackedFiles) !=
false ]
-git ls-files --others --exclude-standard --error-unmatch
-- '*' /dev/null 2/dev/null
+git ls-files --others --exclude-standard --error-unmatch
-- ':/*' /dev/null 2/dev/null
then
u=%${ZSH_VERSION+%}
fi
--
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] git prompt: Use toplevel to find untracked files.
Cody A Taylor cody.tay...@maternityneighborhood.com writes:
From c861d5cb401110ce7d86b76c1eaa8e89e80f484e Mon Sep 17 00:00:00 2001
From: Cody A Taylor codemiste...@yahoo.com
Date: Thu, 12 Mar 2015 20:36:44 -0400
Subject: [PATCH] git prompt: Use toplevel to find untracked files.
All of the above four lines are unwanted in the e-mail body.
* The first line is a separating line to make format-patch output
look like a mbox file, and does not even belong to this patch.
* From: line, when you are not relaying somebody else's patch,
should not be necessary, as long as you set up your MUA correctly
so that the e-mail shows a correct From: in its header.
* Date: is the same; unless you are relaying somebody else's patch,
in which case you might want to preserve the author timestamp,
the first time _we_ the recipients see your patch matters more,
which should be available from the e-mail header.
* Subject: should be in the e-mail header. Sometimes when sending
a patch to an ongoing discussion that has its own subject, it is
handy to be able to override the title with in-body Subject:, but
this patch submission is not such a case. The subjects are the
same in the fourth line in the body (which should be dropped) and
in the header anyway in this message, so please edit it out.
In short
(1) If you cannot convince your mailer to show your @yahoo.com
address on the e-mail header From: line, then having the
in-body From: line above (i.e. the second line) is OK as a
workaround. We however would prefer if you didn't.
(2) Edit the other three lines out.
The __git_ps1() prompt function would not show an untracked
state when the current working directory was not a parent of
the untracked file.
Good find, and nicely explained. I wonder if we can add a test
or two to t9903-bash-prompt.sh?
The patch itself makes sense. Thanks.
Signed-off-by: Cody A Taylor codemiste...@yahoo.com
---
contrib/completion/git-prompt.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index 214e859f99e7..f18aedc73be9 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -487,7 +487,7 @@ __git_ps1 ()
if [ -n ${GIT_PS1_SHOWUNTRACKEDFILES-} ]
[ $(git config --bool bash.showUntrackedFiles) != false
]
-git ls-files --others --exclude-standard --error-unmatch --
'*' /dev/null 2/dev/null
+git ls-files --others --exclude-standard --error-unmatch --
':/*' /dev/null 2/dev/null
then
u=%${ZSH_VERSION+%}
fi
--
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 1/4] git-credential-store: support multiple credential files
On Wed, Mar 11, 2015 at 02:49:10PM +0800, Paul Tan wrote: Previously, git-credential-store only supported storing credentials in a single file: ~/.git-credentials. In order to support the XDG base directory specification[1], git-credential-store needs to be able to lookup and erase credentials from multiple files, as well as to pick the appropriate file to write to so that the credentials can be found on subsequent lookups. I looked over the code here and in the second patch, and I didn't see any real problems. Thanks for iterating on this. Two minor nits, that might not even be worth addressing: +static void store_credential(const struct string_list *fns, struct credential *c, + const char *default_fn) I think you could even get away without passing default_fn here, and just use the rule the first file in the list is the default. Unless you are anticipating ever passing something else, but I couldn't think of a case where that would be useful. + struct string_list fns = STRING_LIST_INIT_NODUP; This is declared NODUP... - if (!file) + if (file) + string_list_append_nodup(fns, file); So you can just call the regular string_list_append here (the idea of declaring the list as DUP or NODUP is that the callers do not have to care; string_list_append does the right thing). -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 v2 01/10] Define a structure for object IDs.
Duy Nguyen pclo...@gmail.com writes:
You mean if it came in pack, offset format, convert it down to
sha1 until the last second that it is needed (e.g. need to put
that in a tree object in order to compute the object name of the
containing tree object)?
I picked my words poorly. It should be pack, the index in pack
instead of the _byte_ offset.
Thanks for a clarification, but I do not think it affects the main
point of the discussion very much. If we use union in struct,
where we can store either an SHA-1 hash or some other identifying
information for the object, but not both, then at some point you
would need to convert pack, nth to sha-1 in a codepath that
needs the sha-1 hash value (e.g. if the object A, that is known to
you as pack, nth, is placed in a tree object B, you need the
object name of A in sha-1 representation in order to compute the
object name of the tree object B. You can choose to keep it in
pack, nth form in struct object_id { union } and look up the
sha-1 from the pack index every time, or you can choose to give
up the pack, nth form and upgrade the struct object_id to store
sha-1 at that point.
If you keep both pack, nth *and* sha-1 in struct object_id at
the same time, you can choose whichever is convenient, but it would
bloat everything in core. Not just it bloats struct object and
its subclasses, the in-core index entries, which is what I meant
by ...
Unless you fix that union in struct assumption, that is.
... this.
To me, pack, offset information smells to belong more to a struct
object (or its subclass) as an optional annotation---when a caller
is asked to parse_object(), you would bypass the sha1_read_file()
that goes and looks the object name up from the list of pack .idx
and instead go there straight using that annotation.
For pack v4, commits and trees can be encoded this way.
Even if your in-pack representation of a commit object allowed to
store the tree pointer in pack, nth format, its object name must
be computed as if you have the commit object in the traditional
format and computed the hash of that (together with the standard
type size\0 header), and at that point, you need the contained
object's name in sha-1 format (imagine how you would implement the
commit-tree command). Hence, I do not think the v4 encoding changes
the discussion very much. I see the primary value of v4 encoding is
to shorten the length of various fields take on-disk and in-pack.
If it were pack, offset, it could be argued that it would also be
faster to get to the packed data in the packfile, and going from
pack, nth to the .idx file and then going to the location in the
data in the packfile would be faster than going from sha-1 to a
particular pack and its in-pack offset, with the difference of cost
around log(n)*m where n is the number of objects in a pack and m is
the total number of packs in the repository.
It is true that nth format (force that the referred-to object
lives in the same pack as the referrer) can help speed up
interpretation of extended SHA-1 expression, e.g. v1.0^0:t, which
can read v1.0 tag in v4 format, find the nth info for the commit
pointed by the tag and get to that data in the pack, find the nth
info for the top-tree recorded in that commit and directly get to
the data of that tree, and then find the entry for t, which will
give the object name for that subtree again in nth format, and at
that point you can find the sha-1 of that final object, without
having to know any object names of the intermediate objects
(i.e. you must start from sha-1 of the tag you obtain from the
refs API, but you didn't use the object name of the commit and its
top-level tree). So for such a codepath, I would say it would be
sufficient to use a union in struct people have been envisioning
and convert pack, nth to sha-1 when the latter form becomes
necessary for the first time for the object.
Anyway, wouldn't this be all academic? I do not see how you would
keep the object name in the pack, nth format in-core, as the
obj_hash[] is a hashtable keyed by sha-1, and even when we switch
to a different hash, I cannot see how such a table to ensure the
singleton-ness of in-core objects can be keyed sometimes by hash
and by pack, nth in some other time.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] upload-pack: fix transfer.hiderefs over smart-http
Jeff King p...@peff.net writes:
When upload-pack advertises the refs (either for a normal,
non-stateless request, or for the initial contact in a
stateless one), we call for_each_ref with the send_ref
function as its callback. send_ref, in turn, calls
mark_our_ref, which checks whether the ref is hidden, and
sets OUR_REF or HIDDEN_REF on the object as appropriate. If
it is hidden, mark_our_ref also returns 1 to signal
send_ref that the ref should not be advertised.
If we are not advertising refs, (i.e., the follow-up
invocation by an http client to send its want lines), we
use mark_our_ref directly as a callback to for_each_ref. Its
marking does the right thing, but when it then returns 1
to for_each_ref, the latter interprets this as an error and
stops iterating. As a result, we skip marking all of the
refs that come lexicographically after it. Any want lines
from the client asking for those objects will fail, as they
were not properly marked with OUR_REF.
Nicely described in a way that the reason of the breakage and the
fix is obvious to those who already know what the codepath is
supposed to be doing.
To solve this, we introduce a wrapper callback around
mark_our_ref which always returns 0 (even if the ref is
hidden, we want to keep iterating). We also tweak the
signature of mark_our_ref to exclude unnecessary parameters
that were present only to conform to the callback interface.
This should make it less likely for somebody to accidentally
use it as a callback in the future.
I especially love this kind of future-proofing ;-).
Thanks, will queue.
Signed-off-by: Jeff King p...@peff.net
---
t/t5551-http-fetch-smart.sh | 11 +++
upload-pack.c | 14 ++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh
index 6cbc12d..b970773 100755
--- a/t/t5551-http-fetch-smart.sh
+++ b/t/t5551-http-fetch-smart.sh
@@ -213,6 +213,17 @@ test_expect_success 'cookies stored in http.cookiefile
when http.savecookies set
test_cmp expect_cookies.txt cookies_tail.txt
'
+test_expect_success 'transfer.hiderefs works over smart-http' '
+ test_commit hidden
+ test_commit visible
+ git push public HEAD^:refs/heads/a HEAD:refs/heads/b
+ git --git-dir=$HTTPD_DOCUMENT_ROOT_PATH/repo.git \
+ config transfer.hiderefs refs/heads/a
+ git clone --bare $HTTPD_URL/smart/repo.git hidden.git
+ test_must_fail git -C hidden.git rev-parse --verify a
+ git -C hidden.git rev-parse --verify b
+'
+
test_expect_success EXPENSIVE 'create 50,000 tags in the repo' '
(
cd $HTTPD_DOCUMENT_ROOT_PATH/repo.git
diff --git a/upload-pack.c b/upload-pack.c
index b531a32..c8e8713 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -681,7 +681,7 @@ static void receive_needs(void)
}
/* return non-zero if the ref is hidden, otherwise 0 */
-static int mark_our_ref(const char *refname, const unsigned char *sha1, int
flag, void *cb_data)
+static int mark_our_ref(const char *refname, const unsigned char *sha1)
{
struct object *o = lookup_unknown_object(sha1);
@@ -695,6 +695,12 @@ static int mark_our_ref(const char *refname, const
unsigned char *sha1, int flag
return 0;
}
+static int check_ref(const char *refname, const unsigned char *sha1, int
flag, void *cb_data)
+{
+ mark_our_ref(refname, sha1);
+ return 0;
+}
+
static void format_symref_info(struct strbuf *buf, struct string_list
*symref)
{
struct string_list_item *item;
@@ -713,7 +719,7 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
const char *refname_nons = strip_namespace(refname);
unsigned char peeled[20];
- if (mark_our_ref(refname, sha1, flag, NULL))
+ if (mark_our_ref(refname, sha1))
return 0;
if (capabilities) {
@@ -767,8 +773,8 @@ static void upload_pack(void)
advertise_shallow_grafts(1);
packet_flush(1);
} else {
- head_ref_namespaced(mark_our_ref, NULL);
- for_each_namespaced_ref(mark_our_ref, NULL);
+ head_ref_namespaced(check_ref, NULL);
+ for_each_namespaced_ref(check_ref, NULL);
}
string_list_clear(symref, 1);
if (advertise_refs)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] reset: enable '-' short-hand for previous branch
On Tue, Mar 10, 2015 at 6:03 PM, Sudhanshu Shekhar
sudshekha...@gmail.com wrote:
[PATCH v3 1/2] reset: enable '-' short-hand for previous branch
This should be v4, I think, not v3.
git reset -' will reset to the previous branch. It will behave similar
to @{-1} except when a file named '@{-1}' is present.
The way this is phrased, the reader is left hanging: What happens
when a file named @{-1} is present?
To refer to a file named '-', use ./- or the -- flag.
A documentation update to reflect this change would be appropriate.
See, for instance, 696acf45 (checkout: implement - abbreviation, add
docs and tests; 2009-01-17).
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Helped-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Sudhanshu Shekhar sudshekha...@gmail.com
---
Eric, I have added a user_input variable to record the input entered
by the user. This way I can avoid the multiple 'if' clauses. Thank you
for the suggestion.
I have also removed the unrelated change that I had unintentionally
committed. I am sending this patch on the thread for further review.
Once both the patches are reviewed and accepted, I will create a new
mail for it. Hope that is okay.
Please wrap commentary to about 72 columns, just as you would the
commit message, rather than typing it all on a single line. (I wrapped
it manually here in order to reply to it.)
diff --git a/builtin/reset.c b/builtin/reset.c
index 4c08ddc..b428241 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -192,6 +192,8 @@ static void parse_args(struct pathspec *pathspec,
{
const char *rev = HEAD;
unsigned char unused[20];
+ int substituted_minus = 0;
+ char *user_input = argv[0];
You're assigning a 'const char *' to a 'char *'. The compiler should
have warned about it.
This variable name is not as expressive as it could be. Try to name
the variable after what you expect it to represent, for instance
maybe_rev or rev_or_path or something more suitable. Even
orig_argv0 would be more informative than user_input.
/*
* Possible arguments are:
*
@@ -205,6 +207,10 @@ static void parse_args(struct pathspec *pathspec,
*/
if (argv[0]) {
+ if (!strcmp(argv[0], -)) {
+ argv[0] = @{-1};
+ substituted_minus = 1;
+ }
if (!strcmp(argv[0], --)) {
argv++; /* reset to HEAD, possibly with paths */
} else if (argv[1] !strcmp(argv[1], --)) {
@@ -222,9 +228,12 @@ static void parse_args(struct pathspec *pathspec,
* Ok, argv[0] looks like a commit/tree; it should not
* be a filename.
*/
- verify_non_filename(prefix, argv[0]);
+ verify_non_filename(prefix, user_input);
rev = *argv++;
} else {
+ /* We were treating - as a commit and not a file */
+ if (substituted_minus)
+ argv[0] = -;
In my review of the previous version[1], I mentioned that it was ugly
to muck with argv[0]; moreover that it was particularly ugly to have
to muck with it multiple times, undoing and redoing assignments.
Although you've eliminated some reassignments via 'user_input', my
intent, by asking if you could rework the logic, was to prompt you to
take a couple steps back and examine the overall logic of the function
more closely. The munging of argv[0] is effectively a fragile and
undesirable band-aid approach. It is possible to support '-' as an
alias for '@{-1}' without having to resort to such kludges at all.
One other concern: When there is no previous branch, and no file named
-, then 'git reset -' misleadingly complains bad flag '-' used
after filename, rather than the more appropriate ambiguous argument
'-': unknown revision or path.
[1]: http://article.gmane.org/gmane.comp.version-control.git/265255
/* Otherwise we treat this as a filename */
verify_filename(prefix, argv[0], 1);
}
--
2.3.1.278.ge5c7b1f.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is it possible get the tag name of working copy in Git?
On 03/13/2015 08:08 AM, chen chang wrote: I want to use make file auto generate the revision number of working copy from the tag name in git. You should have the tag name, as it is set up before running make, and probably feed into both git checkout tagXXYYXX and the Makefile. If you want the version number, what is this ? Git has a sha value, you can git it like this: git rev-parse HEAD | cut -b 1-9 HTH -- 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: [Documentation/RFC] Submitting Patches
Junio C Hamano gits...@pobox.com wrote: Subject: SubmittingPatches: nudge to use send-email In step (4) Sending your patches, we instruct users to do an inline patch, avoid breaking whitespaces, avoid attachments, use [PATCH v2] for second round, etc., all of which send-email knows how to do. The idea that `git send-email` does all of the suggestions really should be reflected in the documentation. Mention send-email at least once to gently nudge the user to (learn to) use it. If the tool is good, do not tippy toe around the subject. Write plain text e-mail is a strange enough experience today, the documentation should plainly state that git send-email is likely the easiest solution to sending a patch or series of patches. Suggesting: Cody A Taylor cody.tay...@maternityneighborhood.com --- Documentation/SubmittingPatches | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index ef0eeb40cd22..702f1ace08ae 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -136,6 +136,14 @@ that is fine, but please mark it as such. (4) Sending your patches. +The git format-patch and git send-email commands are +complemtary to one another. They are optimized to make the work +flow of sending patches much easier. Primarily, using these +commands avoids the need to re-learn your existing e-mail client +that is optimized for multipart/* mime type e-mails. Using +these tools you will midigate the simple problems that cause poorly +formatted e-mails. + People on the Git mailing list need to be able to read and comment on the changes you are submitting. It is important for a developer to be able to quote your changes, using standard -- v2.3.2 -- 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] t7102: add 'reset -' tests
On Tue, Mar 10, 2015 at 6:10 PM, Sudhanshu Shekhar
sudshekha...@gmail.com wrote:
Add following test cases:
1) Confirm error message when git reset is used with no previous branch
2) Confirm git reset - works like git reset @{-1}
3) Confirm - is always treated as a commit unless the -- file option is
specified
4) Confirm git reset - works normally even when a file named @{-1} is
present
Does it concern you that all new tests pass except the last one even
when patch 1/2 is not applied? I would have expected most or all of
these tests to fail without patch 1/2.
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Helped-by: Matthieu Moy matthieu@grenoble-inp.fr
Helped-by: David Aguilar dav...@gmail.com
Signed-off-by: Sudhanshu Shekhar sudshekha...@gmail.com
---
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 98bcfe2..d3a5874 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -568,4 +568,163 @@ test_expect_success 'reset --mixed sets up work tree' '
test_cmp expect actual
'
+test_expect_success 'reset - with no previous branch fails' '
+ git init no_previous
I understand the intention of the name no_previous in tests for
which there is no @{-1}, however...
+ test_when_finished rm -rf no_previous
+ (
+ cd no_previous
+ test_must_fail git reset - 2actual
+ )
+ test_i18ngrep bad flag no_previous/actual
+'
+
+test_expect_success 'reset - while having file named - and no previous
branch fails' '
+ git init no_previous
+ test_when_finished rm -rf no_previous
+ (
+ cd no_previous
+ -
+ test_must_fail git reset - 2actual
+ )
+ test_i18ngrep bad flag no_previous/actual
+'
+
+test_expect_success \
+ 'reset - in the presence of file named - with previous branch resets
commit' '
+ cat expect -\EOF
+ Unstaged changes after reset:
+ M -
+ M file
+ EOF
+ git init no_previous
I don't understand the name no_previous in tests for which @{-1} can
resolve. It probably would be better to choose a more generic name and
use it for all these tests. For instance, resetdash or just dash
or something better.
+ test_when_finished rm -rf no_previous
+ (
+ cd no_previous
+ -
+ file
+ git add file -
+ git commit -m add base files
+ git checkout -b new_branch
+ echo random -
+ echo wow file
+ git add file -
+ git reset - ../actual
+ )
+ test_cmp expect actual
+'
+
+test_expect_success 'reset - with file named @{-1} succeeds' '
I may be missing something obvious, but why is it necessary to single
out a file named @{-1} at all, particuarly when there are so many
other ways to specify revisions, and there may be files mirroring
those spellings, as well?
+ cat expect EOF
+ Unstaged changes after reset:
+ M file
+ M @{-1}
+ EOF
+ git init no_previous
+ test_when_finished rm -rf no_previous
+ (
+ cd no_previous
+ echo random @{-1}
+ echo random file
+ git add @{-1} file
+ git commit -m base commit
+ git checkout -b new_branch
+ echo additional stuff file
+ echo additional stuff @{-1}
+ git add file @{-1}
+ git reset - ../actual
+ )
+ test_cmp expect actual
+'
+
test_done
--
2.3.1.278.ge5c7b1f.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/GSoC/RFC] fetch: git fetch --deepen
This patch is just for discusstion. An option --deepen is added to
'git fetch'. When it comes to '--deepen', git should fetch N more
commits ahead the local shallow commit, where N is indicated by
'--depth=N'. [1]
e.g.
(upstream)
---o---o---o---A---B
(you)
A---B
After excuting git fetch --depth=1 --deepen, (you) get one more
tip and it becomes
(you)
o---A---B
'--deepen' is designed to be a boolean option in this patch, which
is a little different from [1]. It's designed in this way, because
it can reuse '--depth' in the program, and just costs one more bit
in some data structure, such as fetch_pack_args,
git_transport_options.
Of course, as a patch for discussion, it remains a long way to go
before being complete.
1) Documents should be completed.
2) More test cases, expecially corner cases, should be added.
3) No need to get remote refs when it comes to '--deepen' option.
4) Validity on options combination should be checked.
5) smart-http protocol remains to be supported. [2]
Besides, I still have one question:
What does (you) exactly mean in [1]? The local branch or the local
remote ref?
I hope you could give me some comments and suggestions on this
patch. I would like to know whether I'm off the right way.
[1] http://article.gmane.org/gmane.comp.version-control.git/212950
[2] http://article.gmane.org/gmane.comp.version-control.git/265050
Helped-by: Duy Nguyen pclo...@gmail.com
Signed-off-by: Dongcan Jiang dongcan.ji...@gmail.com
---
builtin/fetch.c | 5 -
fetch-pack.c | 3 ++-
fetch-pack.h | 1 +
t/t5510-fetch.sh | 11 +++
transport.c | 4
transport.h | 4
upload-pack.c| 15 +++
7 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index f951265..6861207 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -33,7 +33,7 @@ static int fetch_prune_config = -1; /* unspecified */
static int prune = -1; /* unspecified */
#define PRUNE_BY_DEFAULT 0 /* do we prune by default? */
-static int all, append, dry_run, force, keep, multiple, update_head_ok,
verbosity;
+static int all, append, dry_run, force, keep, multiple, update_head_ok,
verbosity, deepen;
static int progress = -1, recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
static int tags = TAGS_DEFAULT, unshallow, update_shallow;
static const char *depth;
@@ -111,6 +111,7 @@ static struct option builtin_fetch_options[] = {
OPT_BOOL(0, progress, progress, N_(force progress reporting)),
OPT_STRING(0, depth, depth, N_(depth),
N_(deepen history of shallow clone)),
+ OPT_BOOL(0, deepen, deepen, N_(deepen)),
{ OPTION_SET_INT, 0, unshallow, unshallow, NULL,
N_(convert to a complete repository),
PARSE_OPT_NONEG | PARSE_OPT_NOARG, NULL, 1 },
@@ -853,6 +854,8 @@ static struct transport *prepare_transport(struct remote
*remote)
set_option(transport, TRANS_OPT_KEEP, yes);
if (depth)
set_option(transport, TRANS_OPT_DEPTH, depth);
+ if (deepen)
+ set_option(transport, TRANS_OPT_DEEPEN, yes);
if (update_shallow)
set_option(transport, TRANS_OPT_UPDATE_SHALLOW, yes);
return transport;
diff --git a/fetch-pack.c b/fetch-pack.c
index 655ee64..6f4adca 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -295,6 +295,7 @@ static int find_common(struct fetch_pack_args *args,
if (no_done)strbuf_addstr(c, no-done);
if (use_sideband == 2) strbuf_addstr(c,
side-band-64k);
if (use_sideband == 1) strbuf_addstr(c, side-band);
+ if (args-depth_deepen) strbuf_addstr(c,
depth_deepen);
if (args-use_thin_pack) strbuf_addstr(c,
thin-pack);
if (args-no_progress) strbuf_addstr(c,
no-progress);
if (args-include_tag) strbuf_addstr(c,
include-tag);
@@ -317,7 +318,7 @@ static int find_common(struct fetch_pack_args *args,
if (is_repository_shallow())
write_shallow_commits(req_buf, 1, NULL);
if (args-depth 0)
- packet_buf_write(req_buf, deepen %d, args-depth);
+ packet_buf_write(req_buf, depth %d, args-depth);
packet_buf_flush(req_buf);
state_len = req_buf.len;
diff --git a/fetch-pack.h b/fetch-pack.h
index bb7fd76..200ac78 100644
--- a/fetch-pack.h
+++ b/fetch-pack.h
@@ -10,6 +10,7 @@ struct fetch_pack_args {
const char *uploadpack;
int unpacklimit;
int depth;
+ unsigned depth_deepen:1;
unsigned quiet:1;
unsigned keep_pack:1;
unsigned lock_pack:1;
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index d78f320..6738006 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -708,4 +708,15 @@
Kedves: Webmail Előfizető
-- Kedves: Webmail Előfizető Felhívjuk figyelmét, hogy az e-mail fiók meghaladta tárolókapacitás. Ön nem tud küldeni és fogadni e-maileket és a e-mail fiókja törlésre kerül a szerverünkről. A probléma elkerülése érdekében, Kattintson ide frissítse a számla. http://mailhua.jigsy.com Köszönöm. Rendszergazda E-mail System. Köszönjük az együttm?ködést! Levél a Web Team @ 2014 -- 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: Is it possible get the tag name of working copy in Git?
On Fri, Mar 13, 2015 at 2:36 AM, Torsten Bögershausen tbo...@web.de wrote: On 03/13/2015 08:08 AM, chen chang wrote: I want to use make file auto generate the revision number of working copy from the tag name in git. Maybe you're looking for git describe? http://git-scm.com/docs/git-describe -- 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
