* 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: 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
* 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
* [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
* 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
* 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
* 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: 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
* [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
* [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
* 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
* 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: [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] 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: 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] 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
* 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] 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
* 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: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Junio C Hamano @ 2011-11-23 18:51 UTC (permalink / raw)
To: Philippe Vaucher; +Cc: git, Christian Couder
In-Reply-To: <CAGK7Mr4GZq5eXn4OB+B0ZborX-OVoXiWU8Lo1XM5LRZDuRe1YA@mail.gmail.com>
Philippe Vaucher <philippe.vaucher@gmail.com> writes:
> So if I recap my ideas:
>
> "I want to discard my changes" --> git reset --all HEAD^
That is discarding your changes and also the last commit.
> "I want to discard the last commit" --> git reset --index HEAD^
I do not think this has a clear meaning. "discard the last commit but
leave the contents in the working tree. I do not care a newly added files
are forgotten by the index, I'll remember to re-add them if I need to" is
what you are saying here, but the word "index" does not hint it. When
used as an option name, "--index" means "this command usually works on or
touches working tree but for this invocation please also affect the index";
"please look at or affect _only_ the index" is usually spelled "--cached".
In any case, I think your proposal makes it even worse than the current
state, and you should aim higher. Some modes of "git reset" have
historical reasoning behind their behaviour that cannot be dismissed
easily by somebody who does not understand them, but at the same time some
of them outlived their usefulness and we may want to start thinking about
deprecating them. The first step might be to make them less prominent in
the documentation.
I am guilty of introducing "git reset --soft HEAD^" before I invented
"commit --amend" during v1.3.0 timeframe to solve the issue "soft" reset
originally wanted to. Even though the whole point of the "reset" command
is about "resetting the index", it is an unfortunate oddball that does not
touch the index. It shouldn't have been part of the "reset" command, and
if we were doing Git from scratch today, we probably wouldn't have it
there. What it does is sometimes useful in interactive use and often
useful in scripting, but scripts can use update-ref.
"git reset --hard HEAD" is an unambiguously descriptive good name for the
option. It is a "hard reset" like power cycling a machinery to discard
anything in progress and get back to a clean slate. I do not see anything
confusing with this mode nor its name.
"git reset --keep" was introduced at 9bc454d (reset: add option "--keep"
to "git reset", 2010-01-19) as a short-hand to run something like this.
git checkout -B $current_branch $target_commit
If we made the above command line to work (it errors out saying you cannot
update the current branch) instead of adding it a new mode to "reset", it
would have been much easier to understand what the particular operation
does. You are updating the tip of the branch that happens to be the
current branch to a different commit while carrying the local change with
you.
It also would have made number of options "reset" has smaller by one and
reducing confusion. What it does is too similar to what "reset --merge"
does, which only adds to the confusion.
^ permalink raw reply
* Re: Possible bug with branch names and case sensitivity
From: Junio C Hamano @ 2011-11-23 18:59 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Jay Soffian, Gerd Knops, git
In-Reply-To: <4ECCBB3D.7070204@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 11/22/2011 06:49 PM, Junio C Hamano wrote:
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>> Currently git handles references names case-sensitively and allows
>>> multiple reference names that differ only in case.
>>
>> We do the same for in-tree paths, by the way. Ultimately, I think the
>> sane thing to do is to appeal to the user's common sense. [...common
>> sense aka "if it hurts don't do it" omitted...]
>>
>> I think refnames have exactly the same issue. In theory, you could have
>> "Master" and "master" branches, and nothing stops you from trying to do
>> so, but in practice, if it is not useful for you and your project, and
>> if it is equally fine to use some other name instead of "Master" for the
>> purpose of you and your project, then there is no strong reason for doing
>> so, unless you are trying to irritate users on case folding platforms.
>
> I agree.
>
> But git could nevertheless help users (1) by providing config settings
> or hook scripts or something that could be configured in a repository to
> prevent case-conflicts from entering the project history; (2) by
> emitting an error when such a conflict arises rather than getting so
> confused.
Yeah, and you didn't have to say "But"; we are in agreement (see my other
message in response to the same message from you).
^ permalink raw reply
* Re: git-bisect working only from toplevel dir
From: Junio C Hamano @ 2011-11-23 19:09 UTC (permalink / raw)
To: Adam Borowski; +Cc: git
In-Reply-To: <20111123145034.GB17927@angband.pl>
Adam Borowski <kilobyte@angband.pl> writes:
> 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
Interesting. It used to be that people were thankful when a command
happened to work from a subdirectory, and it was a minor irritation when
some command didn't; in the early days, everything in Git was to be used
from the top-legvel.
> 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.
Thanks; read and follow Documentation/SubmittingPatches the next time
perhaps?
As to the approach, I suspect that it would be far better if it made
workable with cd_to_toplevel at the beginning, instead of saying
SUBDIRECTORY_OK.
After all, the current directory may disappear during the course of
bisection, upon checking out a revision that did not have the directory
you started your bisection from.
>
> --
> 1KB // Yo momma uses IPv4!
>
> 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
^ permalink raw reply
* Re: git-bisect working only from toplevel dir
From: Jeff King @ 2011-11-23 19:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Borowski, git
In-Reply-To: <7vd3cibqqe.fsf@alter.siamese.dyndns.org>
On Wed, Nov 23, 2011 at 11:09:29AM -0800, Junio C Hamano wrote:
> As to the approach, I suspect that it would be far better if it made
> workable with cd_to_toplevel at the beginning, instead of saying
> SUBDIRECTORY_OK.
>
> After all, the current directory may disappear during the course of
> bisection, upon checking out a revision that did not have the directory
> you started your bisection from.
But from what directory would you expect:
git bisect run make
to run from? If you use a GNU-ish layout with all of your code in
"src/", then I can see it useful to do something like:
cd src
git bisect run make
If we cd_to_toplevel, we can remember the prefix that we started from
and cd to it before running the user's command, but there is no
guarantee that it actually exists. Maybe that commit should be
considered indeterminate then?
I dunno. I haven't thought that hard about it. But I don't think it's
quite as simple as just telling bisect it's OK to run from a subdir.
-Peff
^ permalink raw reply
* svn to git with non-standard layout
From: Bernd Schubert @ 2011-11-23 19:23 UTC (permalink / raw)
To: git
Hi all,
we just want to migrate from subversion to git, but so far all attempts
to do that resulted in missing commit information.
So we have an svn repo with multiple sub-repos. The trouble is now that
those sub-repos have their own trunk/tags (no branches) directories, but
actually those projects are very dependent on each other and lots of
commits go to many sub-project in a single commit.
So our new git repository shall meld all sub-projects into a new common
repository.
So we have something like this:
svn-root -> main-project
/ | \
/ | \
proj1 proj2 proj{n}
/ \ / \ / \
/ \ / \ trunk tags
/ \ trunk tags
trunk tags
/ \
tag1 tag{2...n}
I think the same issue has been asked a few times before, for example here:
http://comments.gmane.org/gmane.comp.version-control.git/163491
but I still do not know how to properly convert the old structure into a
new global one. So we simply want to have:
branches,tags <- main-project -> {proj1, proj2, ..., projN}
I think the above link suggests something like
[svn-remote "svn"]
url = https://some-repo-url
fetch=/:refs/remotes/svnroot
fetch = build_scripts/trunk:refs/remotes/build_scripts/trunk
fetch = create_repos/trunk:refs/remotes/create_repos/trunk
When I'm going to to 'svn fetch' this, files from different projects are
going to be in the same directory. But of course, the project directory
structure is supposed to stay as it it.
Any ideas what I still could try to do?
Thanks,
Bernd
^ permalink raw reply
* Re: git-bisect working only from toplevel dir
From: Adam Borowski @ 2011-11-23 20:09 UTC (permalink / raw)
To: git
In-Reply-To: <20111123192329.GA21630@sigill.intra.peff.net>
On Wed, Nov 23, 2011 at 02:23:29PM -0500, Jeff King wrote:
> On Wed, Nov 23, 2011 at 11:09:29AM -0800, Junio C Hamano wrote:
>
> > As to the approach, I suspect that it would be far better if it made
> > workable with cd_to_toplevel at the beginning, instead of saying
> > SUBDIRECTORY_OK.
> >
> > After all, the current directory may disappear during the course of
> > bisection, upon checking out a revision that did not have the directory
> > you started your bisection from.
No different from git-reset or git-checkout.
>
> But from what directory would you expect:
>
> git bisect run make
>
> to run from? If you use a GNU-ish layout with all of your code in
> "src/",
In a vast majority of cases the layout remains constant during the whole
bisection.
> then I can see it useful to do something like:
>
> cd src
> git bisect run make
>
> If we cd_to_toplevel, we can remember the prefix that we started from
> and cd to it before running the user's command, but there is no
> guarantee that it actually exists.
I guess, the best that can be done is going into as many path components as
possible.
> Maybe that commit should be considered indeterminate then?
Why? If you're running an automated command, then it will probably fail,
yeah. I guess most people bisect manually though, so even in repositories
that do have this problem, there's someone who can test the given commit
anyway.
> I dunno. I haven't thought that hard about it. But I don't think it's
> quite as simple as just telling bisect it's OK to run from a subdir.
At the very least, generally working with a caveat in corner cases seems to
be better than outright failing.
If you're paranoid, there's an option of having a config setting "yes, I've
read the manual why automated bisection can fail".
--
1KB // Yo momma uses IPv4!
^ 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