* Re: [PATCH 3/3] git checkout --nodwim
From: Michael J Gruber @ 2009-10-23 8:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nanako Shiraishi, Avery Pennarun, Junio C Hamano, Alex Riesen,
git, Jay Soffian
In-Reply-To: <alpine.DEB.1.00.0910220226270.4985@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 22.10.2009 02:27:
> Hi,
>
> On Thu, 22 Oct 2009, Nanako Shiraishi wrote:
>
>> Quoting Avery Pennarun <apenwarr@gmail.com>
>>
>>> On Sun, Oct 18, 2009 at 3:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> Helping hands in polishing it up is very welcome.
>>>
>>> I find the idea of an option for "don't do what I mean" to be pretty
>>> entertaining. Or maybe just misleading :)
>>>
>>> Have fun,
>>>
>>> Avery
>>
>> As Junio asked for helping hands, let's try to be helpful and constructive.
>>
>> Maybe "don't second-guess" explains it better?
>
> My take on it:
>
> 1) --no-porcelain
Between --no-dwim and --no-porcelain, maybe --no-wimp is a good compromise?
> 2) we all are bike-shedding, not being constructive at all
That's the fun part!
Michael
^ permalink raw reply
* Re: requesting info page (and pdf) doc releases
From: Michael J Gruber @ 2009-10-23 8:39 UTC (permalink / raw)
To: Rustom Mody; +Cc: Sebastian Pipping, git
In-Reply-To: <f46c52560910221513w1cb19949lfa05ef964987d809@mail.gmail.com>
Rustom Mody venit, vidit, dixit 23.10.2009 00:13:
> On Fri, Oct 23, 2009 at 2:11 AM, Sebastian Pipping <sping@gentoo.org> wrote:
>>
>> hi there!
>>
>>
>> would be nice to get info pages (and pdf) doc releases in addition to
>> html and man pages. i imagine such a change to the release machine
>> should not be too hard to integrate. we could use it in gentoo.
>>
>> thanks,
>>
>>
>>
>> sebastian
>
> +1
> Why only gentoo? I would use it on ubuntu or windows as well
Because they don't build from source!? ;)
Michael
^ permalink raw reply
* Re: Detached HEAD and "git log --all"
From: Michael J Gruber @ 2009-10-23 8:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200910222237.04056.jnareb@gmail.com>
Jakub Narebski venit, vidit, dixit 22.10.2009 22:37:
> When discussing differences between concept and implementation
> of branches in Git and in Mercurial on StackOverflow[1] (abusing
> SO comment system a bit), Steve Losh[2] wrote that he was surprised
> by the fact that "git log --all" doesn't include commits made
> on detached HEAD.
>
> While documentation clearly states:
>
> --all Pretend as if all the refs in `$GIT_DIR/refs/` are listed
> on the command line as <commit>.
>
> and HEAD is in `$GIT_DIR/HEAD`, which is outside `$GIT_DIR/refs/`,
> it is nevertheless a bit strange that "git log --all" doesn't list
> all (everything).
>
> This is of course only an issue if we are on detached HEAD; I guess
> that semantics of `--all` option to git-log predates this feature.
>
> [1] http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930
> [2] http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/
>
...OK, finally found it: Dscho did just that in f0298cf (revision
walker: include a detached HEAD in --all, 2009-01-16) which is in
v1.6.1.3 and later.
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Thomas Rast @ 2009-10-23 8:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eugene Sajine, git
In-Reply-To: <7vljj3dkid.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > @@ -259,7 +260,14 @@ static void describe(const char *arg, int last_one)
> > printf("%s\n", find_unique_abbrev(sha1, abbrev));
> > return;
> > }
> > - die("cannot describe '%s'", sha1_to_hex(sha1));
> > + if (unannotated_cnt)
> > + die("cannot describe '%s'"
> > + " with only\nannotated tags. Try --tags.",
>
> Did you mean UNannotated tags here?
No, but I think I see where the misunderstanding came from.
This code path means that we did not find a tag to describe with, but
we counted some unannotated tags (and because of how the counting
logic is wrapped, this only triggers when neither --all nor --tags are
in effect).
So I wanted it to say "it is impossible to describe this with the tags
you told me to use", which in this case are the annotated ones.
I tried to keep the general structure of the message ("cannot describe
..."), and with this restriction I can't seem to find a clearer
wording. However, it could be written e.g.
No annotated tags can describe '%s'. However, there were
unannotated tags: try --tags.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git bisect Vs branch
From: Johannes Sixt @ 2009-10-23 8:34 UTC (permalink / raw)
To: Grégory Romé; +Cc: git@vger.kernel.org, Santi Béjar
In-Reply-To: <4AE156A9.9060809@maxim-ic.com>
Grégory Romé schrieb:
> Thanks Santi but I have a problem, due to the fact that the commit which
> has an impact on my code is in origin/master or first-origin/master
>
> When bisect checkout a commit from those branch I have none of my own
> modifications... So I can' test if my code is good or bad excepted if I
> can merge my commits in the bisect branch...
> ᐁ
> first-origin/master *---A---------B----------------o------C-
> \ \ \
> origin/master ----------B'----------U-----------C'-
> \ \ \
> master ------------U'----------C''-
C" is the commit that merges upstream changes into your changes. You are
saying that your changes alone (before the merge) are good, and that
upstream before the merge is also good (since it doesn't contain your
changes, it is good by definition, more or less). That indeed means that
the merge commit is the first bad one; i.e., this is exactly the situation
that the user manual describes.
You should do:
$ git checkout -b tmp master # master is at C"
$ git rebase origin/master
$ git bisect start tmp orgin/master
That is, you rebuild your history on top of origin/master in a linear
fashion. (If you had merge conflicts in U', then you will see them again.)
Then you bisect the linearized history. This will point you to the bad
commit and you will understand what is going wrong.
With this new knowledge, go back to master (C") and fix the problem.
-- Hannes
^ permalink raw reply
* Re: Detached HEAD and "git log --all"
From: Michael J Gruber @ 2009-10-23 8:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200910222237.04056.jnareb@gmail.com>
Jakub Narebski venit, vidit, dixit 22.10.2009 22:37:
> When discussing differences between concept and implementation
> of branches in Git and in Mercurial on StackOverflow[1] (abusing
> SO comment system a bit), Steve Losh[2] wrote that he was surprised
> by the fact that "git log --all" doesn't include commits made
> on detached HEAD.
>
> While documentation clearly states:
>
> --all Pretend as if all the refs in `$GIT_DIR/refs/` are listed
> on the command line as <commit>.
>
> and HEAD is in `$GIT_DIR/HEAD`, which is outside `$GIT_DIR/refs/`,
> it is nevertheless a bit strange that "git log --all" doesn't list
> all (everything).
>
> This is of course only an issue if we are on detached HEAD; I guess
> that semantics of `--all` option to git-log predates this feature.
>
> [1] http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930
> [2] http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/
>
Commit 77abcbd (Let --decorate show HEAD position, 2009-10-12) goes a
little bit in that direction, adding HEAD to the "labels" that
--decorate may use, but not to the list of refs specified by "--all". But:
Well, after playing around a bit: git rev-list --all does list my
detached HEAD, git log --all shows it (which is the same statement, of
course), whether I use --decorate or not. Are you seeing different
behaviour?
git describe --all HEAD does not describe the detached HEAD (other than
v1.6.5-87-g4584daf in my case), which may or may not be desirable
(because describe outputs at most one description, unlike --decorate).
Michael
^ permalink raw reply
* [cvsimport] Import CVS repository from a specified date or branch name
From: Klaus Rödel @ 2009-10-23 7:52 UTC (permalink / raw)
To: git
Hello,
I have a very large and old (serveral years) cvs repository and I want
to import this in git.
For my work it is not nessecary to import all the revision history from
the cvs repository.
It is engough to import only the revisions from a specified date or
branch name of the cvs repo.
Is this possible with git-cvsimport?
If yes, how?
If no, is it possible to include such a function in the git-cvsimport
script?
Thanks for any help.
Greets Klaus
^ permalink raw reply
* Re: git bisect Vs branch
From: Grégory Romé @ 2009-10-23 7:09 UTC (permalink / raw)
Cc: git@vger.kernel.org
In-Reply-To: <adf1fd3d0910220950s50ccf8efwda891374e6480a30@mail.gmail.com>
Thanks Santi but I have a problem, due to the fact that the commit which has an
impact on my code is in origin/master or first-origin/master
When bisect checkout a commit from those branch I have none of my own
modifications... So I can' test if my code is good or bad excepted if I can
merge my commits in the bisect branch...
ᐁ
first-origin/master *---A---------B----------------o------C-
\ \ \
origin/master ----------B'----------U-----------C'-
\ \ \
master ------------U'----------C''-
I generalized the problem but I can give a real example. My problem concerns an
Linux USB driver for MIPS based SoC. first-origin is the official kernel
repository and origin/master is the MIPS repository.
Cheers!
Grégory
Santi Béjar wrote:
> On Thu, Oct 22, 2009 at 5:48 PM, Grégory Romé <gregory.rome@maxim-ic.com> wrote:
>> Considering the following story what is the method to find the regression
>> with bisect?
>>
>> I cloned a git repository (origin) which derives from another one
>> (first-origin). A merge is done from first-origin to origin at each stable
>> release (identified by a tag).
>>
>> first-origin/master *---A---------B-----------------------C-
>> \ \ \
>> origin/master ----------B'----------U-----------C'-
>> \ \ \ master
>> ------------U'----------C''-
>>
>> Now, after that I merged C' I fixed the conflicts and compiled without error
>> but I have a regression. It could come from any commit between B and C or U
>> and C', and I need to modify my code to correct the issue.
>>
>> I would like to find the commit which introduce this regression by using git
>> bisect but as the history is not linear it is not so easy (1). It though to
>> create a linear history but I have no idea how to proceed...
>
> You just have to proceed as normal, but you may test more commits than
> with a linear history.
>
> The only problem is iff the culprit is a merge commit (as in the
> user-manual chapter you linked). And the "problem" is to know where
> exactly in the (merge) commit is the bug, but not the procedure.
>
> HTH,
> Santi
^ permalink raw reply
* Re: [PATCH] git svn: fix fetch where glob is on the top-level URL
From: Eric Wong @ 2009-10-23 6:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Brewster, Daniel Cordero, git
In-Reply-To: <20091023060751.GA14477@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> Eric Wong <normalperson@yhbt.net> wrote:
> > From 3abaf9fdf216fd0307bb9e9f03772bd80a64177c Mon Sep 17 00:00:00 2001
> > From: Adam Brewster <adambrewster@gmail.com>
> > Date: Thu, 22 Oct 2009 21:26:32 -0700
> > Subject: [PATCH] git svn: fix fetch where glob is on the top-level URL
>
> Actually, no, something is broken here it seems... Ugh, falling asleep :x
Oops, I was running the tests from the wrong machine that didn't have
the patch on that one.
As noted in my previous email, the leading slashes cause
SVN::Ra::get_log to fail with an assertion if the path passed to it
has a leading slash but is not a standalone slash.
Here's my original patch which seems to work fine (but doesn't allow the
more flexible, bare "*" in "branches = *:refs/remotes/*" Adam's one did.
>From 42079a567bef745996b6272ad546d682dfcf57d6 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Thu, 22 Oct 2009 23:39:04 -0700
Subject: [PATCH] git svn: fix fetch where glob is on the top-level URL
In cases where the top-level URL we're tracking is the path we
glob against, we can once again track odd repositories that keep
branches/tags at the top level. This regression was introduced
in commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d.
Thanks to Daniel Cordero for the original bug report and
bisection.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index eb4b75a..56af221 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1765,7 +1765,7 @@ sub read_all_remotes {
my $use_svm_props = eval { command_oneline(qw/config --bool
svn.useSvmProps/) };
$use_svm_props = $use_svm_props eq 'true' if $use_svm_props;
- my $svn_refspec = qr{\s*/?(.*?)\s*:\s*(.+?)\s*};
+ my $svn_refspec = qr{\s*(.*?)\s*:\s*(.+?)\s*};
foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
if (m!^(.+)\.fetch=$svn_refspec$!) {
my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
@@ -1979,7 +1979,7 @@ sub find_ref {
my ($ref_id) = @_;
foreach (command(qw/config -l/)) {
next unless m!^svn-remote\.(.+)\.fetch=
- \s*/?(.*?)\s*:\s*(.+?)\s*$!x;
+ \s*(.*?)\s*:\s*(.+?)\s*$!x;
my ($repo_id, $path, $ref) = ($1, $2, $3);
if ($ref eq $ref_id) {
$path = '' if ($path =~ m#^\./?#);
--
Eric Wong
^ permalink raw reply related
* Re: [bug][bisected] git-svn with root branches
From: Eric Wong @ 2009-10-23 6:38 UTC (permalink / raw)
To: Adam Brewster; +Cc: Daniel Cordero, git
In-Reply-To: <c376da900910220824g2948dc2sa1156bda59b49405@mail.gmail.com>
Adam Brewster <adambrewster@gmail.com> wrote:
> > I'm not sure why Adam decided the leading slash needed to be removed for
> > the git refspec. That said, the globbing/branching code still makes me
> > want to hide under a rock and I'm generally afraid to touch it.
> > I'll wait for Adam to chime in since he's braver than I am :)
> >
> How's this for brave: I'm not sure why I did that either.
>
> Looking at it again it seems correct for the leading / to be ignored because
> it has no meaning. What's the difference between the above config and
> "branches = *:refs/remotes/*" (besides the fact that one works and one
> doesn't)? In both cases I think I've asked for all of the top-level
> directories to be branches. But that has nothing to do with the rest of the
> patch, so it shouldn't have been included.
<snip>
> That is, continue disregard the / on the actual input because it means
> nothing, and add a / in places where the code will crash if it's not there.
> Even better would be to find out _why_ $path and $local_ref need a leading /
> and fix it that way, but that's more work that I don't have time for right
> now.
Actually, SVN 1.5+ does not like the leading "/" and trips on an
assertion failure on all cases except a standalone "/". That is, "/*"
continues to work since we send "/" to SVN::Ra::get_log().
--
Eric Wong
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Junio C Hamano @ 2009-10-23 6:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Howard Miller, Jakub Narebski, git
In-Reply-To: <4AE143BC.7040507@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> The easiest way (IMHO) to achieve this is certainly:
>
> # start a new branch at the tip of the series
> $ git checkout -b all-in-one the-series
>
> # squash 17 commits
> $ git reset --soft HEAD~17
> $ git commit
>
> Now you have a new branch 'all-in-one' that has the same contents as the
> original series 'the-series', but with only one commit:
>
> $ git diff the-series..all-in-one # must show no differences
I think --squash "*merge*" is conceptually simpler to explain *and*
has an added advantage that it helps preparing the consolidated log
message.
# start from the last customer dump
$ git checkout -b customer-update last-release
# give the customer the greatness in the series, content-wise
$ git merge --squash the-series
$ git commit
This will start the "customer-update" branch starting from the
last dump you gave to the customer, merge in the changes made
in the series without history, and when you make a commit, you
will have access to all the individual log messages in the
series to look at as reference, so that you can cut and paste
from them to summarized message instead of typing everything anew.
^ permalink raw reply
* Re: [PATCH] git svn: fix fetch where glob is on the top-level URL
From: Eric Wong @ 2009-10-23 6:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Brewster, Daniel Cordero, git
In-Reply-To: <20091023044843.GA16169@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> From 3abaf9fdf216fd0307bb9e9f03772bd80a64177c Mon Sep 17 00:00:00 2001
> From: Adam Brewster <adambrewster@gmail.com>
> Date: Thu, 22 Oct 2009 21:26:32 -0700
> Subject: [PATCH] git svn: fix fetch where glob is on the top-level URL
Actually, no, something is broken here it seems... Ugh, falling asleep :x
--
Eric Wong
^ permalink raw reply
* Re: feature "git tag -r" to show tags and commits they are pointing to
From: Junio C Hamano @ 2009-10-23 5:58 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Junio C Hamano, git
In-Reply-To: <76c5b8580910221930s4b31b180t8298c262d9d9f421@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> I was looking for this info in order to create second tag for the same
> commit. For example if the first tag created by somebody or
> automatically (CI, release system), so i could add a verbose tag.
>
> But i just realized that i don't need commit id for that - just tag
> the tag, stupid...
You do not have to live with a tag that points at another tag that points
at a commit.
You can still tag the commit directly with your new tag, and you do not
need to have the exact commit object name to do so. You just tell the
tool to follow the tag chain to get to the pointed-to object, like this:
$ git tag -a -m "my message" newtag oldtag^0
This assumes [*1*] that the old tag points at (strictly speaking, "might
point at") a commit object, and uses "^0" (zeroth parent of) operator to
make sure that the object the newtag points at (the last argument to the
"git tag" command, i.e. "oldtag^0" in this example) is a commit object,
not an annotated tag "oldtag" itself.
That is what I meant by "just as usable as hexadecimal to the tools".
>> ... "v0.1" is
>> much more useful than 8794hke to humans, and these tag names are just as
>> usable as the hexadecimal commit object names to the tools. You can say
>> "git show v0.1^0" and "git show 8794hke" and get the same thing.
[Footnote]
*1* A tag can point at any object, not necessarily a commit. If oldtag
points at a tree object (or a blob object), oldtag^0 will fail, because
the operator "^0" is "zeroth parent of", and is applicable only to a
commit. In general, you can write
$ git tag -a -m "my message" newtag oldtag^{}
The "^{}" operator is a special case of "^{type}" operator; the former
means "dereference the tag repeatedly until it becomes something that is
not a tag", and the latter means "dereference the tag repeatedly until it
becomes something of that type". I.e. "oldtag^0" is "oldtag^{commit}".
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Johannes Sixt @ 2009-10-23 5:48 UTC (permalink / raw)
To: Howard Miller; +Cc: Jakub Narebski, git
In-Reply-To: <26ae428a0910221411l73aa7cbak5c060925ccdf4cea@mail.gmail.com>
Howard Miller schrieb:
> Actually thinking some more.... I don't understand something about
> this. I don't actually want to merge or rebase with anything. I just
> want to say "make those commits a series of commits on a branch into
> just one commit with a new message". I seriously suspect I'm missing
> the point somewhere but what has that got to do with merging or
> rebasing?
The easiest way (IMHO) to achieve this is certainly:
# start a new branch at the tip of the series
$ git checkout -b all-in-one the-series
# squash 17 commits
$ git reset --soft HEAD~17
$ git commit
Now you have a new branch 'all-in-one' that has the same contents as the
original series 'the-series', but with only one commit:
$ git diff the-series..all-in-one # must show no differences
-- Hannes
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Howard Miller @ 2009-10-23 5:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <26ae428a0910222236l58bc64b7l12c4cff09b086dac@mail.gmail.com>
>
> Hi Jakub,
>
> Yes it helps a lot. What I *don't* care about (or want to do) is
> actually do a merge or a rebase I just want to change history. Well,
> that's what I thought I wanted. What I suppose I really want is the
> full history for *me* and a second branch with the 'reduced' history
> to push to my client. I suppose that's different yet again?
>
> Howard
>
Actually, what I should have said in the first place is that this is
specifically nothing to do with the main trunk. We are doing small
custom developments for clients away from the main project
development. So we specifically don't want to merge or rebase with the
master - that's never going to happen. I want to keep the development
branch in tact for my reference, but when I push (the custom
development branch) to the client I need that sanitized. I think I
finally have it clear in my own head now!
Howard
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Howard Miller @ 2009-10-23 5:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200910222357.15189.jnareb@gmail.com>
2009/10/22 Jakub Narebski <jnareb@gmail.com>:
> On Thu, 22 Oct 2009, Howard Miller wrote:
>
>> > You can use either "git merge --squash" or "git rebase --interactive"
>> > (changing 'pick' to 'squash').
>> >
>>
>> Actually thinking some more.... I don't understand something about
>> this. I don't actually want to merge or rebase with anything. I just
>> want to say "make those commits a series of commits on a branch into
>> just one commit with a new message". I seriously suspect I'm missing
>> the point somewhere but what has that got to do with merging or
>> rebasing?
>
> Actually using "git merge --squash" is a bit different from using
> "git rebase --interactive".
>
>
> 1. "git merge --squash"
>
> From documentation:
>
> --squash::
> Produce the working tree and index state as if a real
> merge happened (except for the merge information),
> but do not actually make a commit or
> move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
> cause the next `git commit` command to create a merge
> commit. This allows you to create a single commit on
> top of the current branch whose effect is the same as
> merging another branch (or more in case of an octopus).
>
> This means for example if you did your changes on a separate
> topic branch, and you want to merge your changes into 'master'
> branch, you would do
>
> $ git checkout master
> $ git merge side-branch
>
> which would result in the following history:
>
>
> ---*---*---*---*---*---*---*---M <-- master
> \ /
> \-.---.---.---.---.---.-/ <-- side-branch
>
>
> If you used '--squash' option to git-merge, because changes were
> made in throwaway topic branch, and as you said only final result
> matter, you would get:
>
> $ git checkout master
> $ git merge --squash side-branch
>
> ---*---*---*---*---*---*---*---M' <-- master
> \
> \-.---.---.---.---.---. <-- side-branch
>
>
> where commit M' has the same contents (the same tree) as commit M
> in previous example, but is not a merge commit.
>
> If you simply want to squash last say 5 commits into one, you can
> use "git merge --squash" for it in the following way:
>
> $ git reset --hard HEAD~5
> $ git merge --squash --no-ff HEAD@{1}
>
> which means basically: rewind to state 5 commits back, then merge
> in changes from before rewind, squashing them. The --no-ff is needed
> because otherwise it would be fast-forward and no commit would be
> created.
>
>
> 2. "git rebase --interactive"
>
> The interactive rebase is meant to edit commits being rebased, but
> it can be used simply to edit commits. It includes 'squash' command
> that can be used to concatenate (squash) commits.
>
> So to squash last say 5 commits into one, you would use
>
> $ git rebase --interactive HEAD~5
>
> then edit provided list of commands and commits to read something like
> this:
>
> pick deadbee The oneline of this commit
> squash fa1afe1 The oneline of the next commit
> ...
> squash beedead The oneline of the that commit
>
> i.e. replace 'pick' command by 'squash' command.
>
> This is a very powerfull command, and can be used for example to turn
> series of say 5 commits into series of say 2 commits; not simply squashing
> to a single commit, but reducing number of commits (and presumably
> cleaning up those commits).
>
>
> HTH (hope that helps)
> --
> Jakub Narebski
> Poland
>
Hi Jakub,
Yes it helps a lot. What I *don't* care about (or want to do) is
actually do a merge or a rebase I just want to change history. Well,
that's what I thought I wanted. What I suppose I really want is the
full history for *me* and a second branch with the 'reduced' history
to push to my client. I suppose that's different yet again?
Howard
^ permalink raw reply
* [PATCH] git svn: fix fetch where glob is on the top-level URL
From: Eric Wong @ 2009-10-23 4:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Brewster, Daniel Cordero, git
In-Reply-To: <20091021144113.GA7440@cumin>
>From 3abaf9fdf216fd0307bb9e9f03772bd80a64177c Mon Sep 17 00:00:00 2001
From: Adam Brewster <adambrewster@gmail.com>
Date: Thu, 22 Oct 2009 21:26:32 -0700
Subject: [PATCH] git svn: fix fetch where glob is on the top-level URL
In cases where the top-level URL we're tracking is the path we
glob against, we can once again track odd repositories that keep
branches/tags at the top level. This regression was introduced
in commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d.
Additionally, the leading slash is now optional when tracking
the top-level path to be consistent with non-top-level paths.
We now allow both of the following "branches" in [svn-remote
"foo"] sections of $GIT_CONFIG:
; with a leading slash (this worked before 6f5748e1)
branches = /*:refs/remotes/*
; now it it also works without a leading slash
branches = *:refs/remotes/*
Thanks to Daniel Cordero for the original bug report and
bisection.
[ew: commit message]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Daniel Cordero <theappleman@gmail.com> wrote:
> Hello,
>
> when trying to clone a svn repo with the command-line:
>
> $ git svn clone -b / http://svn.collab.net/repos/svn/
>
> (that is, each folder in the root of the repo should be considered it's
> own branch)
> the clone sometimes[1] fails saying:
>
> ref: 'refs/remotes/' ends with a trailing slash, this is not permitted by git nor Subversion
>
> The offending config is:
> [svn-remote "svn"]
> url = http://svn.collab.net/repos/svn
> branches = /*:refs/remotes/*
>
>
> This used to work in the past; I bisected the bad commit to
>
> commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d
> Author: Adam Brewster <adambrewster@gmail.com>
> Date: Tue Aug 11 23:14:03 2009 -0400
>
> svn: allow branches outside of refs/remotes
>
>
> Thanks in advance.
>
>
> [1] It does work when the URL has at least 1 folder of depth
> (e.g. suffix "trunk" to the above URL).
>
> Its config section is:
> [svn-remote "svn"]
> url = http://svn.collab.net/repos/svn
> branches = trunk//*:refs/remotes/*
>
git-svn.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index eb4b75a..2e9a720 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1768,7 +1768,7 @@ sub read_all_remotes {
my $svn_refspec = qr{\s*/?(.*?)\s*:\s*(.+?)\s*};
foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
if (m!^(.+)\.fetch=$svn_refspec$!) {
- my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
+ my ($remote, $local_ref, $remote_ref) = ($1, "/$2", $3);
die("svn-remote.$remote: remote ref '$remote_ref' "
. "must start with 'refs/'\n")
unless $remote_ref =~ m{^refs/};
@@ -1780,7 +1780,7 @@ sub read_all_remotes {
$r->{$1}->{url} = $2;
} elsif (m!^(.+)\.(branches|tags)=$svn_refspec$!) {
my ($remote, $t, $local_ref, $remote_ref) =
- ($1, $2, $3, $4);
+ ($1, $2, "/$3", $4);
die("svn-remote.$remote: remote ref '$remote_ref' ($t) "
. "must start with 'refs/'\n")
unless $remote_ref =~ m{^refs/};
@@ -1980,7 +1980,7 @@ sub find_ref {
foreach (command(qw/config -l/)) {
next unless m!^svn-remote\.(.+)\.fetch=
\s*/?(.*?)\s*:\s*(.+?)\s*$!x;
- my ($repo_id, $path, $ref) = ($1, $2, $3);
+ my ($repo_id, $path, $ref) = ($1, "/$2", $3);
if ($ref eq $ref_id) {
$path = '' if ($path =~ m#^\./?#);
return ($repo_id, $path);
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Daniel Barkalow @ 2009-10-23 3:43 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, Björn Steinbrink, Sean Estabrooks, git
In-Reply-To: <20091023025434.GA29908@sigio.peff.net>
On Thu, 22 Oct 2009, Jeff King wrote:
> On Wed, Oct 21, 2009 at 10:05:27AM +0200, Thomas Rast wrote:
>
> > What if any combination of fetch and merge always gave you the long
> > form? After all, even if you do have a tracking branch for whatever
> > you are merging, that information is probably useless and it would be
> > nicer if all of the following resulted in the long form:
> >
> > * git fetch git://git.kernel.org/pub/scm/git/git pu
> > git merge FETCH_HEAD
> >
> > * git remote add origin git://git.kernel.org/pub/scm/git/git
> > git fetch origin
> > git merge origin/pu
> >
> > * git fetch git://git.kernel.org/pub/scm/git/git pu:tmp
> > git merge tmp
>
> Maybe it's just me, but I actually prefer the shorthand names. Five
> years from now when I browse the history and see that I merged
> remote branch "mike/topic", I'll know exactly what that means: developer
> Mike's version of a certain topic branch. But I am not likely to care
> about exactly where we were storing developer repos at that time.
>
> But probably that is an artifact of the workflow. The scenario I am
> describing above implies a somewhat centralized workflow, where the
> shorthand contains all of the interesting information. In a totally
> distributed, we-don't-share-anything-except-the-url-namespace setup of
> an open source repo, the full URL makes more sense.
>
> So maybe it is something that should be optional.
Surely you ought to be able to get the short form with "pull", though, if
you happen to like short forms. So it would make sense to decide how to
format the merge message based entirely on an option, not at all on
whether you use pull or fetch+merge.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Jeff King @ 2009-10-23 2:54 UTC (permalink / raw)
To: Thomas Rast; +Cc: Björn Steinbrink, Daniel Barkalow, Sean Estabrooks, git
In-Reply-To: <200910211005.29053.trast@student.ethz.ch>
On Wed, Oct 21, 2009 at 10:05:27AM +0200, Thomas Rast wrote:
> What if any combination of fetch and merge always gave you the long
> form? After all, even if you do have a tracking branch for whatever
> you are merging, that information is probably useless and it would be
> nicer if all of the following resulted in the long form:
>
> * git fetch git://git.kernel.org/pub/scm/git/git pu
> git merge FETCH_HEAD
>
> * git remote add origin git://git.kernel.org/pub/scm/git/git
> git fetch origin
> git merge origin/pu
>
> * git fetch git://git.kernel.org/pub/scm/git/git pu:tmp
> git merge tmp
Maybe it's just me, but I actually prefer the shorthand names. Five
years from now when I browse the history and see that I merged
remote branch "mike/topic", I'll know exactly what that means: developer
Mike's version of a certain topic branch. But I am not likely to care
about exactly where we were storing developer repos at that time.
But probably that is an artifact of the workflow. The scenario I am
describing above implies a somewhat centralized workflow, where the
shorthand contains all of the interesting information. In a totally
distributed, we-don't-share-anything-except-the-url-namespace setup of
an open source repo, the full URL makes more sense.
So maybe it is something that should be optional.
-Peff
>
> and so on.
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: feature "git tag -r" to show tags and commits they are pointing to
From: Eugene Sajine @ 2009-10-23 2:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5svf6x9.fsf@alter.siamese.dyndns.org>
Please, disregard...
I was looking for this info in order to create second tag for the same
commit. For example if the first tag created by somebody or
automatically (CI, release system), so i could add a verbose tag.
But i just realized that i don't need commit id for that - just tag
the tag, stupid...
Thanks,
Eugene
On 10/22/09, Junio C Hamano <gitster@pobox.com> wrote:
> Eugene Sajine <euguess@gmail.com> writes:
>
>> Hi,
>>
>> Currently there is no way you can get the commits your tags are
>> pointing to by using git tag.
>> The only way i found is to use rev-parse (which is by the way not
>> supported by the bash_completion)
>>
>> It seems reasonable to have upper level command like:
>>
>> $ git tag -r
>>
>> to output
>>
>> v0.1 8794hke84f9e8h9ef9eh949793...
>> v0.2 jhkd934398e9f499f47w9789o97...
>>
>> $ git tag -n -r
>>
>> v0.1 "super message" 8794hke84f9e8h9ef9eh949793...
>> v0.2 "another message" jhkd934398e9f499f47w9789o9f...
>>
>> $ git tag -r v0.2
>> v0.2 jhkd934398e9f499f47w9789o9f...
>>
>>
>> What do you think?
>
> Not intereseted at all, as this does not look anything more than "because
> I could", not "because this is useful and sorely lacking".
>
> The "super message" and such are actually useful to humans, but "v0.1" is
> much more useful than 8794hke to humans, and these tag names are just as
> usable as the hexadecimal commit object names to the tools. You can say
> "git show v0.1^0" and "git show 8794hke" and get the same thing.
>
> Heck, "8794hke" is not even hexadecimal, and the fact that you did not
> even notice it is a _S*RE_ sign that they are not useful to humans.
>
> If you _are_ a human, that is ;-)
>
> In other words, please do not justify such a proposal with "I want to have
> 'git tag' command to show the commit object name". Rather, justify _why_
> (1) you _need_ to show the commit object name to begin with, and (2) the
> output _has_ to come from 'git tag' and not 'git rev-parse'.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [RFC PATCH] git-gui: Allow staging multiple lines at once
From: Jeff Epler @ 2009-10-23 1:53 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Shawn O. Pearce
In-Reply-To: <20091022195116.GB3944@book.hvoigt.net>
On Thu, Oct 22, 2009 at 09:51:16PM +0200, Heiko Voigt wrote:
> Tested it and it works like a charm. I will include Shawn in the CC: so
> he can comment.
Thanks, but don't miss the v2 patch:
http://thread.gmane.org/gmane.comp.version-control.git/130968
this fixes a bug staging line(s) followed only by deletions.
Jeff
^ permalink raw reply
* Re: confusion with git diff-tree output
From: Jeff King @ 2009-10-23 0:54 UTC (permalink / raw)
To: David Roundy; +Cc: git
In-Reply-To: <117f2cc80910211523m5c1399aej594398fb6597e5de@mail.gmail.com>
On Wed, Oct 21, 2009 at 06:23:08PM -0400, David Roundy wrote:
> You're right. I figured I must be overlooking something obvious, and
> that was it. What surprised me was that -p implies -r, which is not
> documented. Since the -p output was recursive, I incorrectly presumed
> that this was the default.
It's due to hysterical raisins:
http://article.gmane.org/gmane.comp.version-control.git/54078
-Peff
^ permalink raw reply
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Junio C Hamano @ 2009-10-23 0:28 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Alex Riesen, Thomas Rast, Eugene Sajine, git
In-Reply-To: <alpine.LFD.2.00.0910222011200.21460@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> On Thu, 22 Oct 2009, Junio C Hamano wrote:
>
>> Alex Riesen <raa.lkml@gmail.com> writes:
>>
>> > These are quite verbose. Could they be conditional on something like
>> > advice.describeHints?
>>
>> Concurred. Please make it so.
>
> I don't have a strong opinion either ways, but is having a less verbose
> message in the _error_ path really a big issue?
Thanks for catching a thinko---I somehow thought the patch was about
warning when we give an annotated tag that is farther than an unannotated
one.
It should be good enough to unconditionally give hints upon an error, as
long as they are correct.
^ permalink raw reply
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Junio C Hamano @ 2009-10-23 0:25 UTC (permalink / raw)
To: Thomas Rast; +Cc: Eugene Sajine, git
In-Reply-To: <f1e86b9095d63c6541d0a8df6a1cf8eadfe247bb.1256226187.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> @@ -259,7 +260,14 @@ static void describe(const char *arg, int last_one)
> printf("%s\n", find_unique_abbrev(sha1, abbrev));
> return;
> }
> - die("cannot describe '%s'", sha1_to_hex(sha1));
> + if (unannotated_cnt)
> + die("cannot describe '%s'"
> + " with only\nannotated tags. Try --tags.",
Did you mean UNannotated tags here?
> + sha1_to_hex(sha1));
> + else
> + die("cannot describe '%s'"
> + " with tags\nTry --always, or create some tags.",
> + sha1_to_hex(sha1));
> }
>
> qsort(all_matches, match_cnt, sizeof(all_matches[0]), compare_pt);
^ permalink raw reply
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Nicolas Pitre @ 2009-10-23 0:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Thomas Rast, Eugene Sajine, git
In-Reply-To: <7v63a7f4ka.fsf@alter.siamese.dyndns.org>
On Thu, 22 Oct 2009, Junio C Hamano wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > These are quite verbose. Could they be conditional on something like
> > advice.describeHints?
>
> Concurred. Please make it so.
I don't have a strong opinion either ways, but is having a less verbose
message in the _error_ path really a big issue?
Nicolas
^ 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