* [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
* Re: git-describe doesn't show the most recent tag
From: Pierre Habouzit @ 2008-09-28 13:55 UTC (permalink / raw)
To: Erez Zilber; +Cc: git@vger.kernel.org, open-iscsi
In-Reply-To: <ce513bcc0809280648s352cda3fj5eb35b6e9cd40af9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
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.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git-describe doesn't show the most recent tag
From: Erez Zilber @ 2008-09-28 13:48 UTC (permalink / raw)
To: git-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw
Hi,
I'm trying to run git-describe on the open-iscsi git tree
(git://git.kernel.org/pub/scm/linux/kernel/git/mnc/open-iscsi.git):
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-branch -a
* master
origin/2.0-869-bugfix
origin/HEAD
origin/bnx2i
origin/cxgb3i
origin/master
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-describe
2.0-868-rc1-81-g31c9d42
However, there are newer tags than 2.0-868-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
>From what I see in the man page "git-describe - Show the most recent
tag that is reachable from a commit". In this repository, it doesn't
look like that...
Now, I switch to the "2.0-869-bugfix" branch:
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-checkout -b
2.0-869-bugfix origin/2.0-869-bugfix
Branch 2.0-869-bugfix set up to track remote branch
refs/remotes/origin/2.0-869-bugfix.
Switched to a new branch "2.0-869-bugfix"
and running again git-describe:
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-describe
2.0-868-rc1-33-g81133dd
Only if I use the --tags flag, I get what I expected:
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-describe --tags
2.0-869.2
Why is this happening?
Thanks,
Erez
^ permalink raw reply
* Re: strange "git clone" behavior wrt an active branch
From: Leo Razoumov @ 2008-09-28 13:23 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <adf1fd3d0809280537k7adffe3dte9579fe70c7f990e@mail.gmail.com>
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 tranfering the ref links:
This is quite unfortunate design decision. 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".
--Leo--
^ permalink raw reply
* Re: small warm-up: easy parse-opt migrations.
From: Sverre Rabbelier @ 2008-09-28 13:20 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, spearce, gitster
In-Reply-To: <1222595139-32087-1-git-send-email-madcoder@debian.org>
On Sun, Sep 28, 2008 at 11:45, Pierre Habouzit <madcoder@debian.org> wrote:
> There's not a lot to tell, those are just three migration to
> parse-options.
I think you forgot the -n switch to git format-patch, yes?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] bash completion: Add --[no-]-validate to "git send-email"
From: Teemu Likonen @ 2008-09-28 12:55 UTC (permalink / raw)
To: Michael Witten; +Cc: gitster, git, spearce
In-Reply-To: <20080928045121.GA3208@mithlond.arda.local>
Teemu Likonen wrote (2008-09-28 07:51 +0300):
> Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
> ---
>
> If your patch is to be applied let's also add the options to bash
> completion.
One extra hyphen in the subject of my commit message. This is better:
bash completion: Add --[no-]validate to "git send-email"
^ permalink raw reply
* Re: strange "git clone" behavior wrt an active branch
From: Santi Béjar @ 2008-09-28 12:37 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Git Mailing List
In-Reply-To: <ee2a733e0809280505n69f62e0fy89667c175bcc16c@mail.gmail.com>
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 tranfering the ref links:
$ git ls-remote $url
$sha1 HEAD
$sha1 $branchname
...
instead of:
ref: refs/heads/master HEAD
$sha1 $branchname
...
So, I think it is a current limitation that maybe should be documented.
HTH,
Santi
^ permalink raw reply
* Re: [PATCH] Document the textconv filter.
From: Matthieu Moy @ 2008-09-28 12:29 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200809281307.21409.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Sonntag, 28. September 2008, Matthieu Moy wrote:
>> +Converting files to text before a diff
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +The attribute `textconv` affects 'git diff' in a way similar to the
>> +`diff` attribute, but with `textconv`, the user provides only a way to
>> +convert the file into text, and git takes care of doing the diff as
>> +usual (i.e. other options of 'git diff' such as '--color' remain
>> +available).
>> +
>> +The value of `textconv` must be a string, which is the textconv
>> +driver.
>
> Wouldn't it be much more useful to have git parse stdout of the custom diff
> tool in order to colorize it?
That would do it for --color, but not --color-words for example. The
problem with the GIT_EXTERNAL_DIFF is that the diff tool has to
re-implement everything that "git diff" already do.
Take my opendocument diff script :
http://www-verimag.imag.fr/~moy/opendocument/git-oodiff
That's 77 lines of code as a wrapper to odt2txt and diff. With the
"textconv" attribute, it's one line in .gitattributes, and two in
~/.gitconfig.
> Of course, this would mean that external diff tools are more
> complicated and their stdout has to conform mostly to the git diff
> syntax. But:
>
>> +To tell git to use the `exif` filter for jpeg images, use:
>> +
>> +----------------------------------------------------------------
>> +*.jpg textconv=exif
>> +----------------------------------------------------------------
>
> In this very example it would be possible that the external diff driver shows
> the differences in the image in a window and also produces EXIF information
> on stdout.
Yes, but that's really a specific example. Having git colorize the
diff would be a little extra, but that wouldn't reduce the effort to
write the external diff tool itself, and doesn't give you _all_ of
git-diff, just --color.
--
Matthieu
^ permalink raw reply
* Re: [PATCH 01/14] Extend index to save more flags
From: Nguyen Thai Ngoc Duy @ 2008-09-28 12:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200809281359.46858.jnareb@gmail.com>
On 9/28/08, Jakub Narebski <jnareb@gmail.com> wrote:
> So now there is:
>
> Now CE_EXTENDED_FLAGS & 0x803FFFFF is bad because:
> * CE_EXTENDED_FLAGS & 0x0000FFFF are saved flags (not extended)
>
> * CE_EXTENDED_FLAGS & 0x003F0000 are in-memory flags
>
> * CE_EXTENDED_FLAGS & 0x80000000 is 'extra flags' bit
> (this is not mentioned in quoted comment; I'm not sure if
> it needs to be or not)
>
> Is that correct?
Correct.
--
Duy
^ permalink raw reply
* strange "git clone" behavior wrt an active branch
From: Leo Razoumov @ 2008-09-28 12:05 UTC (permalink / raw)
To: Git Mailing List
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?
Here is the example that demontrates the problem
~> mkdir tmp
~/tmp> git init
~/tmp> cat > txt
some text
~/tmp> git add .
~/tmp> git ci -m 'init ci'
~/tmp> git branch -a
* master
~/tmp> git co -b My
~/tmp> git branch -a
* My
master
Now "My" is my active branch in 'tmp' repo. It points to the same
commit as the master. Now let us clone it
~/tmp> cd ..
~> git clone tmp tmp1
~> cd tmp1
~/tmp1> git branch -a
* master
origin/HEAD
origin/My
origin/master
In the cloned repository 'tmp1', master branch is active. No local
tracking branch for "My" was created. I think this behavior
contradicts the man page. Is it a bug or feature??
Thanks,
--Leo--
^ permalink raw reply
* Re: [PATCH 01/14] Extend index to save more flags
From: Jakub Narebski @ 2008-09-28 11:59 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <48d723bf90941_5de93fcd2ee870984625e@app02.zenbe.com.tmail>
On Mon, 22 Sep 2008, Duy Nguyen wrote:
> On 09/22/2008 "Jakub Narebski" <jnareb@gmail.com> wrote:
>>On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote:
>>> On 9/21/08, Jakub Narebski <jnareb@gmail.com> wrote:
>>>>> +
>>>>> +#define CE_EXTENDED_FLAGS (0)
>>>>> +
>>>>> +/*
>>>>> + * Safeguard to avoid saving wrong flags:
>>>>> + * - CE_EXTENDED2 won't get saved until its semantic is known
>>>>> + * - Bits in 0x0000FFFF have been saved in ce_flags already
>>>>> + * - Bits in 0x003F0000 are currently in-memory flags
>>>>> + */
>>>>> +#if CE_EXTENDED_FLAGS & 0x80CFFFFF
>>>>> +#error "CE_EXTENDED_FLAGS out of range"
>>>>> +#endif
>>>>
>>>>
>>>> I don't quite understand the above fragment (especially with the fact
>>>> that CE_EXTENDED_FLAGS is defined as (0))...
>>>
>>> Because this patch does not introduce any new on-disk flag yet so
>>> CE_EXTENDED_FLAGS remains 0. In the next patch, CE_EXTENDED_FLAGS will
>>> be updated to have CE_NO_CHECKOUT.
>>
>> Well, now I understand CE_EXTENDED_FLAGS being (0).
>>
>> What I still don't understand the pattern it is protected against.
>> As I understand it if CE_EXTENDED_FLAGS & 0x0000FFFF it is bad,
>> because ce_flags saved flags are not extended flags, and
>> CE_EXTENDED_FLAGS & 0x003F0000 are in-memory flags. But why
>> CE_EXTENDED_FLAGS & 0x80C00000 is bad, and why (if I understand it)
>> CE_EXTENDED_FLAGS & 0x00300000 is not bad.
>
> Wrong bit computation, should be "#if CE_EXTENDED_FLAGS & 0x803FFFFF".
> Thanks for pointing out.
So now there is:
Now CE_EXTENDED_FLAGS & 0x803FFFFF is bad because:
* CE_EXTENDED_FLAGS & 0x0000FFFF are saved flags (not extended)
* CE_EXTENDED_FLAGS & 0x003F0000 are in-memory flags
* CE_EXTENDED_FLAGS & 0x80000000 is 'extra flags' bit
(this is not mentioned in quoted comment; I'm not sure if
it needs to be or not)
Is that correct?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Document the textconv filter.
From: Johannes Sixt @ 2008-09-28 11:07 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1222567618-22156-5-git-send-email-Matthieu.Moy@imag.fr>
On Sonntag, 28. September 2008, Matthieu Moy wrote:
> +Converting files to text before a diff
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +The attribute `textconv` affects 'git diff' in a way similar to the
> +`diff` attribute, but with `textconv`, the user provides only a way to
> +convert the file into text, and git takes care of doing the diff as
> +usual (i.e. other options of 'git diff' such as '--color' remain
> +available).
> +
> +The value of `textconv` must be a string, which is the textconv
> +driver.
Wouldn't it be much more useful to have git parse stdout of the custom diff
tool in order to colorize it? Of course, this would mean that external diff
tools are more complicated and their stdout has to conform mostly to the git
diff syntax. But:
> +To tell git to use the `exif` filter for jpeg images, use:
> +
> +----------------------------------------------------------------
> +*.jpg textconv=exif
> +----------------------------------------------------------------
In this very example it would be possible that the external diff driver shows
the differences in the image in a window and also produces EXIF information
on stdout.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Implement a textconv filter for "git diff"
From: Matthieu Moy @ 2008-09-28 10:00 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080928041526.GB24214@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Sep 28, 2008 at 04:06:56AM +0200, Matthieu Moy wrote:
>
>> +static int textconv_two_files(const char *textconv,
>> + const char *name_a,
>> + const char *name_b,
>> + mmfile_t *mf1,
>> + mmfile_t *mf2,
>> + struct diff_filespec *one,
>> + struct diff_filespec *two)
>> +{
>
> Must we always be textconv'ing two files? What if I am comparing
> "v1.5:foo.odf" to "foo.txt" in the working tree?
Hmm, why not, and the textconv could be different (like comparing
old:foo.doc with ./foo.odt).
> In my implementation, I textconv one at a time. I just did so from
> fill_mmfile, so all of diff automagically just sees the converted text.
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.
--
Matthieu
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2008-09-28 10:01 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
In-Reply-To: <200809251230.11342.jnareb@gmail.com>
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.
* 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.
* 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...
* Support for generating bundles, and not only snapshots, either
depth=1 bundles, or diff bundles (snapshot for diff is bundle).
* Support for i18n (translating gitweb), best using 'gettext' which
the rest of git (gitk and git-gui) uses (use Locale::TextDomain,
or Locale::Maketext?).
* Possibly: fallback to "user.name <user.email>" for repository owner
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Implementation of a "textconv" filter for easy custom diff.
From: Matthieu Moy @ 2008-09-28 9:57 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080928041040.GA24214@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Neat. I started on something like this quite a while ago,
Did you publish/send it anywhere?
> We have one major difference in our approaches. In yours, there is a
> new "textconv" attribute that can be used. In mine, I subtly changed the
> meaning of the "diff=foo" attribute to be "use the diff driver named by
> diff.foo.*", and you would set diff.foo.textconv to your command. This
> is a bit simpler to implement, and it provides a better path forward for
> defining sets of diff tweaks.
Yes, that's an interesting approach too.
One point in favor of mine is that the "textconv" thing is no
necessarily limited to diff-ing. That would be really cool to have
"blame" use it too for example (with quite bad performance, but that
would be the first time I see a tool able to do this).
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.
> For example, one of the limitations of the current syntax is that you
> can't say "Choose automatically whether this is binary or text, but if
> it is text, use this hunk header." But with my scheme it is easy to do:
>
> in attributes:
> file diff=foo
>
> in config:
> [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.
--
Matthieu
^ permalink raw reply
* [PATCH] parse-opt: migrate git-merge-base.
From: Pierre Habouzit @ 2008-09-28 9:45 UTC (permalink / raw)
To: git; +Cc: spearce, gitster, Pierre Habouzit
In-Reply-To: <1222595139-32087-2-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
builtin-merge-base.c | 37 ++++++++++++++++---------------------
1 files changed, 16 insertions(+), 21 deletions(-)
diff --git a/builtin-merge-base.c b/builtin-merge-base.c
index b08da51..03fc1c2 100644
--- a/builtin-merge-base.c
+++ b/builtin-merge-base.c
@@ -1,6 +1,7 @@
#include "builtin.h"
#include "cache.h"
#include "commit.h"
+#include "parse-options.h"
static int show_merge_base(struct commit **rev, int rev_nr, int show_all)
{
@@ -21,8 +22,10 @@ static int show_merge_base(struct commit **rev, int rev_nr, int show_all)
return 0;
}
-static const char merge_base_usage[] =
-"git merge-base [--all] <commit-id> <commit-id>...";
+static const char * const merge_base_usage[] = {
+ "git merge-base [--all] <commit-id> <commit-id>...",
+ NULL
+};
static struct commit *get_commit_reference(const char *arg)
{
@@ -44,25 +47,17 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
int rev_nr = 0;
int show_all = 0;
- git_config(git_default_config, NULL);
-
- while (1 < argc && argv[1][0] == '-') {
- const char *arg = argv[1];
- if (!strcmp(arg, "-a") || !strcmp(arg, "--all"))
- show_all = 1;
- else
- usage(merge_base_usage);
- argc--; argv++;
- }
- if (argc < 3)
- usage(merge_base_usage);
-
- rev = xmalloc((argc - 1) * sizeof(*rev));
-
- do {
- rev[rev_nr++] = get_commit_reference(argv[1]);
- argc--; argv++;
- } while (argc > 1);
+ struct option options[] = {
+ OPT_BOOLEAN('a', "all", &show_all, "outputs all common ancestors"),
+ OPT_END()
+ };
+ git_config(git_default_config, NULL);
+ argc = parse_options(argc, argv, options, merge_base_usage, 0);
+ if (argc < 2)
+ usage_with_options(merge_base_usage, options);
+ rev = xmalloc(argc * sizeof(*rev));
+ while (argc-- > 0)
+ rev[rev_nr++] = get_commit_reference(*argv++);
return show_merge_base(rev, rev_nr, show_all);
}
--
1.6.0.2.516.g12936
^ permalink raw reply related
* [PATCH] parse-opt: migrate fmt-merge-msg.
From: Pierre Habouzit @ 2008-09-28 9:45 UTC (permalink / raw)
To: git; +Cc: spearce, gitster, Pierre Habouzit
In-Reply-To: <1222595139-32087-1-git-send-email-madcoder@debian.org>
Also fix an inefficient printf("%s", ...) where we can use write_in_full.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
builtin-fmt-merge-msg.c | 50 +++++++++++++++++++++-------------------------
1 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index a1879f1..654d996 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -5,8 +5,10 @@
#include "revision.h"
#include "tag.h"
-static const char *fmt_merge_msg_usage =
- "git fmt-merge-msg [--log] [--no-log] [--file <file>]";
+static const char * const fmt_merge_msg_usage[] = {
+ "git fmt-merge-msg [--log|--no-log] [--file <file>]",
+ NULL
+};
static int merge_log;
@@ -342,37 +344,31 @@ int fmt_merge_msg(int merge_log, struct strbuf *in, struct strbuf *out) {
int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
{
+ const char *inpath = NULL;
+ struct option options[] = {
+ OPT_BOOLEAN(0, "log", &merge_log, "populate log with the shortlog"),
+ OPT_STRING('F', "file", &inpath, "file", "file to read from"),
+ OPT_END()
+ };
+
FILE *in = stdin;
struct strbuf input, output;
int ret;
git_config(fmt_merge_msg_config, NULL);
-
- while (argc > 1) {
- if (!strcmp(argv[1], "--log"))
- merge_log = 1;
- else if (!strcmp(argv[1], "--no-log"))
- merge_log = 0;
- else if (!strcmp(argv[1], "-F") || !strcmp(argv[1], "--file")) {
- if (argc < 3)
- die ("Which file?");
- if (!strcmp(argv[2], "-"))
- in = stdin;
- else {
- fclose(in);
- in = fopen(argv[2], "r");
- if (!in)
- die("cannot open %s", argv[2]);
- }
- argc--; argv++;
- } else
- break;
- argc--; argv++;
+ argc = parse_options(argc, argv, options, fmt_merge_msg_usage, 0);
+ if (argc > 0)
+ usage_with_options(fmt_merge_msg_usage, options);
+
+ if (!inpath || strcmp(inpath, "-"))
+ in = stdin;
+ else {
+ fclose(in);
+ in = fopen(argv[2], "r");
+ if (!in)
+ die("cannot open %s", argv[2]);
}
- if (argc > 1)
- usage(fmt_merge_msg_usage);
-
strbuf_init(&input, 0);
if (strbuf_read(&input, fileno(in), 0) < 0)
die("could not read input file %s", strerror(errno));
@@ -381,6 +377,6 @@ int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
ret = fmt_merge_msg(merge_log, &input, &output);
if (ret)
return ret;
- printf("%s", output.buf);
+ write_in_full(STDOUT_FILENO, output.buf, output.len);
return 0;
}
--
1.6.0.2.516.g12936
^ permalink raw reply related
* [PATCH] parse-opt: migrate builtin-merge-file.
From: Pierre Habouzit @ 2008-09-28 9:45 UTC (permalink / raw)
To: git; +Cc: spearce, gitster, Pierre Habouzit
In-Reply-To: <1222595139-32087-3-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
builtin-merge-file.c | 68 +++++++++++++++++++++++++++----------------------
1 files changed, 37 insertions(+), 31 deletions(-)
diff --git a/builtin-merge-file.c b/builtin-merge-file.c
index 45c9853..7736fe8 100644
--- a/builtin-merge-file.c
+++ b/builtin-merge-file.c
@@ -2,21 +2,44 @@
#include "cache.h"
#include "xdiff/xdiff.h"
#include "xdiff-interface.h"
+#include "parse-options.h"
-static const char merge_file_usage[] =
-"git merge-file [-p | --stdout] [--diff3] [-q | --quiet] [-L name1 [-L orig [-L name2]]] file1 orig_file file2";
+static const char *const merge_file_usage[] = {
+ "git merge-file [options] [-L name1 [-L orig [-L name2]]] file1 orig_file file2",
+ NULL
+};
+
+static int label_cb(const struct option *opt, const char *arg, int unset)
+{
+ static int label_count = 0;
+ const char **names = (const char **)opt->value;
+
+ if (label_count >= 3)
+ return error("too many labels on the command like");
+ names[label_count++] = arg;
+ return 0;
+}
int cmd_merge_file(int argc, const char **argv, const char *prefix)
{
- const char *names[3];
+ const char *names[3] = { NULL, NULL, NULL };
mmfile_t mmfs[3];
mmbuffer_t result = {NULL, 0};
xpparam_t xpp = {XDF_NEED_MINIMAL};
int ret = 0, i = 0, to_stdout = 0;
int merge_level = XDL_MERGE_ZEALOUS_ALNUM;
- int merge_style = 0;
+ int merge_style = 0, quiet = 0;
int nongit;
+ struct option options[] = {
+ OPT_BOOLEAN('p', "stdout", &to_stdout, "send results to standard output"),
+ OPT_SET_INT(0, "diff3", &merge_style, "use a diff3 based merge", XDL_MERGE_DIFF3),
+ OPT__QUIET(&quiet),
+ OPT_CALLBACK('L', NULL, names, "name",
+ "set labels for file1/orig_file/file2", &label_cb),
+ OPT_END(),
+ };
+
prefix = setup_git_directory_gently(&nongit);
if (!nongit) {
/* Read the configuration file */
@@ -25,37 +48,20 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
merge_style = git_xmerge_style;
}
- while (argc > 4) {
- if (!strcmp(argv[1], "-L") && i < 3) {
- names[i++] = argv[2];
- argc--;
- argv++;
- } else if (!strcmp(argv[1], "-p") ||
- !strcmp(argv[1], "--stdout"))
- to_stdout = 1;
- else if (!strcmp(argv[1], "-q") ||
- !strcmp(argv[1], "--quiet"))
- freopen("/dev/null", "w", stderr);
- else if (!strcmp(argv[1], "--diff3"))
- merge_style = XDL_MERGE_DIFF3;
- else
- usage(merge_file_usage);
- argc--;
- argv++;
- }
-
- if (argc != 4)
- usage(merge_file_usage);
-
- for (; i < 3; i++)
- names[i] = argv[i + 1];
+ argc = parse_options(argc, argv, options, merge_file_usage, 0);
+ if (argc != 3)
+ usage_with_options(merge_file_usage, options);
+ if (quiet)
+ freopen("/dev/null", "w", stderr);
for (i = 0; i < 3; i++) {
- if (read_mmfile(mmfs + i, argv[i + 1]))
+ if (!names[i])
+ names[i] = argv[i];
+ if (read_mmfile(mmfs + i, argv[i]))
return -1;
if (buffer_is_binary(mmfs[i].ptr, mmfs[i].size))
return error("Cannot merge binary files: %s\n",
- argv[i + 1]);
+ argv[i]);
}
ret = xdl_merge(mmfs + 1, mmfs + 0, names[0], mmfs + 2, names[2],
@@ -65,7 +71,7 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
free(mmfs[i].ptr);
if (ret >= 0) {
- const char *filename = argv[1];
+ const char *filename = argv[0];
FILE *f = to_stdout ? stdout : fopen(filename, "wb");
if (!f)
--
1.6.0.2.516.g12936
^ permalink raw reply related
* small warm-up: easy parse-opt migrations.
From: Pierre Habouzit @ 2008-09-28 9:45 UTC (permalink / raw)
To: git; +Cc: spearce, gitster
There's not a lot to tell, those are just three migration to
parse-options.
^ 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