All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Riesen <raa.lkml@gmail.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: [PATCH] Add remove_path: a function to remove as much as possible of a path
Date: Sat, 27 Sep 2008 00:56:46 +0200	[thread overview]
Message-ID: <20080926225645.GA13412@blimp.localhost> (raw)
In-Reply-To: <20080926152823.GA17470@spearce.org>

The function has two potential users which both managed to get wrong
their implementations (the one in builtin-rm.c one has a memleak, and
builtin-merge-recursive.c scribles over its const argument).

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Shawn O. Pearce, Fri, Sep 26, 2008 17:28:23 +0200:
> Alex Riesen <raa.lkml@gmail.com> wrote:
> > It is the same as in merge-recursive, but they're so small so unless
> > we get a special file with such random routines there is no much point
> > exporting it. Actually, we do seem to have such a file: dir.c. It is
> > already plagued by file_exists kind of things, why not remove_path...
> 
> Yea.  I'm thinking remove_path should migrate to dir.c.  Hell,
> we already have rm -rf as remove_dir_recursively() in dir.c.
> remove_path is its long-lost soul mate.  I'm not applying this
> builtin-rm fix, and am hoping you'll rewrite it around a move
> of remove_path to dir.c...  ;-)
>  

Okay :) The next one is on top of the previous fix in merge-recursive
(removes ENOENT conditional)

 dir.c |   20 ++++++++++++++++++++
 dir.h |    3 +++
 2 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/dir.c b/dir.c
index acf1001..1c3c501 100644
--- a/dir.c
+++ b/dir.c
@@ -831,3 +831,23 @@ void setup_standard_excludes(struct dir_struct *dir)
 	if (excludes_file && !access(excludes_file, R_OK))
 		add_excludes_from_file(dir, excludes_file);
 }
+
+int remove_path(const char *name)
+{
+	char *slash;
+
+	if (unlink(name) && errno != ENOENT)
+		return -1;
+
+	slash = strrchr(name, '/');
+	if (slash) {
+		char *dirs = xstrdup(name);
+		slash = dirs + (slash - name);
+		do {
+			*slash = '\0';
+		} while (rmdir(dirs) && (slash = strrchr(dirs, '/')));
+		free(dirs);
+	}
+	return 0;
+}
+
diff --git a/dir.h b/dir.h
index 2df15de..278ee42 100644
--- a/dir.h
+++ b/dir.h
@@ -81,4 +81,7 @@ extern int is_inside_dir(const char *dir);
 extern void setup_standard_excludes(struct dir_struct *dir);
 extern int remove_dir_recursively(struct strbuf *path, int only_empty);
 
+/* tries to remove the path with empty directories along it, ignores ENOENT */
+extern int remove_path(const char *path);
+
 #endif
-- 
1.6.0.2.328.g14651

  reply	other threads:[~2008-09-26 22:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-24 16:32 [BUG] git merge does not prune empty directories Anders Melchiorsen
2008-09-25 20:12 ` [PATCH] Remove empty directories in recursive merge Alex Riesen
2008-09-25 20:17   ` [PATCH] Cleanup remove_path Alex Riesen
2008-09-25 20:22     ` [PATCH] Fix memleak and the implementation of remove_file in builtin-rm.c Alex Riesen
2008-09-26 15:28       ` Shawn O. Pearce
2008-09-26 22:56         ` Alex Riesen [this message]
2008-09-26 22:59           ` [PATCH] Use remove_path from dir.c instead of own implementation Alex Riesen
2008-09-25 20:33   ` [PATCH] Remove empty directories in recursive merge Alex Riesen
2008-09-26 15:06     ` Shawn O. Pearce
2008-09-26  5:58   ` Johannes Sixt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080926225645.GA13412@blimp.localhost \
    --to=raa.lkml@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.