* [PATCH] t8001-annotate: fix a bash-ism in this test
From: Eric Wong @ 2006-07-04 8:04 UTC (permalink / raw)
To: Ryan Anderson; +Cc: junkio, git
In-Reply-To: <11519766033852-git-send-email-ryan@michonline.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t8001-annotate.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t8001-annotate.sh b/t/t8001-annotate.sh
index 70e2ad2..3a6490e 100755
--- a/t/t8001-annotate.sh
+++ b/t/t8001-annotate.sh
@@ -8,8 +8,8 @@ PROG='git annotate'
test_expect_success \
'Annotating an old revision works' \
- '[ $(git annotate file master | awk "{print \$3}" | grep -c "^A$") == 2 ] && \
- [ $(git annotate file master | awk "{print \$3}" | grep -c "^B$") == 2 ]'
+ '[ $(git annotate file master | awk "{print \$3}" | grep -c "^A$") -eq 2 ] && \
+ [ $(git annotate file master | awk "{print \$3}" | grep -c "^B$") -eq 2 ]'
test_done
--
1.4.1.g4148
^ permalink raw reply related
* Re: git-cvsimport gets parents wrong for branches
From: Johannes Schindelin @ 2006-07-04 8:09 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Elrond, git
In-Reply-To: <46a038f90607031615m2cafbf05q5922fb04eae72362@mail.gmail.com>
Hi,
On Tue, 4 Jul 2006, Martin Langhoff wrote:
> It is pretty hard to get that one right in any case, as there are
> cases where the new branch starts from something that is not a commit
> in the parent (from GIT's perspective).
But it should be easy to introduce a faked commit, which just contains
those versions (and takes the newest commit touching any of these file
versions as branch point).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2nd try] Make git-fmt-merge-msg a builtin
From: Johannes Schindelin @ 2006-07-04 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk66tls5o.fsf@assigned-by-dhcp.cox.net>
Hai^H^H^HHi,
On Tue, 4 Jul 2006, Junio C Hamano wrote:
> >> I think we should extend boolean to accept 'yes' and 'no',
> >
> > In that case, could we have "YesPlease", "oui", "si" and "da", too? ;-)
>
> Hai? Nah, that's too much.
You know, I always wondered if we could introduce "perhaps", for us
procrastinators.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Make clear_commit_marks() clean harder
From: Junio C Hamano @ 2006-07-04 8:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607040951390.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> If we didn't mark them, then clearing them would be a no-op, so nobody
>> really cares.
>
> My point being: if we try to clear commits we could not have possibly
> marked, because they were not yet parsed, this is wrong.
While you say above is correct, object.parsed bit does not give
you enough information to decide if we could not have possibly
marked or not, because it is perfectly valid to mark a commit
that we have not parsed.
As Linus said in this thread already (I am rephrasing):
- When you have a commit object, which is parsed, you can tell
who its parents are; more importantly, at that point you have
access to the commit objects for the parents already, but they
may not have been parsed.
- If you can make a decision whether the parents of a commit
should be marked or not solely by looking at the commit, you
are allowed to do so before parsing these parents. The
commit you look at to make that decision has to be parsed for
you to know who the parents are, though.
Marking unparsed objects is a valid operation because even
unparsed objects have flags field that is retained when they are
later lazily parsed.
Right now, in the inner loop of the main loop of merge_base()
code, we parse each parent and insert it into the &list, but
instead we could parse commit (if not parsed yet) just before
taking its parents list in the outer loop. That way we would
parse the parents lazily and will have commits marked but still
not parsed.
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Johannes Schindelin @ 2006-07-04 8:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitzilla, git
In-Reply-To: <7vpsgllsnp.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 4 Jul 2006, Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
> >> This is a good demonstration that merge-base may not give you
> >> minimal set for pathological cases. If you want to be through
> >> you could traverse everything to make sure we do not say 'S' is
> >> relevant, but that is quite expensive, so I think there will
> >> always be artifacts of horizon effect like this no matter how
> >> you try to catch it (didn't I keep saying that already?).
> >
> > The problem is in mark_reachable_commits(); it is either superfluous
> > or it needs to parse_commit() those commits that haven't been parsed
> > yet that it needs to traverse.
>
> Yes, you could traverse everything. But that is not practical.
> We have known that the clean-up pass has this horizon effect,
> and it is a compromise.
We could introduce a time.maximumSkew variable, and just walk only
that much further when traversing the commits.
So, if you do not trust your clients to have a proper ntp setup, just say
"I trust my peers to be off at most 1 day". That would save lots vs
traverse-everything.
Ciao,
Dscho
^ permalink raw reply
* Can't import Xenomai svn repo
From: llandre @ 2006-07-04 8:48 UTC (permalink / raw)
To: git
Hi all,
I tried to import Xenomai svn repo but the script failed:
git-svnimport -v -C xenomai.git http://svn.gna.org/xenomai/trunk
RA layer request failed: PROPFIND request failed on '/xenomai/trunk':
PROPFIND of '/xenomai/trunk': 405 Method Not Allowed
(http://svn.gna.org) at /usr/bin/git-svnimport line 135
Git version is 1.4.0.
Anybody can help me?
TIA,
llandre
DAVE Electronics System House - R&D Department
web: http://www.dave-tech.it
email: r&d2@dave-tech.it
^ permalink raw reply
* Re: [PATCH] t8001-annotate: fix a bash-ism in this test
From: Junio C Hamano @ 2006-07-04 8:46 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060704080424.GA31612@soma>
Thanks -- good catch.
^ permalink raw reply
* [PATCH] Teach rev-parse the ... syntax.
From: Santi Béjar @ 2006-07-04 9:02 UTC (permalink / raw)
To: Git Mailing List, Junio C. Hamano
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
I think this time the mail patch is OK, I've tested it.
builtin-rev-parse.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 5f5ade4..8d2beb2 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -331,14 +331,29 @@ int cmd_rev_parse(int argc, const char *
unsigned char end[20];
const char *next = dotdot + 2;
const char *this = arg;
+ int symmetric = *next == '.';
+
*dotdot = 0;
+ next += symmetric;
+
if (!*next)
next = "HEAD";
if (dotdot == arg)
this = "HEAD";
if (!get_sha1(this, sha1) && !get_sha1(next, end)) {
show_rev(NORMAL, end, next);
- show_rev(REVERSED, sha1, this);
+ show_rev(symmetric?NORMAL:REVERSED, sha1, this);
+ if (symmetric) {
+ struct commit *a, *b;
+ a = lookup_commit_reference(sha1);
+ b = lookup_commit_reference(end);
+ struct commit_list *exclude = get_merge_bases(a, b,1);
+ while (exclude) {
+ show_rev(REVERSED,
+ exclude->item->object.sha1,NULL);
+ exclude = exclude->next;
+ }
+ }
continue;
}
*dotdot = '.';
--
1.4.1.ge6c0-dirty
^ permalink raw reply related
* New And the results will impress your girl
From: Della @ 2006-07-04 9:47 UTC (permalink / raw)
To: godard
Nice to see you!
Prolong your ssex. You have small peniis? Add 3 inches in lenght! Find what you need here: http://abirtes.com/gal/ms
A black plum is as sweet as a white. Not to know is bad; not to wish to know is worse Every man has his price You can lead a horse to water but.. how?. A tidy house holds a bored woman.
^ permalink raw reply
* Re: Can't import Xenomai svn repo
From: Dennis Stosberg @ 2006-07-04 10:17 UTC (permalink / raw)
To: llandre; +Cc: git
In-Reply-To: <44AA2B50.4060403@dave-tech.it>
llandre wrote:
> I tried to import Xenomai svn repo but the script failed:
>
> git-svnimport -v -C xenomai.git http://svn.gna.org/xenomai/trunk
> RA layer request failed: PROPFIND request failed on '/xenomai/trunk':
> PROPFIND of '/xenomai/trunk': 405 Method Not Allowed (http://svn.gna.org) at
> /usr/bin/git-svnimport line 135
Looks like the repository is simply not accessible by http.
$ svn co http://svn.gna.org/xenomai/trunk
svn: PROPFIND request failed on '/xenomai/trunk'
svn: PROPFIND of '/xenomai/trunk': 405 Method Not Allowed (http://svn.gna.org)
git-svnimport imports a complete svn repository including its
branches and tags (as long as the svn repo follows the official
layout). So you would run it against the repository's root:
git svnimport svn://svn.gna.org/xenomai/
If you want to import/track the trunk only (and maybe commit to it),
git-svn from git's contrib is probably what you want.
Regards,
Dennis
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Junio C Hamano @ 2006-07-04 10:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitzilla, git
In-Reply-To: <Pine.LNX.4.63.0607041019580.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> We could introduce a time.maximumSkew variable, and just walk only
> that much further when traversing the commits.
>
> So, if you do not trust your clients to have a proper ntp setup, just say
> "I trust my peers to be off at most 1 day". That would save lots vs
> traverse-everything.
The problem ALASCM's example demonstrates does rely on clock
skews. The timestamps used in the example looked like this:
1 1
/ \/ \
4 -1 4
| | |
3 -2 3
| | |
2 -3 2
\ | /
0
The crucial clock skew the case relies on is that the tip of the
middle branch (-1) is older than the common commit (0). But the
topmost commits with timestamp 1 could be with timestamp 5 to
correct the clock skew and still make the example "fail".
5 5
/ \/ \
4 -1 4
| | |
3 -2 3
| | |
2 -3 2
\ | /
0
However, I am not sure how you are going to use that maximumSkew
variable. The evil owner of the middle branch may have started
running a "git am" to commit 4-patch series just when the
machine's clock jumped back by 3 seconds, at the pace of 1 patch
a second. Then he pushes '0' out on "master" branch, and the
three commits on top of that on "next" branch.
Two days later, two friends build left and right strands of
pearls based on the "master" branch of the evil owner of the
middle branch. Maybe they do that one patch a day. On the
fifth day, they both merge the "next" branch.
The point is that it does not require a very large clock skew to
trigger this.
^ permalink raw reply
* Re: git-cvsimport gets parents wrong for branches
From: Elrond @ 2006-07-04 10:46 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90607031615m2cafbf05q5922fb04eae72362@mail.gmail.com>
On Tue, Jul 04, 2006 at 11:15:47AM +1200, Martin Langhoff wrote:
> Elrond,
>
> you are right, the current git-cvsimport takes a very naive approach
> to determine where branches open from. It uses cvsps internally, which
> only reports on the ancestor branch, so we take the latest commit from
> the ancestor.
If there is no fix visible, it probably should be
documented, that git-cvsimport isn't the perfect solution,
so people aren't surprised.
> Parsecvs probably has a more sophisticated approach, have you tried it?
After finding the current correct git:-url [1] for it, I
noticed, that I need libgit for it (I use git from my
distribution), so I've postponed this.
Of course, you can use my script and try parsecvs yourself.
> If the cvs2svn documentation is not lying, it probably has the
> smartest/correctest implementation. For small-medium repos, you may be
> able to run cvs2svn and then import with git-svnimport.
I'll try that soon.
Elrond
[1] git://anongit.freedesktop.org/git/users/keithp/parsecvs
^ permalink raw reply
* Re: [PATCH] Teach rev-parse the ... syntax.
From: Johannes Schindelin @ 2006-07-04 10:50 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List, Junio C. Hamano
In-Reply-To: <873bdhbv4x.fsf@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 387 bytes --]
Hi,
On Tue, 4 Jul 2006, Santi Béjar wrote:
> + struct commit_list *exclude = get_merge_bases(a, b,1);
You never free_commit_list() exclude.
Side thought: we do not really support multiple ranges, do we? E.g.
git-rev-list HEAD~10..HEAD~8 HEAD^..
would not yield the intended result, right? (And same goes for ... ranges)
Maybe we should at least warn about that.
Ciao,
Dscho
^ permalink raw reply
* Re: git-cvsimport gets parents wrong for branches
From: Elrond @ 2006-07-04 11:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.63.0607041007391.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Jul 04, 2006 at 10:09:18AM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 4 Jul 2006, Martin Langhoff wrote:
>
> > It is pretty hard to get that one right in any case, as there are
> > cases where the new branch starts from something that is not a commit
> > in the parent (from GIT's perspective).
>
> But it should be easy to introduce a faked commit, which just contains
> those versions (and takes the newest commit touching any of these file
> versions as branch point).
Of couye in theory, (if cvs was used sanely), the base of
each branch should be a commit on the parent-branch. But as
we all know, cvs allows pathologic cases.
(My script doesn't create such a case, it's sanely
representable in git without any fake commits.)
So now for the patholigic cases (when they're solved, the
main issue is solved too):
Of course, the base version for a branch can be turned into
a tree (should be easy: cvsps's first changeset of the
branch has the previous revisions of each file).
This tree can also be turned into a fake commit...
just which parent should our new fake commit have?
My current simple answer is: The commit on the parent
branch with the most matching number of files, so that
the diff, that the fake commit introduces has the least
number of files.
In the non-patholoc case, the fake commit would introduce
no diff at all and should be dropped.
Of couse I have no idea, how hard it would be to implement
this. And in reality, it would be cvsps's job to do that.
Elrond
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Andreas Ericsson @ 2006-07-04 11:10 UTC (permalink / raw)
To: Keith Packard; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <1151987441.4723.110.camel@neko.keithp.com>
Keith Packard wrote:
> On Mon, 2006-07-03 at 20:40 -0700, Linus Torvalds wrote:
>
>
>> "And, it's painfully slow, even when the repository is up to date"
>>
>>and gave a 17-second time.
>
>
> It's faster this evening, down to 8 seconds using ssh and 4 seconds
> using git. I clearly need to force use of the git protocol. Anyone else
> like the attached patch?
Since it changes the current meaning of ssh+git, I'm not exactly
thrilled. However, "git/ssh" or "ssh/git" would work fine for me. The
slash-separator could be used to say "fetch over this, push over that",
so we can end up with any valid protocol to use for fetches and another
one to push over.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Jakub Narebski @ 2006-07-04 11:16 UTC (permalink / raw)
To: git
In-Reply-To: <7vsllhhcxr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> The problem ALASCM's example demonstrates does rely on clock
> skews. The timestamps used in the example looked like this:
>
>
> 1 1
> / \/ \
> 4 -1 4
> | | |
> 3 -2 3
> | | |
> 2 -3 2
> \ | /
> 0
>
> The crucial clock skew the case relies on is that the tip of the
> middle branch (-1) is older than the common commit (0). But the
> topmost commits with timestamp 1 could be with timestamp 5 to
> correct the clock skew and still make the example "fail".
>
> 5 5
> / \/ \
> 4 -1 4
> | | |
> 3 -2 3
> | | |
> 2 -3 2
> \ | /
> 0
So would putting timestamp for merge be MAX(now, parents timestamps)
solve the problem?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Teach rev-parse the ... syntax.
From: Santi @ 2006-07-04 11:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Junio C. Hamano
In-Reply-To: <Pine.LNX.4.63.0607041247200.29667@wbgn013.biozentrum.uni-wuerzburg.de>
2006/7/4, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Tue, 4 Jul 2006, Santi Béjar wrote:
>
> > + struct commit_list *exclude = get_merge_bases(a, b,1);
>
> You never free_commit_list() exclude.
>
Ups! But thanks to Junio it is already there :)
Santi
--
Looking for signature...
Looking for signature...done
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Matthias Kestenholz @ 2006-07-04 11:18 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <44AA4CB0.7020604@op5.se>
* Andreas Ericsson (ae@op5.se) wrote:
> Keith Packard wrote:
> >On Mon, 2006-07-03 at 20:40 -0700, Linus Torvalds wrote:
> >
> >
> >> "And, it's painfully slow, even when the repository is up to date"
> >>
> >>and gave a 17-second time.
> >
> >
> >It's faster this evening, down to 8 seconds using ssh and 4 seconds
> >using git. I clearly need to force use of the git protocol. Anyone else
> >like the attached patch?
>
> Since it changes the current meaning of ssh+git, I'm not exactly
> thrilled. However, "git/ssh" or "ssh/git" would work fine for me. The
> slash-separator could be used to say "fetch over this, push over that",
> so we can end up with any valid protocol to use for fetches and another
> one to push over.
>
If we would do such a thing, we would be probably better off
allowing different URLs for pushing and pulling, because the git and
ssh URLs will only be the same, if the git repositories are located
in the root folder and I suspect that's almost never the case.
Matthias
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-04 11:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vk66tna71.fsf@assigned-by-dhcp.cox.net>
On 7/4/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
>
> Yes, either you (1) need to make sure the user is aware what
> underlying git commands QGit runs for them, so that the user
> knows what workflow to follow when the procedure needs to go
> manual, or (2) hide the underlying git commands QGit runs for
> users, but then you need to make QGit aware of what workflow to
> follow when the procedure needs to go manual, and guide the user
> through that workflow. I think either is fine approach;
> personally I prefer transparent tools that does (1), which is
> the impression I am getting from your description of QGit.
>
Yes, I prefer way (1) too. QGit as an error reporting infrastructure
to always report by a message box arguments (starting from 0) of
offending command, be it native git or not.
> If you take route (1), using "am --fail" number of times
> involves QGit runs "am --fail" once, guide user to fix things up
> _and_ give control back to QGit, then you run the next "am
> --fail", etc, which would be quite cumbersome to implement. But
> running multiple am and do reset soft to roll back needed number
> of parents might be easier option to implement in QGit, but you
> still have the same "you give the control to the user but then
> you have to take the control away to proceed" problem when the
> patch does not apply cleanly somewhere (you let the user to hand
> resolve and say "am --resolved", but then when the series is
> depleted, somebody has to run "reset --soft" to roll N commits
> back to realize what you wanted to do, so at that point QGit
> somehow needs to take control back).
>
>
I have started to implement the feature suggested by Jakub (patch in
working dir only, not committed). The core is a loop of git-am, one
for each patch to import, followed by a:
git-reset --mixed HEAD~<Num of succesfully applied patches>
To note that the above git-reset command is _always_ run be the patch
series apply successfully be it fails at some point, so that in any
case the tree is not dirty up, and you have the working tree with the
information you need in case of manual fixup.
I will plan to push as soon I'm able to reach a "pushable site" ;-)
Comments? could work? not consistent?
Marco
^ permalink raw reply
* Re: contrib/ status
From: Jakub Narebski @ 2006-07-04 11:26 UTC (permalink / raw)
To: git
In-Reply-To: <7vmzbrwi3c.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> OTOH I haven't seen much interest in contrib/colordiff, now
> Johannes's built-in "diff --color" is in. So if people do not
> mind, I'd like to drop it.
Since when, and is it documented?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-cvsimport gets parents wrong for branches
From: Johannes Schindelin @ 2006-07-04 11:33 UTC (permalink / raw)
To: Elrond; +Cc: Martin Langhoff, git
In-Reply-To: <20060704110313.GC24572@memak.tu-darmstadt.de>
Hi,
On Tue, 4 Jul 2006, Elrond wrote:
> On Tue, Jul 04, 2006 at 10:09:18AM +0200, Johannes Schindelin wrote:
> > Hi,
> >
> > On Tue, 4 Jul 2006, Martin Langhoff wrote:
> >
> > > It is pretty hard to get that one right in any case, as there are
> > > cases where the new branch starts from something that is not a commit
> > > in the parent (from GIT's perspective).
> >
> > But it should be easy to introduce a faked commit, which just contains
> > those versions (and takes the newest commit touching any of these file
> > versions as branch point).
>
> [...]
>
> just which parent should our new fake commit have?
That is what I tried to address with the "branch point" thing. Just take
the newest commit (in the ancestor line) touching the file versions of
that particular tree, or in other words, the oldest commit having at least
these file versions.
IMHO it is dumb enough not to branch off of a commit that it does not
matter that much what parent this faked commit has.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Johannes Schindelin @ 2006-07-04 11:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8dim7$8cm$1@sea.gmane.org>
Hi,
On Tue, 4 Jul 2006, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
>
> > The problem ALASCM's example demonstrates does rely on clock
> > skews. The timestamps used in the example looked like this:
> >
> >
> > 1 1
> > / \/ \
> > 4 -1 4
> > | | |
> > 3 -2 3
> > | | |
> > 2 -3 2
> > \ | /
> > 0
> >
> > The crucial clock skew the case relies on is that the tip of the
> > middle branch (-1) is older than the common commit (0). But the
> > topmost commits with timestamp 1 could be with timestamp 5 to
> > correct the clock skew and still make the example "fail".
> >
> > 5 5
> > / \/ \
> > 4 -1 4
> > | | |
> > 3 -2 3
> > | | |
> > 2 -3 2
> > \ | /
> > 0
>
> So would putting timestamp for merge be MAX(now, parents timestamps)
> solve the problem?
If there is an evil committer, the parents could have bogus timestamps,
too. But then, I would not pull from such an evil person...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Johannes Schindelin @ 2006-07-04 11:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitzilla, git
In-Reply-To: <7vsllhhcxr.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 4 Jul 2006, Junio C Hamano wrote:
> However, I am not sure how you are going to use that maximumSkew
> variable.
My idea was to continue traversing the merge base's ancestors, marking
them UNINTERESTING, until hitting a commit which is maximumSkew older than
the merge base (and not just stop at the merge base, as is the case right
now, and neither continue traversing in eternity like suggested).
This would not help _evil_ cases (i.e. intentional), but most certainly
your regular clock skew in a Microsoft network.
Ciao,
Dscho
^ permalink raw reply
* Re: contrib/ status
From: Johannes Schindelin @ 2006-07-04 11:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8dj9u$asn$1@sea.gmane.org>
Hi,
On Tue, 4 Jul 2006, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> > OTOH I haven't seen much interest in contrib/colordiff, now
> > Johannes's built-in "diff --color" is in. So if people do not
> > mind, I'd like to drop it.
>
> Since when, and is it documented?
To your first question:
commit cd112cef999c59a7ca2a96c37b197d303a355924
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Tue Jun 13 18:45:44 2006 +0200
diff options: add --color
To the second:
No.
;-) It should be in diff-options.txt, but then you would have to document
the config variables to change the color, too, so I'll leave that task to
somebody else and go back to work...
Ciao,
Dscho
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-04 11:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <e8d2eo$k44$1@sea.gmane.org>
On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> > QGit is not supposed to be a GUI replacement of git UI. QGit only let
> > users quickly call some commonly used commands. [...]
>
> It's a pity. Doing some of commands from visual history viewer, with view of
> branches etc. would be so much easier: like bisect, rebasing, cherry
> picking, reverting a commit...
>
In the past weeks I (with Pavel support) have implemented and pushed
the concept of "custom actions".
Is it possible to associate commands sequences, scripts and anything
else executable to a custom action. Actions can be called and run from
menu entry and corresponding output is grabbed by a terminal window.
Instead of hard code each git-native command, this way you have a
flexible framework to add shortcuts and menu entry for anything you
would like to be a click away. BTW I use this for stuff like git pull,
but also for 'make' and 'make install' because you have a window
terminal for feedback.
There is also the possibility to input command line parameters before
to run, useful, as example for a git pull action that asks for source
repository to pull from.
Is this something that can fulfill you request? do you need something
different? perhaps something as a "default to current selected SHA as
input argument" flag.
Marco
^ 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