Hi Junio,
My email server (zoho) puts leading UTF-8 non-breaking spaces ("\xC2\xA0")
when folding long mail headers. Due to this, git-am is failing as it expects
only '\t' or ' ' characters.
RFC2822 [1] on page 7 states:
> The general rule is that wherever this standard allows for folding white
ing list:
Thanks! It was rather daft of me to not realise this. I was waiting
for it to appear on public-inbox.
I re-sent it with the CC. The timestamp is a little bit
skewed, but I think it should make sense.
Thanks,
Siddharth.
[2]:
https://public-inbox.org/git/20170207191450.GA5569@ubuntu-512mb-blr1-01.localdomain/
[3]: https://public-inbox.org/git/vpqh944eof7@anie.imag.fr/
Thanks,
Siddharth.
P.S. This message was sent _before_ 1cmcxh-nd...@crossperf.com but
I didn't CC The mailing list in that message. I am sending it with the
mailing list cc-ed to ensure that the conversation makes sense.
. The way that I have implemented
ensured that not a lot of "rm"-like commands were enabled.
My patch that would enable this shorthand for other projects is
here[2].
[1]: http://public-inbox.org/git/vpqh944eof7@anie.imag.fr/
[2]:
http://public-inbox.org/git/1488007487-12965-5-git-send-email-kannan.siddhart...@gmail.com/
Thanks,
Siddharth.
provided as argument was unknown to
handle_revision_opt().
Signed-off-by: Siddharth Kannan
---
revision.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/revision.c b/revision.c
index b37dbec..5674a9a 100644
--- a/revision.c
+++ b/revision.c
@@ -2016,8 +2016,6 @@ static
provided as argument was unknown to
handle_revision_opt().
Signed-off-by: Siddharth Kannan
---
revision.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/revision.c b/revision.c
index b37dbec..5674a9a 100644
--- a/revision.c
+++ b/revision.c
@@ -2016,8 +2016,6 @@ static
Swap the condition and bodies of an "if (A) do_A else do_B" in
setup_revisions() to "if (!A) do_B else do A", to make the change in
the the next step easier to read.
No behaviour change is intended in this step.
Signed-off-by: Siddharth Kannan
---
revision.c | 6 +++--
been removed.
This patch also adds a test to check that revert recognizes the "-" shorthand.
Signed-off-by: Siddharth Kannan
---
builtin/revert.c| 2 --
t/t3514-revert-shorthand.sh | 25 +
2 files changed, 25 insertions(+), 2 deletions(-)
cre
rent : this function calls revision.c:get_sha1
This patch also adds a test for checking that the shorthand works properly
Signed-off-by: Siddharth Kannan
---
builtin/merge.c | 2 --
t/t3035-merge-hyphen-shorthand.sh | 33 +
2 files changed,
this
patch. This is something that needs to be fixed later by making changes deeper
down the callchain.
Signed-off-by: Siddharth Kannan
---
sha1_name.c | 5 +++
t/t4214-log-shorthand.sh | 106 +++
2 files changed, 111 insertions(+)
cre
n.siddhart...@gmail.com
[2]: vpqbmu768on@anie.imag.fr
[3]: xmqq1sv1euob@gitster.mtv.corp.google.com
Siddharth Kannan (6):
revision.c: do not update argv with unknown option
revision.c: swap if/else blocks
revision.c: args starting with "-" might be a revision
sha1_name
on to the next argument.
This patch prepares the addition of "-" as a shorthand for "previous branch".
Signed-off-by: Siddharth Kannan
---
revision.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/revision.c b/revision.c
index 8d4ddae..5470c33 10064
On 21 February 2017 at 02:00, Junio C Hamano wrote:
> Siddharth Kannan writes:
> > So, is it okay to stop with just supporting "-" and not support things
> > like "-@{yesterday}"?
>
> If the approach to turn "-" into "@{-1}" at that sp
; is not an ideal final state, is probably an acceptable milestone to
> stop at.
So, is it okay to stop with just supporting "-" and not support things
like "-@{yesterday}"?
Matthieu's comments on the matter:
Siddharth Kannan writes:
> As per Matthieu'
Hey Junio and Matthieu,
On 17 February 2017 at 00:19, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Siddharth Kannan writes:
>>
>>> This is as per our discussion[1]. The patches and commit messages are based
>>> on
>>> J
e confusion!
Yes, I used the past perfect tense to refer to changes that were made
in this particular patch!
I will change the message in the next version to something that's in
present tense.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
--
Best Regards,
- Siddharth.
ill have to keep that part intact even in this solution. (I am not too
sure about this. If this is the preferred solution, then I will dig deeper and
find the right place as I did for the first part of this patch)
Matthieu: Thanks a lot for your comments on the tests! test_commit has made the
test
provided as argument was unknown to
handle_revision_opt().
Signed-off-by: Siddharth Kannan
---
revision.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/revision.c b/revision.c
index b37dbec..5674a9a 100644
--- a/revision.c
+++ b/revision.c
@@ -2016,8 +2016,6 @@ static
on to the next argument.
This patch prepares the addition of "-" as a shorthand for "previous branch".
Signed-off-by: Siddharth Kannan
---
revision.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/revision.c b/revision.c
index 8d4ddae..5470c33 10064
ds in this list are not of the rm-variety, (i.e a command that
would delete something), this change does not make it easier for people to
delete. (eg: "git branch -d -" is *not* enabled by this patch)
Signed-off-by: Siddharth Kannan
---
Instead of replacing the whole string, we would e
Swap the condition and bodies of an "if (A) do_A else do_B" in
setup_revisions() to "if (!A) do_B else do_A", to make the change in
the the next step easier to read.
No behaviour change is intended in this step.
Signed-off-by: Siddharth Kannan
---
revision.c | 6 +++--
remove code that does this shorthand stuff for
other commands as per Matthieu's comments)
--
Best Regards,
Siddharth Kannan.
On Sat, Feb 11, 2017 at 01:08:09PM -0800, Junio C Hamano wrote:
> Siddharth Kannan writes:
>
> > Um, I am sorry, but I feel that decrementing left, and incrementing it
> > again is
> > also confusing.
>
> Yes, but it is no more confusing than your original "
Hey Matthieu,
On Sun, Feb 12, 2017 at 10:48:56AM +0100, Matthieu Moy wrote:
> Siddharth Kannan writes:
>
> > sha1_name.c | 5
> > t/t4214-log-shorthand.sh | 73
> >
> > 2 files changed, 78 inserti
die("bad revision '%s'", arg);
> @@ -2255,8 +2261,6 @@ int setup_revisions(int argc, const char **argv, struct
> rev_info *revs, struct s
> append_prune_data(&prune_data, argv + i);
> break;
> }
> - else
> - got_rev_arg = 1;
> }
>
> if (prune_data.nr) {
Thanks Junio, for the time you spent analysing and writing the above version of
the patch!
Regards,
- Siddharth Kannan
ds in this list are not of the rm-variety, (i.e a command that
would delete something), this change does not make it easier for people to
delete. (eg: "git branch -d -" is *not* enabled by this patch)
Signed-off-by: Siddharth Kannan
---
sha1_name.c | 5
t/t4214-l
s starting
with "-" and once for arguments that didn't start with "-". Now, it will be
called once per argument.
This patch prepares the addition of "-" as a shorthand for "previous branch".
Signed-off-by: Siddharth Kannan
---
revision.c | 12
pqh944eof7@anie.imag.fr/#t
[2]:
https://public-inbox.org/git/can-3qhozn_wyvqbvdu_c1h4vuoat5fobfl7k+femnpqkxjw...@mail.gmail.com/
[3]: https://travis-ci.org/icyflame/git/builds/200431159
Siddharth Kannan (2):
revision.c: args starting with "-" might be a revision
sha1_name: teach get_sha1
mind when polishing the commit message.
I will definitely do that. I am working on a good commit message for
this by looking at some past changes to sha1_name.c which have
affected multiple commands.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
--
Best Regards,
- Siddharth.
ot;yes, let's
do it", but to actually flesh out these pages:
>
>> Someone steps in to do what exactly?
>
> First we need an admin. Then as you said a bit of janitoring work on
> the web pages.
[1]:
https://public-inbox.org/git/20170125204504.ebw2sa4uokfww...@sigill.intra.peff.net/
--
Best Regards,
- Siddharth.
know it
will not conflict (or be confused by users) with possible other uses
of "-", I do not think we would mind "git branch -D -" and other
commands to learn "-" as a synonym for @{-1}.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
Thanks a lot for the review on this patch, Matthieu!
--
Best Regards,
- Siddharth.
[1]: https://public-inbox.org/git/7vmwpitb6k@alter.siamese.dyndns.org/
Teach revision.c:setup_revisions that an argument starting with "-" can be an
argument also. `left` variable needs to be incremented only when the supplied
arg is neither an argument, nor an option.
Teach sha1_name.c:get_sha1_1 that "-" is equivalent to "@{-1}"
S
e in sha1_name.c will touch a lot of commands
(setup_revisions is called from everywhere in the codebase), so, I am
still trying to figure out how to do this such that the rest of the
codepath remains unchanged.
I hope that you do not mind this side-effect, but rather, you intended
for this to happen, right? More commands will start supporting this
shorthand, suddenly. (such as format-patch, whatchanged, diff to name
a very few).
Best Regards,
Siddharth.
n will be a lot more involved, of course, and I
> think it will be larger than a reasonable microproject for people
> new to the codebase.
So true :) I had spent a fair bit of time already on my previous patch,
and I thought I might as well complete my research into this, and send
this write-up to the mailing list, so that I could write a patch some
time later. In case you would prefer for me to not work on this
anymore because I am new to the codebase, I will leave it at this.
- Siddharth Kannan
Hey Pranit,
On Sun, Feb 05, 2017 at 02:45:46AM +0530, Pranit Bauva wrote:
> Hey Siddharth,
>
> On Sat, Feb 4, 2017 at 8:01 PM, Siddharth Kannan
> wrote:
> > The error_on_missing_default_upstream helper function learned to
> > take op_prep argument with 15a147e618 ("r
Hey Junio,
On Sun, Feb 05, 2017 at 04:15:03PM -0800, Junio C Hamano wrote:
> Siddharth Kannan writes:
>
> > @@ -158,6 +158,51 @@ static void cmd_log_init_finish(int argc, const char
> > **argv, const char *prefix,
> >
> > if (quiet)
> >
ick: allow "-" as
abbreviation of '@{-1}', 2013-09-05) and 4e8115ff (merge: allow "-" as a
short-hand for "previous branch", 2011-04-07)
(c) and (d) have been implemented by using the strbuf API, growing it to the
right size and placing "@{-1}"
nt is no longer used. Remove it.
Signed-off-by: Siddharth Kannan
---
Thanks a lot for the review, Pranit and Junio! I have made the appropriate
changes, and the edit to the file inside contrib/examples/ has been removed from
this patch.
git-parse-remote.sh | 3 +--
git-rebase.sh | 2 +-
On Sat, Feb 04, 2017 at 04:55:45PM +0530, Pranit Bauva wrote:
> Hey SIddharth,
>
> > Subject: parse-remote: Remove reference to unused op_prep
> ^
>
> Minor nit: after the colon, we generally don't use the word starting
> wit
nt is no longer used. Remove it.
Signed-off-by: Siddharth Kannan
---
Thanks a lot, Pranit and Junio for your reviews on the first version of this
patch. I have changed the messages accordingly.
contrib/examples/git-pull.sh | 2 +-
git-parse-remote.sh | 3 +--
git-rebase.sh
ropriately
Signed-off-by: Siddharth Kannan
---
The contrib/examples/git-pull.sh file also has a variable op_prep which is used
in one of the messages shown the user. Should I remove this variable as well?
contrib/examples/git-pull.sh | 2 +-
git-parse-remote.sh | 3 +--
git-rebase.sh
ithout the tree that refers to it, we
would not know that the blob is relevant to our walk.
2. We do not need to test a tip commit that is missing.
Upload-pack omits these for us (and in fact, we
complain even in the non-bitmap case if it fails to do
so).
Reported-by: Si
On 03/26/2014 03:40 PM, Siddharth Agarwal wrote:
On 03/26/2014 12:22 AM, Jeff King wrote:
[tl;dr the patch is the same as before, but there is a script to measure
its effects; please try it out on your repos]
Here are the numbers from another, much larger repo:
Test
On 03/26/2014 12:22 AM, Jeff King wrote:
[tl;dr the patch is the same as before, but there is a script to measure
its effects; please try it out on your repos]
Here are results from one of our repos:
Test origin HEAD
-
Hi,
We're still experimenting with bitmaps, and we've have run into issues
where fetching from a repository with bitmaps enabled can lead to
objects that used to be present on the server but have since been GC'd
being accessed, and git pack-objects on the server failing because of that.
I ca
On 03/22/2014 05:56 AM, Jeff King wrote:
On Fri, Mar 21, 2014 at 07:58:55PM -0700, Siddharth Agarwal wrote:
Is it also reproducible just with the tip of "next"? Note that the
patches in jk/bitmap-reuse-delta have not been widely deployed (in
particular, we are not yet using them at G
Hi all,
At Facebook we've found that fetch speed is a bottleneck for our Git
repos, so we've been looking to deploy bitmaps to speed up fetches.
We've been trying out git-next with the top two patches from
https://github.com/peff/git/commits/jk/bitmap-reuse-delta, but the
following is reprodu
Helped-by: Eric Sunshine
Signed-off-by: Siddharth Goel
---
Added a space after colon in the subject as compared to previous
patch [PATCH v2].
[PATCH v2]: http://thread.gmane.org/gmane.comp.version-control.git/243150
git-compat-util.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions
Helped-by: Eric Sunshine
Signed-off-by: Siddharth Goel
---
Thanks a lot Eric for your valuable comments. Please let me know if there is
anything else which needs to be modified in this patch.
git-compat-util.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/git
this Microproject or should I go with another one?
On Sat, Mar 1, 2014 at 9:32 PM, Siddharth Goel wrote:
> Rewrote skip_prefix() function so that prefix is scanned once.
>
> Signed-off-by: Siddharth Goel
> ---
> git-compat-util.h | 7 +--
> 1 file changed, 5 insertio
Rewrote skip_prefix() function so that prefix is scanned once.
Signed-off-by: Siddharth Goel
---
git-compat-util.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 614a5e9..550dce3 100644
--- a/git-compat-util.h
+++ b/git
On 01/23/2014 06:28 PM, Jeff King wrote:
I think your understanding is accurate here. So we want repack to
respect keep files for deletion, but we _not_ necessarily want
pack-objects to avoid packing an object just because it's in a pack
marked by .keep (see my other email).
Yes, that makes sen
On 01/23/2014 03:45 PM, Siddharth Agarwal wrote:
The worry is less certain objects not being packed and more the old
packs being deleted by git repack, isn't it? From the man page for
git-index-pack:
This should probably be "new pack" and not "old packs", I guess
On 01/23/2014 02:52 PM, Jeff King wrote:
Right, that's expected.
The bitmap format cannot represent objects that are not present in the
pack. So we cannot write a bitmap index if any object reachable from a
packed commit is omitted from the pack.
We could be nicer and downgrade it to a warning,
On 01/22/2014 06:38 PM, Siddharth Agarwal wrote:
In our case we have .keep files lying around from ages ago (possibly
due to kill -9s run on the server). It also means that running repack
-a with bitmap writing enabled on a repo becomes problematic if a
fetch is run concurrently.
We briefly
Running git-next, writing bitmap indexes fails if a keep file is present
from an earlier pack.
With git at b139ac2, the following commands demonstrate the problem:
git init test
cd test
touch a
git add a
git commit -m "a"
git repack -ad # generate a pack file
for f in .git/objects/pack/*.pack
With git-next, the --max-pack-size option to git repack doesn't work.
With git at b139ac2, `git repack --max-pack-size=1g` says
error: option `max-pack-size' expects a numerical value
while `git repack --max-pack-size=1073741824` says
error: unknown option `max_pack_size=1073741824'
I bisecte
On 01/17/2014 12:40 AM, John Keeping wrote:
On Thu, Jan 16, 2014 at 06:47:38PM -0800, Siddharth Agarwal wrote:
On 01/16/2014 06:21 PM, Jeff King wrote:
On Thu, Jan 16, 2014 at 05:08:14PM -0800, Siddharth Agarwal wrote:
With git-next, where git pull --rebase can print out "fatal: No suc
On 01/16/2014 06:21 PM, Jeff King wrote:
On Thu, Jan 16, 2014 at 05:08:14PM -0800, Siddharth Agarwal wrote:
With git-next, where git pull --rebase can print out "fatal: No such
ref: ''" if git pull --rebase is run on branches without an upstream.
This is already fixed in
With git-next, where git pull --rebase can print out "fatal: No such
ref: ''" if git pull --rebase is run on branches without an upstream.
With git at b139ac2589b15d55cd9fa5c6957da44b150d0737, the following
commands demonstrate the problem:
git init repo1
cd repo1
touch a; git add a; git comm
60 matches
Mail list logo
