* 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
* Re: Feature requset: listing of current stash in git gui
From: David Aguilar @ 2011-11-23 11:20 UTC (permalink / raw)
To: Stefan Näwe; +Cc: dexen deVries, git@vger.kernel.org
In-Reply-To: <4ECBBD72.40101@atlas-elektronik.com>
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)
...
--
David
^ permalink raw reply
* Re: [PATCH] Fix revert --abort on Windows
From: Johannes Sixt @ 2011-11-23 10:21 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <20111123100452.GA30629@elie.hsd1.il.comcast.net>
Am 11/23/2011 11:04, schrieb Jonathan Nieder:
> ... "git reset --merge <commit>" renames the
> .git/sequencer directory as a secondary effect --- after moving to
> <commit>, or so the logic goes, it is unlikely but possible that the
> caller of git reset wants to continue the series of cherry-picks that
> was in progress, so git renames the sequencer state to
> .git/sequencer-old to be helpful while allowing the cherry-pick to be
> resumed if the caller did not want to end the sequence after all.
> ...
> By the way, as the length of [this paragraph] might
> have hinted, I am not convinced that allowing "git reset --hard" as an
> escape route from a cherry-pick sequence was very sensible. It
> _would_ be nice to have a command to return to a known state,
> discarding progress in all pending multiple-command guided workflows
> (am, rebase, bisect), but git reset is not that command.
IMO, it doesn't make sense that git-reset aborts a cherry-pick sequence:
When I messed up a difficult conflict in the middle of a cherry-pick
sequence, it might be useful to be able to 'git reset --hard && git
cherry-pick that-one-commit' to restart the conflict resolution.
(But does a single-commit cherry-pick during a multi-commit cherry-pick
work to begin with?)
-- Hannes
^ permalink raw reply
* Re: [PATCH] Fix revert --abort on Windows
From: Jonathan Nieder @ 2011-11-23 10:04 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <4ECCB3A2.5030102@viscovery.net>
Johannes Sixt 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.
Nice catch.
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Speaking of which, it doesn't make a lot of sense for "git revert
--abort" to be leaving a .git/sequencer-old directory around. How
about this on top?
-- >8 --
Subject: revert --abort: do not leave behind useless sequencer-old directory
The "git cherry-pick --abort" command currently renames the
.git/sequencer directory to .git/sequencer-old instead of removing it
on success due to an accident. cherry-pick --abort is designed to
work in three steps:
1) find which commit to roll back to
2) call "git reset --merge <commit>" to move to that commit
3) remove the .git/sequencer directory
But the careless author forgot step 3 entirely. The only reason the
command worked anyway is that "git reset --merge <commit>" renames the
.git/sequencer directory as a secondary effect --- after moving to
<commit>, or so the logic goes, it is unlikely but possible that the
caller of git reset wants to continue the series of cherry-picks that
was in progress, so git renames the sequencer state to
.git/sequencer-old to be helpful while allowing the cherry-pick to be
resumed if the caller did not want to end the sequence after all.
By running "git cherry-pick --abort", the operator has clearly
indicated that she is not planning to continue cherry-picking. Remove
the (renamed) .git/sequencer directory as intended all along.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
By the way, as the length of the second-to-last paragraph above might
have hinted, I am not convinced that allowing "git reset --hard" as an
escape route from a cherry-pick sequence was very sensible. It
_would_ be nice to have a command to return to a known state,
discarding progress in all pending multiple-command guided workflows
(am, rebase, bisect), but git reset is not that command.
builtin/revert.c | 1 +
t/t7106-reset-sequence.sh | 8 ++++++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 5dedb51c..818b4abb 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -942,6 +942,7 @@ static int sequencer_rollback(struct replay_opts *opts)
}
if (reset_for_rollback(sha1))
goto fail;
+ remove_sequencer_state(1);
strbuf_release(&buf);
return 0;
fail:
diff --git a/t/t7106-reset-sequence.sh b/t/t7106-reset-sequence.sh
index 3f86e8c5..83f7ea59 100755
--- a/t/t7106-reset-sequence.sh
+++ b/t/t7106-reset-sequence.sh
@@ -41,4 +41,12 @@ test_expect_success 'reset --hard cleans up sequencer state, providing one-level
test_path_is_missing .git/sequencer-old
'
+test_expect_success 'cherry-pick --abort does not leave sequencer-old dir' '
+ pristine_detach initial &&
+ test_must_fail git cherry-pick base..anotherpick &&
+ git cherry-pick --abort &&
+ test_path_is_missing .git/sequencer &&
+ test_path_is_missing .git/sequencer-old
+'
+
test_done
--
1.7.8.rc3
^ permalink raw reply related
* Re: Possible bug with branch names and case sensitivity
From: Michael Haggerty @ 2011-11-23 9:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, Gerd Knops, git
In-Reply-To: <7vwrasdp3t.fsf@alter.siamese.dyndns.org>
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.
Note that Unicode encoding differences can cause very similar problems
(even assuming utf8, there can be multiple ways to encode the same
string) and should maybe be addressed similarly.
By the way, I'm not volunteering for this project; case-sensitive
ASCII's good enough for me :-)
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* git fetch overwriting local tags
From: Uwe Kleine-König @ 2011-11-23 9:08 UTC (permalink / raw)
To: git; +Cc: John Kacur
Hello,
John and I wondered about git fetch overwriting local tags. I was sure
enough to claim that git fetch won't overwrite local tags with remote
tags having the same name. But after John pointed me to
http://www.pythian.com/news/9067/on-the-perils-of-importing-remote-tags-in-git/
I tested that (using Debian's 1.7.7.3) and really, git does overwrite
local tags.
Here is my test script:
mkdir a
cd a
echo some content > some_file
git init
git add some_file
git commit -m 'some commit log'
git tag some_tag
cd ..
mkdir b
cd b
echo some different content > another_file
git init
git add another_file
git commit -m 'another commit log'
git tag some_tag
git fetch --tags ../a
After that I have:
git log -1 --oneline some_tag
c4ad89a some commit log
so b's tag was overwritten.
Is this intended?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ 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