* "git add sub1/ sub2/" doesn't work as expected when sub1 and sub2 has .git under them
From: Ping Yin @ 2009-01-12 8:36 UTC (permalink / raw)
To: Git Mailing List
Assume directories sub1 and sub2 have .git under them. "git add sub1/"
works as expected (files under sub1/ are added), howerver "git add
sub1/ sub2/" doesn't work as expeced (sub1 and sub2 are added as
submoudle).
$ git --version git version 1.6.0.4.617.g2baf1
# create repo super
$ mkdir super && cd super && git init && git commit --allow-empty -m
"Initial commit"
# create repo super/sub1 with file sub1-file
$ mkdir sub1 && cd sub1 && touch sub1-file
$ git init && git add . && git commit -m "Initial commit" && cd ..
# create repo super/sub2 with file sub2-file
$ mkdir sub2 && cd sub2 && touch sub2-file
$ git init && git add . && git commit -m "Initial commit" && cd ..
# to intend to add files under sub1 and sub2, but submodules are added
$ git add sub1/ sub2/
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: sub1
# new file: sub2
#
$ git rm --cached sub1 sub2
# to intend add files under sub1, ok
$ gtad sub1/
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: sub1/sub1-file
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# sub2/
Ping Yin
^ permalink raw reply
* Re: Recent annoying problem with Linus's git repository?
From: Marco Roeland @ 2009-01-12 8:29 UTC (permalink / raw)
To: walt; +Cc: git, rmk
In-Reply-To: <20090112075942.GB29673@fiberbit.xs4all.nl>
On Monday January 12th 2009 at 08:59 Marco Roeland wrote:
> The file should probably just be really deleted. Adding Russell to the
> Cc. ;-)
Andrew Price already reported the issue and sent a patch last Wednesday:
http://marc.info/?l=linux-kernel&m=123134235028543&w=2
--
Marco Roeland, who should check all his mailing lists before answering
^ permalink raw reply
* Re: [PATCH 3/4] color-words: refactor to allow for 0-character word boundaries
From: Thomas Rast @ 2009-01-12 8:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901112059340.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 3629 bytes --]
As a side remark, this patch makes a good use-case for --patience, and
is not isomorphic to the other edit-and-move examples; rather it's a
delete-and-edit.
Johannes Schindelin wrote:
> Subject: [PATCH 3/4] color-words: refactor to allow for 0-character word boundaries
I do not think the term "refactor" is accurate. Wikipedia roughly
defines it as a code change that preserves all external semantics by
some standard method, and lists methods such as variable renaming,
common code extraction, etc. You are actually completely replacing
the algorithm "under the hood" with a new one, so no such standard
method applies.
And there is also a tiny semantic change: compare
A: a b c
B: x y z
^^
The old version implicitly generated an empty line at the double
spaces (marked ^^), which subsequently became context and caused the
words to be printed as follows, where <..> is old and [..] is new:
<a b >[x y ] <c>[z]
Your patched version does not generate empty lines for any space
whatsoever, not even for newlines. Thus the result is
<a b c>[x y z]
I think this is actually a good change, since it results in longer
chunks for "entirely rewritten" parts of the diff. It also answers
Junio's question in the other thread:
Junio C Hamano wrote:
>>
>> What happens if the input "language" does not have any inter-word spacing
>> but its words can still be expressed by regexp patterns?
>>
>> ImagineALanguageThatAllowsYouToWriteSomethingLikeThis. Does the mechanism
>> help users who want to do word-diff files written in such a language by
>> outputting:
>>
>> ImagineALanguage<red>That</red><green>Which</green>AllowsYou...
>>
>> when '[A-Z][a-z]*' is given by the word pattern?
Your patch handles this as a side-effect *even if the lines are
indented*, since no sequence of spaces whatsoever is special. (Mine
would have given hard-to-predict results based on the number of
newlines between them, and xdiff's decision whether the newlines or
the words are more valuable as context.)
So I think this is actually an improvement, but the commit message
should point out the change in semantics.
> +static void fn_out_diff_words_aux(void *priv, char *line, unsigned long len)
> {
> + if (line[0] != '@' || parse_hunk_header(line, len,
> + &minus_first, &minus_len, &plus_first, &plus_len))
It would be nice to have a comment here that points out that this
method crucially relies on having context length 0 (just as the old
one crucially relied on having the full text in a single hunk).
> + for (i = 0; i < buffer->text.size; i++) {
> + if (isspace(buffer->text.ptr[i]))
> + continue;
I think it is this coupling of the loops to find a word, and to find a
word _beginning_, that comes back to haunt you in 4/4. If the outer
loop was strictly about the words, you could use the regex match info
to find the beginning in the regex case. This is probably cleaner
than attempting to force an anchored match, since at least the 'grep'
on my system takes '^^foo' to mean 'a "^foo" at the beginning of a
line', so you cannot just unconditionally insert a ^. (Conditionally
inserting one seems even harder.)
These remarks aside (and the last one is the only one of relevance to
the code), this patch would be a vast improvement of the code even if
we weren't discussing it in the context of the regex feature. So FWIW
Acked-by: Thomas Rast <trast@student.ethz.ch>
up to here. I hope we can agree on some sane regex semantics for
4/4...
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: grammar patches not best use of talent
From: jdelstrother @ 2009-01-12 8:54 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87bpudp77t.fsf_-_@jidanni.org>
Wait, "a handful X" is now a legitimate form of "a handful of X"? I
assumed they were due to non-native speakers.
On 1/12/09, jidanni@jidanni.org <jidanni@jidanni.org> wrote:
> I've decided to back out of my plan to patch grammar.
> $ perl -nwle '/\w+\s+handful.*/i&& print $&' Documentation/*|sort -uf
> a handful commits on top of that,
> A handful documentation fixes.
> A handful documentation updates.
> a handful example hooks are copied in the
> a handful fixes to run it
> a handful of examples:
> A handful of sample hooks are installed when
> a handful pack-objects changes to help you cope better
> a handful small fixes to gitweb.
> a handful the real changes in non-zero
> first handful of characters, show the full
> only handful hexdigits prefix.
> only handful hexdigits prefix. Non default number of
> only handful hexdigits prefix. This is
>
> At first some of the above lines irritated me, but who am I to say
> that English must be said like my mom says it, and is never allowed to
> evolve further. Nope, I'll stick to correcting 2+2=3 type things.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* patches in context format ?
From: Christian MICHON @ 2009-01-12 9:00 UTC (permalink / raw)
To: git list
I'm maintaining a git tree of the vim project: this work can be seen
at http://github.com/cmichon/vim
vim patches do not come as unified format, but only as context format
instead (from a "diff -c").
The current solution I have is to use the original patch command,
stage modifications and add new files. I do not like this solution,
because I have to work out the commit messages out of the mbox and I
lose reproducibility. I'm basically maintaining a subset of shell
scripts, the original patches and an artificial way (ugly) to get
timestamps of modifications (for the commit dates).
Instead of this complicated procedure, I'd like to use "git apply" or
"git am", provided I can get git to support "context output format" as
input for patches ?
I guess the answer is no, but has anyone on the list been working on
this ? is there another way to translate from "context" to "unified"
format ?
TIA
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: [RFC/PATCH 1/3] tree.c: add support for traversal of submodules
From: Lars Hjemli @ 2009-01-12 9:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr639kyf0.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 12, 2009 at 04:15, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>
>> If the commit referenced by a gitlink is available in the (possibly
>> alternate) object database, read_tree_recursive() is now able to descend
>> into the tree of the linked commit if the flag 'traverse_gitlinks' is
>> turned on.
>>
>> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
>> ---
>> tree.c | 20 +++++++++++++++++---
>> tree.h | 1 +
>> 2 files changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/tree.c b/tree.c
>> index 03e782a..1468e10 100644
>> --- a/tree.c
>> +++ b/tree.c
>> @@ -7,6 +7,7 @@
>> #include "tree-walk.h"
>>
>> const char *tree_type = "tree";
>> +int traverse_gitlinks = 0;
>
> I think we tend to put these global settings that will affect everybody in
> environment.c. You do not have to initialize variable to zero; BSS will
> take care of it.
Ok, I'll add a proper interface in environment.c for this setting.
> When the user explicitly asks you to traverse into submodules and the
> necessary commit is not available in a submodule, the code goes on without
> complaining. I am not saying it is bad, but I wonder if we would want to
> distinguish these three cases:
>
> (1) the submodule is initialized and the necessary commit is there.
>
> (2) the submodule is initialized, but the necessary commit is missing.
>
> (3) the submodule is not even initialized (aka "the user is not
> interested in it"); there is only an empty directory.
>
> I think it is perfectly fine not to say anything for (3) but I am unsure
> about the second case.
Do we want to impose the porcelainish rules of git-submodule
(.gitmodules, .git/config) in read_tree_recursive()?
If so, I guess a new submodule.h might provide something like this
(disclaimer: coded in gmail):
struct submodule {
int interesting:1;
char *name;
char *url;
char **objectdirs;
char **paths;
}
typedef int (*submodule_cb)(struct submodule *submodule, void *data);
int load_submodule_config();
struct submodule *get_submodule_from_path(char *path);
int add_submodule_objectdb(struct submodule *item);
int for_each_submodule(submodule_cb cb, void *data);
Then, in read_tree_recursive(), we could check submodule->interesting
to decide if we should follow the gitlink. Also, for bare
repositories, we'd need to support something like
'submodule.<name>.objectdir' in the config file (and .gitmodules must
obviously be read from the objectdb).
If we don't want to impose these rules, the current patch should be
minimally sufficient (the user has to edit
.git/objects/info/alternates by hand and missing submodule commits are
treated as if the submodule is not interesting).
--
larsh
^ permalink raw reply
* [PATCH next] bash completion: refactor diff options
From: Thomas Rast @ 2009-01-12 9:16 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <1231679663-31907-1-git-send-email-trast@student.ethz.ch>
diff, log and show all take the same diff options. Refactor them from
__git_diff and __git_log into a variable, and complete them in
__git_show too.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
js/patience-diff is now in next, so here's a version on top of that.
contrib/completion/git-completion.bash | 38 ++++++++++++++++++-------------
1 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index dee75b5..39ae7a3 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -759,25 +759,30 @@ _git_describe ()
__gitcomp "$(__git_refs)"
}
-_git_diff ()
-{
- __git_has_doubledash && return
-
- local cur="${COMP_WORDS[COMP_CWORD]}"
- case "$cur" in
- --*)
- __gitcomp "--cached --stat --numstat --shortstat --summary
+__git_diff_common_options="--stat --numstat --shortstat --summary
--patch-with-stat --name-only --name-status --color
--no-color --color-words --no-renames --check
--full-index --binary --abbrev --diff-filter=
- --find-copies-harder --pickaxe-all --pickaxe-regex
+ --find-copies-harder
--text --ignore-space-at-eol --ignore-space-change
--ignore-all-space --exit-code --quiet --ext-diff
--no-ext-diff
--no-prefix --src-prefix= --dst-prefix=
- --base --ours --theirs
--inter-hunk-context=
--patience
+ --raw
+"
+
+_git_diff ()
+{
+ __git_has_doubledash && return
+
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--cached --pickaxe-all --pickaxe-regex
+ --base --ours --theirs
+ $__git_diff_common_options
"
return
;;
@@ -960,17 +965,16 @@ _git_log ()
--relative-date --date=
--author= --committer= --grep=
--all-match
- --pretty= --name-status --name-only --raw
+ --pretty=
--not --all
--left-right --cherry-pick
--graph
- --stat --numstat --shortstat
- --decorate --diff-filter=
- --color-words --walk-reflogs
+ --decorate
+ --walk-reflogs
--parents --children --full-history
--merge
--inter-hunk-context=
- --patience
+ $__git_diff_common_options
"
return
;;
@@ -1475,7 +1479,9 @@ _git_show ()
return
;;
--*)
- __gitcomp "--pretty="
+ __gitcomp "--pretty=
+ $__git_diff_common_options
+ "
return
;;
esac
--
tg: (f5cbdbb..) t/bash-complete-show (depends on: origin/next)
^ permalink raw reply related
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Alex Riesen @ 2009-01-12 9:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis
In-Reply-To: <200901120246.28364.jnareb@gmail.com>
2009/1/12 Jakub Narebski <jnareb@gmail.com>:
> Do you have any suggestions to bypass this block for git? I have access
> to Linux shell account (no root access, though) which doesn't have
> problems with repo.or.cz, so I think I could set up SSH tunnel: but
> how? And what to do with access via git:// - move to SSH too?
See man ssh, look for -L. It works for arbitrary ports, so you can redirect
git:// port to anywhere. Same for push over ssh, just give another port when
connecting.
^ permalink raw reply
* Re: Lightweight tag ?
From: Francis Moreau @ 2009-01-12 9:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63klsgf5.fsf@gitster.siamese.dyndns.org>
Hello,
Junio C Hamano <gitster@pobox.com> writes:
> Don't use explicit --tags blindly. It says "no matter what kind of tag,
> transfer everything under refs/tags". Otherwise you won't see a
> difference.
Well:
$ git --version
git version 1.6.0.4
$ mkdir test-tag
$ cd test-tag/
$ date > A
$ git init
Initialized empty Git repository in
/home/fmoreau/tmp/git/test-tag/.git/
$ git add .
$ git commit -a -s -m "Init"
Created initial commit be8750e: Init
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 A
$ cd ..
$ git clone --bare test-tag test-tag.git
Initialized empty Git repository in /home/fmoreau/tmp/git/test-tag.git/
$ cd test-tag
$ git tag light
$ git tag -a -m "Annoted tag" annoted
$ git push ../test-tag.git
Everything up-to-date
$ git push --tags ../test-tag.git
Counting objects: 1, done.
Writing objects: 100% (1/1), 166 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (1/1), done.
To ../test-tag.git
* [new tag] annoted -> annoted
* [new tag] light -> light
It looks like they're no difference for git-push...
That said the documentation about this is rather cryptic IMHO:
,----[ man git-push ]
| --tags
| All refs under $GIT_DIR/refs/tags are pushed, in
| addition to refspecs explicitly listed on the command
| line.
`----
>From a user point of view, the word lightweight is missing here. Why
not simply saying:
,----
| All kind of tags are pushed with this option _otherwise_ only annoted
| tags are pushed
`----
thanks
--
Francis
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Asheesh Laroia @ 2009-01-12 9:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200901120246.28364.jnareb@gmail.com>
This is a little off-topic, but you CC:d the git list first. (-;
On Mon, 12 Jan 2009, Jakub Narebski wrote:
> The ISP I use (Telekomunikacja Polska S.A., aka TP) made some
> unannounced changes for ADSL service (Neostrada) which made it block
> repo.or.cz (and of course its aliases, including git.or.cz where git
> wiki resides). It blocks also gimp.org and some Polish IRC servers
> (irc.freenode.org on which #git resides works O.K.). People speculate
> that this blocking was based on MAPS (Mail Abuse Prevention System,
> which is SPAM backwards) lists to fight SPAM and/or to block botnets,
> and uses null routing (IP based) blocking. I have no idea why repo.or.cz
> is blocked: gimp.org is supposedly blocked because it hosts
> irc.gimp.org on the same IP. By block I mean that even ping doesn't
> work (no reply at all).
That's horrifying.
> I can access git wiki via one of many free HTTP proxies; currently I use
> http://www.4proxy.de so there are only slight problems there.
>
> The problems is with fetching (via git:// protocol) of forks of git
> repository on repo.or.cz, and pushing (via SSH) to a few of my git
> repositories hosted on repo.or.cz.
>
> Do you have any suggestions to bypass this block for git? I have access
> to Linux shell account (no root access, though) which doesn't have
> problems with repo.or.cz, so I think I could set up SSH tunnel: but
> how? And what to do with access via git:// - move to SSH too?
$ ssh -D 1080 user@host
In a a separate terminal:
$ cat > /tmp/tsocks.conf
# Here we have a config for tsocks that uses localhost:1080 as SOCKS5.
server = 127.0.0.1
# Server type defaults to 4 so we need to specify it as 5 for this one
server_type = 5
# The port defaults to 1080 but I've stated it here for clarity
server_port = 1080
^D
$ export TSOCKS_CONF_FILE=/tmp/tsocks.conf
$ tsocks lynx http://repo.or.cz/
You would need the 'tsocks' tool for your client system. Note that the
remote system doesn't need any configuration this way. Just prefix any
command-line operations that involve repo.or.cz with 'tsocks' and be sure
to set TSOCKS_CONF_FILE. (On a Windows machine, use putty's graphical SSH
client and FreeCap <http://www.freecap.ru/eng/>.
Once you have the 'ssh -D' tunnel running, you can use it in Firefox as a
SOCKS proxy: host = localhost, port = 1080.
-- Asheesh.
--
Don't relax! It's only your tension that's holding you together.
^ permalink raw reply
* Re: patches in context format ?
From: Junio C Hamano @ 2009-01-12 9:28 UTC (permalink / raw)
To: Christian MICHON; +Cc: git list
In-Reply-To: <46d6db660901120100g7f62a0c2k68c96cbfc23dab5@mail.gmail.com>
"Christian MICHON" <christian.michon@gmail.com> writes:
> I'm maintaining a git tree of the vim project: this work can be seen
> at http://github.com/cmichon/vim
>
> vim patches do not come as unified format, but only as context format
> instead (from a "diff -c").
> ...
> I guess the answer is no, but has anyone on the list been working on
> this ? is there another way to translate from "context" to "unified"
> format ?
Not that I know of.
If you want to add support for the copied context format patches to your
workflow, I think the first step (and easiest one) would be to find an
external program that lets you convert from the copied context format to
the unified context format. Perhaps "interdiff /dev/null copied >unified"
would suffice (but I haven't tested this).
Then find the place that feeds "git apply" with a patch, and add an option
to "git am" to instead do something like this:
- git apply --index "$dotest/patch"
+ case "$input_is_in_the_copied_context_format"
+ yes)
+ interdiff /dev/null "$dotest/patch" | git apply --index
+ ;;
+ *)
+ # unified context as before...
+ git apply --index "$dotest/patch"
+ ;;
+ esac
In the longer term, if we were to update "git-apply" to support the copied
context format, I think we should take the same approach.
Inside read_patch_file(), you detect that the patch is in the copied
context format, and convert it to the unified context format and return
the result. All the rest of the program can then be left alone and you
will have little chance of regression.
^ permalink raw reply
* Re: patches in context format ?
From: Teemu Likonen @ 2009-01-12 9:34 UTC (permalink / raw)
To: Christian MICHON; +Cc: git list
In-Reply-To: <46d6db660901120100g7f62a0c2k68c96cbfc23dab5@mail.gmail.com>
Christian MICHON (2009-01-12 10:00 +0100) wrote:
> is there another way to translate from "context" to "unified" format ?
Well, this is not exactly the best solution for a Vim user but this is
the only way I know. Emacs can convert diffs between the formats. You
don't even need to launch Emacs, just run it in batch mode:
$ emacs --batch -Q --file input.diff \
--eval '(diff-context->unified (point-min) (point-max))' \
--eval '(save-buffer)'
^ permalink raw reply
* Re: grammar patches not best use of talent
From: Junio C Hamano @ 2009-01-12 9:35 UTC (permalink / raw)
To: jdelstrother; +Cc: jidanni, git
In-Reply-To: <57518fd10901120054o5fbe78f8he0a54f6d62216ad5@mail.gmail.com>
jdelstrother@gmail.com writes:
> Wait, "a handful X" is now a legitimate form of "a handful of X"? I
> assumed they were due to non-native speakers.
You assumed correctly.
Jidanni is saying that _he_ thought about doing so, and then changed his
mind. I personally do not know what the point of saying such things on
the public list like this: you either just do it, or you don't, and you do
not add noise to the traffic by saying you won't do this nor that.
If you agree with me on the above point, just ignore the message you are
responding to (I am not saying "just ignore _him_"; at least not yet), and
if you are inclined to help, please don't let the message you are
responding to discourage you.
Thanks.
^ permalink raw reply
* Re: [PATCH 3/4] color-words: refactor to allow for 0-character word boundaries
From: Junio C Hamano @ 2009-01-12 9:36 UTC (permalink / raw)
To: Thomas Rast; +Cc: Johannes Schindelin, git
In-Reply-To: <200901120947.13566.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> These remarks aside (and the last one is the only one of relevance to
> the code), this patch would be a vast improvement of the code even if
> we weren't discussing it in the context of the regex feature. So FWIW
>
> Acked-by: Thomas Rast <trast@student.ethz.ch>
>
> up to here. I hope we can agree on some sane regex semantics for
> 4/4...
Ok, although I've already queued your series to 'pu' for the night, I'll
drop and replace it with the one from Dscho. After a few more iteration
hopefully we can get it into a reasonable shape.
Thanks, both.
^ permalink raw reply
* Re: [RFC/PATCH 2/3] replace_object: add mechanism to replace objects found in "refs/replace/"
From: Jakub Narebski @ 2009-01-12 9:50 UTC (permalink / raw)
To: Tim Ansell; +Cc: git
In-Reply-To: <1231727868.6716.155.camel@vaio>
On Mon, 12 Jan 2009, Tim 'mithro' Ansell wrote:
> > I just had an idea: we can use this mechanism to better manage large
> > binary files in Git, by using replacements for _blobs_.
> >
> > We want to be able to have two flavours of repository: one with large
> > blobs (media files usually), and one without. We can use stubs in the
> > place of large binary files in 'no-megablobs' flavor, and add contents
> > of those files via refs/replace/* for _blobs_ in 'with-megablobs'
> > flavour. We can control which objects we want to have, and which
> > objects to transfer.
> >
> > What do you think about this (abuse of) an idea?
>
> I'm not sure I understand. I don't really care much about the
> implementation details if it's transparent to the user :)
>
> I have not really had much time to pursue my idea of getting sha1_file
> to read download blob on an as-needed basis (work has been hectic).
Actually this idea is a bit different from lazy / on demand downloading
of large blobs.
In "on demand loading" solution you have sha-1 of _full_ blob in a tree,
but git knows that not having it is not a fatal error (somehow), and you
can ask git to download it. This is as far as I understand the solution
you proposed and partially implemented.
In "replacement blobs" solution, the (ab)use of object replacement
mechanism meant originally for easier bisect, you have sha-1 of _stub_
object in a tree. If you want full (large) blob, you add replacement
in refs/replace/*, replacing stub blob object (must be unique; it can
for example contain some header + sha-1 of full object) with full
object. If you want to have large object, you need to transfer
refs/replace/*. This solution means that user needs to be aware of
this mechanism, or have some wrapper (script) around it.
Different solution, and a bit different behavior wrt getting large
object for the user.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC PATCH 1/3] Add "vcs" config option in remotes
From: Bert Wesarg @ 2009-01-12 9:52 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LNX.1.00.0901110332580.19665@iabervon.org>
On Sun, Jan 11, 2009 at 21:12, Daniel Barkalow <barkalow@iabervon.org> wrote:
> diff --git a/builtin-push.c b/builtin-push.c
> index 122fdcf..3fdedba 100644
> --- a/builtin-push.c
> +++ b/builtin-push.c
> @@ -53,6 +53,9 @@ static int do_push(const char *repo, int flags)
> int i, errs;
> struct remote *remote = remote_get(repo);
>
> + if (remote->foreign_vcs)
> + die("Pushing with foreign VCSes not supported.");
> +
> if (!remote)
> die("bad repository '%s'", repo);
>
Use of remote before NULL check.
Bert
^ permalink raw reply
* Re: patches in context format ?
From: Christian MICHON @ 2009-01-12 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vy6xgj2jq.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 12, 2009 at 10:28 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> I guess the answer is no, but has anyone on the list been working on
>> this ? is there another way to translate from "context" to "unified"
>> format ?
>
> Not that I know of.
>
> If you want to add support for the copied context format patches to your
> workflow, I think the first step (and easiest one) would be to find an
> external program that lets you convert from the copied context format to
> the unified context format. Perhaps "interdiff /dev/null copied >unified"
> would suffice (but I haven't tested this).
>
interdiff is exactly what I needed (I used -p and -q switches, plus a
substitution for the path).
Thanks for this! I guess there's not really a need to add this now in
git-am, since I've seldom seen such context patches.
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: patches in context format ?
From: Jeff King @ 2009-01-12 9:52 UTC (permalink / raw)
To: Christian MICHON; +Cc: git list
In-Reply-To: <46d6db660901120100g7f62a0c2k68c96cbfc23dab5@mail.gmail.com>
On Mon, Jan 12, 2009 at 10:00:11AM +0100, Christian MICHON wrote:
> The current solution I have is to use the original patch command,
> stage modifications and add new files. I do not like this solution,
> because I have to work out the commit messages out of the mbox and I
> lose reproducibility. I'm basically maintaining a subset of shell
> scripts, the original patches and an artificial way (ugly) to get
> timestamps of modifications (for the commit dates).
>
> Instead of this complicated procedure, I'd like to use "git apply" or
> "git am", provided I can get git to support "context output format" as
> input for patches ?
Maybe this is not the nicest solution if you are going to apply a lot of
these patches, but you can pick up where git-am fails, run patch, and
ask it to resume:
$ git am mbox-with-context-diff
Applying: a minor change
error: No changes
Patch failed at 0001.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
$ patch <.git/rebase-apply/patch ;# or whatever
$ git add -u
$ git am -r
Applying: a minor change
-Peff
^ permalink raw reply
* Re: patches in context format ?
From: Christian MICHON @ 2009-01-12 9:53 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git list
In-Reply-To: <871vv8rhpz.fsf@iki.fi>
On Mon, Jan 12, 2009 at 10:34 AM, Teemu Likonen <tlikonen@iki.fi> wrote:
> Christian MICHON (2009-01-12 10:00 +0100) wrote:
>
>> is there another way to translate from "context" to "unified" format ?
>
> Well, this is not exactly the best solution for a Vim user but this is
> the only way I know. Emacs can convert diffs between the formats. You
> don't even need to launch Emacs, just run it in batch mode:
>
> $ emacs --batch -Q --file input.diff \
> --eval '(diff-context->unified (point-min) (point-max))' \
> --eval '(save-buffer)'
>
you're asking a vim user to use emacs ? ;-)
thanks for the suggestion: I'll try it at least, but I think I'll
stick to interdiff.
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: patches in context format ?
From: Christian MICHON @ 2009-01-12 9:57 UTC (permalink / raw)
To: Jeff King; +Cc: git list
In-Reply-To: <20090112095250.GB3079@coredump.intra.peff.net>
On Mon, Jan 12, 2009 at 10:52 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Jan 12, 2009 at 10:00:11AM +0100, Christian MICHON wrote:
>
>> The current solution I have is to use the original patch command,
>> stage modifications and add new files. I do not like this solution,
>> because I have to work out the commit messages out of the mbox and I
>> lose reproducibility. I'm basically maintaining a subset of shell
>> scripts, the original patches and an artificial way (ugly) to get
>> timestamps of modifications (for the commit dates).
>>
>> Instead of this complicated procedure, I'd like to use "git apply" or
>> "git am", provided I can get git to support "context output format" as
>> input for patches ?
>
> Maybe this is not the nicest solution if you are going to apply a lot of
> these patches, but you can pick up where git-am fails, run patch, and
> ask it to resume:
>
> $ git am mbox-with-context-diff
> Applying: a minor change
> error: No changes
> Patch failed at 0001.
> When you have resolved this problem run "git am --resolved".
> If you would prefer to skip this patch, instead run "git am --skip".
> To restore the original branch and stop patching run "git am --abort".
>
> $ patch <.git/rebase-apply/patch ;# or whatever
> $ git add -u
> $ git am -r
> Applying: a minor change
>
> -Peff
>
vim patches are in hundredth... so I guess this is too manual.
Thanks for the suggestion!
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: [RFC/PATCH 1/3] tree.c: add support for traversal of submodules
From: Junio C Hamano @ 2009-01-12 10:07 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <8c5c35580901120104u418d8d73mad4ab7d71fe8c3f8@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> On Mon, Jan 12, 2009 at 04:15, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> When the user explicitly asks you to traverse into submodules and the
>> necessary commit is not available in a submodule, the code goes on without
>> complaining. I am not saying it is bad, but I wonder if we would want to
>> distinguish these three cases:
>>
>> (1) the submodule is initialized and the necessary commit is there.
>>
>> (2) the submodule is initialized, but the necessary commit is missing.
>>
>> (3) the submodule is not even initialized (aka "the user is not
>> interested in it"); there is only an empty directory.
>>
>> I think it is perfectly fine not to say anything for (3) but I am unsure
>> about the second case.
>
> Do we want to impose the porcelainish rules of git-submodule
> (.gitmodules, .git/config) in read_tree_recursive()?
>
> If so, I guess a new submodule.h might provide something like this
> (disclaimer: coded in gmail):
I do not see why you would need anything more than we already have to tell
(3) from (1) and (2). And I do not see why you need to have the Porcelain
policy in the picture for telling these three cases apart, either.
For example, there is this code in read-cache.c::ce_compare_gitlink():
static int ce_compare_gitlink(struct cache_entry *ce)
{
unsigned char sha1[20];
/*
* We don't actually require that the .git directory
* under GITLINK directory be a valid git directory. It
* might even be missing (in case nobody populated that
* sub-project).
*
* If so, we consider it always to match.
*/
if (resolve_gitlink_ref(ce->name, "HEAD", sha1) < 0)
return 0;
return hashcmp(sha1, ce->sha1);
}
It asks resolve_gitlink_ref() to see if the directory (where the submodule
checkout _might_ be present if the user is interested in it) has .git/HEAD
that resolves. If so, the user has a checkout and is interested in it.
Otherwise, there is no checkout, in other words, we have case (3) above.
Whether you force the user to link the submodule object store to the
primary one as alternates, or do that for the user temporarily inside the
process [*1*], you would then be able to tell (1) and (2) apart by asking
has_sha1_file() if you can see the commit.
One thing that is unclear is to me is for whom the commit is missing (or
present). I think the outline I gave above follows the design of your
patch to assume that the commit may (or may not) be available to the
superproject and traverse into the commit when that is the case. It does
not mean the commit is available to the submodule itself (the commit may
have found in the primary project itself, not via the alternates), but
such an arrangement makes it somewhat useless.
What's the typical direction of using alternates in a setting with
superproject with a submodule? Do people have alternates in the submodule
repository that borrows from the superproject repository? Or the other
way around? What's the rationale for having such alternates for normal
use case? I am suspecting that there is no reason (other than this
"recursive tree traversal") to have an alternates file in either
direction, but I also strongly suspect that I am missing some unwritten
assumption you are making.
[Footnote]
*1* If you want to recurse seemlessly, it might make sense to add (during
the course of this "recursive tree traversal") the object store of the
submodule repository to the process'es list of alternate object databases
yourself, instead of forcing the user to do so permanently by mucking with
the alternates list of the primary project repository. But that is an
independent issue.
^ permalink raw reply
* Re: Funny: git -p submodule summary
From: Johannes Sixt @ 2009-01-12 10:59 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20090111112222.GA29656@coredump.intra.peff.net>
From: Johannes Sixt <j6t@kdbg.org>
Jeff King schrieb:
> On Fri, Jan 09, 2009 at 11:36:41AM +0100, Johannes Sixt wrote:
>
>> I'll test your other patch (that replaces the execvp in git.c by
>> run_command).
>
> There is something funny with it that I have not diagnosed: aliases are
> broken, and "git foobar" does not return an error. Presumably just
> checking the "we did not exec succesfully" case is not triggering
> properly. However, I think the right solution is actually to refactor
> git.c to figure out ahead of time whether we have a builtin, external,
> or alias. I can work on that, but not tonight, as my git-time is up for
> now.
>
> But other than that, did it work for you on Windows?
It passed the test suite. This should already work better on Windows,
because we already *do* look-up the program, and exit from
mingw_spawnvpe() before the equivalent of fork+exec happens.
> However, here is a 4-patch series that handles the separate signal
> delivery problem. It should fix the "^C makes funny things happen"
> problems you were seeing. Please test and let me know how it works on
> Windows.
It does help a bit. The interesting thing is that the only case where I
can now reproduces the unwanted behavior with the unpatched version is
when all output was completely read by 'less' and git already waits in
wait_for_pager(), such as in 'git show'. But Ctrl-C'ing a 'git log -p'
works as expected even without these patches. With the patches, the 'git
show' case now works as well.
> The patches are:
> 1/4: Makefile: clean up TEST_PROGRAMS definition
> 2/4: chain kill signals for cleanup functions
> 3/4: refactor signal handling for cleanup functions
> 4/4: pager: do wait_for_pager on signal death
But we need to insert the patch below *before* 2/4. The test case needs a
change, too,(exit code on Windows is 3, not 130) but I'll keep that in my
repository, like with all other Windows related test suite changes.
-- Hannes
-- 8< --
From: Johannes Sixt <j6t@kdbg.org>
Subject: Windows: Fix signal numbers
We had defined some SIG_FOO macros that appear in the code, but that are
not supported on Windows, in order to make the code compile. But a
subsequent change will assert that a signal number is non-zero. We now
use the signal numbers that are commonly used on POSIX systems.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
compat/mingw.h | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 4f275cb..a255898 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -21,12 +21,12 @@ typedef int pid_t;
#define WEXITSTATUS(x) ((x) & 0xff)
#define WIFSIGNALED(x) ((unsigned)(x) > 259)
-#define SIGKILL 0
-#define SIGCHLD 0
-#define SIGPIPE 0
-#define SIGHUP 0
-#define SIGQUIT 0
-#define SIGALRM 100
+#define SIGHUP 1
+#define SIGQUIT 3
+#define SIGKILL 9
+#define SIGPIPE 13
+#define SIGALRM 14
+#define SIGCHLD 17
#define F_GETFD 1
#define F_SETFD 2
--
1.6.1.rc4.959.gcece.dirty
^ permalink raw reply related
* Re: [RFC/PATCH 1/3] tree.c: add support for traversal of submodules
From: Lars Hjemli @ 2009-01-12 10:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vab9wj0rs.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 12, 2009 at 11:07, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>
>> On Mon, Jan 12, 2009 at 04:15, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>>> When the user explicitly asks you to traverse into submodules and the
>>> necessary commit is not available in a submodule, the code goes on without
>>> complaining. I am not saying it is bad, but I wonder if we would want to
>>> distinguish these three cases:
>>>
>>> (1) the submodule is initialized and the necessary commit is there.
>>>
>>> (2) the submodule is initialized, but the necessary commit is missing.
>>>
>>> (3) the submodule is not even initialized (aka "the user is not
>>> interested in it"); there is only an empty directory.
>>>
>>> I think it is perfectly fine not to say anything for (3) but I am unsure
>>> about the second case.
>>
>> Do we want to impose the porcelainish rules of git-submodule
>> (.gitmodules, .git/config) in read_tree_recursive()?
>>
>> If so, I guess a new submodule.h might provide something like this
>> (disclaimer: coded in gmail):
>
> I do not see why you would need anything more than we already have to tell
> (3) from (1) and (2). And I do not see why you need to have the Porcelain
> policy in the picture for telling these three cases apart, either.
>
> For example, there is this code in read-cache.c::ce_compare_gitlink():
>
> static int ce_compare_gitlink(struct cache_entry *ce)
> {
> unsigned char sha1[20];
>
> /*
> * We don't actually require that the .git directory
> * under GITLINK directory be a valid git directory. It
> * might even be missing (in case nobody populated that
> * sub-project).
> *
> * If so, we consider it always to match.
> */
> if (resolve_gitlink_ref(ce->name, "HEAD", sha1) < 0)
> return 0;
> return hashcmp(sha1, ce->sha1);
> }
>
> It asks resolve_gitlink_ref() to see if the directory (where the submodule
> checkout _might_ be present if the user is interested in it) has .git/HEAD
> that resolves. If so, the user has a checkout and is interested in it.
> Otherwise, there is no checkout, in other words, we have case (3) above.
Ah, yes, this makes sense. Thanks.
> Whether you force the user to link the submodule object store to the
> primary one as alternates, or do that for the user temporarily inside the
> process [*1*],
If resolve_gitlink_ref() returns 0, I think we should automatically
insert the objectdir of the submodule as a tempory alternate.
> you would then be able to tell (1) and (2) apart by asking
> has_sha1_file() if you can see the commit.
Yes (I've also got a use-case for this with bare repositories [*1*],
but in that setting I guess it's ok to force the user to link the
alternates manually).
> One thing that is unclear is to me is for whom the commit is missing (or
> present). I think the outline I gave above follows the design of your
> patch to assume that the commit may (or may not) be available to the
> superproject and traverse into the commit when that is the case. It does
> not mean the commit is available to the submodule itself (the commit may
> have found in the primary project itself, not via the alternates), but
> such an arrangement makes it somewhat useless.
I think we can ignore this issue; if someone has added the
superproject as an alternate for the submodule and then done a
checkout of a superproject commit in the submodule followed by
committing this gitlink in the superproject, we can only hope the user
really knew what he was doing...
> What's the typical direction of using alternates in a setting with
> superproject with a submodule? Do people have alternates in the submodule
> repository that borrows from the superproject repository? Or the other
> way around? What's the rationale for having such alternates for normal
> use case? I am suspecting that there is no reason (other than this
> "recursive tree traversal") to have an alternates file in either
> direction,
Likewise.
> but I also strongly suspect that I am missing some unwritten
> assumption you are making.
I'm only assuming that we want to support traversal into the
submodules from core git.
*1* This will be (ab)used by cgit to support downloading of 'complete'
tarballs, as outlined in
http://thread.gmane.org/gmane.comp.version-control.git/102827.
--
larsh
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Jakub Narebski @ 2009-01-12 11:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0901120117mf010317m79874a235e29a439@mail.gmail.com>
Alex Riesen wrote:
> 2009/1/12 Jakub Narebski <jnareb@gmail.com>:
> > Do you have any suggestions to bypass this block for git? I have access
> > to Linux shell account (no root access, though) which doesn't have
> > problems with repo.or.cz, so I think I could set up SSH tunnel: but
> > how? And what to do with access via git:// - move to SSH too?
>
> See man ssh, look for -L. It works for arbitrary ports, so you can redirect
> git:// port to anywhere. Same for push over ssh, just give another port when
> connecting.
Currently I have the folowing in my ~/.ssh/config:
# TP S.A. blocks repo.or.cz
Host repo.or.cz
NoHostAuthenticationForLocalhost yes
HostName localhost
Port 2222
and I can simply use "git push repo" without any changes.
But I have to run
$ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
first. Is there any way to automate this?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Funny: git -p submodule summary
From: Jeff King @ 2009-01-12 11:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <496B2278.9050905@viscovery.net>
On Mon, Jan 12, 2009 at 11:59:04AM +0100, Johannes Sixt wrote:
> But we need to insert the patch below *before* 2/4. The test case needs a
> change, too,(exit code on Windows is 3, not 130) but I'll keep that in my
> repository, like with all other Windows related test suite changes.
Hrm. How do you properly detect "killed by SIGINT" on Windows? That is
the intent of that test.
> -#define SIGKILL 0
> -#define SIGCHLD 0
> -#define SIGPIPE 0
> -#define SIGHUP 0
> -#define SIGQUIT 0
> -#define SIGALRM 100
> +#define SIGHUP 1
> +#define SIGQUIT 3
> +#define SIGKILL 9
> +#define SIGPIPE 13
> +#define SIGALRM 14
> +#define SIGCHLD 17
Don't these get fed to signal()? Does Windows really not care about
getting bogus numbers versus 0 (which is, admittedly, bogus itself)? Or
are we just ignoring the return code everywhere?
-Peff
^ 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