Re: with git 1.8.3.1 get only merged tags

[Michal Novotny]

On Thu, Sep 13, 2018 at 1:27 PM Ævar Arnfjörð Bjarmason
 wrote:
>
>
> On Tue, Sep 11 2018, Michal Novotny wrote:
>
> > I need to emulate git tag --merged with very old git 1.8.3.1. Is that
> > somehow possible?
> > I am looking for a bash function that would take what git 1.8.3.1
> > offers and return only the tags accessible from the current branch
>
> Jeff answer the question you had, but I just have one of my own: Is
> RedHat stuck on 1.8-era git in some release it's still maintaining, does
> this mean that e.g. you're still backporting security fixes to this
> 2012-era release?

Yes, that's exactly the case with RHEL-7.

clime

Re: with git 1.8.3.1 get only merged tags

[Michal Novotny]

On Tue, Sep 11, 2018 at 9:05 PM Jeff King  wrote:
>
> On Tue, Sep 11, 2018 at 12:43:15PM +0200, Michal Novotny wrote:
>
> > I need to emulate git tag --merged with very old git 1.8.3.1. Is that
> > somehow possible?
> > I am looking for a bash function that would take what git 1.8.3.1
> > offers and return only the tags accessible from the current branch
> > tip. Could you, please, give me at least a hint how this could be
> > done?
>
> This is not particularly fast, but it should work:
>
>   git for-each-ref refs/tags |
>   cut -f2 |
>   while read tag; do
> test "$(git merge-base $tag HEAD)" = \
>  "$(git rev-parse $tag^{commit})" && echo $tag
>   done

That works for me. Thank you a lot for help!

clime

>
> -Peff

with git 1.8.3.1 get only merged tags

[Michal Novotny]

Hello,

I need to emulate git tag --merged with very old git 1.8.3.1. Is that
somehow possible?
I am looking for a bash function that would take what git 1.8.3.1
offers and return only the tags accessible from the current branch
tip. Could you, please, give me at least a hint how this could be
done?

Thank you
clime

getting pull and push URLs for the current branch

[Michal Novotny]

Hello,

is there a way to get remote url  for the current branch? That is the
url that will be used when I call `git pull`. It doesn't seem to be a
particularly easy task.

Thank you!
clime

get commit ID from a tree object ID

[Michal Novotny]

Hello,

let's say I have made an annotated tag on a certain treeish:

$ git tag -a -m msg tagname HEAD:

Now, I can try to see the content of the tag:

$ git tag -v tagname
object 42a1c36553a50ceae2f75ffc4b1446c6c393eae7
type tree
tag tagname
tagger clime  1521288727 +0100

msg
error: no signature found


Can I use that object ID 42a1c36553a50ceae2f75ffc4b1446c6c393eae7 to
get back to a particular commit from which the tag was created? The
reason is that I would eventually like to checkout that commit.

Thank you
clime

Re: allow "~" to be present in a tag name

[Michal Novotny]

On Tue, Mar 13, 2018 at 11:09 AM, Ævar Arnfjörð Bjarmason
<ava...@gmail.com> wrote:
>
> On Tue, Mar 13 2018, Michal Novotny jotted:
>
>> On Tue, Mar 13, 2018 at 10:07 AM, Ævar Arnfjörð Bjarmason
>> <ava...@gmail.com> wrote:
>>>
>>> On Tue, Mar 13 2018, Michal Novotny jotted:
>>>
>>>> Hello,
>>>>
>>>> currently, if I try to create a tag that has tilde "~"  in name, an
>>>> error is raised. E.g.
>>>>
>>>> $ git tag rpkg-util-1.4~rc1
>>>> fatal: 'rpkg-util-1.4~rc1' is not a valid tag name.
>>>>
>>>> Now, actually it would be very cool if tilde was allowed in a tag name
>>>> because we would like to use it for tagging pre-releases of (not-only
>>>> rpm) packages.
>>>>
>>>> Is there some deep technical reason why tilde cannot be present in a
>>>> tag name? I tried that e.g.
>>>
>>> Yes, because a trailing tilde is part of git's rev syntax, see "man
>>> git-rev-parse", or try in any repo:
>>>
>>> git show HEAD
>>> git show HEAD~2
>>> git show HEAD^~2
>>
>> Right, reading the man pages:
>>
>> ~, e.g. master~3
>>A suffix ~ to a revision parameter means the commit
>> object that is the th generation ancestor of the named commit
>> object, following only the first
>>parents. I.e.  ~3 is equivalent to ^^^ which is
>> equivalent to ^1^1^1. See below for an illustration of the usage
>> of this form.
>>
>> Would it be acceptable to disallow only ~ ( as [0-9]+) in a tag
>> name but allow ~[^0-9].*, i.e. if the immediately following symbol
>> after '~' is a letter, do not
>> interpret ~ as a special character. Could it work?
>
> We could make that work, with some caveats:
>
>  1) The syntax we've reserved for refnames is quite small, and my bias
> at least would be to say you should just make a tag like
> rpkg-util-1.4-rc1 instead (as e.g. git.git and linux.git do).

