* Re: git not resuming push
From: Jeff King @ 2011-11-23 18:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Brossier, git
In-Reply-To: <7vmxbncq5v.fsf@alter.siamese.dyndns.org>
On Tue, Nov 22, 2011 at 10:24:12PM -0800, Junio C Hamano wrote:
> Another possibility, if it is the connection between you and the other
> side that is the problem, is to chunk your push in smaller pieces. That
> is, if you are trying to push out v3.0, you first push only to v1.0, then
> to v2.0, and then finally to v3.0.
>
> Peff, by the way, wouldn't this request reminds of us of a scenario we
> discussed recently, which I said I would imagine would be common while you
> dismissed as not likely to be common?
I didn't say it wasn't common; I said I didn't think it was the majority
case, and that I didn't want a solution that only helped this case
without covering the other cases.
Also, it isn't clear to me that an immediate-reconnect scheme would
work. When the connection gets dropped, is it simply that TCP connection
that goes out, and another one could immediately be made to resume? Or
is the network actually out (even if only for a few seconds)?
-Peff
^ permalink raw reply
* Re: [PATCH] git-apply: fix rubbish handling in --check case
From: Brandon Casey @ 2011-11-23 18:44 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: git
In-Reply-To: <1322065563-3651-1-git-send-email-dedekind1@gmail.com>
On Wed, Nov 23, 2011 at 10:26 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> $ git apply --check /bin/bash
> $ echo $?
> 0
>
> Not exactly what I expected :-) The same happnes if you use an empty file.
>
> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> ---
>
> Note, I did not extensively test it!
>
> Makefile | 2 +-
> builtin/apply.c | 8 +++++---
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/apply.c b/builtin/apply.c
> index 84a8a0b..2d6862a 100644
> --- a/builtin/apply.c
> +++ b/builtin/apply.c
> @@ -3596,9 +3596,6 @@ static int write_out_results(struct patch *list, int skipped_patch)
> int errs = 0;
> struct patch *l;
>
> - if (!list && !skipped_patch)
> - return error("No changes");
> -
I think write_out_results() can lose the skipped_patch parameter now.
> for (phase = 0; phase < 2; phase++) {
> l = list;
> while (l) {
> @@ -3741,6 +3738,11 @@ static int apply_patch(int fd, const char *filename, int options)
> !apply_with_reject)
> exit(1);
>
> + if (!list && !skipped_patch) {
> + error("No changes");
> + exit(1);
You can use die() instead of error followed by exit.
Also, I don't see any reason why this check shouldn't be moved up so
that it is performed immediately after the while loop, avoiding any
unnecessary work.
btw. die'ing like this affects diffstat, numstat, summary etc. too
since now they will report an error instead of just displaying an
informational message describing zero changes when passed a bogus
patch. But that seems correct to me.
I would have also suggested changing the error message to something
more descriptive than "No changes", but apparently apply is a plumbing
command. It seems kind of an "in-between plumbing and porcelain"
command.
It still seems like the correct behavior change with respect to
diffstat, numstat et al that I mentioned above after rethinking from a
plumbing perspective. git apply should error out if it cannot
recognize its input.
-Brandon
^ permalink raw reply
* Infinite loop in cascade_filter_fn()
From: Henrik Grubbström @ 2011-11-23 17:40 UTC (permalink / raw)
To: Git Mailing list; +Cc: Junio C Hamano
[-- Attachment #1: Type: TEXT/PLAIN, Size: 689 bytes --]
Hi.
My git repository walker just got bitten by what seems to be a reasonably
new bug in convert.c:cascade_filter_fn() (git 1.7.8.rc3 (gentoo)).
How to reproduce:
git clone git@github.com:pikelang/Pike.git
git checkout -f 0e2080f838c6f0bc7d670ac7549676a353451dca^
git checkout -f 0e2080f838c6f0bc7d670ac7549676a353451dca
The first two commands complete as expected, while the last hangs forever.
Performing the same with git 1.7.6.4 works as expected.
The problematic file seems to be /src/modules/_Crypto/rijndael_ecb_vt.txt
which has the attributes: text ident eol=crlf
Thanks,
--
Henrik Grubbström grubba@grubba.org
Roxen Internet Software AB grubba@roxen.com
^ permalink raw reply
* Re: [PATCH] revert: do not pass non-literal string as format to git_path()
From: Junio C Hamano @ 2011-11-23 17:29 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1322052336-13619-1-git-send-email-pclouds@gmail.com>
Thanks.
^ permalink raw reply
* Re: git not resuming push
From: Paul Brossier @ 2011-11-23 17:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmxbncq5v.fsf@alter.siamese.dyndns.org>
ok, that, with a bit of patience, should help!
thank you both for your answers,
piem
On 22/11/2011 23:24, Junio C Hamano wrote:
> Jeff King<peff@peff.net> writes:
>
>> On Tue, Nov 22, 2011 at 08:58:56PM -0700, Paul Brossier wrote:
>>
>>> If the connection fails after uploading part of the data, it seems I
>>> need to start over from zero again. Is there a way to resume the upload
>>> instead?
>>
>> No, there isn't a way to resume just using push.
>>
>> If you have shell access on the server, one workaround you can do is to
>> create a bundle with the commits in question, upload it via some
>> resumable protocol (like sftp, http, rsync, etc), possibly taking many
>> attempts, and then fetch the result on the server side from the bundle
>> into the repository.
>>
>> See "git help bundle" for some examples.
>
> Another possibility, if it is the connection between you and the other
> side that is the problem, is to chunk your push in smaller pieces. That
> is, if you are trying to push out v3.0, you first push only to v1.0, then
> to v2.0, and then finally to v3.0.
>
> Peff, by the way, wouldn't this request reminds of us of a scenario we
> discussed recently, which I said I would imagine would be common while you
> dismissed as not likely to be common?
>
>
^ permalink raw reply
* Re: [PATCH] Fix revert --abort on Windows
From: Alex Riesen @ 2011-11-23 17:23 UTC (permalink / raw)
To: Johannes Sixt
Cc: Jonathan Nieder, Junio C Hamano, Ramkumar Ramachandra, git,
Christian Couder, Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <4ECCB3A2.5030102@viscovery.net>
On Wed, Nov 23, 2011 at 09:49, Johannes Sixt <j.sixt@viscovery.net> wrote:
> From: Johannes Sixt <j6t@kdbg.org>
>
> On Windows, it is not possible to rename or remove a directory that has
> open files. 'revert --abort' renamed .git/sequencer when it still had
> .git/sequencer/head open. Close the file as early as possible to allow
> the rename operation on Windows.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> I guess it's too late to squash this in. ;)
>
Just made a patch for this of my own (noticed it on Cygwin), should have
looked in the archives first. Thanks!
The minority platforms can wait, I guess :)
^ permalink raw reply
* Re: [ANN] SubGit Early Access Program Build #789
From: Semen Vadishev @ 2011-11-23 17:19 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: jgit-dev, EGit developer discussion, Git Mailing List
In-Reply-To: <4ECCB6C6.8040200@op5.se>
Hello Andreas,
> How does it handle merges?
The short answer is
1. git to svn: SubGit sets svn:mergeinfo accordingly to
the history of merged parent(s).
2. git to svn: SubGit checks whether modified svn:mergeinfo includes
the history of a certain branch, if so it adds this branch as a merge
parent.
For more details please refer to
http://subgit.com/documentation/spec/merge.pdf — it's a part of SubGit
specification related to the merge-tracking stuff.
Semen Vadishev,
TMate Software,
http://subgit.com/ - Two Way Ticket to The Dark Side
On 23 November 2011 10:03, Andreas Ericsson wrote:
> On 11/22/2011 08:15 PM, Semen Vadishev wrote:
>> Hello All,
>>
>> Let me introduce our new project: SubGit (http://subgit.com/).
>>
>> SubGit is a tool for smooth migration from Subversion to Git. As well as
>> from Git to Subversion. Without git-svn insanity.
>>
>> It works like this:
>>
>> - Install SubGit into your repository on the server side
>>
>> - Let initial translation complete (time depends on the size of repository)
>>
>> - SubGit installs hooks into repository, so it translates every svn
>> revision and git commit
>>
>> - Committers may now use either Git or Subversion (or both) with the
>> tools of their choice
>>
> How does it handle merges?
>
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Junio C Hamano @ 2011-11-23 17:16 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <CACsJy8A7HVe8kLR5j9Ej0tJhpkxigCXRqpg9DvE9qJsfengi1Q@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Mon, Nov 21, 2011 at 10:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> In the medium term, I think one reasonable way forward solving the "TODO
>> that used to be tracked but now untracked and ignored" issue is to
>> introduce "info/exclude-override" that comes between command line and
>> in-tree patterns. The info/exclude file is designed as the fallback
>> definition to be used when all other sources are too lax, and comes near
>> the precedence stack; the "TODO" situation however calls for an override
>> that is stronger than the in-tree patterns.
>
> "info/precious" might be a better name
The above is only about the precedence order and is not about introducing
the new "precious" class at all.
>> In the longer term, we should carefully determine if we need "precious" in
>> the first place. The last time this was brought up there were people who
>> argued they are OK with having to remove the ignored file by hand when
>> checking out another branch (i.e. we switch the semantics of "ignored" so
>> that they are "not tracked but all precious").
>>
>> I think it matters in two cases.
>>
>> (1) If you change an untracked "cruft" file on branch A into a directory
>> with tracked files in it on another branch B. If you are on branch A,
>> have that "cruft" file (perhaps it is a build product after running
>> "make"), and try to checkout branch B, such an updated "git checkout"
>> will start erroring out telling you that "cruft" will be lost.
>>
>> (2) If you have a directory on branch A, underneath of which there are
>> untracked "cruft" files (e.g. think "build/" directory that is full
>> of "*.o" files and ".gitignore" to mark object files as ignored but
>> is otherwise empty), and another branch B that has the same path as a
>> file. If you are on branch A, have "cruft" files in that directory,
>> and try to checkout branch B, such an updated "git checkout" will
>> start erroring out telling you that "cruft" will be lost.
>
> I think we should do this regardless precious being added or not.
Because (see below)?
>> If people are OK with such a behaviour, we can do without "precious".
>
> What about git-clean to remove ignored but not precious files?
"clean" without -x is a way to remove untracked and not ignored files,
i.e. remove "test.c", "trash-patch", "notes" that are not part of the
sources but were crufts you hand generated during your development process
that you do not need, without removing build products such as "main.o". If
we switch the semantics of "ignored" from "untracked and is expendable for
the purpose of checking out another conflicting branch" to "untracked but
is not expendable", it is clear that it should not remove them.
"clean -x" is more subtle. It has been a way to say "Remove cruft the
usual way, and in addition, remove the expendable build products, just
like 'make clean' _should_ do, but I do not trust my Makefile". If we
introduced "precious", it would be very clear what it should do---even
with "-x" precious files should be kept. But if we don't and just try to
get away by changing the semantics of "ignored", they will still need to
be removed, so we won't really get the "precious".
The conclusion from this is that it is a mistake to change the semantics
of "ignored" from the current "untracked and expendable if needed" if the
purpose of that change is to avoid introducing the new "precious" class.
I don't care too much about it, as I do not use "git clean -x" myself ;-)
but that wouldn't stop others from think about the issue and try to come
up with a good solid design.
> Or do excluded() twice, the first time to check for precious files,
> the second for all ignored rules. Callers are changed anyway, but this
> way git-add for example will be untouched because it does not care
> about precious stuff. Only unpack-trees and maybe git-clean are
> changed.
I don't think we want to go there, as it will encourage different
codepaths doing different things without a good reason. Having to add
ignore source manually in different codepaths was the real cause of the
inconsistency bug around info/exclude vs .gitignore we discussed earlier.
^ permalink raw reply
* Re: Git ticket / issue tracking ERA: Git shouldn't allow to push a new branch called HEAD
From: Junio C Hamano @ 2011-11-23 17:02 UTC (permalink / raw)
To: Frans Klaver
Cc: Paolo Ciarrocchi, Daniele Segato, Git Mailing List, Jeff King,
Scott Chacon
In-Reply-To: <CAH6sp9OXzHj=r707zyRQxaJmndHm5_DcWWMLn_1zyLdEZ_TSbA@mail.gmail.com>
Frans Klaver <fransklaver@gmail.com> writes:
>> But that's the only repo mentioned in the git-scm home page.
>
> The note from the maintainer[1] mentions
>
> git://git.kernel.org/pub/scm/git/git.git/
> git://repo.or.cz/alt-git.git
> https://github.com/git/git
> https://code.google.com/p/git-core/
>
> I would assume one of those would be a nomination for 'official' repo.
>
> Maybe something for Scott C. to address?
As long as the link says "Git source repository" without "the official",
Scott is doing the right thing. It is just one of the copies that I push
into, so it may be considered more official than a fork of my history by a
random unknown person.
As Git is distributed, we do not need a single "official" repository. If
you really want to name one, my private working repository at my home
machine would be what is closest to one, as patches and pull requests are
processed there and then the result is pushed out to the above four and a
few others. But that "official" one is not exposed to the outside world ;-)
^ permalink raw reply
* [PATCH] git-apply: fix rubbish handling in --check case
From: Artem Bityutskiy @ 2011-11-23 16:26 UTC (permalink / raw)
To: git; +Cc: Artem Bityutskiy
In-Reply-To: <1322065563-3651-1-git-send-email-dedekind1@gmail.com>
From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
This patch fixes the following inconsistency:
Let's take my bash binary.
$ ls -l /bin/bash
-rwxr-xr-x. 1 root root 924200 Jun 22 16:49 /bin/bash
$ file /bin/bash
/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
Let's try to apply it
$ git apply /bin/bash
error: No changes
$ echo $?
1
Good, rejected and error code is returned. Let's try with --check:
$ git apply --check /bin/bash
$ echo $?
0
Not exactly what I expected :-) The same happnes if you use an empty file.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
---
Note, I did not extensively test it!
Makefile | 2 +-
builtin/apply.c | 8 +++++---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 84a8a0b..2d6862a 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3596,9 +3596,6 @@ static int write_out_results(struct patch *list, int skipped_patch)
int errs = 0;
struct patch *l;
- if (!list && !skipped_patch)
- return error("No changes");
-
for (phase = 0; phase < 2; phase++) {
l = list;
while (l) {
@@ -3741,6 +3738,11 @@ static int apply_patch(int fd, const char *filename, int options)
!apply_with_reject)
exit(1);
+ if (!list && !skipped_patch) {
+ error("No changes");
+ exit(1);
+ }
+
if (apply && write_out_results(list, skipped_patch))
exit(1);
--
1.7.6.4
^ permalink raw reply related
* [PATCH] git-apply: fix rubbish handling in --check case
From: Artem Bityutskiy @ 2011-11-23 16:26 UTC (permalink / raw)
To: git; +Cc: Artem Bityutskiy
From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
This patch fixes the following inconsistency:
Let's take my bash binary.
$ ls -l /bin/bash
-rwxr-xr-x. 1 root root 924200 Jun 22 16:49 /bin/bash
$ file /bin/bash
/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
Let's try to apply it
$ git apply /bin/bash
error: No changes
$ echo $?
1
Good, rejected and error code is returned. Let's try with --check:
$ git apply --check /bin/bash
$ echo $?
0
Not exactly what I expected :-) The same happnes if you use an empty file.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
---
Note, I did not extensively test it!
Makefile | 2 +-
builtin/apply.c | 8 +++++---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 84a8a0b..2d6862a 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3596,9 +3596,6 @@ static int write_out_results(struct patch *list, int skipped_patch)
int errs = 0;
struct patch *l;
- if (!list && !skipped_patch)
- return error("No changes");
-
for (phase = 0; phase < 2; phase++) {
l = list;
while (l) {
@@ -3741,6 +3738,11 @@ static int apply_patch(int fd, const char *filename, int options)
!apply_with_reject)
exit(1);
+ if (!list && !skipped_patch) {
+ error("No changes");
+ exit(1);
+ }
+
if (apply && write_out_results(list, skipped_patch))
exit(1);
--
1.7.6.4
^ permalink raw reply related
* Re: Git ticket / issue tracking ERA: Git shouldn't allow to push a new branch called HEAD
From: Frans Klaver @ 2011-11-23 15:47 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Junio C Hamano, Daniele Segato, Git Mailing List, Jeff King,
Scott Chacon
In-Reply-To: <CAHVLzc=SPD+AHhAPP_=mEVv5cJvn0oiJ_k-KBEkG=Qhcw2UxHA@mail.gmail.com>
On Wed, Nov 23, 2011 at 2:44 PM, Paolo Ciarrocchi
<paolo.ciarrocchi@gmail.com> wrote:
> On Tue, Nov 22, 2011 at 8:41 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Daniele Segato <daniele.bilug@gmail.com> writes:
>>
>>> [1] according to http://git-scm.com/ the link on "Git source repository"
>>> is https://github.com/gitster/git
>>
>> That one is as official as anybody's "git clone" from many of the
>> distribution points.
>>
>> I do not see any reason to name an official repository, but if I were
>> pressed, that copy at github is not the one I would nominate.
>
> But that's the only repo mentioned in the git-scm home page.
The note from the maintainer[1] mentions
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git
https://github.com/git/git
https://code.google.com/p/git-core/
I would assume one of those would be a nomination for 'official' repo.
Maybe something for Scott C. to address?
Cheers,
Frans
[1] http://article.gmane.org/gmane.comp.version-control.git/184174
^ permalink raw reply
* git-bisect working only from toplevel dir
From: Adam Borowski @ 2011-11-23 14:50 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 487 bytes --]
Hi!
The requirement to be in the toplevel directory when calling git-bisect is
pretty infuriating. I tried to find an explanation for this, and the only
reference I found was:
http://thread.gmane.org/gmane.comp.version-control.git/27524/focus=27596
However, since then, git-reset has been changed (in a81c311f). What about
changing git-bisect as well?
A trivial patch seems to work for me, but I might have missed some corner
case.
--
1KB // Yo momma uses IPv4!
[-- Attachment #1.2: 0001-git-bisect-allow-using-it-from-a-subdirectory.patch --]
[-- Type: text/x-diff, Size: 740 bytes --]
From 1dd5dda6a9db3d987e15784c4de24e593cc596e0 Mon Sep 17 00:00:00 2001
From: Adam Borowski <kilobyte@angband.pl>
Date: Wed, 23 Nov 2011 15:08:42 +0100
Subject: [PATCH] git-bisect: allow using it from a subdirectory.
Just like git-reset, restricting it to toplevel is an annoyance, and the
latter has been changed in a81c311f.
---
git-bisect.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 99efbe8..fd6ccdd 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -27,6 +27,7 @@ git bisect run <cmd>...
Please use "git help bisect" to get the full man page.'
OPTIONS_SPEC=
+SUBDIRECTORY_OK=Yes
. git-sh-setup
. git-sh-i18n
--
1.7.8.rc3.31.g017d1
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply related
* Re: Git ticket / issue tracking ERA: Git shouldn't allow to push a new branch called HEAD
From: Paolo Ciarrocchi @ 2011-11-23 13:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniele Segato, Git Mailing List, Jeff King
In-Reply-To: <7vd3ckdjx9.fsf@alter.siamese.dyndns.org>
On Tue, Nov 22, 2011 at 8:41 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Daniele Segato <daniele.bilug@gmail.com> writes:
>
>> [1] according to http://git-scm.com/ the link on "Git source repository"
>> is https://github.com/gitster/git
>
> That one is as official as anybody's "git clone" from many of the
> distribution points.
>
> I do not see any reason to name an official repository, but if I were
> pressed, that copy at github is not the one I would nominate.
But that's the only repo mentioned in the git-scm home page.
Regards,
Paolo
^ permalink raw reply
* Re: [PATCH] run-command.c: Accept EACCES as command not found
From: Frans Klaver @ 2011-11-23 13:25 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <CACsJy8ATJ33i5YaM-APtUPq_fDkj9=JpKj9pmvqWK2QodgbexQ@mail.gmail.com>
On Wed, Nov 23, 2011 at 1:04 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> If you print diagnostic messages with trace_printf() and friends (only
> showed when GIT_TRACE variable is set), then there's no need for being
> terse.
I'll keep that in mind, thanks.
Frans
^ permalink raw reply
* [PATCH] revert: do not pass non-literal string as format to git_path()
From: Nguyễn Thái Ngọc Duy @ 2011-11-23 12:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
This fixes the following warning.
CC builtin/revert.o
builtin/revert.c: In function ‘write_cherry_pick_head’:
builtin/revert.c:311: warning: format not a string literal and no format arguments
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/revert.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 0c61668..9b9b2e5 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -308,7 +308,7 @@ static void write_cherry_pick_head(struct commit *commit, const char *pseudoref)
strbuf_addf(&buf, "%s\n", sha1_to_hex(commit->object.sha1));
- filename = git_path(pseudoref);
+ filename = git_path("%s", pseudoref);
fd = open(filename, O_WRONLY | O_CREAT, 0666);
if (fd < 0)
die_errno(_("Could not open '%s' for writing"), filename);
--
1.7.4.74.g639db
^ permalink raw reply related
* Incremental use of fast-import may cause conflicting notes
From: Henrik Grubbström @ 2011-11-23 12:09 UTC (permalink / raw)
To: Git Mailing list; +Cc: Johan Herland, Jonathan Nieder
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1318 bytes --]
Hi.
Background: I have an incremental repository-walker creating a
corresponding documentation repository from a source repository
that uses git-notes to store its state, a use for which notes
seem very suitable.
Problem: When the number of notes in the root of the notes branch
increases beyond a threshold, fast-import changes the fanout. This
is as designed, but the problem is that when fast-import is restarted
it won't remember the fanout, and will start writing files in the root
again. This means that there may be multiple notes-files for the same
commit, eg both de/adbeef and deadbeef.
This is not what the user expects, and is not good practice, even if it in
this case actually works, since the latter is defined to have priority.
I'm however not sure if eg fast_import.c:do_change_note_fanout() will do
the right thing if/when the fanout is changed again.
The problem is probably due to b->num_notes not being initialized properly
when the old non-empty root commit for the notes branch is loaded in
parse_from()/parse_new_commit().
My workaround for now is to use filedeleteall and restore all the notes
by hand in the first new commit on the notes branch.
Version of git: 1.7.6.4 (gentoo)
Thanks,
--
Henrik Grubbström grubba@grubba.org
Roxen Internet Software AB grubba@roxen.com
^ permalink raw reply
* Re: Incremental use of fast-import may cause conflicting notes
From: Henrik Grubbström @ 2011-11-23 12:10 UTC (permalink / raw)
To: Git Mailing list; +Cc: Johan Herland, Jonathan Nieder
In-Reply-To: <Pine.GSO.4.63.1111231137350.5099@shipon.roxen.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1437 bytes --]
On Wed, 23 Nov 2011, Henrik Grubbström wrote:
> Hi.
>
> Background: I have an incremental repository-walker creating a corresponding
> documentation repository from a source repository
> that uses git-notes to store its state, a use for which notes
> seem very suitable.
>
> Problem: When the number of notes in the root of the notes branch
> increases beyond a threshold, fast-import changes the fanout. This is as
> designed, but the problem is that when fast-import is restarted
> it won't remember the fanout, and will start writing files in the root again.
> This means that there may be multiple notes-files for the same commit, eg
> both de/adbeef and deadbeef.
>
> This is not what the user expects, and is not good practice, even if it in
> this case actually works, since the latter is defined to have priority.
> I'm however not sure if eg fast_import.c:do_change_note_fanout() will do the
> right thing if/when the fanout is changed again.
>
> The problem is probably due to b->num_notes not being initialized properly
> when the old non-empty root commit for the notes branch is loaded in
> parse_from()/parse_new_commit().
>
> My workaround for now is to use filedeleteall and restore all the notes
> by hand in the first new commit on the notes branch.
>
> Version of git: 1.7.6.4 (gentoo)
Oops, wrong machine... 1.7.8.rc3 (gentoo)
> Thanks,
--
Henrik Grubbström grubba@roxen.com
Roxen Internet Software AB
^ permalink raw reply
* Re: [PATCH] run-command.c: Accept EACCES as command not found
From: Nguyen Thai Ngoc Duy @ 2011-11-23 12:04 UTC (permalink / raw)
To: Frans Klaver; +Cc: Junio C Hamano, git
In-Reply-To: <CAH6sp9N2ycsoU=is3BVanH33CowD+sMNmWq=Z1MsPJX=HGYY+g@mail.gmail.com>
On Wed, Nov 23, 2011 at 3:17 PM, Frans Klaver <fransklaver@gmail.com> wrote:
> If there are no objections, I'm going to cook up a patch that
>
> - Keeps the current behavior (bail on EACCES)
> - Adds a more helpful diagnostic message somewhat like libexplain's,
> but more terse and if possible with slightly more domain knowledge
If you print diagnostic messages with trace_printf() and friends (only
showed when GIT_TRACE variable is set), then there's no need for being
terse.
--
Duy
^ permalink raw reply
* Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Nguyen Thai Ngoc Duy @ 2011-11-23 12:02 UTC (permalink / raw)
To: Philippe Vaucher; +Cc: git
In-Reply-To: <CAGK7Mr4GZq5eXn4OB+B0ZborX-OVoXiWU8Lo1XM5LRZDuRe1YA@mail.gmail.com>
On Wed, Nov 23, 2011 at 3:28 PM, Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:
> Hello,
>
> A lot of time when I want to use reset for smth else than "--hard" I
> have to go and look the documentation.
May be related: http://thread.gmane.org/gmane.comp.version-control.git/170266
--
Duy
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Nguyen Thai Ngoc Duy @ 2011-11-23 11:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <7vk46th5bz.fsf@alter.siamese.dyndns.org>
On Mon, Nov 21, 2011 at 10:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> In the medium term, I think one reasonable way forward solving the "TODO
> that used to be tracked but now untracked and ignored" issue is to
> introduce "info/exclude-override" that comes between command line and
> in-tree patterns. The info/exclude file is designed as the fallback
> definition to be used when all other sources are too lax, and comes near
> the precedence stack; the "TODO" situation however calls for an override
> that is stronger than the in-tree patterns.
"info/precious" might be a better name
> In the longer term, we should carefully determine if we need "precious" in
> the first place. The last time this was brought up there were people who
> argued they are OK with having to remove the ignored file by hand when
> checking out another branch (i.e. we switch the semantics of "ignored" so
> that they are "not tracked but all precious").
>
> I think it matters in two cases.
>
> (1) If you change an untracked "cruft" file on branch A into a directory
> with tracked files in it on another branch B. If you are on branch A,
> have that "cruft" file (perhaps it is a build product after running
> "make"), and try to checkout branch B, such an updated "git checkout"
> will start erroring out telling you that "cruft" will be lost.
>
> (2) If you have a directory on branch A, underneath of which there are
> untracked "cruft" files (e.g. think "build/" directory that is full
> of "*.o" files and ".gitignore" to mark object files as ignored but
> is otherwise empty), and another branch B that has the same path as a
> file. If you are on branch A, have "cruft" files in that directory,
> and try to checkout branch B, such an updated "git checkout" will
> start erroring out telling you that "cruft" will be lost.
I think we should do this regardless precious being added or not.
> If people are OK with such a behaviour, we can do without "precious".
What about git-clean to remove ignored but not precious files?
> Otherwise we would need to update excluded() in dir.c to return tristate
> (ignored, precious or unspecified) instead of the current boolean (ignored
> or unspecified), examine and decide for each caller what they want to do
> to "precious" files.
Or do excluded() twice, the first time to check for precious files,
the second for all ignored rules. Callers are changed anyway, but this
way git-add for example will be untouched because it does not care
about precious stuff. Only unpack-trees and maybe git-clean are
changed.
--
Duy
^ permalink raw reply
* Re: git reset --merge documentation improvments
From: Philippe Vaucher @ 2011-11-23 11:39 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: git
In-Reply-To: <4ECCB565.9020706@lyx.org>
>> "Updates the files in the working tree that are different between
>> <commit> and HEAD, but keeps those which are different between the
>> index and working tree, and finally resets the index."
>
> There is nothing to update as long as the index is not reset.
Well then I simply don't understand what --merge does. Is it like
--keep but instead of failing when a file-to-be-overwritten has
changes it simply ignores the overwriting and continues?
Philippe
^ permalink raw reply
* Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Philippe Vaucher @ 2011-11-23 11:32 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq4nxvusty.fsf@bauges.imag.fr>
>> Optional: a new mode would be introduced for consistency:
>> --worktree (or maybe --tree): only updates the worktree but not the index
>
> That would be an alias for "git checkout <rev> -- path", right?
Hum... yeah probably, what motivated me was that there's a way to
reset the index and not the worktree, but there's no way to reset the
worktree but not the index. I guess it's "checkout" as you pointed
out.
>> --keep could be removed in favor of an additional --safe flag
>
> If you are to change the option names, then you should also make the
> behavior safe by default:
>
> * "git reset --all" = "git reset --keep"
> * "git reset --all --force" = "git reset --hard"
Yes that's actually much better. Let's change my proposal to that.
Philippe
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Nguyen Thai Ngoc Duy @ 2011-11-23 11:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <7vfwhhgzcb.fsf@alter.siamese.dyndns.org>
On Tue, Nov 22, 2011 at 12:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> It dated back to f8a9d42 (read-tree: further loosen "working file will
>> be lost" check. - 2006-12-04) when you introduced --exclude-per-directory
>> to read-tree, but not --exclude-from to explicitly add .git/info/exclude.
>
> That one together with 1127148 (Loosen "working file will be lost" check
> in Porcelain-ish, 2006-12-04) complets the picture. Thanks for digging
> this out.
>
>> I guess it's time to add "read-tree --exclude-from".
>
> Perhaps, also --exclude-standard to match?
Yep, will do.
--
Duy
^ permalink raw reply
* Re: Feature requset: listing of current stash in git gui
From: Stefan Näwe @ 2011-11-23 11:24 UTC (permalink / raw)
To: David Aguilar; +Cc: dexen deVries, git@vger.kernel.org
In-Reply-To: <CAJDDKr78CV+eDrfSg4Tqp5W2N4MDTaqAcxiB5JrNpUyEn5vqAQ@mail.gmail.com>
Am 23.11.2011 12:20, schrieb David Aguilar:
> On Tue, Nov 22, 2011 at 7:19 AM, Stefan Näwe
> <stefan.naewe@atlas-elektronik.com> wrote:
>> Am 22.11.2011 11:24, schrieb David Aguilar:
>>>
>>> git-cola has this feature.
>>>>
>>>
>>> http://git-cola.github.com/
>>
>> Yeah, right. I totally forgot about git cola.
>>
>> But I guess there's no way of starting only the stash view like the 'DAG'
>> view, is there ?
>
> That's a good idea.
>
> https://github.com/git-cola/git-cola/commit/0b1bf59c0b4a455cc8a9149dcfcafb5bed3a19ab
>
> git cola stash
> git cola classic
> (and a few others)
> ...
Perfetto!
Stefan
--
----------------------------------------------------------------
/dev/random says: Thesaurus: ancient reptile with an excellent vocabulary.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox