Most gmtime implementations return a NULL value when they
encounter an error (and this behavior is specified by ANSI C
and POSIX). FreeBSD's implementation, however, will
indicate an error by returning a pointer to a struct tm
with all fields set to zero. Let's also recognize this and
convert it
One of the tests in t4212 checks our behavior when we feed
gmtime a date so far in the future that it gives up and
returns NULL. Some implementations, like AIX, may actually
just provide us a bogus result instead.
It's not worth it for us to come up with heuristics that
guess whether the return
AIX's gmtime will happily overflow the tm_year field. Let's
catch this error before handing the value to gmtime.
Signed-off-by: Jeff King p...@peff.net
---
This is an alternative to loosening the test in t4212.
It's really not _that_ ugly. The LL here may not be portable, though.
32-bit systems
On Mon, Mar 31, 2014 at 02:48:45PM -0700, Siddharth Agarwal wrote:
On 03/28/2014 03:00 AM, Jeff King wrote:
From: Vicent Marti tan...@gmail.com
When pack-objects is computing the reachability bitmap to serve a
fetch request, it can erroneously die() if some of the UNINTERESTING
objects are
On 04/01/2014 12:37 AM, Michael Haggerty wrote:
On 03/31/2014 11:51 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Make (most of) the error messages for invalid input have the same
format [1]:
$COMMAND [SP $REFNAME]: $MESSAGE
Update the tests accordingly.
Hi guys!
I just made two Git scripts of mine open-source:
https://github.com/cool-RR/git-cascade
https://github.com/cool-RR/git-cascade
This project contains two scripts:
- git cascade - Cascade changes from each branch to its dependents.
- git forward-merge - Merge branches without
I tried to get a diff between HEAD and the current version of my
project, so I did git diff.
It's a web project with a CSS file that contains the following CSS rule:
a[href^=tel] {
color:inherit;
text-decoration:none;
}
Now, whenever I do git diff, it will always show the a[href^=tel]
Hi;
I hope this is the right place for my question.
I wanna build GoldenDict from source, however I get a fattal error when I
try to clone the repository.
Here is the recorded session:
sunny@s9:~/Programs/goldendict$ git clone
git://github.com/goldendict/goldendict.git
Cloning into
On Tue, Apr 01, 2014 at 07:25:54PM +0900, Mike Hommey wrote:
I am currently prototyping a native mercurial remote handler for git,
For my own curiosity, how does this differ from what is in
contrib/remote-helpers/git-remote-hg?
Would adding a fast-import command to handle deltas be considered
On Tue, Apr 01, 2014 at 12:49:00PM +0200, rocketscienc01100101 . wrote:
I tried to get a diff between HEAD and the current version of my
project, so I did git diff.
That actually diffs between the index and the working tree, but if you
haven't used git add to add any changes, the index content
On Tue, Apr 01, 2014 at 07:45:03AM -0400, Jeff King wrote:
On Tue, Apr 01, 2014 at 07:25:54PM +0900, Mike Hommey wrote:
I am currently prototyping a native mercurial remote handler for git,
For my own curiosity, how does this differ from what is in
contrib/remote-helpers/git-remote-hg?
On Tue, Apr 01, 2014 at 10:07:03PM +0900, Mike Hommey wrote:
For my own curiosity, how does this differ from what is in
contrib/remote-helpers/git-remote-hg?
contrib/remote-helpers/git-remote-hg does a local mercurial clone before
doing the git conversion. While this is not really a
Hi,
I found something which seems to be a bug to me (or well, maybe I'm
doing something wrong...). When I revert a commit with -n/--no-commit
and there's a conflict, when doing git revert --continue I get an
editor, even though I wouldn't expect that to happen.
Example:
$ git init
On Tue, Apr 01, 2014 at 09:15:12AM -0400, Jeff King wrote:
It seems to me fast-import keeps a kind of human readable format for its
protocol, i wonder if xdelta format would fit the bill. That being said,
I also wonder if i shouldn't just try to write a pack on my own...
The fast-import
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have seen some discussion about various changes to the format of the
index and pack files over time, but can't find anything about it in
the man pages. Are the different formats documented anywhere, and how
to tell which format you are using?
Document a couple more functions and the flags argument as used by
hold_lock_file_for_update() and hold_lock_file_for_append().
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/technical/api-lockfile.txt | 36 +---
1 file changed, 33
This makes space for other bits.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
cache.h| 2 +-
lockfile.c | 9 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index 107ac61..08d0e48 100644
--- a/cache.h
+++ b/cache.h
@@ -537,7 +537,7 @@
This reduces the amount of string editing gyrations and makes it
unnecessary for callers to know how to derive the filename from the
lock_filename.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
cache.h| 1 +
lockfile.c | 57
It is only necessary to clear the lock_file's filename field if it was
not already clear.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lockfile.c b/lockfile.c
index 8fbcb6a..d26711f 100644
--- a/lockfile.c
Allocate temporary space to hold result_file instead of storing it in
a fixed-length buffer. This removes the last arbitrary path-length
limitation, so remove the path length check in lock_file().
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 19 ---
1
It does exactly what we need.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 3974137..852d717 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -72,12 +72,8 @@ static void
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 852d717..c06e134 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -85,6 +85,14 @@ static void
When deleting a reference, it might be that another process already
holds the lock on the loose reference file and/or the packed-refs
file. In those cases, there is no alternative but for the delete to
fail. Verify that in such cases the reference values are left
unchanged.
But in fact, when
Add a new option flag, LOCK_SEPARATE_STAGING_FILE, that can be passed
to hold_lock_file_for_update() or hold_lock_file_for_append() to use a
staging file that is independent of the lock file.
Add a new function activate_staging_file() that activates the contents
that have been written to the
Now that the filename is stored separately, the external users of this
field only use it as the filename to which they are trying to write.
Soon it will not necessarily be the name of the lock file, so rename
the field more generically.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
It's bad manners. Especially since, if unlink_or_warn() failed, the
memory wasn't restored to its original contents.
So make our own copy to work with.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff
When rolling back the lockfile, call close_lock_file() so that the
lock_file's fd field gets set back to -1. This could help prevent
confusion in the face of hypothetical future programming errors.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 2 +-
1 file changed, 1
It used to be that if locking failed, lock_file() usually did not
register the lock_file object in lock_file_list but sometimes it did.
This confusion was compounded if lock_file() was called via
hold_lock_file_for_append(), which has its own failure modes.
The ambiguity didn't have any ill
I've had this patch series kicking around for a long time, along with
some followup patches to fix a race in reference deletion. I haven't
had the time to get everything done and tested, but let me at least
push this first series out there. I especially want to submit it in
case we accept a GSoC
This is a bit easier to read than the old version, which nested part
of the non-error code in an if block.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index
By the time the if block is entered, the lock_file instance from the
main function block is no longer in use, so re-use that one instead of
allocating a second one.
Note that the lock variable in the if block used to shadow the
lock variable at function scope, so the only change needed is to
If there is an error copying the old contents to the lockfile, roll
back the lockfile before exiting so that the lockfile is not held
until process cleanup.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 4a9ceda..4e3ada8 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -178,14 +178,17 @@ static char *resolve_symlink(char *p,
Mike Hommey m...@glandium.org writes:
On Tue, Apr 01, 2014 at 09:15:12AM -0400, Jeff King wrote:
It seems to me fast-import keeps a kind of human readable format for its
protocol, i wonder if xdelta format would fit the bill. That being said,
I also wonder if i shouldn't just try to write
Junio C Hamano wrote:
Assuming that you do have and are willing to read the original file,
you have three possible (and one impractical) approaches:
[...]
- Apply the foreign changes to the original file yourself, and feed
the resulting content to fast-import in full, letting fast-import
Am 01.04.2014 09:42, schrieb Jeff King:
diff --git a/compat/gmtime.c b/compat/gmtime.c
new file mode 100644
index 000..ffcabf4
--- /dev/null
+++ b/compat/gmtime.c
@@ -0,0 +1,26 @@
+#include ../git-compat-util.h
+#undef gmtime
+#undef gmtime_r
+
+struct tm *git_gmtime(const time_t *timep)
+{
For some people it is also a norm to keep files that have been
modified from HEAD and/or index without committing for a long time
(e.g. earlier, Linus said that the version in Makefile is updated and
kept modified in the working tree long before a new release is
committed with that
Justin Lebar jle...@google.com writes:
[administrivia: please do not top-post]
On Mon, Mar 31, 2014 at 4:19 PM, Junio C Hamano gits...@pobox.com wrote:
Four patches queued on 'pu' as-is (but retitled). I didn't read
everything very carefully, though.
Thanks.
It's unclear to me: Are we
Jeff King p...@peff.net writes:
On Fri, Mar 28, 2014 at 12:30:02PM -0700, Junio C Hamano wrote:
Let's just deal with a simple known cases (like FreeBSD) in the real
code that everybody exercises at runtime, and have the new test only
check we do not segfault on a value we used to segfault
René Scharfe l@web.de writes:
Am 01.04.2014 09:42, schrieb Jeff King:
diff --git a/compat/gmtime.c b/compat/gmtime.c
new file mode 100644
index 000..ffcabf4
--- /dev/null
+++ b/compat/gmtime.c
@@ -0,0 +1,26 @@
+#include ../git-compat-util.h
+#undef gmtime
+#undef gmtime_r
+
Duy Nguyen pclo...@gmail.com writes:
The basic support is there. Some bells and whistles (e.g. listing
checkouts) are not, but we can add them when we see the needs. Eric
and Torsten helped review but no, there hasn't much discussion about
it, which may be because it's already perfect, or
Read the configuration to get trailer information, and then process
it and storing it in a doubly linked list.
The config information is stored in the list whose first item is
pointed to by:
static struct trailer_item *first_conf_item;
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
t/t7513-interpret-trailers.sh | 336 ++
1 file changed, 336 insertions(+)
create mode 100755 t/t7513-interpret-trailers.sh
diff --git a/t/t7513-interpret-trailers.sh
Implement the logic to process trailers from stdin and arguments.
At the beginning trailers from stdin are in their own in_tok
doubly linked list, and trailers from arguments are in their own
arg_tok doubly linked list.
The lists are traversed and when an arg_tok should be applied,
it is removed
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
t/t7513-interpret-trailers.sh | 71 +++
1 file changed, 71 insertions(+)
diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh
index 417a4f3..0a1f3b6 100755
---
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Documentation/git-interpret-trailers.txt | 123 +++
1 file changed, 123 insertions(+)
create mode 100644 Documentation/git-interpret-trailers.txt
diff --git a/Documentation/git-interpret-trailers.txt
This patch adds the git interpret-trailers command.
This command uses the previously added process_trailers()
function in trailer.c.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
.gitignore | 1 +
Makefile | 1 +
builtin.h
This patch series implements a new command:
git interpret-trailers
and an infrastructure to process trailers that can be reused,
for example in commit.c.
1) Rationale:
This command should help with RFC 822 style headers, called
trailers, that are found at the end of commit messages.
This patch adds the process_trailers() function that
calls all the previously added processing functions
and then prints the results on the standard output.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
trailer.c | 49 +
trailer.h |
We will use a doubly linked list to store all information
about trailers and their configuration.
This way we can easily remove or add trailers to or from
trailer lists while traversing the lists in either direction.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Makefile | 1 +
---
Documentation/git-rev-parse.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index e05e6b3..377d9d7 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -363,7 +363,7 @@
Michael Haggerty mhag...@alum.mit.edu writes:
Use temporary variables in the for-loop blocks to simplify expressions
in the rest of the loop.
Shouldn't the summary of the change simplify expressions? Use of
temporary variables is a means to the end. If you have enough room
to say achieve X
Parse the trailer command line arguments and put
the result into an arg_tok doubly linked list.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
trailer.c | 103 ++
1 file changed, 103 insertions(+)
diff --git a/trailer.c
Read trailers from stdin, parse them and put the result into a doubly linked
list.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
trailer.c | 76 +++
1 file changed, 76 insertions(+)
diff --git a/trailer.c b/trailer.c
Michael Haggerty mhag...@alum.mit.edu writes:
Build out the API for dealing with a bunch of reference checks and
changes within a transaction. Define an opaque ref_transaction type
that is managed entirely within refs.c. Introduce functions for
beginning a transaction, adding updates to a
On Tue, Apr 01, 2014 at 12:07:22PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Fri, Mar 28, 2014 at 12:30:02PM -0700, Junio C Hamano wrote:
Let's just deal with a simple known cases (like FreeBSD) in the real
code that everybody exercises at runtime, and have the
Michael Haggerty mhag...@alum.mit.edu writes:
This change is mostly clerical: the parse_cmd_*() functions need to
use local variables rather than a struct ref_update to collect the
arguments needed for each update, and then call ref_transaction_*() to
queue the change rather than building up
Michael Haggerty mhag...@alum.mit.edu writes:
It has been superseded by reference transactions. This also means
that struct ref_update can become private.
Good.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
On Tue, Apr 01, 2014 at 05:58:09PM +0200, Michael Haggerty wrote:
When deleting a reference, it might be that another process already
holds the lock on the loose reference file and/or the packed-refs
file. In those cases, there is no alternative but for the delete to
fail. Verify that in
Michael Haggerty mhag...@alum.mit.edu writes:
This is consistent with the usual nomenclature.
I am of two minds.
Looking for \(\.\|-\)ref_name used to ignore refname fields of
other structures and let us focus on the ref_update structure. Yes,
there is the ref_lock structure that shares
On Tue, Apr 01, 2014 at 10:18:55AM -0400, Phillip Susi wrote:
I have seen some discussion about various changes to the format of the
index and pack files over time, but can't find anything about it in
the man pages. Are the different formats documented anywhere, and how
to tell which format
Michael Haggerty mhag...@alum.mit.edu writes:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/refs.c b/refs.c
index d72d0ab..2b80f6d 100644
--- a/refs.c
+++ b/refs.c
@@ -3274,11 +3274,11
On Tue, Apr 01, 2014 at 05:58:12PM +0200, Michael Haggerty wrote:
When rolling back the lockfile, call close_lock_file() so that the
lock_file's fd field gets set back to -1. This could help prevent
confusion in the face of hypothetical future programming errors.
This also solves a race. We
On Tue, Apr 01, 2014 at 05:58:13PM +0200, Michael Haggerty wrote:
If the call to adjust_shared_perm() fails, lock_file returns -1, which
to the caller looks like any other failure to lock the file. So in
this case, roll back the lockfile before returning so that the lock
file is deleted
On Tue, Apr 01, 2014 at 05:58:10PM +0200, Michael Haggerty wrote:
By the time the if block is entered, the lock_file instance from the
main function block is no longer in use, so re-use that one instead of
allocating a second one.
Note that the lock variable in the if block used to shadow
Michael Haggerty mhag...@alum.mit.edu writes:
This is temporary space for ref_transaction_commit().
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
I was about to complain to *Add* type that does not say what it is
used for at all, with Please do not add something for unknown
On Tue, Apr 01, 2014 at 04:02:42PM -0400, Jeff King wrote:
On Tue, Apr 01, 2014 at 05:58:13PM +0200, Michael Haggerty wrote:
If the call to adjust_shared_perm() fails, lock_file returns -1, which
to the caller looks like any other failure to lock the file. So in
this case, roll back the
I also have this question posted to stack overflow (
http://stackoverflow.com/questions/22792906/how-do-i-produce-every-possible-git-status
), but perhaps this is a better place to ask this question.
In working on some code which provides an interface to existing git
repositories the question
On Tue, Apr 01, 2014 at 05:58:15PM +0200, Michael Haggerty wrote:
diff --git a/lockfile.c b/lockfile.c
index e679e4c..c989f6c 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -130,6 +130,22 @@ static int lock_file(struct lock_file *lk, const char
*path, int flags)
*/
static const
On Tue, Apr 01, 2014 at 05:58:17PM +0200, Michael Haggerty wrote:
+unable_to_lock_error::
+
+ Emit an error describing that there was an error locking the
+ specified path. The err parameter should be the errno of the
+ problem that caused the failure.
+
On Tue, Apr 01, 2014 at 05:58:20PM +0200, Michael Haggerty wrote:
It's bad manners. Especially since, if unlink_or_warn() failed, the
memory wasn't restored to its original contents.
So make our own copy to work with.
Sounds good...
if (!(flag REF_ISPACKED) || flag REF_ISSYMREF)
Am 01.04.2014 01:35, schrieb Ronald Weiss:
On 1. 4. 2014 0:50, Ronald Weiss wrote:
On 31. 3. 2014 23:47, Ronald Weiss wrote:
On Mon, Mar 31, 2014 at 8:58 PM, Jens Lehmann jens.lehm...@web.de wrote:
As Junio mentioned it would be great if you could teach the add
command also honor the
On Tue, Apr 01, 2014 at 05:58:22PM +0200, Michael Haggerty wrote:
/*
- * p = path that may be a symlink
- * s = full size of p
- *
- * If p is a symlink, attempt to overwrite p with a path to the real
- * file or directory (which may or may not exist), following a chain of
- * symlinks if
On Tue, Apr 01, 2014 at 05:58:30PM +0200, Michael Haggerty wrote:
Add a new option flag, LOCK_SEPARATE_STAGING_FILE, that can be passed
to hold_lock_file_for_update() or hold_lock_file_for_append() to use a
staging file that is independent of the lock file.
Add a new function
On Tue, Apr 01, 2014 at 05:58:08PM +0200, Michael Haggerty wrote:
I've had this patch series kicking around for a long time, along with
some followup patches to fix a race in reference deletion. I haven't
had the time to get everything done and tested, but let me at least
push this first
Am 01.04.2014 21:08, schrieb Junio C Hamano:
René Scharfe l@web.de writes:
Am 01.04.2014 09:42, schrieb Jeff King:
diff --git a/compat/gmtime.c b/compat/gmtime.c
new file mode 100644
index 000..ffcabf4
--- /dev/null
+++ b/compat/gmtime.c
@@ -0,0 +1,26 @@
+#include ../git-compat-util.h
On Tue, Apr 01, 2014 at 11:17:14PM +0200, René Scharfe wrote:
So are you saying we should set EOVERFLOW ourselves, or does FreeBSD
set EOVERFLOW for us in this case and we do not have to worry?
If we correct the return value then we should correct errno as well.
gmtime() on FreeBSD 10
Michael Toy mich...@toyland.org writes:
Of the 24 possibilities (not counting ignored) in git-status,
there are 7 that I can't figure out how to generate.
As the post [*1*] that triggered e92e9cd3 (Documentation
improvements for the description of short format., 2010-04-23),
which is where the
On 1. 4. 2014 22:23, Jens Lehmann wrote:
Am 01.04.2014 01:35, schrieb Ronald Weiss:
On 1. 4. 2014 0:50, Ronald Weiss wrote:
On 31. 3. 2014 23:47, Ronald Weiss wrote:
On Mon, Mar 31, 2014 at 8:58 PM, Jens Lehmann jens.lehm...@web.de wrote:
As Junio mentioned it would be great if you could
Junio C Hamano gits...@pobox.com writes:
I haven't reverted the merge of that submodule update topic yet; I
should do that soonish.
...
Sigh... This is giving me a lot of headache.
As 23d25e48 (submodule: explicit local branch creation in
module_clone, 2014-01-26) has been in 'master' since
On Tue, Apr 01, 2014 at 10:14:02AM -0700, Junio C Hamano wrote:
Mike Hommey m...@glandium.org writes:
On Tue, Apr 01, 2014 at 09:15:12AM -0400, Jeff King wrote:
It seems to me fast-import keeps a kind of human readable format for its
protocol, i wonder if xdelta format would fit the
Michael Toy wrote:
https://gist.github.com/the-michael-toy/9907309
Two nits:
- Please use --porcelain (implied by -z in the absence of another
format option) instead of --short. --short is meant to be human
readable and details of the output might change some day.
- Depending on what
Mike Hommey m...@glandium.org writes:
On Tue, Apr 01, 2014 at 10:14:02AM -0700, Junio C Hamano wrote:
...
Unless you already have your change in the xdelta on hand, or the
format your foreign change is in gives sufficient information to
produce a corresponding xdelta without looking at the
Junio C Hamano gits...@pobox.com writes:
Christian Couder chrisc...@tuxfamily.org writes:
+test_expect_success '--trim-empty without config' '
+cat expected -\EOF
+ack: Peff
+Acked-by: Johan
+EOF
+git interpret-trailers --trim-empty ack = Peff
Christian Couder chrisc...@tuxfamily.org writes:
+test_expect_success '--trim-empty without config' '
+ cat expected -\EOF
+ ack: Peff
+ Acked-by: Johan
+ EOF
+ git interpret-trailers --trim-empty ack = Peff Reviewed-by
Acked-by: Johan sob: actual
+
On Tue, Apr 01, 2014 at 03:32:49PM -0700, Junio C Hamano wrote:
[Footnote]
*1* I am still not sure how useful the feature would be outside
slurping from Hg and Git---for obvious reasons, though. As long as
the change is to a cleanly isolated codepath, it would be OK, I
guess.
That's why I
On 01.04.2014, at 15:15, Jeff King p...@peff.net wrote:
On Tue, Apr 01, 2014 at 10:07:03PM +0900, Mike Hommey wrote:
For my own curiosity, how does this differ from what is in
contrib/remote-helpers/git-remote-hg?
contrib/remote-helpers/git-remote-hg does a local mercurial clone before
On Wed, Apr 2, 2014 at 2:17 AM, Junio C Hamano gits...@pobox.com wrote:
Unfortunately, this multiple checkout thing conflicts with how I
use emacs (--daemon) so I'm not one of its heavy users either. I
only occastionally make new, short-lived checkouts to test things.
FWIW, I do keep a
(culling cc list)
Hi,
Christian Couder wrote:
[Subject: Documentation: add documentation for 'git interpret-trailers']
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
This should be squashed into the patch that introduces the
interpret-trailers command, IMHO (or if it should be
On Wed, Apr 02, 2014 at 01:29:13AM +0200, Max Horn wrote:
On 01.04.2014, at 15:15, Jeff King p...@peff.net wrote:
On Tue, Apr 01, 2014 at 10:07:03PM +0900, Mike Hommey wrote:
For my own curiosity, how does this differ from what is in
contrib/remote-helpers/git-remote-hg?
On 04/01/2014 09:39 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Build out the API for dealing with a bunch of reference checks and
changes within a transaction. Define an opaque ref_transaction type
that is managed entirely within refs.c. Introduce functions for
On 04/01/2014 09:46 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
This change is mostly clerical: the parse_cmd_*() functions need to
use local variables rather than a struct ref_update to collect the
arguments needed for each update, and then call
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
I haven't reverted the merge of that submodule update topic yet; I
should do that soonish.
...
Sigh... This is giving me a lot of headache.
As 23d25e48 (submodule: explicit local branch creation in
On 04/01/2014 09:53 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
This is consistent with the usual nomenclature.
I am of two minds.
Looking for \(\.\|-\)ref_name used to ignore refname fields of
other structures and let us focus on the ref_update structure.
94 matches
Mail list logo
