* [1.8.0] Tracking empty directories
From: Jakub Narebski @ 2011-02-02 11:56 UTC (permalink / raw)
To: git
In-Reply-To: <7vwrll57ha.fsf@alter.siamese.dyndns.org>
See "Tracking empty directories" subthread on git mailing list,
starting with
http://thread.gmane.org/gmane.comp.version-control.git/165655/focus=165831
The idea is for git to be able to track empty directories without the
.keepme (or empty .gitignore) file trick. This was one of the most
requested features is native support for tracking empty directories,
with 35.2% support (from those who answered question) in
"Git User's Survey 2010":
https://git.wiki.kernel.org/index.php/GitSurvey2010#17._Which_of_the_following_features_would_you_like_to_see_implemented_in_git.3F
There were some concerns about *backwards compatibility* of this
feature, see for example this email (which I would summarize here).
http://thread.gmane.org/gmane.comp.version-control.git/165655/focus=165847
That's why it is in 1.8.0 proposals.
The problem with backward compatibility is twofold. First and more
important is while git supports empty tree object (it has it hardcoded
for some time, as it is necessary e.g. for initial diff, or merging
unrelated branches without common ancestor), and there is no problem
with entry for empty tree in a tree object
040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb empty
there is (supposedly) problem when checking out such tree (see email
referenced above) with an old git.
Second is that tracking empty directories would require extension to the
git index (storing trees in index, like we store submodules)... but that
is purely local matter.
There is also issue with pre-change git automatically removing empty
directories, but that is probably matter for pre-commit hook to check,
or pre-receive hook in publishing repository.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: moving to a git-backed wiki
From: Jakub Narebski @ 2011-02-02 11:14 UTC (permalink / raw)
To: Felipe Contreras
Cc: Vincent Hanquez, J.H., Jay Soffian, Jeff King, Scott Chacon,
Junio C Hamano, git
In-Reply-To: <AANLkTi=07yifUAQYqabA8Dv1qmBTe=50+BDN-b0YZ1zb@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Wed, Feb 2, 2011 at 11:55 AM, Vincent Hanquez <tab@snarc.org> wrote:
>> On 01/02/11 22:48, J.H. wrote:
>>>
>>> The wiki will almost universally have a "central site" no matter what
>>> the backend. Personally I see little advantage to having a git backed
>>> wiki myself.
>>
>> with git based wiki, you can clone the whole wiki on your local machine, and
>> read/edit/commit on it locally using standard editor tool (i.e. $EDITOR).
>> and the history/revision/diff is completely built-in.
>
> But there's no git based wiki (or any other wiki) that has even a
> fraction of the features that MediaWiki has, or IMO a markup format
> similarly sane.
Gollum (the engine used by git-based wikis on GitHub) offers support
for MediaWiki format. I don't know how it is with editing and
presenting history (end e.g. reverting spam), especially on older or
text browsers.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: moving to a git-backed wiki
From: Felipe Contreras @ 2011-02-02 10:53 UTC (permalink / raw)
To: Vincent Hanquez
Cc: J.H., Jay Soffian, Jeff King, Scott Chacon, Junio C Hamano, git
In-Reply-To: <4D4929F4.3020805@snarc.org>
On Wed, Feb 2, 2011 at 11:55 AM, Vincent Hanquez <tab@snarc.org> wrote:
> On 01/02/11 22:48, J.H. wrote:
>>
>> The wiki will almost universally have a "central site" no matter what
>> the backend. Personally I see little advantage to having a git backed
>> wiki myself.
>
> with git based wiki, you can clone the whole wiki on your local machine, and
> read/edit/commit on it locally using standard editor tool (i.e. $EDITOR).
> and the history/revision/diff is completely built-in.
But there's no git based wiki (or any other wiki) that has even a
fraction of the features that MediaWiki has, or IMO a markup format
similarly sane.
--
Felipe Contreras
^ permalink raw reply
* Re: moving to a git-backed wiki
From: Vincent Hanquez @ 2011-02-02 9:55 UTC (permalink / raw)
To: J.H.; +Cc: Jay Soffian, Jeff King, Scott Chacon, Junio C Hamano, git
In-Reply-To: <4D488DCD.3080305@eaglescrag.net>
On 01/02/11 22:48, J.H. wrote:
> The wiki will almost universally have a "central site" no matter what
> the backend. Personally I see little advantage to having a git backed
> wiki myself.
with git based wiki, you can clone the whole wiki on your local machine,
and read/edit/commit on it locally using standard editor tool (i.e.
$EDITOR). and the history/revision/diff is completely built-in.
--
Vincent
^ permalink raw reply
* Re: problem when pulling a specific branch from origin
From: Ivan Kanis @ 2011-02-02 9:54 UTC (permalink / raw)
To: Konstantin Khomoutov; +Cc: git
In-Reply-To: <20110202001734.GL5713@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 3355 bytes --]
Hi Konstantin,
Thanks for your thorough answer.
Konstantin Khomoutov <flatworm@users.sourceforge.net> wrote:
> The first one is that you seem to maintain a wrong idea about what
> happens when you do `git pull origin branch`. It appears you assume
> this action is supposed to first update the local branch
> "remotes/origin/branch" and then merge it to the locally checked out
> branch. The truth is that specifying a branch in this way to git-pull
> (or git-fetch, which is called by git-pull) is a special case -- it
> means that no corresponding local ref is updated, and the fetched line
> of history is directly merged into the checked out branch right after
> fetching (see the git-fetch manual and the EXAMPLES section in the
> git-pull manual).
You're right I get the wrong idea of pull origin branch, it's a special
case and it doesn't update local ref.
> I'm not really sure about your expectation as you did not clearly
> articulate them, so it seems there are two points to touch here...
I expect my local ref to be updated with the server ref.
> In your particular case you're merging remote branch "branch" which is
> one commit ahead of remote "master" to the locally checked branch
> "master" which is, at the moment, the same as the same-named remote
> branch. Consequently, after merging "branch" (which results in
> fast-forward) your local branch "master" starts to be one commit ahead
> of its remote counterpart; no local branches beyond this one are
> updated.
I forgot to checkout the branch in the repository bar, I have attached
the updated script. The result is the same my branch is one commit ahead.
If we run git fetch without argument the refs are updated:
yan:~/tmp/bar$ git fetch
From /home/ivan/tmp/foo
6fe0a63..ebcae31 branch -> origin/branch
However running fetch without arguments pull all remote refs which my
developer does not want. Is there a command to update a specific
remote ref?
> The second point is less clear/more complicated.
> At first, it's not clear whether you wanted to have the remote branch
> "branch" become the active local branch during the cloning process, or
> "master" (in your case "master" became the active branch).
> On the one hand, you explicitly branched "branch" off "master" right
> before cloning (updating the first repo's HEAD ref) which hints you
> intended that branch to be default in the clone.
> On the other hand, while the documentation says the default branch in
> the clone is the one listed in the HEAD ref of the source repository, in
> my tests using Git (1.7.2.x in Debian and msysgit 1.7.3.x), in cases
> like yours the destination repository ends up having the "master" branch
> as the default one, not the branch from the HEAD ref; to make this work,
> the branch listed in the HEAD ref should have received at least one
> commit after forking. I suspect the problem might be in that such a
> branch freshly cloned off "master" points to the same commit object's
> name which might confuse Git.
> This, in my eyes, might indeed display a bug.
The current behavior is a bit weird to say the least, I don't know if
it's a bug.
Take care,
--
Ivan Kanis
http://kanis.fr
At Group L, Stoffel oversees six first-rate programmers, a
managerial challenge roughly comparable to herding cats.
-- Anonymous , 1985-06-09 , The Washington Post
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: repro.sh --]
[-- Type: text/x-sh, Size: 296 bytes --]
#!/bin/sh
rm -rf foo bar
git --version
mkdir foo
cd foo
git init
echo foo > foo.txt
git add foo.txt
git commit -am"foo"
git checkout -b branch
cd ..
git clone foo bar
cd foo
echo bar > foo.txt
git commit -am"bar"
cd ..
cd bar
git checkout branch
git pull origin branch
git status
git branch -rv
^ permalink raw reply
* [BUG] "git apply --index" with missing --directory option silently does nothing
From: Yann Dirson @ 2011-02-02 9:24 UTC (permalink / raw)
To: git list
When applying a patch file for a subtree of a git repo, where was
required is "git apply --index --directory=...", if the user forgets
to add the --directory flag, then git should bomb out saying it cannot
apply the patch.
But what happens is that nothing happens, and git stays silent about
having done nothing:
~/softs/tmp/linux-2.6.32$ git rev-parse --git-dir
/home/localadm/softs/tmp/.git
~/softs/tmp/linux-2.6.32$ bzcat /home/localadm/Downloads/patch-2.6.32.28.bz2 | git apply --index --whitespace=nowarn
~/softs/tmp/linux-2.6.32$ echo $?
0
~/softs/tmp/linux-2.6.32$ git status
# On branch master
nothing to commit (working directory clean)
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Erik Faye-Lund @ 2011-02-02 8:31 UTC (permalink / raw)
To: George Spelvin; +Cc: git
In-Reply-To: <20110202022909.30644.qmail@science.horizon.com>
On Wed, Feb 2, 2011 at 3:29 AM, George Spelvin <linux@horizon.com> wrote:
> If there's a compelling reason to change, could someone please describe it?
I think the most compelling argument I can think of is that it makes
top-level entries like Documentation, RelNotes, COPYING, README and
INSTALL easier to spot when doing "ls". For some users (first-time
hackers etc) that's a pretty big plus, I'd think.
^ permalink raw reply
* [PATCH 2/2] fast-import: introduce "feature notes" command
From: Jonathan Nieder @ 2011-02-02 5:07 UTC (permalink / raw)
To: git
Cc: Johan Herland, Sverre Rabbelier, Ramkumar Ramachandra,
Shawn O. Pearce, Sam Vilain
In-Reply-To: <20110202045826.GC15285@elie>
Here is a "feature" command for streams to use to require support for
the notemodify (N) command.
Support for importing notes was added to git fast-import quite a while
ago (v1.6.6-rc0~21^2~8, 2009-10-09), before the 'feature' facility was
introduced (v1.7.0-rc0~95^2~4, fast-import: add feature command,
2009-12-04) so for compatibility with older git versions, authors
of existing frontends should not start using the "feature notes"
command. Most git versions in wide use support notemodify already.
The purpose of the "feature notes" declaration is instead to
distinguish between git and fast-import backends that do not support
notemodify. In git "feature notes" will be a no-op while in other
current fast-import backends it will error out with a clear error
message.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Still to do: the documentation does not hint at the point mentioned
in paragraphs 2 and 3 above. Ideas for wording?
Aside from that, I think this is ready. Thanks for reading.
Documentation/git-fast-import.txt | 12 +++++++-----
fast-import.c | 6 ++++--
t/t9301-fast-import-notes.sh | 1 +
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 086b14f..2393252 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -942,11 +942,13 @@ import-marks::
any "feature import-marks" command in the stream.
cat-blob::
- Ignored. Versions of fast-import not supporting the
- "cat-blob" command will exit with a message indicating so.
- This lets the import error out early with a clear message,
- rather than wasting time on the early part of an import
- before the unsupported command is detected.
+ Require that the backend support the 'cat-blob' command.
+ Versions of fast-import not supporting the 'cat-blob'
+ command will exit with a message indicating so.
+
+notes::
+ Require that the backend support the 'notemodify' (N)
+ subcommand to the 'commit' command.
`option`
~~~~~~~~
diff --git a/fast-import.c b/fast-import.c
index 60f26fe..bf2f9f8 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2983,14 +2983,16 @@ static int parse_one_feature(const char *feature, int from_stream)
option_import_marks(feature + 13, from_stream);
} else if (!prefixcmp(feature, "export-marks=")) {
option_export_marks(feature + 13);
- } else if (!strcmp(feature, "cat-blob")) {
- ; /* Don't die - this feature is supported */
} else if (!prefixcmp(feature, "relative-marks")) {
relative_marks_paths = 1;
} else if (!prefixcmp(feature, "no-relative-marks")) {
relative_marks_paths = 0;
} else if (!prefixcmp(feature, "force")) {
force_update = 1;
+ }
+ /* These features are present; don't error out for them. */
+ else if (!strcmp(feature, "cat-blob")) {
+ } else if (!strcmp(feature, "notes")) {
} else {
return 0;
}
diff --git a/t/t9301-fast-import-notes.sh b/t/t9301-fast-import-notes.sh
index 7cf8cd8..463254c 100755
--- a/t/t9301-fast-import-notes.sh
+++ b/t/t9301-fast-import-notes.sh
@@ -120,6 +120,7 @@ test_expect_success 'add notes with simple M command' '
test_tick
cat >input <<INPUT_END
+feature notes
commit refs/notes/test
committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
data <<COMMIT
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/2] Documentation/fast-import: explain how to remove a note
From: Jonathan Nieder @ 2011-02-02 5:00 UTC (permalink / raw)
To: git
Cc: Johan Herland, Sverre Rabbelier, Ramkumar Ramachandra,
Shawn O. Pearce, Sam Vilain
In-Reply-To: <20110202045826.GC15285@elie>
A notemodify (N) command with blob id consisting of 40 zeroes (so
is_null_sha1 is true) means to not add a note to replace the existing,
removed one.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-fast-import.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 4415e63..086b14f 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -651,9 +651,9 @@ External data format::
'N' SP <dataref> SP <committish> LF
....
+
-Here `<dataref>` can be either a mark reference (`:<idnum>`)
-set by a prior `blob` command, or a full 40-byte SHA-1 of an
-existing Git blob object.
+Here `<dataref>` can be a mark reference (`:<idnum>`)
+set by a prior `blob` command, a full 40-byte SHA-1 of an
+existing Git blob object, or 40 zeroes, to remove a note.
Inline data format::
The data content for the note has not been supplied yet.
--
1.7.2.3
^ permalink raw reply related
* [PATCH/RFC 0/2] fast-import: introduce "feature notes" command
From: Jonathan Nieder @ 2011-02-02 4:58 UTC (permalink / raw)
To: git
Cc: Johan Herland, Sverre Rabbelier, Ramkumar Ramachandra,
Shawn O. Pearce, Sam Vilain
Hi,
As promised, here is a "feature" command for streams to use to require
support for the notemodify (N) command.
Patch 1 explains how to delete notes. On first reading, I had thought
that feature was missing.
Patch 2 is the title feature. The relevant message explains why
this is an rfc.
Thoughts welcome, as always.
Jonathan Nieder (2):
Documentation/fast-import: explain how to delete a note
fast-import: introduce "feature notes" command
Documentation/git-fast-import.txt | 18 ++++++++++--------
fast-import.c | 6 ++++--
t/t9301-fast-import-notes.sh | 1 +
3 files changed, 15 insertions(+), 10 deletions(-)
^ permalink raw reply
* Re: [1.8.0] Change branch --set-uptream to take an argument
From: Jay Soffian @ 2011-02-02 4:18 UTC (permalink / raw)
To: Miles Bader; +Cc: Junio C Hamano, git
In-Reply-To: <buohbcn3wp5.fsf@dhlpc061.dev.necel.com>
On Tue, Feb 1, 2011 at 11:08 PM, Miles Bader <miles@gnu.org> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>> Okay, our emails criss-crossed. I agree with that, but my other email
>> proposes adding -u <name> with correct behavior and just deprecating
>> --set-upstream. I suppose we could instead (or in addition) just fix
>> --set-upstream.
>
> BTW, you're just talking about "git branch", right?
>
> ['cause the way "--set-upstream" works with "git push" is perfect, and
> shouldn't be changed...]
I was talking about git-branch and git-checkout. I didn't realize
git-push even had --set-upstream. Interestingly, -u is an alias for
--set-upstream with git-push, but not with git-branch.
j.
^ permalink raw reply
* Re: [1.8.0] Change branch --set-uptream to take an argument
From: Miles Bader @ 2011-02-02 4:08 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, git
In-Reply-To: <AANLkTi=gvVwh-H9FiGz6SQeJYwxmnnViYsDQX=RYRjb6@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Okay, our emails criss-crossed. I agree with that, but my other email
> proposes adding -u <name> with correct behavior and just deprecating
> --set-upstream. I suppose we could instead (or in addition) just fix
> --set-upstream.
BTW, you're just talking about "git branch", right?
['cause the way "--set-upstream" works with "git push" is perfect, and
shouldn't be changed...]
-miles
--
Selfish, adj. Devoid of consideration for the selfishness of others.
^ permalink raw reply
* Re: Tracking empty directories
From: Nguyen Thai Ngoc Duy @ 2011-02-02 3:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jonathan Nieder, Dmitry S. Kravtsov, git, Shawn Pearce
In-Reply-To: <201102012003.50941.jnareb@gmail.com>
On Wed, Feb 2, 2011 at 2:03 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> To add, one would use "git update-index --add".
>
> Porcelain version could be "git add -N <directory>", don't you agree?
"git add" is recursive, with or without -N. What I worry is user
accidentally "git add -N <dir>" where <dir> is not empty, which adds
everything in <dir>.
>> The magic disappears when you register a file within that directory;
>> to tell git you want to keep it, one would mkdir and
>> "git update-index --add" again. Once it's working, we can think about
>> if there is a need for making that last step automatic after all
>> (my guess: "no"). ;-)
>
> Hmmm... could we use mechanism similar to assume-unchanged to mark
> directory as explicitely tracked, and that git should not remove it
> when it becomes empty?
I think git-attr suits better, more persistent. Although if you insist
the directory must stay, why not just put a hidden file in there?
--
Duy
^ permalink raw reply
* Re: [PATCH 2/3] t9010-svn-fi: Add tests for svn-fi
From: Jonathan Nieder @ 2011-02-02 3:18 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, David Barr, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <20110202024944.GA11339@kytes>
Ramkumar Ramachandra wrote:
> Jonathan Nieder writes:
>> Ramkumar Ramachandra wrote:
>> Is it impossible to test without svn present or otherwise speed
>> these up? Some random ideas:
[...]
> Hm, I'm not entirely convinced -- the final verdict is always dictated
> by whether or not the emitted dumpstream loads. Many streams that look
> alright to the eye don't actually load because of small intricacies
> like missing newlines. It'll be awfully complicated reverse-engineer
> all these intricate rules and write them in terms of sed/ awk
> commands. Yes, svnrdump will be faster, but it'll only be available
> with the later versions of Subversion (same problem with fixing
> svnadmin bottlenecks).
If svnrdump is fast enough, wouldn't something like
if svnrdump --help >/dev/null 2>&1
then
load_dump () {
svnrdump load "file://$1"
}
test_set_prereq SVN
elif svnadmin --help >/dev/null 2>&1
then
load_dump () {
svnadmin load "$1"
}
test_set_prereq SVN
else
: no usable svn installation
fi
do it?
>>> +svn_look () {
>>> + subcommand=$1 &&
>>> + shift &&
>>> + svnlook "$subcommand" "$svnrepo" "$@"
>>> +}
[...]
> Just a convinience: I am using svn_look to look at the properties of
> nodes in several tests.
Ah, I missed the implicit $svnrepo argument. Makes sense then (might
be good to have a comment to explain the purpose, though).
>>> +test_expect_success 'normal empty files' '
>>> + reinit_svn &&
>>> + cat >expect.tree <<-\EOF &&
>>> + /
>>> + foo
>>> + bar
>>> + EOF
>>> + cat >input <<-\EOF &&
>>> + reset refs/heads/master
>>> + commit refs/heads/master
>>> + mark :1
>>> + author nobody <nobody@localhost> 1170199019 +0100
>>> + committer nobody <nobody@localhost> 1170199019 +0100
>>
>> Where do the dates come from? Why should I (the reader) expect
>> them?
>
> What do you suggest? I need some valid "generic" timestamp + offset.
test_tick
...
author nobody <nobody@localhost> $GIT_AUTHOR_DATE
[...]
> Okay, I'll try this. Is there no other way? Can we whip up a shell
> script to convert the timestamp?
Maybe the standard "date" utility can help with conversions?
I'm not sure what kinds of validation you're doing on the dates, hence
the vague answers. For examples of fuzzing out the unimportant bits,
git grep fuzz t/*.sh
can help.
>>> +test_expect_success 'malformed fast-import stream: author 2' '
[...]
>>> + try_load input must_fail
>>
>> What's wrong with this stream?
>
> author nobody <localhost>
> ^
> Parse error there, since build_svn_author tries to use the part of the
> email address appearing before the '@'. This is just a temporary test
> -- we should make the svn_author generation logic configurable.
So the stream is not malformed? In that case, I guess the
intent is
test_expect_failure 'does something reasonable with email address without @' '
...
try_load input
'
Thanks again.
Jonathan
^ permalink raw reply
* Re: [PATCH 3/3] vcs-svn: Refactor dump_export code into dispatch table
From: Ramkumar Ramachandra @ 2011-02-02 2:56 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git List, David Barr, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <20110201174241.GB3771@burratino>
Hi Jonathan,
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>
> > +++ b/vcs-svn/dump_export.c
> > @@ -11,6 +11,48 @@
> [...]
> > +static state_fn *const dispatch_table[NODE_KIND_COUNT][NODE_ACTION_COUNT] = {
> > + /* NODE_KIND_UNKNOWN */
> > + {abort, abort, abort, Adelete, abort},
> > + /* NODE_KIND_NORMAL */
> > + {abort, Nchange, Nadd, Adelete, Nreplace},
> > + /* NODE_KIND_EXECUTABLE */
> > + {abort, Echange, Eadd, Adelete, Ereplace},
> > + /* NODE_KIND_SYMLINK */
> > + {abort, Schange, Sadd, Adelete, Sreplace},
> > + /* NODE_KIND_GITLINK */
> > + {abort, abort, abort, abort, abort},
> > + /* NODE_KIND_DIR */
> > + {abort, Dchange, Dadd, Adelete, Dreplace},
> > + /* NODE_KIND_SUBDIR */
> > + {abort, abort, abort, abort, abort}
> > +};
>
> Heh. I think that Junio was suggesting making the _parser_
> table-driven, meaning something like
Oops :p I'll fix this in the next round.
> ... node_kinds[] = {
> { "100644", sizeof("100644"), "file" },
> { "100755", sizeof("100755"), "file", "svn:executable" },
> { "120000", sizeof("120000"), "file", "svn:special" },
> { "160000", sizeof("160000"), "file" }, /* NEEDSWORK: seems wrong" */
> { "040000", sizeof("040000"), "dir" }
> };
>
> (Side note: remember that 644 and 755 are permitted synonyms for
> 100644 and 100755!)
>
> I personally think that simple state machines tend to be easier to
> follow if the current state is represented by the instruction pointer
> rather than a variable, as in the current fast-import.c. But maybe
> that's a matter of taste?
>
> Anyway, my other complaints about this dispatch_table are that the
> function names leave me rubbing my head and I can't keep the list
> of states you're transitioning between straight in my head. I guess
> "Adelete" is an abbreviation for print_delete_node_action? Is a
> callback needed at all (rather than just a string) for such actions?
True -- there are many intermediate layers where all kinds of
variables are getting set. It'll probably be a good idea to remove all
these abstraction layers and map fast-import commands directly to
dumpstream strings. I'll do this in the next iteration.
-- Ram
^ permalink raw reply
* Re: [PATCH 1/3] vcs-svn: Introduce svnload, a dumpfile producer
From: Ramkumar Ramachandra @ 2011-02-02 2:53 UTC (permalink / raw)
To: Erik Faye-Lund
Cc: Git List, Jonathan Nieder, David Barr, Sverre Rabbelier,
Junio C Hamano
In-Reply-To: <AANLkTikUUojgj_H0r0L=XBi7H714xUvAS=vPsgMRNNjr@mail.gmail.com>
Hi Erik,
Erik Faye-Lund writes:
> A very superficial review, because I don't have much time, and don't
> know the surrounding code well. Sorry about that.
Thanks. I have to often switch back and fourth between GNU-style (for
Subversion) and Linux-style (for Git), so please bear with my silly
style errors.
> On Tue, Feb 1, 2011 at 3:26 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:
> > + if (!val) die("Malformed author line");
> > + if (!(tz_off = strrchr(val, ' '))) goto error;
> > + *tz_off++ = '\0';
> > + if (!(t = strrchr(val, ' '))) goto error;
>
> style: use
> "if (x)
> do_stuff();"
> instead of
> "if (x) do_stuff();"
This was intentional -- I'm only using it when do_stuff() is 'goto
error'. I thought it looked nicer that way.
-- Ram
^ permalink raw reply
* Re: [PATCH 2/3] t9010-svn-fi: Add tests for svn-fi
From: Ramkumar Ramachandra @ 2011-02-02 2:49 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git List, David Barr, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <20110201185817.GG3771@burratino>
Hi Jonathan,
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>
> > Create a test-svn-fi in toplevel directory, add rules to build it, and
> > add some basic tests.
>
> Thanks. Probably this should be squashed with patch #1?
Right. Will do.
> > --- /dev/null
> > +++ b/t/t9010-svn-fi.sh
>
> Test number's already taken. 9012 is free, though.
Ok. Will rename in the next iteration.
> > @@ -0,0 +1,303 @@
> > +#!/bin/sh
> > +
> > +test_description='check svn dumpfile exporter'
> > +
> > +. ./test-lib.sh
> > +
> > +if ! svnadmin -h >/dev/null 2>&1
> > +then
> > + skip_all='skipping svn-fi tests, svn not available'
> > + test_done
> > +fi
>
> Is it impossible to test without svn present or otherwise speed
> these up? Some random ideas:
>
> - feed svn-fi output into svn-fe and compare git repos
> - check if "svn-fi after svn-fe" is idempotent (should it be?)
> - check for individual salient features from svn-fi output, using
> "grep", "sed", or "awk" to ignore the rest
> - use svnrdump in place of "svnadmin load" if available (is it
> faster?)
> - find the bottleneck in svnadmin and fix it
>
> Of course at least one test of the "svn-fe | svnadmin load"
> pipeline seems worthwhile; I'm just thinking we should avoid
> habits that slow down the test suite too much.
Hm, I'm not entirely convinced -- the final verdict is always dictated
by whether or not the emitted dumpstream loads. Many streams that look
alright to the eye don't actually load because of small intricacies
like missing newlines. It'll be awfully complicated reverse-engineer
all these intricate rules and write them in terms of sed/ awk
commands. Yes, svnrdump will be faster, but it'll only be available
with the later versions of Subversion (same problem with fixing
svnadmin bottlenecks).
> > +svn_look () {
> > + subcommand=$1 &&
> > + shift &&
> > + svnlook "$subcommand" "$svnrepo" "$@"
> > +}
>
> Needed? The svn_cmd function exists to point to a configuration
> directory.
Just a convinience: I am using svn_look to look at the properties of
nodes in several tests. If I don't use this in enough tests, I'll
factor it out.
> > +test_expect_success 'normal empty files' '
> > + reinit_svn &&
> > + cat >expect.tree <<-\EOF &&
> > + /
> > + foo
> > + bar
> > + EOF
> > + cat >input <<-\EOF &&
> > + reset refs/heads/master
> > + commit refs/heads/master
> > + mark :1
> > + author nobody <nobody@localhost> 1170199019 +0100
> > + committer nobody <nobody@localhost> 1170199019 +0100
>
> Where do the dates come from? Why should I (the reader) expect
> them?
What do you suggest? I need some valid "generic" timestamp + offset.
> > +# TODO: How to test date? Need to convert from local timestamp
>
> Ah, you saw. :)
>
> One possibility is to fuzz away whatever is unimportant when
> comparing results (and using tools like "awk" to extract the
> date to perform whatever tests on it are appropriate where it
> matters).
Okay, I'll try this. Is there no other way? Can we whip up a shell
script to convert the timestamp?
> > +test_expect_success 'malformed fast-import stream: author 2' '
> > + reinit_svn &&
> > + cat >input <<-\EOF &&
> > + reset refs/heads/master
> > + commit refs/heads/master
> > + mark :1
> > + author nobody <localhost> 1170199019 +0100
> > + committer nobody <nobody@localhost> 1170199019 +0100
> > + data 0
> > + M 100644 inline foo
> > + data 0
> > +
> > + EOF
> > + try_load input must_fail
>
> What's wrong with this stream?
author nobody <localhost>
^
Parse error there, since build_svn_author tries to use the part of the
email address appearing before the '@'. This is just a temporary test
-- we should make the svn_author generation logic configurable.
> > +test_expect_success 'svn:special and svn:executable' '
> > + reinit_svn &&
> > + cat >input <<-\EOF &&
> > + reset refs/heads/master
> > + commit refs/heads/master
> > + mark :1
> > + author nobody <nobody@localhost> 1170199019 +0100
> > + committer nobody <nobody@localhost> 1170199019 +0100
> > + data 7
> > + nothing
> > + M 100755 inline foo
> > + data 0
> > + M 755 inline moo
> > + data 0
> > + M 120000 inline bar
> > + data 0
> > +
> > + EOF
> > + try_load input &&
> > + svn_look propget svn:executable foo &&
> > + svn_look propget svn:executable moo &&
> > + svn_look propget svn:special bar
>
> Maybe worth checking for the absence of svn:executable +
> svn:special from an ordinary file, too?
Good idea.
> > +test_expect_success 'replace symlink with normal file' '
>
> Nice. "replace symlink with executable" and "replace symlink
> with directory" might also be interesting.
Good idea. Will do.
-- Ram
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: George Spelvin @ 2011-02-02 2:29 UTC (permalink / raw)
To: git; +Cc: linux
For what it's worth, I don't see the "cleanup".
If it significantly reduced the size of the largest directory,
that would be a win. But moving everything into src/ doesn't
do that.
If there's a way to divide the source into cohesive subunits, that
would be great. A programmer could ignore whole subdirectories
when working on something.
But just moving the whole existing pile into a subdirectory "because
everyone else does it" is not a reason; that's superstition.
Having to type "src/" a lot more often is definitely a downside.
Heck, that's one thing I actively dislike about GNU autoconf conventions.
If there's a compelling reason to change, could someone please describe it?
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: david @ 2011-02-02 2:23 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Shawn Pearce, Nguyen Thai Ngoc Duy, Jakub Narebski,
Jonathan Nieder, Dmitry S. Kravtsov, git
In-Reply-To: <alpine.LFD.2.00.1102012110320.8580@xanadu.home>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1659 bytes --]
On Tue, 1 Feb 2011, Nicolas Pitre wrote:
> On Tue, 1 Feb 2011, Shawn Pearce wrote:
>
>> On Tue, Feb 1, 2011 at 13:51, Nicolas Pitre <nico@fluxnic.net> wrote:
>>> On Tue, 1 Feb 2011, Shawn Pearce wrote:
>>>
>>>> On Tue, Feb 1, 2011 at 09:11, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>>>>> Narrow/Subtree clone is still just an idea, but can pack cache support
>>>>> be made to resumable initial narrow clone too?
>>>>
>>>> This would be very hard to do. We could do cached packs for a popular
>>>> set of path specifications (e.g. Documentation/ if documentation only
>>>> editing is common), but once we start getting random requests for path
>>>> specifications that we cannot predict in advance and pre-pack we'd
>>>> have to fall back to the normal enumerate code path.
>>>
>>> Also... people interested in Narrow clones are likely to be shallow
>>> clone users too, right?
>>
>> I think that depends. Some users might want the full history of the
>> files they are working on. Others wouldn't care and just want the tip
>> revision so they can make changes. Obviously a shallow clone of depth
>> 1 is very cheap to implement on the server; there really isn't any
>> caching required.
>>
>> Probably 50% want full history, 50% want shallow clone. So I doubt we
>> can assume that narrow implies shallow and thus is cheap. :-(
>
> Let's see what happens when this gets used in the wild.
also, many users may assume that a full clone is very expensive, but for
code-based projects a full clone is usually comparable to the size to
download a single tarball.
if you have large binary files this changes, but most projects don't.
David Lang
^ permalink raw reply
* [1.8.0] Provide proper remote ref namespaces
From: Johan Herland @ 2011-02-02 2:21 UTC (permalink / raw)
To: git; +Cc: Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <AANLkTimtU56BAnWU-2pY1npdkPdKEBq_CMCGwXUK+E=H@mail.gmail.com>
On Wednesday 02 February 2011, Sverre Rabbelier wrote:
> On Tue, Feb 1, 2011 at 19:14, Jeff King <peff@peff.net> wrote:
> > i.e., make refs/remotes/* an actual mirror of selected parts of the
> > remote's refs/ hierarchy. And then figure out sane rules for merging
> > those namespaces into the ref lookup procedure.
>
> Jeff, Nguy, are either of you interested in writing up a new/modifying
> this proposal to be about namespacing everything?
Here's my go at phrasing this in a proposal format. Feel free to revise and
resend:
Proposal:
Currently, git stores remote refs in the local repo by default as follows:
Remote repo -> Local repo
---------------------------------------------------------
HEAD refs/remotes/$remote/HEAD (implicit)
refs/heads/* refs/remotes/$remote/*
refs/tags/* refs/tags/* (implicit, autofollow)
refs/replace/* (TBD)
refs/notes/* (TBD)
Several users report that they are confused by the difference in how heads
and tags are mapped, and by the implicit mappings that are not mentioned in
the configured refspecs. Also, as users want to share ever more different
types of refs (replace refs and notes refs have been discussed recently),
the existing ref mappings (aka. refspecs) do not suggest a natural/intuitive
mapping for the new ref types.
Instead, we should change the default ref mappings into the following:
Remote repo -> Local repo
--------------------------------------------------
HEAD refs/remotes/$remote/HEAD
refs/heads/* refs/remotes/$remote/heads/*
refs/tags/* refs/remotes/$remote/tags/*
refs/replace/* refs/remotes/$remote/replace/*
refs/notes/* refs/remotes/$remote/notes/*
In short, we make refs/remotes/$remote/* an actual mirror of selected parts
of the remote's refs/* hierarchy. This provides consistent namespaces for
remote refs that naturally allows adding new ref types in the future.
This change obviously affects our ref-handling code:
- Remote tags are now stored separate from local tags. When looking up a
shorthand tag name (e.g. v1.7.4), we should consult local tags
(refs/tags/v1.7.4) before remote tags (refs/remotes/*/tags/v1.7.4 [1]). See
[2] for more details.
- Remote heads have moved into refs/remotes/$remote/heads/*, hence
invalidating shorthand remote head names, like "origin/master". We should
change the lookup code, so that a shorthand ref of the form "$remote/$head"
where "$remote" happens to match a configured remote is eventually expanded
into lookup for "refs/remotes/$remote/heads/$head" [3].
- We might want to generalize the handling of "$remote/$head" into allowing
shorthands like "$remote/$tag", "$remote/$replace" and "$remote/$note" as
well (provided, of course, that they match unambiguously).
- All fetch refspecs should be given explicitly.
Sub-proposal: While we are changing the default refspecs, we should also
consider whether we want to keep the auto-following behavior that Git
currently does for tags (don't fetch tags that refer to objects not
otherwise fetched by another refspec). If we simply make an explicit
"+refs/tags/*:refs/remotes/$remote/tags/*" refspec, we will lose the auto-
following behavior. If we do want to keep the auto-following behavior, we
could for example add a "~" prefix to the refspec to trigger auto-following
behavior (i.e. this refspec only applies to refs that happen to point at
objects fetched by way of a different refspec). See
http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160795
for more details.
Risks:
Existing scripts/programs may make assumptions about the layout of remote
refs without consulting the configured refspecs. However, such
scripts/programs may also break today when non-default refspecs are used.
When remotes have conflicting tags (same tag name points to different
objects), and the tag name does not exist locally (in refs/tags/*), looking
up the shorthand tag name will result in an "ambiguous ref" error (instead
of silently adopting whichever tag was fetched first). Although many
consider this an improvement on the current behavior, there may be scenarios
where this causes problems in external scripts/programs.
Existing scripts/programs that assume and depend on the current implicit
refspecs (or the tag auto-following behavior), might encounter problems when
we drop these in favor of explicit refspecs.
Migration plan:
The main part of this proposal is simply changing the default refspecs. As
such, the proposal can be simulated in current Git versions by setting up
custom refspecs according to the above table of ref mappings.
In v1.8.0, we should default to the new default refspecs when creating new
remotes. However, existing remotes (created pre-v1.8.0) must continue to
work as before, so we cannot simply remove the implicit refspecs (or tag
auto-following). Instead we need to make sure that the implicit refspecs is
NOT applied to the new-style remotes. Identifying new-style vs. old-style
remotes can be done by looking at the refspec itself (old-style:
"refs/remotes/$remote/*", new-style: "refs/remotes/$remote/heads/*"), or
(worst case) by introducing a config variable specifying the desired
behavior (defaulting to old-style).
When adding the new rules for looking up shorthand refs (described above),
we should carefully verify that these won't cause regressions when applied
to old-style refspecs in existing repos.
In a later major version we can consider removing the (by then ancient)
implicit refspecs, and any other outdated compatibility measures code in our
ref lookup code.
Have fun! :)
...Johan
[1]: The "refs/remotes/*/tags/v1.7.4" is not hardcoded, but rather the
(default) result of mapping "refs/tags/v1.7.4" through each remote's
refspecs as defined in the config.
[2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local tag
(refs/tags/v1.7.4) is found, then we have an unambiguous match. If no local
tag is found, we look up the tag name in all configured remotes (using the
method described in [1]). If the tag name exists in one or more remotes, and
those remotes all agree on its ultimate object name (after applying e.g.
^{commit} or whatever is appropriate in the context of the lookup), then we
also have an unambiguous match. However, if the tag name exists in multiple
remotes, and they do NOT all agree on its ultimate object name, then the
shorthand tag name is ambiguous and the lookup fails. The user can always
resolve this ambiguity by creating a local tag (refs/tags/v1.7.4) pointing
to the desired object.
[3]: As in [1], the "refs/remotes/$remote/heads/$head" is not hardcoded, but
rather the result of mapping "refs/heads/$head" through the refspecs for
$remote as defined in the config.
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Nicolas Pitre @ 2011-02-02 2:11 UTC (permalink / raw)
To: Shawn Pearce
Cc: Nguyen Thai Ngoc Duy, Jakub Narebski, Jonathan Nieder,
Dmitry S. Kravtsov, git
In-Reply-To: <AANLkTikaztSn+xQ3xT7d-3-Yghk69qXXN1DRg9h+kEHx@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1359 bytes --]
On Tue, 1 Feb 2011, Shawn Pearce wrote:
> On Tue, Feb 1, 2011 at 13:51, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Tue, 1 Feb 2011, Shawn Pearce wrote:
> >
> >> On Tue, Feb 1, 2011 at 09:11, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> >> > Narrow/Subtree clone is still just an idea, but can pack cache support
> >> > be made to resumable initial narrow clone too?
> >>
> >> This would be very hard to do. We could do cached packs for a popular
> >> set of path specifications (e.g. Documentation/ if documentation only
> >> editing is common), but once we start getting random requests for path
> >> specifications that we cannot predict in advance and pre-pack we'd
> >> have to fall back to the normal enumerate code path.
> >
> > Also... people interested in Narrow clones are likely to be shallow
> > clone users too, right?
>
> I think that depends. Some users might want the full history of the
> files they are working on. Others wouldn't care and just want the tip
> revision so they can make changes. Obviously a shallow clone of depth
> 1 is very cheap to implement on the server; there really isn't any
> caching required.
>
> Probably 50% want full history, 50% want shallow clone. So I doubt we
> can assume that narrow implies shallow and thus is cheap. :-(
Let's see what happens when this gets used in the wild.
Nicolas
^ permalink raw reply
* Re: [1.8.0] Remove deprecated commands
From: Jonathan Nieder @ 2011-02-02 0:57 UTC (permalink / raw)
To: René Scharfe; +Cc: Junio C Hamano, git
In-Reply-To: <4D4852EE.6080605@lsrfire.ath.cx>
Hi,
René Scharfe wrote:
> command deprecated since replaced by
> ---------------- ---------------- ---------------------
Some quick thoughts based on a code search:
- removing lost-found seems safe
- removing peek-remote seems safe
- repo-config should probably warn before it is removed
- removing tar-tree will probably break "make dist" for old
projects. I still am tempted to say removing it should be
okay.
> git-lost-found 2007-11-08 git fsck --lost-found
It can stay in contrib/examples for inspiration.
> git-peek-remote 2007-11-24 git ls-remote
No one seems to be using it
(github.com/gitpan/App-GitHub-FindRepository.git uses it as a fallback
when ls-remote is not present).
> git-repo-config 2008-01-17 git config
giggle[1] still uses it --- see libgiggle-git/giggle-git-config-read.c
and giggle-git-config-write.c.
Likewise darcs2git[2] and the stgit testsuite.
webkit's VCSUtils.pm only uses repo-config as a fallback when git
config is not present.
> git-tar-tree 2007-11-08 git archive
Already prints a deprecation notice. WWW::PkgFind from CPAN uses it
but doesn't seem to be maintained.
pilgrim[3] uses tar-tree in its "make dist" target. I wouldn't be
surprised if some other projects use it in a similar way.
Jonathan
[1] git://git.gnome.org/giggle.git
[2] git://repo.or.cz/darcs2git.git
[3] git://git.fedorahosted.org/pilgrim.git
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Shawn Pearce @ 2011-02-02 0:26 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Nguyen Thai Ngoc Duy, Jakub Narebski, Jonathan Nieder,
Dmitry S. Kravtsov, git
In-Reply-To: <alpine.LFD.2.00.1102011647000.8580@xanadu.home>
On Tue, Feb 1, 2011 at 13:51, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Tue, 1 Feb 2011, Shawn Pearce wrote:
>
>> On Tue, Feb 1, 2011 at 09:11, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> > Narrow/Subtree clone is still just an idea, but can pack cache support
>> > be made to resumable initial narrow clone too?
>>
>> This would be very hard to do. We could do cached packs for a popular
>> set of path specifications (e.g. Documentation/ if documentation only
>> editing is common), but once we start getting random requests for path
>> specifications that we cannot predict in advance and pre-pack we'd
>> have to fall back to the normal enumerate code path.
>
> Also... people interested in Narrow clones are likely to be shallow
> clone users too, right?
I think that depends. Some users might want the full history of the
files they are working on. Others wouldn't care and just want the tip
revision so they can make changes. Obviously a shallow clone of depth
1 is very cheap to implement on the server; there really isn't any
caching required.
Probably 50% want full history, 50% want shallow clone. So I doubt we
can assume that narrow implies shallow and thus is cheap. :-(
--
Shawn.
^ permalink raw reply
* Re: problem when pulling a specific branch from origin
From: Konstantin Khomoutov @ 2011-02-02 0:17 UTC (permalink / raw)
To: Ivan Kanis; +Cc: git
In-Reply-To: <877hdjy8d8.fsf@kanis.fr>
On Tue, Feb 01, 2011 at 06:25:55PM +0100, Ivan Kanis wrote:
> When I pull a specific branch from a repository I get in a state where
> git thinks I am ahead of the branch by one commit. The use case is a
> programmer that doesn't want to pull all the branches of the server.
>
> I have made a small script to reproduce the problem:
>
> ----
> #!/bin/sh
>
> rm -rf foo bar
> git --version
> mkdir foo
> cd foo
> git init
> echo foo > foo.txt
> git add foo.txt
> git commit -am"foo"
> git checkout -b branch
> cd ..
> git clone foo bar
> cd foo
> echo bar > foo.txt
> git commit -am"bar"
> cd ..
> cd bar
> git pull origin branch
> git status
> git branch -rv
> ----
>
> I get the following output:
>
> ----
> git version 1.7.3.5
> Initialized empty Git repository in /home/ivan/tmp/foo/.git/
> [master (root-commit) eefa065] foo
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 foo.txt
> Switched to a new branch 'branch'
> Cloning into bar...
> done.
> [branch 7ecd065] bar
> 1 files changed, 1 insertions(+), 1 deletions(-)
> remote: Counting objects: 5, done.
> remote: Total 3 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From /home/ivan/tmp/foo
> * branch branch -> FETCH_HEAD
> Updating eefa065..7ecd065
> Fast-forward
> foo.txt | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> # On branch master
> # Your branch is ahead of 'origin/master' by 1 commit.
> #
> nothing to commit (working directory clean)
> origin/HEAD -> origin/master
> origin/branch eefa065 foo
> origin/master eefa065 foo
> ----
>
> I expected to not be ahead of origin/master and that origin/branch
> points to 7ecd065. Is this a bug?
I'm not really sure about your expectation as you did not clearly
articulate them, so it seems there are two points to touch here...
The first one is that you seem to maintain a wrong idea about what
happens when you do `git pull origin branch`. It appears you assume
this action is supposed to first update the local branch
"remotes/origin/branch" and then merge it to the locally checked out
branch. The truth is that specifying a branch in this way to git-pull
(or git-fetch, which is called by git-pull) is a special case -- it
means that no corresponding local ref is updated, and the fetched line
of history is directly merged into the checked out branch right after
fetching (see the git-fetch manual and the EXAMPLES section in the
git-pull manual).
In your particular case you're merging remote branch "branch" which is
one commit ahead of remote "master" to the locally checked branch
"master" which is, at the moment, the same as the same-named remote
branch. Consequently, after merging "branch" (which results in
fast-forward) your local branch "master" starts to be one commit ahead
of its remote counterpart; no local branches beyond this one are
updated.
The second point is less clear/more complicated.
At first, it's not clear whether you wanted to have the remote branch
"branch" become the active local branch during the cloning process, or
"master" (in your case "master" became the active branch).
On the one hand, you explicitly branched "branch" off "master" right
before cloning (updating the first repo's HEAD ref) which hints you
intended that branch to be default in the clone.
On the other hand, while the documentation says the default branch in
the clone is the one listed in the HEAD ref of the source repository, in
my tests using Git (1.7.2.x in Debian and msysgit 1.7.3.x), in cases
like yours the destination repository ends up having the "master" branch
as the default one, not the branch from the HEAD ref; to make this work,
the branch listed in the HEAD ref should have received at least one
commit after forking. I suspect the problem might be in that such a
branch freshly cloned off "master" points to the same commit object's
name which might confuse Git.
This, in my eyes, might indeed display a bug.
^ permalink raw reply
* git ls-files --with is very hard if not impossible to find when reading man page
From: Marc Weber @ 2011-02-01 23:33 UTC (permalink / raw)
To: git
Hi
I knew about git-ls. But searching the man page for both: commit and
hash or such didn't tell me about hte --with flag (which cirwin told me
on irc).
Is it worth adding to the man page?
Or is the option that common that most users just know about it?
Marc Weber
^ 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