There is no need to break out the "buf" and "len" members into
separate temporary variables. Rename path_buf to path and use
path.buf and path.len directly. This makes it easier to reason about
the data flow in the function.
Signed-off-by: Michael Haggerty
---
entry.c | 32
remove_subtree() manipulated path in a fixed-size buffer even though
the length of the input, let alone the length of entries within the
directory, were not known in advance. Change the function to take a
strbuf argument and use that object as its scratch space.
Signed-off-by: Michael Haggerty
-
These patches are proposed for maint (but also apply cleanly to
master).
I presume that this is exploitable via Git commands, though I haven't
verified it explicitly [1].
I *think* that the rest of the file is OK. open_output_fd() initially
looks suspicious, because it strcpy()s a string onto th
Hi,
I have two branches.
- master-b1
- master-b2
Suppose I'm in master-b1 then did a change
on master-b1
$ git add test/init.c
$ git commit -s -m "init.c Changed!"
$ git log
Author: Jagan Teki
Date: Thu Mar 13 00:48:44 2014 -0700
init.c Changed!
$ git checkout master-b2
$ git log
Author: Jag
Jagan Teki writes:
> How can we do this, any idea?
git cherry-pick
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscr
On Thu, Mar 13, 2014 at 4:19 PM, Michael Haggerty wrote:
> There is no need to break out the "buf" and "len" members into
> separate temporary variables. Rename path_buf to path and use
> path.buf and path.len directly. This makes it easier to reason about
> the data flow in the function.
I wan
On Thu, Mar 13, 2014 at 4:19 PM, Michael Haggerty wrote:
> remove_subtree() manipulated path in a fixed-size buffer even though
> the length of the input, let alone the length of entries within the
> directory, were not known in advance. Change the function to take a
> strbuf argument and use tha
Signed-off-by: Nguyễn Thái Ngọc Duy
---
I missed the "else" anchor because it's indented far to the right and
misread the code for a second there. Might as well fix it while I'm
at it.
connect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/connect.c b/connect.c
index 4c
--
Your Trust and Partnership
Firstly, I apologize for sending you this sensitive information via
e-mail instead of a Certified mail/Post-mail. This is due to the
urgency and importance of the information. This project is based on
trust, confidentiality and sincerity of purpose in order to have a
On Thu, Mar 13, 2014 at 10:19:06AM +0100, Michael Haggerty wrote:
> These patches are proposed for maint (but also apply cleanly to
> master).
>
> I presume that this is exploitable via Git commands, though I haven't
> verified it explicitly [1].
It's possible to overflow this buffer, like:
Jagan:
On Thu, Mar 13, 2014 at 4:56 AM, Jagan Teki wrote:
> Hi,
Hello,
> I have two branches.
> - master-b1
> - master-b2
>
> Suppose I'm in master-b1 then did a change
> on master-b1
> $ git add test/init.c
> $ git commit -s -m "init.c Changed!"
> $ git log
> Author: Jagan Teki
> Date: Thu
On 03/12/2014 03:06 PM, Quint Guvernator wrote:
> 2014-03-12 9:51 GMT-04:00 Duy Nguyen :
>> starts_with(..) == !memcmp(...). So
>> you need to negate every replacement.
>
> My apologies--it doesn't look like the tests caught it either. I will
> fix this and submit a new patch.
It is very, very un
On 03/12/2014 08:04 PM, Junio C Hamano wrote:
> Here is another, as I seem to have managed to kill another one ;-)
>
> -- >8 --
>
> "VAR=VAL command" is sufficient to run 'command' with environment
> variable VAR set to value VAL without affecting the environment of
> the shell itself, but we can
On 03/12/2014 07:31 PM, Junio C Hamano wrote:
> Jacopo Notarstefano writes:
>
>> On Mon, Mar 3, 2014 at 7:34 PM, Junio C Hamano wrote:
>>> I think you fundamentally cannot use two labels that are merely
>>> "distinct" and bisect correctly. You need to know which ones
>>> (i.e. good) are to be e
Hi,
On Wed, Mar 12, 2014 at 4:19 PM, Yuxuan Shui wrote:
> Hi,
>
> I'm Yuxuan Shui, a undergraduate student from China. I'm applying for
> GSoC 2014, and here is my proposal:
>
> I found this idea on the ideas page, and did some research about it.
> The pack bitmap patchset add a new .bitmap file
Quint Guvernator writes:
>> The result after the conversion, however, still have the same magic
>> numbers, but one less of them each. Doesn't it make it harder to
>> later spot the patterns to come up with a better abstraction that
>> does not rely on the magic number?
>
> It is _not_ my goal t
David Kastrup writes:
> Junio C Hamano writes:
>
>> Taking two random examples from an early and a late parts of the
>> patch:
>>
>> --- a/builtin/cat-file.c
>> +++ b/builtin/cat-file.c
>> @@ -82,7 +82,7 @@ static int cat_one_file(int opt, const char *exp_type,
>> const char *obj_name)
>>
Thanks ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 13, 2014 at 10:47:28AM -0700, Junio C Hamano wrote:
> >> --- a/builtin/cat-file.c
> >> +++ b/builtin/cat-file.c
> >> @@ -82,7 +82,7 @@ static int cat_one_file(int opt, const char *exp_type,
> >> const char *obj_name)
> >>enum object_type type;
> >>
Sandy Carter writes:
> I refered to the wrong lines, the ones I was refering to were:
>
>> +static int maxwidth(const char *(*label)(int), int minval, int maxval)
>> +{
>> +int result = 0, i;
>> +
>> +for (i = minval; i <= maxval; i++) {
>> +const char *s = label(i);
>> +
Eric Sunshine writes:
> Shouldn't this logic [to decide what the printf arguments should
> be] also be encoded in the table?
> ...
> The same argument also applies to computation of the 'name' variable
> above. It too can be pushed into the the table.
Because the "printf argument" logic does not
Michael Haggerty writes:
> It seems to me that we can infer which mark is which from the normal
> bisect user interaction. At the startup phase of a bisect, there are
> only three cases:
>
> 1. There are fewer than two different types of marks on tested commits.
>For example, maybe one commi
Duy Nguyen writes:
> On Sat, Mar 8, 2014 at 2:20 AM, Junio C Hamano wrote:
>> Looking at "git grep -B3 OPT_NONEG" output, it seems that NONEG is
>> associated mostly with OPTION_CALLBACK and OPTION_SET_INT in the
>> existing code.
>>
>> Perhaps OPT_SET_INT should default to not just OPT_NOARG bu
Yuxuan Shui writes:
> Since fsck_ident doesn't change the content of **ident, the type of
> ident could be const char **.
>
> This change is required to rewrite fsck_commit() to use skip_prefix().
>
> Signed-off-by: Yuxuan Shui
> ---
It may not be a bad idea to read and understand reviews other
Yuxuan Shui writes:
> Currently we use memcmp() in fsck_commit() to check if buffer start
> with a certain prefix, and skip the prefix if it does. This is exactly
> what skip_prefix() does. And since skip_prefix() has a self-explaintory
> name, this could make the code more readable.
>
> Signed-o
Junio C Hamano writes:
>> -if (memcmp(buffer, "tree ", 5))
>> +buffer = skip_prefix(buffer, "tree ");
>> +if (buffer == NULL)
>
> We encourage people to write this as:
>
> if (!buffer)
>
> The same comment applies to other new lines in this patch.
I also see a lot of repetition
Signed-off-by: Yao Zhao
---
GSoC_MicroProject_#8
Hello Eric,
Thanks for reviewing my code. I implemented table-driven method this time and
correct the style
problems indicated in review.
Thank you,
Yao
branch.c | 72
1 file ch
On Thu, Mar 13, 2014 at 2:34 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> Shouldn't this logic [to decide what the printf arguments should
>> be] also be encoded in the table?
>> ...
>> The same argument also applies to computation of the 'name' variable
>> above. It too can be pushed i
Eric Sunshine writes:
>> +Prepare a request to your upstream project to pull your changes to
>> +their tree to the standard output, by summarizing your changes and
>> +showing where your changes can be pulled from.
>
> Perhaps splitting this into two sentence (and using fewer to's) would
> make i
On Wed, Mar 12, 2014 at 05:21:21PM -0700, Shawn Pearce wrote:
> Today I tried pushing a copy of linux.git from a client that had
> bitmaps into a JGit server. The client stalled for a long time with no
> progress, because it reused the existing pack. No progress appeared
> while it was sending the
On Thu, Mar 13, 2014 at 2:26 PM, Jeff King wrote:
> On Wed, Mar 12, 2014 at 05:21:21PM -0700, Shawn Pearce wrote:
>
>> Today I tried pushing a copy of linux.git from a client that had
>> bitmaps into a JGit server. The client stalled for a long time with no
>> progress, because it reused the exist
On Thu, Mar 13, 2014 at 03:01:09PM -0700, Shawn Pearce wrote:
> > It would definitely be good to have throughput measurements while
> > writing out the pack. However, I'm not sure we have anything useful to
> > count. We know the total number of objects we're reusing, but we're not
> > actually pa
On Wed, Mar 12, 2014 at 5:24 PM, TamerTas wrote:
>
> Signed-off-by: TamerTas
> --
There should be three hyphens "---" here but somehow you have only two
"--". Since "---" is detected automatically when the patch is applied,
this deviation can be problematic.
> Thanks for the feedback. Comments
Jeff King writes:
> There are a few ways around this:
>
> 1. Add a new phase "Writing packs" which counts from 0 to 1. Even
> though it's more accurate, moving from 0 to 1 really isn't that
> useful (the throughput is, but the 0/1 just looks like noise).
>
> 2. Add a new phase "Writ
On Thu, Mar 13, 2014 at 06:07:54PM -0400, Jeff King wrote:
> 3. Use the regular "Writing objects" progress, but fake the object
> count. We know we are writing M bytes with N objects. Bump the
> counter by 1 for every M/N bytes we write.
Here is that strategy. I think it looks pretty
On Wed, Mar 12, 2014 at 7:47 PM, Paweł Wawruch wrote:
> Replace the chain of if statements with table of strings.
>
> Signed-off-by: Paweł Wawruch
> ---
> Thanks to Eric Sunshine and Junio C Hamano.
> Simplified printing logic. The name moved to a table.
>
> v4: http://thread.gmane.org/gmane.comp
On Thu, Mar 13, 2014 at 4:35 PM, Eric Sunshine wrote:
> A more table-driven approach might look something
> like this:
>
> struct M { const char *s; const char **a1; const char **a2; }
> message[][2][2] = {{{
> { "Branch %s set ... %s ... %s", &shortname, &origin },
> ...
>
Has there been any talk about adding a stub for git subtrees in .git/config?
The primary benefits would be:
1. Determine what sub directories of the project were at one time
pulled from another repo (where from and which commit id), without
having to attempt to infer this by scanning the log.
2.
On Fri, Mar 14, 2014 at 2:00 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Sat, Mar 8, 2014 at 2:20 AM, Junio C Hamano wrote:
>>> Looking at "git grep -B3 OPT_NONEG" output, it seems that NONEG is
>>> associated mostly with OPTION_CALLBACK and OPTION_SET_INT in the
>>> existing code.
>>
John Butterfield writes:
> Has there been any talk about adding a stub for git subtrees in .git/config?
I do not think so, and that is probably for a good reason.
A subtree biding can change over time, but .git/config is about
recording information that do not change depending on what tree you
Hi
When your system shell (/bin/sh) is a dash control sequences in
strings get interpreted by the echo command. A commit message
which ends with the string '\n' may result in a garbage line in
the todo list of an interactive rebase which causes the rebase
to fail.
To reproduce the behavior (with
Hi,
Uwe Storbeck wrote:
> To reproduce the behavior (with dash as /bin/sh):
>
> mkdir test && cd test && git init
> echo 1 >foo && git add foo
> git commit -m"this commit message ends with '\n'"
> echo 2 >foo && git commit -a --fixup HEAD
> git rebase -i --autosquash --root
>
> Now the
> A subtree biding can change over time, but .git/config is about
recording information that do not change depending on what tree you
are looking at, so there is an impedance mismatch---storing that
information in .git/config is probably a wrong way to go about it.
I see. How about a .gitsubtrees
by "per folder" I meant, "for each subtree"
On Thu, Mar 13, 2014 at 5:43 PM, John Butterfield wrote:
>> A subtree biding can change over time, but .git/config is about
> recording information that do not change depending on what tree you
> are looking at, so there is an impedance mismatch---stori
Signed-off-by: Nemina Amarasinghe
---
branch.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/branch.c b/branch.c
index 723a36b..fd93603 100644
--- a/branch.c
+++ b/branch.c
@@ -87,16 +87,11 @@ void install_branch_config(int flag, const char *local,
const char *origin,
Hi,
Nemina Amarasinghe wrote:
> Signed-off-by: Nemina Amarasinghe
The above is a place to explain why this is a good change. For example:
When it prints a message indicating what it has done,
install_branch_config() treats the (!remote_is_branch && origin)
and (!remote
Thanks for the resubmission. Comments below.
On Thu, Mar 13, 2014 at 4:20 PM, Yao Zhao wrote:
> Subject: [PATCH] GSoC Change multiple if-else statements to be table-driven
It's a good idea to let reviewers know that this is attempt 2. Do so
by saying [PATCH v2]. Your next one will be [PATCH v3].
On Fri, Mar 14, 2014 at 01:02:13AM +0100, Uwe Storbeck wrote:
> When your system shell (/bin/sh) is a dash control sequences in
> strings get interpreted by the echo command. A commit message
> which ends with the string '\n' may result in a garbage line in
> the todo list of an interactive rebase
On Fri, Mar 07, 2014 at 08:23:05AM +0100, Johannes Sixt wrote:
> No, I meant lines like
>
> static double var;
>-static int old;
>+static int new;
>
> The motivation is to show hints where in a file the change is located:
> Anything that could be of significance for the author should
On Wed, Mar 12, 2014 at 07:55:51PM +0700, Duy Nguyen wrote:
> On Wed, Mar 5, 2014 at 7:10 AM, Junio C Hamano wrote:
> > [Graduated to "master"]
> > * jk/pack-bitmap (2014-02-12) 26 commits
> > (merged to 'next' on 2014-02-25 at 5f65d26)
>
> And it's finally in! Shall we start thinking about th
Is this safe? Today branch.c::create_branch
checks that the argument
> to e.g. --set-upstream-to is either in
refs/heads/* or the image of
> some remote, but what is making sure that remains
true tomorrow?
>
> So if changing this, I would be happier if the
"if" condition were
> still (!remot
On Tue, Mar 11, 2014 at 09:49:33PM +0530, karthik nayak wrote:
> On Tue, Mar 11, 2014 at 8:21 PM, Matthieu Moy
> wrote:
> > karthik nayak writes:
> >
> >> Currently we have multiple invocation of git_config() in an
> >> individual invocation of git() which is not efficient. Also, it is
> >> hard
On Wed, Mar 12, 2014 at 04:19:23PM +0800, Yuxuan Shui wrote:
> I'm Yuxuan Shui, a undergraduate student from China. I'm applying for
> GSoC 2014, and here is my proposal:
>
> I found this idea on the ideas page, and did some research about it.
> The pack bitmap patchset add a new .bitmap file for
This is mainly changing messages that say:
run "git foo --bar"
to
use "git foo --bar" to baz
Although the commands and flags are usually self-explanatory, this is
more consistent with other status messages, and gives some sort of
explanation to the user.
Signed-off-by: Andrew Wong
---
w
Print message during "git merge" and "git status".
Add a new "mergeHints" advice to silence these messages.
Signed-off-by: Andrew Wong
---
Documentation/config.txt | 3 +++
advice.c | 2 ++
advice.h | 1 +
builtin/merge.c | 6 ++
wt-status.c
During a merge, "--mixed" is most likely not what the user wants. Using
"--mixed" during a merge would leave the merged changes and new files
mixed in with the local changes. The user would have to manually clean
up the work tree, which is non-trivial. In future releases, we want to
make "git reset
2/3: I've added advice.mergeHints to silent the messages that suggests "git
merge--abort".
3/3: I've added a warning message when users used "git reset" during a merge.
This warning will be printed if the user is in the middle of a merge. In future
releases, we'll change this into an error to prev
On Sat, Mar 01, 2014 at 12:01:44PM +0100, Matthieu Moy wrote:
> Jeff King writes:
>
> > If we had the keys in-memory, we could reverse this: config code asks
> > for keys it cares about, and we can do an optimized lookup (binary
> > search, hash, etc).
>
> I'm actually dreaming of a system wher
On Wed, Mar 12, 2014 at 11:33:50PM -0400, Quint Guvernator wrote:
> It is _not_ my goal to make the code harder to maintain down the road.
> So, at this point, which hunks (if any) are worth patching?
This discussion ended up encompassing a lot of other related cleanups. I
hope we didn't scare yo
Jeff King writes:
> Hmph. We ran into this before and fixed all of the sites (e.g., d1c3b10
> and 938791c). This one appears to have been added a few months later
> (by 68d5d03).
>
>> Maybe there are more places where it would be more robust to use
>> printf instead of echo.
>
> FWIW, I just look
Am 3/14/2014 4:54, schrieb Jeff King:
> On Fri, Mar 07, 2014 at 08:23:05AM +0100, Johannes Sixt wrote:
>
>> No, I meant lines like
>>
>> static double var;
>>-static int old;
>>+static int new;
>>
>> The motivation is to show hints where in a file the change is located:
>> Anything tha
61 matches
Mail list logo
