Hi Eric,
Eric Sunshine writes:
> On Wed, Aug 6, 2014 at 7:59 PM, Fabian Ruch wrote:
>> The to-do list commands `squash` and `fixup` apply the changes
>> introduced by the named commit to the tree but instead of creating
>> a new commit on top of the current head it replaces the previous
>> commit
Hi Thomas,
Thomas Rast writes:
> Fabian Ruch writes:
>> @@ -923,6 +923,8 @@ EOF
>> ;;
>> esac
>>
>> +mkdir -p "$state_dir" || die "Could not create temporary $state_dir"
>> +
>> git var GIT_COMMITTER_IDENT >/dev/null ||
>> die "You need to set your committer info first"
>>
>> @@ -
Hi Thomas,
Thomas Rast writes:
> Fabian Ruch writes:
>> Subject: Re: [PATCH v2 08/23] rebase -i: reword executes pre-commit hook on
>> interim commit
>
> I think the change makes sense, but can you reword the subjects that it
> describes the state after the commit (i.e. what you are doing), ins
>> - printf_ln(_("Huh (%s)?"), (*ptr)->buf);
>> + printf_ln(_("Wrong choice (%s). Choose again."),
>> (*ptr)->buf);
> Why is this an improvement?
Because 'Huh?' without intonation, gesture or a frown provided by a
human being is hard to understand. It does n
On 10/08/14 18:29, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> On 08/08/14 15:07, Tanay Abhra wrote:
>> ...
>>> (cc to Ramsay)
>>>
>>> The discussion in both threads (v8 and v9), boils down to this,
>>> is the `key_value_info` struct really required to be declared public or
>>> should be
>
Hi,
I have created one repository (but I'm not a root user on the server) like
$ git init --bare
And I do push my changes locally to remote repo where I created.
My friend also working the same repo, and he needs to push the changes
on the same.
I tried by adding below line on the remote config
On 11.08.2014 13:41, Jagan Teki wrote:
> Hi,
>
> I have created one repository (but I'm not a root user on the server) like
> $ git init --bare
>
> And I do push my changes locally to remote repo where I created.
> My friend also working the same repo, and he needs to push the changes
> on the sa
On Fri, Aug 8, 2014 at 11:17 AM, David Turner wrote:
> On Fri, 2014-08-08 at 09:45 -0700, Ronnie Sahlberg wrote:
>
>> +struct ref_be refs_files = {
>> + .transaction_begin = files_transaction_begin,
>> + .transaction_update_sha1= files_transaction_update_sha1,
>> +
Fixed. Thanks!
On Fri, Aug 8, 2014 at 10:27 AM, David Turner wrote:
> On Fri, 2014-08-08 at 09:44 -0700, Ronnie Sahlberg wrote:
>> + * Check is a particular refname is available for creation. skip
>> contains
>
> s/Check is/Check that/'
>
>> + * a list of refnames to exclude from the refname col
Alexander Shopov writes:
>>> - printf_ln(_("Huh (%s)?"), (*ptr)->buf);
>>> + printf_ln(_("Wrong choice (%s). Choose again."),
>>> (*ptr)->buf);
>> Why is this an improvement?
> Because 'Huh?' without intonation, gesture or a frown provided by a
> human bei
Fabian Ruch writes:
> Hi Thomas,
>
> Thomas Rast writes:
>> Fabian Ruch writes:
>>> @@ -923,6 +923,8 @@ EOF
>>> ;;
>>> esac
>>>
>>> +mkdir -p "$state_dir" || die "Could not create temporary $state_dir"
>>> +
>>> git var GIT_COMMITTER_IDENT >/dev/null ||
>>> die "You need to set your
Fabian Ruch writes:
> Hi Thomas,
>
> Thomas Rast writes:
>> Fabian Ruch writes:
>>> Subject: Re: [PATCH v2 08/23] rebase -i: reword executes pre-commit
>>> hook on interim commit
>>
>> I think the change makes sense, but can you reword the subjects that it
>> describes the state after the commi
Chris Packham writes:
> Is there any way where we could share the conflict resolution around
> but still end up with a single merge commit.
One idea that immediately comes to me is to use something like
"rerere" (not its implementation and storage, but the underlying
idea) enhanced with the tric
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/mv.c | 47 +--
> 1 file changed, 21 insertions(+), 26 deletions(-)
>
> diff --git a/builtin/mv.c b/builtin/mv.c
> index dcfcb11..988945c 100644
> --- a/builtin/mv.c
>
Le 11 août 2014 07:50, "Christian Couder" a écrit :
>
> This should be possible using "git imerge" which is separate tool.
Sorry I sent the above using the gmail app on my mobile phone and
unfortunately I can't make it send plain text emails.
(Emails which are not plain text are rejected by vger.
Stefan Beller writes:
> Even the documentation tells us:
> You should check if it
> returns any error (non-zero return code) and if it does not, you can
> start using get_revision() to do the iteration.
>
> In preparation for this commit, I grepped all occurrences of
> prepare_r
On 11.08.2014 21:09, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Even the documentation tells us:
>> You should check if it
>> returns any error (non-zero return code) and if it does not, you can
>> start using get_revision() to do the iteration.
>>
>> In preparation for thi
IIUC, this might help,
http://www.mail-archive.com/git@vger.kernel.org/msg56418.html
http://www.mail-archive.com/git@vger.kernel.org/msg56468.html
--
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://
In line 1763 of unpack-tree.c we have a condition on the current tree
if (current) {
...
Within this block of code we can assume current to be non NULL, hence
the code after the statement in line 1796:
if (current)
return ...
cannot be reached.
The
Hello,
$ git pull --rebase=false
Already up-to-date.
$ git pull --rebase=true
Current branch v3.5 is up to date.
$ git pull --rebase=preserve
Successfully rebased and updated refs/heads/v3.5.
The last one being particularly misleading as nothing was actually
changed.
git version 1.9.3
-- Sergey
> If there were something else "Huh?" could mean after you
> give a response to that prompt, but I do not think there is.
OK, you love your "Huh"s. Good for you. I cannot find a convincing
argument then.
> If I were asked to say what it is then, I would say "it reassures".
It is like a jewel you f
Previous description of -f option was wrong as "git rebase" does not
require -f to perform rebase when "current branch is a descendant of
the commit you are rebasing onto", provided commit(s) to be rebased
contain merge(s).
Signed-off-by: Sergey Organov
---
Documentation/git-rebase.txt | 7 +++--
Hi Thomas,
an updated patch is attached below.
Thomas Rast writes:> Fabian Ruch writes:
> [...]
>> are not supported at the moment. Neither are options that contain
>> spaces because the shell expansion of `args` in `do_next` interprets
>> white space characters as argument separator, that is a
This was found by coverity. (Id: 290001)
the variable 'output' is only assigned to a value inequal to NUL,
after all gotos to the corrupt label.
Therefore we can conclude the two removed lines are actually dead code.
Signed-off-by: Stefan Beller
---
builtin/mailsplit.c | 2 --
1 file changed, 2
Greetings,
I have been working happily with git for a couple of years, and ran
into a mysterious issue today: after running a git-pull during which I
saw the message "Auto packing the repository for optimum performance".
I now receive the error "Fatal: not a git repository" when running any
git co
On Tue, Aug 12, 2014 at 6:44 AM, Junio C Hamano wrote:
> Chris Packham writes:
>
>> Is there any way where we could share the conflict resolution around
>> but still end up with a single merge commit.
>
> One idea that immediately comes to me is to use something like
> "rerere" (not its implement
I'm seeing some oddity in one of my repositories where the root commit is being
output in 'rev-list' even when I pass in a reference that should exclude it
from being output.
I've attempted to reproduce the issue in a test environment but so far have
failed at that.
Problem details below as be
On Mon, Aug 11, 2014 at 4:29 PM, Chris Packham wrote:
>> So, the "recording" phase may go something like this:
>> ...
>> git checkout merge-fix/$this-$that
>> git read-tree -m -u HEAD $this
>> git commit -a -m 'merge-fix/$this-$that postimage'
>>
>> The rough idea is "git show merge-f
Reachability bitmaps do not work with shallow operations,
because they cache a view of the object reachability that
represents the true objects. Whereas a shallow repository
(or a shallow operation in a repository) is inherently
cutting off the object graph with a graft.
We explicitly disallow the
29 matches
Mail list logo