There is kind of clash of symbolics with rpm world. In rpm world, the component
after the last dash in a package full (versioned) name is usually
reserved for a downstream
packager who increments it as he/she adds patches to the original
sources. I will
need to do slightly more research here of what is possible.

Thank you so far!

>
> Carving out an exception like this also means we couldn't use
> ~[^0-9].* for anything magical in the future.
>
> But I think that's a rather small objection, we have other syntax
> escape hatches, and we're unlikely to use ~[^0-9].* as some new
> magic.
>
>  2) If we patch git to accept this, you'll be creating refs that aren't
> inter-operable with previous versions of git.
>
> This is a big deal. E.g. you'll happily create this special ref,
> then try to push it to github, and they'll croak because that's an
> invalid ref to them. Ditto some co-worker of yours who's using an
> older version of git.
>
> FWIW if you manually create such a tag e.g. for-each-ref will emit
> 'warning: ignoring ref with broken name' and just not show it.
>
>>>
>>> etc.
>>>
>>> Although I guess git could learn to disambiguate that form from the tag
>>> you're trying to create.
>>>
>>>> git tag rpkg-util-1.4%rc1
>>>>
>>>> but percentage sign does not seem to be particular fitting for
>>>> pre-release marking.
>>>>
>>>> Thank you
>>>> clime

Re: allow "~" to be present in a tag name

[Michal Novotny]

On Tue, Mar 13, 2018 at 10:07 AM, Ævar Arnfjörð Bjarmason
<ava...@gmail.com> wrote:
>
> On Tue, Mar 13 2018, Michal Novotny jotted:
>
>> Hello,
>>
>> currently, if I try to create a tag that has tilde "~"  in name, an
>> error is raised. E.g.
>>
>> $ git tag rpkg-util-1.4~rc1
>> fatal: 'rpkg-util-1.4~rc1' is not a valid tag name.
>>
>> Now, actually it would be very cool if tilde was allowed in a tag name
>> because we would like to use it for tagging pre-releases of (not-only
>> rpm) packages.
>>
>> Is there some deep technical reason why tilde cannot be present in a
>> tag name? I tried that e.g.
>
> Yes, because a trailing tilde is part of git's rev syntax, see "man
> git-rev-parse", or try in any repo:
>
> git show HEAD
> git show HEAD~2
> git show HEAD^~2

Right, reading the man pages:

~, e.g. master~3
   A suffix ~ to a revision parameter means the commit
object that is the th generation ancestor of the named commit
object, following only the first
   parents. I.e.  ~3 is equivalent to ^^^ which is
equivalent to ^1^1^1. See below for an illustration of the usage
of this form.

Would it be acceptable to disallow only ~ ( as [0-9]+) in a tag
name but allow ~[^0-9].*, i.e. if the immediately following symbol
after '~' is a letter, do not
interpret ~ as a special character. Could it work?

Thank you!
clime

>
> etc.
>
> Although I guess git could learn to disambiguate that form from the tag
> you're trying to create.
>
>> git tag rpkg-util-1.4%rc1
>>
>> but percentage sign does not seem to be particular fitting for
>> pre-release marking.
>>
>> Thank you
>> clime

allow "~" to be present in a tag name

[Michal Novotny]

Hello,

currently, if I try to create a tag that has tilde "~"  in name, an
error is raised. E.g.

$ git tag rpkg-util-1.4~rc1
fatal: 'rpkg-util-1.4~rc1' is not a valid tag name.

Now, actually it would be very cool if tilde was allowed in a tag name
because we would like to use it for tagging pre-releases of (not-only
rpm) packages.

Is there some deep technical reason why tilde cannot be present in a
tag name? I tried that e.g.

git tag rpkg-util-1.4%rc1

but percentage sign does not seem to be particular fitting for
pre-release marking.

Thank you
clime

[PATCH] git-tag: Allow --points-at syntax to create a tag pointing to specified commit

[Michal Novotny]

This patch adds the option to specify SHA-1 commit hash using
--points-at option of git tag to create a tag pointing to
the historical commit.

