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
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
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
---
No change since v4.
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
---
No change since v4.
wt-status.c | 32
Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr writes:
I'd vote for keeping it simple and not having the copyright notice. Most
t/*.sh do not have one. The Git history + mailing-list archives are much
better than in-code comments to keep track of who wrote what.
Remi: any objection on
On Tue, Jun 30, 2015 at 4:32 AM, Stefan Beller sbel...@google.com wrote:
for calculating the minutes we would only need to take % 3600 (which
you do), but
then we still need to divide by 60 to convert seconds to minutes?
Whoops, yes we do. It should be:
tz = tz / 3600 * 100 + tz % 3600 / 60;
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr writes:
This series makes git status provide an output like
interactive rebase in progress; onto $ONTO
Last commands done (2 commands done):
pick $COMMIT2 two_commit
exec exit 15
Next commands to
On Tue, Jun 30, 2015 at 4:32 AM, Stefan Beller sbel...@google.com wrote:
On Mon, Jun 29, 2015 at 1:32 PM, Stefan Beller sbel...@google.com wrote:
On Sun, Jun 28, 2015 at 7:06 AM, Paul Tan pyoka...@gmail.com wrote:
+ tz = tz / (60 * 60) * 100 + tz % (60 * 60);
What
The use of must (albeit not in all caps) suggests that this is
actually a requirement of the protocol. As no implementation exists
that actually does this verification, this is misleading at best.
Signed-off-by: Dave Borowitz dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 3
send-pack.c omits this field when args-url is null or empty. Fix the
protocol specification to match reality.
Signed-off-by: Dave Borowitz dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
We want to fix such inaccuracies, but there are a lot and there is no
guarantee at any particular point in time that this document will be
error-free.
Signed-off-by: Dave Borowitz dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 11 +++
1 file changed, 11
Signed-off-by: Dave Borowitz dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index 66d2d95..1386840 100644
---
The signed push protocol documentation did not really match the reality of what
send-pack.c and receive-pack.c do, much to my chagrin as I attempted to
implement this protocol in JGit. This series covers most of the issues I found
on a first pass.
Dave Borowitz (7):
pack-protocol.txt: Add
On Wed, Jul 1, 2015 at 11:08 AM, Dave Borowitz dborow...@google.com wrote:
Signed-off-by: Dave Borowitz dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/technical/pack-protocol.txt
On Wed, Jul 01, 2015 at 08:19:40AM -0700, Junio C Hamano wrote:
Sounds good. While at it, perhaps add a mention (perhaps by
creating a BUGS section at the end of the file) that --count
with --use-bitmap-index ignores pathspec silently?
I think we can just fix it rather than documenting the
On Wed, Jul 1, 2015 at 11:21 AM, Stefan Beller sbel...@google.com wrote:
I think the problem with this part of the documentation is its ambiguity on
what exactly we want to document. The sender SHOULD put an LF, while
the receiver MUST NOT assume the LF is there always, so I guess it's best
to
Eric Sunshine sunsh...@sunshineco.com writes:
On Wed, Jul 1, 2015 at 1:13 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, Jul 1, 2015 at 12:53 PM, Junio C Hamano gits...@pobox.com wrote:
* Duy seems to think worktree add is coming, too, so here is a
trivial tweak of your patch
On Wed, Jul 1, 2015 at 12:36 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
I was about to mention the same shortcoming, but you beat me to it.
Perhaps be more strict and do this instead (without
leading strbuf_trim):
if
Matthieu Moy matthieu@imag.fr writes:
+/*
+ * Turn
+ * pick d6a2f0303e897ec257dd0e0a39a5ccb709bc2047 some message
+ * into
+ * pick d6a2f03 some message
+ */
+static void abbrev_sha1_in_line(struct strbuf *line)
+{
+ struct strbuf **split;
+ int i;
+
+ if
Thanks, will queue.
--
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
On Wed, Jul 1, 2015 at 1:01 AM, Paul Tan pyoka...@gmail.com wrote:
On Tue, Jun 30, 2015 at 7:51 AM, Stefan Beller sbel...@google.com wrote:
I needed to read this patch a few times as this patch introduces
`sign_commit`
twice. This is mostly a review problem I'd guess as in the code it
just
From: Eric Sunshine sunsh...@sunshineco.com
The command git checkout --to path is something of an anachronism,
encompassing functionality somewhere between checkout and clone.
The introduction of the git-worktree command, however, provides a proper
and intuitive place to house such functionality.
Dave Borowitz dborow...@google.com writes:
send-pack.c omits this field when args-url is null or empty. Fix the
protocol specification to match reality.
Do some clients omit this in the real world?
As you say, send_pack() does omit it if args-url is null or empty,
but args is prepared in
pack-protocol.txt does not list the nonce as optional. Fortunately, it
should be impossible to not have a nonce by this point in the code, as
the caller should have died on line 380 prior to generating a push
certificate with an empty nonce.
Nonetheless, having this explicit error handling in the
On Wed, Jul 1, 2015 at 1:13 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, Jul 1, 2015 at 12:53 PM, Junio C Hamano gits...@pobox.com wrote:
* Duy seems to think worktree add is coming, too, so here is a
trivial tweak of your patch from the last month, with test
adjustments to
Dave Borowitz dborow...@google.com writes:
This is sort of like a standard identity, except that RFC 4880 section
4.11 allows any UTF-8 text in the User ID packet. It is trivial to get
gpg to pass arbitrary text when generating a push cert by setting
user.signingKey to that arbitrary value
On Tue, Jun 30, 2015 at 7:56 AM, Stefan Beller sbel...@google.com wrote:
I realize this was in am.sh as well, but I find the help strings a bit
unfortunate.
(Yes, you actually need to look them up at another place as most people are
not familiar with the apply options).
Yeah I agree, it would
--count should be mentioned in the usage guide, this updates code and
documentation.
Signed-off-by: Lawrence Siebert lawrencesieb...@gmail.com
---
Documentation/git-rev-list.txt | 1 +
builtin/rev-list.c | 1 +
2 files changed, 2 insertions(+)
diff --git
On Thu, Jun 25, 2015 at 2:39 AM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
IMO the varargs make the code more cumbersome to read (and even fragile,
because you can easily call `xopen(path, O_WRITE | O_CREATE)` and would not
even get so much as a compiler warning!)
I think that
Dear
Good day
Pocket size mini foldable monopod selfie stick with bt shutter button on stick,
now only $3/pc ,only from us,the arcpeaks factory
http://arcpeaks.en.alibaba.com/product/60228194355-801021588/2015_original_factory_foldable_bluetooth_monopod_mini_selfie_stick.html
Please feel free
On Tue, Jun 30, 2015 at 08:00:53PM -0700, Lawrence Siebert wrote:
The following doesn't currently run: `git rev-list --count
--use-bitmap-index HEAD`
This is an optional parameter for rev-list from commit
aa32939fea9c8934b41efce56015732fa12b8247 which can't currently be used
because of
On Mon, Jun 29, 2015 at 11:13 PM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Commit 23af91d (prune: strategies for linked checkouts - 2014-11-30)
adds --worktrees to git prune without realizing that git prune is
for object database only. This patch
On Tue, Jun 30, 2015 at 11:33 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
I think this is like git checkout -b vs git branch. We pack so
many things in 'checkout' that it's a source of both convenience and
confusion. I never use git branch to create a new
Commit 28fcc0b (pathspec: avoid the need of -- when wildcard is used -
2015-05-02) changes how the disambiguation rules work. This patch adds
some tests to demonstrate, basically, if wildcard characters are in an
argument:
- if the argument is valid extended sha-1 syntax, -- must be used
-
On Wed, Jul 1, 2015 at 5:41 PM, Paul Tan pyoka...@gmail.com wrote:
Good point, I agree with this. I'll look into putting the error messages back.
This should work I think. It should take into account that O_RDONLY,
O_WRONLY, O_RDWR is defines as 0, 1, 2 on glibc, while the POSIX spec
also
Jeff King p...@peff.net writes:
Note that this would not work with, say:
git rev-list --use-bitmap-index --count HEAD -- Makefile
as the bitmap index does not have enough information to do path limiting
(we should probably disallow this or fall back to the non-bitmap code
path, but right
It is sometimes useful for importers to be able to read the SHA-1
corresponding to a mark that they have created via fast-import. For
example, they might want to embed the SHA-1 into the commit message of
a later commit. Or it might be useful for internal bookkeeping uses,
or for logging.
Add a
Lawrence Siebert lawrencesieb...@gmail.com writes:
--count should be mentioned in the usage guide, this updates code and
documentation.
Signed-off-by: Lawrence Siebert lawrencesieb...@gmail.com
---
Sounds good. While at it, perhaps add a mention (perhaps by
creating a BUGS section at the
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
Dave Borowitz dborow...@google.com writes:
send-pack.c omits this field when args-url is null or empty. Fix the
protocol specification to match reality.
Do some clients omit this in the real world?
As you
On Wed, Jul 1, 2015 at 12:39 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Dave Borowitz wrote:
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -14,6 +14,17 @@ data. The protocol functions to have a server tell a
client what is
Jeff King p...@peff.net writes:
On Wed, Jul 01, 2015 at 08:19:40AM -0700, Junio C Hamano wrote:
Sounds good. While at it, perhaps add a mention (perhaps by
creating a BUGS section at the end of the file) that --count
with --use-bitmap-index ignores pathspec silently?
I think we can just
Many users prefer to always use --follow with logs. Rather than
aliasing the command, an option might be more convenient for some.
Signed-off-by: David Turner dtur...@twopensource.com
---
Why not just alias log=log --follow?
At Twitter, we manage git config centrally, but we also allow users
Dave Borowitz dborow...@google.com writes:
Signed-off-by: Dave Borowitz dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index
On Wed, Jul 1, 2015 at 12:07 PM, Junio C Hamano gits...@pobox.com wrote:
Answering myself, the most trivial example is git send-pack ;-)
It passes args that has a NULL in the .url field.
Well, the example I have involves an actual git push command. The
fact that .url is NULL in that case may be
Hi,
Dave Borowitz wrote:
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -14,6 +14,17 @@ data. The protocol functions to have a server tell a
client what is
currently on the server, then for the two to negotiate the smallest amount
of
Jonathan Nieder jrnie...@gmail.com writes:
The 'Reference Discovery' section says:
Server SHOULD terminate each non-flush line using LF (\n) terminator;
client MUST NOT complain if there is no terminator.
I think these should be sender/receiver, not server/client.
--
To
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
prefer to make LFs optional in the push cert, for consistency with LFs
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
---
No modification.
t/t7512-status-help.sh | 28
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
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
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
---
No modification.
wt-status.c | 32
David Turner dtur...@twopensource.com writes:
diff --git a/builtin/log.c b/builtin/log.c
index 8781049..11b8d82 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -31,6 +31,7 @@ static const char *default_date_mode = NULL;
static int default_abbrev_commit;
static int default_show_root
Matthieu Moy matthieu@grenoble-inp.fr writes:
So activating --follow for all git log calls would prevent log from
being used with several pathspecs.
Or, do you have a preparation patch that allows --follow with multiple
pathspecs? ;-)
In any case, you have to test git log -- path1
Junio C Hamano gits...@pobox.com writes:
I am moderately negative about this; wouldn't it make the end result
cleaner to fix the implementation?
I think that something like this should be sufficient. As the
receiving end, we must not complain if there is no terminator.
...
And the change
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr writes:
+strbuf_trim(split[1]);
+if (!get_sha1(split[1]-buf, sha1)) {
+abbrev = find_unique_abbrev(sha1, DEFAULT_ABBREV);
+strbuf_reset(split[1]);
+
Matthieu Moy matthieu@grenoble-inp.fr writes:
Actually, we can do simpler: we still have the original line available,
...
I took this (modulo s/line.len[0]/line.buf[0]/, and s/rtrim/trim/ to be
robust to leading whitespace (not really important, but doesn't harm).
I'd prefer us to be
Junio C Hamano gits...@pobox.com writes:
Dave Borowitz dborow...@google.com writes:
Signed-off-by: Dave Borowitz dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/technical/pack-protocol.txt
Eric Sunshine sunsh...@sunshineco.com writes:
I was about to mention the same shortcoming, but you beat me to it.
Perhaps be more strict and do this instead (without
leading strbuf_trim):
if (!get_sha1_hex(split[1]-buf, sha1)
!strcmp(split[1]-buf + 40, ) {
On Wed, Jul 1, 2015 at 12:18 PM, Junio C Hamano gits...@pobox.com wrote:
Matthieu Moy matthieu@imag.fr writes:
+/*
+ * Turn
+ * pick d6a2f0303e897ec257dd0e0a39a5ccb709bc2047 some message
+ * into
+ * pick d6a2f03 some message
+ */
+static void abbrev_sha1_in_line(struct strbuf *line)
On Wed, Jul 1, 2015 at 3:22 AM, Paul Tan pyoka...@gmail.com wrote:
On Tue, Jun 30, 2015 at 7:56 AM, Stefan Beller sbel...@google.com wrote:
I realize this was in am.sh as well, but I find the help strings a bit
unfortunate.
(Yes, you actually need to look them up at another place as most
Here is an collection of various minor clean-ups in the
implementation of one of my most favourite feature, rerere.
This still hasn't reached the step to make the right refactoring to
allow me to fix a bug I wanted to fix, which prompted me to look at
this code, but it should give me a good
On Mon, Jun 29, 2015 at 12:48 PM, Torsten Bögershausen tbo...@web.de wrote:
- Having xopen() with 2 or 3 parameter is good, but the current may need
some tweaks for better portability:
int xopen(const char *path, int oflag, ...)
{
mode_t mode = 0;
if (oflag O_CREAT) {
On Tue, Jun 30, 2015 at 5:39 AM, Junio C Hamano gits...@pobox.com wrote:
Not using any increment inside isspace(), like you showed, is the
most readable.
Yup, I agree.
Thanks,
Paul
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
I'd vote for keeping it simple and not having the copyright notice. Most
t/*.sh do not have one. The Git history + mailing-list archives are much
better than in-code comments to keep track of who wrote what.
Remi: any objection on removing it?
Sorry for not having resent the patches myself,
On Tue, Jun 30, 2015 at 7:51 AM, Stefan Beller sbel...@google.com wrote:
I needed to read this patch a few times as this patch introduces `sign_commit`
twice. This is mostly a review problem I'd guess as in the code it
just affects this
method and you'd see all the code of the method easily
On 07/01/2015 09:10 PM, Karsten Blees wrote:
Of course, it would be nice to hear other opinions as well - this
probably shouldn't be a discussion between the two of us :-)
Karsten
I like this paragraf from your previous mail, I think it can go
into i18n.txt as is:
ISO-8859-x file names may
Moving commit counting from rev-list into list-object which is a step
toward letting git log do counting as well.
Signed-off-by: Lawrence Siebert lawrencesieb...@gmail.com
---
builtin/rev-list.c | 12 ++--
list-objects.c | 14 ++
list-objects.h | 1 +
3 files
adds --count from git rev-list to git log, without --use-bitmap-index
for the moment.
Signed-off-by: Lawrence Siebert lawrencesieb...@gmail.com
---
builtin/log.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/builtin/log.c b/builtin/log.c
index
I'm not altogether sure the best way to update the internal usage
from git-log -h, but this at least updates the man page.
Signed-off-by: Lawrence Siebert lawrencesieb...@gmail.com
---
Documentation/git-log.txt | 2 ++
Documentation/rev-list-options.txt | 2 +-
2 files changed, 3
added test comparing output between git log --count HEAD and
git rev-list --count HEAD
Signed-off-by: Lawrence Siebert lawrencesieb...@gmail.com
---
t/t4202-log.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 1b2e981..077952b 100755
---
On Wed, Jul 1, 2015 at 11:56 AM, Junio C Hamano gits...@pobox.com wrote:
Do some clients omit this in the real world?
I just sent you privately a trace where this happens using a recent
git client. With that in the wild, I think our server is going to have
to handle these even if there is a bug
Junio C Hamano gits...@pobox.com writes:
Dave Borowitz dborow...@google.com writes:
send-pack.c omits this field when args-url is null or empty. Fix the
protocol specification to match reality.
Do some clients omit this in the real world?
As you say, send_pack() does omit it if args-url
As a distributed VCS, git should better define the encodings of its core
textual data structures, in particular those that are part of the network
protocol.
That git is encoding agnostic is only really true for blob objects. E.g.
the 'non-NUL bytes' requirement of tree and commit objects excludes
Signed-off-by: Karsten Blees bl...@dcon.de
---
...just changed wording as you suggested.
Documentation/technical/racy-git.txt | 8 ++--
Makefile | 9 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/Documentation/technical/racy-git.txt
On Wed, Jul 1, 2015 at 1:00 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
Signed-off-by: Dave Borowitz dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
On Wed, Jul 1, 2015 at 9:07 PM, Duy Nguyen pclo...@gmail.com wrote:
On Thu, Jul 2, 2015 at 12:13 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
I noticed GIT_CHECKOUT_NEW_WORKTREE environment variabl that does
not seem to be documented. Is this something we still need?
The log
The first release candidate for the upcoming Git v2.5.0 is now
available for testing at the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the
'v2.5.0-rc1' tag and the 'master' branch that
What's cooking in git.git (Jul 2015, #01; Wed, 1)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here
On Tue, Jun 30, 2015 at 6:02 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Tue, Jun 30, 2015 at 5:23 AM, Duy Nguyen pclo...@gmail.com wrote:
On Tue, Jun 30, 2015 at 11:56 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
The command git checkout --to path is something of an anachronism,
Extract the body of a loop that attempts to replay recorded
resolution for each conflicted path into a helper function, not
because I want to call it from multiple places later, but because
the logic has become too deeply nested and hard to read.
Signed-off-by: Junio C Hamano gits...@pobox.com
Instead of writing the hash for a conflict, a HT, and the path
with three separate write_in_full() calls, format them into a
single record into a strbuf and write it out in one go.
As a more recent rerere remaining codepath abuses the .util field
of the merge_rr data to store a sentinel token,
On Tue, Jun 30, 2015 at 1:18 AM, Junio C Hamano gits...@pobox.com wrote:
Torsten Bögershausen tbo...@web.de writes:
2 remarks:
- I don't know if and why we need the assert() here (but don't know if
we have a strategie in Git for assert())
There is no bright-line rules, but I think it is
handle_cache() loops 3 times starting from an index entry that is
unmerged, while ignoring an entry for a path that is different from
what we are looking for.
As the index is sorted, once we see a different path, we know we saw
all stages for the path we are interested in. Just loop while we
see
The MERGE_RR file records a collection of NUL-terminated entries,
each of which consists of
- a hash that identifies the conflict
- a HT
- the pathname
We used to read this piece-by-piece, and worse yet, read the
pathname part a byte at a time into a fixed buffer of size PATH_MAX.
Instead,
Explain the internals of rerere as in-code comments.
This one covers our thin I/O abstraction to read from either
a file or a memory while optionally writing out to a file.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
rerere.c | 38 +++---
1 file changed,
As the nature of the conflict marker line determies if there should
a SP and label after it, the caller shouldn't have to pass the
parameter redundantly.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
rerere.c | 27 ++-
1 file changed, 22 insertions(+), 5
Explain the internals of rerere as in-code comments, while
sprinkling NEEDSWORK comment to highlight iffy bits and
questionable assumptions.
This one covers the codepath reached from rerere(), the primary
interface to the subsystem.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
rerere.c |
When ac49f5ca (rerere remaining, 2011-02-16) split out a new
helper function check_one_conflict() out of find_conflict()
function, so that the latter will use the returned value from the
new helper to update the loop control variable that is an index into
active_cache[], the new variable
Explain the internals of rerere as in-code comments, while
sprinkling NEEDSWORK comment to highlight iffy bits and
questionable assumptions.
This one covers the $GIT_DIR/MERGE_RR file and in-core merge_rr
that are used to keep track of the status of rerere session in
progress.
Signed-off-by:
Explain the internals of rerere as in-code comments, while
sprinkling NEEDSWORK comment to highlight iffy bits and
questionable assumptions.
This covers the codepath that implements rerere forget.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
rerere.c | 24
1 file
The merge_rr string list stores the conflict ID (a hexadecimal
string that is used to index into $GIT_DIR/rr-cache) in the .util
field of its elements, and when do_plain_rerere() resolves a
conflict, the field is cleared. Also, when rerere_forget()
recomputes the conflict ID to updates the
Signed-off-by: Junio C Hamano gits...@pobox.com
---
rerere.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/rerere.c b/rerere.c
index 27b287d..304df02 100644
--- a/rerere.c
+++ b/rerere.c
@@ -482,6 +482,8 @@ static void update_paths(struct string_list
On Tue, Jun 30, 2015 at 4:02 AM, Stefan Beller sbel...@google.com wrote:
On Sun, Jun 28, 2015 at 7:06 AM, Paul Tan pyoka...@gmail.com wrote:
When commit_tree() is called, if the user does not have an explicit
committer ident configured, it will attempt to construct a default
committer ident
On Thu, Jul 2, 2015 at 12:13 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
I noticed GIT_CHECKOUT_NEW_WORKTREE environment variabl that does
not seem to be documented. Is this something we still need?
The log message of 529fef20 (checkout: support checking out into
a new
94 matches
Mail list logo
