* idea: git "came from" tags
From: D Herring @ 2010-01-18 4:22 UTC (permalink / raw)
To: git
Actors:
- public "upstream" repository
- public "local" repository
- end users tracking both
Situation:
- local starts by tracking upstream
- local makes changes, commits, and sends upstream
- users now tracking local ahead of upstream
- upstream makes modified commits
- local satisfied, wants to reset master to upstream/master
Problem:
- A merge will perpetually leave two parallel branches. Even though
there are no longer any diffs, local/master cannot use the same
objects as upstream/master.
- A hard reset lets local/master return to sharing objects with
upstream/master; but this may break pulls or cause other problems for
users.
Proposed solution:
- Local adds a "came from" tag to upstream/master, leaves a tag on the
head of local/master, and does a hard reset from local/master to
upstream/master. When a user tracking local/master does a pull, their
client detects a non-fast-forward, finds the came-from tag, and treats
it as a fast-forward.
Basically, this is a protocol to glue a "strategy ours" merge onto an
existing tree. This way local can cleanly track upstream, with no
added complexity in the nominal (no local changes) case.
Example:
Without this addition, local/master looks something like
u1 - u2 - u3 - u4 - u5 - u6 ...
\- l1 - l2\+ m1 - \+ m2\+ m3 ...
With this addition, local/master looks like
u1 - u2 - u3(tcf) - u4 - u5 - u6 ...
\- l1 - l2 - t0
where
* u# = upstream changes
* l# = local changes
* m# = local merges (m1=u3, m2=u5, m3=u6, ...)
* the tcf tag points to t0, and t0 tags the end of the local mods
Pseudo-shell-code addition to git-pull:
fetch local/master
fast_forward=usual test whether local/master contains user/master
if test $fast_forward = no
then
for tag in $fetched_tags # something like this or git-describe
do
if is_came_from($tag) && (came_from($tag) contains user/master)
then
fast_forward=yes
break
fi
done
fi
Comments? I think this is completely implementable (though I'm not
well-versed in git internals). Since it only triggers during
non-fast-forward operations, it should have negligible performance impact.
Of course, it would be even better if somebody shows me how to do this
with the current tools. Maybe I'm just doing it all wrong.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH] grep --no-index: allow use of "git grep" outside a git repository
From: Junio C Hamano @ 2010-01-18 4:02 UTC (permalink / raw)
To: Jeff King; +Cc: git, David Aguilar, Nanako Shiraishi
In-Reply-To: <7v8wbwultw.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> Agreed. That is the most common log grep pattern for me (author + grep),
>> and I always want all-match. I see from later in the thread, though,
>> that implementing it is not as straightforward as we might hope.
>
> I haven't looked at the codepath for quite some time but I have a feeling
> that it probably won't be too bad.
>
> It just won't be as simple as flipping the all_match bit with a one-liner.
Perhaps something like this.
-- >8 --
Subject: "log --author=me --grep=it" should find intersection, not union
Historically, any grep filter in "git log" family of commands were taken
as restricting to commits with any of the words in the commit log message.
However, the user almost always want to find commits "done by this person
on that topic". With "--all-match" option, a series of grep patterns can
be turned into a requirement that all of them must produce a match, but
that makes it impossible to ask for "done by me, on either this or that"
with:
log --author=me --grep=this --grep=that
because it will require both "this" and "that" to appear.
Change the "header" parser of grep library to treat the headers specially.
When parsing the above, behave as if it was specified like this on the
command line:
--all-match --author=me '(' --grep=this --grep=that ')'
Even though the "log" command line parser doesn't give direct access to
the extended grep syntax to group terms with parentheses, this change will
cover the majority of the case the users would want.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-grep.c | 1 +
grep.c | 20 ++++++++++++++++++--
grep.h | 2 ++
revision.c | 1 +
4 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 529461f..d57c4d9 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -820,6 +820,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
opt.relative = 1;
opt.pathname = 1;
opt.pattern_tail = &opt.pattern_list;
+ opt.header_tail = &opt.header_list;
opt.regflags = REG_NEWLINE;
opt.max_depth = -1;
diff --git a/grep.c b/grep.c
index bdadf2c..f51fa4a 100644
--- a/grep.c
+++ b/grep.c
@@ -11,8 +11,8 @@ void append_header_grep_pattern(struct grep_opt *opt, enum grep_header_field fie
p->no = 0;
p->token = GREP_PATTERN_HEAD;
p->field = field;
- *opt->pattern_tail = p;
- opt->pattern_tail = &p->next;
+ *opt->header_tail = p;
+ opt->header_tail = &p->next;
p->next = NULL;
}
@@ -173,6 +173,22 @@ void compile_grep_patterns(struct grep_opt *opt)
{
struct grep_pat *p;
+ if (opt->header_list && !opt->all_match) {
+ struct grep_pat *p = opt->pattern_list;
+ opt->pattern_list = opt->header_list;
+ opt->pattern_tail = opt->header_tail;
+ opt->header_list = NULL;
+ opt->header_tail = NULL;
+
+ append_grep_pattern(opt, "(", "internal", 0, GREP_OPEN_PAREN);
+ while (p) {
+ *opt->pattern_tail = p;
+ opt->pattern_tail = &p->next;
+ p = p->next;
+ }
+ append_grep_pattern(opt, ")", "internal", 0, GREP_CLOSE_PAREN);
+ opt->all_match = 1;
+ }
if (opt->all_match)
opt->extended = 1;
diff --git a/grep.h b/grep.h
index 75370f6..e39e514 100644
--- a/grep.h
+++ b/grep.h
@@ -59,6 +59,8 @@ struct grep_expr {
struct grep_opt {
struct grep_pat *pattern_list;
struct grep_pat **pattern_tail;
+ struct grep_pat *header_list;
+ struct grep_pat **header_tail;
struct grep_expr *pattern_expression;
const char *prefix;
int prefix_length;
diff --git a/revision.c b/revision.c
index 25fa14d..18a3658 100644
--- a/revision.c
+++ b/revision.c
@@ -806,6 +806,7 @@ void init_revisions(struct rev_info *revs, const char *prefix)
revs->grep_filter.status_only = 1;
revs->grep_filter.pattern_tail = &(revs->grep_filter.pattern_list);
+ revs->grep_filter.header_tail = &(revs->grep_filter.header_list);
revs->grep_filter.regflags = REG_NEWLINE;
diff_setup(&revs->diffopt);
^ permalink raw reply related
* Re: [PATCH 1/2] Add `init-db.templatedir` configuration variable.
From: Steven Drake @ 2010-01-18 3:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljg2pewo.fsf@alter.siamese.dyndns.org>
On Wed, 13 Jan 2010, Junio C Hamano wrote:
> Steven Drake <sdrake@xnet.co.nz> writes:
>
> > Include `init.templatedir` as an alias for `init-db.templatedir`.
>
> This describes what the patch adds, which we can read in the diff *if* we
> wanted to. The primary job of the first paragraph of the proposed commit
> log message is to convince reviewers why it might be worthwhile to read
> the diff, and to explain whoever reads "git log" output in the future what
> motivated this change to be made.
>
> Your log message doesn't say anything about why it is a good idea to add
> this feature, which is much more important to talk about [*1*].
>
> The target _may_ be probably to have this in $HOME/.gitconfig so that your
> personal templates in $HOME/.gittemplate/ are used in all repositories you
> will create. But you shouldn't make me, anybody who reviews, or readers
> of the documentation for that matter, *guess* what problem the new feature
> is meant to solve.
>
> IOW, code talks what it itself does, but it often cannot say why it does
> what it does, nor why a particular way it does what it does was chosen.
> You help your code justify itself by describing the motivation in your
> commit log message.
Thanks for the advise if you cann't tell I'm used to writing spares message
both in log messages and email, so this is a great help as to what to
write. I'll resubmit some improved patches with better log messages.
On that subject do you prefer resubmits as replies to the originals or new
email?
Do you accept email that use inbodyr-headers and/or scissors?
--
Steven
"won't be big"
-- Linus Torvalds, 25 Aug 1991 - in his first post about linux.
^ permalink raw reply
* Re: [PATCH] grep --no-index: allow use of "git grep" outside a git repository
From: Junio C Hamano @ 2010-01-18 3:35 UTC (permalink / raw)
To: Jeff King; +Cc: git, Nanako Shiraishi
In-Reply-To: <20100118015140.GB6831@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Agreed. That is the most common log grep pattern for me (author + grep),
> and I always want all-match. I see from later in the thread, though,
> that implementing it is not as straightforward as we might hope.
I haven't looked at the codepath for quite some time but I have a feeling
that it probably won't be too bad.
It just won't be as simple as flipping the all_match bit with a one-liner.
Before calling compile_grep_patterns() in revision.c::setup_revisions(),
we probably would want to massage revs->grep_filter to result in the
desired grep expression parse tree, i.e. from
GREP_PATTERN_HEAD("^author .*davvid")
GREP_PATTERN_HEAD("^committer .*gitster")
GREP_PATTERN_BODY("difftool")
GREP_PATTERN_BODY("mergetool")
to
GREP_PATTERN_HEAD("^author .*davvid")
GREP_PATTERN_HEAD("^committer .*gitster")
GREP_NODE_OR(
GREP_PATTERN_BODY("difftool")
GREP_PATTERN_BODY("mergetool")
)
^ permalink raw reply
* Re: [PATCH] commit: match explicit-ident semantics for summary and template
From: Junio C Hamano @ 2010-01-18 3:34 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, git
In-Reply-To: <20100118014735.GA6831@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Jan 17, 2010 at 02:03:48PM -0800, Junio C Hamano wrote:
>
>> We could say something like
>>
>> if (!(user_ident_explicitly_given & IDENT_EMAIL_GIVEN))
>>
>> and it probably is a safer change on platforms with GECOS available, but
>> then wouldn't msysgit folks have to fork this code?
>
> I hadn't thought to be specific to "email must be given". That is, I had
> assumed if you gave a name but not email, you would also be considered
> competent enough to avoid the warning. But I really can't see anybody
> doing that, so the semantics you suggest above are fine by me.
It is fine if we keep insisting on getting both explicitly, but as you
said, I think if we have an explicit user.email, it is much more likely
that the user are happy with what we get from the GECOS than the user is
unhappy with GECOS but hasn't learnt user.name configuration.
Also if you have neither user.name nor user.email on your fresh box, the
chance that GECOS gives us the name you desire is much much more likely
than the chance the output from `whoami`@`hostname -f` happens to match
your desired e-mail identity. I think checking MAIL only would probably
be the best heuristics.
^ permalink raw reply
* Re: [PATCH v4] Add push --set-upstream
From: Miles Bader @ 2010-01-18 3:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ilari Liusvaara, git
In-Reply-To: <7vwrzgweht.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Looks good; thanks. Will queue on 'next'.
Excellent! Can't wait to see it in a release someday...
Thanks, Ilari et al!!
-miles
--
Neighbor, n. One whom we are commanded to love as ourselves, and who does all
he knows how to make us disobedient.
^ permalink raw reply
* Re: [PATCH/RFC] Allow empty commits during rebase -i
From: Junio C Hamano @ 2010-01-18 3:11 UTC (permalink / raw)
To: Pete Harlan; +Cc: Johannes Schindelin, git list, Michael Haggerty
In-Reply-To: <4B53C355.1010109@pcharlan.com>
Pete Harlan <pgit@pcharlan.com> writes:
> ..., "git rebase --continue" does exactly what I would have
> wanted to happen, including putting me in an editor with all three
> commit messages and succeeding when I exit the editor. But without a
> better message from git I don't expect a user to discover that.
There seems to be an idea for a good improvement ;-) CC'ing Michael as he
has been most active in this area for the past few weeks.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #05; Sat, 16)
From: Jakub Narebski @ 2010-01-18 3:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljfxa1o6.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * jh/gitweb-cached (2010-01-13) 9 commits
Those two I think are not close to be ready
> - gitweb: File based caching layer (from git.kernel.org)
Large code dump. I am working (slowly) on splitting it.
> - gitweb: Convert output to using indirect file handle
Does not need two file handles. Style should probably be "print $out <sth>"
Thos could probably be merged soon (after final round of corrections)
> - gitweb: cleanup error message produced by undefined $site_header
It's not only $site_header
> - gitweb: add a get function to compliment print_sort_th
> - gitweb: add a get function to compliment print_local_time
O.K.
> - gitweb: Makefile improvements
I think it is O.K.
> - gitweb: Add option to force version match
Allow for version mismatch in test, add test for version match
> - gitweb: change die_error to take "extra" argument for extended die information
Minor fixup (commit message, whitespace). Otherwise O.K.
> - gitweb: Load checking
O.K., but needs a fixup to 'blame_incremental' related code. Some
assumptions can hold no longer
>
> Replaced with a re-roll. Update to t9500 is probably needed.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git status: display current branch name in color
From: Jeff King @ 2010-01-18 2:32 UTC (permalink / raw)
To: Michael Wookey; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <d2e97e801001162031n1dab2301k5a839846b3cc5d9d@mail.gmail.com>
On Sun, Jan 17, 2010 at 03:31:07PM +1100, Michael Wookey wrote:
> > There is an existing highlight when the user is not on any branch.
> > Enhance this functionality to always provide the name of the current
> > branch in color.
> >
> > Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
> > ---
> > wt-status.c | 10 ++++++----
> > wt-status.h | 3 ++-
> > 2 files changed, 8 insertions(+), 5 deletions(-)
>
> Any thoughts on this?
I don't have an objection to the concept, but for it to be acceptable
for inclusion in mainstream git, the color selection needs to be
configurable (see builtin-commit.c:parse_status_slot) and documented
(see Documentation/config.txt, color.status.<slot>).
And then we can decide what the _default_ color should be. Personally, I
find it a bit distracting to change the color for something so mundane,
and would be in favor of leaving it the same as the header color. But I
will not argue too hard either way; I have no problem with setting my
own config to make it invisible if others disagree. :)
-Peff
^ permalink raw reply
* Re: git rm --cached and pull semantics
From: list @ 2010-01-18 2:31 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <86my0c5l9s.fsf@blue.stonehenge.com>
On 01/18/2010 01:06 AM, Randal L. Schwartz wrote:
> The real WTF here is that you are using a workdir as your live dir.
>
> If you treat git as a *source* manager like it is, you'd also have an
> installer that would copy the resulting files into their live locations,
> and could be edited to either leave that newly untracked file alone,
> or deliberately remove it.
>
> Use git as intended, and you get no problems.
>
>
Hm. Good point. I'll try to put that into some post-pull hook and see
how it works out. Thanks for the help.
^ permalink raw reply
* Re: [PATCH/RFC] Allow empty commits during rebase -i
From: Pete Harlan @ 2010-01-18 2:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git list
In-Reply-To: <7vljfww686.fsf@alter.siamese.dyndns.org>
On 01/17/2010 05:29 PM, Junio C Hamano wrote:
> Pete Harlan <pgit@pcharlan.com> writes:
>
>> I imagine an ideal version of this fix would make it so the use case I
>> presented here would work, but rebase -i would still prevent
>> introducing a new empty commit, or at least warn when it was
>> introducing one. In the absence of that ideal fix, I think this
>> behavior is better than failing to handle this case.
>
> Sorry, I actually tend to think that in the absense of that fix, your
> version introduces risky behaviour that only a corner-case use case
> benefits, and pros-and-cons doesn't look attractive enough.
>
> Why not do something like:
>
> pick X a crap tree with a good message
> pick Y revert X
> pick Z a good tree with a crap message
>
> -->
>
> # drop X
> # drop Y
> edit Z
>
> and then run "git commit --amend -C X" when it is Z's turn to be
> processed?
That is another way to accomplish the same thing, but doesn't prevent
the current behavior from being confusing.
Part of the problem is that with the current behavior the user is sent
to the command line with:
# Not currently on any branch.
nothing to commit (working directory clean)
Could not apply a0b17c5... Revert "Crap tree good message"
with HEAD pointed to X^. Unsure of how to proceed from here, I
--aborted the rebase and copy/pasted the commit message I wanted and
resolved to track this down and fix it when I got a chance.
As it happens, "git rebase --continue" does exactly what I would have
wanted to happen, including putting me in an editor with all three
commit messages and succeeding when I exit the editor. But without a
better message from git I don't expect a user to discover that. And,
when rebase can continue just by being told so it would be nice if it
didn't require that user intervention.
If the introduction of empty commits that the user has asked for
(perhaps inadvertently) is considered too undesirable, then perhaps my
fix is too simple. I'll think about how to do something more
sophisticated.
Thanks for your feedback,
--Pete
^ permalink raw reply
* Re: git clone against firewall
From: Sebastian Pipping @ 2010-01-18 2:04 UTC (permalink / raw)
To: Andreas Krey; +Cc: Andreas Schwab, Junio C Hamano, git
In-Reply-To: <20100115230357.GA10163@inner.home.ulmdo.de>
On 01/16/10 00:03, Andreas Krey wrote:
> It does. After the usual network timeout, which unfortunately is
> a few minutes, and thus not really useful for trying several
> machines:
I would like to a ask for a timeout-after-n-seconds option then.
Thanks in advance!
Sebastian
^ permalink raw reply
* Re: [PATCH] grep --no-index: allow use of "git grep" outside a git repository
From: Jeff King @ 2010-01-18 1:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nanako Shiraishi
In-Reply-To: <7vpr5ait1m.fsf@alter.siamese.dyndns.org>
On Fri, Jan 15, 2010 at 08:15:49PM -0800, Junio C Hamano wrote:
> Realistically, this most often is used when grepping in the log, e.g.
>
> git log --all-match --author=peff --grep=test
>
> I actually wish "log" to somehow default to --all-match mode at least when
> using the --author option. "Change by Jeff, or about test by anybody" is
> rarely what I would want to look for.
Agreed. That is the most common log grep pattern for me (author + grep),
and I always want all-match. I see from later in the thread, though,
that implementing it is not as straightforward as we might hope.
I would personally be fine with "--all-match" being the default, but
that may be too big a change in behavior for some people to swallow (I
would also be fine with log.allmatch in the config, but every time I
suggest something like that people's heads explode and I get told to
make an alias).
-Peff
^ permalink raw reply
* Re: [PATCH] commit: match explicit-ident semantics for summary and template
From: Jeff King @ 2010-01-18 1:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7viqb0xubf.fsf@alter.siamese.dyndns.org>
On Sun, Jan 17, 2010 at 02:03:48PM -0800, Junio C Hamano wrote:
> We could say something like
>
> if (!(user_ident_explicitly_given & IDENT_EMAIL_GIVEN))
>
> and it probably is a safer change on platforms with GECOS available, but
> then wouldn't msysgit folks have to fork this code?
I hadn't thought to be specific to "email must be given". That is, I had
assumed if you gave a name but not email, you would also be considered
competent enough to avoid the warning. But I really can't see anybody
doing that, so the semantics you suggest above are fine by me.
As far as Windows goes, I have no opinion on the correct behavior. But
if they are going to do something different, your encapsulation makes
sense to me.
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] Allow empty commits during rebase -i
From: Junio C Hamano @ 2010-01-18 1:29 UTC (permalink / raw)
To: Pete Harlan; +Cc: Johannes Schindelin, git list
In-Reply-To: <4B53B561.0@pcharlan.com>
Pete Harlan <pgit@pcharlan.com> writes:
> I imagine an ideal version of this fix would make it so the use case I
> presented here would work, but rebase -i would still prevent
> introducing a new empty commit, or at least warn when it was
> introducing one. In the absence of that ideal fix, I think this
> behavior is better than failing to handle this case.
Sorry, I actually tend to think that in the absense of that fix, your
version introduces risky behaviour that only a corner-case use case
benefits, and pros-and-cons doesn't look attractive enough.
Why not do something like:
pick X a crap tree with a good message
pick Y revert X
pick Z a good tree with a crap message
-->
# drop X
# drop Y
edit Z
and then run "git commit --amend -C X" when it is Z's turn to be
processed?
^ permalink raw reply
* Re: [PATCH v2 0/4] Documentation style fixes
From: Junio C Hamano @ 2010-01-18 1:18 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Jonathan Nieder
In-Reply-To: <7vfx6efox9.fsf@alter.siamese.dyndns.org>
I think we have given people enough time to comment, so I am going to
merge 0b444cd (Documentation: spell 'git cmd' without dash throughout,
2010-01-10) which was taken from the tip of your for-next branch and that
has been in 'pu' for the last week.
^ permalink raw reply
* [PATCH/RFC] Allow empty commits during rebase -i
From: Pete Harlan @ 2010-01-18 1:12 UTC (permalink / raw)
To: Johannes Schindelin, git list
If you squash two commits into a previous commit, where the first
squash reverts the previous commit and the second redoes the change
correctly, rebase -i would fail during the first squash because it
generates an empty commit. This patch allows the rebase to succeed.
This also introduces the possibility that you might accidentally
create an empty commit with a squash, but I expect that will happen
less often than the scenario this is intended to address.
Signed-off-by: Pete Harlan <pgit@pcharlan.com>
---
This arose for me recently; I used "git revert" to undo a commit
several changes back, and then reworked and committed anew. The first
commit that I was redoing had a thorough commit message, while my new
commit had a message like "do it right this time". I squashed the
three commits into one with rebase -i, but git choked on the
intermediate empty commit.
I could have simply removed the first two commits I was squashing (the
initial version and its revert), but then would have lost the
well-written commit message that went with the first version.
I imagine an ideal version of this fix would make it so the use case I
presented here would work, but rebase -i would still prevent
introducing a new empty commit, or at least warn when it was
introducing one. In the absence of that ideal fix, I think this
behavior is better than failing to handle this case.
git-rebase--interactive.sh | 2 +-
t/t3404-rebase-interactive.sh | 9 +++++++++
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 1560e84..81db5cf 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -403,7 +403,7 @@ do_next () {
GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
- $USE_OUTPUT git commit --no-verify \
+ $USE_OUTPUT git commit --no-verify --allow-empty \
$MSG_OPT "$EDIT_OR_FILE" || failed=t
fi
if test $failed = t
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 3a37793..5eb9f7e 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -484,4 +484,13 @@ test_expect_success 'reword' '
git show HEAD~2 | grep "C changed"
'
+test_expect_success 'squash including empty' '
+ test_commit Initial_emptysquash emptysquash abc &&
+ test_commit first_mod emptysquash abd &&
+ test_tick &&
+ git revert --no-edit HEAD &&
+ test_commit second_mod emptysquash abe &&
+ FAKE_LINES="1 squash 2 squash 3" git rebase -i Initial_emptysquash
+'
+
test_done
--
1.6.6.196.g1f735
^ permalink raw reply related
* Re: [RFC] Git Wiki Move
From: J.H. @ 2010-01-18 0:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.1001172357420.4985@pacific.mpi-cbg.de>
On 01/17/2010 03:06 PM, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 17 Jan 2010, Matthieu Moy wrote:
>
>> "J.H." <warthog19@eaglescrag.net> writes:
>>
>>> Quick update - I think I've got the vast majority of the obvious and
>>> simple to correct problems fixed at http://git.wiki.kernel.org anyone
>>> want to run through and see if there's anything else that would be
>>> considered a show stopper?
>>
>> The main page is locked, and there are some broken links formatting in
>> the News section: http://git.wiki.kernel.org/index.php/Main_Page#News
>> I'm user "Moy" there if you want to let me fix them.
>
> I think I managed to edit them.
You have to have a confirmed e-mail account to be able to edit anything,
the errors on why you can't edit are fairly straight forward.
>
>> You should set $wgLogo to some Git logo, among
>> http://git.or.cz/gitwiki/GitRelatedLogos
>
> Best would be the standard one: http://git.or.cz/git-logo.png but I would
> actually also like http://henrik.nyh.se/uploads/git-logo.png.
I'd leave that up to the greater community. The second one there would
fit better on the page honestly, but I don't want to go making a logo
decision for the entirety of the project.
>
>> You can also add a few links to the sidebar, by editting:
>> http://git.wiki.kernel.org/index.php/MediaWiki:Sidebar
>>
>> (it seems I don't have permission to do it myself).
>
> You need to be in the Sysop list to do so. Warthog, if you trust me :-)
> would you mind adding me to that group? You can do that by visiting
>
> http://git.wiki.kernel.org/index.php/Special:Userrights
>
> when you are a sysop.
Done.
>
>> I suggest taking the ones of the front-page:
>>
>> * Starting points
>> ** Installation|Installation
>> ** InterfacesFrontendsAndTools|Git Tools
>> ** GitDocumentation|Git Documentation
>> ** GitCommunity|Git Community Support
>> ** GitProjects|Projects using Git
>> ** GitFaq|FAQ
>> ** GitHosting|Git Hosting
>> ** GitLinks|Git Links
>> ** GitComparison|Git Compared
>
> Let's not forget
>
> * navigation
> ** mainpage|mainpage-description
> ** recentchanges-url|recentchanges
> ** randompage-url|randompage
> ** helppage|help
> * SEARCH
> * TOOLBOX
>
> BTW there is a file KHTMLFixes.css in the directory skins/monobook/ which
> makes the layout break with Chromium. Apparently, it is no longer needed
> by KHTML anyway. So could you please replace that file with an empty one,
> or comment out the offending part, like so:
>
> /* #column-content { margin-left: 0; } */
I'm not keen on making changes since that file is still coming from the
shipping version of mediawiki and I'm trying, quite a lot, to not run a
modified version of it. I've got enough troubles with the fact that
that one change would affect 22 wikis in a single go.
As bad as it is to say this, I'd rather wait for 1.16 to come out vs.
modify it in place. Mediawiki is claiming they are in continuous
integration development with quarterly releases but their last release
was June of 2009, so take that as you will.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: git rm --cached and pull semantics
From: Randal L. Schwartz @ 2010-01-18 0:06 UTC (permalink / raw)
To: list; +Cc: Matthieu Moy, git
In-Reply-To: <4B53941A.6020500@phuk.ath.cx>
The real WTF here is that you are using a workdir as your live dir.
If you treat git as a *source* manager like it is, you'd also have an
installer that would copy the resulting files into their live locations,
and could be edited to either leave that newly untracked file alone,
or deliberately remove it.
Use git as intended, and you get no problems.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply
* Re: [RFC] Git Wiki Move
From: Johannes Schindelin @ 2010-01-17 23:06 UTC (permalink / raw)
To: J.H.; +Cc: Matthieu Moy, Petr Baudis, git
In-Reply-To: <vpqwrzhszye.fsf@bauges.imag.fr>
Hi,
On Sun, 17 Jan 2010, Matthieu Moy wrote:
> "J.H." <warthog19@eaglescrag.net> writes:
>
> > Quick update - I think I've got the vast majority of the obvious and
> > simple to correct problems fixed at http://git.wiki.kernel.org anyone
> > want to run through and see if there's anything else that would be
> > considered a show stopper?
>
> The main page is locked, and there are some broken links formatting in
> the News section: http://git.wiki.kernel.org/index.php/Main_Page#News
> I'm user "Moy" there if you want to let me fix them.
I think I managed to edit them.
> You should set $wgLogo to some Git logo, among
> http://git.or.cz/gitwiki/GitRelatedLogos
Best would be the standard one: http://git.or.cz/git-logo.png but I would
actually also like http://henrik.nyh.se/uploads/git-logo.png.
> You can also add a few links to the sidebar, by editting:
> http://git.wiki.kernel.org/index.php/MediaWiki:Sidebar
>
> (it seems I don't have permission to do it myself).
You need to be in the Sysop list to do so. Warthog, if you trust me :-)
would you mind adding me to that group? You can do that by visiting
http://git.wiki.kernel.org/index.php/Special:Userrights
when you are a sysop.
> I suggest taking the ones of the front-page:
>
> * Starting points
> ** Installation|Installation
> ** InterfacesFrontendsAndTools|Git Tools
> ** GitDocumentation|Git Documentation
> ** GitCommunity|Git Community Support
> ** GitProjects|Projects using Git
> ** GitFaq|FAQ
> ** GitHosting|Git Hosting
> ** GitLinks|Git Links
> ** GitComparison|Git Compared
Let's not forget
* navigation
** mainpage|mainpage-description
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help
* SEARCH
* TOOLBOX
BTW there is a file KHTMLFixes.css in the directory skins/monobook/ which
makes the layout break with Chromium. Apparently, it is no longer needed
by KHTML anyway. So could you please replace that file with an empty one,
or comment out the offending part, like so:
/* #column-content { margin-left: 0; } */
Thank you,
Dscho
^ permalink raw reply
* Re: git rm --cached and pull semantics
From: list @ 2010-01-17 22:50 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq1vhpufec.fsf@bauges.imag.fr>
On 01/17/2010 12:42 PM, Matthieu Moy wrote:
> list@phuk.ath.cx writes:
>
>> Hello everyone,
>>
>> I'm trying to manage and distribute a subset of /etc with git.
>> Therefore, I have * in .gitignore and use git add -f to add files. Now
>> sometimes I want to un-track a file that has been in previous commits,
>> but naturally I don't want the file deleted. I just want git to ignore
>> it again. As I read it, the way to do that is "git rm --cached $file".
>> On the local working tree, that works as expected, but when some remote
>> machine pulls a subsequent commit, it deletes the file from its working
>> tree. But I just want git to ignore the file again, just as it does in
>> the origin repo. How can I do that?
>
> I'd say there's no way, and there will hardly ever be any :-(.
>
> Git is purely snapshot-oriented, which means that when you do a "git
> rm --cached", the next commit doesn't say "this file has been
> removed", but instead, it says "the file is not here", which can be
> interpreted as "the file is not here _anymore_" when comparing the
> commit and its ancestor.
>
> But as a result, there's no place to store information about _how_ the
> file was removed. So, for the remote machine doing a "git pull", the
> merge algorithm just sees that it's not there, and deletes it.
>
> OTOH, after "git pull", it's rather simple to do something like
>
> git show HEAD@{1}:your-file.txt > your-file.txt
>
> to restore it as an untracked file. Maybe it's possible to automate
> this in a script, but I have no idea how.
>
Thanks for the clarification. I already suspected that this would
require extra information to be transmitted. However, wouldn't it make
sense for the data model to implement this? As far as I can see, the
non-existence of a special placeholder for files being un-added via rm
--cached effectively breaks the semantics of that statement. That is,
the behaviour on the local tree is inconsistent with the behaviour on
trees being pulled. Right now I can't think of a situation where it
would be desirable that a local "git rm --cached" is equivalent to a
plain "git rm" in the trees being pulled. We do have that
differentiation in the UI, so why not implement it consistently?
I'd be willing to dig into the code and come up with patches, but only
if somebody tells me the overall concept could be acceptable.
But thanks anyway for your attention so far ;-)
^ permalink raw reply
* Re: [PATCH v4] Add push --set-upstream
From: Junio C Hamano @ 2010-01-17 22:30 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1263678331-9794-1-git-send-email-ilari.liusvaara@elisanet.fi>
Looks good; thanks. Will queue on 'next'.
^ permalink raw reply
* Re: [PATCH] sample pre-commit hook: don't trigger when recording a merge
From: Junio C Hamano @ 2010-01-17 22:24 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20100118061636.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> I sent this patch but didn't receive any feedback. Is it a bad idea?
I think the behaviour might make sense for some workflows but not always,
and it also depends on what is checked by the hook, and the extent of
damage detected by the check for a particular merge.
The sample hook checks whitespace breakage, and in the context of merging
other people's branch to obtain a change that is huge enough that neither
I nor the original author may be inclined to fix it up, it _might_ sense
to say that (1) the other branch is already borked and (2) it is too late
to fix it up.
But these two are different from (3) there is not much point complaining.
> It may be better if 'git-commit' didn't call this hook when recording a merge,
I doubt it. I think it largely depends on where you are merging to as
well. I may respond to a pull request by others by merging to 'pu', to
give the topic wider visibility, and in such a case I may wish to disable
the check. On the other hand, when I redo the merge to advance the same
topic to 'next', I may want to notice the breakage so that I can tell the
person to clean up the branch before asking me to pull for real.
So I am slightly negative on this change; it would be better to reject
committing the merge and let the user decide if it is too much to bother
fixing up the other branch (in which case you would reset the merge away),
or let small breakages pass by running "git commit --no-verify" to bypass
the hook explicitly.
>> When recording a merge, even if there are problematic whitespace errors,
>> let them pass, because the damage has already been done in the history. If
>> this hook triggers, it will invite a novice to fix such errors in a merge
>> commit but such a change is not related to the merge. Don't encourage it.
>>
>> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
>> ---
>> templates/hooks--pre-commit.sample | 5 +++++
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/templates/hooks--pre-commit.sample b/templates/hooks--pre-commit.sample
>> index 439eefd..66e56bb 100755
>> --- a/templates/hooks--pre-commit.sample
>> +++ b/templates/hooks--pre-commit.sample
>> @@ -7,6 +7,11 @@
>> #
>> # To enable this hook, rename this file to "pre-commit".
>>
>> +if test -f "${GIT_DIR-.git}"/MERGE_HEAD
>> +then
>> + exit 0
>> +fi
>> +
>> if git-rev-parse --verify HEAD >/dev/null 2>&1
>> then
>> against=HEAD
>> --
>> 1.6.6
>>
>> --
>> Nanako Shiraishi
>> http://ivory.ap.teacup.com/nanako3/
>
> --
> Nanako Shiraishi
> http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] commit: match explicit-ident semantics for summary and template
From: Junio C Hamano @ 2010-01-17 22:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jeff King, git
In-Reply-To: <201001172153.44413.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> On Sonntag, 17. Januar 2010, Jeff King wrote:
>> - if (!user_ident_explicitly_given) {
>> + if (user_ident_explicitly_given != IDENT_ALL_GIVEN) {
>> strbuf_addstr(&format, "\n Committer: ");
>
> Sorry for chiming in so late, but this new condition worries me a bit. On all
> of my machines I have the GECOS field filled in with "Johannes Sixt", i.e., I
> do not need user.name. But of course the automatically derived email address
> is nonsense, so I've set up only user.email. Now I would always this hint,
> wouldn't I? Do most others fill in GECOS in ways that are inappropriate for
> git?
We could say something like
if (!(user_ident_explicitly_given & IDENT_EMAIL_GIVEN))
and it probably is a safer change on platforms with GECOS available, but
then wouldn't msysgit folks have to fork this code?
Below are _two_ overlapping patches that apply on top of individual
topics; they will conflict when the topics are merged but hopefully in a
way that is trivially understandable, and I think can supersede Jeff's
patch.
-- >8 -- to jc/ident topic -- >8 --
builtin-commit.c | 2 +-
cache.h | 1 +
ident.c | 9 +++++++++
3 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index f4974b5..b76f327 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -624,7 +624,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
author_ident);
free(author_ident);
- if (user_ident_explicitly_given != IDENT_ALL_GIVEN)
+ if (!user_ident_sufficiently_given())
fprintf(fp,
"%s"
"# Committer: %s\n",
diff --git a/cache.h b/cache.h
index 16c8e8d..f7a287c 100644
--- a/cache.h
+++ b/cache.h
@@ -929,6 +929,7 @@ extern char git_default_name[MAX_GITNAME];
#define IDENT_MAIL_GIVEN 02
#define IDENT_ALL_GIVEN (IDENT_NAME_GIVEN|IDENT_MAIL_GIVEN)
extern int user_ident_explicitly_given;
+extern int user_ident_sufficiently_given(void);
extern const char *git_commit_encoding;
extern const char *git_log_output_encoding;
diff --git a/ident.c b/ident.c
index d4f6145..96b56e6 100644
--- a/ident.c
+++ b/ident.c
@@ -259,3 +259,12 @@ const char *git_committer_info(int flag)
getenv("GIT_COMMITTER_DATE"),
flag);
}
+
+int user_ident_sufficiently_given(void)
+{
+#ifndef WINDOWS
+ return (user_ident_explicitly_given & IDENT_MAIL_GIVEN);
+#else
+ return (user_ident_explicitly_given == IDENT_ALL_GIVEN);
+#endif
+}
-- 8< -- to jc/ident topic -- 8< --
-- >8 -- to jk/warn-author-committer-after-commit topic -- >8 --
builtin-commit.c | 4 ++--
cache.h | 1 +
ident.c | 5 +++++
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 7f61e87..29dc3df 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -602,7 +602,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
author_ident);
free(author_ident);
- if (!user_ident_explicitly_given)
+ if (!user_ident_sufficiently_given())
fprintf(fp,
"%s"
"# Committer: %s\n",
@@ -991,7 +991,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
strbuf_addstr(&format, "\n Author: ");
strbuf_addbuf_percentquote(&format, &author_ident);
}
- if (!user_ident_explicitly_given) {
+ if (!user_ident_sufficiently_given()) {
strbuf_addstr(&format, "\n Committer: ");
strbuf_addbuf_percentquote(&format, &committer_ident);
if (advice_implicit_identity) {
diff --git a/cache.h b/cache.h
index bf468e5..63e0701 100644
--- a/cache.h
+++ b/cache.h
@@ -926,6 +926,7 @@ extern const char *config_exclusive_filename;
extern char git_default_email[MAX_GITNAME];
extern char git_default_name[MAX_GITNAME];
extern int user_ident_explicitly_given;
+extern int user_ident_sufficiently_given(void);
extern const char *git_commit_encoding;
extern const char *git_log_output_encoding;
diff --git a/ident.c b/ident.c
index 26409b2..248f769 100644
--- a/ident.c
+++ b/ident.c
@@ -259,3 +259,8 @@ const char *git_committer_info(int flag)
getenv("GIT_COMMITTER_DATE"),
flag);
}
+
+int user_ident_sufficiently_given(void)
+{
+ return user_ident_explicitly_given;
+}
-- 8< -- to jk/warn-author-committer-after-commit topic -- 8< --
^ permalink raw reply related
* Саня *** Ti-3 *** Бурим добавил Вас в друзья на сайте ВКонтакте.ру
From: ВКонтакте.ру @ 2010-01-17 21:17 UTC (permalink / raw)
To: Здравствуйте
Здравствуйте,
Саня *** Ti-3 *** Бурим добавил Вас в друзья на сайте ВКонтакте.ру
Вы можете зайти на сайт и просмотреть страницы Ваших друзей, используя
Ваш e-mail и автоматически созданный пароль: OO8EmDtI
ВКонтакте.ру - сайт, который ежедневно позволяет десяткам миллионов людей находить старых друзей и оставаться с ними на связи, делиться фотографиями
и событиями из жизни.
Чтобы войти на сайт, пройдите по ссылке:
http://vk.com/login.php?regemail=git@vger.kernel.org#OO8EmDtI
Внимание: Ваша регистрация не будет активирована, если Вы проигнорируете
это приглашение.
Желаем удачи!
С уважением,
Администрация ВКонтакте.ру
^ 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