This was pretty easy in the past for the lightweight tags that are just simple
pointers (by creating .git/refs/tags/$tagname with SHA-1 hash) but it was not
possible for signed and annotated commits.

It's been tested for all of the tag types mentioned - lightweight tags, signed
tags and also annotated tags and everything is working fine in all scenarios.

Michal

Signed-off-by: Michal Novotny minov...@redhat.com
---
 builtin/tag.c | 32 ++--
 sha1-lookup.h |  3 +++
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/builtin/tag.c b/builtin/tag.c
index f826688..f642acd 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -437,7 +437,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
struct create_tag_options opt;
char *cleanup_arg = NULL;
int annotate = 0, force = 0, lines = -1, list = 0,
-   delete = 0, verify = 0;
+   delete = 0, verify = 0, points_at_commit = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
struct commit_list *with_commit = NULL;
@@ -521,8 +521,24 @@ int cmd_tag(int argc, const char **argv, const char 
*prefix)
die(_(-n option is only allowed with -l.));
if (with_commit)
die(_(--contains option is only allowed with -l.));
-   if (points_at.nr)
-   die(_(--points-at option is only allowed with -l.));
+   if (points_at.nr) {
+   if (points_at.nr  1)
+   die(_(--points-at option is only allowed with -l or a 
single 
+   SHA-1 hash is allowed to create a tag to 
commit.));
+   else {
+   unsigned char *ref = points_at.sha1[0];
+
+   struct object *obj = parse_object(ref);
+   if ((obj != NULL)  (obj-type == OBJ_COMMIT)) {
+   memcpy(object, ref, 20);
+   points_at_commit = 1;
+   }
+   else
+   die(_(--points-at option points to an invalid 
commit));
+
+   free(ref);
+   }
+   }
if (delete)
return for_each_tag_name(argv, delete_tag);
if (verify)
@@ -548,12 +564,16 @@ int cmd_tag(int argc, const char **argv, const char 
*prefix)
 
tag = argv[0];
 
-   object_ref = argc == 2 ? argv[1] : HEAD;
if (argc  2)
die(_(too many params));
 
-   if (get_sha1(object_ref, object))
-   die(_(Failed to resolve '%s' as a valid ref.), object_ref);
+   /* Option --points-at option is setting this already */
+   if (!points_at_commit) {
+   object_ref = argc == 2 ? argv[1] : HEAD;
+
+   if (get_sha1(object_ref, object))
+   die(_(Failed to resolve '%s' as a valid ref.), 
object_ref);
+   }
 
if (strbuf_check_tag_ref(ref, tag))
die(_('%s' is not a valid tag name.), tag);
diff --git a/sha1-lookup.h b/sha1-lookup.h
index 20af285..4eb03cf 100644
--- a/sha1-lookup.h
+++ b/sha1-lookup.h
@@ -1,6 +1,9 @@
 #ifndef SHA1_LOOKUP_H
 #define SHA1_LOOKUP_H
 
+unsigned char *translate_sha1_to_binary(const char *object_ref);
+int sha1_points_to_valid_commit(const char *object_ref);
+
 typedef const unsigned char *sha1_access_fn(size_t index, void *table);
 
 extern int sha1_pos(const unsigned char *sha1,
-- 
1.7.11.7

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] git-tag: Allow --points-at syntax to create a tag pointing to specified commit

[Michal Novotny]

This patch adds the option to specify SHA-1 commit hash using --points-at
option of git tag to create a tag pointing to a historical commit.

This was pretty easy in the past for the lightweight tags that are just simple
pointers (by creating .git/refs/tags/$tagname with SHA-1 hash) but it was not
possible for signed and annotated commits.

It's been tested for all of the tag types mentioned - lightweight tags, signed
tags and also annotated tags and everything is working fine in all scenarios
mentioned above.

Differences between v1 and v2 (this one):
 - The bogus sha1-lookup.h hunk has been removed as it's not required and
   I accidentally forgot to remove it before posting v1

Michal

Signed-off-by: Michal Novotny minov...@redhat.com
---
 builtin/tag.c | 32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/builtin/tag.c b/builtin/tag.c
