On Sat, Jan 24, 2015 at 5:45 PM, Robert Dailey wrote:
> On Fri, Jan 23, 2015 at 10:23 PM, Robert Dailey
> wrote:
>> On Fri, Jan 23, 2015 at 4:13 PM, Chris Packham
>> wrote:
>>> Hi,
>>>
>>> On Fri, Jan 23, 2015 at 3:50 PM, Robert Dailey
>>> wrote:
I have a submodule using HTTP URL. I do t
On Friday, January 23, 2015 01:14:03 PM you wrote:
> Stefan Beller writes:
>
> >> Ok. How should I then ignore any local changes to the .gitignore
> >> file ? And while taking pull, git should skip this file ?
> >
> > Look at .git/info/exclude
>
> Good answer for ".gitignore". In general, you d
On Fri, Jan 23, 2015 at 10:23 PM, Robert Dailey
wrote:
> On Fri, Jan 23, 2015 at 4:13 PM, Chris Packham
> wrote:
>> Hi,
>>
>> On Fri, Jan 23, 2015 at 3:50 PM, Robert Dailey
>> wrote:
>>> I have a submodule using HTTP URL. I do this:
>>>
>>> $ git submodule init MySubmodule
>>> $ git submodule
On Fri, Jan 23, 2015 at 4:13 PM, Chris Packham wrote:
> Hi,
>
> On Fri, Jan 23, 2015 at 3:50 PM, Robert Dailey
> wrote:
>> I have a submodule using HTTP URL. I do this:
>>
>> $ git submodule init MySubmodule
>> $ git submodule update MySubmodule
>>
>> The 2nd command fails because the HTTP URL c
On Fri, Jan 23, 2015 at 1:49 AM, Junio C Hamano wrote:
> I am not (yet) enthused by the intrusiveness of the overall series, though.
I think the gain justifies the series' complexity. Although I don't
mind redoing the whole series if we find a better way.
--
Duy
--
To unsubscribe from this list:
Craig Silverstein writes:
>>> Doesn't a submodule checkout keep some state tied to the working
>>> tree in its repository configuration file?
>>
>> Do you mean, in 'config' itself? If so, I don't see it. (Though it's
>> possible there are ways to use submodules that do keep working-tree
>> stat
Stefan Beller writes:
> On Fri, Jan 23, 2015 at 4:39 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> On Fri, Jan 23, 2015 at 3:57 PM, Junio C Hamano wrote:
Stefan Beller writes:
> -static int commit_ref(struct ref_lock *lock)
> +static int commit_ref(struct ref_loc
On Fri, Jan 23, 2015 at 4:39 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Fri, Jan 23, 2015 at 3:57 PM, Junio C Hamano wrote:
>>> Stefan Beller writes:
>>>
-static int commit_ref(struct ref_lock *lock)
+static int commit_ref(struct ref_lock *lock, const unsigned char *sha
Ping! (now that the holidays are past)
craig
On Tue, Dec 23, 2014 at 1:51 PM, Craig Silverstein
wrote:
> [Ack, I forgot to cc myself on the original patch so now I can't reply
> to it normally. Hopefully my workaround doesn't mess up the threading
> too badly.]
>
> Junio C Hamano pobox.com> wr
Stefan Beller writes:
> On Fri, Jan 23, 2015 at 3:57 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> -static int commit_ref(struct ref_lock *lock)
>>> +static int commit_ref(struct ref_lock *lock, const unsigned char *sha1)
>>> {
>>> + if (!lock->force_write && !hashcmp(lock->old
Stefan Beller writes:
> On Fri, Jan 23, 2015 at 4:14 PM, Junio C Hamano wrote:
>
> yeah that's the goal. Though as we're in one transaction, as soon
> as we have an early exit, the transaction will abort.
An early exit I am talking about is this:
static int write_ref_sha1(struct ref_lock *lock
On Fri, Jan 23, 2015 at 4:14 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> By closing the file descriptors after creating the lock file we are not
>> limiting the size of the transaction by the number of available file
>> descriptors.
>>
>> When closing the file descriptors early, we als
On Fri, Jan 23, 2015 at 3:57 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> -static int commit_ref(struct ref_lock *lock)
>> +static int commit_ref(struct ref_lock *lock, const unsigned char *sha1)
>> {
>> + if (!lock->force_write && !hashcmp(lock->old_sha1, sha1))
>> + r
Stefan Beller writes:
> By closing the file descriptors after creating the lock file we are not
> limiting the size of the transaction by the number of available file
> descriptors.
>
> When closing the file descriptors early, we also need to write the values
> in early, if we don't want to reope
Stefan Beller writes:
> -static int commit_ref(struct ref_lock *lock)
> +static int commit_ref(struct ref_lock *lock, const unsigned char *sha1)
> {
> + if (!lock->force_write && !hashcmp(lock->old_sha1, sha1))
> + return 0;
> if (commit_lock_file(lock->lk))
>
GitHub is organizing a Git-related conference to be held April 8-9,
2015, in Paris. Details here:
http://git-merge.com/
The exact schedule is still being worked out, but there is going to be
some dedicated time/space for Git (and libgit2 and JGit) developers to
meet and talk to each other.
If
Torsten Bögershausen writes:
> It has been tested under Mac OS, root@Mac OS, Cygwin / Msysgit
> What do you think ?
Except that we may want to be more careful to detect errors from the
initial mkdir and clean-up part (which should abort the test, not
just declare !SANITY), I think the basic idea
Pete Wyckoff writes:
> Hi Junio. I'm fortunate enough to need no longer any git
> integration with Perforce (p4). I work only in git these days.
> Thus you might expect my interest in improving git-p4 would
> be waning.
>
> Luke, on the other hand, continues to need git-p4 and is
> active in impr
On Fri, Jan 23, 2015 at 06:04:19AM -0500, Jeff King wrote:
> On Fri, Jan 23, 2015 at 10:29:08AM +0900, Mike Hommey wrote:
>
> > While fooling around with copy/rename detection, I noticed that it
> > doesn't detect the case where you copy or rename a file on top of
> > another:
> >
> > $ git init
Mike Hommey writes:
>> In the context of "git blame", "-C" and "-M" control orthogonal
>> concepts and it makes sense to use only one but not the other, or
>> both.
>
> In the context of blame both -C and -M |= a flags set, so one doesn't
> override the other. You can place them in any order, the
On Fri, Jan 23, 2015 at 2:26 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Assuming you want to ignore less than the upstream project (delete some
>> lines from .gitignore) it get's tricky in my opinion.
>
> Why? Doesn't info/exclude allow negative ignore patterns?
I used negative patt
On Fri, Jan 23, 2015 at 10:41:10AM -0800, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > While -C implies -M, it is quite common to see both on example command lines
> > here and there. The unintuitive thing is that if -M appears after -C, then
> > copy detection is turned off because of how t
Stefan Beller writes:
> Assuming you want to ignore less than the upstream project (delete some
> lines from .gitignore) it get's tricky in my opinion.
Why? Doesn't info/exclude allow negative ignore patterns?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a me
Hi,
On Fri, Jan 23, 2015 at 3:50 PM, Robert Dailey wrote:
> I have a submodule using HTTP URL. I do this:
>
> $ git submodule init MySubmodule
> $ git submodule update MySubmodule
>
> The 2nd command fails because the HTTP URL cannot be resolved, this is
> because it requires a proxy. I have "htt
Thanks, Jens.
Incidentally,
git submodule update --init --recursive
Does exactly what expected – it updates sub/sub/submodules, so there
is certainly some inconsistency in how the --recursive flag is handled
here.
i...@maxheld.de | http://www.maxheld.de | http://www.civicon.de |
Mobil: +49 151 2
Hi Junio. I'm fortunate enough to need no longer any git
integration with Perforce (p4). I work only in git these days.
Thus you might expect my interest in improving git-p4 would
be waning.
Luke, on the other hand, continues to need git-p4 and is
active in improving it. I think you should conside
l...@diamand.org wrote on Fri, 23 Jan 2015 09:15 +:
> If you use git-p4 with the "--prepare-p4-only" option, then
> it prints the p4 command line to use. However, the command
> line was incorrect: the changelist specification must be
> supplied on standard input, not as an argument to p4.
>
>
On Fri, Jan 23, 2015 at 1:14 PM, Junio C Hamano wrote:
>
> Good answer for ".gitignore". In general, you do not "ignore local
> changes" to tracked paths.
>
I assumed Arup would want to ignore more than is in the upstream project,
so you'd come up with an appendix to the .gitignore file because
On 2015-01-22 23.07, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> If I run that sequence manually:
>> chmod 755 .
>> touch x
>> chmod a-w .
>> rm x
>> touch y
>>
>> x is gone, (but shoudn't according to POSIX)
>> y is not created, "access denied"
>
> Good (or is that Sad?).
>
>> di
Stefan Beller writes:
>> Ok. How should I then ignore any local changes to the .gitignore
>> file ? And while taking pull, git should skip this file ?
>
> Look at .git/info/exclude
Good answer for ".gitignore". In general, you do not "ignore local
changes" to tracked paths.
> I found https://h
On Fri, Jan 23, 2015 at 10:35 AM, Arup Rakshit
wrote:
> On Friday, January 23, 2015 11:31:40 AM you wrote:
>> Arup Rakshit writes:
>>
>> > I asked git not to track any changes to the file .gitignore. To do
>> > so I did use the command - git update-index --assume-unchanged
>> > .gitignore.
>>
>>
The 'lock_fd' is the same as 'lk->fd'. No need to store it twice so remove
it. You may argue this introduces more coupling as we need to know more
about the internals of the lock file mechanism, but this will be solved in
a later patch.
No functional changes intended.
Signed-off-by: Stefan Beller
During creation of the patch series our discussion we could have a
more descriptive name for the prerequisite for the test so it stays
unique when other limits of ulimit are introduced.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
Notes:
v2->v3:
no changes
t/t7004-ta
By moving the functions up we don't need to have to declare them first
when using them in a later patch.
Signed-off-by: Stefan Beller
---
Notes:
new in v3
refs.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/refs.c b/refs.c
index 4066752
By closing the file descriptors after creating the lock file we are not
limiting the size of the transaction by the number of available file
descriptors.
When closing the file descriptors early, we also need to write the values
in early, if we don't want to reopen the files.
Signed-off-by: Stefan
This makes write_ref_sha1 only write the the lock file, committing
needs to be done outside of that function. This will help us change
the ref_transaction_commit in a later patch.
Also instead of calling unlock_ref before each return in write_ref_sha1
we can call this after the call. This is a fir
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
Notes:
v2->v3:
no changes
t/t1400-update-ref.sh | 28
1 file changed, 28 insertions(+)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 7b4707b..47d2fe9 100755
--- a/t/t1400-upd
version3:
patches 1,2,3 stayed completely as is, while patches 4,5 are new, patch 6 is
rewritten to first write the contents of the lock files before closing them.
This combines the series "Enable large transactions v2" as sent out yesterday
with the follow up series "[RFC PATCH 0/5] So
On Fri, Jan 23, 2015 at 11:49:05AM -0800, Junio C Hamano wrote:
> 4fe10219 (rev-list: add --indexed-objects option, 2014-10-16) adds
> "--indexed-objects" option to "rev-list", and it is only useful in
> the context of "git rev-list" and not "git log". There are other
> object traversal options t
4fe10219 (rev-list: add --indexed-objects option, 2014-10-16) adds
"--indexed-objects" option to "rev-list", and it is only useful in
the context of "git rev-list" and not "git log". There are other
object traversal options that do not make sense for "git log" that
are shown in the manual page.
M
On Friday, January 23, 2015 11:31:40 AM you wrote:
> Arup Rakshit writes:
>
> > I asked git not to track any changes to the file .gitignore. To do
> > so I did use the command - git update-index --assume-unchanged
> > .gitignore.
>
> You are not asking Git to do anything. You promised Git that y
Arup Rakshit writes:
> I asked git not to track any changes to the file .gitignore. To do
> so I did use the command - git update-index --assume-unchanged
> .gitignore.
You are not asking Git to do anything. You promised Git that you
will make no changes to .gitignore, and then broke that promis
Hi,
I asked git not to track any changes to the file .gitignore. To do so I did use
the command - git update-index --assume-unchanged .gitignore.
[arup@sztukajedzenia]$ git status
# On branch MajorUpgrade
# Your branch is behind 'origin/MajorUpgrade' by 4 commits, and can be
fast-forwarded.
#
Hi Peff,
On 2015-01-23 19:55, Jeff King wrote:
> On Fri, Jan 23, 2015 at 07:46:36PM +0100, Johannes Schindelin wrote:
>
>> > ? And then you can spell that first part as assert(), which I suspect
>> > (but did not test) may shut up clang's warnings.
>>
>> To be quite honest, I assumed that Git's s
On Fri, Jan 23, 2015 at 07:46:36PM +0100, Johannes Schindelin wrote:
> > ? And then you can spell that first part as assert(), which I suspect
> > (but did not test) may shut up clang's warnings.
>
> To be quite honest, I assumed that Git's source code was
> assert()-free. But I was wrong! So I'l
Jeff King writes:
> But of all the options outlined, I think I'd much rather just see an
> assert() for something that should never happen, rather than mixing it
> into the logic.
Surely.
> In that vein, one thing that puzzles me is that the current code looks
> like:
>
> if (options->msg_sev
Hi Peff,
On 2015-01-23 19:37, Jeff King wrote:
> On Fri, Jan 23, 2015 at 10:07:18AM -0800, Junio C Hamano wrote:
>
> [...] one thing that puzzles me is that the current code looks
> like:
>
> if (options->msg_severity && msg_id >= 0 && msg_id < FSCK_MSG_MAX)
> severity = options->msg_s
Mike Hommey writes:
> While -C implies -M, it is quite common to see both on example command lines
> here and there. The unintuitive thing is that if -M appears after -C, then
> copy detection is turned off because of how the command line arguments are
> handled.
This is deliberate, see below.
On Fri, Jan 23, 2015 at 10:07:18AM -0800, Junio C Hamano wrote:
> >> diff --git a/fsck.c b/fsck.c
> >> index 15cb8bd..8f8c82f 100644
> >> --- a/fsck.c
> >> +++ b/fsck.c
> >> @@ -107,7 +107,7 @@ static int fsck_msg_severity(enum fsck_msg_id msg_id,
> >> {
> >>int severity;
> >>
> >> - if (o
On Fri, Jan 23, 2015 at 4:09 AM, Alexander Kuleshov
wrote:
> I made separate patch for every file. Please, let me know if need to
> squash it into one commit.
>
>
> 2015-01-23 17:06 GMT+06:00 Alexander Kuleshov :
>> This patch set contatins minor style fixes. CodingGuidelines contains
>> rule that
Jeff King writes:
>> diff --git a/fsck.c b/fsck.c
>> index 15cb8bd..8f8c82f 100644
>> --- a/fsck.c
>> +++ b/fsck.c
>> @@ -107,7 +107,7 @@ static int fsck_msg_severity(enum fsck_msg_id msg_id,
>> {
>> int severity;
>>
>> -if (options->msg_severity && msg_id >= 0 && msg_id < FSCK_MSG_MA
On Fri, Jan 23, 2015 at 03:21:07PM +0100, Per Cederqvist wrote:
> Some projects keep a ChangeLog which every commit modifies. This
> makes the graph a very uninteresting single line of commits. It is
> sometimes useful to see how the graph would look if we ignore the
> ChangeLog file.
>
> The ne
Neat.
Signed-off-by: Josef 'Jeff' Sipek
On Fri, Jan 23, 2015 at 03:21:06PM +0100, Per Cederqvist wrote:
> git diff-tree by default emits TAB-separated fields. cut by defaults
> processes TAB-separated fields. Simplify getfiles() by using TAB as
> the separator.
>
> Signed-off-by: Per Cederqvi
On Fri, Jan 23, 2015 at 03:33:03PM +0100, Per Cederqvist wrote:
> On Fri, Jan 23, 2015 at 3:21 PM, Jeff Sipek wrote:
> > On Fri, Jan 23, 2015 at 02:24:55PM +0100, Per Cederqvist wrote:
> >> The old rule worked, most of the time, but had several issues:
> >>
> >> - It depended on the corresponding
On Fri, Jan 23, 2015 at 3:21 PM, Jeff Sipek wrote:
> On Fri, Jan 23, 2015 at 02:24:55PM +0100, Per Cederqvist wrote:
>> The old rule worked, most of the time, but had several issues:
>>
>> - It depended on the corresponding guilt-*.txt file, but the usage.sh
>>script actually reads ../guilt-f
Signed-off-by: Josef 'Jeff' Sipek
On Fri, Jan 23, 2015 at 02:24:59PM +0100, Per Cederqvist wrote:
> Make them into reference to the man pages instead.
>
> Signed-off-by: Per Cederqvist
> ---
> Documentation/guilt-add.txt | 2 +-
> Documentation/guilt-refresh.txt | 2 +-
> Documentation/gui
Ah, I see you changed usage.sh here. I guess that kinda invalidates my
comment for patch 1/5.
On Fri, Jan 23, 2015 at 02:24:58PM +0100, Per Cederqvist wrote:
> Signed-off-by: Per Cederqvist
> ---
> Documentation/usage.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/
On Fri, Jan 23, 2015 at 02:24:57PM +0100, Per Cederqvist wrote:
> Note: there is one place where I replace guilt-repair with "guilt
> repair" instead of "+guilt repair+". At least the version of docbook
> I'm using mishandles the "+" signs in that particular spot (even
> though it works properly f
Signed-off-by: Josef 'Jeff' Sipek
On Fri, Jan 23, 2015 at 02:24:56PM +0100, Per Cederqvist wrote:
> Specify an explicit dependency, to stop make from trying to generate
> guilt.xml if cmds.txt could not be created. The asciidoc will fail
> and produce an error message that might hide the origina
git diff-tree by default emits TAB-separated fields. cut by defaults
processes TAB-separated fields. Simplify getfiles() by using TAB as
the separator.
Signed-off-by: Per Cederqvist
---
guilt-graph | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/guilt-graph b/guilt-graph
in
Some projects keep a ChangeLog which every commit modifies. This
makes the graph a very uninteresting single line of commits. It is
sometimes useful to see how the graph would look if we ignore the
ChangeLog file.
The new -x option is useful in situations like this. It can be
repeated several t
If you use a ChangeLog, all output from "guilt graph" will be a boring
line of commits. By using "guilt graph -x ChangeLog" things will look
more interesting.
Also: simplify getfiles.
(This work is also available on the guilt-graph-ignore-2015-v1 branch
of the git://repo.or.cz/guilt/ceder.git re
On Fri, Jan 23, 2015 at 02:24:55PM +0100, Per Cederqvist wrote:
> The old rule worked, most of the time, but had several issues:
>
> - It depended on the corresponding guilt-*.txt file, but the usage.sh
>script actually reads ../guilt-foo.
>
> - Actually, each usage-%.txt depended on all gu
On Fri, Jan 23, 2015 at 01:38:17PM +0100, Johannes Schindelin wrote:
> > Unless we are willing to drop the ">= 0" check completely. I think it is
> > valid to do so regardless of the compiler's representation decision due
> > to the numbering rules I mentioned above. It kind-of serves as a
> > cro
Make them into reference to the man pages instead.
Signed-off-by: Per Cederqvist
---
Documentation/guilt-add.txt | 2 +-
Documentation/guilt-refresh.txt | 2 +-
Documentation/guilt-rm.txt | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/guilt-add.txt
Signed-off-by: Per Cederqvist
---
Documentation/usage.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/usage.sh b/Documentation/usage.sh
index 629f546..9cc49f7
--- a/Documentation/usage.sh
+++ b/Documentation/usage.sh
@@ -2,4 +2,4 @@
name=$(basename $1)
u=$
Note: there is one place where I replace guilt-repair with "guilt
repair" instead of "+guilt repair+". At least the version of docbook
I'm using mishandles the "+" signs in that particular spot (even
though it works properly for "+guilt select+" in another file. I know
too little docbook to be ab
Specify an explicit dependency, to stop make from trying to generate
guilt.xml if cmds.txt could not be created. The asciidoc will fail
and produce an error message that might hide the original error
message.
The added dependency causes make to not remove the guilt.xml file.
Add *.xml to .gitigno
The old rule worked, most of the time, but had several issues:
- It depended on the corresponding guilt-*.txt file, but the usage.sh
script actually reads ../guilt-foo.
- Actually, each usage-%.txt depended on all guilt-*.txt files, so
make had to do more work than necessary if a single f
guilt no longer supports running commands on the "guilt-add" form.
You need to use "guilt add" instead.
This patch series updates most of the documentation to use the
supported "guilt add" form.
There is one known instance where I did not change the style: in the
NAME section in Documentation/gui
I am using git 2.2.2 and want to report an issue with git push --repo option.
git 2.2.2 manual says that git push --repo=public will push to public
only if the current branch does not track a remote branch. See
http://git-scm.com/docs/git-push
However, I see that git pushes even when the current
Hi,
I am a bit surprised that this bug still exists in "maint" / v2.2.2.
Cherry-picking/merging 0ddedd4 fixes it.
Regards,
Daniel.
On 26.12.2014 02:12, Daniel Hahler wrote:
> Hi David,
>
> sorry for the confusion - the patch / fix I've mentioned was meant to be
> applied on the commit that ca
Hi Peff,
On 2015-01-23 13:23, Jeff King wrote:
> On Fri, Jan 23, 2015 at 12:48:29PM +0100, Johannes Schindelin wrote:
>
>> Pointed out by Michael Blume. Jeff King provided the pointer to a commit
>> fixing the same issue elsewhere in the Git source code.
>
> It may be useful to reference
On Fri, Jan 23, 2015 at 12:48:29PM +0100, Johannes Schindelin wrote:
> This is what I have currently in the way of attempting to "fix" it (I
> still believe that Clang is wrong to make this a warning, and causes
> more trouble than it solves):
I agree. It is something we as the programmers cannot
On 2015-01-23 12.08, Alexander Kuleshov wrote:
..
Asterisk must be next with variable
..
But this is a function:
> -static char* make_fast_import_path(const char *path)
> +static char *make_fast_import_path(const char *path)
(Sorry when I need to read this:)
- Fixing style violations while worki
I made separate patch for every file. Please, let me know if need to
squash it into one commit.
2015-01-23 17:06 GMT+06:00 Alexander Kuleshov :
> This patch set contatins minor style fixes. CodingGuidelines contains
> rule that the star must side with variable name.
>
> Alexander Kuleshov (7):
>
Hi Peff,
On 2015-01-22 23:01, Jeff King wrote:
> On Thu, Jan 22, 2015 at 10:20:01PM +0100, Johannes Schindelin wrote:
>
>> On 2015-01-22 20:59, Stefan Beller wrote:
>> > cc Johannes Schindelin who is working in
>> > the fsck at the moment
>> >
>> > On Thu, Jan 22, 2015 at 11:43 AM, Michael Blume
Asterisk must be next with variable
Signed-off-by: Alexander Kuleshov
---
fast-import.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fast-import.c b/fast-import.c
index 1b50923..fec67ca 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -3110,7 +3110,7 @@ static void parse_
Asterisk must be next with variable
Signed-off-by: Alexander Kuleshov
---
quote.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/quote.c b/quote.c
index 7920e18..02e9a3c 100644
--- a/quote.c
+++ b/quote.c
@@ -42,7 +42,7 @@ void sq_quote_buf(struct strbuf *dst, const char *sr
Asterisk must be next with variable
Signed-off-by: Alexander Kuleshov
---
test-hashmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/test-hashmap.c b/test-hashmap.c
index cc2891d..5f67120 100644
--- a/test-hashmap.c
+++ b/test-hashmap.c
@@ -14,13 +14,13 @@ static cons
Asterisk must be next with variable
Signed-off-by: Alexander Kuleshov
---
http-backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/http-backend.c b/http-backend.c
index b6c0484..7b5670b 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -515,7 +515,7 @@ static NORETURN
Asterisk must be next with variable
Signed-off-by: Alexander Kuleshov
---
builtin/clone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index d262a4d..a1ca780 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -741,7 +741,7 @@ static voi
Asterisk must be next with variable
Signed-off-by: Alexander Kuleshov
---
refs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.h b/refs.h
index 425ecf7..bd8afe2 100644
--- a/refs.h
+++ b/refs.h
@@ -86,7 +86,7 @@ extern int for_each_branch_ref(each_ref_fn, void *);
ext
This patch set contatins minor style fixes. CodingGuidelines contains
rule that the star must side with variable name.
Alexander Kuleshov (7):
show-branch: minor style fix
clone: minor style fix
test-hashmap: minor style fix
http-backend: minor style fix
refs: minor style fix
quote: mi
Asterisk must be next with variable
Signed-off-by: Alexander Kuleshov
---
builtin/show-branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/show-branch.c b/builtin/show-branch.c
index 3a7ec55..e7684c8 100644
--- a/builtin/show-branch.c
+++ b/builtin/show-branch.c
On Fri, Jan 23, 2015 at 10:29:08AM +0900, Mike Hommey wrote:
> While fooling around with copy/rename detection, I noticed that it
> doesn't detect the case where you copy or rename a file on top of
> another:
>
> $ git init
> $ (echo foo; echo bar) > foo
If I replace this with a longer input, li
This fixes a small error in the command that git-p4 suggests when
the user gives the --prepare-p4-only option.
It tells the user to use "p4 submit -i filename" but the p4 submit
command reads a change specification on standard input. The correct
command line is therefore:
p4 submit -i http://v
If you use git-p4 with the "--prepare-p4-only" option, then
it prints the p4 command line to use. However, the command
line was incorrect: the changelist specification must be
supplied on standard input, not as an argument to p4.
Signed-off-by: Luke Diamand
---
git-p4.py | 2 +-
1 file changed,
88 matches
Mail list logo
