On Sat, Jul 4, 2015 at 3:54 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Fri, Jul 3, 2015 at 10:53 PM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
COMMANDS
+add path branch::
+
+Check out `branch` into
On Fri, Jul 03, 2015 at 10:52:32AM -0700, Junio C Hamano wrote:
Cc: Andrew Wong andrew.k...@gmail.com
Signed-off-by: Clemens Buchacher clemens.buchac...@intel.com
Reviewed-by: Jorge Nunes jorge.nu...@intel.com
Where was this review made? I may have missed a recent discussion,
and that
Hi,
This message is the title of a listing of git commands, that are
available from $PATH but not located in git's exec path.
Vorhandene Git-Kommandos in '/usr/libexec/git-core'
add merge-octopus
...
Vorhandene Git-Kommandos irgendwo in Ihrem $PATH
imerge
...
What
Noticed-by: Plamen Totev plamen.to...@abv.bg
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
grep.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/grep.c b/grep.c
index b58c7c6..48db15a 100644
--- a/grep.c
+++ b/grep.c
@@ -378,7 +378,7 @@ static void
Hello,
It looks like the git grep command does not support multi-byte character sets
like UTF-8. As a result some of the grep functionality is not working. For
example if you search for non Latin words the ignore case flag does not have
effect(the search is case sensitive). I suspect there
On Mon, Jul 6, 2015 at 6:28 PM, Plamen Totev plamen.to...@abv.bg wrote:
Hello,
It looks like the git grep command does not support multi-byte character sets
like UTF-8. As a result some of the grep functionality is not working. For
example if you search for non Latin words the ignore case
Am 06.07.2015 um 14:42 schrieb Nguyễn Thái Ngọc Duy:
Noticed-by: Plamen Totev plamen.to...@abv.bg
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
grep.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/grep.c b/grep.c
index b58c7c6..48db15a 100644
From: Guillaume Pagès guillaume.pa...@ensimag.grenoble-inp.fr
git status gives more information during rebase -i, about the list of
command that are done during the rebase. It displays the two last
commands executed and the two next lines to be executed. It also gives
hints to find the whole
From: Guillaume Pagès guillaume.pa...@ensimag.grenoble-inp.fr
Signed-off-by: Guillaume Pagès guillaume.pa...@ensimag.grenoble-inp.fr
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
t/t7512-status-help.sh | 28 ++--
From: Guillaume Pagès guillaume.pa...@ensimag.grenoble-inp.fr
Signed-off-by: Guillaume Pagès guillaume.pa...@ensimag.grenoble-inp.fr
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
wt-status.c | 32
1 file
This is almost identical to v5. I turned git_path(var) into
git_path(%s, var) as Junio noticed, but I still prefer my version on
the other points discussed.
Guillaume Pagès (4):
status: factor two rebase-related messages together
status: differentiate interactive from non-interactive rebases
joey@darkstar:~/tmpgit init --shared=world testrepo
Initialized empty shared Git repository in /home/joey/tmp/testrepo/.git/
joey@darkstar:~/tmpgrep shared testrepo/.git/config
sharedrepository = 2
This magic value of 2 seems to be undocumented, as is the magic value of 1
that's
From: Guillaume Pagès guillaume.pa...@ensimag.grenoble-inp.fr
Expand test coverage with one or more than two commands done
and with zero, one or more than two commands remaining.
Signed-off-by: Guillaume Pagès guillaume.pa...@ensimag.grenoble-inp.fr
Signed-off-by: Junio C Hamano
On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz dborow...@google.com wrote:
The alternatives for someone writing a parser are:
a. Store the original pkt-line framing.
Or obviously, a2. Frame in some other way, e.g. JSON array of strings
(complete straw man, not seriously proposing this).
--
To
It was a bit sad since we use scripts to do the merge, then we can
check the conflict list in the log message, and assign to separate
owners to resolve them.
Would it be possible to make it as an config option?
On Tue, Jul 7, 2015 at 12:08 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Shawn Pearce spea...@spearce.org writes:
push cert format is like commit or tag format. You need those LFs. We
can't just go declare them optional because of the way pkt-line read
function is implemented in git-core.
As I said, I view each of the packets between push-cert and
push-cert-end
Shawn Pearce spea...@spearce.org writes:
push cert format is like commit or tag format. You need those LFs. We
can't just go declare them optional because of the way pkt-line read
function is implemented in git-core.
As I said, I view each of the packets between push-cert and
push-cert-end
Eric Sunshine sunsh...@sunshineco.com writes:
I'm not familiar with the criteria for deciding what merits mention
in the newsletter. Is the recent introduction of git-worktree and the
attendant relocation of add and prune functionality worthy? If
so, perhaps the following write-up would be
Clemens Buchacher clemens.buchac...@intel.com writes:
On Fri, Jul 03, 2015 at 10:52:32AM -0700, Junio C Hamano wrote:
Cc: Andrew Wong andrew.k...@gmail.com
Signed-off-by: Clemens Buchacher clemens.buchac...@intel.com
Reviewed-by: Jorge Nunes jorge.nu...@intel.com
Where was this review
git-worktree options affect some worktree commands but not others, but
this is not necessarily obvious from the option descriptions. Make this
clear by indicating explicitly which commands are affected by which
options.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Dave Borowitz dborow...@google.com writes:
Another way of looking at the problem with my assumptions is, I was
assuming pkt-line framing was the same thing as pkt-line header.
You seem to be saying the definition of pkt-line framing is header,
and optional trailing newline.
Yes. I thought
This was missed when git prune --worktrees became git worktree prune.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/git-checkout.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index
Relocate submodule warning to BUGS and enumerate missing commands.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/git-worktree.txt | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-worktree.txt
Due to the (current) absence of a git worktree lock command, locking
a worktree's administrative files to prevent automatic pruning is a
manual task, necessarily requiring low-level understanding of linked
worktree functionality. However, this level of detail does not belong
in the high-level
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/git-worktree.txt | 22 ++
1 file changed, 22 insertions(+)
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 0385e9a..6afff1e 100644
--- a/Documentation/git-worktree.txt
The DESCRIPTION section should provide a high-level overview of linked
worktree functionality to bring users up to speed quickly, without
overloading them with low-level details, so relocate the technical
information to a new DETAILS section.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
Eric Sunshine sunsh...@sunshineco.com writes:
How about this instead: prefixing with As originally implemented,
with a couple s/is/was/ thrown in...
As originally implemented, creation of linked-worktrees was
accomplished via `git checkout --to path branch`, and cleanup
of
Dave Borowitz dborow...@google.com writes:
That existing implementations of the receivers treat an empty packet
(i.e. 0004)
or 0005\n ;)
Is that true? I think
len = pkt_line();
if (!len)
break; /* flush */
would give you len == 1 and would not confuse it
On Mon, Jul 6, 2015 at 2:06 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
Another way of looking at the problem with my assumptions is,
Kevin Daudt m...@ikke.info writes:
rebase learned to stash changes when it encounters a dirty work tree, but
git pull --rebase does not.
Only verify if the working tree is dirty when rebase.autostash is not
enabled.
Signed-off-by: Kevin Daudt m...@ikke.info
Helped-by: Paul Tan
Dave Borowitz dborow...@google.com writes:
Unfortunately, optional LFs still make the stored certs for later
auditing and parsing a bit illegible. This is one way in which push
certs are fundamentally different from the rest of the wire protocol,
which is not intended to be persisted.
Hmm, I
On Mon, Jul 6, 2015 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
The server can munge pkt-lines and reinsert LFs, but it _must_ have
some way of reconstructing the payload that the client signed in order
to verify the signature. If we just
git-apply fails if '-p' option truncate at least one filename in patch to zero
size.
This solution tries to bring closer git-apply to standard Linux patch tool.
Standard patch tool skip the truncated filenames and successfully applies patch.
Evgen Druzhynin (1):
Added ability to scip patch
---
builtin/apply.c | 16 +---
po/bg.po| 15 ---
po/ca.po| 15 ---
po/de.po| 15 ---
po/fr.po| 15 ---
po/git.pot | 11 ---
po/it.po| 11 ---
po/pt_PT.po | 7 ---
On Mon, Jul 6, 2015 at 1:30 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
I think I understand the confusion now. I think you and I are working
from different assumptions about the client behavior.
I agree that we now both understand where we come
On Mon, Jul 6, 2015 at 1:11 PM, Dave Borowitz dborow...@google.com wrote:
On Mon, Jul 6, 2015 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
The server can munge pkt-lines and reinsert LFs, but it _must_ have
some way of reconstructing the
The plan is to relocate git checkout --to functionality to git
worktree add, however, worktree.c won't have access to the 'struct
checkout_opts' passed to prepare_linked_worktree(), which it consults
for the pathname of the new worktree and the argv[] of the command it
should run to populate the
A subsequent patch will also need to compute the basename of the new
worktree, so factor out this logic into a new function.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
builtin/worktree.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff
Now that git worktree add has achieved user-facing feature-parity with
git checkout --to, retire the latter.
Move the actual linked worktree creation functionality,
prepare_linked_checkout() and its helpers, verbatim from checkout.c to
worktree.c.
This effectively reverts changes to checkout.c
With the introduction of git worktree add, git checkout --to is
slated for removal. Therefore, retrofit linked worktree creation tests
to use git worktree add instead.
(The test to check exclusivity of checkout --to and checkout paths
is dropped altogether since it becomes meaningless with
The only references to 'new' were folded out by the last two patches.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
builtin/checkout.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 162c822..134b6d6 100644
---
prepare_linked_checkout() respects git-checkout's --quiet flag, however,
the plan is to relocate git checkout --to functionality to git
worktree add, and git-worktree does not (yet) have a --quiet flag.
Consequently, make prepare_linked_checkout() unconditionally verbose to
ease eventual code
In order to allow linked worktree creation via git checkout --to from
a bare repository, 3473ad0 (checkout: don't require a work tree when
checking out into a new one, 2014-11-30) dropped git-checkout's
unconditional NEED_WORK_TREE requirement and instead performed worktree
setup conditionally
[ Please, don't top-post on this list ]
Andrey Hsiao andreyhs...@gmail.com writes:
It was a bit sad since we use scripts to do the merge, then we can
check the conflict list in the log message, and assign to separate
owners to resolve them.
Would it be possible to make it as an config
On 06/29/2015 10:17 PM, David Turner wrote:
These are necessary because alternate ref backends might store reflogs
somewhere other than .git/logs. Code that now directly manipulates
.git/logs should instead go through git-reflog.
In a moment, we will use these functions to make git stash
One of git-worktree's roles is to populate the new worktree, much like
git-checkout, and thus, for convenience, ought to support several of the
same shortcuts. Toward this goal, add a --detach option to detach HEAD
in the new worktree.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
This is v3 of the series to replace git checkout --to with git
worktree add. It's built atop Duy's df0b6cf (worktree: new place for
git prune --worktrees, 2015-06-29). Thanks to Duy for his review
of v2[*1*].
A v2 to v3 interdiff is included below for ease of review.
Changes since v2:
* retire
As a convenience, when branch is omitted from git worktree path
branch and neither -b nor -B is used, automatically create a new
branch named after path, as if -b $(basename path) was specified.
Thus, git worktree add ../hotfix creates a new branch named hotfix
and associates it with new worktree
One of git-worktree's roles is to populate the new worktree, much like
git-checkout, and thus, for convenience, ought to support several of the
same shortcuts. Toward this goal, add -b/-B options to create a new
branch and check it out in the new worktree.
(For brevity, only -b is mentioned in
Now that the git-worktree command exists, its documentation page is the
natural place for the linked worktree description to reside. Relocate
the MULTIPLE WORKING TREES description verbatim from git-checkout.txt
to git-worktree.txt.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
The plan is to relocate git checkout --to functionality to git
worktree add, however, this check expects a 'struct branch_info' which
git-worktree won't have at hand. It will, however, have access to its
own command-line from which it can pick up the branch name. Therefore,
as a preparatory step,
As a safeguard, checking out a branch already checked out by a different
worktree is disallowed. This behavior can be overridden with
--ignore-other-worktrees, however, this option is neither obvious nor
particularly discoverable. As a common safeguard override, --force is
more likely to come to
Given git checkout --to path HEAD~1, the new worktree's HEAD should
begin life at the current branch's HEAD~1, however, it actually ends up
at HEAD~2. This happens because:
1. git-checkout resolves HEAD~1
2. to satisfy is_git_directory(), prepare_linked_worktree() creates
a HEAD
As a convenience, like git branch and git checkout -b, make
git worktree add -b newbranch path branch default to HEAD when
branch is omitted.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/git-worktree.txt | 1 +
builtin/worktree.c | 6 --
The plan is to relocate git checkout --to functionality to git
worktree add. As a first step, introduce a bare-bones git-worktree
add command along with documentation. At this stage, git worktree
add merely invokes git checkout --to behind the scenes, but an
upcoming patch will move the actual
By default, git worktree add refuses to create a new worktree when
the requested branch is already checked out elsewhere. Add a --force
option to override this safeguard.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/git-worktree.txt | 8 +++-
builtin/worktree.c
Dave Borowitz dborow...@google.com writes:
The server can munge pkt-lines and reinsert LFs, but it _must_ have
some way of reconstructing the payload that the client signed in order
to verify the signature. If we just naively insert LFs where missing,
we lose the ability to verify the
On Mon, Jul 6, 2015 at 12:38 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
I'm not familiar with the criteria for deciding what merits mention
in the newsletter. Is the recent introduction of git-worktree and the
attendant relocation of add and prune
On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
Another way of looking at the problem with my assumptions is, I was
assuming pkt-line framing was the same thing as pkt-line header.
You seem to be saying the definition of
Dave Borowitz dborow...@google.com writes:
On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
Another way of looking at the problem with my assumptions is, I was
assuming pkt-line framing was the same thing as pkt-line header.
On 06/29/2015 10:17 PM, David Turner wrote:
The safe_create_reflog function creates a reflog, if it does not
already exist.
The log_ref_setup function becomes private and gains a force_create
parameter to force the creation of a reflog even if log_all_ref_updates
is false or the refname is
On Mon, Jul 6, 2015 at 12:28 PM, Junio C Hamano gits...@pobox.com wrote:
Shawn Pearce spea...@spearce.org writes:
push cert format is like commit or tag format. You need those LFs. We
can't just go declare them optional because of the way pkt-line read
function is implemented in git-core.
Dave Borowitz dborow...@google.com writes:
I think I understand the confusion now. I think you and I are working
from different assumptions about the client behavior.
I agree that we now both understand where we come from ;-)
And sorry for not being clear when I did the push-cert originally
Thanks, both.
--
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
Paul Tan pyoka...@gmail.com writes:
+test_expect_success 'am with applypatch-msg hook' '
+ test_when_finished rm -f .git/hooks/applypatch-msg
+ rm -fr .git/rebase-apply
+ git reset --hard
+ git checkout first
+ mkdir -p .git/hooks
+ cat
Evgen Druzhynin evgen.druzhy...@gmail.com writes:
This space is for you to explain why it is a good idea to do this
change. What problem does it solve, how often does that problem
appear, what other workarounds exist if any and why they are not
satisfactory, etc, etc?
---
Above this line, we
Eric Sunshine sunsh...@sunshineco.com writes:
Now that git worktree add has achieved user-facing feature-parity with
git checkout --to, retire the latter.
Move the actual linked worktree creation functionality,
prepare_linked_checkout() and its helpers, verbatim from checkout.c to
Junio C Hamano gits...@pobox.com writes:
By clarifying that sender SHOULD terminate with LF, receiver MUST
NOT require it is the rule (and fixing the existing implementations
at places where they violate the MUST NOT part, which I think are
very small number of places), I think we can drop
Hi,
I've been looking at the refspecs for git fetch, and noticed that
globs are partially supported. I wanted to use something like:
refs/tags/some-prefix-*:refs/tags/some-prefix-*
as a refspec, so that I can fetch only tags which have a specific
prefix. I know that I could use namespaces to
On 16.06.2015 03:17, Eric Raible wrote:
So naturally I want to check each of them for correctness.
Sorry for joining this thread so late, I only come to know about it from the
draft of the upcoming Git Rev News 5 [1].
A while ago Robin Green was asking a very similar question on StackOverflow
Eric Sunshine sunsh...@sunshineco.com writes:
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 377ae0f..da71f50 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -9,7 +9,7 @@ git-worktree - Manage multiple worktrees
Eric Sunshine sunsh...@sunshineco.com writes:
As a safeguard, checking out a branch already checked out by a different
worktree is disallowed. This behavior can be overridden with
--ignore-other-worktrees, however, this option is neither obvious nor
particularly discoverable. As a common
On Tue, Jul 7, 2015 at 3:10 AM, René Scharfe l@web.de wrote:
Am 06.07.2015 um 14:42 schrieb Nguyễn Thái Ngọc Duy:
Noticed-by: Plamen Totev plamen.to...@abv.bg
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
grep.c | 14 +++---
1 file changed, 11 insertions(+), 3
Junio C Hamano gits...@pobox.com writes:
When c6458e60 (index-pack: kill union delta_base to save memory,
2015-04-18) attempted to reduce the memory footprint of index-pack,
one of the key thing it did was to keep track of ref-deltas and
ofs-deltas separately.
In fix_unresolved_deltas(),
On Mon, Jul 6, 2015 at 4:01 PM, Junio C Hamano gits...@pobox.com wrote:
Jacob Keller jacob.kel...@gmail.com writes:
What is the reason for not allowing slightly more arbitrary
expressions? Obviously no more than one *...
I cannot seem to be able to find related discussions around that
Mike Hommey m...@glandium.org writes:
One of the first things parse_from does is unconditionally throw away
the tree for the given branch, and then the from tree is loaded. So
when the from commit is the current head of the branch, that make
fast-import do more work than necessary.
If it is
Jacob Keller jacob.kel...@gmail.com writes:
I've been looking at the refspecs for git fetch, and noticed that
globs are partially supported. I wanted to use something like:
refs/tags/some-prefix-*:refs/tags/some-prefix-*
as a refspec, so that I can fetch only tags which have a specific
Hi,
I did something stupid with a script using fast-import, and that made
the whole process ~20% slower on Linux and 400~500% slower on Mac. The
reason this happened is that the script was essentially adding a from
to every commit command, even when the from commit is the current
head of the
On Mon, 6 Jul 2015, Junio C Hamano wrote:
Jacob Keller jacob.kel...@gmail.com writes:
I've been looking at the refspecs for git fetch, and noticed that
globs are partially supported. I wanted to use something like:
refs/tags/some-prefix-*:refs/tags/some-prefix-*
as a refspec, so
On Mon, Jul 06, 2015 at 12:19:14PM -0700, Junio C Hamano wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 377ae0f..da71f50 100644
--- a/Documentation/git-worktree.txt
+++
On Mon, Jul 6, 2015 at 7:20 PM, Daniel Barkalow
barka...@iabervon.iabervon.org wrote:
On Mon, 6 Jul 2015, Junio C Hamano wrote:
Jacob Keller jacob.kel...@gmail.com writes:
I've been looking at the refspecs for git fetch, and noticed that
globs are partially supported. I wanted to use
On Sun, Jul 5, 2015 at 5:30 AM, Junio C Hamano gits...@pobox.com wrote:
When c6458e60 (index-pack: kill union delta_base to save memory,
2015-04-18) attempted to reduce the memory footprint of index-pack,
one of the key thing it did was to keep track of ref-deltas and
ofs-deltas separately.
On Mon, Jul 06, 2015 at 01:39:47PM -0700, Junio C Hamano wrote:
Kevin Daudt m...@ikke.info writes:
rebase learned to stash changes when it encounters a dirty work tree, but
git pull --rebase does not.
Only verify if the working tree is dirty when rebase.autostash is not
enabled.
Translate 65 new messages came from git.pot update in
64f23b0 (l10n: git.pot: v2.5.0 round 1 (65 new, 15 removed)).
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
po/de.po | 192 ---
1 file changed, 98 insertions(+), 94
Today I learned that git push will silently try to recreate a remote
funny ref if you push to it.
Hypothetically ... lets say I have a reimplementation of Git called JGit.
Lets say its on a server somewhere on the network.
Lets say its a bit more liberal in what it accepts...
$ git push origin
Hi Phillip,
Thanks for review!
2015-07-05 15:21 GMT+02:00 Phillip Sz phillip.sze...@gmail.com:
#: help.c:214
msgid git commands available from elsewhere on your $PATH
msgstr Vorhandene Git-Kommandos irgendwo in Ihrem $PATH
What do you think about Git-Kommandos sind anderwo verfügbar in
On 2015-07-02 16.00, Thomas Vieten wrote:
[]
see the file attachend to the end of this message
Thanks for the info
It may be, that you need to nornalize your repo:
in principle we know all this.
What is remarkable that we are able to checkout a version of master which is
not consistent with
On Wed, Jul 1, 2015 at 4:49 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
I am moderately negative about this; wouldn't it make the end result
cleaner to fix the implementation?
I'm not sure I understand your suggestion. Are you saying, you would
On 06/29/2015 10:17 PM, David Turner wrote:
Add an err argument to log_ref_setup that can explain the reason
for a failure. This then eliminates the need to manage errno through
this function since we can just add strerror(errno) to the err string
when meaningful. No callers relied on errno
Dear list:
In the past, when we do the merge in git, if conflicts occurred, when
we commit, the conflict list will be appended to the default commit
message automatically.
eg:
Conflicts:
a.java
b.java
Today, after using Git 2.3.0 for a merge, it seems now the conflict
list was commented
On Wed, Jul 1, 2015 at 1:49 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
I am moderately negative about this; wouldn't it make the end result
cleaner to fix the implementation?
I'm not sure I understand your suggestion. Are you saying, you would
Andrey Hsiao andreyhs...@gmail.com writes:
Dear list:
In the past, when we do the merge in git, if conflicts occurred,
when we commit, the conflict list will be appended to
the default commit message automatically.
eg:
Conflicts:
a.java
b.java
Today, after using Git 2.3.0
On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz dborow...@google.com wrote:
b. Write a parser in some other clever way, e.g. parsing the entire
cert in reverse might work.
...as long as is illegal in nonce and pushee values, which it may
be but is not explicitly documented. I still have no
On Mon, Jul 6, 2015 at 11:27 AM, Dave Borowitz dborow...@google.com wrote:
On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz dborow...@google.com wrote:
b. Write a parser in some other clever way, e.g. parsing the entire
cert in reverse might work.
...as long as is illegal in nonce and pushee
Dear list:
In the past, when we do the merge in git, if conflicts occurred,
when we commit, the conflict list will be appended to
the default commit message automatically.
eg:
Conflicts:
a.java
b.java
Today, after using Git 2.3.0 for a merge, it seems now the conflict list
was
On Mon, Jul 6, 2015 at 10:46 AM, Dave Borowitz dborow...@google.com wrote:
On Wed, Jul 1, 2015 at 4:49 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
I am moderately negative about this; wouldn't it make the end result
cleaner to fix the
On 06/29/2015 10:17 PM, David Turner wrote:
Instead of directly writing to and reading from files in
$GIT_DIR, use ref API to interact with CHERRY_PICK_HEAD
and REVERT_HEAD.
Signed-off-by: David Turner dtur...@twopensource.com
---
branch.c | 4 ++--
97 matches
Mail list logo
