Nguyễn Thái Ngọc Duy writes:
> Paths marked by "git add -N" are simply a reminder to the user that
> these files should be staged. If the user does not stage any of them,
> "git commit" will not record them.
>
> Align the behavior of "diff --cached" and "git commit". The most
> prominent result
Hi guys,
So I was looking at fetch-pack.c (from master @ 52cae643, but I think
it's the same everywhere):
# Lines 626-648
for (retval = 1, ref = *refs; ref ; ref = ref->next) {
const unsigned char *remote = ref->old_sha1;
unsigned char local[20];
str
Yurii Shevtsov writes:
> As I understood there are four unsolved microprojects. I think I can
> deal with "Make "git diff --no-index $directory $file" DWIM better"
> but I don't understand what exactly should I do.
OK.
> I tried to run 'git
> diff --no-index ~/git/ diff.h' cmd on git sources bu
Duy Nguyen writes:
> Notice that the first time pack->obj[] is filled using
> lookup_object(). So yes, the hash table has all the pointers that
> pack->obj[] has.
Are we talking about the same thing?
By "the hash table", I mean **obj_hash that is a hashtable that uses
form of identifier as the
Alexander Kuleshov writes:
> This patch provides fixes for two minor memory leaks in the
> handle_alias function:
>
> 1. We allocate memory for alias_argv with the xmalloc function call,
> after run_command_v_opt function will be executed we no need in this
> variable anymore, so let's free it.
John Szakmeister writes:
> The current definition results in an incorrect expansion of the term under
> zsh.
> For instance "/^${1\\/}/" under zsh with the argument "hi" results in:
> /^/\/h/\/i/
>
> This results in an output similar to this when trying to complete `git grep
> chartab` u
Because "revs->no_walk" gets set when it comes to "git show". You can
find more information on [1].
[1] http://article.gmane.org/gmane.comp.version-control.git/264921
2015-03-15 9:24 GMT+08:00 Manos Pitsidianakis :
> On 03/15/2015 03:08 AM, Dongcan Jiang wrote:
>> it seems that your patch could n
On 03/15/2015 03:08 AM, Dongcan Jiang wrote:
> it seems that your patch could not pass t4052-stat-output.sh.
>
> I think it would be better if you could improve the specification for
> this change in Document/rev-list-options.txt
Can't grok why this happens. What exactly is happening in
t4052-sta
it seems that your patch could not pass t4052-stat-output.sh.
I think it would be better if you could improve the specification for
this change in Document/rev-list-options.txt
2015-03-15 8:43 GMT+08:00 Manos Pitsidianakis :
> In git-log, --graph shows a graphical representation of a continuous
>
In git-log, --graph shows a graphical representation of a continuous
commit history, and --no-walk shows discrete specified commits without
continuity. Using both doesn't make sense, so we forbid the combined use
of these flags.
Signed-off-by: Manos Pitsidianakis
---
This is a microproject intend
On Sun, Mar 15, 2015 at 5:19 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>>> Anyway, wouldn't this be all academic? I do not see how you would
>>> keep the object name in the format in-core, as the
>>> obj_hash[] is a hashtable keyed by , and even when we switch
>>> to a different hash, I
--
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
On Sun, Mar 15, 2015 at 01:55:28AM +0200, epilys wrote:
> On 03/15/2015 01:47 AM, brian m. carlson wrote:
> > It looks like you indented here with four spaces instead of a tab.
> > We prefer tabs in Git.
>
> Messed that up. Do you think I should resubmit a v3 or am I hogging
> the mailing list to
On 03/15/2015 01:47 AM, brian m. carlson wrote:
> It looks like you indented here with four spaces instead of a tab.
> We prefer tabs in Git.
Messed that up. Do you think I should resubmit a v3 or am I hogging
the mailing list too much?
--
To unsubscribe from this list: send the line "unsubscrib
On Sun, Mar 15, 2015 at 01:33:07AM +0200, epilys wrote:
> diff --git a/builtin/log.c b/builtin/log.c
> index dd8f3fc..0194133 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -155,6 +155,8 @@ static void cmd_log_init_finish(int argc, const char
> **argv, const char *prefix,
> memset(&
In git-log, --graph shows a graphical representation of a continuous
commit history, and --no-walk shows discrete specified commits without
continuity. Using both doesn't make sense, so we forbid the combined use
of these flags.
Signed-off-by: Manos Pitsidianakis
---
builtin/log.c | 2 ++
t/t42
Subject is usually prefixed with the part that is changed, in this case
log.
For example:
log: forbid log --graph --no-walk
On Sat, Mar 14, 2015 at 11:31:59PM +0200, epilys wrote:
> In git-log, --graph shows a graphical representation of a
> continuous commit history, and --no-walk shows discre
Duy Nguyen writes:
>> Anyway, wouldn't this be all academic? I do not see how you would
>> keep the object name in the format in-core, as the
>> obj_hash[] is a hashtable keyed by , and even when we switch
>> to a different hash, I cannot see how such a table to ensure the
>> singleton-ness of
Paul Tan writes:
>> 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.
>
> Even though in t
Dave Olszewski writes:
> On Fri, 13 Mar 2015, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > From: Dave Olszewski
>> >
>> > Signed-off-by: Dave Olszewski
>> > ---
>> > Again, this is just a preview. Dave should send the final when he thinks
>> > it is good.
>>
>> Dave?
>>
>> I do not
Duy Nguyen writes:
> On Sat, Mar 14, 2015 at 12:35 PM, Junio C Hamano wrote:
>> Dongcan Jiang writes:
>>> 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 branc
In git-log, --graph shows a graphical representation of a
continuous commit history, and --no-walk shows discrete specified
commits without continuity. This doesn't make sense, so we forbid the
combined use of these flags.
Signed-off-by: Manos Pitsidianakis
---
builtin/log.c | 2 ++
t/t4202-log
In git-log, --graph shows a graphical representation of a
continuous commit history, and --no-walk shows discrete specified
commits without continuity. This doesn't make sense, so we forbid the
combined use of these flags.
Signed-off-by: Manos Pitsidianakis
---
builtin/log.c | 2 ++
t/t4202-log
As I understood there are four unsolved microprojects. I think I can
deal with "Make "git diff --no-index $directory $file" DWIM better"
but I don't understand what exactly should I do. I tried to run 'git
diff --no-index ~/git/ diff.h' cmd on git sources but it says 'error:
file/directory conflict
This patch provides fixes for two minor memory leaks in the
handle_alias function:
1. We allocate memory for alias_argv with the xmalloc function call,
after run_command_v_opt function will be executed we no need in this
variable anymore, so let's free it.
2. Memory allocated for alias_string var
Hi,
If you try to delete a local branch "feature" which is not merged into
another branch, you will get the following warning:
. error: The branch 'feature' is not fully merged.
. If you are sure you want to delete it, run 'git branch -D feature'.
If a local branch is worth to be protected in
On Fri, 13 Mar 2015, Junio C Hamano wrote:
> Jeff King writes:
>
> > From: Dave Olszewski
> >
> > Signed-off-by: Dave Olszewski
> > ---
> > Again, this is just a preview. Dave should send the final when he thinks
> > it is good.
>
> Dave?
>
> I do not see anything wrong with this version tha
On Sat, Mar 14, 2015 at 01:33:28PM -0400, Jeff King wrote:
> On Sat, Mar 14, 2015 at 04:15:53PM +0800, Paul Tan wrote:
>
> > Even though in this case the store_credential() function is not used
> > anywhere else, from my personal API design experience I think that
> > cementing the rule of "the f
On Fri, Mar 13, 2015 at 11:06:22PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > From: Dave Olszewski
> >
> > Signed-off-by: Dave Olszewski
> > ---
> > Again, this is just a preview. Dave should send the final when he thinks
> > it is good.
>
> Dave?
>
> I do not see anything wrong
On Sat, Mar 14, 2015 at 04:15:53PM +0800, Paul Tan wrote:
> Even though in this case the store_credential() function is not used
> anywhere else, from my personal API design experience I think that
> cementing the rule of "the first file in the list is the default" in
> the behavior of the functio
On overall, the patch looks good. Some suggestions to improve the tests
and a minor nitpick below.
Adrien Schildknecht writes:
> +++ b/t/t4034/sh/post
> @@ -0,0 +1,36 @@
> +foo() {ls&echo}
This part is unchanged here and in the pre file. What does it test?
> +$((x++))
> +$((x--))
> +$((--x))
>
On Fri, Mar 13, 2015 at 11:39:26PM +, brian m. carlson wrote:
Changes since v1:
I just realized that I sent this out as v2 instead of v3. It really is
v3. My apologies for the error.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpast
The current definition results in an incorrect expansion of the term under zsh.
For instance "/^${1\\/}/" under zsh with the argument "hi" results in:
/^/\/h/\/i/
This results in an output similar to this when trying to complete `git grep
chartab` under zsh:
:: git grep chartabawk: cm
On Fri, Mar 13, 2015 at 1:03 PM, Junio C Hamano wrote:
>>> To me, 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
On Fri, Mar 13, 2015 at 4:28 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>>> static struct pathspec pathspec;
>>> static const char *prefix;
>>> @@ -22,7 +23,7 @@ static void add_one(struct string_list *result, const
>>> char *name)
>>> struct strbuf sb = STRBUF_INIT;
>>> st
Sir
I am a third year undergraduate student in Computer Science .I have good
knowledge in C. I read all the micro projects ideas and interested to work
on it . So kindly tell me how should I start .
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to m
On Fri, Mar 13, 2015 at 4:10 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> builtin/list-files.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/builtin/list-files.c b/builtin/list-files.c
>> index ac33f13..b99f2b7 1006
On Fri, Mar 13, 2015 at 4:02 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> list-files is supposed to be the user friendly version of ls-files, or
>> an alternative to git-status. Nothing fancy in this patch yet.
>
> The result of applying this patch alone will not give us anythin
On Fri, Mar 13, 2015 at 8:04 PM, Dongcan Jiang wrote:
> @@ -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
On Sat, Mar 14, 2015 at 12:35 PM, Junio C Hamano wrote:
> Dongcan Jiang writes:
>> 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 poi
On Fri, Mar 13, 2015 at 2:15 PM, Jeff King wrote:
>> +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
The latest maintenance release Git v2.3.3 is now available at
the usual places. It is comprised of 26 non-merge commits since
v2.3.2, contributed by 11 people, 1 of which is a new contributor.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repos
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
On the 'maint' front is the latest maintenance release v2.3.3.
You can find the changes described here in the integration branches
of the repos
43 matches
Mail list logo