* Re: Stack overflow at write_one()
From: Shawn Pearce @ 2011-11-20 2:00 UTC (permalink / raw)
To: Cesar Eduardo Barros; +Cc: Junio C Hamano, git
In-Reply-To: <4EC8437C.6000808@cesarb.net>
On Sat, Nov 19, 2011 at 16:02, Cesar Eduardo Barros <cesarb@cesarb.net> wrote:
> Em 19-11-2011 21:30, Shawn Pearce escreveu:
>>
>> On Sat, Nov 19, 2011 at 13:46, Cesar Eduardo Barros<cesarb@cesarb.net>
>> wrote:
>>>
>>> Em 19-11-2011 19:08, Junio C Hamano escreveu:
>>>>
>>>> Already found the real cause (jGit bug) and workaround posted, I think.
>>>
>>> I presume the cause then is what was fixed by
>>>
>>> http://egit.eclipse.org/w/?p=jgit.git;a=commit;h=2fbf296fda205446eac11a13abd4fcdb182f28d9
>>> ?
>>
>> Yes. The AOSP servers were all updated with the above JGit patch, so
>> the servers are no longer sending duplicate objects. But yes, for a
>> period of time there were duplicates in the kernel repositories,
>> particularly kernal/omap.
>
> So, would an alternative workaround in my situation be to delete
> kernel/omap.git and let repo sync recreate it? It seems repo does not have
> extra metadata anywhere else, so just removing the directory should be
> enough for it to clone again from scratch, hopefully getting a corrected
> pack from the server.
Yes. repo does not have extra state, so just removing the directory
and running `repo sync` again to clone the repository would correct
the local repository.
^ permalink raw reply
* Re: [PATCH 1/2] MSVC: Do not close stdout to prevent a crash
From: Junio C Hamano @ 2011-11-20 3:27 UTC (permalink / raw)
To: Andreas Schwab
Cc: Vincent van Ravesteijn, git, msysgit, kusmabite,
Johannes.Schindelin
In-Reply-To: <m2obw7dg1e.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> We have relied on fstat(-1, &st) to correctly error out, and if MSVC build
>> crashes, it is a bug in its fstat() emulation, I would think.
>
> fileno(stdout) is alread wrong if stdout was closed.
The "-1" in my message comes from here:
DESCRIPTION
The fileno() function shall return the integer file descriptor
associated with the stream pointed to by stream.
RETURN VALUE
Upon successful completion, fileno() shall return the integer value of
the file descriptor associated with stream. Otherwise, the value -1
shall be returned and errno set to indicate the error.
^ permalink raw reply
* cherry-pick/revert error messages
From: Jonathan Nieder @ 2011-11-20 7:30 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git, Christian Couder, Martin von Zweigbergk
Hi Ram,
Today I encountered the following error message:
$ git cherry-pick foo..bar
error: .git/sequencer already exists.
error: A cherry-pick or revert is in progress.
hint: Use --continue to continue the operation
hint: or --reset to forget about it
fatal: cherry-pick failed
$
The double "error" seemed a little weird. Also, the capital letters
and periods feel out of place, when compared with other messages
emited by git with an "error:" prefix. The final "fatal: cherry-pick
failed" seems redundant, too. I guess I would have expected something
like the following instead:
$ git cherry-pick foo..bar
fatal: a cherry-pick or revert is already in progress
hint: try "git cherry-pick (--continue | --quit)"
$
What do you think?
^ permalink raw reply
* Re: cherry-pick/revert error messages
From: Ramkumar Ramachandra @ 2011-11-20 8:02 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Christian Couder, Martin von Zweigbergk
In-Reply-To: <20111120073059.GA2278@elie.hsd1.il.comcast.net>
Hi Jonathan,
Jonathan Nieder wrote:
> Today I encountered the following error message:
> [...]
> I guess I would have expected something
> like the following instead:
>
> $ git cherry-pick foo..bar
> fatal: a cherry-pick or revert is already in progress
> hint: try "git cherry-pick (--continue | --quit)"
> $
>
> What do you think?
Looks much better! Yes, a series pretty'fying error messages would be
really nice. I'm busy with exams this week, and "New sequencer
workflow! v2" has been pending for some time -- would you like to
handle this bit?
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 1/2] MSVC: Do not close stdout to prevent a crash
From: Andreas Schwab @ 2011-11-20 9:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Vincent van Ravesteijn, git, msysgit, kusmabite,
Johannes.Schindelin
In-Reply-To: <7vpqgniid5.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> We have relied on fstat(-1, &st) to correctly error out, and if MSVC build
>>> crashes, it is a bug in its fstat() emulation, I would think.
>>
>> fileno(stdout) is alread wrong if stdout was closed.
>
> The "-1" in my message comes from here:
>
> DESCRIPTION
>
> The fileno() function shall return the integer file descriptor
> associated with the stream pointed to by stream.
After fclose(stdout) the stream does not exist any more. Thus the use
of fileno(stdout) is undefined, in fact *any* use of stdout is undefined
afterwards.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 1/2] MSVC: Do not close stdout to prevent a crash
From: Johannes Sixt @ 2011-11-20 9:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Andreas Schwab, Vincent van Ravesteijn, git, msysgit, kusmabite,
Johannes.Schindelin
In-Reply-To: <7vpqgniid5.fsf@alter.siamese.dyndns.org>
Am 20.11.2011 04:27, schrieb Junio C Hamano:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> We have relied on fstat(-1, &st) to correctly error out, and if MSVC build
>>> crashes, it is a bug in its fstat() emulation, I would think.
>>
>> fileno(stdout) is alread wrong if stdout was closed.
>
> The "-1" in my message comes from here:
>
> DESCRIPTION
>
> The fileno() function shall return the integer file descriptor
> associated with the stream pointed to by stream.
>
> RETURN VALUE
>
> Upon successful completion, fileno() shall return the integer value of
> the file descriptor associated with stream. Otherwise, the value -1
> shall be returned and errno set to indicate the error.
But in the description of fclose() there is also:
After the call to fclose(), any use of stream results in undefined
behavior.
And we do call fclose(stdout) in cmd_format_patch.
-- Hannes
^ permalink raw reply
* [RFC/PATCH 0/3] Re: cherry-pick/revert error messages
From: Jonathan Nieder @ 2011-11-20 9:46 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: git, Christian Couder, Martin von Zweigbergk, Phil Hord
In-Reply-To: <CALkWK0=45OwcBoH2TorsgwTbaXjnffVuh0mGxh2+ShN9cuF-=A@mail.gmail.com>
Ramkumar Ramachandra wrote:
> Looks much better! Yes, a series pretty'fying error messages would be
> really nice.
Good to hear. Here's a rough one.
I realize patch 1/3 might not be conservative enough, even though
there hasn't been much time for people to get used to --reset yet. So
I might be sending a second version that treats --reset as a synonym.
But please forget I said that when judging this version (i.e., if it
looks like a problem, I do want to know).
Thoughts?
Jonathan Nieder (3):
revert: rename --reset option to --quit
revert: restructure pick_revisions() for clarity
revert: improve error message for cherry-pick during cherry-pick
Documentation/git-cherry-pick.txt | 2 +-
Documentation/git-revert.txt | 2 +-
Documentation/sequencer.txt | 10 +++---
builtin/revert.c | 71 ++++++++++++++++++-------------------
sequencer.h | 2 +-
t/t3510-cherry-pick-sequence.sh | 10 +++---
t/t7106-reset-sequence.sh | 2 +-
7 files changed, 49 insertions(+), 50 deletions(-)
^ permalink raw reply
* [PATCH 1/3] revert: rename --reset option to --quit
From: Jonathan Nieder @ 2011-11-20 9:48 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: git, Christian Couder, Martin von Zweigbergk, Phil Hord
In-Reply-To: <20111120094650.GB2278@elie.hsd1.il.comcast.net>
The option to "git cherry-pick" and "git revert" to discard the
sequencer state introduced by v1.7.8-rc0~141^2~6 (revert: Introduce
--reset to remove sequencer state, 2011-08-04) has a confusing name.
Change it now, while we still have the time.
Mechanics:
This commit removes the "git cherry-pick --reset" option. Hopefully
nobody was using it. If somebody was, we can add it back again as a
synonym.
The new name for "cherry-pick, please get out of my way, since I've
long forgotten about the sequence of commits I was cherry-picking when
you wrote that old .git/sequencer directory" is --quit. Mnemonic:
this is analagous to quiting a program the user is no longer using ---
we just want to get out of the multiple-command cherry-pick procedure
and not to reset HEAD or restore any other old state.
Adjust documentation and tests to match. While at it, let's clarify
the short descriptions of these operations in "-h" output.
Before:
--reset forget the current operation
--continue continue the current operation
After:
--quit end revert or cherry-pick sequence
--continue resume revert or cherry-pick sequence
Noticed-by: Phil Hord <phil.hord@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-cherry-pick.txt | 2 +-
Documentation/git-revert.txt | 2 +-
Documentation/sequencer.txt | 10 +++++-----
builtin/revert.c | 22 +++++++++++-----------
sequencer.h | 2 +-
t/t3510-cherry-pick-sequence.sh | 10 +++++-----
t/t7106-reset-sequence.sh | 2 +-
7 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 2660a842..21998b82 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -9,8 +9,8 @@ SYNOPSIS
--------
[verse]
'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>...
-'git cherry-pick' --reset
'git cherry-pick' --continue
+'git cherry-pick' --quit
DESCRIPTION
-----------
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index f3519413..b0fcabc8 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -9,8 +9,8 @@ SYNOPSIS
--------
[verse]
'git revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>...
-'git revert' --reset
'git revert' --continue
+'git revert' --quit
DESCRIPTION
-----------
diff --git a/Documentation/sequencer.txt b/Documentation/sequencer.txt
index 3e6df338..75f8e869 100644
--- a/Documentation/sequencer.txt
+++ b/Documentation/sequencer.txt
@@ -1,9 +1,9 @@
---reset::
- Forget about the current operation in progress. Can be used
- to clear the sequencer state after a failed cherry-pick or
- revert.
-
--continue::
Continue the operation in progress using the information in
'.git/sequencer'. Can be used to continue after resolving
conflicts in a failed cherry-pick or revert.
+
+--quit::
+ Forget about the current operation in progress. Can be used
+ to clear the sequencer state after a failed cherry-pick or
+ revert.
diff --git a/builtin/revert.c b/builtin/revert.c
index 544e8c30..b59dd68c 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -40,7 +40,7 @@ static const char * const cherry_pick_usage[] = {
};
enum replay_action { REVERT, CHERRY_PICK };
-enum replay_subcommand { REPLAY_NONE, REPLAY_RESET, REPLAY_CONTINUE };
+enum replay_subcommand { REPLAY_NONE, REPLAY_REMOVE_STATE, REPLAY_CONTINUE };
struct replay_opts {
enum replay_action action;
@@ -133,11 +133,11 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
{
const char * const * usage_str = revert_or_cherry_pick_usage(opts);
const char *me = action_name(opts);
- int reset = 0;
+ int remove_state = 0;
int contin = 0;
struct option options[] = {
- OPT_BOOLEAN(0, "reset", &reset, "forget the current operation"),
- OPT_BOOLEAN(0, "continue", &contin, "continue the current operation"),
+ OPT_BOOLEAN(0, "quit", &remove_state, "end revert or cherry-pick sequence"),
+ OPT_BOOLEAN(0, "continue", &contin, "resume revert or cherry-pick sequence"),
OPT_BOOLEAN('n', "no-commit", &opts->no_commit, "don't automatically commit"),
OPT_BOOLEAN('e', "edit", &opts->edit, "edit the commit message"),
OPT_NOOP_NOARG('r', NULL),
@@ -168,13 +168,13 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
/* Check for incompatible subcommands */
verify_opt_mutually_compatible(me,
- "--reset", reset,
+ "--quit", remove_state,
"--continue", contin,
NULL);
/* Set the subcommand */
- if (reset)
- opts->subcommand = REPLAY_RESET;
+ if (remove_state)
+ opts->subcommand = REPLAY_REMOVE_STATE;
else if (contin)
opts->subcommand = REPLAY_CONTINUE;
else
@@ -183,8 +183,8 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
/* Check for incompatible command line arguments */
if (opts->subcommand != REPLAY_NONE) {
char *this_operation;
- if (opts->subcommand == REPLAY_RESET)
- this_operation = "--reset";
+ if (opts->subcommand == REPLAY_REMOVE_STATE)
+ this_operation = "--quit";
else
this_operation = "--continue";
@@ -965,7 +965,7 @@ static int pick_revisions(struct replay_opts *opts)
* cherry-pick should be handled differently from an existing
* one that is being continued
*/
- if (opts->subcommand == REPLAY_RESET) {
+ if (opts->subcommand == REPLAY_REMOVE_STATE) {
remove_sequencer_state(1);
return 0;
} else if (opts->subcommand == REPLAY_CONTINUE) {
@@ -988,7 +988,7 @@ static int pick_revisions(struct replay_opts *opts)
if (create_seq_dir() < 0) {
error(_("A cherry-pick or revert is in progress."));
advise(_("Use --continue to continue the operation"));
- advise(_("or --reset to forget about it"));
+ advise(_("or --quit to forget about it"));
return -1;
}
if (get_sha1("HEAD", sha1)) {
diff --git a/sequencer.h b/sequencer.h
index 905d2950..f435fdb4 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -13,7 +13,7 @@
*
* With the aggressive flag, it additionally removes SEQ_OLD_DIR,
* ignoring any errors. Inteded to be used by the sequencer's
- * '--reset' subcommand.
+ * '--quit' subcommand.
*/
void remove_sequencer_state(int aggressive);
diff --git a/t/t3510-cherry-pick-sequence.sh b/t/t3510-cherry-pick-sequence.sh
index 3bca2b3d..913435e2 100755
--- a/t/t3510-cherry-pick-sequence.sh
+++ b/t/t3510-cherry-pick-sequence.sh
@@ -13,7 +13,7 @@ test_description='Test cherry-pick continuation features
. ./test-lib.sh
pristine_detach () {
- git cherry-pick --reset &&
+ git cherry-pick --quit &&
git checkout -f "$1^0" &&
git read-tree -u --reset HEAD &&
git clean -d -f -f -q -x
@@ -70,15 +70,15 @@ test_expect_success 'cherry-pick cleans up sequencer state upon success' '
test_path_is_missing .git/sequencer
'
-test_expect_success '--reset does not complain when no cherry-pick is in progress' '
+test_expect_success '--quit does not complain when no cherry-pick is in progress' '
pristine_detach initial &&
- git cherry-pick --reset
+ git cherry-pick --quit
'
-test_expect_success '--reset cleans up sequencer state' '
+test_expect_success '--quit cleans up sequencer state' '
pristine_detach initial &&
test_must_fail git cherry-pick base..picked &&
- git cherry-pick --reset &&
+ git cherry-pick --quit &&
test_path_is_missing .git/sequencer
'
diff --git a/t/t7106-reset-sequence.sh b/t/t7106-reset-sequence.sh
index 4956caaf..3f86e8c5 100755
--- a/t/t7106-reset-sequence.sh
+++ b/t/t7106-reset-sequence.sh
@@ -12,7 +12,7 @@ test_description='Test interaction of reset --hard with sequencer
. ./test-lib.sh
pristine_detach () {
- git cherry-pick --reset &&
+ git cherry-pick --quit &&
git checkout -f "$1^0" &&
git read-tree -u --reset HEAD &&
git clean -d -f -f -q -x
--
1.7.8.rc3
^ permalink raw reply related
* [PATCH 2/3] revert: rearrange pick_revisions() for clarity
From: Jonathan Nieder @ 2011-11-20 9:50 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: git, Christian Couder, Martin von Zweigbergk, Phil Hord
In-Reply-To: <20111120094650.GB2278@elie.hsd1.il.comcast.net>
Deal completely with "cherry-pick --quit" and --continue at the
beginning of pick_revisions(), leaving the rest of the function for
the more interesting "git cherry-pick <commits>" case.
No functional change intended. The impact is just to unindent the
code a little.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
This also paves the way to factoring out the REPLAY_CONTINUE case
into a separate function.
builtin/revert.c | 48 ++++++++++++++++++++++++------------------------
1 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index b59dd68c..dd072ce6 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -968,40 +968,40 @@ static int pick_revisions(struct replay_opts *opts)
if (opts->subcommand == REPLAY_REMOVE_STATE) {
remove_sequencer_state(1);
return 0;
- } else if (opts->subcommand == REPLAY_CONTINUE) {
+ }
+ if (opts->subcommand == REPLAY_CONTINUE) {
if (!file_exists(git_path(SEQ_TODO_FILE)))
- goto error;
+ return error(_("No %s in progress"), action_name(opts));
read_populate_opts(&opts);
read_populate_todo(&todo_list, opts);
/* Verify that the conflict has been resolved */
if (!index_differs_from("HEAD", 0))
todo_list = todo_list->next;
- } else {
- /*
- * Start a new cherry-pick/ revert sequence; but
- * first, make sure that an existing one isn't in
- * progress
- */
+ return pick_commits(todo_list, opts);
+ }
+
+ /*
+ * Start a new cherry-pick/ revert sequence; but
+ * first, make sure that an existing one isn't in
+ * progress
+ */
- walk_revs_populate_todo(&todo_list, opts);
- if (create_seq_dir() < 0) {
- error(_("A cherry-pick or revert is in progress."));
- advise(_("Use --continue to continue the operation"));
- advise(_("or --quit to forget about it"));
- return -1;
- }
- if (get_sha1("HEAD", sha1)) {
- if (opts->action == REVERT)
- return error(_("Can't revert as initial commit"));
- return error(_("Can't cherry-pick into empty head"));
- }
- save_head(sha1_to_hex(sha1));
- save_opts(opts);
+ walk_revs_populate_todo(&todo_list, opts);
+ if (create_seq_dir() < 0) {
+ error(_("A cherry-pick or revert is in progress."));
+ advise(_("Use --continue to continue the operation"));
+ advise(_("or --quit to forget about it"));
+ return -1;
+ }
+ if (get_sha1("HEAD", sha1)) {
+ if (opts->action == REVERT)
+ return error(_("Can't revert as initial commit"));
+ return error(_("Can't cherry-pick into empty head"));
}
+ save_head(sha1_to_hex(sha1));
+ save_opts(opts);
return pick_commits(todo_list, opts);
-error:
- return error(_("No %s in progress"), action_name(opts));
}
int cmd_revert(int argc, const char **argv, const char *prefix)
--
1.7.8.rc3
^ permalink raw reply related
* [PATCH 3/3] revert: improve error message for cherry-pick during cherry-pick
From: Jonathan Nieder @ 2011-11-20 9:51 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: git, Christian Couder, Martin von Zweigbergk, Phil Hord
In-Reply-To: <20111120094650.GB2278@elie.hsd1.il.comcast.net>
In the spirit of v1.6.3.3~3^2 (refuse to merge during a merge,
2009-07-01), "git cherry-pick" refuses to start a new cherry-pick when
in the middle of an existing conflicted cherry-pick in the following
sequence:
1. git cherry-pick HEAD..origin
2. resolve conflicts
3. git cherry-pick HEAD..origin (instead of "git cherry-pick
--continue", by mistake)
Good. However, the error message on attempting step 3 is more
convoluted than necessary:
$ git cherry-pick HEAD..origin
error: .git/sequencer already exists.
error: A cherry-pick or revert is in progress.
hint: Use --continue to continue the operation
hint: or --quit to forget about it
fatal: cherry-pick failed
Clarify by removing the double redundant first "error:" message,
simplifying the advice, and using lower-case and no full stops to be
consistent with other commands that prefix their messages with
"error:", so it becomes
error: a cherry-pick or revert is already in progress
hint: try "git cherry-pick (--continue | --quit)"
fatal: cherry-pick failed
The "fatal: cherry-pick failed" line seems unnecessary, too, but
that can be fixed some other day.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
That's the end of the series. There are more error messages, but
let's start with this one.
Thanks for reading.
builtin/revert.c | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index dd072ce6..9db4c1e4 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -843,8 +843,11 @@ static int create_seq_dir(void)
{
const char *seq_dir = git_path(SEQ_DIR);
- if (file_exists(seq_dir))
- return error(_("%s already exists."), seq_dir);
+ if (file_exists(seq_dir)) {
+ error(_("a cherry-pick or revert is already in progress"));
+ advise(_("try \"git cherry-pick (--continue | --quit)\""));
+ return -1;
+ }
else if (mkdir(seq_dir, 0777) < 0)
die_errno(_("Could not create sequencer directory %s"), seq_dir);
return 0;
@@ -988,12 +991,8 @@ static int pick_revisions(struct replay_opts *opts)
*/
walk_revs_populate_todo(&todo_list, opts);
- if (create_seq_dir() < 0) {
- error(_("A cherry-pick or revert is in progress."));
- advise(_("Use --continue to continue the operation"));
- advise(_("or --quit to forget about it"));
+ if (create_seq_dir() < 0)
return -1;
- }
if (get_sha1("HEAD", sha1)) {
if (opts->action == REVERT)
return error(_("Can't revert as initial commit"));
--
1.7.8.rc3
^ permalink raw reply related
* Bug report - local (and git ignored) file silently removed after checkout
From: Bertrand BENOIT @ 2011-11-20 13:42 UTC (permalink / raw)
To: git
Hi,
In a (special ?) situation, I've lost a local (and git ignored) file
silently, and I've failed to get it back.
Context:
- in previous version of my project, the TODO file was versioned
- in current development version, this file is NO more versioned AND
it is ignored by a gitignore rule, but still at the same place for
better ease of access -> such a way, this file has been locally
updated several times
- during worflow process, I've finally performed a checkout on a
previous version (in which the TODO file was versioned) -> after that
the file has been silently updated with the old version
- after modification, I've performed back a checkout on the current
version and this time my TODO file has been fully and silently removed
Questions:
- is it a behavior regarded as normal ?
- is there any way to get back the TODO file, in LOCAL version it
was before the first checkout ?
- in any case, is there any way to be warned (and to make the
checkout fail) of such situation (local ignored file being overwritten
with 'older' not-ignored version) ?
Thx,
Best regards,
TWK
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 1/2] MSVC: Do not close stdout to prevent a crash
From: Junio C Hamano @ 2011-11-20 21:10 UTC (permalink / raw)
To: Johannes Sixt
Cc: Andreas Schwab, Vincent van Ravesteijn, git, msysgit, kusmabite,
Johannes.Schindelin
In-Reply-To: <4EC8C7FE.5050903@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> But in the description of fclose() there is also:
>
> After the call to fclose(), any use of stream results in undefined
> behavior.
>
> And we do call fclose(stdout) in cmd_format_patch.
Yeah; this means the "in case builtin implementation is too lazy to clean
up after themselves, run_builtin() will clean things up for them" approach
taken by 0f15731 (Check for IO errors after running a command, 2007-06-24)
fundamentally does not work, which is a bit sad.
^ permalink raw reply
* Re: Bug report - local (and git ignored) file silently removed after checkout
From: Junio C Hamano @ 2011-11-20 21:16 UTC (permalink / raw)
To: Bertrand BENOIT; +Cc: git
In-Reply-To: <CAPRVejcpAZrLWCeHTZJr9Uk6_z6hTPQLLd6pCOKteYnRGMQ5ig@mail.gmail.com>
Bertrand BENOIT <projettwk@users.sourceforge.net> writes:
> Context:
> - in previous version of my project, the TODO file was versioned
> - in current development version, this file is NO more versioned AND
> it is ignored by a gitignore rule,...
What you observed is expected with all the versions of Git since the
gitignore mechanism was introduced. The ignored files are "not tracked,
are cruft that can be removed to make room if it is necessary for checking
out a tracked version, and would not want to track (e.g. build artifacts
like '*.o')" (I am not saying that it is the most sane semantics, I am
just stating the fact).
We do not have "not tracked, but precious (e.g. your TODO)" category; from
time to time we have discussed possibilities of adding such to enrich the
categorization, but nobody stepped up to actually do the work of designing
let alone coding such a beast.
^ permalink raw reply
* Re: Bug report - local (and git ignored) file silently removed after checkout
From: Taylor Hedberg @ 2011-11-20 22:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bertrand BENOIT, git
In-Reply-To: <7vehx2ijf8.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]
Junio C Hamano, Sun 2011-11-20 @ 13:16:27-0800:
> We do not have "not tracked, but precious (e.g. your TODO)" category;
> from time to time we have discussed possibilities of adding such to
> enrich the categorization, but nobody stepped up to actually do the
> work of designing let alone coding such a beast.
If I'm not mistaken, files ignored by .git/info/exclude rather than
.gitignore do exhibit this behavior. That is, Git will refuse a checkout
with an error message if it would overwrite a path listed in that file.
I don't know if that's actually intended behavior, but I've noticed it
before and made use of it.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Switch from svn to git and modify repo completely
From: Matthias Fechner @ 2011-11-20 22:21 UTC (permalink / raw)
To: git
In-Reply-To: <20111119225048.384189bc@zappedws>
Am 19.11.2011 19:50, schrieb Alexey Shumkin:
> take a look at "git filter-branch"
thanks a lot for your answer. I checked the manual page, but it does not
work like I expected it or it is described. What I did:
1. I searched the path name with the command:
git show --pretty="format:" --name-only firstrev..endrev | sort | uniq
|grep sdcc
2. I tried to remove the file with the command:
git filter-branch -f --tree-filter 'rm -f
software/tools/net.sourceforge.eclipsesdcc-1.0.0-win32.x86.zip'
--prune-empty -- --all
git told me:
Ref 'refs/heads/master' was rewritten
Ref 'refs/remotes/origin/master' was rewritten
WARNING: Ref 'refs/remotes/origin/master' is unchanged
3. I cloned the repository with:
git clone --no-hardlinks repo-orig.git repo-filtered.git
4. After this I verified in the repo-filtered.git that the file was
really completely removed, but it was not the case. I was able to
checkout the revision which holds the file.
Regarding the manual page it should work... but reality is different.
Has here anyone an idea what I did wrong?
Bye
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
^ permalink raw reply
* Re: [PATCH 1/3] t5501-*.sh: Fix url passed to clone in setup test
From: Junio C Hamano @ 2011-11-21 3:24 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <4EC805CE.10203@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> In particular, the url passed to git-clone has an extra '/' given
> after the 'file://' schema prefix, thus:
>
> git clone --reference=original "file:///$(pwd)/original one
>
> Once the prefix is removed, the remainder of the url looks something
> like "//home/ramsay/git/t/...", which is then interpreted as an
> network path. This then results in a "Permission denied" error, like
> so:
>
> ramsay $ ls //home
> ls: cannot access //home: No such host or network path
> ramsay $ ls //home/ramsay
> ls: cannot access //home/ramsay: Permission denied
> ramsay $
>
> In order to fix the problem, we simply remove the extraneous '/'
> character from the url.
>
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> ---
Thanks; obviously correct.
> t/t5501-fetch-push-alternates.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/t/t5501-fetch-push-alternates.sh b/t/t5501-fetch-push-alternates.sh
> index b5ced84..1bc57ac 100755
> --- a/t/t5501-fetch-push-alternates.sh
> +++ b/t/t5501-fetch-push-alternates.sh
> @@ -28,7 +28,7 @@ test_expect_success setup '
> done
> ) &&
> (
> - git clone --reference=original "file:///$(pwd)/original" one &&
> + git clone --reference=original "file://$(pwd)/original" one &&
> cd one &&
> echo Z >count &&
> git add count &&
^ permalink raw reply
* Re: [PATCH 2/3] config.c: Fix a static buffer overwrite bug by avoiding mkpath()
From: Junio C Hamano @ 2011-11-21 3:32 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <4EC80688.609@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> In order to fix the problem, we replace the call to mkpath() with
> a call to mksnpath() and provide our own buffer.
A longer term fix might be to get rid of unwanted git_config_* call from
stat() callchain, but as a short-term fix, this patch with minor tweaks
should do.
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> ---
> config.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/config.c b/config.c
> index edf9914..5a9ca84 100644
> --- a/config.c
> +++ b/config.c
> @@ -851,6 +851,7 @@ int git_config_system(void)
>
> int git_config_early(config_fn_t fn, void *data, const char *repo_config)
> {
> + char buf[4096];
> int ret = 0, found = 0;
> const char *home = NULL;
Two points. (1) This buffer does not need to be inside the whole function
scope, no? (2) s/4096/PATH_MAX/ to match what get_pathname() has been
returning to the caller?
That is, something like the attached squashed in?
> @@ -865,12 +866,11 @@ int git_config_early(config_fn_t fn, void *data, const char *repo_config)
>
> home = getenv("HOME");
> if (home) {
> - char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
> + char *user_config = mksnpath(buf, sizeof(buf), "%s/.gitconfig", home);
> if (!access(user_config, R_OK)) {
> ret += git_config_from_file(fn, user_config, data);
> found += 1;
> }
> - free(user_config);
> }
>
> if (repo_config && !access(repo_config, R_OK)) {
config.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/config.c b/config.c
index 5a9ca84..b6d789a 100644
--- a/config.c
+++ b/config.c
@@ -851,7 +851,6 @@ int git_config_system(void)
int git_config_early(config_fn_t fn, void *data, const char *repo_config)
{
- char buf[4096];
int ret = 0, found = 0;
const char *home = NULL;
@@ -866,6 +865,7 @@ int git_config_early(config_fn_t fn, void *data, const char *repo_config)
home = getenv("HOME");
if (home) {
+ char buf[PATH_MAX];
char *user_config = mksnpath(buf, sizeof(buf), "%s/.gitconfig", home);
if (!access(user_config, R_OK)) {
ret += git_config_from_file(fn, user_config, data);
^ permalink raw reply related
* Re: Bug report - local (and git ignored) file silently removed after checkout
From: Junio C Hamano @ 2011-11-21 3:36 UTC (permalink / raw)
To: Taylor Hedberg; +Cc: Bertrand BENOIT, git
In-Reply-To: <20111120221930.GF14902@foodlogiq3-xp-d620.thebe.ath.cx>
Taylor Hedberg <tmhedberg@gmail.com> writes:
> Junio C Hamano, Sun 2011-11-20 @ 13:16:27-0800:
>> We do not have "not tracked, but precious (e.g. your TODO)" category;
>> from time to time we have discussed possibilities of adding such to
>> enrich the categorization, but nobody stepped up to actually do the
>> work of designing let alone coding such a beast.
>
> If I'm not mistaken, files ignored by .git/info/exclude rather than
> .gitignore do exhibit this behavior.
As far as I am aware, info/exclude should work exactly the same as having
a .gitignore file at the root level of the working tree. Can you show a
minimum reproduction recipe in a form of a patch to our test scripts in t/
hierarchy?
^ permalink raw reply
* Re: Switch from svn to git and modify repo completely
From: Jonathan Nieder @ 2011-11-21 7:02 UTC (permalink / raw)
To: Matthias Fechner; +Cc: git, Alexey Shumkin
In-Reply-To: <4EC97D52.1010308@fechner.net>
(re-populating cc list)
Hi Matthias,
Matthias Fechner wrote:
> git told me:
> Ref 'refs/heads/master' was rewritten
> Ref 'refs/remotes/origin/master' was rewritten
> WARNING: Ref 'refs/remotes/origin/master' is unchanged
>
> 3. I cloned the repository with:
> git clone --no-hardlinks repo-orig.git repo-filtered.git
>
> 4. After this I verified in the repo-filtered.git that the file was
> really completely removed, but it was not the case.
The section "CHECKLIST FOR SHRINKING A REPOSITORY" from the
git-filter-branch(1) manual page has some hints. In particular, "git
clone --no-hardlinks" still _copies_ all objects --- you probably
would want "git clone file://$(pwd)/repo-orig" to make sure the
ordinary transfer negotiation kicks in.
It's very important that the documentation not be misleading, so if
you can point to places where the wording can be less confusing, that
would be very welcome.
Thanks and hope that helps,
Jonathan
^ permalink raw reply
* [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Johannes Sixt @ 2011-11-21 7:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <7vzkfqgn91.fsf@alter.siamese.dyndns.org>
From: Johannes Sixt <j6t@kdbg.org>
It is an unintended accident that entries matched by .git/info/exclude are
considered precious, but entries matched by .gitignore are not. That is,
'git checkout' will overwrite untracked files matched by .gitignore, but
refuses to overwrite files matched by .git/info/exclude.
It is a lucky accident: it allows the distinction between "untracked but
precious" and "untracked and garbage". And it is a doubly lucky accident:
.gitignore entries are meant for files like build products, which usually
affect all consumers of a repository, whereas .git/info/exclude is
intended for personal files, which frequently are precious (think of a
TODO file).
Add a test that codifies the accident as wanted behavior.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Am 11/21/2011 4:36, schrieb Junio C Hamano:
> As far as I am aware, info/exclude should work exactly the same as having
> a .gitignore file at the root level of the working tree. Can you show a
> minimum reproduction recipe in a form of a patch to our test scripts in t/
> hierarchy?
Here you are. As you can see from my commit message, IMO, this is
a very useful accident. Therefore, there is no 'test_expect_failure'
in the test script :-)
-- Hannes
t/t2023-checkout-ignored.sh | 51 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 51 insertions(+), 0 deletions(-)
create mode 100755 t/t2023-checkout-ignored.sh
diff --git a/t/t2023-checkout-ignored.sh b/t/t2023-checkout-ignored.sh
new file mode 100755
index 0000000..03a5a56
--- /dev/null
+++ b/t/t2023-checkout-ignored.sh
@@ -0,0 +1,51 @@
+#!/bin/sh
+
+test_description='checkout overwrites or preserves ignored files
+
+`git checkout` makes a distinction between files mentioned in
+.gitignore and .git/info/exclude in that untracked files matched
+by the latter are considered precious and are not overwritten.
+'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+
+ echo excluded > excluded &&
+ echo ignored > ignored &&
+ git add . &&
+ test_commit initial &&
+ git checkout -b side &&
+ git rm excluded &&
+ git mv ignored .gitignore &&
+ test_commit side &&
+ echo excluded >> .git/info/exclude
+'
+
+test_expect_success 'files are ignored' '
+
+ echo keep > excluded &&
+ echo overwrite > ignored &&
+ list=$(git ls-files --others --exclude-standard) &&
+ test -z "$list"
+'
+
+test_expect_success 'entries in .git/info/exclude are precious' '
+
+ test_must_fail git checkout master 2>errors &&
+ test_i18ngrep "would be overwritten" errors &&
+ grep " excluded" errors &&
+ ! grep " ignored" errors &&
+ grep keep excluded &&
+ grep overwrite ignored
+'
+
+test_expect_success 'entries in .gitignore are not precious' '
+
+ rm -f excluded &&
+ git checkout master &&
+ grep excluded excluded &&
+ grep ignored ignored
+'
+
+test_done
--
1.7.8.rc0.126.gd15506
^ permalink raw reply related
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Philip Oakley @ 2011-11-21 7:45 UTC (permalink / raw)
To: Johannes Sixt, Junio C Hamano; +Cc: Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <4EC9FC81.3080306@viscovery.net>
From: "Johannes Sixt" <j.sixt@viscovery.net>
> From: Johannes Sixt <j6t@kdbg.org>
>
> It is an unintended accident that entries matched by .git/info/exclude are
> considered precious, but entries matched by .gitignore are not. That is,
> 'git checkout' will overwrite untracked files matched by .gitignore, but
> refuses to overwrite files matched by .git/info/exclude.
>
> It is a lucky accident: it allows the distinction between "untracked but
> precious" and "untracked and garbage". And it is a doubly lucky accident:
> .gitignore entries are meant for files like build products, which usually
> affect all consumers of a repository, whereas .git/info/exclude is
> intended for personal files, which frequently are precious (think of a
> TODO file).
>
> Add a test that codifies the accident as wanted behavior.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> Am 11/21/2011 4:36, schrieb Junio C Hamano:
>> As far as I am aware, info/exclude should work exactly the same as having
>> a .gitignore file at the root level of the working tree. Can you show a
>> minimum reproduction recipe in a form of a patch to our test scripts in
>> t/
>> hierarchy?
>
> Here you are. As you can see from my commit message, IMO, this is
> a very useful accident. Therefore, there is no 'test_expect_failure'
> in the test script :-)
Shouldn't there be some documentation changes to support this very useful
feature. By documenting the existing code functionality we get the double
benefit of no code changes and we publish the existance of a desired bit of
functionality.
Philip
>
> -- Hannes
>
> t/t2023-checkout-ignored.sh | 51
> +++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 51 insertions(+), 0 deletions(-)
> create mode 100755 t/t2023-checkout-ignored.sh
>
> diff --git a/t/t2023-checkout-ignored.sh b/t/t2023-checkout-ignored.sh
> new file mode 100755
> index 0000000..03a5a56
> --- /dev/null
> +++ b/t/t2023-checkout-ignored.sh
> @@ -0,0 +1,51 @@
> +#!/bin/sh
> +
> +test_description='checkout overwrites or preserves ignored files
> +
> +`git checkout` makes a distinction between files mentioned in
> +.gitignore and .git/info/exclude in that untracked files matched
> +by the latter are considered precious and are not overwritten.
> +'
> +
> +. ./test-lib.sh
> +
> +test_expect_success setup '
> +
> + echo excluded > excluded &&
> + echo ignored > ignored &&
> + git add . &&
> + test_commit initial &&
> + git checkout -b side &&
> + git rm excluded &&
> + git mv ignored .gitignore &&
> + test_commit side &&
> + echo excluded >> .git/info/exclude
> +'
> +
> +test_expect_success 'files are ignored' '
> +
> + echo keep > excluded &&
> + echo overwrite > ignored &&
> + list=$(git ls-files --others --exclude-standard) &&
> + test -z "$list"
> +'
> +
> +test_expect_success 'entries in .git/info/exclude are precious' '
> +
> + test_must_fail git checkout master 2>errors &&
> + test_i18ngrep "would be overwritten" errors &&
> + grep " excluded" errors &&
> + ! grep " ignored" errors &&
> + grep keep excluded &&
> + grep overwrite ignored
> +'
> +
> +test_expect_success 'entries in .gitignore are not precious' '
> +
> + rm -f excluded &&
> + git checkout master &&
> + grep excluded excluded &&
> + grep ignored ignored
> +'
> +
> +test_done
> --
> 1.7.8.rc0.126.gd15506
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1872 / Virus Database: 2092/4628 - Release Date: 11/20/11
>
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Junio C Hamano @ 2011-11-21 7:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <4EC9FC81.3080306@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> It is a lucky accident: it allows the distinction between "untracked but
> precious" and "untracked and garbage". And it is a doubly lucky accident:
> .gitignore entries are meant for files like build products, which usually
> affect all consumers of a repository, whereas .git/info/exclude is
> intended for personal files, which frequently are precious (think of a
> TODO file).
> ...
> Here you are. As you can see from my commit message, IMO, this is
> a very useful accident. Therefore, there is no 'test_expect_failure'
> in the test script :-)
Heh.
If this is a feature, we would like a patch to Documentation/gitignore.txt
as well, I think. Also I have a suspicion that this was an unintended
"regression"; do you have a bisection?
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Junio C Hamano @ 2011-11-21 7:59 UTC (permalink / raw)
To: Philip Oakley; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <00392567F0B045E38A429F95594C1BD2@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> Shouldn't there be some documentation changes to support this very
> useful feature.
I do not agree it is "useful", if it is info/exclude only, which by design
would not propagate across repositories and histories.
If we were to support "precious" as a feature, we should do that properly
with a properly defined syntax (e.g. just like '!' prefix is "no, this is
not 'ignored' entry", use some prefix to say "well, this is ignored in the
sense that not to be tracked, but that does not mean this can be nuked")
that can be in any exclude sources.
Exclude patterns in info/exclude should work just like ones in the in-tree
.gitignore only at different precedence for uniformity and consistency, so
the behaviour J6t showed in the new test should be fixed.
The entries in info/exclude are at lower priority than the ones in in-tree
.gitignore files, which probably was a design mistake, but that is a
separate issue.
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Nguyen Thai Ngoc Duy @ 2011-11-21 8:17 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <4EC9FC81.3080306@viscovery.net>
On Mon, Nov 21, 2011 at 08:23:45AM +0100, Johannes Sixt wrote:
> From: Johannes Sixt <j6t@kdbg.org>
>
> It is an unintended accident that entries matched by .git/info/exclude are
> considered precious, but entries matched by .gitignore are not. That is,
> 'git checkout' will overwrite untracked files matched by .gitignore, but
> refuses to overwrite files matched by .git/info/exclude.
>
> It is a lucky accident: it allows the distinction between "untracked but
> precious" and "untracked and garbage". And it is a doubly lucky accident:
> .gitignore entries are meant for files like build products, which usually
> affect all consumers of a repository, whereas .git/info/exclude is
> intended for personal files, which frequently are precious (think of a
> TODO file).
>
> Add a test that codifies the accident as wanted behavior.
If you want to keep this accident (which is a bug to me), you may want
to add the reason: callers to unpack_trees() are supposed to also
setup exclude rules in .git/info/exclude before calling
unpack_trees(), which they don't.
So .git/info/exclude is entirely dismissed. This patch makes t2023.3
fail. I haven't dug into history to see if this is on purpose though.
-- 8< --
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 2a80772..c2fc2ba 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -412,6 +412,8 @@ static int merge_working_tree(struct checkout_opts *opts,
topts.dir = xcalloc(1, sizeof(*topts.dir));
topts.dir->flags |= DIR_SHOW_IGNORED;
topts.dir->exclude_per_dir = ".gitignore";
+ if (!access(git_path("info/exclude"), R_OK))
+ add_excludes_from_file(topts.dir, git_path("info/exclude"));
tree = parse_tree_indirect(old->commit ?
old->commit->object.sha1 :
EMPTY_TREE_SHA1_BIN);
-- 8< --
--
Duy
^ permalink raw reply related
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Nguyen Thai Ngoc Duy @ 2011-11-21 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <7vsjlhhq33.fsf@alter.siamese.dyndns.org>
On Mon, Nov 21, 2011 at 2:50 PM, Junio C Hamano <gitster@pobox.com> wrote:
> If this is a feature, we would like a patch to Documentation/gitignore.txt
> as well, I think. Also I have a suspicion that this was an unintended
> "regression"; do you have a bisection?
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. "read tree --exclude-per-directory"
is used in git-checkout.sh and the same logic is carried over to
builtin-checkout.c until today.
I guess it's time to add "read-tree --exclude-from". Not sure what to
do with git-checkout though. We may add an option to checkout to skip
either .git/info/exclude or .gitignore, or both.
--
Duy
^ 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