* [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
* Re: qgit idea: marking refs (heads and tags)
From: Marco Costalba @ 2006-07-04 12:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8d3i6$ne9$1@sea.gmane.org>
On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
> One thing I sorely lack in qgit as compared to gitk (and even gitweb[*1*])
> is marking commits with refs (heads and tags, marked with different colors
> or different shape marker). gitk currently uses markers in short log line
> before text of commit summary, gitweb uses markers after (at the end) of
> commit log summary. In qgit head commits are marked as such, but not to
> which branche they belong[*2*].
Currently you have to select the head and the status bar will show
related information: branch, tag message, etc.
>
> And also somewhat (but to much lesser extent) showing explicitely sha1-ids
> for commit, parents, tree, referenced object (in tag), to copy'n'paste to
> shell.
>
Something as a typical browser "copy selected link" context menu entry?
Marco
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Andreas Ericsson @ 2006-07-04 12:05 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: git
In-Reply-To: <20060704111838.GA4285@spinlock.ch>
Matthias Kestenholz wrote:
> * 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.
>
True. We use relative paths where I work, so for us either way would
work. Your way is better though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: qgit idea: marking refs (heads and tags)
From: Jakub Narebski @ 2006-07-04 12:45 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550607040503x75b1abdavbbeb80b41a454e7d@mail.gmail.com>
Marco Costalba wrote:
> On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> One thing I sorely lack in qgit as compared to gitk (and even gitweb[*1*])
>> is marking commits with refs (heads and tags, marked with different colors
>> or different shape marker). gitk currently uses markers in short log line
>> before text of commit summary, gitweb uses markers after (at the end) of
>> commit log summary. In qgit head commits are marked as such, but not to
>> which branche they belong[*2*].
>
> Currently you have to select the head and the status bar will show
> related information: branch, tag message, etc.
That is step in right direction, but still when viewing history as a whole
I'd like to know which branch is which. Head refs are marked, so it shouldn't
be much work (well, perhaps some on the GUI side) to add, as an option,
head name somewhere (before or after, or even somwehere else) along commit
"subject".
>> And also somewhat (but to much lesser extent) showing explicitely sha1-ids
>> for commit, parents, tree, referenced object (in tag), to copy'n'paste to
>> shell.
>
> Something as a typical browser "copy selected link" context menu entry?
Yes, "copy sha1 of selected link" would be nice.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Jakub Narebski @ 2006-07-04 13:29 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550607040458m1e6ea6bes44b3e3eba26856f0@mail.gmail.com>
Marco Costalba wrote:
> 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.
It would be nice (I don't know if feasible) that either to provide some kind
of parameters substitution in the likes of "%head" in the invocation line
for a script to be expanded to the sha1 or name of head of currently
selected commit.
Other solution would be to provide GUI for input of command line parameters,
e.g. combo-box (i.e. editable text field, with provided list of default
values) for repository (populated from .git/branches and .git/remotes),
option to select commit or use selected commit for head ref or just commit
ref, etc...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Add a custom ./configure script
From: Jakub Narebski @ 2006-07-04 13:50 UTC (permalink / raw)
To: git
In-Reply-To: <20060704004012.22639.44317.stgit@machine.or.cz>
Petr Baudis wrote:
> The patch is on top of pu, that is Jakub Narebski's autoconf patch, because
> it reuses most of its infrastructure and just replaces the configure script.
If you named it for example configure.sh, then autoconf generated version,
and your by hand created version could coexist.
For now I think it would be best to move autoconf related files (configure.ac,
config.mak.in) to the contrib/autoconf/ area. Then one would be able to
compare config.mak.autogen generated by ./configure from autoconf, and
your ./configure script.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 2, proof of concept] autoconf: Use %configure in git.spec, autoconf dependency only in rpm target
From: Jakub Narebski @ 2006-07-04 14:09 UTC (permalink / raw)
To: git
In-Reply-To: <200607030156.50455.jnareb@gmail.com>
This is __Proof of Concept__ patch, which makes use of predefined
%configure rpm macro to define install dirs, using autoconf
generated ./configure script.
This patch introduces dependency on autoconf _only_ for rpm target during
build process.
---
Probably there is more portable way of ignoring diff exit status than
using '|| true', and probably better way to generate
"file creation"/"new file" patch from a working directory (only) file
(perhaps using git-diff too).
Sidenote 1: current git.spec.in doesn't allow building RPMS from a dirty
version:
error: line 3: Illegal char '-' in version: Version: 1.4.1.g1c7c-dirty
Is it intentional?
Sidenote 2: building rpm currently does compilation _twice_, once to generate
git-tar-tree, and once in the rpm build (in BuildRoot).
Makefile | 3 +++
git.spec.in | 6 ++++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 3c2c257..8ad1a4a 100644
--- a/Makefile
+++ b/Makefile
@@ -721,6 +722,9 @@ dist: git.spec git-tar-tree
gzip -f -9 $(GIT_TARNAME).tar
rpm: dist
+ autoconf
+ diff -Nu /dev/null configure > git-add-autoconf-configure.patch || true
+ gzip -f -9 git-add-autoconf-configure.patch
$(RPMBUILD) -ta $(GIT_TARNAME).tar.gz
htmldocs = git-htmldocs-$(GIT_VERSION)
diff --git a/git.spec.in b/git.spec.in
index 8ccd256..9c02803 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -7,6 +7,7 @@ License: GPL
Group: Development/Tools
URL: http://kernel.org/pub/software/scm/git/
Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
+Patch0: git-add-autoconf-configure.patch.gz
BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: git-core, git-svn, git-cvs, git-arch, git-email, gitk
@@ -72,15 +73,16 @@ Git revision tree visualiser ('gitk')
%prep
%setup -q
+%patch0 -p0
%build
+%configure
make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \
- prefix=%{_prefix} all %{!?_without_docs: doc}
+ all %{!?_without_docs: doc}
%install
rm -rf $RPM_BUILD_ROOT
make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \
- prefix=%{_prefix} mandir=%{_mandir} \
install %{!?_without_docs: install-doc}
(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "arch|svn|cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
--
1.4.0
^ permalink raw reply related
* Re: [PATCH 1/3] Add read_cache_from() and discard_cache()
From: Johannes Schindelin @ 2006-07-04 14:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virmepfhx.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 3 Jul 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Okay. After reading the comment, I am quite certain we can just set the
> > index_file_timestamp to 0.
>
> Thanks.
>
> > So, I still think that these two lines should be in the cleanup part of
> > get_merge_bases().
>
> I think that is sane -- please make it so.
Ummm. After reading my original mail again: bad tobacco that was. Of
course, I meant discard_cache(), not get_merge_bases(). Setting
index_file_timestamp in get_merge_bases() would be wrong.
Sorry for the noise,
Dscho
^ 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