index f826688..f642acd 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -437,7 +437,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
struct create_tag_options opt;
char *cleanup_arg = NULL;
int annotate = 0, force = 0, lines = -1, list = 0,
-   delete = 0, verify = 0;
+   delete = 0, verify = 0, points_at_commit = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
struct commit_list *with_commit = NULL;
@@ -521,8 +521,24 @@ int cmd_tag(int argc, const char **argv, const char 
*prefix)
die(_(-n option is only allowed with -l.));
if (with_commit)
die(_(--contains option is only allowed with -l.));
-   if (points_at.nr)
-   die(_(--points-at option is only allowed with -l.));
+   if (points_at.nr) {
+   if (points_at.nr  1)
+   die(_(--points-at option is only allowed with -l or a 
single 
+   SHA-1 hash is allowed to create a tag to 
commit.));
+   else {
+   unsigned char *ref = points_at.sha1[0];
+
+   struct object *obj = parse_object(ref);
+   if ((obj != NULL)  (obj-type == OBJ_COMMIT)) {
+   memcpy(object, ref, 20);
+   points_at_commit = 1;
+   }
+   else
+   die(_(--points-at option points to an invalid 
commit));
+
+   free(ref);
+   }
+   }
if (delete)
return for_each_tag_name(argv, delete_tag);
if (verify)
@@ -548,12 +564,16 @@ int cmd_tag(int argc, const char **argv, const char 
*prefix)
 
tag = argv[0];
 
-   object_ref = argc == 2 ? argv[1] : HEAD;
if (argc  2)
die(_(too many params));
 
-   if (get_sha1(object_ref, object))
-   die(_(Failed to resolve '%s' as a valid ref.), object_ref);
+   /* Option --points-at option is setting this already */
+   if (!points_at_commit) {
+   object_ref = argc == 2 ? argv[1] : HEAD;
+
+   if (get_sha1(object_ref, object))
+   die(_(Failed to resolve '%s' as a valid ref.), 
object_ref);
+   }
 
if (strbuf_check_tag_ref(ref, tag))
die(_('%s' is not a valid tag name.), tag);
-- 
1.7.11.7

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] git-tag: Allow --points-at syntax to create a tag pointing to specified commit

[Michal Novotny]

On 03/14/2013 02:36 PM, John Keeping wrote:
 On Thu, Mar 14, 2013 at 01:34:54PM +0100, Michal Novotny wrote:
 This patch adds the option to specify SHA-1 commit hash using --points-at
 option of git tag to create a tag pointing to a historical commit.
 What does this do that git tag name commit doesn't?

Oh, interesting. It's working now and I didn't know that as it was not
working some time ago I've been trying this approach. Maybe it's been
added recently as I also saw several sites having different approach of
tagging to specified commit (usually creating a new branch, tagging
there and rebasing etc.).

Thanks for information!
Michal

-- 
Michal Novotny minov...@redhat.com, RHCE, Red Hat
Virtualization | libvirt-php bindings | php-virt-control.org

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] daemon: --access-hook option

[Michal Novotny]

;
 +
 + if (!seen_errors) {
 + strbuf_release(buf);
 + return 0;
 + }
 +
 +error_return:
 + strbuf_ltrim(buf);
 + if (!buf.len)
 + strbuf_addstr(buf, service rejected);
 + eol = strchr(buf.buf, '\n');
 + if (eol)
 + *eol = '\0';
 + errno = EACCES;
 + daemon_error(dir, buf.buf);
 + strbuf_release(buf);
 + return -1;
 +}
 +
  static int run_service(char *dir, struct daemon_service *service)
  {
   const char *path;
 @@ -304,6 +370,13 @@ static int run_service(char *dir, struct daemon_service 
 *service)
   }
  
   /*
 +  * Optionally, a hook can choose to deny access to the
 +  * repository depending on the phase of the moon.
 +  */
 + if (access_hook  run_access_hook(service, dir, path))
 + return -1;
 +
 + /*
* We'll ignore SIGTERM from now on, we have a
* good client.
*/
 @@ -1142,6 +1215,10 @@ int main(int argc, char **argv)
   export_all_trees = 1;
   continue;
   }
 + if (!prefixcmp(arg, --access-hook=)) {
 + access_hook = arg + 14;
 + continue;
 + }
   if (!prefixcmp(arg, --timeout=)) {
   timeout = atoi(arg+10);
   continue;

-- 
Michal Novotny minov...@redhat.com, RHCE, Red Hat
Virtualization | libvirt-php bindings | php-virt-control.org

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Implement ACL module architecture and sample MySQL ACL module

[Michal Novotny]

Hi,
this is the patch to introduce the ACL module architecture into git
versioning system. The variable of GIT_BASE_DIR is being used to seek
for the modules if available. If variable is unset then daemon looks
for the /etc/git-daemon.conf file existence and reads the
'base_path' key if it exists to determine the root path for
the git-daemon. This will be referred to as to $GIT_BASE_DIR
directory and the ACL modules subdirectory should reside in path of
$GIT_BASE_DIR/modules/acl. For MySQL connection you have to
alter the modules/config/modgitacl_mysql.cfg file to be able
to connect to the MySQL server using your credentials.

For MySQL database connection 2 new tables will get created
on your server and in the desired database. One holds the
ACLs for IP addresses and repositories and the second is
optional logging to the history table. This is by default
disabled however it could be enabled by setting the log_history
column of the git_access_acl entry to 1.

The patch also introduces the global_access_rule key to the config
which defines the default access policy if address and repository
key combination doesn't exist in the database. This automatically
creates the default access rule for the repository (which is
basically an entry with addr field set to '%' as all possible
entries in this column) based on the key settings.

The search algorithm for the entries is as follows:
1) Try to find the default entry for the repository
   - If default entry doesn't exist then create it based on the
 global_access_rule key settings (if set and valid)
