Junio C Hamano gits...@pobox.com 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)
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 mhag...@alum.mit.edu
---
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
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 jagannadh.t...@gmail.com
Date: Thu Mar 13 00:48:44 2014 -0700
init.c Changed!
$ git checkout
Jagan Teki jagannadh.t...@gmail.com 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:
On Thu, Mar 13, 2014 at 4:19 PM, Michael Haggerty mhag...@alum.mit.edu 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
On Thu, Mar 13, 2014 at 4:19 PM, Michael Haggerty mhag...@alum.mit.edu 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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
--
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
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:
git
Jagan:
On Thu, Mar 13, 2014 at 4:56 AM, Jagan Teki jagannadh.t...@gmail.com 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
On 03/12/2014 03:06 PM, Quint Guvernator wrote:
2014-03-12 9:51 GMT-04:00 Duy Nguyen pclo...@gmail.com:
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
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 cannot do
On 03/12/2014 07:31 PM, Junio C Hamano wrote:
Jacopo Notarstefano jacopo.notarstef...@gmail.com writes:
On Mon, Mar 3, 2014 at 7:34 PM, Junio C Hamano gits...@pobox.com wrote:
I think you fundamentally cannot use two labels that are merely
distinct and bisect correctly. You need to know
Hi,
On Wed, Mar 12, 2014 at 4:19 PM, Yuxuan Shui yshu...@gmail.com 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
Quint Guvernator quintus.pub...@gmail.com 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
David Kastrup d...@gnu.org writes:
Junio C Hamano gits...@pobox.com 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
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;
Eric Sunshine sunsh...@sunshineco.com 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
Michael Haggerty mhag...@alum.mit.edu 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,
Duy Nguyen pclo...@gmail.com writes:
On Sat, Mar 8, 2014 at 2:20 AM, Junio C Hamano gits...@pobox.com 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
Yuxuan Shui yshu...@gmail.com 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 yshu...@gmail.com
---
It may not be a bad idea to read
Yuxuan Shui yshu...@gmail.com 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
Junio C Hamano gits...@pobox.com 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
Signed-off-by: Yao Zhao zhaox...@umn.edu
---
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
On Thu, Mar 13, 2014 at 2:34 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com 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
Eric Sunshine sunsh...@sunshineco.com 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
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 p...@peff.net 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
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 parsing
On Wed, Mar 12, 2014 at 5:24 PM, TamerTas tamer...@outlook.com wrote:
Signed-off-by: TamerTas tamer...@outlook.com
--
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.
Jeff King p...@peff.net 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
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 pa...@aleg.pl wrote:
Replace the chain of if statements with table of strings.
Signed-off-by: Paweł Wawruch pa...@aleg.pl
---
Thanks to Eric Sunshine and Junio C Hamano.
Simplified printing logic. The name moved to a table.
v4:
On Thu, Mar 13, 2014 at 4:35 PM, Eric Sunshine sunsh...@sunshineco.com 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 gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Sat, Mar 8, 2014 at 2:20 AM, Junio C Hamano gits...@pobox.com wrote:
Looking at git grep -B3 OPT_NONEG output, it seems that NONEG is
associated mostly with OPTION_CALLBACK and
John Butterfield johnb...@gmail.com 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
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 -mthis commit message ends with '\n'
echo 2 foo git commit -a --fixup HEAD
git rebase -i --autosquash --root
Now the editor opens with
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 johnb...@gmail.com 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
Signed-off-by: Nemina Amarasinghe nemi...@gmail.com
---
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,
Hi,
Nemina Amarasinghe wrote:
Signed-off-by: Nemina Amarasinghe nemi...@gmail.com
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)
Thanks for the resubmission. Comments below.
On Thu, Mar 13, 2014 at 4:20 PM, Yao Zhao zhaox...@umn.edu 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
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 be
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
On Tue, Mar 11, 2014 at 09:49:33PM +0530, karthik nayak wrote:
On Tue, Mar 11, 2014 at 8:21 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
karthik nayak karthik@gmail.com writes:
Currently we have multiple invocation of git_config() in an
individual invocation of git() which
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
Print message during git merge and git status.
Add a new mergeHints advice to silence these messages.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
Documentation/config.txt | 3 +++
advice.c | 2 ++
advice.h | 1 +
builtin/merge.c | 6 ++
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 prevent
On Sat, Mar 01, 2014 at 12:01:44PM +0100, Matthieu Moy wrote:
Jeff King p...@peff.net 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
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 you
58 matches
Mail list logo
