Hi,
On Wed, Apr 2, 2014 at 2:39 AM, Jonathan Nieder jrnie...@gmail.com wrote:
(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
On Wed, Apr 2, 2014 at 12:54 AM, Junio C Hamano gits...@pobox.com wrote:
+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
When we are sending a packfile to a remote, we currently try
to reuse a whole chunk of packfile without bothering to look
at the individual objects. This can make things like initial
clones much lighter on the server, as we can just dump the
packfile bytes.
However, it's possible that the other
[]
diff --git a/lockfile.c b/lockfile.c
index c1af65b..1928e5e 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -148,9 +148,11 @@ static int lock_file(struct lock_file *lk, const char
*path, int flags)
lock_file_list = lk;
lk-on_list = 1;
[]
diff --git a/refs.c b/refs.c
index 28d5eca..11ad23e 100644
--- a/refs.c
+++ b/refs.c
@@ -2485,12 +2485,14 @@ static int repack_without_ref(const char *refname)
static int delete_ref_loose(struct ref_lock *lock, int flag)
{
if (!(flag REF_ISPACKED) || flag REF_ISSYMREF) {
-
On Wed, Apr 02, 2014 at 08:52:17AM +0200, Torsten Bögershausen wrote:
+ /*
+ * loose. The loose file name is the same as the
+ * lockfile name, minus .lock:
+ */
+ char *loose_filename = xmemdupz(lock-lk-filename,
+
On 04/01/2014 05:58 PM, Michael Haggerty wrote:
Reduce the amount of code that has to know about the lock_file's
filename field.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
config.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/config.c
On 04/01/2014 10:21 PM, Jeff King wrote:
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
rocketscienc01100101 . rocketscienc01100...@gmail.com writes:
http://i.imgur.com/BoJSjm9.png
Here's a screenshot that shows the problem.
(better cut-and-paste the text than sending a PNG image)
There's always a misplaced line in the output (most of the time
a[href^=tel] { }), no matter
On 04/02/2014 04:09 AM, Michael Haggerty wrote:
From: Aman Gupta a...@tmm1.net
[snip]
@@ -147,6 +147,7 @@ static void parse_cmd_create(const char *next)
struct ref_update *update;
update = update_alloc();
+ update-have_old = 1;
Looks good.
+test_expect_success 'stdin -z
On 04/02/2014 09:06 AM, Eric Sunshine wrote:
On Tue, Apr 1, 2014 at 11:58 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
lockfile.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff
Hi!
I have a small question: After a git gc with last commit being [shared
2679648] I found this:
cat .git/HEAD
ref: refs/heads/shared
cat .git/refs/heads/shared
cat: .git/refs/heads/shared: No such file or directory
Is this intentional? How does Git find the numeric commit for HEAD?
Using
Good day,
Please can I talk to you about interesting business deal?
I will be happy if you permit.
I wait to hear from you soon.
Regards,
Kalifah
--
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
Michael Haggerty mhag...@alum.mit.edu writes:
Junio, I incorporated your feedback (which so far has only affected
commit messages). I also rebased the patch series to the current
master. I pushed the result to GitHub [1]. I'll refrain from spamming
the list with v3 yet.
Thanks; let us
Jeff King p...@peff.net writes:
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
Jeff King p...@peff.net writes:
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
Jeff King p...@peff.net writes:
So for a moment, lk-filename contains the name of the valuable file we
are locking. If we get a signal at that moment, do we accidentally
delete it in remove_lock_file?
I think the answer is no, because we check lk-owner before deleting,
which will not match
Michael Haggerty mhag...@alum.mit.edu writes:
Change struct lock_file's filename field from a fixed-length buffer
into a strbuf.
Good.
As I allued to in a review on an unrelated patch, I do not think it
is a good idea to name the lock filename field lock_filename in a
structure that is about
Michael Haggerty mhag...@alum.mit.edu writes:
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.
Hmph.
Is it worth duplicating the whole thing? If you are planning to
break the invariant
Michael Haggerty mhag...@alum.mit.edu writes:
+static int open_staging_file(struct lock_file *lk)
+{
+ strbuf_setlen(lk-staging_filename, lk-filename.len);
+ strbuf_addstr(lk-staging_filename, .new);
+ lk-fd = open(lk-staging_filename.buf, O_RDWR | O_CREAT | O_EXCL,
0666);
+
Michael Haggerty mhag...@alum.mit.edu writes:
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
@@
Michael Haggerty mhag...@alum.mit.edu writes:
Reduce the amount of code that has to know about the lock_file's
filename field.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
config.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/config.c
René Scharfe l@web.de writes:
---
Documentation/git-rev-parse.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Thanks; I'll forge your Sign-off ;-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index e05e6b3..377d9d7 100644
---
Am 02.04.2014 19:32, schrieb Junio C Hamano:
René Scharfe l@web.de writes:
---
Documentation/git-rev-parse.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Thanks; I'll forge your Sign-off ;-)
Oops, sorry, and thanks.
Signed-off-by: Rene Scharfe l@web.de
diff --git
Jeff King p...@peff.net writes:
When we are sending a packfile to a remote, we currently try
to reuse a whole chunk of packfile without bothering to look
at the individual objects. This can make things like initial
clones much lighter on the server, as we can just dump the
packfile bytes.
Junio C Hamano gits...@pobox.com writes:
I wonder if ref-transaction-commit can shrink its parameter list by
accepting a single pointer to one ref_update?
Disregard this one. I was fooled into thinking that the function is
called with parameters such as update-old_sha1, update_flags,
Ulrich Windl ulrich.wi...@rz.uni-regensburg.de writes:
Hi!
I have a small question: After a git gc with last commit being [shared
2679648] I found this:
cat .git/HEAD
ref: refs/heads/shared
cat .git/refs/heads/shared
cat: .git/refs/heads/shared: No such file or directory
Is this
Jonas Bang em...@jonasbang.dk writes:
... The default behaviour would cover their
use case so your proposal would not hurt them, but I wonder if there
are things you could do to help them as well, perhaps by allowing
this new configuration to express something like local changes in
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
If 'err' is non-zero, lstat() has failed. Consider the entry modified
without passing the (unreliable) stat info to ce_modified() in this
case.
Noticed-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Nguyễn Thái Ngọc Duy
Michael S. Tsirkin m...@redhat.com writes:
On Mon, Mar 31, 2014 at 12:54:46PM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
The hash used is mostly an internal implementation detail, isn't it?
Yes, but that does not mean we can break people who keep an external
Am 01.04.2014 23:59, schrieb Ronald Weiss:
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
On Wed, Apr 02, 2014 at 11:18:26AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Mon, Mar 31, 2014 at 12:54:46PM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
The hash used is mostly an internal implementation detail, isn't it?
David Kastrup d...@gnu.org writes:
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:
On 2. 4. 2014 20:53, Jens Lehmann wrote:
Am 01.04.2014 23:59, schrieb Ronald Weiss:
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
On Mon, Mar 31, 2014 at 05:29:03PM -0700, Junio C Hamano wrote:
* hv/submodule-ignore-fix (2013-12-06) 4 commits
- disable complete ignorance of submodules for index - HEAD diff
- always show committed submodules in summary after commit
- teach add -f option for ignored submodules
- fix
Hello,
I needed to convert a subdirectory of a repo to a submodule and have the
histories of both repos linked together. I found that this was discussed
few years back [1], but the code seemed quite complicated and was not
merged.
[1]:
During a 'git rebase --continue', I got an error about having left a
file in place which the next commit intended to add as new. Stupid me.
So I rm'ed the file and tried again. This time, git rebase --continue
succeeded. But it accidentally left out the next commit in my rebase-todo.
I looked
On Mon, Mar 31, 2014 at 5:50 PM, Junio C Hamano gits...@pobox.com wrote:
Thiago Farina tfrans...@gmail.com writes:
In imap-send.c:socket_perror() we pass |func| as a parameter, which I
think it is the name of the function that called socket_perror, or
the name of the function which generated
Duy Nguyen pclo...@gmail.com writes:
The --daemon part is probably not worth mentioning because I always
have one emacs window open. The problem is switch-buffer based on file
name can be confusing (git.c and git.c2, which belongs to which
checkout?). I ended up modifying files in the wrong
39 matches
Mail list logo
