* interactive rebase not rebasing
From: Stephen Haberman @ 2008-09-29 4:50 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]
Hello,
Per the emails from me last week, I'm working in an environment with
shared topic branches and am trying to find a bullet-proof way for devs
to rebase their local commits after the topic branch has moved.
The easy approach would be to just let `git pull` create merge commits,
and I would have been done with this long ago, but I'm striving to get
rebasing to "just work" and avoid the ugliness of same-branch merge
commits. Cross-branch merge commits are cool, but not same-branch.
So, here's a crazy scenario we've ran into--a new release has hit
stable, with two devs working on the same topic branch, and both of them
merge. One wins, and the other has to rebase. Previously, this was
replaying commits, but with great tips from the list last week, `rebase
-i -p` is handling most scenarios.
However, not this one:
# A --C------ <-- origin/stable
# \ | \
# B -- D -- E -- F <-- origin/topic2
# \|
# g -- h <-- topic2
topic2 is a dev that has locally merged stable in g, moved on in h, is
ready to push, but another dev already merged stable in E, and also
committed F.
If we do a `git pull --no-rebase`, the result is:
# A --C------ <-- origin/stable
# \ | \
# B -- D -- E -- F <-- origin/topic2
# \| \
# g -- h ------- i <-- topic2
But i is a same-branch merge, and we'd rather rebase to something like:
# A --C------ <-- origin/stable
# \ \
# B -- D -- E -- F <-- origin/topic2
# \
# h' <-- topic2
(...maybe g' in there if g resolved stable conflicts differently
E did them. I'm not sure, I haven't gotten there yet.)
However, currently, `git rebase -i -p origin/topic2` results in:
# A --C------ <-- origin/stable
# \ | \
# B -- D -- E -- F <-- origin/topic2
# \|
# g -- h <-- topic2
Nothing has changed. g & h haven't moved...I can keep executing this
operation and the commits never make it on top of origin/topic2's F.
Frustratingly, if I run non-interactive rebase, it works perfectly. But
I've got other cases (see earlier posts) that do need the interactive
rebase. Personally, I could probably make do with trying each and
seeing what happened, but I'm really trying to find a bullet proof
command/alias/script for devs to run and have it "just work".
I've attached a test that sets up the DAG as above and currently passes
by asserting the not-desired/unchanged-DAG result. The assert for the
desired result is commented out at the end.
Am I correct in asserting this is some sort of bug in the interactive
rebase such that g & h are not ending up on top of F?
Thanks,
Stephen
[-- Attachment #2: t3404b.sh --]
[-- Type: text/x-sh, Size: 2680 bytes --]
#!/bin/sh
test_description='rebase interactive does not rebase'
. ./test-lib.sh
test_expect_success 'setup' '
echo "setup" >a &&
git add a &&
git commit -m "setup" &&
git clone ./. server &&
rm -fr server/.git/hooks &&
git remote add origin ./server &&
git config --add branch.master.remote origin &&
git config --add branch.master.merge refs/heads/master &&
git fetch &&
git checkout -b stable master &&
echo "setup.stable" >a &&
git commit -a -m "stable" &&
git push origin stable
'
#
# A --C------ <-- origin/stable
# \ | \
# B -- D -- E -- F <-- origin/topic2
# \| \
# g -- h ------- i <-- topic2
#
# Trying to push F..i
#
# merge-base(F, h) has two options: B and C
#
test_expect_success 'merging in stable with tricky double baserev does not fool the script' '
# B: start our topic2 branch, and share it
git checkout -b topic2 origin/stable &&
git config --add branch.topic2.merge refs/heads/topic2 &&
echo "commit B" >a.topic2 &&
git add a.topic2 &&
git commit -m "commit B created topic2" &&
git push origin topic2 &&
# C: now, separately, move ahead stable, and share it
git checkout stable
echo "commit C" >a &&
git commit -a -m "commit C moved stable" &&
git push origin stable &&
# D: have another client commit (in this case, it is the server, but close enough) moves topic2
cd server &&
git checkout topic2 &&
echo "commit D continuing topic2" >a.client2 &&
git add a.client2 &&
git commit -m "commit D by client2" &&
# E: the same other client merges the moved stable
git merge stable &&
# F: the same other client moves topic2 again
echo "commit F" >a.client2 &&
git commit -a -m "commit F by client2" &&
F_hash=$(git rev-parse HEAD) &&
cd .. &&
# g: now locally merge in the moved stable (even though our topic2 is out of date)
git checkout topic2 &&
git merge stable &&
g_hash=$(git rev-parse HEAD) &&
# h: advance local topic2
echo "commit H" >a.topic2 &&
git commit -a -m "commit H continues local fork" &&
h_hash=$(git rev-parse HEAD) &&
# i: make a new merge commit
git pull --no-rebase &&
i_hash=$(git rev-parse HEAD) &&
# Watch merge rejected as something that should get rebased
# ! git push origin topic2
test "$i_hash $h_hash $F_hash" = "$(git rev-list --parents --no-walk HEAD)"
# Now fix it the merge by rebasing it
git reset --hard ORIG_HEAD &&
GIT_EDITOR=: git rebase -i -p origin/topic2 &&
h2_hash=$(git rev-parse HEAD) &&
# Should be:
# test "$h2_hash $F_hash" = "$(git rev-list --parents --no-walk HEAD)"
# But is just:
test "$h_hash $g_hash" = "$(git rev-list --parents --no-walk HEAD)"
# Where did $F_hash go?
'
test_done
^ permalink raw reply
* Re: [PATCH 2/6] gitweb: use_pathinfo filenames start with /
From: Jakub Narebski @ 2008-09-29 1:08 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Lea Wiemann, Junio C Hamano
In-Reply-To: <1222030663-22540-3-git-send-email-giuseppe.bilotta@gmail.com>
On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
> When using path info, make filenames start with a / (right after the :
> that separates them from the hash base). This minimal change allows
> relative navigation to work properly when viewing HTML files.
Good idea. Nitpick: instead of "using path info", perhaps "generating
path info URL"; this change is about gitweb link generation...
Did you check if gitweb strips leading '/' from filename?
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index e783d12..18da484 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -664,7 +664,7 @@ sub href (%) {
> if (defined $params{'hash_base'}) {
> $href .= "/".esc_url($params{'hash_base'});
> if (defined $params{'file_name'}) {
> - $href .= ":".esc_url($params{'file_name'});
> + $href .= ":/".esc_url($params{'file_name'});
> delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
> delete $params{'file_name'};
> } else {
> --
> 1.5.6.5
Is there reason why this change is separate (not squashed) from
previous commit?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 1/6] gitweb: action in path with use_pathinfo
From: Jakub Narebski @ 2008-09-29 1:03 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Lea Wiemann, Junio C Hamano
In-Reply-To: <1222030663-22540-2-git-send-email-giuseppe.bilotta@gmail.com>
I'm sorry for the delay reviewing those patches.
On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
> When using path info, reduce the number of CGI parameters by embedding
> the action in the path. The typicial cgiweb path is thus
> $project/$action/$hash_base:$file_name or $project/$action/$hash
cgiweb?
>
> This is mostly backwards compatible with the old-style gitweb paths,
> except when $project/$branch was used to access a branch whose name
> matches a gitweb action.
I would also state that gitweb _generates_ such pathinfo links if
configured (or if coming from pahinfo URL), and that this change
allow to represent wider number of gitweb links (gitweb URLs) in
pathinfo form.
Also, from what I understand, generated pathinfo links now always
use action, so they are a tiny little bit longer.
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 109 ++++++++++++++++++++++++++++++++++------------------
> 1 files changed, 72 insertions(+), 37 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index da474d0..e783d12 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -488,6 +488,37 @@ if (defined $searchtext) {
> $search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
> }
>
> +# dispatch
> +my %actions = (
> + "blame" => \&git_blame,
> + "blobdiff" => \&git_blobdiff,
> + "blobdiff_plain" => \&git_blobdiff_plain,
> + "blob" => \&git_blob,
> + "blob_plain" => \&git_blob_plain,
> + "commitdiff" => \&git_commitdiff,
> + "commitdiff_plain" => \&git_commitdiff_plain,
> + "commit" => \&git_commit,
> + "forks" => \&git_forks,
> + "heads" => \&git_heads,
> + "history" => \&git_history,
> + "log" => \&git_log,
> + "rss" => \&git_rss,
> + "atom" => \&git_atom,
> + "search" => \&git_search,
> + "search_help" => \&git_search_help,
> + "shortlog" => \&git_shortlog,
> + "summary" => \&git_summary,
> + "tag" => \&git_tag,
> + "tags" => \&git_tags,
> + "tree" => \&git_tree,
> + "snapshot" => \&git_snapshot,
> + "object" => \&git_object,
> + # those below don't need $project
> + "opml" => \&git_opml,
> + "project_list" => \&git_project_list,
> + "project_index" => \&git_project_index,
> +);
> +
This is as I understand simply moving %actions hash around?
Well, you could instead split hash declaration from defining it,
in the form of
my %actions = ();
...
%actions = (
...
);
but I guess moving declaration earlier is good solution.
> # now read PATH_INFO and use it as alternative to parameters
> sub evaluate_path_info {
> return if defined $project;
> @@ -512,6 +543,16 @@ sub evaluate_path_info {
> # do not change any parameters if an action is given using the query string
> return if $action;
> $path_info =~ s,^\Q$project\E/*,,;
> +
> + # next comes the action
> + $action = $path_info;
> + $action =~ s,/.*$,,;
I would use perhaps "$action = ($path_info =~ m!^([^/]+)/!;"
But that is Perl, so TIMTOWDI.
> + if (exists $actions{$action}) {
> + $path_info =~ s,^\Q$action\E/*,,;
> + } else {
> + $action = undef;
> + }
> +
I don't think you need quoting pattern metacharacters; valid actions
should not contain regexp metacharacters. Defensive programming?
> my ($refname, $pathname) = split(/:/, $path_info, 2);
> if (defined $pathname) {
> # we got "project.git/branch:filename" or "project.git/branch:dir/"
> @@ -525,10 +566,12 @@ sub evaluate_path_info {
> }
> $hash_base ||= validate_refname($refname);
> $file_name ||= validate_pathname($pathname);
> + $hash ||= git_get_hash_by_path($hash_base, $file_name);
I don't understand why you feel that you need to do this (this is
additional git command fork, as git_get_hash_by_path calls Git, to
be more exact it calls git-ls-tree (it could call git-rev-parse
instead). Moreover, I don't understand why you need to do this _here_,
instead of just before where you would have to have $hash variable set.
> } elsif (defined $refname) {
> # we got "project.git/branch"
> - $action ||= "shortlog";
> - $hash ||= validate_refname($refname);
> + $action ||= "shortlog";
> + $hash ||= validate_refname($refname);
> + $hash_base ||= validate_refname($refname);
> }
> }
> evaluate_path_info();
> @@ -624,8 +636,13 @@ sub href (%) {
> if ($params{-replay}) {
> while (my ($name, $symbol) = each %mapping) {
> if (!exists $params{$name}) {
> - # to allow for multivalued params we use arrayref form
> - $params{$name} = [ $cgi->param($symbol) ];
> + if ($cgi->param($symbol)) {
> + # to allow for multivalued params we use arrayref form
> + $params{$name} = [ $cgi->param($symbol) ];
> + } else {
> + no strict 'refs';
> + $params{$name} = $$name if $$name;
> + }
> }
> }
> }
What this change is about? And why this change is _here_, in this
commit? It is I think unrelated, and wrong change.
href(..., -replay=>1) is all about reusing current URL, perhaps with
a few parameters changed, like for example pagination links differ only
in page number param change. For example if we had only hb= and f=
parameters, -replay=>1 links should use only those, and not add h=
parameter because somewhere we felt that we need $hash to be calculated.
> @@ -636,10 +653,28 @@ sub href (%) {
This hunk is about generating pathinfo URL, isn't it?
You probably would want to change comment at the top of this part
of href() subroutine, namely
if ($use_pathinfo) {
# use PATH_INFO for project name
as you now try to use PATH_INFO for more than project name. Please do
not leave comments to get out of sync with the code.
> $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
> delete $params{'project'};
>
> - # Summary just uses the project path URL
> - if (defined $params{'action'} && $params{'action'} eq 'summary') {
> + # Summary just uses the project path URL, any other action come next
> + # in the URL
> + if (defined $params{'action'}) {
> + $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
> delete $params{'action'};
> }
> +
> + # next, we put either hash_base:file_name or hash
> + if (defined $params{'hash_base'}) {
> + $href .= "/".esc_url($params{'hash_base'});
> + if (defined $params{'file_name'}) {
> + $href .= ":".esc_url($params{'file_name'});
> + delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
First, this page has around 140 characters. That is too long, much too long.
Please try to wrap code around 80-characters.
Second, following Petr 'Pasky' Baudis suggestion of reducing complexity
and shortening gitweb URLs, we could unconditionally remove redundant
'hash' parameter if we have both 'hash_base' and 'file_name'
parameters. This would also simplify and speed up (lack of extra fork)
gitweb code.
> + delete $params{'file_name'};
> + } else {
> + delete $params{'hash'} if $params{'hash'} eq $params{'hash_base'};
> + }
> + delete $params{'hash_base'};
> + } elsif (defined $params{'hash'}) {
> + $href .= "/".esc_url($params{'hash'});
> + delete $params{'hash'};
> + }
O.K.... I think.
Did you test this, preferably also using Mechanize test, with gitweb
configuration turning path_info on by default.?
> }
>
> # now encode the parameters explicitly
Hmmm... now I am not so sure if it wouldn't be better to split this
patch in pathinfo parsing and pathinfo generation. The first part
would be obvious, the second part would be smaller and easier to review.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 3/8] Docs: send-email: Man page option ordering
From: Jeff King @ 2008-09-29 0:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Michael Witten, git
In-Reply-To: <200809290210.33880.jnareb@gmail.com>
On Mon, Sep 29, 2008 at 02:10:31AM +0200, Jakub Narebski wrote:
> peff> The manpage, on the other hand, is a comprehensive reference
> peff> and so should probably be alphabetized for easy reading.
>
> [...]
>
> Second, large manpages with large number of options are usually divided
> into sections, see git-rev-list(1) manpage, or rpmbuild(8) manpage. So
> there is precedent for that. And I think it is good precedent.
I am not opposed to dividing it into sections, with options alphabetized
in each section, as long as the section divisions make sense (e.g., in
rev-list, an obvious section is "commit formatting options"). I just
didn't think we had enough here to bother subdividing.
Either way will be in improvement on the current status, which is
apparently random (it looks like it was probably alphabetized at one
point, and then new options were added to the end).
-Peff
^ permalink raw reply
* Re: [PATCH 3/8] Docs: send-email: Man page option ordering
From: Jakub Narebski @ 2008-09-29 0:10 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <FB3A852B-728F-4183-A5AF-BA8F8D995AD7@mit.edu>
On Sun, 28 Sep 2008 21:04, Michael Witten wrote:
> On 28 Sep 2008, at 3:08 AM, Jakub Narebski wrote:
>> Michael Witten wrote:
>>
>>> Now the man page lists the options in alphabetical
>>> order (in terms of the 'main' part of an option's
>>> name).
>>
>> I know it is a matter of taste, but I prefer having options
>> on man page in functional order, grouped by function, perhaps
>> with subsections to group them (c.f. git-rev-list man page).
>
> See: http://marc.info/?l=git&m=122246885210923&w=2
You meant the following comment by Jeff King?
peff> 4/6: I am not sure about making the order of options the same,
peff> the two formats serve different purposes. I think
peff> "git send-email --foo" should present the options based on
peff> commonality of use. You clearly got the usage wrong, so
peff> I think it is helping you to figure out quickly what you
peff> probably meant.
This agrees with Gnits (GNU Coding Standard expanded) about --help
http://www.gnu.org/software/womb/gnits/Help-Output.html#Help-Output
# When a program has many options, try regrouping options logically,
instead of listing them all alphabetically (say), as the mere
regrouping is a succint way to convey much information. Present each
group of options in its own subtable, suitably introduced by some few
words. Separate groups by white lines for making the overall structure
more easy to grasp by the reader. Here is an excerpt from a relatively
big `--help' output:
Main operation mode:
-t, --list list the contents of an archive
-x, --extract, --get extract files from an archive
-c, --create create a new archive
-d, --diff, --compare find differences between archive and file system
-r, --append append files to the end of an archive
-u, --update only append files newer than copy in archive
-A, --catenate append tar files to an archive
--concatenate same as -A
--delete delete from the archive (not on mag tapes!)
Device blocking:
-b, --blocking-factor=BLOCKS BLOCKS x 512 bytes per record
--record-size=SIZE SIZE bytes per record, multiple of 512
-i, --ignore-zeros ignore zeroed blocks in archive (means EOF)
-B, --read-full-records reblock as we read (for 4.2BSD pipes)
peff> The manpage, on the other hand, is a comprehensive reference
peff> and so should probably be alphabetized for easy reading.
I haven't found definitive guide or definitive suggestion whether
options in man page should be alphabetized or put in some functional
order. GNU Coding Standards doesn't say anything; at least I haven't
found anything on this topic.
First, git lacks structured texinfo documentation, so manpages serves
_both_ as reference, and _as learning tool_. For learning you would
want options grouped by function, perhaps sorted alphabetically in
group. If you want to find some option, you can always use search
and incremental search capabilities of manpages pager.
Second, large manpages with large number of options are usually divided
into sections, see git-rev-list(1) manpage, or rpmbuild(8) manpage. So
there is precedent for that. And I think it is good precedent.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Petr Baudis @ 2008-09-28 21:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200809281201.04161.jnareb@gmail.com>
On Sun, Sep 28, 2008 at 12:01:03PM +0200, Jakub Narebski wrote:
> On Thu, 25 Sep 2008, Jakub Narebski wrote:
>
> > This is yet another series of planned gitweb features. It expands more
> > on new user-visible features than on improving gitweb code (therefore
> > for example using Git.pm/Git::Repo, gitweb caching, and list form of
> > open for pipelines are not mentioned here).
>
> Below there are a few more features which were missing from the list:
>
> * Support for invoking gitweb.cgi (the compiled version) from command
> line to easy generate projects list in format used by gitweb,
> perhaps also to generate web feeds (RSS, Atom, OPML). It would
> probably require adding support for CLI parameters.
Or, for starters, just document the existing one. ;-)
REQUEST_METHOD=GET QUERY_STRING=a=opml gitweb/gitweb.cgi
> * gitweb-admin or gitwebmin; I guess best as separate script.
>
> Allow to set gitweb configuration, gitweb-related per-repository
> configuration (visibility, access, description, README, URLs,...).
> Perhaps also allow to set access permissions, delete/create
> branches, change denyFastForward, rename project, set alternates,
> etc.
I don't see this very useful for gitweb administrator, but more for
owners of particular projects shown by gitweb. That would be very
useful, yes!
> * Make gitweb use less dependent on understanding git terminology, like
> 'tree' -> 'browse' etc. (proposed by Pieter de Bie (Pieter) on #git,
> as "simplified interface", 2008-09-27T14:56+0200).
>
> 'tree' -> 'browse', 'blob' -> 'file' or 'show',
> 'snapshot' -> 'archive' or 'download', 'heads' -> 'branches'
> 'commit | commitdiff | tree | snapshot' -> 'show | browse' for heads
>
> Unfortunately there is no consensus on how such simpler terminology
> should look like...
Yes, I would be very careful here. I personally agree with 'snapshot' ->
'archive' and 'heads' -> 'branches', but I'm not comfortable with the
others at all.
> * Possibly: fallback to "user.name <user.email>" for repository owner
That would be good.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: strange "git clone" behavior wrt an active branch
From: Santi Béjar @ 2008-09-28 19:43 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Git Mailing List
In-Reply-To: <ee2a733e0809280623i30a9e298i30db2a84b8530d61@mail.gmail.com>
On Sun, Sep 28, 2008 at 3:23 PM, Leo Razoumov <slonik.az@gmail.com> wrote:
> On 9/28/08, Santi Béjar <santi@agolina.net> wrote:
>> On Sun, Sep 28, 2008 at 2:05 PM, Leo Razoumov <slonik.az@gmail.com> wrote:
>> > Hi All,
>> > I am using the latest stable version git-1.6.0.2.
>> >
>> > The man page for git-clone states explicitly that "git clone"
>> >
>> > " Clones a repository into a newly created directory, ...[snip]...
>> > and creates and checks out an initial branch equal to the
>> > cloned repository's currently active branch. "
>> >
>> > I noticed that while my active branch "My" happens to point to the
>> > same commit as the "master" the git clone will check out master
>> > instead of My (currently active branch). Is it a bug?
>> >
>>
>>
>> Currently it is only guessed which is the active branch (with a
>> preference for the master branch as it is the default), as the current
>> protocol does not allow transferring the ref links:
>
> This is quite unfortunate design decision.
This is not a design decision, git has evolved, not designed. The ref
links are younger than the transfer protocols.
> There can be any number of
> local branches referring to the same commit. Without being able to
> pick into .git/HEAD it is impossible to decide which of them is
> "active".
I'm sure patches are welcome.
>
> --Leo--
>
^ permalink raw reply
* Re: [PATCH 7/8] Docs: send-email: Added all config variables to man end
From: Jeff King @ 2008-09-28 19:08 UTC (permalink / raw)
To: Michael Witten; +Cc: gitster, git
In-Reply-To: <C886DB88-EA48-4608-A9DB-B8A11C1240B2@MIT.EDU>
On Sun, Sep 28, 2008 at 02:03:42PM -0500, Michael Witten wrote:
>> Maybe it is better to simply make a note of that (or
>> mention it in the --foo section).
>
> Then it would be better to do away with all but
>
> sendemail.aliasesfile
> sendemail.aliasfile
>
> which sounds OK with me.
Yes, that was exactly what I meant (but I hadn't bothered to see how
many, if any, options didn't directly correspond to a command line
option).
-Peff
^ permalink raw reply
* Re: [PATCH 8/8] Docs: config: send-email config options included
From: Jeff King @ 2008-09-28 19:06 UTC (permalink / raw)
To: Michael Witten; +Cc: gitster, git
In-Reply-To: <C0DC4F74-6157-44AE-A25A-4C74A415CDDA@mit.edu>
On Sun, Sep 28, 2008 at 02:03:59PM -0500, Michael Witten wrote:
>> Note that this list is non-comprehensive and not necessarily complete.
>> For command-specific variables, you will find a more detailed
>> description
>> in the appropriate manual page. You will find a description of non-core
>> porcelain configuration variables in the respective porcelain
>> documentation.
>
> I think config.txt is not the place to put this stuff (though I've only
> given it a quick glance), and include:: will just cause us to litter
> the place with tool-config.txt include files, which looks yucky and is
> subject to neglect.
Ah, I hadn't read that before. So yes, I agree that it should go into
git-send-email.txt. I do think putting a note (similar to the one for
imap.*) into config.txt would be a nice addition, but it is obviously
independent of your other changes.
-Peff
^ permalink raw reply
* Re: [PATCH 1/8] Docs: send-email's usage text and man page mention same options
From: Michael Witten @ 2008-09-28 19:04 UTC (permalink / raw)
To: Miklos Vajna; +Cc: gitster, git
In-Reply-To: <20080928050828.GZ23137@genesis.frugalware.org>
On 28 Sep 2008, at 12:08 AM, Miklos Vajna wrote:
> On Sat, Sep 27, 2008 at 08:09:49PM -0500, Michael Witten <mfwitten@MIT.EDU
> > wrote:
>> Specifically, boolean options are now listed in the form
>>
>> --[no-]option
>>
>> and both forms of documentation now consistently use
>>
>> --[no-]signed-off-by-cc
>
> I don't think documenting --no-foo in the perl script itself is a good
> idea. See c3170a8 (git-merge: exclude unnecessary options from
> OPTIONS_SPEC, 2008-05-12) which removes --no-foo from git-merge as
> well.
>
> Of course the man page part makes sense.
I like that it's in the help usage text, because it makes it clear how
it should be used.
Besides, I basically removed the same kind of cruft that was removed
with c3170a8, but I still managed to include the same information.
^ permalink raw reply
* Re: [PATCH 8/8] Docs: config: send-email config options included
From: Michael Witten @ 2008-09-28 19:03 UTC (permalink / raw)
To: Jeff King; +Cc: gitster, git
In-Reply-To: <20080928032407.GC15696@sigill.intra.peff.net>
On 27 Sep 2008, at 10:24 PM, Jeff King wrote:
> On Sat, Sep 27, 2008 at 08:09:56PM -0500, Michael Witten wrote:
>
>> I just copied what is in the send-email man text.
>
> NAK, this makes things much worse by creating two places which must be
> updated with any changes. Shouldn't doing it the right way be as
> simple
> as something like the patch below?
I also think it is stupid, but I didn't quite understand what you
meant before (I must have been skimming).
Also, the surrounding config variable definitions didn't really make
it clear that I could (or should) include a file (I didn't even think
about it, especially given that I didn't understand your original
suggestion).
> Though it looks like imap.* simply says "See git-imap-send(1)" in
> config.txt, which would also be OK by me (and makes sense especially
> if
> we drop most of the sendemail.* description in favor of just
> mentioning
> the config option near the matching command-line option).
I agree! I think these separate config variable descriptions are
superfluous and dangerously subject to obsolescence; consider
what config.txt says:
> Note that this list is non-comprehensive and not necessarily complete.
> For command-specific variables, you will find a more detailed
> description
> in the appropriate manual page. You will find a description of non-
> core
> porcelain configuration variables in the respective porcelain
> documentation.
I think config.txt is not the place to put this stuff (though I've only
given it a quick glance), and include:: will just cause us to litter
the place with tool-config.txt include files, which looks yucky and is
subject to neglect.
^ permalink raw reply
* Re: [PATCH 3/8] Docs: send-email: Man page option ordering
From: Michael Witten @ 2008-09-28 19:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <gbne1a$8g2$1@ger.gmane.org>
On 28 Sep 2008, at 3:08 AM, Jakub Narebski wrote:
> Michael Witten wrote:
>
>> Now the man page lists the options in alphabetical
>> order (in terms of the 'main' part of an option's
>> name).
>
> I know it is a matter of taste, but I prefer having options
> on man page in functional order, grouped by function, perhaps
> with subsections to group them (c.f. git-rev-list man page).
See: http://marc.info/?l=git&m=122246885210923&w=2
^ permalink raw reply
* Re: [PATCH 7/8] Docs: send-email: Added all config variables to man end
From: Michael Witten @ 2008-09-28 19:03 UTC (permalink / raw)
To: Jeff King; +Cc: gitster, git
In-Reply-To: <20080928031822.GB15696@sigill.intra.peff.net>
On 27 Sep 2008, at 10:18 PM, Jeff King wrote:
> On Sat, Sep 27, 2008 at 08:09:55PM -0500, Michael Witten wrote:
>
>> Admittedly, I didn't take much pride in my work, but
>> I'm not trying to solve this problem.
>
> Remember that your commit message is supposed to be convincing us that
> your patch is worth applying. ;P
Well, I told the truth ;-)
> It seems like these are just mechanical "sendemail.foo is a default
> for
> --foo" additions.
They are indeed!
> Maybe it is better to simply make a note of that (or
> mention it in the --foo section).
Then it would be better to do away with all but
sendemail.aliasesfile
sendemail.aliasfile
which sounds OK with me.
^ permalink raw reply
* Re: [PATCH 6/8] Docs: Arranged config options in man page
From: Michael Witten @ 2008-09-28 19:03 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20080928031550.GA15696@sigill.intra.peff.net>
On 27 Sep 2008, at 10:15 PM, Jeff King wrote:
> On Sat, Sep 27, 2008 at 08:09:54PM -0500, Michael Witten wrote:
>
>> Signed-off-by: Michael Witten <mfwitten@mit.edu>
>> ---
>
> Arranged in what way? I assume alphabetized, but please make it clear
> in the commit message.
Fair enough; for whatever reason, I thought I had.
> Also, Junio is out of touch for a few weeks, so it probably makes
> sense
> to send your patches to Shawn Pearce <spearce@spearce.org> in the
> interim.
Indeed. I wish Junio had setup some kind of automatic reply.
> Also also, micronit: we usually use the imperative to describe patch
> changes (i.e., "arrange" instead of "arranged").
Then I shall comply.
^ permalink raw reply
* Re: [PATCH] Implement a textconv filter for "git diff"
From: Jeff King @ 2008-09-28 16:12 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq8wtc1tf7.fsf@bauges.imag.fr>
On Sun, Sep 28, 2008 at 12:00:44PM +0200, Matthieu Moy wrote:
> Hmm, why not, and the textconv could be different (like comparing
> old:foo.doc with ./foo.odt).
Exactly.
> One has to be carefull not to call textconv for plumbing commands,
> since the generated patches are not applicable, and only for the eyes
> of the reader.
Right, but that is prevented by not loading the appropriate diff driver
config, I believe (and I didn't look closely at your implementation in
that respect, but I believe it is the same as mine, because both
porcelain and plumbing use the code in diff.c).
-Peff
^ permalink raw reply
* Re: Implementation of a "textconv" filter for easy custom diff.
From: Jeff King @ 2008-09-28 16:11 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqd4io1tla.fsf@bauges.imag.fr>
On Sun, Sep 28, 2008 at 11:57:05AM +0200, Matthieu Moy wrote:
> > Neat. I started on something like this quite a while ago,
>
> Did you publish/send it anywhere?
No, I was waiting to clean it up and test it a bit more.
> Well, OTOH, one could argue that "blame" is based on diff-ing, and
> therefore it's natural to define a diff filter to tell how "blame"
> should work.
Yes, I would have made that argument. ;)
> > [diff "foo"]
> > xfuncname = "some regex"
> > binary = auto
>
> No sure that would actually be useful in real life, but it doesn't
> harm to have it. And the argument "better path forward for defining
> sets of diff tweaks" is a good one IMO.
Yes, I think currently most diff options supersede the decision about
whether or not it's binary (like textconv, in which you probably assume
the result is diff-able as text). xfuncname doesn't, but the example is
perhaps a bit contrived. So I do think of it as more of a way for future
expansion.
I seem to recall actually running into this as part of the textconv work
I was doing, but now I can't remember the exact details. So that's not
that compelling an argumen.t :)
-Peff
^ permalink raw reply
* Re: having to pull twice
From: Thomas Rast @ 2008-09-28 15:26 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Shawn O. Pearce, Michael P. Soulier, git
In-Reply-To: <20080928151135.GF23137@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
Miklos Vajna wrote:
>
> Oh, the racy git problem. ;-)
>
> $ git reset --hard; touch foo; git merge side
IIUC, this is not the same as "racy git". The racy case is if you
manage to get a file changed immediately after its index entry was
updated, so that it will look unchanged. In this case, it's simply
the same file with a new mtime, which means it looks changed
superficially but still has the same contents.
Granted, you could call my test "racy" because it relies on 'make
install' taking at least one second, which by Moore's law should
happen sometime around 2019 ;-)
> Thanks for the reproducer, I'll write a proper testcase for this and try to
> provide a fix for it as well.
Thanks.
- Thomas
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: mysterious error message
From: tom sgouros @ 2008-09-28 15:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
In-Reply-To: <20080926143726.GZ3669@spearce.org>
I have upgraded and the problem has disappeared. Many thanks for the
advice.
-tom
Shawn O. Pearce <spearce@spearce.org> wrote:
> tom sgouros <tomfool@as220.org> wrote:
> > > On Thu, 25 Sep 2008, Tom Sgouros wrote:
> > > > I receive the following error message when I try to do a 'git push':
> > > >
> > > > tomfool@toms-box:hpl$ git push
> > > > updating 'refs/heads/master'
> > > > from ad4ae7925d3dd23798e7c5b733d2d8f930f7410f
> > > > to 5b5f5fae014a4f3535fa10b0f6e28b4bf3225dc3
> > > > Also local refs/remotes/origin/master
> > > > Generating pack...
> > > > Done counting 10 objects.
> > > > Deltifying 10 objects...
> > > > error: pack-objects died with strange error
> > > > unpack eof before pack header was fully read
> > > > ng refs/heads/master n/a (unpacker error)
> > > > error: failed to push to 'ssh://tomfool@as220.org/home/tomfool/hpl.git'
> > > > tomfool@toms-box:hpl$
> > >
> > > I got this message when I tried to push a project with submodules to a
> > > server which had submodule-ignorant git installed. Maybe it's that?
> >
> > I'm not sure which versions are submodule-ignorant, but it's version
> > 1.5.3.6 on the pusher and version 1.5.4.5 on the server. I installed
> > git via the fink package manager. Could there be some other
> > incompatibility?
>
> This change came after 1.5.3.6 and I think its what you are
> tripping over:
>
> commit 481f0ee60eef2c34b891e5d04b7e6e5a955eedf4
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Sun Nov 11 23:35:23 2007 +0000
>
> Fix rev-list when showing objects involving submodules
>
> rev-list aborting because it cannot mark a submodule commit
> as uninteresting should cause pack-objects to abort too since
> the list of objects wasn't completely produced.
>
> That fix is in 1.5.3.7 or later.
>
> --
> Shawn.
>
--
------------------------
tomfool at as220 dot org
http://sgouros.com
http://whatcheer.net
^ permalink raw reply
* [PATCH] doc: enhance git describe --tags help
From: Pierre Habouzit @ 2008-09-28 15:12 UTC (permalink / raw)
To: Erez Zilber; +Cc: git@vger.kernel.org, open-iscsi, spearce, Junio C Hamano
In-Reply-To: <20080928150318.GI5302@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 714 bytes --]
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Documentation/git-describe.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index c4dbc2a..9cc8c2f 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -30,7 +30,8 @@ OPTIONS
--tags::
Instead of using only the annotated tags, use any tag
- found in `.git/refs/tags`.
+ found in `.git/refs/tags`. Though if an annotated tag is found in the
+ ancestry, it will always be preferred to lightweight tags.
--contains::
Instead of finding the tag that predates the commit, find
--
1.6.0.2.516.g12936.dirty
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: having to pull twice
From: Miklos Vajna @ 2008-09-28 15:11 UTC (permalink / raw)
To: Thomas Rast; +Cc: Shawn O. Pearce, Michael P. Soulier, git
In-Reply-To: <200809271616.32082.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 959 bytes --]
On Sat, Sep 27, 2008 at 04:16:29PM +0200, Thomas Rast <trast@student.ethz.ch> wrote:
> * Setup:
>
> mkdir $temp_repo
> cd $temp_repo
> git init
> echo foo > foo
> git add foo
> git commit -m initial
> echo a > foo
> git commit -m a foo
> git checkout -b side HEAD^
> echo b > foo
> git commit -m b foo
> git checkout master
Oh, the racy git problem. ;-)
$ git reset --hard; touch foo; git merge side
HEAD is now at 5bafc63 a
Auto-merging foo
CONFLICT (content): Merge conflict in foo
Automatic merge failed; fix conflicts and then commit the result.
$ git reset --hard; sleep 1; touch foo;git merge side
HEAD is now at 5bafc63 a
error: Entry 'foo' not uptodate. Cannot merge.
fatal: merging of trees 86de5e13286a8449a8a706a58e63be6781770b12 and 9ee610433fb8854e497d62c648a612b5deb090cf failed
Thanks for the reproducer, I'll write a proper testcase for this and try to
provide a fix for it as well.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-describe doesn't show the most recent tag
From: Erez Zilber @ 2008-09-28 15:05 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git@vger.kernel.org, open-iscsi
In-Reply-To: <20080928143949.GH5302@artemis.corp>
On Sun, Sep 28, 2008 at 5:39 PM, Pierre Habouzit <madcoder@debian.org> wrote:
> On Sun, Sep 28, 2008 at 02:29:21PM +0000, Erez Zilber wrote:
>> On Sun, Sep 28, 2008 at 4:55 PM, Pierre Habouzit <madcoder@debian.org> wrote:
>> > On Sun, Sep 28, 2008 at 01:48:42PM +0000, Erez Zilber wrote:
>> >> Why is this happening?
>> >
>> > --tags
>> > Instead of using only the annotated tags, use any tag found in
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > .git/refs/tags.
>> >
>>
>> I'm not sure that I understand the difference between tags and annotated tags.
>
> a lightweight tag is just a reference. an annotated tag has a message
> associated. Usually tags are meant as local help, whereas annotated tags
> are the ones pushed to the repositories and that never change. That's
> why many tools ignore non annotated tags by default unless you pass
> --tags to them.
Thanks for the explanation.
>
>> Anyway, if I move to the master branch, I see the following tags:
>>
>> [erez.zilber@erez-lx:/tmp/open-iscsi.git]$ ls .git/refs/tags/
>> 2.0-868-rc1 2.0-869 2.0-869.1 2.0-869.2 2.0-869-rc2 2.0-869-rc3
>> 2.0-869-rc4 2.0-870-rc1
>> [erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-tag
>> 2.0-868-rc1
>> 2.0-869
>> 2.0-869-rc2
>> 2.0-869-rc3
>> 2.0-869-rc4
>> 2.0-869.1
>> 2.0-869.2
>> 2.0-870-rc1
>>
>> However:
>> [erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-describe --tags
>> 2.0-868-rc1-81-g31c9d42
>>
>> I was expecting to see 2.0-870-rc1 here.
>
> That's because master is not at -rc1 exactly, but some commits
> afterwards. Please read the git-describe manpage fully, it's _really_
> well explained:
>
> The command finds the most recent tag that is reachable from a commit.
> If the tag points to the commit, then only the tag is shown. Otherwise,
> it suffixes the tag name with the number of additional commits on top
> of the tagged object and the abbreviated object name of the most recent
> commit.
>
>
> Which means that your master is 81 commits ahead of the exact 2.0-860-rc1 tag,
> at sha1 31c9d42
I read that, but I still don't understand what happens in the open-iscsi tree:
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ cat .git/refs/tags/2.0-870-rc1
5e80c8167c112687ae7b30b1e40af6f03088c56c
The head is 12 commits from the 2.0-870-rc1 tag. Therefore, I expected
to see something like 2.0-870-rc1-12-some_hash (not
2.0-868-rc1-81-g31c9d42).
Erez
^ permalink raw reply
* Re: git-describe doesn't show the most recent tag
From: Pierre Habouzit @ 2008-09-28 15:03 UTC (permalink / raw)
To: Erez Zilber; +Cc: git@vger.kernel.org, open-iscsi
In-Reply-To: <20080928143949.GH5302@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]
On Sun, Sep 28, 2008 at 02:39:49PM +0000, Pierre Habouzit wrote:
> On Sun, Sep 28, 2008 at 02:29:21PM +0000, Erez Zilber wrote:
> > On Sun, Sep 28, 2008 at 4:55 PM, Pierre Habouzit <madcoder@debian.org> wrote:
> > > On Sun, Sep 28, 2008 at 01:48:42PM +0000, Erez Zilber wrote:
> > >> Why is this happening?
> > >
> > > --tags
> > > Instead of using only the annotated tags, use any tag found in
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > .git/refs/tags.
> > >
> >
> > I'm not sure that I understand the difference between tags and annotated tags.
>
> a lightweight tag is just a reference. an annotated tag has a message
> associated. Usually tags are meant as local help, whereas annotated tags
> are the ones pushed to the repositories and that never change. That's
> why many tools ignore non annotated tags by default unless you pass
> --tags to them.
>
> > Anyway, if I move to the master branch, I see the following tags:
> >
> > [erez.zilber@erez-lx:/tmp/open-iscsi.git]$ ls .git/refs/tags/
> > 2.0-868-rc1 2.0-869 2.0-869.1 2.0-869.2 2.0-869-rc2 2.0-869-rc3
> > 2.0-869-rc4 2.0-870-rc1
> > [erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-tag
> > 2.0-868-rc1
> > 2.0-869
> > 2.0-869-rc2
> > 2.0-869-rc3
> > 2.0-869-rc4
> > 2.0-869.1
> > 2.0-869.2
> > 2.0-870-rc1
> >
> > However:
> > [erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-describe --tags
> > 2.0-868-rc1-81-g31c9d42
> >
> > I was expecting to see 2.0-870-rc1 here.
Scratch my previous answer, I was confused with too many digits (868
vs 870). In fact looking at the code, if there is an annotated tag in
the ancestry, git describe will always prefer it to lightweight tags.
the problem with lightweight tags is that they are meant to be moved,
hence are not really something you want to base on to chose a uuid
(which git-describe generates).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-describe doesn't show the most recent tag
From: Andreas Ericsson @ 2008-09-28 14:51 UTC (permalink / raw)
To: Erez Zilber; +Cc: Pierre Habouzit, git@vger.kernel.org, open-iscsi
In-Reply-To: <ce513bcc0809280729p47cc3790nb77b3cae8b805221@mail.gmail.com>
Erez Zilber wrote:
> On Sun, Sep 28, 2008 at 4:55 PM, Pierre Habouzit <madcoder@debian.org> wrote:
>> On Sun, Sep 28, 2008 at 01:48:42PM +0000, Erez Zilber wrote:
>>> Why is this happening?
>> --tags
>> Instead of using only the annotated tags, use any tag found in
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> .git/refs/tags.
>>
>
> I'm not sure that I understand the difference between tags and annotated tags.
>
An annotated tag is one created with "git tag -a" or "git tag -s".
Other tags are considered "lightweight". They are supported for
creating immutable quick-and-dirty savepoints for private use,
while published tags are supposed to be annotated to give them
some extra weight.
You can use lightweight tags like normal tags (ie, and publish
them), but then some assumptions in git will not be correct and
you need to tell it so.
Btw, the default update hook prevents lightweight (unannotated)
tags from entering a repository you're pushing to, so this
assumption is not something that's unique to just "describe".
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-describe doesn't show the most recent tag
From: Pierre Habouzit @ 2008-09-28 14:39 UTC (permalink / raw)
To: Erez Zilber; +Cc: git@vger.kernel.org, open-iscsi
In-Reply-To: <ce513bcc0809280729p47cc3790nb77b3cae8b805221@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]
On Sun, Sep 28, 2008 at 02:29:21PM +0000, Erez Zilber wrote:
> On Sun, Sep 28, 2008 at 4:55 PM, Pierre Habouzit <madcoder@debian.org> wrote:
> > On Sun, Sep 28, 2008 at 01:48:42PM +0000, Erez Zilber wrote:
> >> Why is this happening?
> >
> > --tags
> > Instead of using only the annotated tags, use any tag found in
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > .git/refs/tags.
> >
>
> I'm not sure that I understand the difference between tags and annotated tags.
a lightweight tag is just a reference. an annotated tag has a message
associated. Usually tags are meant as local help, whereas annotated tags
are the ones pushed to the repositories and that never change. That's
why many tools ignore non annotated tags by default unless you pass
--tags to them.
> Anyway, if I move to the master branch, I see the following tags:
>
> [erez.zilber@erez-lx:/tmp/open-iscsi.git]$ ls .git/refs/tags/
> 2.0-868-rc1 2.0-869 2.0-869.1 2.0-869.2 2.0-869-rc2 2.0-869-rc3
> 2.0-869-rc4 2.0-870-rc1
> [erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-tag
> 2.0-868-rc1
> 2.0-869
> 2.0-869-rc2
> 2.0-869-rc3
> 2.0-869-rc4
> 2.0-869.1
> 2.0-869.2
> 2.0-870-rc1
>
> However:
> [erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-describe --tags
> 2.0-868-rc1-81-g31c9d42
>
> I was expecting to see 2.0-870-rc1 here.
That's because master is not at -rc1 exactly, but some commits
afterwards. Please read the git-describe manpage fully, it's _really_
well explained:
The command finds the most recent tag that is reachable from a commit.
If the tag points to the commit, then only the tag is shown. Otherwise,
it suffixes the tag name with the number of additional commits on top
of the tagged object and the abbreviated object name of the most recent
commit.
Which means that your master is 81 commits ahead of the exact 2.0-860-rc1 tag,
at sha1 31c9d42
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-describe doesn't show the most recent tag
From: Erez Zilber @ 2008-09-28 14:29 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git@vger.kernel.org, open-iscsi
In-Reply-To: <20080928135526.GG5302@artemis.corp>
On Sun, Sep 28, 2008 at 4:55 PM, Pierre Habouzit <madcoder@debian.org> wrote:
> On Sun, Sep 28, 2008 at 01:48:42PM +0000, Erez Zilber wrote:
>> Why is this happening?
>
> --tags
> Instead of using only the annotated tags, use any tag found in
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> .git/refs/tags.
>
I'm not sure that I understand the difference between tags and annotated tags.
Anyway, if I move to the master branch, I see the following tags:
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ ls .git/refs/tags/
2.0-868-rc1 2.0-869 2.0-869.1 2.0-869.2 2.0-869-rc2 2.0-869-rc3
2.0-869-rc4 2.0-870-rc1
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-tag
2.0-868-rc1
2.0-869
2.0-869-rc2
2.0-869-rc3
2.0-869-rc4
2.0-869.1
2.0-869.2
2.0-870-rc1
However:
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-describe --tags
2.0-868-rc1-81-g31c9d42
I was expecting to see 2.0-870-rc1 here.
Erez
^ 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