* Re: [RFC PATCHv2 04/10] gitweb: Use Cache::Cache compatibile (get, set) output caching
From: Petr Baudis @ 2010-02-10 1:23 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, John 'Warthog9' Hawley,
John 'Warthog9' Hawley
In-Reply-To: <201002100212.26157.jnareb@gmail.com>
On Wed, Feb 10, 2010 at 02:12:24AM +0100, Jakub Narebski wrote:
> On Tue, 9 Feb 2010 at 11:30 +0100, Jakub Narebski wrote:
>
> > The cache_fetch subroutine captures output (from STDOUT only, as
> > STDERR is usually logged) using either ->push_layer()/->pop_layer()
> > from PerlIO::Util submodule (if it is available), or by setting and
> > restoring *STDOUT. Note that only the former could be tested reliably
> > to be reliable in t9503 test!
>
> Scratch that, I have just checked that (at least for Apache + mod_cgi,
> but I don't think that it matters) the latter solution, with setting
> and restoring *STDOUT doesn't work: I would get data in cache (so it
> can be restored later), but instead of output I would get Internal Server
> Error ("The server encountered an internal error or misconfiguration and
> was unable to complete your request.") without even a hint what the
> problem was. Sprinkling "die ...: $!" didn't help to catch this error:
> I suspect that the problem is with capturing.
>
> So we either would have to live with non-core PerlIO::Util or (pure Perl)
> Capture::Tiny, or do the 'print -> print $out' patch...
All the magic methods seem to be troublesome, but in that case I'd
really prefer a level of indirection instead of filehandle - as is,
'print (...) -> output (...)' ins. of 'print (...) -> print $out (...)'
(or whatever). That should be really flexible and completely
futureproof, and I don't think the level of indirection would incur any
measurable overhead, would it?
--
Petr "Pasky" Baudis
If you can't see the value in jet powered ants you should turn in
your nerd card. -- Dunbal (464142)
^ permalink raw reply
* Re: [RFC PATCHv2 04/10] gitweb: Use Cache::Cache compatibile (get, set) output caching
From: Jakub Narebski @ 2010-02-10 1:12 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Petr Baudis
In-Reply-To: <1265711427-15193-5-git-send-email-jnareb@gmail.com>
On Tue, 9 Feb 2010 at 11:30 +0100, Jakub Narebski wrote:
> The cache_fetch subroutine captures output (from STDOUT only, as
> STDERR is usually logged) using either ->push_layer()/->pop_layer()
> from PerlIO::Util submodule (if it is available), or by setting and
> restoring *STDOUT. Note that only the former could be tested reliably
> to be reliable in t9503 test!
Scratch that, I have just checked that (at least for Apache + mod_cgi,
but I don't think that it matters) the latter solution, with setting
and restoring *STDOUT doesn't work: I would get data in cache (so it
can be restored later), but instead of output I would get Internal Server
Error ("The server encountered an internal error or misconfiguration and
was unable to complete your request.") without even a hint what the
problem was. Sprinkling "die ...: $!" didn't help to catch this error:
I suspect that the problem is with capturing.
So we either would have to live with non-core PerlIO::Util or (pure Perl)
Capture::Tiny, or do the 'print -> print $out' patch...
[....]
> Capturing gitweb output
> =======================
> When output (response) caching is enabled, the caching mechanism has to
> capture gitweb output (perhaps while printing it to standard output) to
> save it to cache, unless the data is available in cache and not expired.
>
> Because die_error uses 'exit', and because it uses git_header_html and
> other printing subroutines (which output has to be captured in other
> situations), it needs to disable caching, unless we are "tee"-ing.
> Otherwise we would get no output from die_error (because it is captured),
> but also we would not get data to be saved in cache and printed, because
> 'exit' in die_error would exit capture, too. This restricts methods and
> modules that can be used to capture output.
>
> Below there are presented various considered and used ways of capturing the
> output, or "tee"-ing it (capturing while printing), with their advantages
> and disadvantages.
>
>
> Capturing output (capture)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
> 5. Without 'print <sth>' to 'print $out <sth>' change to gitweb, one can try
> manipulating *STDOUT directly, first saving *STDOUT or \*STDOUT to some
> variable, then setting *STDOUT = $data_fh, where $data_fh is filehandle
> opened to in-memory file.
>
> This seems to work, does not require large patch to gitweb, and does not
> require extra (non-core) Perl module. Nevertheless it seems fragile with
> respect to restoring STDOUT, and even though basic tests (not included)
> of this mechanism producted expected result, I wasn't able to write
> working tests when using this method.
>
> We could probably examine how Capture::Tiny does it, and reuse (copy)
> relevant parts of code, perhaps duplicating STDOUT, closing it and then
> reopening as in-memory filehandle.
>
> YMMV (Your Mileage May Vary).
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] git log -p -m: Document, honor --first-parent
From: Petr Baudis @ 2010-02-10 1:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian MICHON, git list
In-Reply-To: <7v1vguuf8h.fsf@alter.siamese.dyndns.org>
On Tue, Feb 09, 2010 at 04:05:50PM -0800, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > I'm not sure if there is any clever switch for this, but I usually
> > just use one of
> >
> > git diff mergecommit^1 mergecommit
> > git diff mergecommit^2 mergecommit
> >
> > depending on which parent I want the diff against. If you always do your
> > merges as "on mainline, merging in a topic" without fast-forwarding,
> > diff against the first parent will be probably the right one and you can
> > simply use:
> >
> > git diff mergecommit^ mergecommit
>
> Frankly, we should make "git log --first-parent -p" DTRT, I think.
>
> The attitude towards merges we maintain officially is "all parents are
> equal", but in practice, there often are cases where --first-parent
> traversal makes a lot more sense when browsing the history (especially
> "the official" one). The use of that option should be a clear enough sign
> that diff between the first parent and the merge result is asked for.
I have also discovered -m while digging into this, which seems to have
the effect of showing the merge TWICE, each time against a different
parent; this is sort-of-almost what Christian also wanted.
This seems to be undocumented and does have this effect only in log,
not in show - I have absolutely no idea why from cursory code
examination.
I think making just --first-parent alone imply this behavior is wrong,
IMHO first-parent alone does not warrant avoiding combined-diff behavior.
I'm not really sure though, so feel free to add another
if (revs->diff && revs->follow_first_parent)
revs->ignore_merges = 0;
test at the right place (whatever that is). At any rate, -m explicitly
states the intent and the current behavior of not honoring
--first-parent is IMHO a bug.
I think --first-parent documentation is still accurate with the new
behavior, so I adjusted just -m documentation - also making the flag
actually visible for non-diff-tree-stdin cases. Sorry that it's both
conflated in a single patch, I'd rather avoid creating a patch queue
out of this supposedly-5-minute hack.
--8<--
git log -p -m has a special magic behavior of showin one merge entry per
parent, with an appropriate diff; this can be frequently useful when
examining histories where full set of changes introduced by a merged
branch is interesting, not only the conflicts.
This patch properly documents the -m switch, which has so far been
mentioned only as a fairly special diff-tree flag. It also makes the
code show full patch entry only for the first parent in case
--first-parent is used. Thus,
git log -p -m --first-parent
will show the history from the "main branch perspective", while also
including full diff of changes introduced by other merged in branches.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
index 0f25ba7..8f9a241 100644
--- a/Documentation/diff-generate-patch.txt
+++ b/Documentation/diff-generate-patch.txt
@@ -56,7 +56,8 @@ combined diff format
"git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or
'--cc' option to produce 'combined diff'. For showing a merge commit
-with "git log -p", this is the default format.
+with "git log -p", this is the default format; you can force showing
+full diff with the '-m' option.
A 'combined diff' format looks like this:
------------
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 0e39bb6..a2a2d04 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -118,6 +118,15 @@ git log master --not --remotes=*/master::
Shows all commits that are in local master but not in any remote
repository master branches.
+git log -p -m --first-parent::
+
+ Shows the history including change diffs, but only from the
+ "main branch" perspective, skipping commits that come only from
+ merges, and showing full diffs of changes introduced by the merges.
+ This makes sense only when following a strict policy of merging all
+ topic branches when staying on a single integration branch and
+ making sure the merges are not fast-forwards.
+
Discussion
----------
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 6e9baf8..d7d0dee 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -108,8 +108,8 @@ options may be given. See linkgit:git-diff-files[1] for more options.
-c::
- This flag changes the way a merge commit is displayed. It shows
- the differences from each of the parents to the merge result
+ This flag forces the default way a merge commit is displayed. It
+ shows the differences from each of the parents to the merge result
simultaneously instead of showing pairwise diff between a parent
and the result one at a time. Furthermore, it lists only files
which were modified from all parents.
@@ -121,6 +121,15 @@ options may be given. See linkgit:git-diff-files[1] for more options.
the parents have only two variants and the merge result picks
one of them without modification.
+-m::
+
+ This flag makes the merge commits show the full diff like
+ regular commits; for each merge parent, a separate log entry
+ and diff is generated. (An exception is made if '--first-parent'
+ option has been also passed; in that case, only diff against
+ the first parent is shown, representing the changes the merge
+ brought _into_ the then-current branch.)
+
-r::
Show recursive diffs.
diff --git a/log-tree.c b/log-tree.c
index 27afcf6..fb990a1 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -514,6 +514,14 @@ static int log_tree_diff(struct rev_info *opt, struct commit *commit, struct log
return 0;
else if (opt->combine_merges)
return do_diff_combined(opt, commit);
+ else if (opt->first_parent_only) {
+ /* Generate merge log entry only for the first
+ * parent, showing summary diff of the others
+ * we merged _in_. */
+ diff_tree_sha1(parents->item->object.sha1, sha1, "", &opt->diffopt);
+ log_tree_diff_flush(opt);
+ return !opt->loginfo;
+ }
/* If we show individual diffs, show the parent info */
log->parent = parents->item;
^ permalink raw reply related
* Re: What should I do to display the diff of even a simple merge commit?
From: Christian MICHON @ 2010-02-10 0:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git list
In-Reply-To: <20100209235707.GQ9553@machine.or.cz>
On Wed, Feb 10, 2010 at 12:57 AM, Petr Baudis <pasky@suse.cz> wrote:
> Hi!
>
> On Wed, Feb 10, 2010 at 12:45:44AM +0100, Christian MICHON wrote:
>> I'm performing many merges between developpers branches these days,
>> most of them not yielding into conflicts. (understand: simple merges)
>>
>> All is good, but sometimes, I would like to really like what has been changed.
>>
>> As I do not systematically do this "git merge --no-commit --stat
>> <list_to_merge>" and then fire "git gui" to inspect the diffs before
>> the real commit, I'm wondering: how could I do this using some
>> plumbing ?
>>
>> Right now, I've tried the obvious git log -c -p, git show -u --cc, but
>> since the merge are simple merges, I cannot get any diff output. I
>> believe this is by construction.
>>
>> Any hints ?
>
> I'm not sure if there is any clever switch for this, but I usually
> just use one of
>
> git diff mergecommit^1 mergecommit
> git diff mergecommit^2 mergecommit
>
> depending on which parent I want the diff against. If you always do your
> merges as "on mainline, merging in a topic" without fast-forwarding,
> diff against the first parent will be probably the right one and you can
> simply use:
>
> git diff mergecommit^ mergecommit
>
Hi Petr,
unfortunately it does not ouput anything :-( the diff is empty, again...
I'm fiddling now with "git checkout -f <that-commit>", and I'm faking
an "amend last commit" using "git gui". With this dirty trick, I get
the same diff I would have gotten from git gui with a merge
--no-commit.
Thanks for suggesting !
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: What should I do to display the diff of even a simple merge commit?
From: Junio C Hamano @ 2010-02-10 0:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: Christian MICHON, git list
In-Reply-To: <20100209235707.GQ9553@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I'm not sure if there is any clever switch for this, but I usually
> just use one of
>
> git diff mergecommit^1 mergecommit
> git diff mergecommit^2 mergecommit
>
> depending on which parent I want the diff against. If you always do your
> merges as "on mainline, merging in a topic" without fast-forwarding,
> diff against the first parent will be probably the right one and you can
> simply use:
>
> git diff mergecommit^ mergecommit
Frankly, we should make "git log --first-parent -p" DTRT, I think.
The attitude towards merges we maintain officially is "all parents are
equal", but in practice, there often are cases where --first-parent
traversal makes a lot more sense when browsing the history (especially
"the official" one). The use of that option should be a clear enough sign
that diff between the first parent and the merge result is asked for.
^ permalink raw reply
* Re: What should I do to display the diff of even a simple merge commit?
From: Petr Baudis @ 2010-02-09 23:57 UTC (permalink / raw)
To: Christian MICHON; +Cc: git list
In-Reply-To: <46d6db661002091545j74f625ffr74ca70a0474948fc@mail.gmail.com>
Hi!
On Wed, Feb 10, 2010 at 12:45:44AM +0100, Christian MICHON wrote:
> I'm performing many merges between developpers branches these days,
> most of them not yielding into conflicts. (understand: simple merges)
>
> All is good, but sometimes, I would like to really like what has been changed.
>
> As I do not systematically do this "git merge --no-commit --stat
> <list_to_merge>" and then fire "git gui" to inspect the diffs before
> the real commit, I'm wondering: how could I do this using some
> plumbing ?
>
> Right now, I've tried the obvious git log -c -p, git show -u --cc, but
> since the merge are simple merges, I cannot get any diff output. I
> believe this is by construction.
>
> Any hints ?
I'm not sure if there is any clever switch for this, but I usually
just use one of
git diff mergecommit^1 mergecommit
git diff mergecommit^2 mergecommit
depending on which parent I want the diff against. If you always do your
merges as "on mainline, merging in a topic" without fast-forwarding,
diff against the first parent will be probably the right one and you can
simply use:
git diff mergecommit^ mergecommit
Kind regards,
Petr "Pasky" Baudis
^ permalink raw reply
* Re: Fix signal handler
From: Daniel Barkalow @ 2010-02-09 23:49 UTC (permalink / raw)
To: Markus Elfring; +Cc: Jeff King, git
In-Reply-To: <4B71A2EE.8070708@web.de>
On Tue, 9 Feb 2010, Markus Elfring wrote:
>
> >
> > If you can demonstrate a practical problem and provide a patch, then I
> > am sure people would be happy to read it.
> >
>
> I need a few further clarifications on this issue to choose a potential fix.
>
> I have noticed that the variable "show_early_output" gets a value
> assigned only at a few places in the source code. I wonder that the set
> pointer is only used by the function "limit_list" to call the function
> "log_show_early" on demand.
> http://git.kernel.org/?p=git/git.git;a=blob;f=revision.c;h=3ba6d991f6e9789949c314c2981dfc6b208a6f66;hb=HEAD#l683
>
> I find that a simple flag would be sufficient. I see no need to handle
> different function pointers here. Do any objections exist to achieve the
> same effect with the data type "sig_atomic_t"?
In that particular instance, there's actually a comment that says it uses
an int (which is almost certainly what sig_atomic_t is, but sig_atomic_t
might not be defined on some actual platforms). Making the code match the
comment, at least, would be good.
In particular, function pointers are more likely than other pointers to be
not a machine word. I'm pretty sure that an IA64 machine could potentially
have a race with a small window here.
As to whether to use int (as the comment says) or sig_atomic_t, I don't
really have any idea which would have fewer problems.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: What should I do to display the diff of even a simple merge commit?
From: Christian MICHON @ 2010-02-09 23:46 UTC (permalink / raw)
To: git list
In-Reply-To: <46d6db661002091545j74f625ffr74ca70a0474948fc@mail.gmail.com>
On Wed, Feb 10, 2010 at 12:45 AM, Christian MICHON
<christian.michon@gmail.com> wrote:
> Hi list,
>
> I'm performing many merges between developpers branches these days,
> most of them not yielding into conflicts. (understand: simple merges)
>
> All is good, but sometimes, I would like to really like what has been changed.
I meant << I would really like to see what has been changed. >>
>
> As I do not systematically do this "git merge --no-commit --stat
> <list_to_merge>" and then fire "git gui" to inspect the diffs before
> the real commit, I'm wondering: how could I do this using some
> plumbing ?
>
> Right now, I've tried the obvious git log -c -p, git show -u --cc, but
> since the merge are simple merges, I cannot get any diff output. I
> believe this is by construction.
>
> Any hints ?
>
> Thanks in advance.
>
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* What should I do to display the diff of even a simple merge commit?
From: Christian MICHON @ 2010-02-09 23:45 UTC (permalink / raw)
To: git list
Hi list,
I'm performing many merges between developpers branches these days,
most of them not yielding into conflicts. (understand: simple merges)
All is good, but sometimes, I would like to really like what has been changed.
As I do not systematically do this "git merge --no-commit --stat
<list_to_merge>" and then fire "git gui" to inspect the diffs before
the real commit, I'm wondering: how could I do this using some
plumbing ?
Right now, I've tried the obvious git log -c -p, git show -u --cc, but
since the merge are simple merges, I cannot get any diff output. I
believe this is by construction.
Any hints ?
Thanks in advance.
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: git add -u nonexistent-file
From: Junio C Hamano @ 2010-02-09 23:18 UTC (permalink / raw)
To: Chris Packham; +Cc: Junio C Hamano, Jeff King, SZEDER Gábor, git
In-Reply-To: <a038bef51002091417o1048c098x898517596115ed90@mail.gmail.com>
Chris Packham <judge.packham@gmail.com> writes:
> On Tue, Feb 9, 2010 at 4:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> It won't be entirely trivial to do so efficiently but it shouldn't be a
>> rocket surgery.
>>
>> Something like this (untested of course)?
>>
>
> Passes my new test and all the rest in t2200-add-update.sh and t3700-add.sh.
Thanks; will squash two tests into one.
^ permalink raw reply
* Re: t5401-update-hooks test failure
From: Junio C Hamano @ 2010-02-09 23:16 UTC (permalink / raw)
To: Shawn O. Pearce, Nicolas Pitre; +Cc: Larry D'Anna, Jeff King, git
In-Reply-To: <7vpr4eyqok.fsf@alter.siamese.dyndns.org>
Oh, I hate myself ;-)
This seems to fix the test. Could somebody please explain why?
I am guessing it has something to do with O_APPEND but I cannot come up
with a commit log message that clearly describes the fix.
t/t5401-update-hooks.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/t/t5401-update-hooks.sh b/t/t5401-update-hooks.sh
index c3cf397..804431a 100755
--- a/t/t5401-update-hooks.sh
+++ b/t/t5401-update-hooks.sh
@@ -61,8 +61,9 @@ EOF
chmod u+x victim/.git/hooks/post-update
test_expect_success push '
+ rm -f send.out send.err &&
test_must_fail git send-pack --force ./victim/.git \
- master tofail >send.out 2>send.err
+ master tofail >>send.out 2>>send.err
'
test_expect_success 'updated as expected' '
^ permalink raw reply related
* Re: [stgit] Documentation build error in proposed branch
From: Catalin Marinas @ 2010-02-09 23:07 UTC (permalink / raw)
To: Gustav Hållberg; +Cc: git
In-Reply-To: <a1e915351002080500u74e4878fy500713ddb25aa750@mail.gmail.com>
2010/2/8 Gustav Hållberg <gustav@gmail.com>:
> As of recently, I cannot compile documentation in
> git://repo.or.cz/stgit.git proposed:
>
> lux:~/devel/stgit$ git ls-files -o | xargs rm
> lux:~/devel/stgit$ git rev-parse HEAD
> c7506039d0299c093140857b7a617ec6bcdbfc13
> lux:~/devel/stgit$ make all doc
> :
> cd Documentation && make all
> make[1]: Entering directory `/home/gustav/devel/stgit/Documentation'
> rm -f doc.dep+ doc.dep
> perl ./build-docdep.perl >doc.dep+
> mv doc.dep+ doc.dep
> make[1]: Leaving directory `/home/gustav/devel/stgit/Documentation'
> make[1]: Entering directory `/home/gustav/devel/stgit/Documentation'
> ../stg-build --cmd-list > command-list.txt
Thanks for reporting this. I actually pushed it to master without
checking the documentation building. I'll have a look tomorrow.
--
Catalin
^ permalink raw reply
* [Announce] bup 0.09: git-based backup system for really huge datasets
From: Avery Pennarun @ 2010-02-09 22:48 UTC (permalink / raw)
To: Git Mailing List
Hi all,
bup is a file backup tool based on the git packfile format. If you're
interested in git, you might find bup interesting because:
- It can handle really massive datasets (hundreds of gigabytes)
without melting down.
- It can handle huge individual files (hundreds of gigabytes), such as
virtual machine images or giant textual database dumps, while neither
wasting disk space nor bogging down in xdelta.
- It can backup files directly to a remote server, without creating
git objects on the local system first.
- It uses a different format for its index file (.bup/bupindex) that
allows you to search and iterate non-linearly. Thus if you have a
filesystem with a million files and only one of them is marked dirty,
bup can back it up near-instantly.
- Like git, it separates the concept of indexing the filesystem from
the concept of actually making new commits. Thus it would be easy to
plugin an inotify-like system eventually, avoiding the slow filesystem
iteration every time you want to make a backup.
- It introduces a "multi-index" file (midx) that has a sorted list of
the objects from multiple .pack files, so that checking for a
nonexistent object only needs to swap in two pages at most. (This is
unimportant in git, but critical when most of your work is ingesting
huge files whose sha1sums haven't been seen before.)
- It provides a FUSE-based filesystem so that you can easily browse
your backup history, including exporting it via samba if you want.
bup doesn't yet back up extra file metadata (beyond what git already
tracks). Obviously this will be needed relatively soon.
bup is still pretty experimental, but it's already a useful tool for
backing up your files, even if those files include millions of files
and hundreds of gigs of VM images.
You can find the source code (and README) at github:
http://github.com/apenwarr/bup
To subscribe to the bup mailing list, send an email to:
bup-list+subscribe@googlegroups.com
Looking forward to everyone's feedback.
Have fun,
Avery
^ permalink raw reply
* Re: t5401-update-hooks test failure
From: Junio C Hamano @ 2010-02-09 22:44 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nicolas Pitre, Larry D'Anna, Jeff King, git
In-Reply-To: <20100209192628.GC28936@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> The only way I can see this missing message happening is if the C
> library isn't flushing the stdio buffer before the hook process
> exits. Given that the hook process is a /bin/sh shell script,
> and its using echo to print its messages... I'm at a loss for how
> to fix that in Git.
>
> Unless its the recv_sideband() somehow skipping a line. But I
> can't see it doing that.
The detection method of test is fooled by intermixed message.
This is what send.err has, and you grep for '^remote:' in it.
-- >8 --
warning: updating the current branch
warning: Updating the currently cheremote: STDERR pre-receive
,
warning: as the index and work tree do not reflect changes that are in HEAD.
warning: As a result, you may see the changes you just pushed into it
warning: reverted when you run 'git diff' over there, and you may want
warning: to run 'git reset --hard' before starting to work to recover.
warning:
warning: You can set 'receive.denyCurrentBranch' configuration variable to
warning: 'refuse' in the remote repository to forbid pushing into its
warning: current branch.
warning: To allow pushing into the current branch, you can set it to 'ignore';
warning: but this is not recommended unless you arranged to update its work
warning: tree to match what you pushed in some other way.
warning:
warning: To squelch this message, you can set it to 'warn'.
warning:
warning: Note that the default will change in a future version of git
warning: to refuse updating the current branch unless you have the
warning: configuration variable set to either 'ignore' or 'warn'.
remote: STDOUT update refs/heads/master
remote: STDERR update refs/heads/master
remote: STDOUT update refs/heads/tofail
remote: STDERR update refs/heads/tofail
error: hook declined to update refs/heads/tofail
remote: STDOUT post-receive
remote: STDERR post-receive
remote: STDOUT post-update
remote: STDERR post-update
To ./victim/.git
d4f8e4a..b07e5b8 master -> master
! [remote rejected] tofail -> tofail (hook declined)
-- 8< --
But there indeed _is_ some skipping. "Updating the currently che"
is interrupted by the output from the pre-receive hook, and I do not see
the remainder "cked out branch may cause confusion,\n" anywhere.
^ permalink raw reply
* [PATCH 3/3] t2200-add-update.sh: change expected fail to success
From: Chris Packham @ 2010-02-09 22:30 UTC (permalink / raw)
To: git; +Cc: peff, szeder, gitster
In-Reply-To: <1265754650-25438-3-git-send-email-judge.packham@gmail.com>
This changes the test added in bb73e5c to an expected success now that
Junio has supplied a fix.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
t/t2200-add-update.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t2200-add-update.sh b/t/t2200-add-update.sh
index dbabc3c..6302137 100755
--- a/t/t2200-add-update.sh
+++ b/t/t2200-add-update.sh
@@ -176,7 +176,7 @@ test_expect_success 'add -u resolves unmerged paths' '
'
-test_expect_failure 'error out when attempting to add -u non-existent pathspec' '
+test_expect_success 'error out when attempting to add -u non-existent pathspec' '
test_must_fail git add -u non-existent &&
! (git ls-files | grep "non-existent")
'
--
1.6.4.2
^ permalink raw reply related
* Re: git add -u nonexistent-file
From: Chris Packham @ 2010-02-09 22:30 UTC (permalink / raw)
To: git; +Cc: peff, szeder, gitster
In-Reply-To: <a038bef51002091417o1048c098x898517596115ed90@mail.gmail.com>
Heres the up to date series with Junios fix and my test. The two test patches
could be squashed together if we want to change the order.
^ permalink raw reply
* [PATCH 2/3] git add -u: give an error if pathspec unmatched
From: Chris Packham @ 2010-02-09 22:30 UTC (permalink / raw)
To: git; +Cc: peff, szeder, gitster
In-Reply-To: <1265754650-25438-2-git-send-email-judge.packham@gmail.com>
From: Junio C Hamano <gitster@pobox.com>
If a pathspec is supplied to 'git add -u' and no matching path is
matched, fail with an approriate error message and exit code.
Tested-by: Chris Packham <judge.packham@gmail.com>
---
builtin-add.c | 38 +++++++++++++++++++++++++++++---------
1 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 2705f8d..87d2980 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -117,7 +117,19 @@ static void fill_pathspec_matches(const char **pathspec, char *seen, int specs)
}
}
-static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
+static char *find_used_pathspec(const char **pathspec)
+{
+ char *seen;
+ int i;
+
+ for (i = 0; pathspec[i]; i++)
+ ; /* just counting */
+ seen = xcalloc(i, 1);
+ fill_pathspec_matches(pathspec, seen, i);
+ return seen;
+}
+
+static char *prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
{
char *seen;
int i, specs;
@@ -137,13 +149,7 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
}
dir->nr = dst - dir->entries;
fill_pathspec_matches(pathspec, seen, specs);
-
- for (i = 0; i < specs; i++) {
- if (!seen[i] && pathspec[i][0] && !file_exists(pathspec[i]))
- die("pathspec '%s' did not match any files",
- pathspec[i]);
- }
- free(seen);
+ return seen;
}
static void treat_gitlinks(const char **pathspec)
@@ -359,6 +365,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
int flags;
int add_new_files;
int require_pathspec;
+ char *seen = NULL;
git_config(add_config, NULL);
@@ -418,7 +425,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
/* This picks up the paths that are not tracked */
baselen = fill_directory(&dir, pathspec);
if (pathspec)
- prune_directory(&dir, pathspec, baselen);
+ seen = prune_directory(&dir, pathspec, baselen);
}
if (refresh_only) {
@@ -426,6 +433,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)
goto finish;
}
+ if (pathspec) {
+ int i;
+ if (!seen)
+ seen = find_used_pathspec(pathspec);
+ for (i = 0; pathspec[i]; i++) {
+ if (!seen[i] && pathspec[i][0]
+ && !file_exists(pathspec[i]))
+ die("pathspec '%s' did not match any files",
+ pathspec[i]);
+ }
+ free(seen);
+ }
+
exit_status |= add_files_to_cache(prefix, pathspec, flags);
if (add_new_files)
--
1.6.4.2
^ permalink raw reply related
* [PATCH 1/3] test for add with non-existent pathspec
From: Chris Packham @ 2010-02-09 22:30 UTC (permalink / raw)
To: git; +Cc: peff, szeder, gitster
In-Reply-To: <1265754650-25438-1-git-send-email-judge.packham@gmail.com>
Add a test for 'git add -u pathspec' and 'git add pathspec' where
pathspec does not exist. The expected result is that git add exits with
an error message and an appropriate exit code.
This adds 1 expected failure to t/t2200-add-update.sh.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
t/t2200-add-update.sh | 5 +++++
t/t3700-add.sh | 5 +++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/t/t2200-add-update.sh b/t/t2200-add-update.sh
index 9120750..dbabc3c 100755
--- a/t/t2200-add-update.sh
+++ b/t/t2200-add-update.sh
@@ -176,4 +176,9 @@ test_expect_success 'add -u resolves unmerged paths' '
'
+test_expect_failure 'error out when attempting to add -u non-existent pathspec' '
+ test_must_fail git add -u non-existent &&
+ ! (git ls-files | grep "non-existent")
+'
+
test_done
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index 85eb0fb..c77bb71 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -255,4 +255,9 @@ test_expect_success 'git add to resolve conflicts on otherwise ignored path' '
git add track-this
'
+test_expect_success 'error out when attempting to add non-existent pathspec' '
+ test_must_fail git add non-existent &&
+ ! (git ls-files | grep "non-existent")
+'
+
test_done
--
1.6.4.2
^ permalink raw reply related
* Re: [PATCH v3 3/3] git-push: make git push --dry-run --porcelain exit with status 0 even if updates will be rejected
From: Junio C Hamano @ 2010-02-09 22:25 UTC (permalink / raw)
To: Larry D'Anna; +Cc: git
In-Reply-To: <032264a40d15cb9f4a86885947ffa23a603bfb0e.1265661033.git.larry@elder-gods.org>
Larry D'Anna <larry@elder-gods.org> writes:
> @@ -1052,7 +1053,7 @@ int transport_push(struct transport *transport,
> flags & TRANSPORT_PUSH_FORCE);
>
> ret = transport->push_refs(transport, remote_refs, flags);
> - err = push_had_errors(remote_refs);
> + err = (pretend && porcelain) ? 0 : push_had_errors(remote_refs);
Hmph, you are doing (rewritten in an easier to follow format)
if (--dry-run && --porcelain)
err = 0;
else
err = push_add_errors(remote_refs);
here, which I think changes the semantics of what follows immediately
after this hunk, namely:
if (!quiet || err)
print_push_status(transport->url, remote_refs,
verbose | porcelain, porcelain,
nonfastforward);
Earlier, the logic said "even if you asked for --quiet, we would report if
there is an error" but now you are changing the rule to "under --dry-run
and --porcelain, --quiet means don't ever report the status, even when
there are errors".
I don't necessarily think it is a bad change, but in any case the semantic
change is worth documenting.
^ permalink raw reply
* Re: [RFC PATCHv2 09/10] gitweb/cache.pm - Regenerate (refresh) cache in background
From: Jakub Narebski @ 2010-02-09 22:23 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Petr Baudis
In-Reply-To: <1265711427-15193-10-git-send-email-jnareb@gmail.com>
On Tue, 9 Feb 2010, Jakub Narebski wrote:
[...]
> + my $pid = fork() if ($data && $self->get_background_cache());
> + if (!defined $pid || $pid) {
> + # parent, or didn't fork
> + $data = $p_coderef->($self, $p_key);
> + $self->set($p_key, $data);
> +
> + if ($pid) {
> + # releases lock before waiting and exiting
> + close $lock_fh;
> + # wait for child (which would print) and exit
> + waitpid $pid, 0;
> + exit 0;
> + }
> + } else {
> + # child is to serve stale data
> + return $data;
> + }
[...]
I have decide to rely on $SIG{CHLD} = 'IGNORE' to not generate zombies,
and consistently exit in child (in forked process) and return in parent.
This change would be in next version of this series.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git add -u nonexistent-file
From: Chris Packham @ 2010-02-09 22:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, SZEDER Gábor, git
In-Reply-To: <7v7hqm2hs7.fsf@alter.siamese.dyndns.org>
On Tue, Feb 9, 2010 at 4:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> It won't be entirely trivial to do so efficiently but it shouldn't be a
> rocket surgery.
>
> Something like this (untested of course)?
>
Passes my new test and all the rest in t2200-add-update.sh and t3700-add.sh.
Hows this for a commit message:
git add -u: give an error if pathspec unmatched
If a pathspec is supplied to 'git add -u' and no matching path is
matched, fail with an approriate error message and exit code.
^ permalink raw reply
* Re: [PATCH] Add a test for a problem in "rebase --whitespace=fix"
From: Junio C Hamano @ 2010-02-09 21:58 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git
In-Reply-To: <6672d0161002072337r2ad002adq69f4c686da8cdf09@mail.gmail.com>
Björn Gustavsson <bgustavsson@gmail.com> writes:
> I see at least two possible ways to implement that:
>
> 1. Have "git rebase" give "git apply" a special option so that it
> will apply patches beyond the end of file (and trusting the
> line numbers in the chunks).
>
> 2. Having "git rebase" remember the number of blanks line that
> was removed in each previous file in previous fixed commits
> and add them back just before invoking "git apply".
I actually changed my mind after thinking about it a bit more.
I think you should be able to do the same thing as we already do in
git-apply inside match_fragment(), and without involving any "rebase"
specific hacks nor options, the result will cover most of the real-life
use cases.
The existing logic in the function says "We were told to find a location
in the img (i.e. the text being patched) where preimage appears. We will
replace the copy of the preimage in img with the corresponding postimage.
Unfortunately, the preimage does not exactly match, but if we consider
that we may have applied earlier patches with whitespace=fix, we can see
that the given preimage matches with this location in our img except for
whitespace differences."
When it finds the place that "fuzzily" matches the preimage, it adjusts
the given preimage to match what we have (i.e. pretends that the patch
sender sent a patch based on a version of the text with whitespace fixes
we made in ours already applied), and then let the common logic replace
that copy of preimage with postimage in img.
The hunk is applied successfully, and we are happy.
Using the same logic, your "a/b/c trail" -> "a/b/c gap d/e/f" example
would work like this.
After applying the first patch with blank-at-eof, we will have "a/b/c" (no
trailing blanks) in img.
The second patch comes. It looks like this:
@@ -l,3 +k,6 @@
b
c
+d
+e
+f
This tells you to match "'b c blank' at the end" (lack of trailing context
would trigger match_end hint, I think). So you go ahead and look at your
img, which is "a/b/c" (no trailing blanks). It does not match.
Just like existing logic in match_fragment() knows that the img might have
undergone whitespace fixes, your new logic would realize that with an
addition of one empty line to make your img "a/b/c blank", the preimage of
this hunk matches the way as you are told to search.
At that point, you adjust the preimage to match what we have (the logic is
exactly the same as blank-at-eol case---adjust the patch to pretend that
they started with a whitespace-corrected version we have). This would
make the hunk look like this:
@@ -l,2 +k,6 @@
b
c
+
+d
+e
+f
and by applying that adjusted hunk, you will get the expected result,
namely, "a/b/c gap d/e/f".
Notice that we did all that without ever looking at 'l' and 'k' (hunk
offsets)?
I'd like to see this logic (and only this logic, without relying on the
diff hunk offset numbers at all) done first, because it is very much in
line with what we already do, and more importantly, because it is a more
general solution that is applicable outside the context of rebase.
This of course will not catch the case where you used to have added tons
of blanks at the end in the earlier patch (and losing sight of how many
blanks you removed while applying it). You would need to build a special
case that probably relies on the diff hunk offset, and trigger that
additional logic in rebase (i.e. the caller that _knows_ the hunk offsets
are reliable). That special case may not involve a change to "git apply"
at all, as you suggested as an alternative (2), as you can do that all
inside "git rebase". But I'd rather like to see a solution that does not
rely on the special case as one patch that is independent from rebase, and
the special case built on top of it, as a separate patch.
After all, if you _are_ applying with whitespace=fix and blank-at-eof is
in effect, it is very likely that the nature of the contents in that path
is something that blank lines in the middle does not matter except for
readability (e.g. something like .git/config file format); the fact that
it is safe to strip the blank-at-eof strongly suggests that blanks do not
have semantic meaning and are there purely for readability. In contents
of such a nature, it would not matter if you lost indeterminate number of
blank lines in the middle by applying two patches, the first one leaving
100 blank lines at the end and then the second one adding some non-blank
lines at the end. It might even turn out to be a moot point to worry
about the special case hack if that is the case.
^ permalink raw reply
* Re: git add -u nonexistent-file
From: Junio C Hamano @ 2010-02-09 21:58 UTC (permalink / raw)
To: Jeff King; +Cc: Chris Packham, SZEDER Gábor, git
In-Reply-To: <20100209003958.GA4065@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It's not ignoring the extra parameters. They limit the scope of the
> operation. So:
>
> $ git init
> $ touch file && mkdir subdir && touch subdir/file
> $ git add . && git commit -m one
> $ echo changes >file && echo changes >subdir/file
> $ git add -u subdir
> $ git status
> # On branch master
> # Changes to be committed:
> # modified: subdir/file
> #
> # Changed but not updated:
> # modified: file
> #
>
> That being said, you noticed that the regular add case notes unused
> pathspecs on the command line:
>
> $ git add bogus
> fatal: pathspec 'bogus' did not match any files
>
> We could probably do the same here.
It won't be entirely trivial to do so efficiently but it shouldn't be a
rocket surgery.
Something like this (untested of course)?
builtin-add.c | 38 +++++++++++++++++++++++++++++---------
1 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 2705f8d..87d2980 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -117,7 +117,19 @@ static void fill_pathspec_matches(const char **pathspec, char *seen, int specs)
}
}
-static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
+static char *find_used_pathspec(const char **pathspec)
+{
+ char *seen;
+ int i;
+
+ for (i = 0; pathspec[i]; i++)
+ ; /* just counting */
+ seen = xcalloc(i, 1);
+ fill_pathspec_matches(pathspec, seen, i);
+ return seen;
+}
+
+static char *prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
{
char *seen;
int i, specs;
@@ -137,13 +149,7 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
}
dir->nr = dst - dir->entries;
fill_pathspec_matches(pathspec, seen, specs);
-
- for (i = 0; i < specs; i++) {
- if (!seen[i] && pathspec[i][0] && !file_exists(pathspec[i]))
- die("pathspec '%s' did not match any files",
- pathspec[i]);
- }
- free(seen);
+ return seen;
}
static void treat_gitlinks(const char **pathspec)
@@ -359,6 +365,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
int flags;
int add_new_files;
int require_pathspec;
+ char *seen = NULL;
git_config(add_config, NULL);
@@ -418,7 +425,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
/* This picks up the paths that are not tracked */
baselen = fill_directory(&dir, pathspec);
if (pathspec)
- prune_directory(&dir, pathspec, baselen);
+ seen = prune_directory(&dir, pathspec, baselen);
}
if (refresh_only) {
@@ -426,6 +433,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)
goto finish;
}
+ if (pathspec) {
+ int i;
+ if (!seen)
+ seen = find_used_pathspec(pathspec);
+ for (i = 0; pathspec[i]; i++) {
+ if (!seen[i] && pathspec[i][0]
+ && !file_exists(pathspec[i]))
+ die("pathspec '%s' did not match any files",
+ pathspec[i]);
+ }
+ free(seen);
+ }
+
exit_status |= add_files_to_cache(prefix, pathspec, flags);
if (add_new_files)
^ permalink raw reply related
* git-svn: Cannot lock the ref 'refs/remotes/tags/autotag_for_.'.
From: Tzafrir Cohen @ 2010-02-09 21:39 UTC (permalink / raw)
To: git
Hi
I'm using git-svn for watching over SVN repositories in
svn.asterisk.org . The largest one there is
http://svn.asterisk.org/svn/asterisk .
This worked fine up until recently. I was using Debian Stable with Git
1.5.6 .
Recently I upgraded my system to Debian Testing with Git 1.6 (I
currently have 1.6.6.1-1). Today I tried to update the repository (git
svn rebase --fetch-all) and got the following error:
fatal: Cannot lock the ref 'refs/remotes/tags/autotag_for_.'.
IIRC it followed an automatic garbage-collection in the repository.
I decided to re-clone the SVN repository (I was planning on doing that
for quite some time, with a proper AUTHORS file this time. But it's a
repo of some 200,000 revisions and takes a few days to clone)
I eventually got the same error.
The specific revision that triggered it:
http://svnview.digium.com/svn/asterisk?view=revision&revision=47394
Should git-svn mangle SVN tag names to be legal git ref names? Or just
panic before it makes the git repo invalid?
Is there a way for me to skip some tags? I can avoid that specific tag.
Please CC your replies to me as I don't actively follow this list.
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.cohen@xorcom.com
+972-50-7952406 mailto:tzafrir.cohen@xorcom.com
http://www.xorcom.com iax:guest@local.xorcom.com/tzafrir
^ permalink raw reply
* Re: [RFD] Notes are independent: proposal for new notes implementation
From: Avery Pennarun @ 2010-02-09 21:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Johan Herland, Junio C Hamano, Jon Seymour
In-Reply-To: <201002092155.29304.jnareb@gmail.com>
On Tue, Feb 9, 2010 at 3:55 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 9 Feb 2010, Avery Pennarun wrote:
>> 2010/2/9 Jakub Narebski <jnareb@gmail.com>:
>> > But
>> > what if the answer was to change implementation, decoupling history of
>> > notes from each other, and keeping history of each note separate.
>>
>> Congratulations, you've re-invented CVS! :)
>>
>> Seriously though, I'm not sure what problems this solved. Notes that
>> are related to each other can (and perhaps should) be in the same
>> notes commit history; notes that are not related to each other can
>> exist in separate histories with their own ref.
>
> The problem is (as I see it) that notes are _not_ (in almost all cases)
> related to each other, just like files in $HOME or in /etc are not
> related to each other.
As a side note, I didn't find this example compelling at all. I
*absolutely* want to manage all my files in /etc as a single repo.
"The configuration of my computer" is an ongoing project where the
configuration of my smtp daemon depends on /etc/hosts and /etc/passwd
and /etc/group. If I set up another server, I want to be able to fork
my basic configuration and apply some patches. If I set up some
clever aliases in /etc/profile, I want to send that patch "upstream"
to the /etc project on my other servers.
Similarly with $HOME; the evolution of my home directory over time is
a thing I can talk about as a sensible whole, and of course I want
rename tracking and deltas and so on.
Combining /etc and $HOME into a single repo would be harder to
justify. But that sounds to me like the "kind (flavor)" distinction
you're talking about; system config files and personal files are two
different kinds of files.
>> > This means for example that if in repository A somebody annotated
>> > commits foo and bar creating notes in this order, and in repository B
>> > somebody annotated bar and foo (creating notes in reverse order), then
>> > merging those changes would require generating merge commit even if
>> > those notes are identical.
>>
>> That's a feature; now you have the true history of your notes, which
>> is good for all the same reasons it's good in git.
>
> No, you are introducing artificial ordering in something that is a bag,
> unordered collection.
I would put it another way: you're recording the true ordering of
something where the ordering *may* not be important. It is easy to
ignore that ordering.
However, it's very hard to unignore ordering that you didn't record in
the first place. That's why CVS's model of recording
one-history-per-file is so nasty. Yet it seemed so clever when they
invented it.
What is a real use case where the "artificial ordering" causes a problem?
Here's a use case where having a single history would be a clear
benefit: say you're running an autobuilder such as gitbuilder[1].
Something goes wrong with your autobuild environment, like the disk
fills up, and all the build results since yesterday at noon are
invalid. If the build results are stored as a single history of git
notes[2], I can just rewind the history to yesterday at noon and
discard the entire sequence of bad results across all commits. If
they each had their own history, it would be more complex to
implement.
Have fun,
Avery
[1] http://github.com/apenwarr/gitbuilder
[2] gitbuilder doesn't currently use git-notes, it just uses plain files.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox