Torstein Hegge he...@resisty.net writes:
When bisect successfully finds a single revision, the first bad commit
should be shown to human readers of 'git bisect log'.
This resolves the apparent disconnect between the bisection result and
the log when a bug reporter says I know that the first
Am 4/15/2013 5:04, schrieb Junio C Hamano:
Ramkumar Ramachandra artag...@gmail.com writes:
... In my proposal, the
precedence order branch.name.pushremote, remote.pushdefault,
branch.name.remote, remote.default, origin, remains the same: we
just want to change which branch that name refers
Johannes Sixt j.s...@viscovery.net writes:
User says:
git push -- master docs release
Then git pushes the three branches to three different upstreams. You find
that confusing. Do I understanding correctly so far?
It is far more subtle than that. User says that while on 'next'
branch.
I've merged a handful more topics to 'next'.
It is likely that I'll be merging kb/status-ignored-optim to
'master' soonish, but as I kept saying this topic touches rather
core part of working tree inspection code, so a fallout from it may
affect not just status -uvarious but more destructive add,
Ping Yin pkufra...@gmail.com writes:
15 git rebase --stash, git pull --rebase --stash
It seems that Ramkumar Ramachandra is working on this in his [PATCH
v2 0/3] Introduce pull.autostash series
Ping Yin
Ah, cool! Added a note to the wiki, thanks,
--
Matthieu Moy
Junio C Hamano wrote:
Relocate to where in the superproject's gitdir? Presumably you can
do this more than once in a given superproject, so there needs to be
a key per such a clone, no? I am guessing that you would follow the
usual when adding a submodule without name, use its path as the
You could continue git clone and then teach git add (or git
submodule add) to relocate the embedded git directory from the
submodule working tree, you could git clone with separate-git-dir
from the beginning, or you could extend git add, perhaps
git add --url=git://up.stre.am/repository
Ramkumar Ramachandra artag...@gmail.com writes:
+stash_required () {
+ ! (git diff-files --quiet --ignore-submodules
+ git diff-index --quiet --cached HEAD --ignore-submodules)
+}
Isn't this too pessimistic? If the local changes do not overlap (in
terms of files) with the pulled
Junio C Hamano wrote:
Any new configuration variable brings its own problem by forcing
existing users to countermand it explicitly from the command line.
If the --separate-git-dir would not work for your application, you
need a new feature and you can achieve the same by adding a new
command
On Mon, Apr 15, 2013 at 12:20:32AM -0700, Junio C Hamano wrote:
Johannes Sixt j.s...@viscovery.net writes:
User says:
git push -- master docs release
Then git pushes the three branches to three different upstreams. You find
that confusing. Do I understanding correctly so far?
Miklos Vajna vmik...@suse.cz writes:
Fix this bug and make sure all arguments are commits, and
for the first non-commit, error out with:
fatal: name: Can't cherry-pick a type
@@ -1067,6 +1068,23 @@ int sequencer_pick_revisions(struct replay_opts *opts)
if (opts-subcommand ==
Matthieu Moy matthieu@grenoble-inp.fr writes:
https://git.wiki.kernel.org/index.php/SmallProjectsIdeas
My $0.02:
* Allow git add -p to use git diff --color-words to show hunks
Check if you can use the existing --word-diff=porcelain output somehow
to get it done in pure perl.
John Keeping wrote:
I may be an atypical user, but my expectation currently is that
branch.name.remote is what is used when I run git push with no
additional arguments.
This is probably because whenever I add additional arguments (currently)
I have to specify where I am pushing to.
So I
Thomas Rast tr...@inf.ethz.ch writes:
My $0.02:
(BTW, feel free to edit the wiki. I've added a few bits from your
message there already).
* Allow git add -p to use git diff --color-words to show hunks
[...]
If neither one is possible my feeling is that it's one of the
hardest tasks on
On Mon, Apr 15, 2013 at 6:19 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
It doesn't make sense as a command-line option, because it is magic
that kicks in only when git clone is executed inside an existing git
worktree. The point is that the user doesn't have to remember
anything
John Keeping j...@keeping.me.uk writes:
I may be an atypical user, but my expectation currently is that
branch.name.remote is what is used when I run git push with no
additional arguments.
This is probably because whenever I add additional arguments (currently)
I have to specify where I am
Junio C Hamano wrote:
That changing the meaning of name in the middle, and doing so
will be confusing to the users, is exactly the issue, isn't it?
Yes, but we have to change _something_ if we don't want to hit a WTF
like 'git push master next' pushing master and next to
branch.HEAD.pushremote.
On Mon, Apr 15, 2013 at 11:24:21AM +0200, Matthieu Moy wrote:
Thomas Rast tr...@inf.ethz.ch writes:
* Allow git send-email --cc 'f...@example.com, b...@example.com' instead
of git send-email --cc f...@example.com --cc b...@example.com
That would be really nice. Bonus points if it
Junio C Hamano wrote:
I do not think it is a red-herring at all. It is not about
breaking, but there will be multiple, conflicting and equally
plausible expectations that makes me worry about unnecessary
confusion.
Well put.
My solution to the problem is to take one of the three
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Any new configuration variable brings its own problem by forcing
existing users to countermand it explicitly from the command line.
If the --separate-git-dir would not work for your application, you
need a new feature and
On Mon, Apr 15, 2013 at 02:47:35PM +0530, Ramkumar Ramachandra wrote:
John Keeping wrote:
I may be an atypical user, but my expectation currently is that
branch.name.remote is what is used when I run git push with no
additional arguments.
This is probably because whenever I add
Duy Nguyen wrote:
If a user is inside .git, I believe setup_git_directory() will also
find correct gitdir. In that case, we do not want magic (i.e. only do
your magic when you are inside worktree). Still I'd rather see no
magic (i.e. command line option) first. Let people try it out for a
Matthieu Moy matthieu@grenoble-inp.fr writes:
Ramkumar Ramachandra artag...@gmail.com writes:
+stash_required () {
+! (git diff-files --quiet --ignore-submodules
+git diff-index --quiet --cached HEAD --ignore-submodules)
+}
Isn't this too pessimistic? If the local changes do
On Mon, Apr 15, 2013 at 06:38:09 +0200, Christian Couder wrote:
I wonder if we should also write something into the bisect log if for
example the bisection stopped because there are only 'skip'ped commits
left to test. But maybe this could go into another patch after this
one.
Yes, that would
On Sat, Apr 6, 2013 at 4:13 AM, Junio C Hamano gits...@pobox.com wrote:
If %C(auto) applies to some %placeholder but not to some others,
the user needs to learn which %placeholder will eat the auto (so
it no longer applies to the next one) and which one will not even
look at auto (so the next
On Mon, Apr 15, 2013 at 02:29:29AM -0700, Junio C Hamano wrote:
- Your branch.*.remote only kicks in when I do not say either what
to push or where to push to, so 'git push -- master' won't be
affected could be one valid natural extension to your knowledge
the config only kicks in
Ramkumar Ramachandra artag...@gmail.com writes:
I specifically did not go down this route, because I think it is
gross. Where does moving a GITDIR fit into what git add's normal job
(index manipulation) is? Tools should do one specific thing, and do
it well: not a mixed bag of unrelated
Junio C Hamano gits...@pobox.com writes:
Yes, that is why I said for pull-merge, --authsquash is neutral-to-better
and pull.autosquash is harmful.
To speak from my experience: I find myself typing git stash git pull
git stash pop relatively often. Typical use-case: I start working on
Junio C Hamano wrote:
When we discuss git add, the one unit of work is at much higher
level than that of git update-index. git add dir/ has to do a
lot more than git add file, and git add symlink has to do quite
a different thing from git add file, but to the end user, all of
them are about
On Mon, Apr 15, 2013 at 7:06 PM, Thomas Rast tr...@inf.ethz.ch wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
https://git.wiki.kernel.org/index.php/SmallProjectsIdeas
My $0.02:
* Allow git add -p to use git diff --color-words to show hunks
Check if you can use the existing
Junio C Hamano wrote:
When you add a submodule with the current system, bypassing git
submodule add, you can either
(1) git clone $URL here and then git add here; or
(2) git init here and then git add here.
Because you didn't say what you are aiming for in the grander
picture, I
On Mon, Apr 15, 2013 at 12:37 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
@@ -417,36 +421,54 @@ static void fill_tracking_info(struct strbuf *stat,
const char *branch_name,
int ours, theirs;
char *ref = NULL;
struct branch *branch = branch_get(branch_name);
Junio C Hamano wrote:
In the end, simple cases (the canonical example being Linus keeping
a local change to Name = Unicycling Gorilla in his Makefile while
running dozens of git pull every day) would not be helped with
this feature very much because there is rarely overlap, while in a
complex
Matthieu Moy wrote:
Isn't this too pessimistic? If the local changes do not overlap (in
terms of files) with the pulled changes, then autosquash is not needed.
There should be a test for the case of non-overlapping changes.
In the pull-rebase case, no; it is not too pessimistic.
In the
On Mon, Apr 15, 2013 at 11:24:21AM +0200, Matthieu Moy wrote:
* git pull --set-upstream
This is vaguely related to another itch that nobody has bothered to
fix: 'git fetch origin foo' should really update origin/foo. This has
been discussed on the list a few times already:
Matthieu Moy wrote:
I disagree. A configuration option is something you set once, and then
forget about. A command, or a command-line option, is something you
explicitely add when you need it.
You're making it out to be a much bigger difference than it actually
is. Users will simply alias
Jeff King p...@peff.net writes:
On Mon, Apr 15, 2013 at 11:24:21AM +0200, Matthieu Moy wrote:
* git pull --set-upstream
This is vaguely related to another itch that nobody has bothered to
fix: 'git fetch origin foo' should really update origin/foo. This has
been discussed on
Torstein Hegge he...@resisty.net writes:
I was wondering why git grep show-ref *.sh gave so few users. It looks
like rev-parse is more common.
It is primarily because show-ref is slightly newer. When you have a
full refname (e.g. refs/bisect/bad) and not an arbitrary object name
that is
Ramkumar Ramachandra wrote:
Okay, so you're proposing a uniform --autostash feature for both merge
and rebase. Sorry, I didn't get it last time due to the typos in your
email; yeah, this is worth investigating.
So, I thought about this and have concluded that pull is the Right
place for
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
In the end, simple cases (the canonical example being Linus keeping
a local change to Name = Unicycling Gorilla in his Makefile while
running dozens of git pull every day) would not be helped with
this feature very much
A few small personal itches off the top of my head:
- Make git status -s show state status as well: this essentially
requires writing an equivalent of wt_status_print_state() for use in
wt_shortstatus_print().
- Make the -s and -b switches in git status configuration variables.
I currently have
Matthieu Moy matthieu@grenoble-inp.fr writes:
I think you're taking it the wrong way. You seem to insist that
autostash should be a pull feature. I think it should be a feature of
merge and rebase, and the convenience script git pull should expose
them to the user.
I see no reason to
Ramkumar Ramachandra artag...@gmail.com writes:
- Make the -3 and -c switches in git am configuration variables. I
have an alias.
- Make failed git am --3way due to unusable index a bit more
helpful. Right now, the information on which hunk failed to apply
is lost, and there is no git
On Fri, Feb 1, 2013 at 5:00 PM, TJ g...@iam.tj wrote:
Using Ubuntu Precise 12.04 with git version (1.8.0.3) I discovered a bug
whereby git-clone deletes the repository
it has just created if there is a GnuTLS error after the final transfer.
I switched to building and using the current git
Ramkumar Ramachandra artag...@gmail.com writes:
Matthieu Moy wrote:
AFAICT, git merge --abort is an alias for git reset --merge
Yes, that is correct.
which
was precisely designed to reset only modifications comming from a merge,
and not the local changes that were present before the merge
On Mon, Apr 15, 2013 at 09:48:22AM +1000, Duy Nguyen wrote:
On Mon, Apr 15, 2013 at 9:25 AM, Adam Spiers g...@adamspiers.org wrote:
The introduction of argc also makes it possible to invoke
check_ignore() with arguments which are not self-consistent.
This is the same problem with main()
Ramkumar Ramachandra artag...@gmail.com writes:
Matthieu Moy wrote:
I disagree. A configuration option is something you set once, and then
forget about. A command, or a command-line option, is something you
explicitely add when you need it.
You're making it out to be a much bigger
Translate 39 new messages came from git.pot update in
c138af5 (l10n: git.pot: v1.8.3 round 1 (54 new, 15 removed)).
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
po/de.po | 186 +--
1 file changed, 97 insertions(+), 89
Matthieu Moy matthieu@grenoble-inp.fr writes:
Ramkumar Ramachandra artag...@gmail.com writes:
Matthieu Moy wrote:
AFAICT, git merge --abort is an alias for git reset --merge
Yes, that is correct.
which
was precisely designed to reset only modifications comming from a merge,
and not
Junio C Hamano wrote:
By tempting the user to use autostash first, you are forcing the
user to say reset --hard (the first one), ORIG_HEAD (to start
from the pre-pull state), stash pop (to recover the autostashed
WIP), to a user who got conflict during stash pop after the pull
integrated the
Ramkumar Ramachandra artag...@gmail.com writes:
A few small personal itches off the top of my head:
- Make git status -s show state status as well: this essentially
requires writing an equivalent of wt_status_print_state() for use in
wt_shortstatus_print().
Do you mean, showing it in a
Junio C Hamano wrote:
git-rebase --autostash
git commit --allow-empty -m 'index part'
git commit --allow-empty -a -m 'working tree part'
git rebase --onto $UPSTREAM
git reset HEAD^
git reset --soft HEAD^
On Mon, Apr 15, 2013 at 4:59 AM, John Keeping j...@keeping.me.uk wrote:
So the question is what is the natural extension of the current
behaviour?, and the answer for me is it's completely new, but others
have different (and conflicting) internal models that give different
answers.
I don't
Matthieu Moy wrote:
No, you don't. Just try if you're not convinced:
Oh, I trusted the documentation on this one and never tried with a
dirty worktree myself. Please fix the documentation, if you know how
exactly to correct it.
No, I'm not proposing to do anything for merge. There's no reason
Michael Haggerty mhag...@alum.mit.edu writes:
It is a nice unit of work and soon will be needed from multiple
locations.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git
Matthieu Moy wrote:
No, they don't. Git forbids redefining commands with aliases. They may
have an alias like git pullauto or so, but not git pull.
Ofcourse, but you get the point. I use p for push, and pu for pull myself.
There's not much we can do about it now, as Git cannot guess whether
On Mon, Apr 15, 2013 at 10:15:54PM +0530, Ramkumar Ramachandra wrote:
Junio's criticism of pull.autostash hurting pull-merge people is
cogent; my current plan is to ditch pull.autostash altogether, and
implement rebase.autostash for the reduced case of a non-interactive
rebase.
Why restrict
John Keeping wrote:
Why restrict it to non-interactive? I'd find it useful when doing
interactive rebases as well - consider the case when you simply want to
re-order some commits.
Actually, I made a mistake: it should be doable for any specific
rebase (includes rebase--interactive,
On Mon, Apr 15, 2013 at 11:39:40AM -0500, Felipe Contreras wrote:
On Mon, Apr 15, 2013 at 4:59 AM, John Keeping j...@keeping.me.uk wrote:
So the question is what is the natural extension of the current
behaviour?, and the answer for me is it's completely new, but others
have different
On Mon, Apr 15, 2013 at 12:13 PM, John Keeping j...@keeping.me.uk wrote:
On Mon, Apr 15, 2013 at 11:39:40AM -0500, Felipe Contreras wrote:
On Mon, Apr 15, 2013 at 4:59 AM, John Keeping j...@keeping.me.uk wrote:
So the question is what is the natural extension of the current
behaviour?, and
Michael Haggerty mhag...@alum.mit.edu writes:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 1df1ccd..f503ec4 100644
--- a/refs.c
+++ b/refs.c
@@ -525,10 +525,14 @@
Michael Haggerty mhag...@alum.mit.edu writes:
Instead of just returning a success/failure bit, return an enumeration
value that explains the reason for any failure. This will come in
handy shortly.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
This is a valid rewrite because
Michael Haggerty mhag...@alum.mit.edu writes:
The old version was inconsistent: when a reference was
REF_KNOWS_PEELED but with a null peeled value, it returned non-zero
for the current reference but zero for other references. Change the
behavior for non-current references to match that of
Michael Haggerty mhag...@alum.mit.edu writes:
if (read_ref_full(refname, base, 1, flag))
return -1;
- if ((flag REF_ISPACKED)) {
+ /*
+ * If the reference is packed, read its ref_entry from the
+ * cache in the hope that we already know its peeled
Michael Haggerty mhag...@alum.mit.edu writes:
Establish an internal API for iterating over references, which gives
the callback functions direct access to the ref_entry structure
describing the reference. (Do not change the iteration API that is
exposed outside of the module.)
Define a new
Michael Haggerty mhag...@alum.mit.edu writes:
A packed reference can be overridden by a loose reference, in which
case the packed reference is obsolete and is never used. The object
pointed to by such a reference can be garbage collected. Since
d66da478f2, this could lead to the emission of
Michael Haggerty mhag...@alum.mit.edu writes:
Stop emitting an error message for dangling packed references found
when deleting another packed reference. See the previous commit for a
longer explanation of the issue.
Change repack_without_ref_fn() to silently ignore dangling packed
Michael Haggerty mhag...@alum.mit.edu writes:
When a reference that existed in the packed-refs file is deleted, the
packed-refs file must be rewritten. Previously, the file was
rewritten without any peeled refs, even if the file contained peeled
refs when it was read. This was not a bug,
Michael Haggerty mhag...@alum.mit.edu writes:
Change the callers convert submodule names into ref_cache pointers.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
A nice cleanup.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
This is another reroll of my patches for glossary-content.txt.
- The first patch is the same as in v2.
- The second patch only adds the log message which Junio suggested and a
missing full stop.
- The third patch is new and is a direct consequence of the second patch.
- In the fourth patch there
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Documentation/glossary-content.txt | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index eb7ba84..5a7a486 100644
---
The name of the hash function is SHA-1, not SHA1.
Also to people who look up object name in the glossary,
the details of which hash function is applied on what to
compute object name is not important but the fact that the
name is meant to be an unique identifier for the contents
stored in the
Use SHA-1 instead of SHA1 whenever we talk about the hash function.
When used as a programming symbol, we keep SHA1.
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Documentation/config.txt | 2 +-
Documentation/git-cat-file.txt| 6
The exact definition of refspec can be found in git-fetch
and git-push manpages. So don't duplicate this here in the glossary.
Actually the definition of pathspec should be moved to a separate
file akin to the way it's done with refspec. But this will only
be wortwhile when there's more to say
Marc Branchaud mbranch...@xiplink.com writes:
In general I think it is a mistake to overload git clone with the notion of
adding a submodule.
I agree with that principle, but my understanding is that this
effort is not about teaching git clone to create a submodule.
Both git clone and git
Marc Branchaud wrote:
git add ssh://host/blammo.git
Heh. And I want git add *coffee* to make me coffee.
What's your gripe with git submodule add?
I could have
~/.git/
to maintain revisions of various personal files, config .dotfiles, scripts in
~/bin/ and so on.
[...]
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
git-rebase --autostash
git commit --allow-empty -m 'index part'
git commit --allow-empty -a -m 'working tree part'
git rebase --onto $UPSTREAM
git
Hi Eric.
I tried --fast-export. It's 2 times faster.
The first thing that differs: in cvsps2 commits with adjacent
timestamps were joined into one (see the attached files). Do you know
the reason?
Does this --fast-export thing support what John mentioned, the
incremental import support? Does
Junio C Hamano wrote:
My
understanding is that this config is about making that option
easier to use when you _know_ any new repository you create with
git clone or git init inside your (toplevel super)project's
working tree will become its submodule, as it is more convenient to
have their
Junio C Hamano wrote:
If rebase -m were to be taught to do this, the natural way to do
so is to
(1) Prepare the todo the usual way
(2) Do those two commits for index and working tree
(3) Append two insns (exec reset HEAD^ and exec reset --soft
HEAD^) at the end of the rebase
Thomas Ackermann th.ac...@arcor.de writes:
fix the idendation of
the first paragraph after the bullet list
That's indentation, I think, and is a good fix.
and remove the one-item
list of magic signatures with its - for the user - unnecessary
introduction of magic word 'top'.
But I do not
Thomas Ackermann th.ac...@arcor.de writes:
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Looks sensible. Thanks.
Documentation/glossary-content.txt | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/Documentation/glossary-content.txt
Thomas Ackermann th.ac...@arcor.de writes:
Use SHA-1 instead of SHA1 whenever we talk about the hash function.
When used as a programming symbol, we keep SHA1.
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Thanks. Will queue as-is for now, but I wonder if we want to fix
them to
On Mon, Apr 15, 2013 at 11:38:20PM +0530, Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
If rebase -m were to be taught to do this, the natural way to do
so is to
(1) Prepare the todo the usual way
(2) Do those two commits for index and working tree
(3) Append two insns (exec
Thomas Rast tr...@inf.ethz.ch writes:
From a cursory glance it looks like it's actually an existing bug in
read_revisions_from_stdin or handle_revision_arg, depending on which way
you look at it. read_revisions_from_stdin passes its temporary buffer
down to handle_revision_arg:
But I do not know if the description of the longhand :(top) is
unnecessary for the user. Is the equivalence between it and :/
described anywhere else in our documentation set?
The only complete documentation for all of this is in setup.c and I must
confess that I missed the subtle
On Mon, Apr 15, 2013 at 11:30:40PM +0530, Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
My
understanding is that this config is about making that option
easier to use when you _know_ any new repository you create with
git clone or git init inside your (toplevel super)project's
Marc Branchaud marcn...@xiplink.com writes:
After that clone or init creates a repository, you still have to
add if you want to make it a submodule to the toplevel.
To me it makes more sense to move the .git directory when the user invokes
git submodule add instead of creating it in an
On 13-04-15 02:00 PM, Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
I do not think the addition Ram is envisioning in the patch will
prevent you from teaching add to do that. An implemention of such
an addition indeed would most likely use the same --separate-git-dir
mechanism anyway.
On 13-04-15 01:50 PM, Junio C Hamano wrote:
Marc Branchaud mbranch...@xiplink.com writes:
In general I think it is a mistake to overload git clone with the notion of
adding a submodule.
I agree with that principle, but my understanding is that this
effort is not about teaching git clone
This patch series addresses several bugs and performance issues in
.gitignore processing.
Patches #1 - #6 fix bugs and add appropriate test cases.
Patch #7 changes handling of ignored tracked directories, as I discovered
that with the current bahavior git-clean can delete tracked content.
'git-status --ignored' drops ignored directories if they contain untracked
files in an untracked sub directory.
Fix it by getting exact (recursive) excluded status in treat_directory.
Signed-off-by: Karsten Blees bl...@dcon.de
---
dir.c | 9 +
'git-status --ignored' lists both the ignored directory and the ignored
files if the files are in a tracked sub directory.
When recursing into sub directories in read_directory_recursive, pass on
the check_only parameter so that we don't accidentally add the files.
Signed-off-by: Karsten Blees
'git-status --ignored' lists ignored tracked directories without any
ignored files if a tracked file happens to match an exclude pattern.
Always exclude tracked files.
Signed-off-by: Karsten Blees bl...@dcon.de
---
dir.c | 11 ---
t/t7061-wtstatus-ignore.sh | 24
'git-ls-files --ignored --directories' hides empty directories even though
--no-empty-directory was not specified.
Treat the DIR_HIDE_EMPTY_DIRECTORIES flag independently from
DIR_SHOW_IGNORED to make all git-ls-files options work as expected.
Signed-off-by: Karsten Blees bl...@dcon.de
---
'git-status --ignored' lists empty untracked directories as ignored, even
though they don't have any ignored files.
When checking if a directory is already listed as untracked (i.e. shouldn't
be listed as ignored as well), don't assume that the directory has only
ignored files if it doesn't have
'git-status --ignored path/' doesn't list ignored files and directories
within 'path' if some component of 'path' is classified as untracked.
Disable the DIR_SHOW_OTHER_DIRECTORIES flag while traversing leading
directories. This prevents treat_leading_path() with DIR_SHOW_IGNORED flag
from
The notion of ignored tracked directories introduced in 721ac4ed dir.c:
Make git-status --ignored more consistent has a few unwanted side effects:
- git-clean -d -X: deletes ignored tracked directories. git-clean should
never delete tracked content.
- git-ls-files --ignored --other
Signed-off-by: Karsten Blees bl...@dcon.de
---
dir.c | 36 ++--
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/dir.c b/dir.c
index f10fb69..594307c 100644
--- a/dir.c
+++ b/dir.c
@@ -751,6 +751,26 @@ int is_excluded_from_list(const char *pathname,
Move prep_exclude in preparation for the next patch.
Signed-off-by: Karsten Blees bl...@dcon.de
---
dir.c | 144 +-
1 file changed, 72 insertions(+), 72 deletions(-)
diff --git a/dir.c b/dir.c
index 594307c..fcb3def 100644
---
1 - 100 of 168 matches
Mail list logo
