* Project- vs. Package-Level Branching in Git
From: Thomas Hauk @ 2011-01-27 19:38 UTC (permalink / raw)
To: git
Back when I worked at a large games company, we used Perforce, and our repo structure looked a little something like this:
/branches
/alpha
/beta
/mainline
/packages
/external
/foolib
/1.0
/1.1
/2.0
/internal
/barlib
/dev
/1.0
/2.0
/bazlib
/2.34
/2.35
/qux
/dev
At the package level, we would split up packages/libraries into two groups based on if they were developed at the company or not (external/internal), and inside each one, we might have multiple versions. In the example above, the repo is for the "qux" game, which uses an internal "bazlib" library developed by another group, and the "barlib" library which was developed for use on "qux" and may be used simultaneously on other projects.
Project-level branches took mainline as a base and branched into the /branches directory. Package-level branches would usually take the "dev" version (which represented the current development version, akin to "master" in Git) as a base and branch into the same parent directory but with an actual version name.
I've successfully used this repo structure with several other projects over the years at other companies (who were mostly using Subversion). Now I'm trying to get into the Git swing of things, but it seems to be that Git only offers project-level branching, and doesn't allow for the kind of package-level branching I'm describing here.
Am I incorrect or is there a way to accomplish with Git what I was doing before with P4 and SVN?
--
Thomas Hauk
Shaggy Frog Software
www.shaggyfrog.com
^ permalink raw reply
* Re: [PATCH v4] fast-import: treat filemodify with empty tree as delete
From: Peter Baumann @ 2011-01-27 19:33 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Sverre Rabbelier, Git Mailing List,
Ramkumar Ramachandra, Shawn O. Pearce, David Barr
In-Reply-To: <20110127060749.GA5586@burratino>
On Thu, Jan 27, 2011 at 12:07:49AM -0600, Jonathan Nieder wrote:
> diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
> index 50d5913..8487734 100755
> --- a/t/t9300-fast-import.sh
> +++ b/t/t9300-fast-import.sh
> @@ -818,6 +818,48 @@ test_expect_success \
> compare_diff_raw expect actual'
>
> +test_expect_success \
> + 'N: delete directory by copying' \
> + 'cat >expect <<-\EOF &&
> + OBJID
> + :100644 000000 OBJID OBJID D foo/bar/qux
> + OBJID
> + :000000 100644 OBJID OBJID A foo/bar/baz
> + :000000 100644 OBJID OBJID A foo/bar/qux
> + EOF
> + empty_tree=$(git mktree </dev/null) &&
[ Feel free to ignore me ... ]
Just a (stupid?) suggestion: Why not put a $EMPTY_TREE definiton in test-lib.sh
(or any other global file sourced in the tests) so if another caller needs this
definition it won't waste cpu cycles doing the calculation via mktree < /dev/null
again?
^ permalink raw reply
* Re: [PATCH] Fix wrong xhtml option to highlight
From: Junio C Hamano @ 2011-01-27 19:00 UTC (permalink / raw)
To: Drew Northup
Cc: Junio C Hamano, Jochen Schmitt, Jakub Narebski, Adam Tkac, git
In-Reply-To: <1296092646.23506.10.camel@drew-northup.unet.maine.edu>
Drew Northup <drew.northup@maine.edu> writes:
>> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> > index 1025c2f..b662420 100755
>> > --- a/gitweb/gitweb.perl
>> > +++ b/gitweb/gitweb.perl
>> > @@ -3468,7 +3468,7 @@ sub run_highlighter {
>> > close $fd;
>> > open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
>> > quote_command($highlight_bin).
>> > - " --xhtml --fragment --syntax $syntax |"
>> > + " -xhtml --fragment --syntax $syntax |"
>>
>> Curious.
>>
>> Does the command take double-dash for the fragment and syntax options but
>> a single dash for the xhtml option? Really...
>>
>> A few top hits returned by Google for "highlight manual page" tells me
>> otherwise.
>
> Certainly appears to be the case that "--xhtml" is the option in Ubuntu
> 10.04.1 LTS.
>
> Jochen,
> Did you mean "-X" (which sets the same option)?
The current proposal is to drop --xhtml and let highlight default to HTML.
Honestly speaking, I don't like the approach very much; it would have been
much better if highlight had a single way that is supported throughout its
versions to specify the output format. But it appears that there isn't,
and relying on and hoping for its default to stay HTML is the best we
could do, if we plan to support highlight 2.4.something or older.
The copy of U10.04 I have has highlight 2.12, and according to its manual
pages, -X, --xhtml, and --out-format=xhtml mean the same thing. HTML is
the default.
The change-log at www.andre-simon.de indicates that --out-format has
become the preferred method and the short options like -X and -H are not
supported in recent versions (3.0 beta and newer).
But as Jakub mentioned, 2.4.5 did not have --output-format; it was only in
3.0 beta that -O was redefined to mean --output-format and in old versions
the short option meant something else.
What a mess...
The next time we introduce a new dependency, we really should try hard to
assess the stability and maturity of that dependency. In hindsight, I
think "highlight" was probably a bit too premature to be depended upon.
^ permalink raw reply
* [PATCH] gitk: Preserve Entry class key bindings for SHA id
From: Kacper Kornet @ 2011-01-27 16:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
If bind is specified for key without any modifier, then any combination
of modifiers may be present in the event. So bind $e $ev "$escript;
break" breaks some useful bindings from Entry class (for example
Ctrl+k).
Signed-off-by: Kacper Kornet <kornet@camk.edu.pl>
---
gitk | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/gitk b/gitk
index 9cbc09d..71eebb2 100755
--- a/gitk
+++ b/gitk
@@ -2389,6 +2389,10 @@ proc makewindow {} {
}
}
+ foreach e $entries {
+ bindtags $e [linsert [bindtags $e] 2 entrybind]
+ }
+
bind .pwbottom <Configure> {resizecdetpanes %W %w}
pack .ctop -fill both -expand 1
bindall <1> {selcanvline %W %x %y}
@@ -2588,12 +2592,8 @@ proc scrollcanv {cscroll f0 f1} {
proc bindkey {ev script} {
global entries
bind . $ev $script
- set escript [bind Entry $ev]
- if {$escript == {}} {
- set escript [bind Entry <Key>]
- }
foreach e $entries {
- bind $e $ev "$escript; break"
+ bind entrybind $ev "break"
}
}
--
1.7.3.5
--
Kacper Kornet
^ permalink raw reply related
* [PATCH] Disallow empty section and variable names
From: Libor Pechacek @ 2011-01-27 14:52 UTC (permalink / raw)
To: git
It is possible to break you repository config by creating an invalid config
option. The config parser in turn chokes on it.
$ git init
Initialized empty Git repository in /tmp/gittest/.git/
$ git config .foo false
$ git config .foo
fatal: bad config file line 6 in .git/config
This patch makes git-config reject keys which start or end with a dot. The fix
also revealed a typo in t5526-fetch-submodules, which is fixed by this patch as
well.
Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
---
Applies on top "Sanity-check config variable names".
config.c | 7 ++++++-
t/t5526-fetch-submodules.sh | 2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index c976544..81a0705 100644
--- a/config.c
+++ b/config.c
@@ -1119,7 +1119,7 @@ int git_config_parse_key(const char *key, char **store_key, int *baselen_)
* key name separated by a dot, we have to know where the dot is.
*/
- if (last_dot == NULL) {
+ if (last_dot == NULL || *key == '.') {
error("key does not contain a section: %s", key);
return -2;
}
@@ -1156,6 +1156,11 @@ int git_config_parse_key(const char *key, char **store_key, int *baselen_)
if (store_key)
(*store_key)[i] = 0;
+ if (key[i-1] == '.') {
+ error("key does not contain variable name: %s", key);
+ goto out_free_ret_1;
+ }
+
return 0;
out_free_ret_1:
diff --git a/t/t5526-fetch-submodules.sh b/t/t5526-fetch-submodules.sh
index 884a5e5..7106c6c 100755
--- a/t/t5526-fetch-submodules.sh
+++ b/t/t5526-fetch-submodules.sh
@@ -124,7 +124,7 @@ test_expect_success "--recurse-submodules overrides fetchRecurseSubmodules setti
(
cd downstream &&
git fetch --recurse-submodules >../actual.out 2>../actual.err &&
- git config -f --unset .gitmodules submodule.submodule.fetchRecurseSubmodules true &&
+ git config -f .gitmodules --unset submodule.submodule.fetchRecurseSubmodules true &&
git config --unset submodule.submodule.fetchRecurseSubmodules
) &&
test_cmp expect.out actual.out &&
--
1.7.4.rc3.3.g8b2bfe
^ permalink raw reply related
* [PATCH v3] Sanity-check config variable names
From: Libor Pechacek @ 2011-01-27 14:28 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20110121162318.GC21840@sigill.intra.peff.net>
Sanity-check config variable names when adding and retrieving them. As a side
effect code duplication between git_config_set_multivar and get_value (in
builtin/config.c) was removed and the common functionality was placed in
git_config_parse_key.
This breaks a test in t1300 which used invalid section-less keys in the tests
for "git -c". However, allowing such names there was useless, since there was
no way to set them via config file, and no part of git actually tried to use
section-less keys. This patch updates the test to use more realistic examples.
Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
Cc: Jeff King <peff@peff.net>
---
On Fri 21-01-11 11:23:19, Jeff King wrote:
> Typo: s/ckeck/check/
>
> Other than that, this version looks good to me.
Fixed the typo and return values from get_value and git_config_set_multivar.
We have changed git_config_parse_key to return negative values on error, but
forgot to negate the numbers when returning them as exit codes. That led to
process exit codes 255 and 254, which is, I think, unwanted.
> Acked-by: Jeff King <peff@peff.net>
Thanks. Now I consider this patch truly final.
Libor
builtin/config.c | 18 ++++++--
cache.h | 1 +
config.c | 107 ++++++++++++++++++++++++++++++-----------------
t/t1300-repo-config.sh | 7 +--
4 files changed, 85 insertions(+), 48 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index ca4a0db..66c0586 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -153,7 +153,6 @@ static int show_config(const char *key_, const char *value_, void *cb)
static int get_value(const char *key_, const char *regex_)
{
int ret = -1;
- char *tl;
char *global = NULL, *repo_config = NULL;
const char *system_wide = NULL, *local;
@@ -168,17 +167,26 @@ static int get_value(const char *key_, const char *regex_)
}
key = xstrdup(key_);
- for (tl=key+strlen(key)-1; tl >= key && *tl != '.'; --tl)
- *tl = tolower(*tl);
- for (tl=key; *tl && *tl != '.'; ++tl)
- *tl = tolower(*tl);
if (use_key_regexp) {
+ char *tl;
+
+ /* TODO - this naive pattern lowercasing obviously does not
+ * work for more complex patterns like `^[^.]*Foo.*bar' */
+ for (tl = key+strlen(key)-1; tl >= key && *tl != '.'; --tl)
+ *tl = tolower(*tl);
+ for (tl = key; *tl && *tl != '.'; ++tl)
+ *tl = tolower(*tl);
+
key_regexp = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(key_regexp, key, REG_EXTENDED)) {
fprintf(stderr, "Invalid key pattern: %s\n", key_);
goto free_strings;
}
+ } else {
+ ret = -git_config_parse_key(key_, &key, NULL);
+ if (ret)
+ goto free_strings;
}
if (regex_) {
diff --git a/cache.h b/cache.h
index d83d68c..1e32d63 100644
--- a/cache.h
+++ b/cache.h
@@ -997,6 +997,7 @@ extern int git_config_maybe_bool(const char *, const char *);
extern int git_config_string(const char **, const char *, const char *);
extern int git_config_pathname(const char **, const char *, const char *);
extern int git_config_set(const char *, const char *);
+extern int git_config_parse_key(const char *, char **, int *);
extern int git_config_set_multivar(const char *, const char *, const char *, int);
extern int git_config_rename_section(const char *, const char *);
extern const char *git_etc_gitconfig(void);
diff --git a/config.c b/config.c
index 625e051..c976544 100644
--- a/config.c
+++ b/config.c
@@ -1098,6 +1098,72 @@ int git_config_set(const char *key, const char *value)
return git_config_set_multivar(key, value, NULL, 0);
}
+/* Auxiliary function to sanity-check and split the key into the section
+ * identifier and variable name.
+ *
+ * Returns 0 on success, -1 when there is an invalid character in the key and
+ * -2 if there is no section name in the key.
+ *
+ * store_key - pointer to char* which will hold a copy of the key with
+ * lowercase section and variable name, can be NULL
+ * baselen - pointer to int which will hold the length of the
+ * section + subsection part, can be NULL
+ */
+int git_config_parse_key(const char *key, char **store_key, int *baselen_)
+{
+ int i, dot, baselen;
+ const char *last_dot = strrchr(key, '.');
+
+ /*
+ * Since "key" actually contains the section name and the real
+ * key name separated by a dot, we have to know where the dot is.
+ */
+
+ if (last_dot == NULL) {
+ error("key does not contain a section: %s", key);
+ return -2;
+ }
+
+ baselen = last_dot - key;
+ if (baselen_)
+ *baselen_ = baselen;
+
+ /*
+ * Validate the key and while at it, lower case it for matching.
+ */
+ if (store_key)
+ *store_key = xmalloc(strlen(key) + 1);
+
+ dot = 0;
+ for (i = 0; key[i]; i++) {
+ unsigned char c = key[i];
+ if (c == '.')
+ dot = 1;
+ /* Leave the extended basename untouched.. */
+ if (!dot || i > baselen) {
+ if (!iskeychar(c) || (i == baselen+1 && !isalpha(c))) {
+ error("invalid key: %s", key);
+ goto out_free_ret_1;
+ }
+ c = tolower(c);
+ } else if (c == '\n') {
+ error("invalid key (newline): %s", key);
+ goto out_free_ret_1;
+ }
+ if (store_key)
+ (*store_key)[i] = c;
+ }
+ if (store_key)
+ (*store_key)[i] = 0;
+
+ return 0;
+
+out_free_ret_1:
+ if (store_key)
+ free(*store_key);
+ return -1;
+}
+
/*
* If value==NULL, unset in (remove from) config,
* if value_regex!=NULL, disregard key/value pairs where value does not match.
@@ -1124,59 +1190,22 @@ int git_config_set(const char *key, const char *value)
int git_config_set_multivar(const char *key, const char *value,
const char *value_regex, int multi_replace)
{
- int i, dot;
int fd = -1, in_fd;
int ret;
char *config_filename;
struct lock_file *lock = NULL;
- const char *last_dot = strrchr(key, '.');
if (config_exclusive_filename)
config_filename = xstrdup(config_exclusive_filename);
else
config_filename = git_pathdup("config");
- /*
- * Since "key" actually contains the section name and the real
- * key name separated by a dot, we have to know where the dot is.
- */
-
- if (last_dot == NULL) {
- error("key does not contain a section: %s", key);
- ret = 2;
+ ret = -git_config_parse_key(key, &store.key, &store.baselen);
+ if (ret)
goto out_free;
- }
- store.baselen = last_dot - key;
store.multi_replace = multi_replace;
- /*
- * Validate the key and while at it, lower case it for matching.
- */
- store.key = xmalloc(strlen(key) + 1);
- dot = 0;
- for (i = 0; key[i]; i++) {
- unsigned char c = key[i];
- if (c == '.')
- dot = 1;
- /* Leave the extended basename untouched.. */
- if (!dot || i > store.baselen) {
- if (!iskeychar(c) || (i == store.baselen+1 && !isalpha(c))) {
- error("invalid key: %s", key);
- free(store.key);
- ret = 1;
- goto out_free;
- }
- c = tolower(c);
- } else if (c == '\n') {
- error("invalid key (newline): %s", key);
- free(store.key);
- ret = 1;
- goto out_free;
- }
- store.key[i] = c;
- }
- store.key[i] = 0;
/*
* The lock serves a purpose in addition to locking: the new
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index d0e5546..3e79c37 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -876,11 +876,10 @@ test_expect_success 'check split_cmdline return' "
"
test_expect_success 'git -c "key=value" support' '
- test "z$(git -c name=value config name)" = zvalue &&
test "z$(git -c core.name=value config core.name)" = zvalue &&
- test "z$(git -c CamelCase=value config camelcase)" = zvalue &&
- test "z$(git -c flag config --bool flag)" = ztrue &&
- test_must_fail git -c core.name=value config name
+ test "z$(git -c foo.CamelCase=value config foo.camelcase)" = zvalue &&
+ test "z$(git -c foo.flag config --bool foo.flag)" = ztrue &&
+ test_must_fail git -c name=value config core.name
'
test_done
--
1.7.4.rc3.2.g27487
^ permalink raw reply related
* Re: [PATCH 2/3] git-gui: spelling fixes in russian translation
From: Alex Riesen @ 2011-01-27 12:58 UTC (permalink / raw)
To: Pat Thoyts
Cc: git, Shawn O. Pearce, Serge Ziryukin, Dmitry Potapov,
Alexander Gavrilov, Junio C Hamano
In-Reply-To: <87fwseo9f4.fsf@fox.patthoyts.tk>
On Thu, Jan 27, 2011 at 12:47, Pat Thoyts
<patthoyts@users.sourceforge.net> wrote:
>>What's with git-gui-i18n/mob branch being out-of-date? Actually,
>>it seems to be abandoned, because it does have quite a bit of
>>changes in it which are not in git-gui/master: spanish, bulgarian,
>>portugese, romanian, chinese, italian, japan and greek:
>
> The git-gui/git-gui-i18n.git repository is a fork that was created to do
> the initial internationalization of git-gui I believe. It predates my
> involvement with this project so I could be wrong.
Well, still does not answer the question: why are these spanish, bulgarian,
etc translations not in git-gui/master?
> We don't provide a mob branch but you could create your own fork on
> repo.or.cz if you intend to do much development and then post merge
> requests to this group and myself.
No need. I'll provide a link to pull from next time.
> I think I'd prefer to see forks than use a mob branch. Or receive
> patches or course.
With abundance of free Git hosting I too think it is a solution preferable
to almost everyone (that's why I suggested about a branch to pull from
in some earlier message).
^ permalink raw reply
* [PATCH] Don't pass "--xhtml" to hightlight in gitweb.perl script.
From: Adam Tkac @ 2011-01-27 12:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, Jochen Schmitt
In-Reply-To: <20110127120323.GA3416@traged.englab.brq.redhat.com>
The "--xhtml" option is supported only in highlight < 3.0. There is no option
to enforce (X)HTML output format compatible with both highlight < 3.0 and
highlight >= 3.0. However default output format is HTML so we don't need to
explicitly specify it.
Signed-off-by: Adam Tkac <atkac@redhat.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1025c2f..0779f12 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3468,7 +3468,7 @@ sub run_highlighter {
close $fd;
open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
quote_command($highlight_bin).
- " --xhtml --fragment --syntax $syntax |"
+ " --fragment --syntax $syntax |"
or die_error(500, "Couldn't open file or run syntax highlighter");
return $fd;
}
--
1.7.3.5
^ permalink raw reply related
* Re: [PATCH] git-gui: update russian translation
From: Pat Thoyts @ 2011-01-27 11:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Alex Riesen, git, Shawn O. Pearce, Serge Ziryukin, Dmitry Potapov,
Alexander Gavrilov
In-Reply-To: <7vmxmplt2g.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>Pat Thoyts <patthoyts@users.sourceforge.net> writes:
>
>> Thank you for the patches. I've applied the four patches and pushed them to
>> http://repo.or.cz/w/git-gui.git master.
>
>I see a few changes outside po/ru.po in this update:
>
> git-gui.sh | 26 ++-
> lib/browser.tcl | 2 +-
> lib/diff.tcl | 60 ++++--
> po/ru.po | 623 ++++++++++++++++++++++++++++---------------------------
> 4 files changed, 381 insertions(+), 330 deletions(-)
>
>Are they all good to go for 1.7.4 final? My cursory look indicates that
>they are all minor bugfixes and look sane, but I rarely use git-gui
>myself, so I am just double checking.
>
>
>Alex Riesen (2):
> git-gui: update russian translation
> git-gui: update russian translation
>
>Bert Wesarg (5):
> git-gui: fix ANSI-color parsing
> git-gui: respect conflict marker size
> git-gui: fix browsers [Up To Parent] in sub-sub-directories.
> git-gui: Fix use of renamed tag.
> git-gui: Fix use of hunk tag for non-hunk content.
>
>Serge Ziryukin (1):
> git-gui: fix russian translation typos
>
>Skip (1):
> git-gui: spelling fixes in russian translation
>
>Stefan Naewe (1):
> git-gui: use --exclude-standard to check for untracked files
>
Yes - these are good to go. Anything going onto master should be
suitable for merging to git. Anything that is still being tested I would
put onto pu if it got pushed at all.
So please merge git://repo.or.cz/git-gui.git master
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [PATCH] Pass "-O xhtml" param to highlight instead of "-xhtml"
From: Adam Tkac @ 2011-01-27 12:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, Jochen Schmitt
In-Reply-To: <7vaainjq7f.fsf@alter.siamese.dyndns.org>
On Wed, Jan 26, 2011 at 01:43:48PM -0800, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> >> Current highlight utility doesn't recognize "--xhtml" parameter, it
> >> recognizes only "-O xhtml" parameter.
> >>
> >> Reference: https://bugzilla.redhat.com/show_bug.cgi?id=672293
> >
> > Shouldn't the above be in commit message?
>
> Actually, I prefer not having that "Reference" in the commit message
> myself, but I do want to have some relevant details
> missing from the proposed commit message but is in
> that ticket (especially the comment #5) in the commit message.
>
> > In highlight 2.4.5 '-O' means "name of output directory", i.e. --outdir.
> > There is no --out-format either.
>
> Thanks for digging about 2.4.5; in that case, unlike the redhat ticket
> hinted, this change may not be backward compatible enough, as it seems
> that the compatibility goes only back to 3.0.something.
Right you are, I digged too shallowly, thanks for your inspection.
>
> >
> > WTF this backward incompatibile change in highlight... the only
> > solution that would make it work both for old and for new versions is
> > to rely on the fact that HTML is default output format, i.e.
> >
> > open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
> > quote_command($highlight_bin).
> > - " --xhtml --fragment --syntax $syntax |"
> > + " --fragment --syntax $syntax |"
> > or die_error(500, "Couldn't open file or run syntax highlighter");
>
> Adam, Jochen? How does the counterproposal look to you?
>
> Without knowing much about highlight nor using gitweb in general myself,
> the above looks a bit more reasonable fix to the issue, if the default
> format has been and will stay to be HTML.
The proposal looks like the best (and the only one) correct solution.
I will send updated patch.
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
^ permalink raw reply
* Re: [PATCH 2/3] git-gui: spelling fixes in russian translation
From: Pat Thoyts @ 2011-01-27 11:47 UTC (permalink / raw)
To: Alex Riesen
Cc: git, Shawn O. Pearce, Serge Ziryukin, Dmitry Potapov,
Alexander Gavrilov, Junio C Hamano
In-Reply-To: <AANLkTi=A=yD4Oe-meB=ZMFe_Wm8om-hmA_MOU8vyyBNR@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
>On Tue, Jan 25, 2011 at 00:31, Pat Thoyts
><patthoyts@users.sourceforge.net> wrote:
>> Alex Riesen <raa.lkml@gmail.com> writes:
>>
>>>2011/1/17 Alex Riesen <raa.lkml@gmail.com>:
>>>> po/ru.po | 24 ++++++++++++------------
>>>> 1 files changed, 12 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/po/ru.po b/po/ru.po
>>>> index c15bdfa..304bb3a 100644
>>>
>>>BTW, does anyone know what happens to git-gui development?
>>>In particular, the i18n patches. The old way of pushing
>>>to a mob branch seems to stopped working, and anyway, the
>>>branch is very out of date.
>>>
>>>Is git gui development stalled? Should I perhaps send the
>>>i18n pull request directly to Junio?
>>>
>>
>> If you post here they'll get picked up eventually.
>> If you want to use the mob branch, we can use that too but you would
>> need to post here and to me to notify everyone.
>
>What's with git-gui-i18n/mob branch being out-of-date? Actually,
>it seems to be abandoned, because it does have quite a bit of
>changes in it which are not in git-gui/master: spanish, bulgarian,
>portugese, romanian, chinese, italian, japan and greek:
>
> $ git cherry -v git-gui-i18n/master git-gui-i18n/mob
> - 0896a7856335cc934328e02b84e1e41b9db2632d Updated Hungarian
>translation (e5fba18)
> + c6fb29db5a50df150280b641d3c2a6703589b529 Fixed usage of positional
>parameters in it.po and ja.po
> + a1fdd910cf11837135f8b007dbb1380131f8d107 Started Romanian Translation
> + 2f27eb24bf1dfdbb14dbc44698cb07ed294a10cf Start Spanish translation
> + 4616c11423484f40361466e0f2470d6c4a29e692 More strings for Spanish
>translation
> + e51f330c4c94795cb7cfd151df2f2a222bde0d66 Yet more strings translated...
> + 0947a8e1d71ff03fbc2838f4742de8aa6c971083 Translated a few more strings
> - 71438168c673dd644b442a4c3f863456ddf4b13b Update french translation.
> + bb88a426e49b73c6e7f9b0c8c3be6dc1946252a7 More translated strings
>for Spanish. Close to being there...
> + 1cf3364c33c57f83b214e51a3ee260334ddc7e56 Fixed usage of positional
>parameters in ja.po
> + 3f4263f049b76118ce8f8f35aacc99dc2f958a82 A few more strings
> + 31da610cb074364aa8d6e32c4cf2a3b5c6d16b51 A Bulgarian translation
>has been added.
> + ad8d6a97f364f4ee3082258aeddb0488652b81d2 git-gui: Update
>simplified Chinese translation to POT-2008-08-02
> + 6227f5ee3c74078eec37790111242ac3856759da git-gui: Add traditional
>Chinese translation
> + de6afb81c44b44722affd8f2f6aa26fece24c401 Started Portuguese translation.
> + 78ae667f948ed29dca3f7abc3ae67996a56fabf7 Cleaned header of
>Portuguese translation and corrects translation of "Commit@@verb".
> + c71abd9b3de78db783e8a7af92fb75bdd57bf2a9 Clean messed up header from KBabel
> + 7b89dc573b03e26ef0b620b5f73aaf116f0eaef9 Added Greek translation & glossary
>
The git-gui/git-gui-i18n.git repository is a fork that was created to do
the initial internationalization of git-gui I believe. It predates my
involvement with this project so I could be wrong.
We don't provide a mob branch but you could create your own fork on
repo.or.cz if you intend to do much development and then post merge
requests to this group and myself.
I think I'd prefer to see forks than use a mob branch. Or receive
patches or course.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: Which git command to be used to keep my local repo updated with the recent changes made to the original repo
From: Victor Engmark @ 2011-01-27 11:43 UTC (permalink / raw)
To: Akash; +Cc: git
In-Reply-To: <29999288.56562.1296123202254.JavaMail.trustmail@mail1.terreactive.ch>
On 01/27/2011 11:13 AM, Akash wrote:
>
> I am new to git , So I just wanted to know which git command to be used to
> keep my local repo updated with the recent changes made to the original repo
$ git help pull
This command is a combination of `git fetch` (to get the commit data)
and `git merge` (to merge that data with the current working copy).
Typically you want to get the data from the same place where you cloned
from, in which case a simple `git pull` should be sufficient. If not,
you should `git help remote` and `git help branch`.
--
Victor Engmark
^ permalink raw reply
* Which git command to be used to keep my local repo updated with the recent changes made to the original repo
From: Akash @ 2011-01-27 10:13 UTC (permalink / raw)
To: git
I am new to git , So I just wanted to know which git command to be used to
keep my local repo updated with the recent changes made to the original repo
--
View this message in context: http://git.661346.n2.nabble.com/Which-git-command-to-be-used-to-keep-my-local-repo-updated-with-the-recent-changes-made-to-the-origio-tp5965757p5965757.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* New Version Control System to be used for some software development projects
From: APARNA SHARAN @ 2011-01-27 7:46 UTC (permalink / raw)
To: git
Hi,
We are looking for 1 day training program on GIT, the open source distributed version control system used to manage small to large projects with speed and efficiency. Our company is based in Noida.
Kindly let us know if someone has an expertise in this area and can do the training for us.
Regards
Aparna Sharan
Asst. Manager - HR
SEL-India
Noida
Mb: +91-9910019281
^ permalink raw reply
* [PATCH v4] fast-import: treat filemodify with empty tree as delete
From: Jonathan Nieder @ 2011-01-27 6:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sverre Rabbelier, Git Mailing List, Ramkumar Ramachandra,
Shawn O. Pearce, David Barr
In-Reply-To: <7vd3nji54o.fsf@alter.siamese.dyndns.org>
Normal git processes do not allow one to build a tree with an empty
subtree entry without trying hard at it. This is in keeping with the
general UI philosophy: git tracks content, not empty directories.
v1.7.3-rc0~75^2 (2010-06-30) changed that by making it easy to include
an empty subtree in fast-import's active commit:
M 040000 4b825dc642cb6eb9a060e54bf8d69288fbee4904 subdir
One can trigger this by reading an empty tree (for example, the tree
corresponding to an empty root commit) and trying to move it to a
subtree. It is better and more closely analogous to 'git read-tree
--prefix' to treat such commands as requests to remove the subtree.
Noticed-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Junio C Hamano wrote:
> Hmm, why not on top of v1.7.3-rc0~75^2 aka 334fba6 (Teach fast-import to
> import subtrees named by tree id, 2010-06-30) then?
Okay, I found time to try it. Some other small simplifications while
at it.
fast-import.c | 6 ++++++
t/t9300-fast-import.sh | 42 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index ad6843a..cd9310d 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2163,6 +2163,12 @@ static void file_change_m(struct branch *b)
p = uq.buf;
}
+ /* Git does not track empty, non-toplevel directories. */
+ if (S_ISDIR(mode) && !memcmp(sha1, EMPTY_TREE_SHA1_BIN, 20) && *p) {
+ tree_content_remove(&b->branch_tree, p, NULL);
+ return;
+ }
+
if (S_ISGITLINK(mode)) {
if (inline_data)
die("Git links cannot be specified 'inline': %s",
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 50d5913..8487734 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -818,6 +818,48 @@ test_expect_success \
compare_diff_raw expect actual'
+test_expect_success \
+ 'N: delete directory by copying' \
+ 'cat >expect <<-\EOF &&
+ OBJID
+ :100644 000000 OBJID OBJID D foo/bar/qux
+ OBJID
+ :000000 100644 OBJID OBJID A foo/bar/baz
+ :000000 100644 OBJID OBJID A foo/bar/qux
+ EOF
+ empty_tree=$(git mktree </dev/null) &&
+ cat >input <<-INPUT_END &&
+ commit refs/heads/N-delete
+ committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+ data <<COMMIT
+ collect data to be deleted
+ COMMIT
+
+ deleteall
+ M 100644 inline foo/bar/baz
+ data <<DATA_END
+ hello
+ DATA_END
+ C "foo/bar/baz" "foo/bar/qux"
+ C "foo/bar/baz" "foo/bar/quux/1"
+ C "foo/bar/baz" "foo/bar/quuux"
+ M 040000 $empty_tree foo/bar/quux
+ M 040000 $empty_tree foo/bar/quuux
+
+ commit refs/heads/N-delete
+ committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+ data <<COMMIT
+ delete subdirectory
+ COMMIT
+
+ M 040000 $empty_tree foo/bar/qux
+ INPUT_END
+ git fast-import <input &&
+ git rev-list N-delete |
+ git diff-tree -r --stdin --root --always |
+ sed -e "s/$_x40/OBJID/g" >actual &&
+ test_cmp expect actual'
+
test_expect_success \
'N: modify copied tree' \
'cat >expect <<-\EOF &&
:100644 100644 fcf778cda181eaa1cbc9e9ce3a2e15ee9f9fe791 fcf778cda181eaa1cbc9e9ce3a2e15ee9f9fe791 C100 newdir/interesting file3/file5
--
1.7.4.rc3
^ permalink raw reply related
* Re: HTTP push not respecting .netrc
From: David Borowitz @ 2011-01-27 2:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tay Ray Chuan, git
In-Reply-To: <AANLkTi=cqsvXb3eywTfxAg9hH9cigumSQjoHqq5bnJfM@mail.gmail.com>
On Wed, Jan 26, 2011 at 18:00, David Borowitz <dave@bwitz.com> wrote:
> But this raises further questions:
> -Why does git/curl decide it's ok to retry with authentication in one
> case, but not in the other?
Poking further, it looks like curl is deciding not to retry because
the ioctl callback is failing to rewind the post buffer when clearly
it should be able to. So it's more likely a git bug than a curl issue
(the following question notwithstanding).
> -Why does curl send the auth header before ever receiving a 401, while
> git does not? (Would fixing this be as easy as setting another curl
> option?)
^ permalink raw reply
* Re: [PATCH] Fix wrong xhtml option to highlight
From: Drew Northup @ 2011-01-27 1:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jochen Schmitt, git
In-Reply-To: <7vvd1dlxza.fsf@alter.siamese.dyndns.org>
On Mon, 2011-01-24 at 14:48 -0800, Junio C Hamano wrote:
> Jochen Schmitt <Jochen@herr-schmitt.de> writes:
>
> > ---
> > Hallo,
> >
> > because I'm the maintainer of the highlight package in the
> > Fedora Project I was notified, that highlight doesn't works
> > properly with gitweb in BZ #672293.
> >
> > So I have create the following simple patch to solve the
> > reported issue.
> >
> > Best Regards
> >
> > Jochen Schmitt
> >
> > gitweb/gitweb.perl | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index 1025c2f..b662420 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -3468,7 +3468,7 @@ sub run_highlighter {
> > close $fd;
> > open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
> > quote_command($highlight_bin).
> > - " --xhtml --fragment --syntax $syntax |"
> > + " -xhtml --fragment --syntax $syntax |"
>
> Curious.
>
> Does the command take double-dash for the fragment and syntax options but
> a single dash for the xhtml option? Really...
>
> A few top hits returned by Google for "highlight manual page" tells me
> otherwise.
Certainly appears to be the case that "--xhtml" is the option in Ubuntu
10.04.1 LTS.
Jochen,
Did you mean "-X" (which sets the same option)?
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCH 2/2] rebase: give a better error message for bogus branch
From: Junio C Hamano @ 2011-01-27 1:27 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110127002711.GB32711@sigill.intra.peff.net>
Thanks, both patches look very sensible.
^ permalink raw reply
* Re: [PATCH jn/fast-import-fix v3] fast-import: treat filemodify with empty tree as delete
From: Jonathan Nieder @ 2011-01-27 0:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sverre Rabbelier, Git Mailing List, Ramkumar Ramachandra,
Shawn O. Pearce, David Barr
In-Reply-To: <7vd3nji54o.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Hmm. I suppose on top of b2124125 (jn/fast-import-fix).
>
> Hmm, why not on top of v1.7.3-rc0~75^2 aka 334fba6 (Teach fast-import to
> import subtrees named by tree id, 2010-06-30) then?
That could work, too. ;-)
I was too lazy to check if the test case happens to work in the
absence of the fixes from the fast-import-fix branch.
>> +++ b/fast-import.c
>> @@ -2194,6 +2194,16 @@ static void file_change_m(struct branch *b)
>> p = uq.buf;
>> }
>>
>> + /*
>> + * Git does not track empty, non-toplevel directories.
>> + */
>> + if (S_ISDIR(mode) &&
>> + !memcmp(sha1, (const unsigned char *) EMPTY_TREE_SHA1_BIN, 20) &&
>
> Do you need this cast?
No, it's not needed.
(EMPTY_TREE_SHA1_BIN is a string constant, originally intended for
use in initializers like
static const unsigned char empty_tree_sha1[20] = EMPTY_TREE_SHA1_BIN;
memcmp does not care about such considerations.)
^ permalink raw reply
* Re: [PATCH] tests: sanitize more git environment variables
From: Jeff King @ 2011-01-27 0:31 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v39ofl7ki.fsf@alter.siamese.dyndns.org>
On Wed, Jan 26, 2011 at 12:43:25PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > These variables should generally not be set in one's
> > environment, but they do get set by rebase, which means
> > doing an interactive rebase like:
> >
> > pick abcd1234 foo
> > exec make test
> >
> > will cause false negatives in the test suite.
>
> Cute. Thanks.
BTW, for anyone interested, I am using this with the following script:
-- >8 --
#!/bin/sh
upstream=`git rev-parse --symbolic-full-name "$1@{u}" >/dev/null 2>&1`
GIT_EDITOR='sed -i "/^pick .*/aexec make -j8 test"' \
git rebase -i "${upstream:-origin}" $1
-- 8< --
which is a convenient way of testing each commit in a patch series
before submitting it upstream (and it stops on test failure so you can
fix up that commit).
You can drop it in your PATH as "git-test" and run "git test" or "git
test <branch>".
-Peff
^ permalink raw reply
* [PATCH 2/2] rebase: give a better error message for bogus branch
From: Jeff King @ 2011-01-27 0:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When you give a non-existent branch to git-rebase, it spits
out the usage. This can be confusing, since you may
understand the usage just fine, but simply have made a
mistake in the branch name.
Before:
$ git rebase origin bogus
Usage: git rebase ...
After:
$ git rebase origin bogus
fatal: no such branch: bogus
Usage: git rebase ...
Signed-off-by: Jeff King <peff@peff.net>
---
git-rebase.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 345b18c..cbb0ea9 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -482,6 +482,7 @@ case "$#" in
then
head_name="detached HEAD"
else
+ echo >&2 "fatal: no such branch: $1"
usage
fi
;;
--
1.7.4.rc3.5.g8354b
^ permalink raw reply related
* [PATCH 1/2] rebase: use explicit "--" with checkout
From: Jeff King @ 2011-01-27 0:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In the case of a ref/pathname conflict, checkout will
already do the right thing and checkout the ref. However,
for a non-existant ref, this has two advantages:
1. If a file with that pathname exists, rebase will
refresh the file from the index and then rebase the
current branch instead of producing an error.
2. If no such file exists, the error message using an
explicit "--" is better:
# before
$ git rebase -i origin bogus
error: pathspec 'bogus' did not match any file(s) known to git.
Could not checkout bogus
# after
$ git rebase -i origin bogus
fatal: invalid reference: bogus
Could not checkout bogus
The problems seem to be trigger-able only through "git
rebase -i", as regular git-rebase checks the validity of the
branch parameter as a ref very early on. However, it doesn't
hurt to be defensive.
Signed-off-by: Jeff King <peff@peff.net>
---
git-rebase--interactive.sh | 2 +-
git-rebase.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a5ffd9a..7bd5602 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -894,7 +894,7 @@ first and then run 'git rebase --continue' again."
if test ! -z "$1"
then
- output git checkout "$1" ||
+ output git checkout "$1" -- ||
die "Could not checkout $1"
fi
diff --git a/git-rebase.sh b/git-rebase.sh
index d8e1903..345b18c 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -513,7 +513,7 @@ then
if test -z "$force_rebase"
then
# Lazily switch to the target branch if needed...
- test -z "$switch_to" || git checkout "$switch_to"
+ test -z "$switch_to" || git checkout "$switch_to" --
say "Current branch $branch_name is up to date."
exit 0
else
--
1.7.4.rc3.5.g8354b
^ permalink raw reply related
* Re: [PATCH jn/fast-import-fix v3] fast-import: treat filemodify with empty tree as delete
From: Junio C Hamano @ 2011-01-27 0:04 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sverre Rabbelier, Junio C Hamano, Git Mailing List,
Ramkumar Ramachandra, Shawn O. Pearce, David Barr
In-Reply-To: <20110126230608.GA26787@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Sverre Rabbelier wrote:
>
>> Should it go on maint now that it's factored out, since it shipped in
>> 1.7.3, or just master?
>
> Hmm. I suppose on top of b2124125 (jn/fast-import-fix).
Hmm, why not on top of v1.7.3-rc0~75^2 aka 334fba6 (Teach fast-import to
import subtrees named by tree id, 2010-06-30) then?
> While applying it there I noticed that the change to t9300 includes an
> unrelated change (residue of an old rebase). Here's a fixed version.
> diff --git a/fast-import.c b/fast-import.c
> index d881630..9cf26f1 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -2194,6 +2194,16 @@ static void file_change_m(struct branch *b)
> p = uq.buf;
> }
>
> + /*
> + * Git does not track empty, non-toplevel directories.
> + */
> + if (S_ISDIR(mode) &&
> + !memcmp(sha1, (const unsigned char *) EMPTY_TREE_SHA1_BIN, 20) &&
Do you need this cast?
^ permalink raw reply
* Re: [RFC] fast-import: 'cat-blob' and 'ls' commands
From: Sam Vilain @ 2011-01-26 23:46 UTC (permalink / raw)
To: Jonathan Nieder
Cc: vcs-fast-import-devs, David Barr, Git Mailing List,
Ramkumar Ramachandra, Sverre Rabbelier, Shawn O. Pearce,
Tomas Carnecky
In-Reply-To: <20110126213922.GA19727@burratino>
On 27/01/11 07:39, Jonathan Nieder wrote:
> Hi fast importers,
>
> I would like your thoughts on a few developments in fast-import
> protocol (thanks to David, Ram, Sverre, Tomas, and Sam for work so
> far). If they seem good, I'd be happy to help make patches to other
> backends so these can be implemented widely.
>
> Contents: cat-blob command, filemodify (M) with trees, ls command.
Ok. My first thoughts here are to be careful about the design: this
fast-import protocol is fast becoming close to getting an RFC, having
multiple interoperable implementations available, so do consider whether
all syntax will be cleanly extensible to eventually support full basic
plumbing requirements.
ie, using the command 'cat-blob' instead of a 'cat' command with 'blob'
as an argument as git cat-file currently works seems to be an
inflexibility and may eventually be considered legacy.
Otherwise it looks fine, seems to support all the file types etc.
Thanks for keeping the work up!
Cheers,
Sam
^ permalink raw reply
* [PATCH jn/fast-import-fix v3] fast-import: treat filemodify with empty tree as delete
From: Jonathan Nieder @ 2011-01-26 23:06 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Git Mailing List, Ramkumar Ramachandra,
Shawn O. Pearce, David Barr
In-Reply-To: <AANLkTimNWLFgTk0Bueiscw-WkAX53v0Xsepn9esXOt7+@mail.gmail.com>
Date: Sat, 11 Dec 2010 16:42:28 -0600
Normal git processes do not allow one to build a tree with an empty
subtree entry without trying hard at it. This is in keeping with the
general UI philosophy: git tracks content, not empty directories.
Unfortunately, v1.7.3-rc0~75^2 (2010-06-30) changed that by making it
easy to include an empty subtree in fast-import's active commit:
M 040000 4b825dc642cb6eb9a060e54bf8d69288fbee4904 subdir
It is easy to trigger this by accident by reading an empty tree (for
example, the tree corresponding to an empty root commit) and trying to
move it to a subtree. It would be better and more closely analogous
to "git read-tree --prefix" to treat such commands as a request to
remove ("to empty") the subdir.
Noticed-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Sverre Rabbelier wrote:
> Should it go on maint now that it's factored out, since it shipped in
> 1.7.3, or just master?
Hmm. I suppose on top of b2124125 (jn/fast-import-fix).
While applying it there I noticed that the change to t9300 includes an
unrelated change (residue of an old rebase). Here's a fixed version.
fast-import.c | 10 ++++++++++
t/t9300-fast-import.sh | 42 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index d881630..9cf26f1 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2194,6 +2194,16 @@ static void file_change_m(struct branch *b)
p = uq.buf;
}
+ /*
+ * Git does not track empty, non-toplevel directories.
+ */
+ if (S_ISDIR(mode) &&
+ !memcmp(sha1, (const unsigned char *) EMPTY_TREE_SHA1_BIN, 20) &&
+ *p) {
+ tree_content_remove(&b->branch_tree, p, NULL);
+ return;
+ }
+
if (S_ISGITLINK(mode)) {
if (inline_data)
die("Git links cannot be specified 'inline': %s",
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index dd90a09..ef3a347 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -875,6 +875,48 @@ test_expect_success \
compare_diff_raw expect actual'
+test_expect_success \
+ 'N: delete directory by copying' \
+ 'cat >expect <<-\EOF &&
+ OBJID
+ :100644 000000 OBJID OBJID D foo/bar/qux
+ OBJID
+ :000000 100644 OBJID OBJID A foo/bar/baz
+ :000000 100644 OBJID OBJID A foo/bar/qux
+ EOF
+ empty_tree=$(git mktree </dev/null) &&
+ cat >input <<-INPUT_END &&
+ commit refs/heads/N-delete
+ committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+ data <<COMMIT
+ collect data to be deleted
+ COMMIT
+
+ deleteall
+ M 100644 inline foo/bar/baz
+ data <<DATA_END
+ hello
+ DATA_END
+ C "foo/bar/baz" "foo/bar/qux"
+ C "foo/bar/baz" "foo/bar/quux/1"
+ C "foo/bar/baz" "foo/bar/quuux"
+ M 040000 $empty_tree foo/bar/quux
+ M 040000 $empty_tree foo/bar/quuux
+
+ commit refs/heads/N-delete
+ committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+ data <<COMMIT
+ delete subdirectory
+ COMMIT
+
+ M 040000 $empty_tree foo/bar/qux
+ INPUT_END
+ git fast-import <input &&
+ git rev-list N-delete |
+ git diff-tree -r --stdin --root --always |
+ sed -e "s/$_x40/OBJID/g" >actual &&
+ test_cmp expect actual'
+
test_expect_success \
'N: copy root directory by tree hash' \
'cat >expect <<-\EOF &&
:100755 000000 f1fb5da718392694d0076d677d6d0e364c79b0bc 0000000000000000000000000000000000000000 D file3/newf
--
1.7.4.rc3
^ permalink raw reply related
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