Hi all,
Thanks for the review. I apologize for rushing the patch out as I
wanted to get feedback on the new behavior before committing to any
more code changes. I also wanted to quickly clear any doubts that
people may have about my coding ability. (Or maybe it created more ;)
)
On Wed, Mar 4, 2
karthik nayak writes:
>> Looks suspiciously familiar...
> Yes, you suggested it.
> It has a similar structure to unpack_sha1_header().
> Anything wrong with it?
I don't know if there is something wrong with the code, or not, but
it wasn't mentioned in the log message at all that it is not your
c
Stefan Beller writes:
> I cannot remember the usual option off hand to describe the revision
> instead of a date.
Because "log --since= master" and "log v1.0..master"
mean two completely different things, we need some way to specify
which one of these two the user wants to "git clone" so that th
Jeff King writes:
> On Wed, Mar 04, 2015 at 12:56:10PM -0800, Junio C Hamano wrote:
>
>> > As in, while working on a specific project, I sometimes just want to
>> > exclude, for the time being, a bunch of stuff from 'git grep'.
>>
>> The key word here is "for the time being", though. What would
Jeff King writes:
> On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote:
>
>
>> This one, and $gmane/264101, are a few instances of this known issue
>> raised here recently.
>
> If $gmane/264101 is caused by clock skew, I'd find that disturbing.
> Those algorithms are supposed to be "c
On Wed, Mar 04, 2015 at 12:56:10PM -0800, Junio C Hamano wrote:
> > As in, while working on a specific project, I sometimes just want to
> > exclude, for the time being, a bunch of stuff from 'git grep'.
>
> The key word here is "for the time being", though. What would you
> do once you are done
On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote:
> > Calculating them is simple. Caching and storage is the bigger question.
>
> Yes, also having to handle the ones whose generation numbers haven't
> been computed yet adds to the complexity.
I'm not sure it's that bad. If you cach
Hi
http://newmajorityopportunity.org/interest.php?action=6azpd6cuw9fb2
wb...@aol.com
Sent from my iPhone
--
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
René Scharfe writes:
> No sign-off, yet, because I'm not sure we really need another option.
> E.g. --text=all doesn't seem to be actually useful, but it was easy to
> implement. Info-ZIP's zip always creates archives like --text=auto
> does, so perhaps we should make that our default behavior a
On Wed, Mar 4, 2015 at 6:44 PM, Junio C Hamano wrote:
> Troy Moure writes:
>
>> git rev-list --bisect --first-parent --parents HEAD --not HEAD~1
>
> Hmm, as "rev-list --bisect" is not end-user facing command (it is
> purely an implementation detail for "git bisect") and we never call
> it with --
Lasse Kliemann writes:
> 1. Try pushing to origin/master. If it works, fine. If not, goto 2.
>
> 2. Push to the appropriate personal branch.
I wonder what happens to this user _after_ that change gets
integrated on the project side. Presumably somebody picks up the
change from the "personal bra
Junio C Hamano writes:
>> +versionsort.prereleaseSuffix::
>> +When version sort is used in linkgit:git-tag[1], prerelease
>> +tags (e.g. "1.0-rc1") may appear after the main release
>> +"1.0". By specifying the suffix "-rc" in this variable,
>> +"1.0-rc1" will appear before "1.0".
On 03/05/2015 02:28 AM, Junio C Hamano wrote:
Karthik Nayak writes:
> add "sha1_object_info_literally()" which is to be used when
> the "literally" option is given to get the type of object
> and print it, using "sha1_object_info_extended()".
>
> add "unpack_sha1_header_literally()" to unpack
Stefan Beller writes:
> On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano wrote:
>> On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley wrote:
git clone --since 2.weeks.ago
git clone --since v2.10
>>>
>>> The use of --since instead of --date would be an equally valid way of
>>> sp
Amate Yolande writes:
> This is a patch for my work on one of the micro projects, as I intend
> to apply for the Google Summer of Code 2015 under the Git community.
> This patch gives the user the oppotunity to specify configuration
> options for some commonly used command-line options for
On Wed, Mar 4, 2015 at 11:10 AM, Shawn Pearce wrote:
> On Wed, Mar 4, 2015 at 4:05 AM, Duy Nguyen wrote:
>> On Wed, Mar 4, 2015 at 11:27 AM, Shawn Pearce wrote:
>>> Let me go on a different tangent a bit from the current protocol.
>>>
>>> http://www.grpc.io/ was recently released and is built on
Sudhanshu Shekhar writes:
>> What should worry us even more is what the user would get when @{-1}
>> does not resolve to something the command can use. It would be bad
>> if we give an error message with @{-1} in it that the user never
>> typed (and may not even understand what it means).
>
> I
On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano wrote:
> On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley wrote:
>>>
>>>git clone --since 2.weeks.ago
>>>git clone --since v2.10
>>
>> The use of --since instead of --date would be an equally valid way of
>> spelling the option (coders choice;
On Thu, Mar 5, 2015 at 6:55 AM, Stefan Beller wrote:
> On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley wrote:
>
>> A possible idea is to add a date based variant of shallow clone :
>>
>> 'git clone --date ...'
>>
>> in the same vein as the existing depth (shallow) clone.
>
> As food for thought:
On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley wrote:
>>
>>git clone --since 2.weeks.ago
>>git clone --since v2.10
>
> The use of --since instead of --date would be an equally valid way of
> spelling the option (coders choice;-)
I think it is a demonstration of poor taste. Everywhere els
Hello
My name is Amate Yolande a first year computer science student
from Cameroon. I would like to participate in the google summer fo
code 2015 with the Git community. I have done one of the micro project
and I hope it gets reviewed soon so I could update it. I would like to
work on the
On Tue, Mar 3, 2015 at 3:43 AM, Michael Haggerty wrote:
> This is v3 of the patch series. Thanks to Junio for his comments
> about v2 [1]; I think this version addresses all of his points.
>
> Changes since v2:
>
> * Introduce a temporary in "struct ref_lock: delete the force_write
> member" to
From: "Stefan Beller"
On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley
wrote:
A possible idea is to add a date based variant of shallow clone :
'git clone --date ...'
in the same vein as the existing depth (shallow) clone.
As food for thought:
Maybe broaden this further up to the git-ish
This is a patch for my work on one of the micro projects, as I intend
to apply for the Google Summer of Code 2015 under the Git community.
This patch gives the user the oppotunity to specify configuration
options for some commonly used command-line options for exampel:
git config de
On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley wrote:
> A possible idea is to add a date based variant of shallow clone :
>
> 'git clone --date ...'
>
> in the same vein as the existing depth (shallow) clone.
As food for thought:
Maybe broaden this further up to the git-ish way of describing re
Troy Moure writes:
> git rev-list --bisect --first-parent --parents HEAD --not HEAD~1
Hmm, as "rev-list --bisect" is not end-user facing command (it is
purely an implementation detail for "git bisect") and we never call
it with --first-parent, I am not sure if it is worth labelling it as
a BUG.
>On 4 Mar 2015, Junio C Hamano Wrote:
> Sent: March 4, 2015 5:11 PM
> To: Ben Walton
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] Use unsigned char to squash compiler warnings
>
> Ben Walton writes:
>
> > On Mon, Mar 2, 2015 at 8:30 PM Junio C Hamano
> wrote:
> >
> >> The conversion looked
Ben Walton writes:
> On Mon, Mar 2, 2015 at 8:30 PM Junio C Hamano wrote:
>
>> The conversion looked good from a cursory view; I didn't check it
>> very carefully though.
>>
> Yes, because of the Solaris ABI, the Studio compiler defaults char to
> signed char.
Doesn't our beloved GCC also uses
On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, Mar 04, 2015 at 04:06:17PM +0100, Michael J Gruber wrote:
> >
> >> Complexity: Was that due to replace refs? Other than that, it seemed to
> >> be simple: max(parent generation numbers)+1.
> >
> > Ca
From: "Matthieu Moy"
Sent: Friday, February 20, 2015 9:39 AM
Jeff King writes:
- Matthieu, who also cited time constraints
Just to clarify: last year we were co-mentoring with Ram. I ended up
having a lot of time and did most of the work (not blaming Ram, and I
enjoyed the experience). I'
The 'true' short-hand doesn't deserve a separate sentence; even our own
git config --bool foo.bar yes
would not produce it.
Signed-off-by: Junio C Hamano
---
Documentation/config.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Document
Instead of describing it for color.branch. and have everybody
else refer to it, explain how colors are spelled in "Values" section
upfront.
Signed-off-by: Junio C Hamano
---
Documentation/config.txt | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git
In "git log --decorate", you would see the commit header like this:
commit ... (HEAD, jc/decorate-leaky-separator-color)
where "commit ... (" is painted in color.diff.commit, "HEAD" in
color.decorate.head, ", " in color.diff.commit, the branch name in
color.decorate.branch and then closing ")
The various types of values set to the configuration variables
deserve more than a brief footnote mention in the syntax section,
and it will be more so after the later steps of this clean up
effort.
Move the mention of booleans from the syntax section to this new
section, and describe how human-re
Entries in a ZIP file can be marked as text files. Extractors can use
that flag to apply end-of-line conversions. An example is unzip -a.
git archive currently marks all ZIP file entries as binary files. This
patch adds the new option --text that can be used to mark non-binary
files or all file
The syntax section repeats what the preamble explained already.
That a variable can have multiple values is more about what a
variable is than the syntax of the file.
Signed-off-by: Junio C Hamano
---
Documentation/config.txt | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --g
In "git log --decorate", you would see the commit header like this:
commit ... (HEAD, jc/decorate-leaky-separator-color)
where "commit ... (" is painted in color.diff.commit, "HEAD" in
color.decorate.head, ", " in color.diff.commit, the branch name in
color.decorate.branch and then closing ")
A line can be continued via a backquote-LF and can be chomped at a
comment character. But that is not specific to string-typed values.
It is common to all, just like unquoted leading and trailing
whitespaces are stripped and inter-word spacing are retained.
Move the description around and desribe
Section names and variable names are both case-insensitive, but one
is described as "not case sensitive". Use "case-insensitive" for
both.
Instead of saying "... have to be escaped" without telling what that
escaping achieves, state it in a more positive way, i.e. "... can be
included by escaping
Michael J Gruber writes:
>> Ahh, OK. The way the existing tests prepare 'expect' is "by hand".
>>
>> So I think what is wrong with this new test is not that relies on
>> the current contents of 'expect', but that it modifies it (imagine
>> being a merge/patch monkey who has to accept this chang
Michael J Gruber writes:
> Junio C Hamano venit, vidit, dixit 03.03.2015 22:26:
>> Michael J Gruber writes:
>>
>>> +diff --git INDEX=staged-for-commit/dir1/modified
>>> WORKTREE=not-staged-for-commit/dir1/modified
>>> +index e69de29..d00491f 100644
>>> +--- INDEX=staged-for-commit/dir1/modified
Am 23.02.2015 um 20:30 schrieb René Scharfe:
Am 23.02.2015 um 14:58 schrieb Ulrike Fischer:
The zip contained four text files and a pdf.
The CTAN maintainers informed me that all files in the zip are
flagged as binaries and this makes it difficult for them to process
them further (they want to
Karthik Nayak writes:
> add "sha1_object_info_literally()" which is to be used when
> the "literally" option is given to get the type of object
> and print it, using "sha1_object_info_extended()".
>
> add "unpack_sha1_header_literally()" to unpack sha headers
> which may be greater than 32 bytes,
Noel Grandin writes:
> On 2015-03-02 02:50 PM, Trevor Saunders wrote:
>> I think they solve somewhat different problems, but maybe my problem
>> is so specialized I should just have a wrapper around grep that
>> changes defaults. Trev
>
> I'm with Trevor on this one. While I see the appeal of th
Jeff King writes:
> On Wed, Mar 04, 2015 at 04:06:17PM +0100, Michael J Gruber wrote:
>
>> Complexity: Was that due to replace refs? Other than that, it seemed to
>> be simple: max(parent generation numbers)+1.
>
> Calculating them is simple. Caching and storage is the bigger question.
Yes, also
Michael J Gruber writes:
>> I am not sure how the intention of the commit 1c2eafb8 (Add
>> url..pushInsteadOf: URL rewriting for push only, 2009-09-07),
>> which introduced the behaviour verified by this test, interacts with
>> the desire to redefine what URL and pushURL mean in our recent past,
On Wed, Mar 4, 2015 at 11:54 AM, Junio C Hamano wrote:
> Chris Pimlott writes:
>
>> folio:text chris$ git --git-dir=../.git describe --always --dirty
>> c0edd63-dirty
>
> I have a feeling that this is not limited to describe at all. With
> the --git-dir option, you are telling Git that your
Anton Trunov writes:
> For the code version before applying this patch the following scenario
> will take place if "git merge -Xignore-all-space remote" gets executed.
>
> base file:
> 1st line
> 2nd line
>
> master file:
> 1st line
> 2nd line with substantial change
>
> remote file:
>
Matthieu Moy writes:
> Jeff King writes:
>
>> Maybe something along the lines of "If you are really excited about
>> working on git, we would love to see your application; if you are just
>> looking for a random project, there may be a lot of competition for a
>> small number of slots". Except I
Chris Pimlott writes:
> It seems that git-describe always thinks that working copy is dirty if
> you are not in the WC root and you explicitly specify the .git
> directory location using --git-dir:
>
> # set up test repo
> folio:~ chris$ mkdir repo && cd repo
> folio:repo chris$ mkdir text
It seems that git-describe always thinks that working copy is dirty if
you are not in the WC root and you explicitly specify the .git
directory location using --git-dir:
# set up test repo
folio:~ chris$ mkdir repo && cd repo
folio:repo chris$ mkdir text && echo hi > text/hi.txt
folio:repo
On Wed, Mar 4, 2015 at 4:05 AM, Duy Nguyen wrote:
> On Wed, Mar 4, 2015 at 11:27 AM, Shawn Pearce wrote:
>> Let me go on a different tangent a bit from the current protocol.
>>
>> http://www.grpc.io/ was recently released and is built on the HTTP/2
>> standard. It uses protobuf as a proven extens
On Wed, Mar 04, 2015 at 04:06:17PM +0100, Michael J Gruber wrote:
> > 3. Introduce a more trust-worthy mechanism for ordering commits. The
> > timestamp here is really just a proxy for the oft-discussed
> > "generation number" of the commit within the graph. We've avoided
> > addi
On Wed, Mar 04, 2015 at 04:46:47PM +0100, Michael J Gruber wrote:
>
> So, how does this relate to:
>
> http://permalink.gmane.org/gmane.comp.version-control.git/264592
>
> I don't mind you taking this over at all, it's just that we should keep
> things together where the discussion begun.
>
> M
Kevin Daudt venit, vidit, dixit 04.03.2015 00:12:
> Only behaviour with these options are currently explained. Add
> explanation what the default behaviour is.
>
> Signed-off-by: Kevin Daudt
> ---
> Documentation/git-remote.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documen
David Lang venit, vidit, dixit 04.03.2015 01:53:
> On Tue, 3 Mar 2015, Shawn Pearce wrote:
>
>> On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller wrote:
>>> bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity
>>
>> Indeed, a DVCS like Git or Hg does not fit everyone. And neither do
Jeff King venit, vidit, dixit 04.03.2015 11:54:
> On Thu, Feb 26, 2015 at 03:23:14PM +0100, Michal Hocko wrote:
>
>> The commit in the middle was ammended to have committer date in the
>> past.
>> $ git describe --contains d63972e4e4e7eda0444e56739ad09bfbc476b9bd
>> tag~1
>>
>> but
>> $ git descri
Mason wrote:
I was planning to write 'git diff -q commit^ commit'
to test for empty commits. Looks like I'll be needing
'git diff commit^ commit | wc -l' instead?
I wrote a script to generate the list of empty commits.
git log --format="%h" --reverse 413cb08.. | while read H
do
if git diff
The test checks that both remotes under '$GIT_DIR/remotes' and remotes
in the config file are listed.
Signed-off-by: SZEDER Gábor
---
t/t9902-completion.sh | 19 +++
1 file changed, 19 insertions(+)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index f10a752..7a883d
The __git_remotes() helper function lists the remotes from the config
file by processing the output of a 'git config' query. A simple 'git
remote' produces the exact same output, so run that instead.
Remotes under '$GIT_DIR/remotes' are still listed by running 'ls -1',
because 'git remote' unfort
Hi,
Quoting SZEDER Gábor :
Hi,
Quoting Junio C Hamano :
SZEDER Gábor writes:
@@ -412,7 +412,7 @@ __git_refs_remotes ()
__git_remotes ()
{
local i IFS=$'\n' d="$(__gitdir)"
- test -d "$d/remotes" && ls -1 "$d/remotes"
+ test -d "$d/remotes" && ls -1 "$d/remotes" 2>/dev
On Wed, Mar 4, 2015 at 11:27 AM, Shawn Pearce wrote:
> Let me go on a different tangent a bit from the current protocol.
>
> http://www.grpc.io/ was recently released and is built on the HTTP/2
> standard. It uses protobuf as a proven extensibility mechanism.
> Including a full C based grpc stack
On Wed, Mar 4, 2015 at 6:26 PM, Jeff King wrote:
>> > It might be nice if parseopt had a PARSE_OPT_NEGHELP option or something
>> > to show the "--no-" form.
>>
>> Regardless, yes it would be nice to have something like this. I think
>> there are places that can make use of this.
>
> Grepping arou
On Wed, Mar 04, 2015 at 06:13:32PM +0700, Duy Nguyen wrote:
> On Wed, Mar 4, 2015 at 5:16 PM, Jeff King wrote:
> > Hmm. If the default is "--exclude-standard", then what expect people to
> > use is "--no-exclude-standard". Would it make more sense to list that in
> > the "-h" output?
>
> I thoug
On 2015-03-02 02:50 PM, Trevor Saunders wrote:
I think they solve somewhat different problems, but maybe my problem is so specialized I should just have a wrapper
around grep that changes defaults. Trev
I'm with Trevor on this one. While I see the appeal of the generality of a macro solution,
On Wed, Mar 4, 2015 at 5:31 PM, Jeff King wrote:
> On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote:
>
>> On Thu, Feb 19, 2015 at 2:14 AM, Jeff King wrote:
>> > Where I really need help now is in the "ideas" page:
>> >
>> > http://git.github.io/SoC-2015-Ideas.html
>>
>> Is this too am
On Wed, Mar 4, 2015 at 5:16 PM, Jeff King wrote:
> Hmm. If the default is "--exclude-standard", then what expect people to
> use is "--no-exclude-standard". Would it make more sense to list that in
> the "-h" output?
I thought about it and actually edited git-grep man page to clarify
the default,
Junio C Hamano venit, vidit, dixit 03.03.2015 22:26:
> Michael J Gruber writes:
>
>> +diff --git INDEX=staged-for-commit/dir1/modified
>> WORKTREE=not-staged-for-commit/dir1/modified
>> +index e69de29..d00491f 100644
>> +--- INDEX=staged-for-commit/dir1/modified
>> WORKTREE=not-staged-for-c
Junio C Hamano venit, vidit, dixit 03.03.2015 23:26:
> Junio C Hamano writes:
>
>> Michael J Gruber writes:
>>
>>> Signed-off-by: Michael J Gruber
>>> ---
>>> t/t7508-status.sh | 6 ++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/t/t7508-status.sh b/t/t7508-status.sh
>>> index
On Thu, Feb 26, 2015 at 03:23:14PM +0100, Michal Hocko wrote:
> The commit in the middle was ammended to have committer date in the
> past.
> $ git describe --contains d63972e4e4e7eda0444e56739ad09bfbc476b9bd
> tag~1
>
> but
> $ git describe --contains 108a0d5972fd2e5f25b2f38cfd2fee73031ff9d3
> f
On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote:
> On Thu, Feb 19, 2015 at 2:14 AM, Jeff King wrote:
> > Where I really need help now is in the "ideas" page:
> >
> > http://git.github.io/SoC-2015-Ideas.html
>
> Is this too ambitious for a summer? I suspect the answer is yes, but any
On Fri, Feb 27, 2015 at 09:01:58PM +0700, Nguyễn Thái Ngọc Duy wrote:
> The current help string is about --no-exclude-standard. But "git grep -h"
> would show --exclude-standard instead. Flip the string. See 0a93fb8
> (grep: teach --untracked and --exclude-standard options - 2011-09-27)
> for more
Anders Kaseorg venit, vidit, dixit 04.03.2015 10:43:
> On Wed, 4 Mar 2015, Michael J Gruber wrote:
>> If there is no "pushurl":
>> "url" will be used as the "URL for fetch" and as the "URL for push".
>> if we are pushing and there is "pushinsteadof" for (part of) "url"
>> subsitute that wit
On Fri, Feb 27, 2015 at 01:09:30AM +0100, Marc-André Lureau wrote:
> It would be nice if git-add could be told to ignore whitespace
> changes, wouldn't it?
>
> According to SO, I am not the one to think so:
> http://stackoverflow.com/questions/3515597/git-add-only-non-whitespace-changes
>
> A ch
On Wed, Mar 4, 2015 at 4:55 AM, Anton Trunov wrote:
> On 04/03/15 10:07, Eric Sunshine wrote:
+ echo " \t\ttwo words " >text.txt &&
>>
>> Use of echo "\t" is not portable. Either embed literal tab characters
>> or use printf "\t".
> OK.
> Shouldn't it be printf "\t\n" for exact subst
On 03/03/15 23:17, Torsten Bögershausen wrote:
> On 2015-03-03 18.37, Anton Trunov wrote:
> []
>> Signed-off-by: Anton Trunov gmail.com>
> Should we use the "real email" here (with the '@') ?
Didn't realize the parser for the web version mangles emails.
Will use the "real email".
>> ---
>> t/t3
On 04/03/15 10:07, Eric Sunshine wrote:
> On Tue, Mar 3, 2015 at 3:17 PM, Torsten Bögershausen wrote:
>> On 2015-03-03 18.37, Anton Trunov wrote:
>> []
>>> Signed-off-by: Anton Trunov gmail.com>
>> Should we use the "real email" here (with the '@') ?
>>> ---
>>> diff --git a/t/t3032-merge-recursi
On Wed, 4 Mar 2015, Michael J Gruber wrote:
> If there is no "pushurl":
> "url" will be used as the "URL for fetch" and as the "URL for push".
> if we are pushing and there is "pushinsteadof" for (part of) "url"
> subsitute that within "url"
> else if there is "insteadof" for (part of) "u
On Wed, Mar 04, 2015 at 04:24:58AM +0800, Paul Tan wrote:
> @@ -111,8 +114,7 @@ static void remove_credential(const char *fn, struct
> credential *c)
>
> static int lookup_credential(const char *fn, struct credential *c)
> {
> - parse_credential_file(fn, c, print_entry, NULL);
> - ret
On 03/03/15 23:32, Junio C Hamano wrote:
> Anton Trunov writes:
>
>> The git-merge manual says that the ignore-space-change,
>> ignore-all-space, ignore-space-at-eol options preserve our version
>> if their version only introduces whitespace changes to a line.
>>
>> So far if there is whitespace-
Junio C Hamano venit, vidit, dixit 03.03.2015 21:06:
> Michael J Gruber writes:
>
>> Junio C Hamano venit, vidit, dixit 02.03.2015 20:43:
>>> Anders Kaseorg writes:
>>>
Signed-off-by: Anders Kaseorg
---
t/t5516-fetch-push.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletio
On Tue, Mar 03, 2015 at 03:54:05PM -0800, Mike Botsko wrote:
> Thanks, that clarifies a lot.
>
> I only have two follow-up questions:
>
> In your branch example, how does git determine that C/D have been
> rewritten and need to be "replaced" with their current versions
> existing upstream? In thi
On Mon, Mar 02, 2015 at 02:00:09AM +0100, SZEDER Gábor wrote:
> It's not just 'grep -c' but the 'test' checking its output as well.
>
> If something goes wrong and the line count doesn't match expectations
> 'test' fails silently leaving the developer clueless as to what went
> wrong.
>
> 'test_
On March 3, 2015 11:30:13 PM GMT+05:30, Junio C Hamano
wrote:
>On Tue, Mar 3, 2015 at 8:22 AM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> now it works like cd "" which silently succeeds
>>
>> Missing "." at end of sentence.
>
>And lack of capitalization at the beginning.
Yes, noted,
Dennis Kaarsemaker writes:
> For the first step, I'd send a mail to this list asking people for
> input,
I'd even put that as step 2. Step 1 would be: watch the list and see if
anyone is not already working on it. Hint, hint ...
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscrib
85 matches
Mail list logo