2) Try to find entry for repository and IP address to override
   default settings
3) Log entries access if appropriate

If the new default access rule is being created then logging is
enabled for 'deny' global_access_rule and disabled for 'allow'
global_access_rule settings.

The MySQL module is just the working example of how to use the
ACL architecture so it's not being compiled by default and user
has to compile it manually. Basically this module is showing how
git ACL infrastructure works and it's good point to start writing
such modules.

The patch has been tested using following command line on one terminal:

$ make  (cd modules/acl  make  cd -)  GIT_BASE_DIR=`pwd` ./git-daemon 
--export-all

and cloning the existing repository on the second terminal with testing
all possible options in the database (using the sample MySQL module)
and everything was working fine.

Thanks,
Michal

Signed-off-by: Michal Novotny minov...@redhat.com
---
 Makefile   |   1 +
 daemon.c   | 123 +
 modules/acl/Makefile   |   6 ++
 modules/acl/modgitacl_mysql.c  | 211 +
 modules/config/modgitacl_mysql.cfg |  12 +++
 modules/modules.h  |   9 ++
 6 files changed, 362 insertions(+)
 create mode 100644 modules/acl/Makefile
 create mode 100644 modules/acl/modgitacl_mysql.c
 create mode 100644 modules/config/modgitacl_mysql.cfg
 create mode 100644 modules/modules.h

diff --git a/Makefile b/Makefile
index 6b0c961..6fe32a7 100644
--- a/Makefile
+++ b/Makefile
@@ -932,6 +932,7 @@ ifeq ($(uname_S),OSF1)
NO_NSEC = YesPlease
 endif
 ifeq ($(uname_S),Linux)
+   BASIC_CFLAGS += -ldl -rdynamic
NO_STRLCPY = YesPlease
NO_MKSTEMPS = YesPlease
HAVE_PATHS_H = YesPlease
diff --git a/daemon.c b/daemon.c
index ab21e66..8a06c05 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1,9 +1,14 @@
+#defineGIT_DAEMON_CONFIG_FILE  /etc/git-daemon.conf
+#defineGIT_DAEMON_CONFIG_FILE_PATH_KEY base_path
+#defineBUFSIZE 1  12
+
 #include cache.h
 #include pkt-line.h
 #include exec_cmd.h
 #include run-command.h
 #include strbuf.h
 #include string-list.h
+#include modules/modules.h
 
 #ifndef HOST_NAME_MAX
 #define HOST_NAME_MAX 256
@@ -256,6 +261,117 @@ static int daemon_error(const char *dir, const char *msg)
return -1;
 }
 
+static char* daemon_read_config(const char *filename, char *key)
+{
+   FILE *fp;
+   char line[BUFSIZE];
+
+   fp = fopen(filename, r);
+   if (fp == NULL)
+   return NULL;
+
+   while (!feof(fp)) {
+   fgets(line, sizeof(line), fp);
+
+   if (strncmp(line, key, strlen(key)) == 0) {
+   return strdup( line + strlen(key) + 3 );
+   }
+   }
+   fclose(fp);
+
+   return NULL;
+}
+
+static int check_access_addrdir(char *libname, char *base_path, char *addr, 
const char *dir)
+{
+   int ret = -EPERM;
+   void *lib = NULL;
+   void *pCheck = NULL;
+   typedef int (*tCheckFunc) (char *base_path, char *addr, const char 
*dir);
+
+   lib = dlopen(libname, RTLD_LAZY);
+   if (lib == NULL) {
+   logerror(%s: Cannot load ACL library '%s', __FUNCTION__, 
libname);
+   goto cleanup;
+   }
+
+   pCheck = dlsym(lib