Hi Eric,
Eric Sunshine writes:
On Wed, Aug 6, 2014 at 7:59 PM, Fabian Ruch baf...@gmail.com 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
Hi Thomas,
Thomas Rast writes:
Fabian Ruch baf...@gmail.com 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
@@ -938,7
Hi Thomas,
Thomas Rast writes:
Fabian Ruch baf...@gmail.com 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
- 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 not state
On 10/08/14 18:29, Junio C Hamano wrote:
Ramsay Jones ram...@ramsay1.demon.co.uk 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
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 same.
On Fri, Aug 8, 2014 at 11:17 AM, David Turner dtur...@twopensource.com 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=
Fixed. Thanks!
On Fri, Aug 8, 2014 at 10:27 AM, David Turner dtur...@twopensource.com 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
Alexander Shopov a...@kambanaria.org 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
Fabian Ruch baf...@gmail.com writes:
Hi Thomas,
Thomas Rast writes:
Fabian Ruch baf...@gmail.com 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 baf...@gmail.com writes:
Hi Thomas,
Thomas Rast writes:
Fabian Ruch baf...@gmail.com 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
Chris Packham judge.pack...@gmail.com 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)
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/mv.c | 47 +--
1 file changed, 21 insertions(+), 26 deletions(-)
diff --git a/builtin/mv.c b/builtin/mv.c
index dcfcb11..988945c
Le 11 août 2014 07:50, Christian Couder christian.cou...@gmail.com 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
Stefan Beller stefanbel...@gmail.com 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
On 11.08.2014 21:09, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com 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
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
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
--
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 Huhs. 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 find in a
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 sorga...@gmail.com
---
Hi Thomas,
an updated patch is attached below.
Thomas Rast writes: Fabian Ruch baf...@gmail.com 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,
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 stefanbel...@gmail.com
---
builtin/mailsplit.c |
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
On Tue, Aug 12, 2014 at 6:44 AM, Junio C Hamano gits...@pobox.com wrote:
Chris Packham judge.pack...@gmail.com 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
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
On Mon, Aug 11, 2014 at 4:29 PM, Chris Packham judge.pack...@gmail.com 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
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
29 matches
Mail list logo
