Duy Nguyen 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.c<2>", which belongs to which
> checkout?). I ended up modifying files in the wrong checkout
On Mon, Mar 31, 2014 at 5:50 PM, Junio C Hamano wrote:
> Thiago Farina 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 an error.
>>
>> But at line
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
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]:
http://git.661346.n2.nabble.com/RFC-What-s-the-best-UI-for-g
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
> -
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 a
David Kastrup writes:
> Junio C Hamano writes:
>
>> Junio C Hamano 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 crea
On Wed, Apr 02, 2014 at 11:18:26AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > On Mon, Mar 31, 2014 at 12:54:46PM -0700, Junio C Hamano wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > The hash used is mostly an internal implementation detail, isn't it?
> >>
> >> Yes,
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 wrote:
>> As Junio
"Michael S. Tsirkin" writes:
> On Mon, Mar 31, 2014 at 12:54:46PM -0700, Junio C Hamano wrote:
>> "Michael S. Tsirkin" 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
>> database ind
Nguyễn Thái Ngọc Duy 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
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> On Fri, Mar 28, 2014 at 11:04 AM, Eric
"Jonas Bang" 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
>> >>
"Ulrich Windl" 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 intentional?
Yes.
>
Junio C Hamano 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,
update->type when looki
Jeff King 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.
>
> However
Am 02.04.2014 19:32, schrieb Junio C Hamano:
René Scharfe 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
diff --git a/Documentation/git-rev-p
René Scharfe 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
> --- a/Documentation/git
Michael Haggerty writes:
> Reduce the amount of code that has to know about the lock_file's
> filename field.
>
> Signed-off-by: Michael Haggerty
> ---
> config.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/config.c b/config.c
> index 6821cef..1ea3f39 100
Michael Haggerty writes:
> Signed-off-by: Michael Haggerty
> ---
> 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 *r
Michael Haggerty 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);
> + if
Michael Haggerty 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 lock_filename === filenam
Michael Haggerty 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 a lockfile, thoug
Jeff King 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 our
Jeff King 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 errors.
>
Jeff King 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" varia
Michael Haggerty 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 know when you are re
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 http
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?
Usi
On 04/02/2014 09:06 AM, Eric Sunshine wrote:
> On Tue, Apr 1, 2014 at 11:58 AM, Michael Haggerty
> wrote:
>> Signed-off-by: Michael Haggerty
>> ---
>> lockfile.c | 31 ---
>> 1 file changed, 16 insertions(+), 15 deletions(-)
>>
>> diff --git a/lockfile.c b/lockfile.c
On 04/02/2014 04:09 AM, Michael Haggerty wrote:
> From: Aman Gupta
[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 create
"rocketscienc01100101 ." 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 where in the file the chang
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...
>
On 04/01/2014 10:19 PM, Jeff King wrote:
> 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
http://i.imgur.com/BoJSjm9.png
Here's a screenshot that shows the problem. There's always a misplaced
line in the output (most of the time a[href^=tel] { }), no matter
where in the file the changes are.
Sometimes it's even in the wrong position, above the @@ numbers.
I'd naturally expect the a[hr
On Tue, Apr 1, 2014 at 12:49 PM, rocketscienc01100101 .
wrote:
> 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-decorati
On 04/01/2014 09:56 PM, Jeff King wrote:
> 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
On 04/01/2014 09:53 PM, Jeff King wrote:
> 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 alternati
On 04/01/2014 10:03 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> This is temporary space for ref_transaction_commit().
>>
>> Signed-off-by: Michael Haggerty
>> ---
>
> I was about to complain to "*Add* type" that does not say what it is
> used for at all, with "Please do not add so
Jonathan Nieder writes:
> - 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.
It already does: part of the output may be translated to non-english.
From: Aman Gupta
Signed-off-by: Aman Gupta
Signed-off-by: Michael Haggerty
---
My colleague Aman ran across this bug and wrote the fix. I didn't
notice this bug, but I just verified that it is also fixed by my
mh/ref-transaction patch series (albeit without a test case).
Because the bug could
On Tue, Apr 1, 2014 at 11:58 AM, 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 activate_staging_fil
On Tue, Apr 1, 2014 at 11:58 AM, Michael Haggerty wrote:
> Signed-off-by: Michael Haggerty
> ---
> 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
> ++
42 matches
Mail list logo
