Hello all,
I have found the "Did you mean this?" feature of git as a very good
feature. I thought it would be even better if it took a step toward by
asking for a prompt when there was only one alternative to the command
that was entered.
E.g.
> unique@unique-pc:~$ git hepl
> git: 'hepl' is
On Sun, 2016-12-18 at 14:16 +0100, Stephan Beyer wrote:
> I cannot tell if this is a good idea (or why it would be a bad idea)
> but
> why do you restrict your suggestion to the case when there is only
> one
> alternative?
>
> Why not also something like:
>
> ---
> $ git sta
> git: 'sta' is not
Hello all,
On Sun, 18 December 2016 at 20:59, Alexei Lozovsky wrote,
> It's definitely a good thing for human users. For example, I am
> annoyed
> from time to time when I type in some long spell, mistype one minor
> thing,
> and the whole command fails. Then I need to press , correct the
>
On Fri, 2017-07-28 at 20:53 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes:
>
> > Though the message seems to be most fitting one, I'm a little reluctant
> > to use it as it "might" create a wrong picture on the minds
: option '-n' must come before non-option arguments
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/setup.c b/setup.c
index 860507e1fdb2d..09c79328247dd 100644
--- a/setup.c
+++ b/setup.c
@@ -230,7
On Sat, 2017-07-29 at 09:10 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes:
> >
> > That's interesting. In that case, I'll go with the suggested statement,
> > happily!
>
> It is not interesting at all. It actually is dis
Splitting a single sentence across multiple lines could
degrade readability. Further, long messages are likely
to be ignored by users.
Split the sentences and simplify it to improve their readability.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
re
elow,
$ git branch
foo
* master
$ git branch -m foo foo old
fatal: too many branches for a rename operation
Change the messages to be more general thus making no assumptions
about the "parameters".
Signed-off-by: Kaartic Sivaraam <kaarticsiva
On Sun, 2017-07-30 at 16:17 +0530, Kaartic Sivaraam wrote:
> On Sat, 2017-07-29 at 09:10 -0700, Junio C Hamano wrote:
> > We perhaps need to somehow make sure new users won't be led to the
> > misunderstanding. Improving our documentation is a good first step.
>
> That's s
elow,
$ git branch
foo
* master
$ git branch -m foo foo old
fatal: too many branches for a rename operation
Change the messages to be more general thus making no assumptions
about the "parameters".
Signed-off-by: Kaartic Sivaraam <kaarticsiva
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
Documentation/SubmittingPatches | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 558d465b6..9d0dab08d 100644
--- a/Documen
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
I'm not sure if the first one (pull --rebase) is still
required and hence leaving it as such. Let me know if it
could be removed.
Documentation/SubmittingPatches | 4
1 file changed, 4 insertions(+)
diff
Sorry, sent it to the wrong thread. Please, ignore this patch.
--
Kaartic
On Wed, 2017-08-02 at 10:32 -0700, Stefan Beller wrote:
> Thanks for checking.
You're welcome. :)
--
Kaartic
On Monday 14 August 2017 11:49 PM, Junio C Hamano wrote:
I tend to agree with "Anyways" above ;-) simply because I found the
long paragraph more confusing than enlightening, leaving me wonder
"why is the user using different settings for author and committer
name" at the end, which _is_ an
On Monday 14 August 2017 11:24 PM, Stefan Beller wrote:
On Mon, Aug 14, 2017 at 1:46 AM, Kaartic Sivaraam
<kaarticsivaraam91...@gmail.com> wrote:
Sign-off added should be that of the "committer" not that of the
"commit's author".
Use the correct logical variable tha
On Tuesday 15 August 2017 01:49 AM, Junio C Hamano wrote:
I wonder if these two lines add any value here. Those who know the
reason would not be helped, and those who don't know have to view
"git show b347d06bf" anyway.
That's right.
I somehow think the above wastes bits a bit too much.
On Tuesday 15 August 2017 12:44 AM, Martin Ågren wrote:
--set-upstream::
- If specified branch does not exist yet or if `--force` has been
- given, acts exactly like `--track`. Otherwise sets up configuration
- like `--track` would when creating the branch, except that where
$ git branch
* master
$ git branch --set-upstream origin/master
fatal: the '--set-upstream' flag is no longer supported and will be
removed. Consider using '--track' or '--set-upstream-to'
$ echo $?
128
$ git branch
* master
Signed-off-by: Kaartic Sivaraam &
Sign-off added should be that of the "committer" not that of the
"commit's author".
Use the correct logical variable that identifies the committer.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
This fixes a small issue when trying to do the
On Wednesday 09 August 2017 12:03 AM, Martin Ågren wrote:
(Also, is this really a refactoring?)
Not quite.
--set-upstream::
- If specified branch does not exist yet or if `--force` has been
- given, acts exactly like `--track`. Otherwise sets up configuration
- like
aster
Helped-by: Martin Ågren <martin.ag...@gmail.com>, Junio C Hamano
<gits...@pobox.com>
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
Changes in v4:
- made a few changes suggested by Martin
- hid the '--set-upstream' option from 'git branch
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
No changes in this one. Sending this just because of the change in the total
number
of commits.
branch.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/branch.c b/branch.c
for the changes that
are to be introduced to be independent of it.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
This was part of [PATCH v3 1/2] and has been separated as it seemed to be
a "logically separate" change.
t/t3200-branch.sh | 1 +
1 file changed, 1 in
On Tue, 2017-08-15 at 10:28 -0700, Junio C Hamano wrote:
> I did shoot for conciseness, but what is a lot more important is to
> record what is at the core of the issue. "I found it by doing A"
> can hint to careful readers why doing A leads to an undesirable
> behaviour, but when there are other
On Wed, 2017-08-16 at 12:09 -0700, Junio C Hamano wrote:
> You said that "checkout" does not do a necessary check that is done
> in "branch", so presumably "branch" already has a code to do so that
> is not called by the current "checkout", right? Then you would add
> a new caller in "checkout"
ottom line: Being consistent prevents all sorts of weird issues.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
Changes in v2:
- updated the commit message
Suggestions regarding ways to improve the message are most welcome.
templates/hooks--prepare-commit
On Thursday 17 August 2017 12:58 AM, Junio C Hamano wrote:
Nothing has. Neither thread seems to have any comment from anybody
but you, and I took it as an indication that people do not think it
is a good change.
I do not find the s/branch/parameter/ too bad (although I would have
said
alternative example that replaces it. This ensures there's
at the least a simple example that illustrates what could be done
using the hook just by enabling it.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
I have made the second patch depend on the first one to avoid
conflicts th
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
builtin/commit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 8d1cac062..aff6bf7aa 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -984,7 +984,7 @@
consistent
with the output of "-s" option.
While at it, name the input parameters to improve readability
of script.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
templates/hooks--prepare-commit-msg.sample | 18 --
1 file changed, 16 insertion
On Tue, 2017-07-11 at 13:22 -0700, Junio C Hamano wrote:
> Having said all that, I am not sure "Prevent such surprises" is a
> problem that is realistic to begin with. When a user sees the
> editor buffer in "git merge", it is pre-populated with at least a
> single line of message "Merge branch
On Tue, 2017-07-11 at 13:22 -0700, Junio C Hamano wrote:
> I think the "validation" done with the rest_is_empty() is somewhat
> bogus. Why should we reject a commit without a message and a
> trailer block with only signed-off-by lines, while accepting a
> commit without a message and a trailer
On Thu, 2017-07-13 at 10:58 -0700, Junio C Hamano wrote:
> I think many people know about and do use the "delete all lines"
> (i.e. ":1,$d" in vi, or \M-< \C-SPC \M-> \C-w in Emacs) to abort out
> of a commit or a merge. I just do not think it is likely for them
> to leave Sign-off lines and
The i18n config variable used weren't readable as they were in
the crude form of how git stores/uses it's config variables.
Improve it's readability by replacing them with camelCased versions
of config variables as it doesn't have any impact on it's usage.
Signed-off-by: Kaartic Sivaraam
.
Reformat the pragraph to make the 'cut-line' stand on a line of
it's own thus distinguishing it from the rest of the paragraph.
This further prevents it from getting wrapped to some extent.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
Documentation/git-commit.tx
uched" error which is wrong. He should be shown the
"empty message" error.
Do the empty message check before checking for an untouched template
thus fixing this issue.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
builtin/commit.c | 12 ++--
1
Note: Re-attempting to send mail due to rejection
On Mon, 2017-07-10 at 16:13 +0100, Ramsay Jones wrote:
>
> Again, s/signature/sign-off/g, or similar (including subject line).
>
Thanks! Forgot that in the course of splitting the patches and
modifying them.
--
Kaartic
On Mon, 2017-07-10 at 16:13 +0100, Ramsay Jones wrote:
>
> Again, s/signature/sign-off/g, or similar (including subject line).
>
Thanks! Forgot that in the course of splitting the patches and
modifying them.
On Fri, 2017-06-30 at 17:42 +0530, Kaartic Sivaraam wrote:
> The notice that "git commit " default to "git commit
> --only " was there since 756e3ee0 ("Merge branch
> 'jc/commit'", 2006-02-14). Back then, existing users of Git
> expected the command
Hello all,
I recently got the following error message by change as a result of the
command,
$ git branch -m no-branch master
fatal: A branch named 'master' already exists.
Note: no-branch is an hypothetical branch that doesn't exist.
Shouldn't I get a 'no-branch' doesn't exist before
Add a simple example that replaces an outdated example
that was removed. This ensures that there's at the least
a simple example that illustrates what could be done
using the hook just by enabling it.
Also, update the documentation.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.
Sorry, forgot to add the RFC suffix to [PATCH]. Please consider it's
presence.
--
Kaartic
e 261f315b ("merge & sequencer:
turn "Conflicts:" hint into a comment", 2014-08-28).
Further update the relevant comments from the sample script
and update the documentation.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
Documentation/githooks.txt
Add a simple example that replaces an outdated example
that was removed. This ensures that there's at the least
a simple example that illustrates what could be done
using the hook just by enabling it.
Also, update the documentation.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.
It's always nice to have named variables instead of
positional variables as they communicate their purpose
well.
Appropriately name the positional variables of the hook
to make it easier to see what's going on.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
templates
istent
with the output of "-s" option.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
templates/hooks--prepare-commit-msg.sample | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/templates/hooks--prepare-commit-msg.sample
b/templates/
On Mon, 2017-07-10 at 13:02 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes:
>
> > I made an attempt to make the second example work with amending
> > with the aim of making it suitable for usage out of the box. It
> > se
se surprises
to users who are accustomed to the meaning of an "empty message"
of "git commit".
Prevent such surprises by ensuring the meaning of an empty 'merge
message' to be in line with that of an empty 'commit message'. This
is done by separating the empty message validator from 'commit'
On Tue, 2017-07-11 at 09:03 -0700, Junio C Hamano wrote:
> But does it even be useful to enable it? The commented out "git
> status" output already lists the modified paths, so I do not think
> anything is gained by adding 'diff --cached --name-status' there.
The script *doesn't* add the output
On Tue, 2017-07-11 at 09:03 -0700, Junio C Hamano wrote:
> But does it even be useful to enable it?
Just for the note, I thought it was considered useful (at least to
someone) due to it's presence in the sample script.
Just wanted to know something out of curiosity. How am I actually
receiving these "What's cooking" emails though I'm not a subscriber to
the mailing list to which this is being addressed ? Further, my email
address isn't list in the To, Cc or Bcc fields.
I wanted to know this as, this has been
On Wed, 2017-07-05 at 12:50 -0700, Junio C Hamano wrote:
> Three things that caught my eyes:
>
> - Between "git commit --cleanup=strip" and "git commit --
> cleanup=verbatim",
> lines that make up this initial instruction section are different.
>
> - "git grep 'Please enter the '" finds
On Thu, 2017-07-13 at 12:23 -0700, Junio C Hamano wrote:
> All good points; if it bothers you that "commit" and "merge" define
> "emptyness" of the buffer differently too much, I think you could
> persuade me to unify them to "the buffer _must_ contain no bytes",
> i.e. not special-casing sign-off
On Fri, 2017-07-14 at 23:19 +0530, Kaartic Sivaraam wrote:
> * Imagine a hypothetical version of git that aborts when the
> is empty though a is present. This would
> quite possibly instigate controversies as the "hypothetical git"
> red
Hello,
As a heads up (and because I have been pulled into this thread :)), I
wanted to bring to the notice of translators that the commit,
b884244c8 commit-template: remove outdated notice about explicit paths
*removes* a message ("Explicit paths specified without -i or -o;
assuming --only
On Mon, 2017-07-17 at 15:16 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes:
> > + Same as `whitespace` except that everything from (and including)
> > +the line found below is truncated, if the message is to be edited.
> > +
.
Reformat the pragraph to make the 'cut-line' stand on a line of
it's own thus distinguishing it from the rest of the paragraph.
This further prevents it from getting wrapped to some extent.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
Documentation/git-commit.tx
On Sun, 2017-07-09 at 11:57 -0700, Junio C Hamano wrote:
> This is borderline "meh" at least to me. An argument against a
> hypothetical version of Git that "fixes" your issue would be that no
> matter what the source of renaming is, as long as 'master' exists,
> "branch -m" shouldn't overwrite
e 261f315b ("merge & sequencer:
turn "Conflicts:" hint into a comment", 2014-08-28).
Further remove the relevant comments from the sample script
and update the documentation.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
Documentation/githooks.txt
Add a simple example that replaces an outdated example
that was removed. This ensures that there's at the least
a simple example that illustrates what could be done
using the hook just by enabling it.
Also, update the documentation.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.
It's always nice to have named variables instead of
positional variables as they communicate their purpose
well.
Appropriately name the positional variables of the hook
to make it easier to see what's going on.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
templates
consistent
with the output of "-s" option.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
templates/hooks--prepare-commit-msg.sample | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/templates/hooks--prepare-commit-msg.sample
b/tem
The first illustration of the "RECOVERING FROM UPSTREAM REBASE"
section in the 'git-rebase' documentation wasn't in line with the
rest of the illustrations of that section.
Correct it.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
Documentation/git-reba
On Sat, 2017-07-08 at 15:33 -0700, Junio C Hamano wrote:
> That is how a message that is BCC'ed to you is supposed to look
> like, isn't it?
May be not. rfc5322 (Internet Message Format) seems to clear the
confusion,
There are three ways in which the "Bcc:" field is used. In the first case,
On Fri, 2017-07-07 at 08:05 -0700, Junio C Hamano wrote:
> That is because I wear multiple hats, because I try to help in
> different ways, and because open source is not a battle to see whose
> idea is more right, but is a cooperative process to find a better
> solution together.
>
Thanks for
On Sat, 2017-07-15 at 21:30 +0200, Jean-Noël Avila wrote:
> * commit 4ddb1354e8 ("status: contextually notify user about an initial
> commit") plays sentence lego while introducing colorization which again
> does not play well with i18n.
>
What, if anything, should be done about this?
--
s".
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
builtin/branch.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index a3bd2262b3367..59fedf085d3db 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
fatal: found flag '--flags' in place of a filename
$ git grep "test" -n
fatal: found flag '-n' in place of a filename
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The second patch differs from the first one only in the commit message.
--
Kaartic
I've added RFC to this patch's subject as I'm not sure if the new
message is suitable. Suggestions for messages that are more suitable
are welcome.
It seems that the function "verify_filename" is invoked by plumbing
commands like 'rev-parse', let me know if I've missed something about
them.
I
elow,
$ git branch
foo
* master
$ git branch -m foo foo old
fatal: too many branches for a rename operation
Change the messages to be more general thus making no assumptions
about the "parameters".
Signed-off-by: Kaartic Sivaraam <kaarticsiva
Let me see if I got everything correctly. Correct me if any of the
below observations are wrong.
On Mon, 2017-07-24 at 14:25 -0700, Junio C Hamano wrote:
> Imagine this scenario instead, which I think is more realistic
> example of making a typo. The set of existing branches are like
> this:
>
The patch in the previous mail results in a change in output as
specified below.
$ git branch
* master
foo
bar
Before patch,
$ git branch -m hypothet master
fatal: A branch named 'master' already exists.
$ git branch -m hypothet real
error: refname
-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
I'm sending this patch as I didn't want to leave this thread
open ended. I'm not yet sure if this is a good thing to do.
This patch is open to comments, as the prvious ones I've sent
have been.
builtin/branch.c | 4
Hello Jonathan Nieder,
Thanks for the reply!
Jonathan Nieder wrote:
>
> > The error message shown when a flag is found when expecting a
> > filename wasn't clear as it didn't communicate what was wrong
> > using the 'suitable' words in *all* cases.
> >
> > Correct case,
> >
> > $ git
Splitting a single sentence across multiple lines could
degrade readability. Further, long messages are likely
to be ignored by users.
Split the sentences and simplify it to improve their readability.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
re
On Thu, 2017-06-29 at 10:56 -0700, Junio C Hamano wrote:
> When I said "I would have ... if I were doing this", I merely meant
> exactly that---as I weren't doing it, I left it up to you. But you
> did it the way anyways, which is very nice of you ;-).
>
It made a *lot* of sense, that's why. :)
On Thu, 2017-06-29 at 11:17 -0700, Junio C Hamano wrote:
> The rationale of this has changed in this final version, hasn't it,
> especially with the removal of the "include/only warning" bit?
>
> We used to add a blank line to separate the "we are committing for
> somebody else", which is an
the other parts of the commit-template to make it more
readable.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
In trying to make the test independent of the previous test,
it got a bit long. Hope it's not doing anything that shouldn't
be done.
In case you would wonder, th
was changed to align with
other people's "$scm commit ", the text was added to help
them transition their expectations.
Remove the message that now has outlived its usefulness.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
Only commit message has been chang
.
Add the signature to the top of the commit message as it's
more appropriate and consistent with the "-s" option of git
commit.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
The change might seem to be bit of an hack, but it seems
worth it (at least to me).
The commit template adds the optional parts without
a new line to distinguish them. This results in
difficulty in interpreting it's content, specifically
for inexperienced users.
Add new lines to separate the distinct parts of the
template.
---
I tried writing tests to ensure that the new line
The notice that "git commit " default to "git commit
--only " was there since 756e3ee0 ("Merge branch
'jc/commit'", 2006-02-14). Back then, existing users of Git
expected the command doing "git commit --include ", and
after we changed the behaviour of the command to align with
other people's
On Fri, 2017-06-30 at 07:52 -0700, Junio C Hamano wrote:
> Thanks, both looks good. Will queue.
You're welcome :)
Will try to follow that in future. :)
--
Regards,
Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
On Fri, 2017-06-30 at 09:44 -0700, Junio C Hamano wrote:
> It does look like a hack. I was wondering if "interpret-trailers"
> is mature enough and can be used for this by now.
It does look promising except for a few differences from the hook which
I'll explain in the following mail.
> Also the
On Sat, 2017-07-01 at 19:45 +0530, Kaartic Sivaraam wrote:
> On Fri, 2017-06-30 at 09:44 -0700, Junio C Hamano wrote:
> > It does look like a hack. I was wondering if "interpret-trailers"
> > is mature enough and can be used for this by now.
>
> It does
consistent
with the output of "-s" option.
While at it, name the input parameters to improve readability
of script.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
I've tried the various commands that I could think of and it
seems to work well. I guess i
On Sat, 2017-07-01 at 10:36 -0700, Junio C Hamano wrote:
> Actually I was wondering if it is a good idea to remove it, as it
> seems to have outlived its usefulness.
It does seem to be a good idea but it would leave the 'prepare-commit-
msg' hook with no scripts that could be used by just
This script is a little different from others in that it uses THREE
hooks to acheive it's goal, which is to allow users to add notes for
a commit while writing the commit message. It's working isn't
guaranteed even if one of the hooks aren't executed.
It currently works in the following
example that replaces it to ensure there's
atleast one example that could be used just by enabling the hook.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91...@gmail.com>
---
This patch assumes that a previous patch that touched the commit
template [1] has been appled. Else it could remov
While trying to merge a branch using "git merge" if a merge
message consists only of a "Sign-off" line it doesn't fail.
To be consistent with the behaviour of "git commit" shouldn't the merge
fail?
--
Kaartic
On Sat, 2017-07-01 at 13:31 -0700, Junio C Hamano wrote:
> That sounds like a sample that is there not because it would be
> useful, but because we couldn't think of any useful example.
>
> IOW, I view it just as useful as a sample that does
>
> #!/bin/sh
> echo "# useless cruft"
On Mon, 2017-07-03 at 11:13 -0700, Junio C Hamano wrote:
> Adding HTTPS support
> > >
> > > I tried to add HTTP/HTTPS support to the custom built version
> > > for which
> > > AFAIK 'git' depends on 'curl'. I tried providing the location
> > > of the
> > >
On Mon, 2017-07-03 at 10:21 -0700, Junio C Hamano wrote:
> I think that it is not by design that it doesn't fail. It's not
> like we decided to allow s-o-b only merge because we found a reason
> why it is a good idea to do so.
>
> So I do not think anybody minds too deeply if somebody came up a
On Mon, 2017-07-03 at 09:58 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes:
>
> > So, it seems that excepting for 'commit' it has quite a nice
> > spacing. I
> > guess we could add something like the following to fix that,
>
Hello all,
Building without localization support
I tried to build git from source without localization support by adding
the following line to the Makefile,
NO_GETTEXT=1
It doesn't seem to be working for reasons I'm unable to find. I used
the following
On Thu, 2017-07-06 at 06:46 +0200, Kevin Daudt wrote:
>
> The function is called "rest_is_empty".
>
Thanks for correcting that!
> But isn't it better that commit and merge use the same code, instead
> of
> duplicating it again? Otherwise one may be updated, and the other
> forgotten, getting
On Wed, 2017-07-05 at 21:14 +0100, Ramsay Jones wrote:
>
> On 05/07/17 18:35, Kaartic Sivaraam wrote:
> > The sample hook to prepare the commit message before
> > a commit allows users to opt-in to add the signature
> > to the commit message. The signature is added a
1 - 100 of 495 matches
Mail list logo
