Junio C Hamano wrote:
> This patch is about for-each-ref and your series does not seem to
> aim to unify it in any way with pretty-formats, so I would have
> expected an enhancement in line with the former, not the latter.
While I might never attempt a unification again, there's no harm in
getting
On 02/11/2013 09:23, Jiang Xin wrote:
> 2013/11/2 Trần Ngọc Quân :
>> Strings in builtin/remote.c line 15 and 42 is similar, please change to
>> same string in order to reduce gettext database (.mo file)
>> --
>> Trần Ngọc Quân.
> Confirmed, there is a typo in builtin/remote.c line 15. Have you se
On Sat, Nov 02, 2013 at 03:11:55AM +0200, Gerasimos Dimitriadis wrote:
> Hi,
>
> I have a question on the order with which commits are applied on a merge.
>
> I am merging two branches that have changes on the same text file and
> I'd like to ask you about the merge result.
>
> The following out
Hi,
I have a question on the order with which commits are applied on a merge.
I am merging two branches that have changes on the same text file and
I'd like to ask you about the merge result.
The following output is provided on the two branches to be merged, by
the command:
git show-branch --dat
"git-rev-parse --is-inside-git-dir" outputs "fatal: Not a git
repository (or any of the parent directories): .git", instead of
"false" when outside of a git directory. "--is-inside-work-tree"
behaves the same way. Both commands work correctly (i.e. output
"true") when inside a git directory, or in
On 01/11/13 22:52, Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.
>
[ ... ]
>
>
> * fc/transport-helper-fixes (2013-11-01) 11 commits
> - transport-helper: demot
Junio C Hamano writes:
> * tr/merge-recursive-index-only (2013-10-28) 3 commits
> - merge-recursive: -Xindex-only to leave worktree unchanged
> - merge-recursive: internal flag to avoid touching the worktree
> - merge-recursive: remove dead conditional in update_stages()
FWIW -- since you dro
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
An early preview 1.8.5-rc0 has been tagged. There still are handful
of fixes and enhancements left in 'next' that I'd like to see in the
final,
Just to update the style of this ancient test script to match
our house style.
Signed-off-by: Junio C Hamano
---
t/lib-read-tree.sh | 52 +--
t/t1005-read-tree-reset.sh | 126 ++---
2 files changed, 89 insertions(+), 89 deletions(-
Jeff King writes:
> On Thu, Oct 31, 2013 at 01:15:39PM -0400, Jeff King wrote:
>
>> On Thu, Oct 31, 2013 at 10:11:49AM -0700, Junio C Hamano wrote:
>>
>> > - Try to discard
>> >
>> >$ git am --abort
>> >error: cache entry has null sha1: remote-curl.c
>> >fatal: unable to write new
From: Jeff King
When we call "read-tree --reset -u HEAD ORIG_HEAD", the first thing we
do with the index is to call read_cache_unmerged. Originally that
would read the index, leaving aside any unmerged entries. However, as
of d1a43f2 (reset --hard/read-tree --reset -u: remove unmerged new
paths
With a conflicted index, this used to give us an error.
Signed-off-by: Junio C Hamano
---
t/t1005-read-tree-reset.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/t/t1005-read-tree-reset.sh b/t/t1005-read-tree-reset.sh
index e29cf63..0745685 100755
--- a/t/t1005-read-tree-
Am 01.11.2013 20:34, schrieb Junio C Hamano:
> In $gmane/234730, J6t pointed out that "rev-list --exclude" needs a
> matching updates to the globbing option "rev-parse" supports.
>
> Here is a follow-up to do just that. They are meant to be applied on
> top of the two patch series that has been co
Eric Sunshine writes:
> On Fri, Nov 1, 2013 at 3:34 PM, Junio C Hamano wrote:
>> Teach "rev-parse" the same "I'm going to glob, but omit the ones
>> that match these patterns" feature as "rev-list".
>>
>> Signed-off-by: Junio C Hamano
>> ---
>> Documentation/git-rev-parse.txt | 14
On Fri, Nov 1, 2013 at 3:34 PM, Junio C Hamano wrote:
> Teach "rev-parse" the same "I'm going to glob, but omit the ones
> that match these patterns" feature as "rev-list".
>
> Signed-off-by: Junio C Hamano
> ---
> Documentation/git-rev-parse.txt | 14 ++
> builtin/rev-parse.c
In $gmane/234730, J6t pointed out that "rev-list --exclude" needs a
matching updates to the globbing option "rev-parse" supports.
Here is a follow-up to do just that. They are meant to be applied on
top of the two patch series that has been cooking in 'pu'.
- $gmane/233484: e7b432c5 (revision: i
... while updating their function signature. To be squashed into
the initial patch to rev-list.
Signed-off-by: Junio C Hamano
---
revision.c | 46 +++---
revision.h | 5 +
2 files changed, 28 insertions(+), 23 deletions(-)
diff --git a/revision.c b/
Teach "rev-parse" the same "I'm going to glob, but omit the ones
that match these patterns" feature as "rev-list".
Signed-off-by: Junio C Hamano
---
Documentation/git-rev-parse.txt | 14 ++
builtin/rev-parse.c | 17 +
t/t6018-rev-list-glob.sh| 12 +
Add tests for the --exclude= feature.
A few tests are added for cases where use of globbing and
"--exclude" results in no positive revisions:
* "--exclude=" before "--all" etc. resulted in no results;
* "--stdin" is used but no input was given;
* "--all" etc. is used but no matching refs are
On Fri, Nov 1, 2013 at 12:35 PM, Junio C Hamano wrote:
> Subject: [PATCH] transport-helper: demote lack of "force" option to a warning
>
> It would have been a good conservative position to take, if there
> were no existing helpers, to die when the user asked to force a push
> through a transport
This patch needed on top of 3/3 for me to pass gcc cleanly.
-- >8 --
Subject: [PATCH] fixup! for-each-ref: introduce %(upstream:track[short])
The condition !prefixcmp(name, "upstream") must be true for the
variable "branch" to be reused, so the variable should be always set
when it gets used, but
Felipe Contreras writes:
> On Fri, Nov 1, 2013 at 8:49 AM, Junio C Hamano wrote:
>
>> Because updated helpers know 'force' option, such a s/die/warning/
>> change would not affect them at all.
>
> Yeah, that makes sense.
OK, then let's queue this separately on top, so that we can revert
it more
This patch makes it clear that "pack-file" is not to be spelled as is in
the unpack-objects usage.
Signed-off-by: Vivien Didelot
---
Documentation/git-unpack-objects.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-unpack-objects.txt
b/Documentation/git-
On Fri, Nov 1, 2013 at 8:49 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Felipe Contreras writes:
>>
>>> On Thu, Oct 31, 2013 at 12:21 PM, Junio C Hamano wrote:
Felipe Contreras writes:
> Otherwise they cannot know when to force the push or not (other than
> hacks)
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Ramkumar Ramachandra writes:
>>
>>> Enhance 'git for-each-ref' with color formatting options. You can now
>>> use the following format in for-each-ref:
>>>
>>> %C(green)%(refname:short)%C(reset)
>>
>> So far, every magic for-each-ref tak
Junio C Hamano writes:
> Felipe Contreras writes:
>
>> On Thu, Oct 31, 2013 at 12:21 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
Otherwise they cannot know when to force the push or not (other than
hacks).
...
diff --git a/transport-helper.c b/transport-helpe
Hi,
I've just made a mistake in a longer git-rebase interactive session. But I've
already entered git-rebase --continue and now I'm at the next conflict
resolution step. I'd need to go back to the last resolved conflict and correct
my mistake.
It would be nice, if git-rebase would allow me to
Hi,
git reintegrate is a helper tool to manage integration branches, it
has all the options of other known tools.
This is a rewrite of John Keeping's git-integration in Ruby, it has
essentially the same features and passes all the git-integration
tests, but it has other features.
One feature tha
On Fri, Nov 1, 2013 at 5:05 AM, SZEDER Gábor wrote:
> On Thu, Oct 31, 2013 at 09:50:51PM -0600, Felipe Contreras wrote:
>> On Thu, Oct 31, 2013 at 8:48 PM, David Aguilar wrote:
>> > On Thu, Oct 31, 2013 at 07:56:03PM -0600, Felipe Contreras wrote:
>>
>> >> Nobody is forcing you to read them.
>> >
On Thu, Oct 31, 2013 at 09:50:51PM -0600, Felipe Contreras wrote:
> On Thu, Oct 31, 2013 at 8:48 PM, David Aguilar wrote:
> > On Thu, Oct 31, 2013 at 07:56:03PM -0600, Felipe Contreras wrote:
>
> >> Nobody is forcing you to read them.
> >
> > You're missing the *key* point.
> > No one wants to in
On Thu, Oct 31, 2013 at 5:17 AM, Junio C Hamano wrote:
> * Magic pathspecs like ":(icase)makefile" that matches both
>Makefile and makefile can be used in more places.
":(glob)foo/**/bar" is another nice thing that could be announced.
--
Duy
--
To unsubscribe from this list: send the line "
Hey,
I'm using a gitosis server. Suddenly I'm not able to push to the
remote server. Everyone else is able to push to the same server. Btw I
can't push to *any repo* on the server. This is the error I get:
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 10
On Wed, Oct 30, 2013 at 03:17:45PM -0700, Junio C Hamano wrote:
> Git v1.8.5 Release Notes (draft)
>
> [...]
> * A packfile that stores the same object more than once is broken and
>will be rejected by "git index-pack" that is run when receiving
>data over the wir
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> Enhance 'git for-each-ref' with color formatting options. You can now
>> use the following format in for-each-ref:
>>
>> %C(green)%(refname:short)%C(reset)
>
> So far, every magic for-each-ref takes were of form %(...); was
> there a rea
34 matches
Mail list logo
