Re: [PATCH] bisect: Store first bad commit as comment in log file
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 bad commit is
$rev, as you can see from $(git bisect log).
Signed-off-by: Torstein Hegge he...@resisty.net
---
I don't know how useful the added test is, I didn't find any existing
tests that looks at the comment parts of bisect log.
git-bisect.sh |8 +++-
t/t6030-bisect-porcelain.sh | 18 ++
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 99efbe8..c58eea7 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -311,7 +311,13 @@ bisect_next() {
res=$?
# Check if we should exit because bisection is finished
- test $res -eq 10 exit 0
+ if test $res -eq 10
+ then
+ bad_rev=$(git show-ref --hash --verify refs/bisect/bad)
+ bad_commit=$(git show-branch $bad_rev)
+ echo # first bad commit: $bad_commit $GIT_DIR/BISECT_LOG
As this is # commented out, replaying will safely ignore this new
record, so this should be safe.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] push: introduce implicit push
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 to. 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? In my opinion, it is a much more subtle change than the entirely new precedence order that you're inventing. Adding -- has never been my itch. I just brought it up out of thin air as a possible alternative that is less confusing. 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? If I were a push.default=(simple|upstream) type, then I would be totally aware that there are three different upstreams involved because I had had to configure them manually and explicitly (correct?), and I would be completely surprised if the push would *not* go to three different upstreams. Just my 2 cents. (But I'm a traditional matching type, so take this with a grain of salt. Or I may be missing the point of this thread, as I haven't followed closely.) -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] push: introduce implicit push
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. The user has been trained to think branch.master.remote takes effect while he has master branch checked out. That is where the possible confusion comes from. As I said number of times, you may be able to declare that the confusion is unfounded once you think it through. Just my 2 cents. (But I'm a traditional matching type, so take this with a grain of salt. Or I may be missing the point of this thread, as I haven't followed closely.) For exmaple, see cf. http://thread.gmane.org/gmane.comp.version-control.git/218429/focus=220707 where I say branch.next.remote should not come into play when I say git push --master docs release while on the next branch and Peff gives a counter-viewpoint. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
No What's cooking yet, but...
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, rm. A final eyeballing of the topic is very much appreciated. Also I've ejected nd/magic-pathspecs and as/check-ignore topics from 'pu' for now, as the former when taken with jl/submodule-mv were somehow breaking the tests (I was running the integration run for 'pu' without 5301, 5700, 7001 and 7408 for a few days), and the latter topic did not play well with kb/status-ignored-optim topic. We may want to revisit them after having a few more topics graduate to 'master' first and then ask them to be rebased. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ensimag students projects, version 2013
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 http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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 initial name convention, but then I would suggest it to be spelled out (and if you are doing it differently, that choice needs to be spelled out and defended). I probably wasn't clear enough in the commit message, but this is what happens when I set clone.submoduleGitDir to ~/bare: a git clone gh:artagnon/clayoven inside the superproject's worktree will make ~/bare/clayoven.git and ./clayoven corresponding to the GITDIR and the worktree of the newly cloned repository. If there are conflicts, it will complain as usual saying that the destination path %s already exists, in which case the user has to choose a name for the GITDIR (not yet implemented) and/or the worktree path (as the final command-line argument to git clone). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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 [--name=name] sub/mod/ule and do that git clone --separate-git-dir internally (which will mean that the end user will not run git clone). 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 things. git clone, on the other hand, was always intended to have a way to point to a location for GITDIR and the worktree: isn't this feature very close to --separate-git-dir already? It is, therefore, git clone's job to relocate the GITDIR. My future plan is to deny git add'ing anything but a worktree-with-a-gitfile. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 changes, then autosquash is not needed.
There should be a test for the case of non-overlapping changes.
+if test $autostash = true stash_required
+then
+ git stash || die $(gettext Cannot autostash)
+ require_clean_work_tree pull Please commit or stash them.
+ if eval $eval
+ then
+ git stash pop || die $(gettext Cannot pop stash)
+ else
+ exit_code=$?
+ echo Please run 'git stash pop' after commiting the conflict
resolution.
+ exit $exit_code
+ fi
+else
+ eval exec $eval
+fi
Shouldn't this belong to git merge instead (i.e. implement git merge
--autosquash and call it from git pull)? Users doing git fetch
git merge by hand should be able to use --autosquash, I think.
Something should be done for git rebase and git pull --rebase too.
In this case, the UI can be much smoother, since the user would have to
run git rebase --continue anyway, so you can do the auto-stash-pop for
him by adding something like exec git stash pop at the end of the todo-list.
Ideally, git rebase --abort should auto-stash-pop too, although this
is much less trivial to implement.
Maybe a good first step is to implement --autosquash only for non-rebase
pull, and later to implement git rebase --autosquash and call it from
git pull.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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 line option (say, --submodule-git-dir), that would be more preferrable. I'm getting a little tired of your first instinct to oppose every new addition to git. (Ofcourse I understand your attitude as the maintainer, but still) 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 special: a normal git clone already does the right thing outside a git worktree; my proposal is to make it do the right thing inside a git worktree as well. Although I'm not against allowing a user to create a full clone inside a git repository by overriding clone.submoduleGitDir via a command-line option, I really cannot see why this would be anything but rare. Why would a user *want* a full clone inside a git worktree? Also, naming it --submodule-git-dir can cause a lot of confusion: --separate-git-dir names a specific directory to put the GITDIR in, while --submodule-git-dir names a directory inside which to create other named directories to put GITDIRs in. Ofcourse clone.submoduleGitDir is a bad name too: any suggestions? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] push: introduce implicit push
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? It is far more subtle than that. User says that while on 'next' branch. The user has been trained to think branch.master.remote takes effect while he has master branch checked out. That is where the possible confusion comes from. As I said number of times, you may be able to declare that the confusion is unfounded once you think it through. 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 think breaking user expectations is a red herring here because the current behaviour means that users cannot have any expectation of what will happen in this case. Either you don't say anything and git push DTRT for your current branch or you must specify precisely what you want to happen (or at least the remote to use if you have push.default = matching or remote.name.mirror set). Personally I'd vote for git push -- master pushing to remote.pushdefault, but I really don't know how you handle git push -- with the naïve implementation of that - is it the same as git push or git push $(git config remote.pushdefault)? On the other hand, I'm really not sure how often I'd use this feature. Normally I just use git push and if I'm giving any more arguments than that then it's for something that I don't do often enough for it to be worth setting up configuration. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] cherry-pick: make sure all input objects are commits
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 == REPLAY_CONTINUE)
return sequencer_continue(opts);
+ for (i = 0; i opts-revs-pending.nr; i++) {
+ unsigned char sha1[20];
+ const char *name = opts-revs-pending.objects[i].name;
+
+ /* This happens when using --stdin. */
+ if (!strlen(name))
+ continue;
This is undefined behavior; the pending.objects[i].name has been freed
already. Luckily valgrind points you right at it:
==9178== Invalid read of size 1
==9178==at 0x4CEFB4: sequencer_pick_revisions (sequencer.c:1077)
==9178==by 0x45E7F2: cmd_cherry_pick (revert.c:236)
==9178==by 0x40523C: handle_internal_command (git.c:292)
==9178==by 0x405467: main (git.c:500)
==9178== Address 0x5bedbd0 is 0 bytes inside a block of size 1,001 free'd
==9178==at 0x4C2ACDA: free (vg_replace_malloc.c:468)
==9178==by 0x4D96C7: strbuf_release (strbuf.c:40)
==9178==by 0x4C9AAE: setup_revisions (revision.c:1285)
==9178==by 0x45E6FA: parse_args (revert.c:203)
==9178==by 0x45E7EA: cmd_cherry_pick (revert.c:235)
==9178==by 0x40523C: handle_internal_command (git.c:292)
==9178==by 0x405467: main (git.c:500)
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:
struct strbuf sb;
[...]
strbuf_init(sb, 1000);
while (strbuf_getwholeline(sb, stdin, '\n') != EOF) {
[...]
if (handle_revision_arg(sb.buf, revs, 0,
REVARG_CANNOT_BE_FILENAME))
die(bad revision '%s', sb.buf);
}
But handle_revision_arg ends up just stuffing that parameter into the
revision-walker options via some helpers:
add_rev_cmdline(revs, object, arg_, REV_CMD_REV, flags ^ local_flags);
add_pending_object_with_mode(revs, object, arg, oc.mode);
This seems to have been lurking since 281eee4 (revision: keep track of
the end-user input from the command line, 2011-08-25).
Junio, at which level should we fix it? We could of course have
read_revisions_from_stdin make a copy of the buffers it passes down, but
perhaps it would be less surprising to instead have handle_revision_arg
make sure it makes a copy of everything it keeps?
The easy fix of course is just this:
diff --git i/revision.c w/revision.c
index 3a20c96..181a8db 100644
--- i/revision.c
+++ w/revision.c
@@ -1277,7 +1277,8 @@ static void read_revisions_from_stdin(struct rev_info
*revs,
}
die(options not supported in --stdin mode);
}
- if (handle_revision_arg(sb.buf, revs, 0,
REVARG_CANNOT_BE_FILENAME))
+ if (handle_revision_arg(xstrdup(sb.buf), revs, 0,
+ REVARG_CANNOT_BE_FILENAME))
die(bad revision '%s', sb.buf);
}
if (seen_dashdash)
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ensimag students projects, version 2013
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. Alternatively, try to hack a word-diff
mode where it spews out both the line-diff (for later application) and
the word-diff (for display) in some clever format, so that the perl
code can easily match them up. If neither one is possible my feeling
is that it's one of the hardest tasks on the list. (Not to
discourcage anyone from trying, but still.)
* 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:
http://thread.gmane.org/gmane.comp.version-control.git/192252
http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758
which by the way would be a *great* thing to fix, hint hint ;-) and
since Peff already posted a POC patch in the first thread, it's
probably not that hard. (Peff?)
* 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 handles continuation
lines etc. correctly, so that it's even easier to paste.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] push: introduce implicit push
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 think breaking user expectations is a red herring here because the current behaviour means that users cannot have any expectation of what will happen in this case. Either you don't say anything and git push DTRT for your current branch or you must specify precisely what you want to happen (or at least the remote to use if you have push.default = matching or remote.name.mirror set). Personally I'd vote for git push -- master pushing to remote.pushdefault, but I really don't know how you handle git push -- with the naïve implementation of that - is it the same as git push or git push $(git config remote.pushdefault)? We're not changing, or even discussing, what a plain git push without destination or refspecs specified should do (yes, that means git push -- too); it depends on push.default, which already exists. My proposal does not aim to change the current behavior of _any_ current invocation (that means git push, git push origin master, git push next master v1.2, and so on). It aims to make the new syntax git push master +next behave logically. I think we can all agree that the logical solution (leaving aside founded/ unfounded user expectations) is to pick destinations for each of the branches specified individually. As I explained in my last email, using remote.pushdefault is Wrong because it treats branches like tags, and invents a new precedence. Voting without a basis is useless: do you have a counter-argument for the points I raised as to why it is Wrong? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ensimag students projects, version 2013
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 the list. (Not to discourcage anyone from trying, but still.) Yes, this was already inferable from the See also the GSoC proposal statement and our discussions on GSoCs on this list ;-). It's not funny if all projects are easy, but it's not a coincidence if this idea has been there for a while without being implemented. * 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: http://thread.gmane.org/gmane.comp.version-control.git/192252 http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758 which by the way would be a *great* thing to fix, hint hint ;-) and since Peff already posted a POC patch in the first thread, it's probably not that hard. (Peff?) My understanding is that this would be technically easy to fix, but a migration plan is needed, which isn't easy for a one-shot, one-month contribution. I've added it to the wiki. * 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 handles continuation lines etc. correctly, so that it's even easier to paste. Added to the wiki too. Thanks, -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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 special: a normal git clone already does the right thing outside a git worktree; my proposal is to make it do the right thing inside a git worktree as well. Although I'm not against allowing a user to create a full clone inside a git repository by overriding clone.submoduleGitDir via a command-line option, I really cannot see why this would be anything but rare. Why would a user *want* a full clone inside a git worktree? 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 while. If people like it and find it inconvenient, magic can come later. I suspect you might want more magic in other places. Maybe if you hold it back until you see full picture, you'll only need a few new config keys (instead of one per separate magic). Unfortunately, this patch is in pathetic shape and is an RFC for three reasons: 1. I've used setup_git_directory_gently() at the start of builtin/clone.c to check if I'm inside a git directory. This breaks a lot of existing tests (I'm yet to understand these failures fully). 2. setup_git_directory_gently() has the side-effect of changing the current directory and calling set_git_work_tree(), both of which must be done away with if we want the rest of clone.c to work. I've hacked around the issue in a very dirty manner. What is the solution to this? Just do what scripts do: spawn a process to run rev-parse so that it does not mess up the main process. You might be able to introduce dry-run mode for setup_git_directory(), but that won't be easy. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] push: introduce implicit push
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 pushing to. So I think breaking user expectations is a red herring here because the current behaviour means that users cannot have any expectation of what will happen in this case. The thing is, people _want_ to reuse the knowledge they have already learned to a situation it does not directly apply to, by finding a consequence, natural extension of that knowledge, applied to a new situation. - 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 when I do not say either. - Peff's 'git push' chooses to push to branch.next.remote when I am on 'next', so 'git push -- master' run in the same state should also push to that place is another equally valid natural extension to his knowledge that 'git push' chooses to push to branch.next.remote when I am on 'next'. - Ram's and my branch.master.remote is about what remote my master branch integrates with, so no matter where I am, 'git push' that does not say where-to should push out my master to that remote is yet another equally valid natural extension to our knowledge that branch.master.remote is about what remote my master branch integrates with. 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] push: introduce implicit push
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. In my opinion, this seems to be the less evil (or disruptive) change. After all, we're not proposing to change the current behavior of any current git invocations: a plain git push can still consider branch.HEAD.pushremote, and it's not a problem in my opinion. After all, a git fetch also considers branch.HEAD.remote, and we all agree that this is fine. 1. We are changing the meaning of branch.name.remote, but this is not inconsistent with the current behavior of push.default at all (even push.default=matching). We just have to improve the push.default documentation. 2. We are not changing the meaning of _any_ existing git push invocations. Pushing unrelated branches to the corresponding remote has not been possible until now (unless you check out each of the branches, set push.default=current, and git push), and we're inventing a new syntax that makes this possible. I see no problem with changing the meaning of branch.name.remote/pushremote for this purpose. Just like Peff, I am sympathetic to people who want to omit where to and have Git automatically make a guess, and would be happy if we can find a reasonable solution to that problem. But I am not convinced what we discussed in these threads are good solutions. At least not yet. There are only so many possibilities, Junio*. You either decide that the logical alternative that I proposed is too confusing and drop the idea, or think about how to move forward minimizing friction. * If you think there are other possibilities, I'd be glad to hear them. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ensimag students projects, version 2013
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 handles continuation lines etc. correctly, so that it's even easier to paste. Added to the wiki too. As an extension to this, it would be really nice if I could say git send-email --reply-to file, feeding it an existing message. This would set To and Cc appropriately but also quote the existing message for me to reply to, either into the cover letter or after the --- in the patch (it's probably an error if there's no cover letter and more than one patch in this mode). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] push: introduce implicit push
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 alternatives, and show how it plugs into the larger workflow picture; in this case, how my proposal fits into the larger picture of a local clone being a collection of branches, each having little triangles. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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 you can achieve the same by adding a new command line option (say, --submodule-git-dir), that would be more preferrable. I'm getting a little tired of your first instinct to oppose every new addition to git. (Ofcourse I understand your attitude as the maintainer, but still) It was purly about do not add anything that makes no sense. and not about oppose all new addition. 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 thought you were making the UI simpler by making it unnecessary for the users to say git clone himself as a separate step before doing git add. In such a world, add would internally run clone. If that were the case (I now know it is not), then the configuration _is_ unnecessary, and it is perfectly valid to question why you thought it is needed. If your plan is instead to keep git clone followed by git add as the pattern for use case (1), teaching clone to automatically use the --separate-git-dir mechanism to point at the right place inside the $GIT_DIR of the superproject does make sense to help the use case. But if that is the direction you are aiming for, would it be possible that the same configuration variable can and should cover the use case (2) as well? After all, between git init here and git add here, the user may say (cd here git pull $URL) and the expected end result would be the same as (1), no? I do not recall the details of the codepaths involved offhand, but when you git clone $URL [here], after running mkdir here, it would create a $GIT_DIR for the here repository in here/.git (and with --separate-git-dir, it would create it elsewhere and drop gitfile at here/.git). When you git init here, after running mkdir here, the same thing happens. How common are these two implementations? If clone just calls init_db(), I would imagine that it might be trivial to cover both cases by telling init_db() to pay attention to the configuration, without doing much in the clone itself. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] push: introduce implicit push
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 additional arguments (currently) I have to specify where I am pushing to. So I think breaking user expectations is a red herring here because the current behaviour means that users cannot have any expectation of what will happen in this case. Either you don't say anything and git push DTRT for your current branch or you must specify precisely what you want to happen (or at least the remote to use if you have push.default = matching or remote.name.mirror set). Personally I'd vote for git push -- master pushing to remote.pushdefault, but I really don't know how you handle git push -- with the naïve implementation of that - is it the same as git push or git push $(git config remote.pushdefault)? We're not changing, or even discussing, what a plain git push without destination or refspecs specified should do (yes, that means git push -- too); it depends on push.default, which already exists. My proposal does not aim to change the current behavior of _any_ current invocation (that means git push, git push origin master, git push next master v1.2, and so on). It aims to make the new syntax git push master +next behave logically. I think we can all agree that the logical solution (leaving aside founded/ unfounded user expectations) is to pick destinations for each of the branches specified individually. As I explained in my last email, using remote.pushdefault is Wrong because it treats branches like tags, and invents a new precedence. Voting without a basis is useless: do you have a counter-argument for the points I raised as to why it is Wrong? As Junio says in his parallel message, there are different opinions here, my suggestions was to effectively replace -- with the value of remote.pushdefault. I don't think your solution is not logical, but I don't think it is the unique logical solution. The problem is that people have different opinions of what the current situation means, resulting in different expectations of what push without a remote should do. Whatever behaviour we choose /will/ be surprising to some users, even though it is completely logical. That much is clear from the differing opinions in this thread. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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 while. If people like it and find it inconvenient, magic can come later. I suspect you might want more magic in other places. Maybe if you hold it back until you see full picture, you'll only need a few new config keys (instead of one per separate magic). Good suggestion. I'll make it a command-line option for now. Just do what scripts do: spawn a process to run rev-parse so that it does not mess up the main process. You might be able to introduce dry-run mode for setup_git_directory(), but that won't be easy. Okay, thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 not overlap (in
terms of files) with the pulled changes, then autosquash is not needed.
Yes, that is why I said for pull-merge, --authsquash is neutral-to-better
and pull.autosquash is harmful.
But for pull-rebase folks, I can understand why this working tree
must be squeakily clean logic is appropriate, if we were to do
this. The root cause is because rebase insists to be run on such a
working tree.
And the worst part is that in order to check if local changes
overlap, you need to fetch first. But Ram's annoyance is about the
user being told the merge/rebase cannot proceed _after_ fetch is
done.
Shouldn't this belong to git merge instead (i.e. implement git merge
--autosquash and call it from git pull)? Users doing git fetch
git merge by hand should be able to use --autosquash, I think.
See my other message. I do not think autosquash would help merge
folks very much, and will actively hurt when it matters.
Something should be done for git rebase and git pull --rebase too.
That I would agree. I am not sure autosquash is the best approach,
but we should be able to help them more.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bisect: Store first bad commit as comment in log file
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 be useful, but I wasn't able to determine all the cases
that would be relevant to log. Only skipped commits left to test is one,
but bisect--helper also exits on various problems related to merge base
handling. The handling of problems related to inconsistent user input is
probably not relevant to log.
I think the successful bisect case is most important to log and the one
that requires the least amount of invasive changes.
diff --git a/git-bisect.sh b/git-bisect.sh
index 99efbe8..c58eea7 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -311,7 +311,13 @@ bisect_next() {
res=$?
# Check if we should exit because bisection is finished
- test $res -eq 10 exit 0
+ if test $res -eq 10
+ then
+ bad_rev=$(git show-ref --hash --verify refs/bisect/bad)
I had a look to make sure that refs/bisect/bad always refered to the
first bad commit at this point, and it is true indeed.
According to Documentation/git-bisect.txt, refs/bisect/bad is the proper
way to determine the first bad commit at the end of a bisection.
Maybe you could have used git rev-parse --verify instead of git
show-ref --hash --verify. It looks simpler to me.
I was wondering why git grep show-ref *.sh gave so few users. It looks
like rev-parse is more common.
And maybe, just in case, you could have added: || die $(gettext Bad rev:
refs/bisect/bad)
Yes, I should probably have done that.
Otherwise this patch looks good to me.
Thanks.
Torstein
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/12] pretty: add %C(auto) for auto-coloring on the next placeholder
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 %placeholder is affected by the auto, i.e. making the effect of auto skip a %placeholder). If the rule were %C(auto) applies to -next- placeholder, then the user does not have to worry about which ones are what you call textual and which ones are not (and there is no textual placeholder defined in the glossary). That would make it harder to learn. It would be much easier to explain if you said %C(auto) affects the next %-placeholder and then resets. So far (after this series, that is), we have two modifiers: %C(auto) and % (and friends). Both can be used to modify the next placeholder, so either of them must learn to ignore the next non-textual placeholder... I wonder if Everything after %C(auto) will not be coloured if the output is not going to the terminal., i.e. not resetting once colouring decision is made, makes more sense, though... .. or we do this, which makes % and friends the only placeholders that care about the next one. Thanks for the idea. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] push: introduce implicit push
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 when I do not say either. - Peff's 'git push' chooses to push to branch.next.remote when I am on 'next', so 'git push -- master' run in the same state should also push to that place is another equally valid natural extension to his knowledge that 'git push' chooses to push to branch.next.remote when I am on 'next'. - Ram's and my branch.master.remote is about what remote my master branch integrates with, so no matter where I am, 'git push' that does not say where-to should push out my master to that remote is yet another equally valid natural extension to our knowledge that branch.master.remote is about what remote my master branch integrates with. 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. Okay, I think it's a red herring from my point of view that this is something new that is very different from the current functionality, but as you point out, no arguments vs. some arguments is only one potential internal model of the current behaviour. 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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 things. I see you are trying to repeat the UNIX mantra, but I do not think it is working. 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 doing everything necessary to add what the user named to the index. git add submodule/ that does whatever necessary to add the submodule to the index is still doing one thing well inside the same framework, and that may include moving the $GIT_DIR and turning it into a gitfile. Not that I am saying I prefer add --url=xxx. Quite the opposite. I very much prefer the clone and then add, but clone drops the repository at the right place from the beginning approach than add that knows about URL only for submodules, which is an ugly kludge. If the user creates here/.git without gitlink with whatever means, it is git add here's job, if it wants to make it a submodule and if it wants to make it possible to later check out another branch that does not have the submodule, to stash away the repository and turn it into gitfile, if it is part of what is needed to add a submodule. Of course, we could start from teaching submodule add to do so, and then internally redirect git add subm to git submodule add, but that is a minor implementation detail that does not affect the end user experience. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 something, a colleague works on the same thing and I need to see what he did to continue. Probably not something so frequent for large projects, but very frequent for small projects (e.g. writing a paper together with a single .tex file and the deadline approaching). In this case, git pull --rebase makes sense for advanced enough users, but newbies who have been told rebase is too dangerous for you, don't use it, it would be cool to have --autostash too. I tend to agree that pull.autostash is harmful. At least in its current form, it is really too easy to overlook the Please run 'git stash pop' after commiting the conflict resolution. message: do some important changes $ git pull fix conflicts $ git status tells me to commit $ git commit WTF, where are my important changes?!? rebase wouldn't have this issue if stash pop is part of the sequence to apply. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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 doing everything necessary to add what the user named to the index. git add submodule/ that does whatever necessary to add the submodule to the index is still doing one thing well inside the same framework, and that may include moving the $GIT_DIR and turning it into a gitfile. You're looking at it from an end-user point of view, while I'm looking at it from the implementation point of view. Here's a coarse simplification of what git add does: 1. Lock the index file, and grab a FILE handle to read/ write the file. 2. Update active_cache. Depending on the pathspec, we might be adding one entry or multiple entries, with different modes to the index. Nowhere did I say that it should add exactly one entry to active_cache with a predefined mode. Sure, tools that operate a lower layer of abstraction like update-index can be more picky about this. 3. Write tree and blob objects to the database corresponding to the worktree entries. Files and symbolic links get blob objects, while directories get tree objects. 4. Write active_cache to FILE handler we grabbed in step 1, and release the lock. What it does not do: 1. Move random files/ directory around in the worktree. 2. Mangle existing files in the worktree. (Although I know that the .gitmodules-mangling is coming soon, I'm not exactly elated with it [1]) 3. Write commit or tag objects to the database. 4. Update random refs. 5. Make coffee for the user to applaud him on the successful add. In my opinion, with some minor exceptions, all git tools follow these principles. Briefly, branch is a refs/heads/* helper, checkout is a HEAD + worktree helper, fetch is a receive-pack + refs/remotes/* helper, and reset is a bit of a swiss army knife that operates on HEAD + index + worktree. In general, I like git because commands don't create unnatural or heavy abstractions on top of these concepts. With some minor exceptions, all the commands are easy to understand and consistent. [1]: This is what led to my OBJ_LINK proposal. Not that I am saying I prefer add --url=xxx. Quite the opposite. I very much prefer the clone and then add, but clone drops the repository at the right place from the beginning approach than add that knows about URL only for submodules, which is an ugly kludge. I don't know why you brought up the alternative in the first place. We both agree that it is git clone's job, although your reason is more superficial and mine's tied to the implementation. If the user creates here/.git without gitlink with whatever means, it is git add here's job, if it wants to make it a submodule and if it wants to make it possible to later check out another branch that does not have the submodule, to stash away the repository and turn it into gitfile, if it is part of what is needed to add a submodule. I disagree. I think we should get a first-class tool to attach/ detach worktrees from a GITDIR. It can incoporate the logic from contrib/workdir/git-new-workdir to optionally create a worktree with an independent index, HEAD, and logs/HEAD. Of course, we could start from teaching submodule add to do so, and then internally redirect git add subm to git submodule add, but that is a minor implementation detail that does not affect the end user experience. Yuck. Don't you care about the implementation, as long as it fixes the end-user's problem? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ensimag students projects, version 2013
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 --word-diff=porcelain output somehow to get it done in pure perl. Alternatively, try to hack a word-diff mode where it spews out both the line-diff (for later application) and the word-diff (for display) in some clever format, so that the perl code can easily match them up. If neither one is possible my feeling is that it's one of the hardest tasks on the list. (Not to discourcage anyone from trying, but still.) Yes, please.. Also in some case, I'd like to pass the pattern to --color-words (usually just --color-words=.). Something for the student to think about when designing the interface. * 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 handles continuation lines etc. correctly, so that it's even easier to paste. * Color the header lines in git send-email. Bonus point if it could highlight possible typos like f...@example.co. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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 thought you were making the UI simpler In the original email, I wrote: Okay, so this is part of my evil plan to make 'git add' DTRT wrt submodules, and deprecate 'git submodule add' (I have some code written down, but this is a prerequisite: I don't like the .git/modules nonsense). I'm not sure how you inferred making the UI simpler from that, or the tests. by making it unnecessary for the users to say git clone himself as a separate step before doing git add. In such a world, add would internally run clone. If that were the case (I now know it is not), then the configuration _is_ unnecessary, and it is perfectly valid to question why you thought it is needed. No, I would _never_ propose something that ugly. Neither my code, tests, nor my commit message indicates that I was going in that direction, so I don't know where you got the idea from. But if that is the direction you are aiming for, would it be possible that the same configuration variable can and should cover the use case (2) as well? After all, between git init here and git add here, the user may say (cd here git pull $URL) and the expected end result would be the same as (1), no? Good point. Yes, I would definitely want that. If clone just calls init_db(), I would imagine that it might be trivial to cover both cases by telling init_db() to pay attention to the configuration, without doing much in the clone itself. Right. I'll start hacking. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] branch: colour upstream branches
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); + struct strbuf fancy; + + strbuf_init(fancy, 0); Nitpick. You could have done struct strbuf fancy = STRBUF_INIT;. No need to resend, I think, unless there are other changes. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 case the user really needs help to save away his WIP, the user is forced to resolve the conflict immediately upon the failed stash pop at the end of git pull. If the conflict turns out to be something the user would not want to resolve at that moment, the user needs to know the way out, something like: git reset --hard;# go back to the result of pull git checkout -b wip ORIG_HEAD ;# start from before the pull git stash pop ;# recover his wip ... perhaps work a bit more ... git commit -a -m wip;# save it away for safety git checkout - ;# result of pull so that he can come back tomorrow, check out wip branch, and decide what to do. What does this have to do with pull at all? git-pull.sh is a simple shell script that runs fetch followed by a merge or rebase. You're handling a merge now, and there's proper support for it in the tool; git merge --abort will work with one caveat: If there were uncommitted worktree changes present when the merge started, git merge --abort will in some cases be unable to reconstruct these changes. It is therefore recommended to always commit or stash your changes before running git merge., to directly quote the manpage. Really, it has the same problem as rebase, if you want --abort to work. Fixing git merge --abort and git rebase are topics for another day. What I'm doing it making it easier to work with the merge/rebase following the fetch by automatically stashing worktree + index changes. The --autosquash option (or not adding either the configuration or the option) would encourage the user to think about the nature of WIP he has in the working tree before running git pull. I'm lost. What does git rebase --autosquash (or rebase.autosquash) have anything to do with git pull --autostash? Is it a too complex beast that may interfere with what others are doing, or is it a trivial change that he can stash away and pop it back? If the former, he will be far better off doing checkout -b, keep working until the local change gets into somewhat a better shape and commit, before pulling into the original branch. A pull-merge person having complex worktree changes should not execute git pull blindly in the first place. That's what git fetch is for: inspect the incoming changes, and decide how to integrate it into the local branch. git pull is a tool that serves an entirely different purpose, in my opinion. But I suspect that pull.autostash configuration is not a good addition because it encourages a bad, pain-inducing workflow. In simple cases it may not hurt, but when local changes are complex, it would actively hurt than not having it, and the configuration robs the incentive to choose. But I'm a pull-rebase guy, and I always want pull.autostash. Will you deny me the configuration variable, simply because it is potentially pain-inducing to pull-merge people who set it blindly and run git pull blindly? I'm not arguing linking pull.autostash to pull.rebase either: my change is admittedly useful to *some* pull-merge people. And I'm not arguing for making it true by default. The equation is somewhat different for pull-rebase, as rebase insists you to start from a clean working tree, so download and then stop annoyance feels bigger. I have a suspicion that loosening that may be a more productive fix to the real problem. Rebase performs relatively simple operation on the worktree, and I would like to keep it that way. I have no desire to fix rebase. (require_clean_work_tree --quiet) || git stash Good point. Will fix in the next iteration. This cannot pop stash is really where the user gets in the deep yoghurt and needs help. Yes, and your point being? That life would've been easier if the user had committed all those changes in the first place? And that the penalty for not having done that is now a git checkout wip ORIG_HEAD; git stash pop; git checkout master; git rebase wip? Please resolve conflicts and commit, and then 'git stash pop'. Cool, will fix. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 pull-merge case, maybe: if your worktree isn't clean, you lose a lot of goodies like merge --abort anyway, and I hate that. Secondly, it's impossible to determine whether the changes overlap or not before actually running merge_trees(). If there were an easy way to do it, I might have considered it. Overall, I don't see how an extra stash/ stash pop where not absolutely necessary hurts. Shouldn't this belong to git merge instead (i.e. implement git merge --autosquash and call it from git pull)? Users doing git fetch git merge by hand should be able to use --autosquash, I think. --autosquash reminds me of rebase.autosquash, and that is completely unrelated to the issue at hand. Did you mean git merge --squash (to update the worktree/index but not create the actual commit?). Sure, it's probably useful to have a merge.squash configuration variable, but I don't see what it has to do with the pull.autostash I'm proposing. Something should be done for git rebase and git pull --rebase too. In this case, the UI can be much smoother, since the user would have to run git rebase --continue anyway, so you can do the auto-stash-pop for him by adding something like exec git stash pop at the end of the todo-list. No. I'm against executing a special codepath for a pull-rebase that has no equivalent in the pull-merge world. Or did you mean: have one configuration variable to git merge --squash and do this for git rebase, as if they're equivalent from the pull perspective? No, they aren't. Ideally, git rebase --abort should auto-stash-pop too, although this is much less trivial to implement. As I already pointed out in my message to Junio, fixing rebase is not the topic of discussion at all. Maybe a good first step is to implement --autosquash only for non-rebase pull, and later to implement git rebase --autosquash and call it from git pull. Implement git rebase --autosquash? If I just set rebase.autosquash to true, the rebase will automatically autosquash whether called from git pull or otherwise. Sorry, I just don't understand what you're saying. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ensimag students projects, version 2013
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: http://thread.gmane.org/gmane.comp.version-control.git/192252 http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758 which by the way would be a *great* thing to fix, hint hint ;-) and since Peff already posted a POC patch in the first thread, it's probably not that hard. (Peff?) My understanding is that this would be technically easy to fix, but a migration plan is needed, which isn't easy for a one-shot, one-month contribution. Yes. The concept isn't that hard, but the question was one of whether it would break some obscure workflows. But I don't remember all of the details; I think I gave some examples in past threads. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 pull to 'pull --autostash' (a lot of them already alias it to pull --ff-only, and I'm going to fix this soon). The decision making process for creating a configuration variable shouldn't be this is potentially dangerous, and therefore therefore it shouldn't be a configuration variable, but rather this is a rarely used option that users only need 50% of the time, and therefore it shouldn't be a configuration variable. In my case, pull.autostash is my 90~95% usecase, and I'm not unique in this aspect. Therefore, it should be a configuration variable that can be consciously turned off with a --no-autostash. If your criticism were that git status doesn't show stash state, I agree with you. However, I don't agree with basing it on user forgetfulness in having set pull.autostash a long time ago + lack of observation skills to notice the message printed by git pull. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ensimag students projects, version 2013
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 the list a few times already: http://thread.gmane.org/gmane.comp.version-control.git/192252 http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758 which by the way would be a *great* thing to fix, hint hint ;-) and since Peff already posted a POC patch in the first thread, it's probably not that hard. (Peff?) My understanding is that this would be technically easy to fix, but a migration plan is needed, which isn't easy for a one-shot, one-month contribution. Yes. The concept isn't that hard, but the question was one of whether it would break some obscure workflows. But I don't remember all of the details; I think I gave some examples in past threads. I think the one Thomas lists in $gmane/165758 is the one. It has been the way for users to make sure that origin/master stays put to explicitly tell Git not to update the remote tracking branch using a refspec without colon, so that they can do git fetch origin master git log origin/master..FETCH_HEAD (or its three-dot variant) to gauge the progress of the other side since the last time the user observed. Personally I doubt this trick is so relevant these days, not just because we can look at reflog of origin/master. The user could just do old=$(git rev-parse origin/master) git fetch origin master git log $old..FETCH_HEAD even with a modified Git that updates the remote tracking branches without a storing refspec. The primary reason why I do not think this is relevant these days is because the original premise remote tracking branches keep what the last 'git fetch' observed has already been broken for a long time. The users are better off thinking that the remote tracking branches can be updated any time (not just the last 'git fetch') when Git observes (or could observe) the state of the remote without being told explicitly with today's pretend as if we fetched immediately after we push behaviour. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bisect: Store first bad commit as comment in log file
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 spelled in a random way (e.g. master~24): show-ref --verify refs/bisect/bad is a perfectly valid way to make sure it _is_ an existing ref. Cf. 358ddb62cfd0 (Add git show-ref builtin command, 2006-09-15) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 autostash because of the following reasons: 0. autostash is purely a convenience function that's useful in simple reduced cases like a dumb 'git pull'; when the script we're implementing it for doesn't have a ton of command-line options. 1. git stash; git pull; git stash pop; is a very common idiom. git stash; git rebase master; git stash pop; is a less common idiom, but I agree that it is one rebase case where autostash could be useful. Having git rebase -i show exec git stash pop at the end of a user-editable instruction sheet is less than ideal. Having git rebase --onto master HEAD~3 do an autostash _might_ be useful, but I'm not sure about it. git stash; git merge feature-branch; git stash pop; is not a common idiom at all. 2. git-stash.sh is a helper script, in the same spirit as git-pull.sh and git-rebase.sh. It is natural and easy to implement autostash for pull and rebase, but not for a C builtin like merge. In fact, it's impossible to implement it for merge unless we make git commit execute git stash pop (yuck!). If you want, you can implement a rebase.autostash, but that is not my itch. Considering the gymnastics the implementation would have to do, I'd be against a merge.autostash. So, again: what is your gripe against my pull.autostash implementation, apart from the fact that git status doesn't show stash information? (I _might_ decide to fix this) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 because there is rarely overlap, while in a complex case the user really needs help to save away his WIP, the user is forced to resolve the conflict immediately upon the failed stash pop at the end of git pull. If the conflict turns out to be something the user would not want to resolve at that moment, the user needs to know the way out, something like: git reset --hard;# go back to the result of pull git checkout -b wip ORIG_HEAD ;# start from before the pull git stash pop ;# recover his wip ... perhaps work a bit more ... git commit -a -m wip;# save it away for safety git checkout - ;# result of pull so that he can come back tomorrow, check out wip branch, and decide what to do. What does this have to do with pull at all? Exactly. 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 committed work with the remote side. If the user did this instead: ... Let's save my large WIP away in a more permanent place first git checkout -b wip ... perhaps work a bit more ... git commit -a -m wip git checkout - ... and then ... git pull the user wouldn't have had to do those extra steps. Another thing to consider is that even with the current system, many users do not have a clear idea on what the state of the working tree is when a pull fails (there are largely two classes). Either the merge failed without damaging the WIP before the pull at all, or there wasn't any interaction between the WIP and the change pull wanted to bring in and only the paths with conflicts need to be resolved and added (i.e. commit -a is a no-no). This auto-pop adds a third failure mode to pull. It is a non-issue for Git-heads like us (we do read the messages from the programs), but not all users are like us. The --autosquash option (or not adding either the configuration or the option) would encourage the user to think about the nature of WIP he has in the working tree before running git pull. I'm lost. What does git rebase --autosquash (or rebase.autosquash) have anything to do with git pull --autostash? Sorry, the typo meant --autostash. Is it a too complex beast that may interfere with what others are doing, or is it a trivial change that he can stash away and pop it back? If the former, he will be far better off doing checkout -b, keep working until the local change gets into somewhat a better shape and commit, before pulling into the original branch. A pull-merge person having complex worktree changes should not execute git pull blindly in the first place. That's what git fetch is for: Huh? You are not making sense. I would understand it if it were That's what git commit is for, though. But I'm a pull-rebase guy, and I always want pull.autostash. That is why I said the equation is different for pull-rebase, where rebase insists that you start from a squeaky clean working tree, so you can check the condition early before git pull even starts. While --autostash will not improve the life for pull-merge people (and pull.autostash will actively hurt them), pull.autostash does help pull-rebase people work around the limitation of rebase. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ensimag students projects, version 2013
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 status aliased to status -sb, and this is less than ideal. - Make the -3 and -c switches in git am configuration variables. I have an alias. - Create an advice.ui (like color.ui) to turn off all advice. I don't need advice. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 prevent users running fetch and then merge or rebase
to use the autostash feature.
I agree that is a good way to look at the problem and would lead to
a much better design of the division of labor among these three
moving parts.
It's not about fixing the existing rebase. It's about implementing
autostash the right way.
As a user, when I run git rebase --continue and it tells me it's done,
I expect the work to actually be done. This is the case today. This
won't be the case after autostash is introduced if the user has to
remember to run stash pop afterwards.
Your rebase can do the autostash right way idea in the other
message is a good one, I think. The rebase proper will sequencially
either apply patches (if the user is using the format-patch | am
variant) or cherry-pick commits (rebase -m). Conceptually we can
view the WIP in the working tree as just another commit at the tip
of the original history to be rebased (modulo that it should not be
left as a commit in the resulting history, and we may need to
differentiate what was in the index and what was only in the working
tree). Ignoring the conflicts at stash pop time issue for now, a
rough outline may look like:
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^
The first reset is to match the index to what was stashed with
the first commit ('index part') while keeping the working tree
changes the original WIP had ('working tree part'), and the last
reset --soft is to move the HEAD back to the tip of the originally
committed history.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ensimag students projects, version 2013
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 am --no-3way (the user needs to know the trick .git/rebase-apply/threeway). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] git-clone fails due to GnuTLS recv error (-9), then deletes entire local repo
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 head (1.8.1.2.433.g070c57d.dirty) and found the same issue is still present. There are two problems here: 1. At the end of the transfer GnuTLS recv error (-9): A TLS packet with unexpected length was received 2. git-clone goes on to resolve deltas *then* deletes the entire repository This is reported as Ubuntu bug #882 at https://bugs.launchpad.net/ubuntu/+bug/882 I believe this is due to git not supporting resumable clones, and that the repo is in an unusable state. It's listed as a 2011 GSoC idea [1] but has since been taken off because it's considered a hard problem (can't come with a email thread right off the top of my head). [1] https://git.wiki.kernel.org/index.php/SoC2011Ideas#Resumable_clone -- Cheers, Ray Chuan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 was started. The man pages are relatively obscure on the subject, but I'd call that a documentation bug. I see. Either way, we need a clean worktree for it to work, no? No, you don't. Just try if you're not convinced: $ git checkout -b branch Switched to a new branch 'branch' $ date test.txt git commit -m 'on branch' test.txt [branch 2482623] on branch 1 file changed, 1 insertion(+), 1 deletion(-) $ git checkout - Switched to branch 'master' $ date test.txt git commit -m 'on master' test.txt [master c322d35] on master 1 file changed, 1 insertion(+), 1 deletion(-) $ date other.txt $ git status # On branch master # Changes not staged for commit: # # modified: other.txt # no changes added to commit (use git add and/or git commit -a) $ git merge branch Auto-merging test.txt CONFLICT (content): Merge conflict in test.txt Automatic merge failed; fix conflicts and then commit the result. $ git status # On branch master # You have unmerged paths. # # Unmerged paths: # # both modified: test.txt # # Changes not staged for commit: # # modified: other.txt # no changes added to commit (use git add and/or git commit -a) $ git merge --abort $ git status # On branch master # Changes not staged for commit: # # modified: other.txt # no changes added to commit (use git add and/or git commit -a) $ There may be corner-cases where it doesn't work, but I never encountered such case. It does. stashing means the user will have to stash pop later. One extra step, one extra opportunity to forget something important. That's only if there are conflicts. If there are conflicts, you'll have to stash anyway if: - You're doing a pull-merge and want merge --abort to work. Again, no. A minor annoyance is that it will touch files that have no reason to be touched, hence may trigger extra rebuilds with make, disturbing text editors that have the file open, etc. Okay, I need to ask you something at this point: do you ever run merge on a dirty worktree unless you're absolutely sure that your local changes won't conflict with the changes introduced by the merge? Most of the time, I just run git pull or git merge. I know it's conservative enough, to it will stop if there's anything dangerous. That's only a pull-merge. Unfortunately, making git-pull.sh uniform means that we have to fall back to the least-common-denominator of functionality (which is currently pull-rebase). You may want to, but you don't have to. pull-merge and pull-rebase already have different behavior in case of non-overlapping changes: $ git pull --rebase . branch Cannot pull with rebase: You have unstaged changes. Please commit or stash them. $ git pull --no-rebase . branch From . * branchbranch - FETCH_HEAD [...] I don't see any reason to restrict to the common denominator in the same situation for another feature. I can accept the it's too hard to implement argument, but not it doesn't bring anything. As a user, when I run git rebase --continue and it tells me it's done, I expect the work to actually be done. This is the case today. This won't be the case after autostash is introduced if the user has to remember to run stash pop afterwards. And how will you implement that for merge, since there is no merge --continue to execute stash pop from? Do you propose to make commit do the stash pop'ing? No, I'm not proposing to do anything for merge. There's no reason to try being uniform in conflict resolution for pull-merge and pull-rebase as it is already different now. We already have git rebase --continue, we don't have git merge --continue. So what? The fact that merge doesn't have the equivalent doesn't mean we should not do something for rebase --continue. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 23/45] check-ignore: convert to use parse_pathspec
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() How could main() be invoked with argc inconsistent with argv? The point is main's caller has to maintain the consistency. So do check_ignore's callers. But only the system runtime calls main(), right? So we can probably rely on it being called in a consistent manner ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 difference than it actually is. Users will simply alias pull to 'pull --autostash' (a lot of them already alias it to pull --ff-only, and I'm going to fix this soon). No, they don't. Git forbids redefining commands with aliases. They may have an alias like git pullauto or so, but not git pull. If your criticism were that git status doesn't show stash state, I agree with you. There's not much we can do about it now, as Git cannot guess whether a stash is to be re-applied later or just kept in case. My main use of git stash is I want a reset --hard, but stash is safer, I wouldn't want status to remind me when I have a stash because it is almost always the case. Showing the autostash status in git status would make sense OTOH, but I agree that it's another topic. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] l10n: de.po: translate 39 new messages
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 deletions(-) diff --git a/po/de.po b/po/de.po index 2cd3fa9..2514567 100644 --- a/po/de.po +++ b/po/de.po @@ -136,12 +136,13 @@ msgstr #: branch.c:201 #, c-format msgid Cannot setup tracking information; starting point '%s' is not a branch. -msgstr +msgstr Kann Informationen zum Übernahmezweig nicht einrichten; +Startpunkt '%s' ist kein Zweig. #: branch.c:203 -#, fuzzy, c-format +#, c-format msgid the requested upstream branch '%s' does not exist -msgstr Zweig '%s' existiert nicht +msgstr der angeforderte externe Übernahmezweig '%s' existiert nicht #: branch.c:205 msgid @@ -154,6 +155,15 @@ msgid \n If you are planning on basing your work on an upstream\n branch that already exists at the remote, you may need to\n run \git fetch\ to retrieve it.\n \n If you are planning to push out a new local branch that\n will track its remote counterpart, you may want to use\n \git push -u\ to set the upstream config as you push. msgstr +\n +Falls Sie vorhaben, Ihre Arbeit auf einem bereits existierenden,\n +externen Übernahmezweig aufzubauen, sollten Sie \git fetch\\n +ausführen, um diesen abzurufen.\n +\n +Falls Sie vorhaben, einen neuen lokalen Zweig zu versenden\n +der seinem externen Gegenstück folgen soll, können Sie\n +\git push -u\ verwenden, um den externen Übernahmezweig\n +beim Versand zu konfigurieren. #: bundle.c:36 #, c-format @@ -181,22 +191,22 @@ msgid revision walk setup failed msgstr Einrichtung des Revisionsgangs fehlgeschlagen #: bundle.c:186 -#, fuzzy, c-format +#, c-format msgid The bundle contains this ref: msgid_plural The bundle contains these %d refs: -msgstr[0] Das Paket enthält %d Referenz -msgstr[1] Das Paket enthält %d Referenzen +msgstr[0] Das Paket enthält diese Referenz: +msgstr[1] Das Paket enthält diese %d Referenzen: #: bundle.c:193 msgid The bundle records a complete history. msgstr Das Paket speichert eine komplette Historie. #: bundle.c:195 -#, fuzzy, c-format +#, c-format msgid The bundle requires this ref: msgid_plural The bundle requires these %d refs: -msgstr[0] Das Paket benötigt diese Referenz -msgstr[1] Das Paket benötigt diese %d Referenzen +msgstr[0] Das Paket benötigt diese Referenz: +msgstr[1] Das Paket benötigt diese %d Referenzen: #: bundle.c:294 msgid rev-list died @@ -731,7 +741,7 @@ msgid Unable to write index. msgstr Konnte Bereitstellung nicht schreiben. #: object.c:195 -#, fuzzy, c-format +#, c-format msgid unable to parse object: %s msgstr Konnte Objekt '%s' nicht parsen. @@ -1376,33 +1386,29 @@ msgid (all conflicts fixed: run \git commit\) msgstr (alle Konflikte behoben: führen Sie \git commit\ aus) #: wt-status.c:972 -#, fuzzy, c-format +#, c-format msgid You are currently reverting commit %s. -msgstr Sie sind gerade bei einer binären Suche in Zweig '%s'. +msgstr Sie kehren gerade Version '%s' um. #: wt-status.c:977 -#, fuzzy msgid (fix conflicts and run \git revert --continue\) msgstr - (beheben Sie die Konflikte und führen Sie dann \git rebase --continue\ + (beheben Sie die Konflikte und führen Sie dann \git revert --continue\ aus) #: wt-status.c:980 -#, fuzzy msgid (all conflicts fixed: run \git revert --continue\) -msgstr (alle Konflikte behoben: führen Sie \git rebase --continue\ aus) +msgstr (alle Konflikte behoben: führen Sie \git revert --continue\ aus) #: wt-status.c:982 -#, fuzzy msgid (use \git revert --abort\ to cancel the revert operation) msgstr - (benutzen Sie \git rebase --abort\ um den ursprünglichen Zweig -auszuchecken) + (benutzen Sie \git revert --abort\ um die Umkehroperation abzubrechen) #: wt-status.c:993 -#, fuzzy, c-format +#, c-format msgid You are currently bisecting, started from branch '%s'. -msgstr Sie sind gerade bei einer binären Suche in Zweig '%s'. +msgstr Sie sind gerade bei einer binären Suche, gestartet von Zweig '%s'. #: wt-status.c:997 msgid You are currently bisecting. @@ -1419,13 +1425,12 @@ msgid On branch msgstr Auf Zweig #: wt-status.c:1186 -#, fuzzy msgid HEAD detached at -msgstr losgelöste Zweigspitze (HEAD) +msgstr Zweigspitze (HEAD) losgelöst bei #: wt-status.c:1188 msgid HEAD detached from -msgstr +msgstr Zweigspitze (HEAD) losgelöst von #: wt-status.c:1191 msgid Not currently on any branch. @@ -1446,15 +1451,16 @@ msgstr Ignorierte Dateien #: wt-status.c:1228 #, c-format msgid It took %.2f seconds to enumerate untracked files. 'status -uno' -msgstr +msgstr Es dauerte %.2f Sekunden die unbeobachteten Dateien zu bestimmen. +'status -uno' #: wt-status.c:1232 msgid may speed it up, but you have to be careful not to forget to add -msgstr +msgstr könnte das beschleunigen, aber Sie müssen darauf
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 the local changes that were present before the merge was started. The man pages are relatively obscure on the subject, but I'd call that a documentation bug. I see. Either way, we need a clean worktree for it to work, no? No, you don't. Just try if you're not convinced: Heh, I still remember breaking git merge and got yelled at loudly. cf. http://thread.gmane.org/gmane.comp.version-control.git/9073 It does. stashing means the user will have to stash pop later. One extra step, one extra opportunity to forget something important. That's only if there are conflicts. If there are conflicts, you'll have to stash anyway if: - You're doing a pull-merge and want merge --abort to work. Again, no. A minor annoyance is that it will touch files that have no reason to be touched, hence may trigger extra rebuilds with make, disturbing text editors that have the file open, etc. Okay, I need to ask you something at this point: do you ever run merge on a dirty worktree unless you're absolutely sure that your local changes won't conflict with the changes introduced by the merge? Most of the time, I just run git pull or git merge. I know it's conservative enough, to it will stop if there's anything dangerous. Exactly. No, I'm not proposing to do anything for merge. There's no reason to try being uniform in conflict resolution for pull-merge and pull-rebase as it is already different now. We already have git rebase --continue, we don't have git merge --continue. So what? The fact that merge doesn't have the equivalent doesn't mean we should not do something for rebase --continue. Well said. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 committed work with the remote side. If the user did this instead: ... Let's save my large WIP away in a more permanent place first git checkout -b wip ... perhaps work a bit more ... git commit -a -m wip git checkout - ... and then ... git pull the user wouldn't have had to do those extra steps. Hm, yes. For a pull-merge guy who opts for pull.autostash, the penalty for forgetting to commit a big WIP in advance is too high. It probably makes sense to restrict the autostash feature to kick in only in the rebase codepath: it might be a good idea to implement rebase.autostash for reduced case of non-interactive rebases instead. I'm only slightly iffy about --onto, but it's not a big concern. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ensimag students projects, version 2013
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 natural language form, or machine-parsable? If the later, there was a patch series doing essentially this: http://thread.gmane.org/gmane.comp.version-control.git/209240 It doesn't seem to have been merged. Phil, what happened to it? - Make the -s and -b switches in git status configuration variables. I currently have status aliased to status -sb, and this is less than ideal. - Make the -3 and -c switches in git am configuration variables. I have an alias. Seems reasonable. Should be good technical warm-ups if people agree this is a good idea. - Create an advice.ui (like color.ui) to turn off all advice. I don't need advice. I tend to agree with you, but the idea has explicitly been rejected in the past. The problem with an option like this is that it would also disable the advices that may be added in the future. By letting people disable the advices one by one, people see new advices as they arrive. You may think of it like do not show this message again tickboxes in some graphical user interfaces. Too controversial area for newcommers I guess ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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^ Why are you rolling your own stash? What do you have against git stash? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] push: introduce implicit push
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 think this does anybody any service. If the current behavior is wrong, and if users all over the Internet is any indication, it is; we do not want to continue such bad behavior. If the new functionality has a different behavior, it only makes sense to change the old behavior to make it consistent. Perpetuating bad behavior choices only hurt the users, we need to start thinking how to make git more user friendly, not worry too much about keep doing what we did five years ago. Sure, we should not break user expectations from one day to the next, but that doesn't mean we can't change anything ever. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 to try being uniform in conflict resolution for pull-merge and pull-rebase as it is already different now. We already have git rebase --continue, we don't have git merge --continue. So what? The fact that merge doesn't have the equivalent doesn't mean we should not do something for rebase --continue. Well, you can't blame me for the misunderstanding then. In a previous email, you wrote: Shouldn't this belong to git merge instead (i.e. implement git merge --autosquash and call it from git pull)? Users doing git fetch git merge by hand should be able to use --autosquash, I think. 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/33] refs: extract a function ref_resolves_to_object()
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 a/refs.c b/refs.c
index c523978..dfc8600 100644
--- a/refs.c
+++ b/refs.c
@@ -529,6 +529,22 @@ static void sort_ref_dir(struct ref_dir *dir)
#define DO_FOR_EACH_INCLUDE_BROKEN 0x01
/*
+ * Return true iff the reference described by entry can be resolved to
+ * an object in the database. Emit a warning if the referred-to
+ * object does not exist.
+ */
+static int ref_resolves_to_object(struct ref_entry *entry)
+{
+ if (entry-flag REF_ISBROKEN)
+ return 0;
+ if (!has_sha1_file(entry-u.value.sha1)) {
+ error(%s does not point to a valid object!, entry-name);
+ return 0;
+ }
+ return 1;
+}
+
+/*
* current_ref is a performance hack: when iterating over references
* using the for_each_ref*() functions, current_ref is set to the
* current reference's entry before calling the callback function. If
@@ -549,14 +565,10 @@ static int do_one_ref(const char *base, each_ref_fn fn,
int trim,
if (prefixcmp(entry-name, base))
return 0;
- if (!(flags DO_FOR_EACH_INCLUDE_BROKEN)) {
- if (entry-flag REF_ISBROKEN)
- return 0; /* ignore broken refs e.g. dangling symref */
- if (!has_sha1_file(entry-u.value.sha1)) {
- error(%s does not point to a valid object!,
entry-name);
- return 0;
- }
- }
+ if (!((flags DO_FOR_EACH_INCLUDE_BROKEN) ||
+ ref_resolves_to_object(entry)))
+ return 0;
+
The original says Unless flags tell us to include broken ones,
return 0 for the broken ones and the ones that point at invalid
objects.
The updated says Unless flags tell us to include broken ones or the
ref is a good one, return 0.
Are they the same? If we have a good one, and if we are not told to
include broken one, the original just passes the control down to the
remainder of the function. The updated one will return 0.
Oh, wait, that is not the case. The OR is inside !( A || B ), so
what it really wants to say is:
if (!(flags DO_FOR_EACH_INCLUDE_BROKEN)
!ref_resolves_to_object(entry))
return 0;
that is, When we are told to exclude broken ones and the one we are
looking at is broken, return 0.
Am I the only one who was confused with this, or was the way the
patch wrote this logic unnecessarily convoluted?
current_ref = entry;
retval = fn(entry-name + trim, entry-u.value.sha1, entry-flag,
cb_data);
current_ref = NULL;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 a stash is to be re-applied later or just kept in case. My main use of git stash is I want a reset --hard, but stash is safer, I wouldn't want status to remind me when I have a stash because it is almost always the case. Showing the autostash status in git status would make sense OTOH, but I agree that it's another topic. If the HEAD of the stash contains a stash beginning with the message pull.autostash: , show it in the status. End of story. Anyway, no point arguing about this since we've decided not to pursue pull.autostash anyway. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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, rebase--am, and rebase--merge) just as easily, without leaking the autostash detail into them. The last statement in git-rebase.sh is run_specific_rebase, which just needs to be wrapped in a git stash/ git stash pop. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] push: introduce implicit push
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 (and conflicting) internal models that give different answers. I don't think this does anybody any service. If the current behavior is wrong, and if users all over the Internet is any indication, it is; we do not want to continue such bad behavior. If the new functionality has a different behavior, it only makes sense to change the old behavior to make it consistent. The current push.default = matching behaviour may be wrong, but I haven't seen anyone say that the fundamental 'git push' does something depending on push.default and 'git push there ref...' specifies exactly what to do is broken. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] push: introduce implicit push
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 the answer for me is it's completely new, but others have different (and conflicting) internal models that give different answers. I don't think this does anybody any service. If the current behavior is wrong, and if users all over the Internet is any indication, it is; we do not want to continue such bad behavior. If the new functionality has a different behavior, it only makes sense to change the old behavior to make it consistent. The current push.default = matching behaviour may be wrong, but I haven't seen anyone say that the fundamental 'git push' does something depending on push.default and 'git push there ref...' specifies exactly what to do is broken. Maybe not, but that doesn't mean that the new behavior should be limited by the old one. If there's an ideal new behavior, the old one should eventually be updated to accommodate the new one. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/33] refs: document do_for_each_ref() and do_one_ref()
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 @@ static void sort_ref_dir(struct ref_dir *dir)
dir-sorted = dir-nr = i;
}
-#define DO_FOR_EACH_INCLUDE_BROKEN 01
+/* Include broken references in a do_for_each_ref*() iteration: */
+#define DO_FOR_EACH_INCLUDE_BROKEN 0x01
static struct ref_entry *current_ref;
+/*
+ * Handle one reference in a do_for_each_ref*()-style iteration.
+ */
static int do_one_ref(const char *base, each_ref_fn fn, int trim,
int flags, void *cb_data, struct ref_entry *entry)
{
@@ -1338,6 +1342,13 @@ void warn_dangling_symref(FILE *fp, const char
*msg_fmt, const char *refname)
for_each_rawref(warn_if_dangling_symref, data);
}
+/*
+ * Call fn for each reference in the specified submodule for which the
+ * refname begins with base. If trim is non-zero, then trim that many
+ * characters off the beginning of each refname before passing the
+ * refname to fn. flags can be DO_FOR_EACH_INCLUDE_BROKEN to include
+ * broken references in the iteration.
+ */
Early termination due to fn() returning non-zero needs to be
documented here, no?
static int do_for_each_ref(const char *submodule, const char *base,
each_ref_fn fn,
int trim, int flags, void *cb_data)
{
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/33] peel_object(): give more specific information in return value
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 all existing callers check if the return value is 0 and does not check the error code against -1. Looking good so far. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/33] peel_ref(): fix return value for non-peelable, not-current reference
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 current_ref,
which is what callers expect. Document the behavior.
Current callers did not trigger the previously-buggy behavior.
Is that because we were lucky by codeflow, or is it just that we
didn't have a testcase to trigger the behaviour?
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 5 -
refs.h | 8
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 84c2497..a0d8e32 100644
--- a/refs.c
+++ b/refs.c
@@ -120,7 +120,8 @@ struct ref_value {
/*
* If REF_KNOWS_PEELED, then this field holds the peeled value
* of this reference, or null if the reference is known not to
- * be peelable.
+ * be peelable. See the documentation for peel_ref() for an
+ * exact definition of peelable.
*/
unsigned char peeled[20];
};
@@ -1339,6 +1340,8 @@ int peel_ref(const char *refname, unsigned char *sha1)
struct ref_entry *r = get_packed_ref(refname);
if (r (r-flag REF_KNOWS_PEELED)) {
+ if (is_null_sha1(r-u.value.peeled))
+ return -1;
hashcpy(sha1, r-u.value.peeled);
return 0;
}
diff --git a/refs.h b/refs.h
index 17bc1c1..ac0ff92 100644
--- a/refs.h
+++ b/refs.h
@@ -74,6 +74,14 @@ extern void add_packed_ref(const char *refname, const
unsigned char *sha1);
extern int ref_exists(const char *);
+/*
+ * If refname is a non-symbolic reference that refers to a tag object,
+ * and the tag can be (recursively) dereferenced to a non-tag object,
+ * store the SHA1 of the referred-to object to sha1 and return 0. If
+ * any of these conditions are not met, return a non-zero value.
+ * Symbolic references are considered unpeelable, even if they
+ * ultimately resolve to a peelable tag.
+ */
extern int peel_ref(const char *refname, unsigned char *sha1);
/** Locks a refs/ ref returning the lock on success and NULL on failure.
**/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/33] refs: extract a function peel_entry()
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 value.
+ * We only try this optimization on packed references because
+ * (a) forcing the filling of the loose reference cache could
+ * be expensive and (b) loose references anyway usually do not
+ * have REF_KNOWS_PEELED.
+ */
+ if (flag REF_ISPACKED) {
struct ref_entry *r = get_packed_ref(refname);
This code makes the reader wonder what happens when a new loose ref
masks a stale packed ref, but the worry is unfounded because the
read_ref_full() wouldn't have gave us REF_ISPACKED in the flag in
such a case.
But somehow the calling sequence looks like such a mistake waiting
to happen. It would be much more clear if a function that returns a
struct ref_entry * is used instead of read_ref_full() above, and
we checked (r-flag REF_ISPACKED) in the conditional, without a
separate get_packed_ref(refname).
-
- if (r (r-flag REF_KNOWS_PEELED)) {
- if (is_null_sha1(r-u.value.peeled))
- return -1;
+ if (r) {
+ if (peel_entry(r))
+ return -1;
hashcpy(sha1, r-u.value.peeled);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/33] refs: change the internal reference-iteration API
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 internal callback signature int each_ref_entry_fn(struct ref_entry *entry, void *cb_data) Change do_for_each_ref_in_dir() and do_for_each_ref_in_dirs() to accept each_ref_entry_fn callbacks, and rename them to do_for_each_entry_in_dir() and do_for_each_entry_in_dirs(), respectively. Adapt their callers accordingly. Add a new function do_for_each_entry() analogous to do_for_each_ref() but using the new callback style. Nicely done. Change do_one_ref() into an each_ref_entry_fn that does some bookkeeping and then calls a wrapped each_ref_fn. Reimplement do_for_each_ref() in terms of do_for_each_entry(), using do_one_ref() as an adapter. Please note that the responsibility for setting current_ref remains in do_one_ref(), which means that current_ref is *not* set when iterating over references via the new internal API. This is not a disadvantage, because current_ref is not needed by callers of the internal API (they receive a pointer to the current ref_entry anyway). But more importantly, this change prevents peel_ref() from returning invalid results in the following scenario: When iterating via the external API, the iteration always includes both packed and loose references, and in particular never presents a packed ref if there is a loose ref with the same name. The internal API, on the other hand, gives the option to iterate over only the packed references. During such an iteration, there is no check whether the packed ref might be hidden by a loose ref of the same name. But until now the packed ref was recorded in current_ref during the iteration. So if peel_ref() were called with the reference name corresponding to current ref, it would return the peeled version of the packed ref even though there might be a loose ref that peels to a different value. This scenario doesn't currently occur in the code, but fix it to prevent things from breaking in a very confusing way in the future. Hopefully that means in later patches in this series ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/33] t3210: test for spurious error messages for dangling packed refs
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 a spurious error message: error: refs/heads/master does not point to a valid object! The error is generated by repack_without_ref() if there is an obsolete dangling packed reference in packed-refs when the packed-refs file has to be rewritten due to the deletion of another packed reference. Add a failing test demonstrating this problem and some passing tests of related scenarios. That is one nasty recent bug. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- How can I get rid of the sleeps in these tests? Would test-chmtime help? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 17/33] repack_without_ref(): silence errors for dangling packed refs
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
references.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Somehow this feels as if it is sweeping the problem under the rug.
If you ignore a ref for which a loose ref exists when you update a
packed refs file, whether the stale packed one points at an object
that is still there or an object that has been garbage collected,
you would not even have to check if the ref resolves to object or
anything like that, no?
Am I missing something?
This one feels iffy in the otherwise pleasant-to-read series.
---
refs.c | 17 ++---
t/t3210-pack-refs.sh | 2 +-
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/refs.c b/refs.c
index 51f68d3..eadbc2a 100644
--- a/refs.c
+++ b/refs.c
@@ -531,15 +531,17 @@ static void sort_ref_dir(struct ref_dir *dir)
/*
* Return true iff the reference described by entry can be resolved to
- * an object in the database. Emit a warning if the referred-to
- * object does not exist.
+ * an object in the database. If report_errors is true, emit a
+ * warning if the referred-to object does not exist.
*/
-static int ref_resolves_to_object(struct ref_entry *entry)
+static int ref_resolves_to_object(struct ref_entry *entry, int report_errors)
{
if (entry-flag REF_ISBROKEN)
return 0;
if (!has_sha1_file(entry-u.value.sha1)) {
- error(%s does not point to a valid object!, entry-name);
+ if (report_errors)
+ error(%s does not point to a valid object!,
+ entry-name);
return 0;
}
return 1;
@@ -578,7 +580,7 @@ static int do_one_ref(struct ref_entry *entry, void
*cb_data)
return 0;
if (!((data-flags DO_FOR_EACH_INCLUDE_BROKEN) ||
- ref_resolves_to_object(entry)))
+ ref_resolves_to_object(entry, 1)))
return 0;
current_ref = entry;
@@ -1897,8 +1899,9 @@ static int repack_without_ref_fn(struct ref_entry
*entry, void *cb_data)
if (!strcmp(data-refname, entry-name))
return 0;
- if (!ref_resolves_to_object(entry))
- return 0; /* Skip broken refs */
+ /* Silently skip broken refs: */
+ if (!ref_resolves_to_object(entry, 0))
+ return 0;
len = snprintf(line, sizeof(line), %s %s\n,
sha1_to_hex(entry-u.value.sha1), entry-name);
/* this should not happen but just being defensive */
diff --git a/t/t3210-pack-refs.sh b/t/t3210-pack-refs.sh
index c032d88..559f602 100755
--- a/t/t3210-pack-refs.sh
+++ b/t/t3210-pack-refs.sh
@@ -142,7 +142,7 @@ test_expect_success 'delete ref with dangling packed
version' '
test_cmp /dev/null result
'
-test_expect_failure 'delete ref while another dangling packed ref' '
+test_expect_success 'delete ref while another dangling packed ref' '
git branch lamb
git commit --allow-empty -m future garbage
git pack-refs --all
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/33] repack_without_ref(): write peeled refs in the rewritten file
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, because the packed-refs file header didn't claim that the file contained peeled values. But it had a performance cost, because the repository would lose the benefit of having precomputed peeled references until pack-refs was run again. Good. Teach repack_without_ref() to write peeled refs to the packed-refs file (regardless of whether they were present in the old version of the file). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 32/33] refs: change do_for_each_*() functions to take ref_cache arguments
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/4] Some small fixes to glossary-content.txt
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 is an explanation in the log message why the exact definition of refspec can be omitted in the glossary. The definition of pathspec is kept in the glossary; there are only small improvements to wording and formatting. [PATCH v3 1/4] glossary: remove outdated/misleading/irrelevant entries [PATCH v3 2/4] glossary: improve description of SHA-1 related topics [PATCH v3 3/4] The name of the hash function is SHA-1, not SHA1 [PATCH v3 4/4] glossary: improve definitions of refspec and pathspec --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/4] glossary: remove outdated/misleading/irrelevant entries
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 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -104,9 +104,6 @@ to point at the new commit. an arbitrary def_commit,commit that isn't necessarily the tip of any particular branch. In this case HEAD is said to be detached. -[[def_dircache]]dircache:: - You are *way* behind. See def_index,index. - [[def_directory]]directory:: The list you get with ls :-) @@ -115,11 +112,6 @@ to point at the new commit. it contains modifications which have not been def_commit,committed to the current def_branch,branch. -[[def_ent]]ent:: - Favorite synonym to def_tree-ish,tree-ish by some total geeks. See - http://en.wikipedia.org/wiki/Ent_(Middle-earth) for an in-depth - explanation. Avoid this term, not to confuse people. - [[def_evil_merge]]evil merge:: An evil merge is a def_merge,merge that introduces changes that do not appear in any def_parent,parent. @@ -257,8 +249,7 @@ This commit is referred to as a merge commit, or sometimes just a def_object,object. [[def_octopus]]octopus:: - To def_merge,merge more than two def_branch,branches. Also denotes an - intelligent predator. + To def_merge,merge more than two def_branch,branches. [[def_origin]]origin:: The default upstream def_repository,repository. Most projects have -- 1.8.1.msysgit.1 --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/4] glossary: improve description of SHA-1 related topics
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 object is. Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/glossary-content.txt | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 5a7a486..2734947 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -153,7 +153,7 @@ to point at the new commit. created. Configured via the `.git/info/grafts` file. [[def_hash]]hash:: - In Git's context, synonym to def_object_name,object name. + In Git's context, synonym for def_object_name,object name. [[def_head]]head:: A def_ref,named reference to the def_commit,commit at the tip of a @@ -225,7 +225,7 @@ This commit is referred to as a merge commit, or sometimes just a [[def_object]]object:: The unit of storage in Git. It is uniquely identified by the - def_SHA1,SHA1 of its contents. Consequently, an + def_SHA1,SHA-1 of its contents. Consequently, an object can not be changed. [[def_object_database]]object database:: @@ -237,10 +237,9 @@ This commit is referred to as a merge commit, or sometimes just a Synonym for def_object_name,object name. [[def_object_name]]object name:: - The unique identifier of an def_object,object. The def_hash,hash - of the object's contents using the Secure Hash Algorithm - 1 and usually represented by the 40 character hexadecimal encoding of - the def_hash,hash of the object. + The unique identifier of an def_object,object. The + object name is usually represented by a 40 character + hexadecimal string. Also colloquially called def_SHA1,SHA-1. [[def_object_type]]object type:: One of the identifiers def_commit_object,commit, @@ -376,7 +375,7 @@ should not be combined with other pathspec. to the result. [[def_ref]]ref:: - A 40-byte hex representation of a def_SHA1,SHA1 or a name that + A 40-byte hex representation of a def_SHA1,SHA-1 or a name that denotes a particular def_object,object. They may be stored in a file under `$GIT_DIR/refs/` directory, or in the `$GIT_DIR/packed-refs` file. @@ -432,8 +431,9 @@ should not be combined with other pathspec. [[def_SCM]]SCM:: Source code management (tool). -[[def_SHA1]]SHA1:: - Synonym for def_object_name,object name. +[[def_SHA1]]SHA-1:: + Secure Hash Algorithm 1; a cryptographic hash function. + In the context of Git used as a synonym for def_object_name,object name. [[def_shallow_repository]]shallow repository:: A shallow def_repository,repository has an incomplete @@ -447,7 +447,7 @@ should not be combined with other pathspec. its history can be later deepened with linkgit:git-fetch[1]. [[def_symref]]symref:: - Symbolic reference: instead of containing the def_SHA1,SHA1 + Symbolic reference: instead of containing the def_SHA1,SHA-1 id itself, it is of the format 'ref: refs/some/thing' and when referenced, it recursively dereferences to this reference. 'def_HEAD,HEAD' is a prime example of a symref. Symbolic -- 1.8.1.msysgit.1 --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] The name of the hash function is SHA-1, not SHA1
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 +++--- Documentation/git-describe.txt| 2 +- Documentation/git-fsck.txt| 4 ++-- Documentation/git-index-pack.txt | 2 +- Documentation/git-ls-files.txt| 2 +- Documentation/git-merge-index.txt | 2 +- Documentation/git-pack-objects.txt| 2 +- Documentation/git-patch-id.txt| 2 +- Documentation/git-replace.txt | 4 ++-- Documentation/git-rev-parse.txt | 4 ++-- Documentation/git-show-branch.txt | 4 ++-- Documentation/git-show-index.txt | 2 +- Documentation/git-show-ref.txt| 4 ++-- Documentation/git-tag.txt | 2 +- Documentation/git-update-index.txt| 2 +- Documentation/git-verify-pack.txt | 4 ++-- Documentation/git-verify-tag.txt | 2 +- Documentation/git.txt | 10 +- Documentation/gitcore-tutorial.txt| 8 Documentation/gitdiffcore.txt | 2 +- Documentation/githooks.txt| 10 +- Documentation/gitrepository-layout.txt| 2 +- Documentation/gittutorial-2.txt | 16 Documentation/howto/recover-corrupted-blob-object.txt | 6 +++--- Documentation/pretty-formats.txt | 2 +- Documentation/revisions.txt | 4 ++-- Documentation/technical/api-sha1-array.txt| 4 ++-- Documentation/technical/pack-format.txt | 14 +++--- Documentation/technical/pack-heuristics.txt | 2 +- Documentation/technical/shallow.txt | 4 ++-- 31 files changed, 68 insertions(+), 68 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 3d750e0..5123636 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -412,7 +412,7 @@ repository's usual working tree). core.logAllRefUpdates:: Enable the reflog. Updates to a ref ref is logged to the file $GIT_DIR/logs/ref, by appending the new and old - SHA1, the date/time and the reason of the update, but + SHA-1, the date/time and the reason of the update, but only when the file exists. If this configuration variable is set to true, missing $GIT_DIR/logs/ref file is automatically created for branch heads (i.e. under diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt index 2fb95bb..30d585a 100644 --- a/Documentation/git-cat-file.txt +++ b/Documentation/git-cat-file.txt @@ -20,7 +20,7 @@ object type, or '-s' is used to find the object size, or '--textconv' is used (which implies type blob). In the second form, a list of objects (separated by linefeeds) is provided on -stdin, and the SHA1, type, and size of each object is printed on stdout. +stdin, and the SHA-1, type, and size of each object is printed on stdout. OPTIONS --- @@ -58,11 +58,11 @@ OPTIONS to apply the filter to the content recorded in the index at path. --batch:: - Print the SHA1, type, size, and contents of each object provided on + Print the SHA-1, type, size, and contents of each object provided on stdin. May not be combined with any other options or arguments. --batch-check:: - Print the SHA1, type, and size of each object provided on stdin. May not + Print the SHA-1, type, and size of each object provided on stdin. May not be combined with any other options or arguments. OUTPUT diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt index 3c81e85..28e5ec0 100644 --- a/Documentation/git-describe.txt +++ b/Documentation/git-describe.txt @@ -149,7 +149,7 @@ is found, its name will be output and searching will stop. If an exact match was not found, 'git describe' will walk back through the commit history to locate an ancestor commit which has been tagged. The ancestor's tag will be output along with an -abbreviation of the input committish's SHA1. +abbreviation of the input committish's SHA-1. If multiple tags were found during the walk then the tag which has the fewest commits different from the input committish will be diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt index eff9188..e5878bd 100644 --- a/Documentation/git-fsck.txt +++ b/Documentation/git-fsck.txt @@ -23,7 +23,7 @@ OPTIONS An object to treat as the head of an
[PATCH v3 4/4] glossary: improve definitions of refspec and pathspec
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 about it. So for the time being just improve the first sentence a little bit; fix the idendation of the first paragraph after the bullet list and remove the one-item list of magic signatures with its - for the user - unnecessary introduction of magic word 'top'. Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/glossary-content.txt | 33 ++--- 1 file changed, 10 insertions(+), 23 deletions(-) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 2734947..c36283c 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -268,7 +268,7 @@ This commit is referred to as a merge commit, or sometimes just a pack. [[def_pathspec]]pathspec:: - Pattern used to specify paths. + Pattern used to limit paths in Git commands. + Pathspecs are used on the command line of git ls-files, git ls-tree, git add, git grep, git diff, git checkout, @@ -277,6 +277,8 @@ limit the scope of operations to some subset of the tree or worktree. See the documentation of each command for whether paths are relative to the current directory or toplevel. The pathspec syntax is as follows: ++ +-- * any path matches itself * the pathspec up to the last slash represents a @@ -286,11 +288,12 @@ pathspec syntax is as follows: of the pathname. Paths relative to the directory prefix will be matched against that pattern using fnmatch(3); in particular, '*' and '?' _can_ match directory separators. + +-- + For example, Documentation/*.jpg will match all .jpg files in the Documentation subtree, including Documentation/chapter_1/figure_1.jpg. - + A pathspec that begins with a colon `:` has special meaning. In the short form, the leading colon `:` is followed by zero or more magic @@ -306,18 +309,10 @@ and a close parentheses `)`, and the remainder is the pattern to match against the path. + The magic signature consists of an ASCII symbol that is not -alphanumeric. -+ --- -top `/`;; - The magic word `top` (mnemonic: `/`) makes the pattern match - from the root of the working tree, even when you are running - the command from inside a subdirectory. --- -+ -Currently only the slash `/` is recognized as the magic signature, -but it is envisioned that we will support more types of magic in later -versions of Git. +alphanumeric. Currently only the slash `/` is recognized as a +magic signature: it makes the pattern match from the root of +the working tree, even when you are running the command from +inside a subdirectory. + A pathspec with only a colon means there is no pathspec. This form should not be combined with other pathspec. @@ -389,15 +384,7 @@ should not be combined with other pathspec. [[def_refspec]]refspec:: A refspec is used by def_fetch,fetch and def_push,push to describe the mapping between remote - def_ref,ref and local ref. They are combined with a colon in - the format src:dst, preceded by an optional plus sign, +. - For example: `git fetch $URL - refs/heads/master:refs/heads/origin` means grab the master - def_branch,branch def_head,head from the $URL and store - it as my origin branch head. And `git push - $URL refs/heads/master:refs/heads/to-upstream` means publish my - master branch head as to-upstream branch at $URL. See also - linkgit:git-push[1]. + def_ref,ref and local ref. [[def_remote_tracking_branch]]remote-tracking branch:: A regular Git def_branch,branch that is used to follow changes from -- 1.8.1.msysgit.1 --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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 init already know how to use a directory that is outside the working tree of the newly created repository to store its $GIT_DIR and point at it with .git in the working tree using the gitfile mechanism (their --separate-git-dir option). 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 $GIT_DIR inside the .git/modules/$name of the superproject. After that clone or init creates a repository, you still have to add if you want to make it a submodule to the toplevel. If I want to *add* something to a repository, I'll use some kind of add command. To me git clone is not the kind of verb I would expect to add something to some distant-parent .git directory. Instead of mucking around withgit clone I would much rather see git add autodetect URLs and do the submodule thing: git add ssh://host/blammo.git would clone blammo.git into ./blammo/ and set it up as a submodule inside $PWD's git repo. 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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. [...] Now, are these Code/* repos inside ~/.git/'s worktree or not? Please don't version your entire ~, effectively shooting yourself in the face? Use a dotfiles repo and write a simple Makefile to symlink ~/.etc to ~/dotfiles/.etc. If you're looking for a good example, see https://github.com/artagnon/dotfiles. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 reset HEAD^ git reset --soft HEAD^ Why are you rolling your own stash? What do you have against git stash? Nothing. It just felt that it does not _have to be_ implemented with stash, and explaining things in terms of commit and reset would be simpler. 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 todo file. Then the usual rebase --continue would just work. Instead you could use git stash at step #2 and add exec git stash pop at step #3. rebase--am could also be told to generate (on the preparation side) and notice (on the application side) a pair of patch files at the end that represent the index state and the working tree state and apply them without making the WIP part into a commit. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: State of CVS-to-git conversion tools (Was: Re: cvsps: bad usage: invalid argument --norc)
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 'git fast-import' has it? I need it, because full import takes too long. The central repo of my employer is CVS, other people commit to it and I use git internally to be able to tidy my commit history before exporting to CVS. -- cvsps2: commit c0654845791da1eefb1e223c8001169d61f9de51 Author: reevzh1 reevzh1 Date: Fri Jul 28 10:47:17 2006 + no message components/rapportlets/src/com/sicap/guif/portalframework/portlets/rap/ReportFraudCDRQuerierPortlet.java | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) commit 2ed1c92eec518a5752277a16cf2aea6bd488d6be Author: reevzh1 reevzh1 Date: Fri Jul 28 04:51:06 2006 + no message components/rapportlets/src/com/sicap/guif/portalframework/portlets/rap/CommonAttributeNames.java | 6 ++ components/rapportlets/src/com/sicap/guif/portalframework/portlets/rap/ReportFraudCDRQuerierItem.java | 129 components/rapportlets/src/com/sicap/guif/portalframework/portlets/rap/ReportFraudCDRQuerierPortlet.java | 101 +++ components/rapportlets/src/com/sicap/guif/portalframework/portlets/rap/containers/ReportContainer.java | 48 + resources/ReportFraudCDRQuerier_en.properties | 2 + web/jsp/report_fraudcdr_querier.jsp | 21 ++-- web/jsp/report_fraudcdr_querier_print.jsp | 309 + web/resources/Language_en.properties | 8 +- 8 files changed, 595 insertions(+), 29 deletions(-) commit d6a7335ea24323509df02b08f52af01926eb5e4d Author: redane1 redane1 Date: Thu Jul 6 10:28:24 2006 + no message ... cvsps3: commit d3732dbdf41b348f0050e888733ce2afec05f7f8 Author: reevzh1 reevzh1 Date: Fri Jul 28 10:47:17 2006 + no message components/rapportlets/src/com/sicap/guif/portalframework/portlets/rap/ReportFraudCDRQuerierPortlet.java | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) commit 158bc55affa80b60471ea6026b1393934f928e58 Author: reevzh1 reevzh1 Date: Fri Jul 28 04:51:22 2006 + no message components/rapportlets/src/com/sicap/guif/portalframework/portlets/rap/ReportFraudCDRQuerierItem.java | 129 + components/rapportlets/src/com/sicap/guif/portalframework/portlets/rap/containers/ReportContainer.java | 48 ++ web/jsp/report_fraudcdr_querier_print.jsp | 309 +++ web/resources/Language_en.properties | 8 +- 4 files changed, 493 insertions(+), 1 deletion(-) commit 1ba90a2baebee9f1838dab04f129c7704331e0a8 Author: reevzh1 reevzh1 Date: Fri Jul 28 04:51:06 2006 + no message components/rapportlets/src/com/sicap/guif/portalframework/portlets/rap/CommonAttributeNames.java | 6 components/rapportlets/src/com/sicap/guif/portalframework/portlets/rap/ReportFraudCDRQuerierPortlet.java | 101 + resources/ReportFraudCDRQuerier_en.properties | 2 ++ web/jsp/report_fraudcdr_querier.jsp | 21 4 files changed, 102 insertions(+), 28 deletions(-) commit d6a7335ea24323509df02b08f52af01926eb5e4d Author: redane1 redane1 Date: Thu Jul 6 10:28:24 2006 + no message ...
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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 $GIT_DIR inside the .git/modules/$name of the superproject. Right. But I'm still worried about .git/modules/$name. Can you explain why it's a better idea than having a dedicated ~/bare? In the case when I have it in ~/bare, I can do many more interesting things: for instance, if I cloned a repository that is actually another project's submodule for instance, I don't have to re-clone it when I clone that superproject. What's more? I can remove submodules and attach a worktree to my ~/bare/repo.git and use it as a separate repository easily. I can move submodules between projects. In comparison, .git/modules/$name just seems like a mess. 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. Well, I'm against the change in principle because add operates on worktree paths, not URLs. I don't want to change that arbitrarily. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 todo file. Er, no. I don't want to touch the instruction sheet. It becomes especially problematic in -i, when the instruction sheet is user-editable. rebase--am could also be told to generate (on the preparation side) and notice (on the application side) a pair of patch files at the end that represent the index state and the working tree state and apply them without making the WIP part into a commit. Ugh, no. I don't want to leak the implementation detail of autostash into specific rebases. Why can't I wrap the last statment in git-rebase.sh in git stash/ git stash pop like I did with git-pull.sh? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] glossary: improve definitions of refspec and pathspec
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 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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] glossary: remove outdated/misleading/irrelevant entries
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 b/Documentation/glossary-content.txt index eb7ba84..5a7a486 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -104,9 +104,6 @@ to point at the new commit. an arbitrary def_commit,commit that isn't necessarily the tip of any particular branch. In this case HEAD is said to be detached. -[[def_dircache]]dircache:: - You are *way* behind. See def_index,index. - [[def_directory]]directory:: The list you get with ls :-) @@ -115,11 +112,6 @@ to point at the new commit. it contains modifications which have not been def_commit,committed to the current def_branch,branch. -[[def_ent]]ent:: - Favorite synonym to def_tree-ish,tree-ish by some total geeks. See - http://en.wikipedia.org/wiki/Ent_(Middle-earth) for an in-depth - explanation. Avoid this term, not to confuse people. - [[def_evil_merge]]evil merge:: An evil merge is a def_merge,merge that introduces changes that do not appear in any def_parent,parent. @@ -257,8 +249,7 @@ This commit is referred to as a merge commit, or sometimes just a def_object,object. [[def_octopus]]octopus:: - To def_merge,merge more than two def_branch,branches. Also denotes an - intelligent predator. + To def_merge,merge more than two def_branch,branches. [[def_origin]]origin:: The default upstream def_repository,repository. Most projects have -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/4] The name of the hash function is SHA-1, not SHA1
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 more official object name, if we are going to the trouble of fixing all of these. It depends on how many places already correctly spell SHA-1, I guess. Documentation/config.txt | 2 +- Documentation/git-cat-file.txt| 6 +++--- Documentation/git-describe.txt| 2 +- Documentation/git-fsck.txt| 4 ++-- Documentation/git-index-pack.txt | 2 +- Documentation/git-ls-files.txt| 2 +- Documentation/git-merge-index.txt | 2 +- Documentation/git-pack-objects.txt| 2 +- Documentation/git-patch-id.txt| 2 +- Documentation/git-replace.txt | 4 ++-- Documentation/git-rev-parse.txt | 4 ++-- Documentation/git-show-branch.txt | 4 ++-- Documentation/git-show-index.txt | 2 +- Documentation/git-show-ref.txt| 4 ++-- Documentation/git-tag.txt | 2 +- Documentation/git-update-index.txt| 2 +- Documentation/git-verify-pack.txt | 4 ++-- Documentation/git-verify-tag.txt | 2 +- Documentation/git.txt | 10 +- Documentation/gitcore-tutorial.txt| 8 Documentation/gitdiffcore.txt | 2 +- Documentation/githooks.txt| 10 +- Documentation/gitrepository-layout.txt| 2 +- Documentation/gittutorial-2.txt | 16 Documentation/howto/recover-corrupted-blob-object.txt | 6 +++--- Documentation/pretty-formats.txt | 2 +- Documentation/revisions.txt | 4 ++-- Documentation/technical/api-sha1-array.txt| 4 ++-- Documentation/technical/pack-format.txt | 14 +++--- Documentation/technical/pack-heuristics.txt | 2 +- Documentation/technical/shallow.txt | 4 ++-- 31 files changed, 68 insertions(+), 68 deletions(-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash
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 reset HEAD^ and exec reset --soft HEAD^) at the end of the rebase todo file. Er, no. I don't want to touch the instruction sheet. It becomes especially problematic in -i, when the instruction sheet is user-editable. rebase--am could also be told to generate (on the preparation side) and notice (on the application side) a pair of patch files at the end that represent the index state and the working tree state and apply them without making the WIP part into a commit. Ugh, no. I don't want to leak the implementation detail of autostash into specific rebases. Why can't I wrap the last statment in git-rebase.sh in git stash/ git stash pop like I did with git-pull.sh? How does that work with the following: - run_specific_rebase fails, so the user needs to fix it up and then run git rebase --continue. We don't want to pop the stash in this case. - the user runs git rebase --continue with staged changes, knowing the git-rebase will commit those. We don't want to create a stash in this case since it will remove the changes the user wants to commit. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] cherry-pick: make sure all input objects are commits
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:
struct strbuf sb;
[...]
strbuf_init(sb, 1000);
while (strbuf_getwholeline(sb, stdin, '\n') != EOF) {
[...]
if (handle_revision_arg(sb.buf, revs, 0,
REVARG_CANNOT_BE_FILENAME))
die(bad revision '%s', sb.buf);
}
But handle_revision_arg ends up just stuffing that parameter into the
revision-walker options via some helpers:
add_rev_cmdline(revs, object, arg_, REV_CMD_REV, flags ^ local_flags);
add_pending_object_with_mode(revs, object, arg, oc.mode);
This seems to have been lurking since 281eee4 (revision: keep track of
the end-user input from the command line, 2011-08-25).
Junio, at which level should we fix it? We could of course have
read_revisions_from_stdin make a copy of the buffers it passes
down, but perhaps it would be less surprising to instead have
handle_revision_arg make sure it makes a copy of everything it
keeps?
That sounds like the right way to go to me.
The easy fix of course is just this:
diff --git i/revision.c w/revision.c
index 3a20c96..181a8db 100644
--- i/revision.c
+++ w/revision.c
@@ -1277,7 +1277,8 @@ static void read_revisions_from_stdin(struct rev_info
*revs,
}
die(options not supported in --stdin mode);
}
- if (handle_revision_arg(sb.buf, revs, 0,
REVARG_CANNOT_BE_FILENAME))
+ if (handle_revision_arg(xstrdup(sb.buf), revs, 0,
+ REVARG_CANNOT_BE_FILENAME))
die(bad revision '%s', sb.buf);
}
if (seen_dashdash)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: [PATCH v3 4/4] glossary: improve definitions of refspec and pathspec
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 difference of magic words which can be used in the long form and magic signatures which are used in the short form. Because currently there is only one magic *, from a user perspective I would prefer to document only the short form. So I suggest to drop the long form paragraph entirely and start the short form paragraph with A pathspec that begins with a colon `:` has special meaning. If the leading colon `:` is followed by zero or more magic ... --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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 working tree will become its submodule, as it is more convenient to have their $GIT_DIR inside the .git/modules/$name of the superproject. Right. But I'm still worried about .git/modules/$name. Can you explain why it's a better idea than having a dedicated ~/bare? I do not have too much deep knowledge of submodules, nor have I been following this thread very closely, but I have not seen how ~/bare would handle per-submodule information? That is, let us imagine I do: git clone $PROJECT one cd one git submodule update foo git clone $PROJECT two cd two git submodule update foo The current scheme would put the cloned modules into one/.git/modules/foo and two/.git/modules/foo, respectively. Let us imagine instead that the first one writes to ~/modules/$URL (assuming some sane mapping of the URL into the filesystem), and the second one says A-ha, I already have ~/modules/$URL, so I can skip cloning it. But that is not the end of the story. If I do: cd one/foo hack hack hack git commit -m foo cd .. git commit -m 'updated submodule' you would not want to see a dirty, updated submodule in project two. You did not touch two/foo nor advance its HEAD at all. So there is some information that is per-clone (the objects, the remote tips), but there is some information that is per-submodule (where our local branches are, the index, the worktree). I can see why it is advantageous to share the per-clone information between similar clones (because it avoids disk space and network transfer). But I do not think you can escape having some form of per-submodule repo, even if it is a thin git-new-workdir-ish repo that points back to a parent repo for the clone. Is there some part of your proposal that I am missing? It seems like you would still need one/.git/modules/foo for this thin repo. And once we separate out those concerns, I also do not see why sharing per-clone information needs to be related to submodules at all. If I do: git clone $URL one git clone $URL two those can potentially be shared in the same way as two submodule repos that happen to point to the same $URL. It would make sense to me to improve such a shared-object setup independently, and then build the shared-submodule storage on top of that. And by the way, I am actually not sure that such a shared-object setup is a good idea, but only that _if_ you are going to do it with submodules, you might as well do it for all repos. In theory, it is not that hard to have a big per-user object-only repository (either for all repos, or for related ones). But we can do that already with git clone -s, and people do not generally bother, because the maintenance is very tricky (especially dealing with reachability and pruning). I am open to the argument that solving it in a specific case (submodules) lets us make assumptions that simplify the problem from the general case, but I do not offhand see how it would be any easier in this case. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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 unusual place when the sub-repo is cloned. After all, git can't *know* that it'll be a submodule until it's submodule-added to the super-repo. It does not relieve git add (or git submodulea add) from the responsibility of moving .git directory. It only reduces the need to do so. When the user says add and the repository has .git directory in it, add (or submodule add) is still responsible for relocating it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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. Well, I'm against the change in principle because add operates on worktree paths, not URLs. I don't want to change that arbitrarily. I don't understand that statement. If git add is all about specifying what lives under paths in the worktree, what's wrong with letting git add go beyond specifying just files? Syntax aside for the moment, I think a command like git add git-repo-reference foo is perfectly natural: It specifies what is inside worktree path foo. M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR
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 to create a submodule. Both git clone and git init already know how to use a directory that is outside the working tree of the newly created repository to store its $GIT_DIR and point at it with .git in the working tree using the gitfile mechanism (their --separate-git-dir option). 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 $GIT_DIR inside the .git/modules/$name of the superproject. 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 unusual place when the sub-repo is cloned. After all, git can't *know* that it'll be a submodule until it's submodule-added to the super-repo. Sure, the user might have set clone.submoduleGitDir somewhere, but users make mistakes, and this setting makes it harder to clean up a mistake: git clone foo.git # Doh! I mean to clone foof.git! rm -rf foo # Gah, now there's cruft in my clone.submoduleGitDir... All that said, the basic idea of being able to configure where git clone stores .git directories might be reasonable. Something like clone.gitDirHome. It seems like something only a git hacker would ever care about, but that's no reason not to have such a config option. OTOH, I still don't see a reason for it, because I don't buy the submodule-at-clone-time argument. M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/14] Improve git-status --ignored
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. Patches #8 - #14 are performance optimizations. Also available here: https://github.com/kblees/git/tree/kb/improve-git-status-ignored-v2 git pull git://github.com/kblees/git.git kb/improve-git-status-ignored-v2 Changes since v1 (old#-new#: description): 1-1: dir.c: git-status --ignored: don't drop ignored directories 2-2: dir.c: git-status --ignored: don't list files in ignored directories 3-3: dir.c: git-status --ignored: don't list empty ignored directories *-4: dir.c: git-ls-files --directories: don't hide empty directories - new bugfix 4-5: dir.c: git-status --ignored: don't list empty directories as ignored - fixed typo in commit message thanks to Eric Sunshine - patch is reduced to a one-liner (the DIR_HIDE_EMPTY_DIRECTORIES flag has already been fixed in patch 4, renaming the variable and tweaking DIR_SHOW_OTHER_DIRECTORIES is not strictly necessary) *-6: dir.c: make 'git-status --ignored' work within leading directories - new bugfix *-7: dir.c: git-clean -d -X: don't delete tracked directories - changes handling of ignored tracked directories 5-8: dir.c: factor out parts of last_exclude_matching for later reuse 5-9: dir.c: move prep_exclude - split in two patches for cleaner diff - removed unnecessary ';' after '}' 6-10: dir.c: unify is_excluded and is_path_excluded APIs - fixed another typo in commit message 7-11: dir.c: replace is_path_excluded with now equivalent is_excluded API 8-12: dir.c: git-status: avoid is_excluded checks for tracked files *-13: dir.c: git-status --ignored: don't scan the work tree three times - new optimization *-14: dir.c: git-status --ignored: don't scan the work tree twice - new optimization Karsten Blees (14): dir.c: git-status --ignored: don't drop ignored directories dir.c: git-status --ignored: don't list files in ignored directories dir.c: git-status --ignored: don't list empty ignored directories dir.c: git-ls-files --directories: don't hide empty directories dir.c: git-status --ignored: don't list empty directories as ignored dir.c: make 'git-status --ignored' work within leading directories dir.c: git-clean -d -X: don't delete tracked directories dir.c: factor out parts of last_exclude_matching for later reuse dir.c: move prep_exclude dir.c: unify is_excluded and is_path_excluded APIs dir.c: replace is_path_excluded with now equivalent is_excluded API dir.c: git-status: avoid is_excluded checks for tracked files dir.c: git-status --ignored: don't scan the work tree three times dir.c: git-status --ignored: don't scan the work tree twice Documentation/technical/api-directory-listing.txt | 25 +- builtin/add.c | 5 +- builtin/check-ignore.c| 7 +- builtin/ls-files.c| 15 +- dir.c | 499 +- dir.h | 25 +- t/t3001-ls-files-others-exclude.sh| 49 +++ t/t7061-wtstatus-ignore.sh| 125 +- t/t7300-clean.sh | 34 ++ unpack-trees.c| 10 +- unpack-trees.h| 1 - wt-status.c | 24 +- 12 files changed, 455 insertions(+), 364 deletions(-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/14] dir.c: git-status --ignored: don't drop ignored directories
'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 +
t/t7061-wtstatus-ignore.sh | 27 +++
2 files changed, 36 insertions(+)
diff --git a/dir.c b/dir.c
index 57394e4..ec4eebf 100644
--- a/dir.c
+++ b/dir.c
@@ -1060,6 +1060,15 @@ static enum directory_treatment treat_directory(struct
dir_struct *dir,
/* This is the show_other_directories case */
+ /* might be a sub directory in an excluded directory */
+ if (!exclude) {
+ struct path_exclude_check check;
+ int dt = DT_DIR;
+ path_exclude_check_init(check, dir);
+ exclude = is_path_excluded(check, dirname, len, dt);
+ path_exclude_check_clear(check);
+ }
+
/*
* We are looking for ignored files and our directory is not ignored,
* check if it contains only ignored files
diff --git a/t/t7061-wtstatus-ignore.sh b/t/t7061-wtstatus-ignore.sh
index 0da1214..0f1034e 100755
--- a/t/t7061-wtstatus-ignore.sh
+++ b/t/t7061-wtstatus-ignore.sh
@@ -143,4 +143,31 @@ test_expect_success 'status ignored tracked directory and
uncommitted file with
test_cmp expected actual
'
+cat expected \EOF
+?? .gitignore
+?? actual
+?? expected
+!! tracked/
+EOF
+
+test_expect_success 'status ignored tracked directory with uncommitted file in
untracked subdir with --ignore' '
+ rm -rf tracked/uncommitted
+ mkdir tracked/ignored
+ : tracked/ignored/uncommitted
+ git status --porcelain --ignored actual
+ test_cmp expected actual
+'
+
+cat expected \EOF
+?? .gitignore
+?? actual
+?? expected
+!! tracked/ignored/uncommitted
+EOF
+
+test_expect_success 'status ignored tracked directory with uncommitted file in
untracked subdir with --ignore -u' '
+ git status --porcelain --ignored -u actual
+ test_cmp expected actual
+'
+
test_done
--
1.8.1.2.8026.g2b66448.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 02/14] dir.c: git-status --ignored: don't list files in ignored directories
'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 bl...@dcon.de
---
dir.c | 4 +---
t/t7061-wtstatus-ignore.sh | 27 +++
2 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/dir.c b/dir.c
index ec4eebf..7c9bc9c 100644
--- a/dir.c
+++ b/dir.c
@@ -1273,7 +1273,6 @@ static enum path_treatment treat_one_path(struct
dir_struct *dir,
return path_ignored;
case DT_DIR:
strbuf_addch(path, '/');
-
switch (treat_directory(dir, path-buf, path-len, exclude,
simplify)) {
case show_directory:
break;
@@ -1343,8 +1342,7 @@ static int read_directory_recursive(struct dir_struct
*dir,
switch (treat_path(dir, de, path, baselen, simplify)) {
case path_recurse:
contents += read_directory_recursive(dir, path.buf,
-path.len, 0,
-simplify);
+ path.len, check_only, simplify);
continue;
case path_ignored:
continue;
diff --git a/t/t7061-wtstatus-ignore.sh b/t/t7061-wtstatus-ignore.sh
index 0f1034e..4ece129 100755
--- a/t/t7061-wtstatus-ignore.sh
+++ b/t/t7061-wtstatus-ignore.sh
@@ -170,4 +170,31 @@ test_expect_success 'status ignored tracked directory with
uncommitted file in u
test_cmp expected actual
'
+cat expected \EOF
+?? .gitignore
+?? actual
+?? expected
+!! tracked/
+EOF
+
+test_expect_success 'status ignored tracked directory with uncommitted file in
tracked subdir with --ignore' '
+ : tracked/ignored/committed
+ git add -f tracked/ignored/committed
+ git commit -m.
+ git status --porcelain --ignored actual
+ test_cmp expected actual
+'
+
+cat expected \EOF
+?? .gitignore
+?? actual
+?? expected
+!! tracked/ignored/uncommitted
+EOF
+
+test_expect_success 'status ignored tracked directory with uncommitted file in
tracked subdir with --ignore -u' '
+ git status --porcelain --ignored -u actual
+ test_cmp expected actual
+'
+
test_done
--
1.8.1.2.8026.g2b66448.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/14] dir.c: git-status --ignored: don't list empty ignored directories
'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
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/dir.c b/dir.c
index 7c9bc9c..fd1f088 100644
--- a/dir.c
+++ b/dir.c
@@ -1109,16 +1109,13 @@ static int treat_file(struct dir_struct *dir, struct
strbuf *path, int exclude,
struct path_exclude_check check;
int exclude_file = 0;
+ /* Always exclude indexed files */
+ if (index_name_exists(the_index, path-buf, path-len, ignore_case))
+ return 1;
+
if (exclude)
exclude_file = !(dir-flags DIR_SHOW_IGNORED);
else if (dir-flags DIR_SHOW_IGNORED) {
- /* Always exclude indexed files */
- struct cache_entry *ce = index_name_exists(the_index,
- path-buf, path-len, ignore_case);
-
- if (ce)
- return 1;
-
path_exclude_check_init(check, dir);
if (!is_path_excluded(check, path-buf, path-len, dtype))
diff --git a/t/t7061-wtstatus-ignore.sh b/t/t7061-wtstatus-ignore.sh
index 4ece129..28b7d95 100755
--- a/t/t7061-wtstatus-ignore.sh
+++ b/t/t7061-wtstatus-ignore.sh
@@ -122,10 +122,34 @@ cat expected \EOF
?? .gitignore
?? actual
?? expected
+EOF
+
+test_expect_success 'status ignored tracked directory and ignored file with
--ignore' '
+ echo committed .gitignore
+ git status --porcelain --ignored actual
+ test_cmp expected actual
+'
+
+cat expected \EOF
+?? .gitignore
+?? actual
+?? expected
+EOF
+
+test_expect_success 'status ignored tracked directory and ignored file with
--ignore -u' '
+ git status --porcelain --ignored -u actual
+ test_cmp expected actual
+'
+
+cat expected \EOF
+?? .gitignore
+?? actual
+?? expected
!! tracked/
EOF
test_expect_success 'status ignored tracked directory and uncommitted file
with --ignore' '
+ echo tracked .gitignore
: tracked/uncommitted
git status --porcelain --ignored actual
test_cmp expected actual
--
1.8.1.2.8026.g2b66448.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/14] dir.c: git-ls-files --directories: don't hide empty directories
'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
---
dir.c | 6 ++
t/t3001-ls-files-others-exclude.sh | 23 +++
wt-status.c| 2 +-
3 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/dir.c b/dir.c
index fd1f088..1112b05 100644
--- a/dir.c
+++ b/dir.c
@@ -1076,15 +1076,13 @@ static enum directory_treatment treat_directory(struct
dir_struct *dir,
if ((dir-flags DIR_SHOW_IGNORED) !exclude) {
int ignored;
dir-flags = ~DIR_SHOW_IGNORED;
- dir-flags |= DIR_HIDE_EMPTY_DIRECTORIES;
ignored = read_directory_recursive(dir, dirname, len, 1,
simplify);
- dir-flags = ~DIR_HIDE_EMPTY_DIRECTORIES;
dir-flags |= DIR_SHOW_IGNORED;
return ignored ? ignore_directory : show_directory;
}
- if (!(dir-flags DIR_SHOW_IGNORED)
- !(dir-flags DIR_HIDE_EMPTY_DIRECTORIES))
+
+ if (!(dir-flags DIR_HIDE_EMPTY_DIRECTORIES))
return show_directory;
if (!read_directory_recursive(dir, dirname, len, 1, simplify))
return ignore_directory;
diff --git a/t/t3001-ls-files-others-exclude.sh
b/t/t3001-ls-files-others-exclude.sh
index efb7ebc..859da35 100755
--- a/t/t3001-ls-files-others-exclude.sh
+++ b/t/t3001-ls-files-others-exclude.sh
@@ -214,6 +214,29 @@ test_expect_success 'subdirectory ignore (l1)' '
test_cmp expect actual
'
+test_expect_success 'show/hide empty ignored directory (setup)' '
+ rm top/l1/l2/l1
+ rm top/l1/.gitignore
+'
+
+test_expect_success 'show empty ignored directory with --directory' '
+ (
+ cd top
+ git ls-files -o -i --exclude l1 --directory
+ ) actual
+ echo l1/ expect
+ test_cmp expect actual
+'
+
+test_expect_success 'hide empty ignored directory with --no-empty-directory' '
+ (
+ cd top
+ git ls-files -o -i --exclude l1 --directory --no-empty-directory
+ ) actual
+ expect
+ test_cmp expect actual
+'
+
test_expect_success 'pattern matches prefix completely' '
: expect
git ls-files -i -o --exclude /three/a.3[abc] actual
diff --git a/wt-status.c b/wt-status.c
index ef405d0..79eb124 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -518,7 +518,7 @@ static void wt_status_collect_untracked(struct wt_status *s)
dir.nr = 0;
dir.flags = DIR_SHOW_IGNORED;
if (s-show_untracked_files != SHOW_ALL_UNTRACKED_FILES)
- dir.flags |= DIR_SHOW_OTHER_DIRECTORIES;
+ dir.flags |= DIR_SHOW_OTHER_DIRECTORIES |
DIR_HIDE_EMPTY_DIRECTORIES;
fill_directory(dir, s-pathspec);
for (i = 0; i dir.nr; i++) {
struct dir_entry *ent = dir.entries[i];
--
1.8.1.2.8026.g2b66448.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/14] dir.c: git-status --ignored: don't list empty directories as ignored
'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 untracked files, as the directory may be
empty.
Signed-off-by: Karsten Blees bl...@dcon.de
---
dir.c | 5 +++--
t/t7061-wtstatus-ignore.sh | 26 --
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/dir.c b/dir.c
index 1112b05..c5705e3 100644
--- a/dir.c
+++ b/dir.c
@@ -1071,7 +1071,7 @@ static enum directory_treatment treat_directory(struct
dir_struct *dir,
/*
* We are looking for ignored files and our directory is not ignored,
-* check if it contains only ignored files
+* check if it contains untracked files (i.e. is listed as untracked)
*/
if ((dir-flags DIR_SHOW_IGNORED) !exclude) {
int ignored;
@@ -1079,7 +1079,8 @@ static enum directory_treatment treat_directory(struct
dir_struct *dir,
ignored = read_directory_recursive(dir, dirname, len, 1,
simplify);
dir-flags |= DIR_SHOW_IGNORED;
- return ignored ? ignore_directory : show_directory;
+ if (ignored)
+ return ignore_directory;
}
if (!(dir-flags DIR_HIDE_EMPTY_DIRECTORIES))
diff --git a/t/t7061-wtstatus-ignore.sh b/t/t7061-wtstatus-ignore.sh
index 28b7d95..6171a49 100755
--- a/t/t7061-wtstatus-ignore.sh
+++ b/t/t7061-wtstatus-ignore.sh
@@ -64,13 +64,35 @@ cat expected \EOF
?? .gitignore
?? actual
?? expected
-!! untracked-ignored/
EOF
-test_expect_success 'status untracked directory with ignored files with
--ignore' '
+test_expect_success 'status empty untracked directory with --ignore' '
rm -rf ignored
mkdir untracked-ignored
mkdir untracked-ignored/test
+ git status --porcelain --ignored actual
+ test_cmp expected actual
+'
+
+cat expected \EOF
+?? .gitignore
+?? actual
+?? expected
+EOF
+
+test_expect_success 'status empty untracked directory with --ignore -u' '
+ git status --porcelain --ignored -u actual
+ test_cmp expected actual
+'
+
+cat expected \EOF
+?? .gitignore
+?? actual
+?? expected
+!! untracked-ignored/
+EOF
+
+test_expect_success 'status untracked directory with ignored files with
--ignore' '
: untracked-ignored/ignored
: untracked-ignored/test/ignored
git status --porcelain --ignored actual
--
1.8.1.2.8026.g2b66448.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/14] dir.c: make 'git-status --ignored' work within leading directories
'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 aborting at the top level untracked directory.
As a side effect, this also eliminates a recursive directory scan per
leading directory level, as treat_directory() can no longer call
read_directory_recursive() when called from treat_leading_path().
Signed-off-by: Karsten Blees bl...@dcon.de
---
dir.c | 3 +++
t/t7061-wtstatus-ignore.sh | 19 +++
2 files changed, 22 insertions(+)
diff --git a/dir.c b/dir.c
index c5705e3..822e501 100644
--- a/dir.c
+++ b/dir.c
@@ -1403,12 +1403,14 @@ static int treat_leading_path(struct dir_struct *dir,
struct strbuf sb = STRBUF_INIT;
int baselen, rc = 0;
const char *cp;
+ int old_flags = dir-flags;
while (len path[len - 1] == '/')
len--;
if (!len)
return 1;
baselen = 0;
+ dir-flags = ~DIR_SHOW_OTHER_DIRECTORIES;
while (1) {
cp = path + baselen + !!baselen;
cp = memchr(cp, '/', path + len - cp);
@@ -1431,6 +1433,7 @@ static int treat_leading_path(struct dir_struct *dir,
}
}
strbuf_release(sb);
+ dir-flags = old_flags;
return rc;
}
diff --git a/t/t7061-wtstatus-ignore.sh b/t/t7061-wtstatus-ignore.sh
index 6171a49..4c6f145 100755
--- a/t/t7061-wtstatus-ignore.sh
+++ b/t/t7061-wtstatus-ignore.sh
@@ -32,6 +32,25 @@ test_expect_success 'status untracked directory with
--ignored -u' '
git status --porcelain --ignored -u actual
test_cmp expected actual
'
+cat expected \EOF
+?? untracked/uncommitted
+!! untracked/ignored
+EOF
+
+test_expect_success 'status prefixed untracked directory with --ignored' '
+ git status --porcelain --ignored untracked/ actual
+ test_cmp expected actual
+'
+
+cat expected \EOF
+?? untracked/uncommitted
+!! untracked/ignored
+EOF
+
+test_expect_success 'status prefixed untracked sub-directory with --ignored
-u' '
+ git status --porcelain --ignored -u untracked/ actual
+ test_cmp expected actual
+'
cat expected \EOF
?? .gitignore
--
1.8.1.2.8026.g2b66448.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/14] dir.c: git-clean -d -X: don't delete tracked directories
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 --directory: lists ignored tracked
directories instead of other directories.
- git-status --ignored: lists ignored tracked directories while contained
files may be listed as modified. Paths listed by git-status should be
disjoint (except in long format where a path may be listed in both the
staged and unstaged section).
Additionally, the current behaviour violates documentation in gitignore(5)
(Specifies intentionally *untracked* files to ignore) and Documentation/
technical/api-directory-listing.txt (DIR_SHOW_OTHER_DIRECTORIES: Include
a directory that is *not tracked*.).
In dir.c::treat_directory, remove the special handling of ignored tracked
directories, so that the DIR_SHOW_OTHER_DIRECTORIES flag only affects
other (i.e. untracked) directories. In dir.c::dir_add_name, check that
added paths are untracked even if DIR_SHOW_IGNORED is set.
Signed-off-by: Karsten Blees bl...@dcon.de
---
dir.c | 11 +++
t/t3001-ls-files-others-exclude.sh | 26 ++
t/t7061-wtstatus-ignore.sh | 6 +++---
t/t7300-clean.sh | 34 ++
4 files changed, 66 insertions(+), 11 deletions(-)
diff --git a/dir.c b/dir.c
index 822e501..f10fb69 100644
--- a/dir.c
+++ b/dir.c
@@ -897,8 +897,7 @@ static struct dir_entry *dir_entry_new(const char
*pathname, int len)
static struct dir_entry *dir_add_name(struct dir_struct *dir, const char
*pathname, int len)
{
- if (!(dir-flags DIR_SHOW_IGNORED)
- cache_name_exists(pathname, len, ignore_case))
+ if (cache_name_exists(pathname, len, ignore_case))
return NULL;
ALLOC_GROW(dir-entries, dir-nr+1, dir-alloc);
@@ -1000,9 +999,8 @@ static enum exist_status directory_exists_in_index(const
char *dirname, int len)
* traversal routine.
*
* Case 1: If we *already* have entries in the index under that
- * directory name, we recurse into the directory to see all the files,
- * unless the directory is excluded and we want to show ignored
- * directories
+ * directory name, we always recurse into the directory to see
+ * all the files.
*
* Case 2: If we *already* have that directory name as a gitlink,
* we always continue to see it as a gitlink, regardless of whether
@@ -1037,9 +1035,6 @@ static enum directory_treatment treat_directory(struct
dir_struct *dir,
/* The len-1 is to strip the final '/' */
switch (directory_exists_in_index(dirname, len-1)) {
case index_directory:
- if ((dir-flags DIR_SHOW_OTHER_DIRECTORIES) exclude)
- break;
-
return recurse_into_directory;
case index_gitdir:
diff --git a/t/t3001-ls-files-others-exclude.sh
b/t/t3001-ls-files-others-exclude.sh
index 859da35..ec4fae2 100755
--- a/t/t3001-ls-files-others-exclude.sh
+++ b/t/t3001-ls-files-others-exclude.sh
@@ -237,6 +237,32 @@ test_expect_success 'hide empty ignored directory with
--no-empty-directory' '
test_cmp expect actual
'
+test_expect_success 'show/hide empty ignored sub-directory (setup)' '
+top/l1/tracked
+ (
+ cd top
+ git add -f l1/tracked
+ )
+'
+
+test_expect_success 'show empty ignored sub-directory with --directory' '
+ (
+ cd top
+ git ls-files -o -i --exclude l1 --directory
+ ) actual
+ echo l1/l2/ expect
+ test_cmp expect actual
+'
+
+test_expect_success 'hide empty ignored sub-directory with
--no-empty-directory' '
+ (
+ cd top
+ git ls-files -o -i --exclude l1 --directory --no-empty-directory
+ ) actual
+ expect
+ test_cmp expect actual
+'
+
test_expect_success 'pattern matches prefix completely' '
: expect
git ls-files -i -o --exclude /three/a.3[abc] actual
diff --git a/t/t7061-wtstatus-ignore.sh b/t/t7061-wtstatus-ignore.sh
index 4c6f145..460789b 100755
--- a/t/t7061-wtstatus-ignore.sh
+++ b/t/t7061-wtstatus-ignore.sh
@@ -186,7 +186,7 @@ cat expected \EOF
?? .gitignore
?? actual
?? expected
-!! tracked/
+!! tracked/uncommitted
EOF
test_expect_success 'status ignored tracked directory and uncommitted file
with --ignore' '
@@ -212,7 +212,7 @@ cat expected \EOF
?? .gitignore
?? actual
?? expected
-!! tracked/
+!! tracked/ignored/
EOF
test_expect_success 'status ignored tracked directory with uncommitted file in
untracked subdir with --ignore' '
@@ -239,7 +239,7 @@ cat expected \EOF
?? .gitignore
?? actual
?? expected
-!! tracked/
+!! tracked/ignored/uncommitted
EOF
test_expect_success 'status ignored tracked directory with
[PATCH v2 08/14] dir.c: factor out parts of last_exclude_matching for later reuse
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,
return -1; /* undecided */
}
+static struct exclude *last_exclude_matching_from_lists(struct dir_struct *dir,
+ const char *pathname, int pathlen, const char *basename,
+ int *dtype_p)
+{
+ int i, j;
+ struct exclude_list_group *group;
+ struct exclude *exclude;
+ for (i = EXC_CMDL; i = EXC_FILE; i++) {
+ group = dir-exclude_list_group[i];
+ for (j = group-nr - 1; j = 0; j--) {
+ exclude = last_exclude_matching_from_list(
+ pathname, pathlen, basename, dtype_p,
+ group-el[j]);
+ if (exclude)
+ return exclude;
+ }
+ }
+ return NULL;
+}
+
/*
* Loads the exclude lists for the directory containing pathname, then
* scans all exclude lists to determine whether pathname is excluded.
@@ -762,25 +782,13 @@ static struct exclude *last_exclude_matching(struct
dir_struct *dir,
int *dtype_p)
{
int pathlen = strlen(pathname);
- int i, j;
- struct exclude_list_group *group;
- struct exclude *exclude;
const char *basename = strrchr(pathname, '/');
basename = (basename) ? basename+1 : pathname;
prep_exclude(dir, pathname, basename-pathname);
- for (i = EXC_CMDL; i = EXC_FILE; i++) {
- group = dir-exclude_list_group[i];
- for (j = group-nr - 1; j = 0; j--) {
- exclude = last_exclude_matching_from_list(
- pathname, pathlen, basename, dtype_p,
- group-el[j]);
- if (exclude)
- return exclude;
- }
- }
- return NULL;
+ return last_exclude_matching_from_lists(dir, pathname, pathlen,
+ basename, dtype_p);
}
/*
--
1.8.1.2.8026.g2b66448.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/14] dir.c: move prep_exclude
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
--- a/dir.c
+++ b/dir.c
@@ -549,78 +549,6 @@ void add_excludes_from_file(struct dir_struct *dir, const
char *fname)
die(cannot use %s as an exclude file, fname);
}
-/*
- * Loads the per-directory exclude list for the substring of base
- * which has a char length of baselen.
- */
-static void prep_exclude(struct dir_struct *dir, const char *base, int baselen)
-{
- struct exclude_list_group *group;
- struct exclude_list *el;
- struct exclude_stack *stk = NULL;
- int current;
-
- if ((!dir-exclude_per_dir) ||
- (baselen + strlen(dir-exclude_per_dir) = PATH_MAX))
- return; /* too long a path -- ignore */
-
- group = dir-exclude_list_group[EXC_DIRS];
-
- /* Pop the exclude lists from the EXCL_DIRS exclude_list_group
-* which originate from directories not in the prefix of the
-* path being checked. */
- while ((stk = dir-exclude_stack) != NULL) {
- if (stk-baselen = baselen
- !strncmp(dir-basebuf, base, stk-baselen))
- break;
- el = group-el[dir-exclude_stack-exclude_ix];
- dir-exclude_stack = stk-prev;
- free((char *)el-src); /* see strdup() below */
- clear_exclude_list(el);
- free(stk);
- group-nr--;
- }
-
- /* Read from the parent directories and push them down. */
- current = stk ? stk-baselen : -1;
- while (current baselen) {
- struct exclude_stack *stk = xcalloc(1, sizeof(*stk));
- const char *cp;
-
- if (current 0) {
- cp = base;
- current = 0;
- }
- else {
- cp = strchr(base + current + 1, '/');
- if (!cp)
- die(oops in prep_exclude);
- cp++;
- }
- stk-prev = dir-exclude_stack;
- stk-baselen = cp - base;
- memcpy(dir-basebuf + current, base + current,
- stk-baselen - current);
- strcpy(dir-basebuf + stk-baselen, dir-exclude_per_dir);
- /*
-* dir-basebuf gets reused by the traversal, but we
-* need fname to remain unchanged to ensure the src
-* member of each struct exclude correctly
-* back-references its source file. Other invocations
-* of add_exclude_list provide stable strings, so we
-* strdup() and free() here in the caller.
-*/
- el = add_exclude_list(dir, EXC_DIRS, strdup(dir-basebuf));
- stk-exclude_ix = group-nr - 1;
- add_excludes_from_file_to_list(dir-basebuf,
- dir-basebuf, stk-baselen,
- el, 1);
- dir-exclude_stack = stk;
- current = stk-baselen;
- }
- dir-basebuf[baselen] = '\0';
-}
-
int match_basename(const char *basename, int basenamelen,
const char *pattern, int prefix, int patternlen,
int flags)
@@ -772,6 +700,78 @@ static struct exclude
*last_exclude_matching_from_lists(struct dir_struct *dir,
}
/*
+ * Loads the per-directory exclude list for the substring of base
+ * which has a char length of baselen.
+ */
+static void prep_exclude(struct dir_struct *dir, const char *base, int baselen)
+{
+ struct exclude_list_group *group;
+ struct exclude_list *el;
+ struct exclude_stack *stk = NULL;
+ int current;
+
+ if ((!dir-exclude_per_dir) ||
+ (baselen + strlen(dir-exclude_per_dir) = PATH_MAX))
+ return; /* too long a path -- ignore */
+
+ group = dir-exclude_list_group[EXC_DIRS];
+
+ /* Pop the exclude lists from the EXCL_DIRS exclude_list_group
+* which originate from directories not in the prefix of the
+* path being checked. */
+ while ((stk = dir-exclude_stack) != NULL) {
+ if (stk-baselen = baselen
+ !strncmp(dir-basebuf, base, stk-baselen))
+ break;
+ el = group-el[dir-exclude_stack-exclude_ix];
+ dir-exclude_stack = stk-prev;
+ free((char *)el-src); /* see strdup() below */
+ clear_exclude_list(el);
+ free(stk);
+ group-nr--;
+ }
+
+ /* Read from the parent directories and push them down. */
+ current = stk ? stk-baselen : -1;
+ while (current
