* Re: Pulling tags from git.git
From: Junio C Hamano @ 2006-03-07 10:33 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <440D5285.3050401@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> With the git or git+ssh protocol, tags will be autofollowed
> when you do a pull (only signed tags, I think). The
> auto-following is done by detecting tags that are fetched,
Ah, you are correct. We do not follow lightweight tags; I am
not sure if we should.
We detect from ls-remote output if you have objects pointed by
remote tags (either signed or unsigned -- we cannot tell it from
ls-remote output) and fetch those tags that point at what we
have.
The auto following is done only when you are tracking remote
branches, BTW. Promiscuous fetch for immediate merging does not
follow tags.
Totally untested, so if somebody is interested, please test it,
and if it works, sign it off and bounce it back to me ;-).
-- >8 --
[PATCH] make "git fetch" follow unannotated tags as well.
---
diff --git a/git-fetch.sh b/git-fetch.sh
index 0346d4a..90c8882 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -375,7 +375,7 @@ case "$no_tags$tags" in
# using local tracking branch.
taglist=$(IFS=" " &&
git-ls-remote $upload_pack --tags "$remote" |
- sed -ne 's|^\([0-9a-f]*\)[ ]\(refs/tags/.*\)^{}$|\1 \2|p' |
+ sed -e 's/\^{}$//' -e 's/ / /' |
while read sha1 name
do
test -f "$GIT_DIR/$name" && continue
@@ -386,7 +386,8 @@ case "$no_tags$tags" in
git-cat-file -t "$sha1" >/dev/null 2>&1 || continue
echo >&2 "Auto-following $name"
echo ".${name}:${name}"
- done)
+ done |
+ sort -u)
esac
case "$taglist" in
'') ;;
^ permalink raw reply related
* Re: git-status too verbose?
From: Andreas Ericsson @ 2006-03-07 10:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Jaffe, Carl Worth, git
In-Reply-To: <7v3bhumvt6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>>I agree that it would be useful if we had a tool that showed the
>>>two status that matter for each file, grouped together on one
>>>line, e.g.
>>> HEAD->index index->files
>>> ------------------------------------------------
>>> hello.c unmodified modified
>>> world.c modified unmodified
>>> frotz.c new unmodified
>>> ...
>>> garbage.c~ ??? n/a
>>>for the current index file and the current HEAD commit.
>>
>>Could we have 'same' or some such instead of 'unmodified'? It's a bit
>>close to 'modified' for the eye to find it quickly.
>>
>>
>>>You obviously need to learn how to read it though. The first
>>>column means what you _would_ commit if you just said "git
>>>commit" without doing anything else now; the second column is
>>>what you _could_ commit if you did some update-index and then
>>>said "git commit" (or ran "git commit" with paths arguments).
>>
>>Pretty-printing will be easier if the filename is last, and it will
>>look a lot neater if all columns are aligned.
>
>
> Somebody who feels strongly about this can propose a design.
> Although I am not particularly fond of the current output, I am
> not volunteering ;-).
>
> It would be nicer if the proposal was accompanied by a patch,
> but that is not a requirement for discussion.
>
I'll see if I can get around to it tonight.
> The points that design would address should include:
>
> - what to do _if_ we choose to do rename detection? you need
> two pathnames.
I like the gitk view of these things, "renamed from" and "renamed to",
although we'll likely want shorter names since the filename part can't
start before column max_label_name * 2 + 4 if we assume two spaces
minimum between word-columns. Perhaps mv-to and mv-from?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-status too verbose?
From: Junio C Hamano @ 2006-03-07 9:46 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Eric Jaffe, Carl Worth, git
In-Reply-To: <440D503E.8090007@op5.se>
Andreas Ericsson <ae@op5.se> writes:
>> I agree that it would be useful if we had a tool that showed the
>> two status that matter for each file, grouped together on one
>> line, e.g.
>> HEAD->index index->files
>> ------------------------------------------------
>> hello.c unmodified modified
>> world.c modified unmodified
>> frotz.c new unmodified
>> ...
>> garbage.c~ ??? n/a
>> for the current index file and the current HEAD commit.
>
> Could we have 'same' or some such instead of 'unmodified'? It's a bit
> close to 'modified' for the eye to find it quickly.
>
>> You obviously need to learn how to read it though. The first
>> column means what you _would_ commit if you just said "git
>> commit" without doing anything else now; the second column is
>> what you _could_ commit if you did some update-index and then
>> said "git commit" (or ran "git commit" with paths arguments).
>
> Pretty-printing will be easier if the filename is last, and it will
> look a lot neater if all columns are aligned.
Somebody who feels strongly about this can propose a design.
Although I am not particularly fond of the current output, I am
not volunteering ;-).
It would be nicer if the proposal was accompanied by a patch,
but that is not a requirement for discussion.
The points that design would address should include:
- set of labels (full list)
modified, same, renamed?, untracked, ...
- field ordering (good point by Andreas)
- what to do _if_ we choose to do rename detection? you need
two pathnames.
- alignment (good point by Andreas)
^ permalink raw reply
* Re: git-status too verbose?
From: Johannes Schindelin @ 2006-03-07 9:38 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20060307091717.GA16645@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1085 bytes --]
Hi,
On Tue, 7 Mar 2006, Karl Hasselström wrote:
> On 2006-03-07 11:05:47 +0530, Joshua N Pritikin wrote:
>
> > On Mon, Mar 06, 2006 at 04:21:52PM -0800, Junio C Hamano wrote:
> >
> > > HEAD->index index->files
> > > ------------------------------------------------
> > > hello.c unmodified modified
> > > world.c modified unmodified
> > > frotz.c new unmodified
> > > ...
> > > garbage.c~ ??? n/a
> >
> > For what it's worth, this chart immediately made sense to me and I
> > would prefer it to the current git-status output.
>
> I agree. This kind of status information makes the whole index concept
> an order of magnitude less confusing. In a way, it lets you learn what
> the index is by example, rather than first having to learn what it is
> in order to be able to grok the status information.
I beg to differ. The index thing is complex enough as it is. You should
not shy away potentially customers by such output at such often used
place.
Ciao,
Dscho
^ permalink raw reply
* Re: Pulling tags from git.git
From: Andreas Ericsson @ 2006-03-07 9:29 UTC (permalink / raw)
To: David Ho; +Cc: git
In-Reply-To: <4dd15d180603061054k36d1a434se7377ded1b3240bb@mail.gmail.com>
David Ho wrote:
> Okay sorry, git fetch --tags did the trick.
>
> Just out of curiosity, should git pull --tags behave similarly since
> the difference is git pull does a merge after a fetch?
>
With the git or git+ssh protocol, tags will be autofollowed when you do
a pull (only signed tags, I think). The auto-following is done by
detecting tags that are fetched, so when you did a pull using rsync the
tags weren't auto-followed but you got all the commits. Next, when you
changed protocol to git:// you already had all the commit objects, so
there was nothing to auto-detect tags on. Since you're using git:// now
it should work as advertised in the future though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-status too verbose?
From: Andreas Ericsson @ 2006-03-07 9:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Jaffe, Carl Worth, git
In-Reply-To: <7vacc36r4v.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> Why do people think mysterious single letter abbreviation is
> better than spelled out words in an output meant for human
> consumption?
>
Familiarity, I suspect.
>
> I agree that it would be useful if we had a tool that showed the
> two status that matter for each file, grouped together on one
> line, e.g.
>
> HEAD->index index->files
> ------------------------------------------------
> hello.c unmodified modified
> world.c modified unmodified
> frotz.c new unmodified
> ...
> garbage.c~ ??? n/a
>
> for the current index file and the current HEAD commit.
>
Could we have 'same' or some such instead of 'unmodified'? It's a bit
close to 'modified' for the eye to find it quickly.
> You obviously need to learn how to read it though. The first
> column means what you _would_ commit if you just said "git
> commit" without doing anything else now; the second column is
> what you _could_ commit if you did some update-index and then
> said "git commit" (or ran "git commit" with paths arguments).
>
Pretty-printing will be easier if the filename is last, and it will look
a lot neater if all columns are aligned.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-status too verbose?
From: Karl Hasselström @ 2006-03-07 9:17 UTC (permalink / raw)
To: git
In-Reply-To: <20060307053547.GK6346@always.joy.eth.net>
On 2006-03-07 11:05:47 +0530, Joshua N Pritikin wrote:
> On Mon, Mar 06, 2006 at 04:21:52PM -0800, Junio C Hamano wrote:
>
> > HEAD->index index->files
> > ------------------------------------------------
> > hello.c unmodified modified
> > world.c modified unmodified
> > frotz.c new unmodified
> > ...
> > garbage.c~ ??? n/a
>
> For what it's worth, this chart immediately made sense to me and I
> would prefer it to the current git-status output.
I agree. This kind of status information makes the whole index concept
an order of magnitude less confusing. In a way, it lets you learn what
the index is by example, rather than first having to learn what it is
in order to be able to grok the status information.
Fitting this in 80 columns should be a funny excercise, though. :-)
I'd suggest printing the filename last:
HEAD->index index->files
------------------------------------------------
unmodified modified hello.c
modified unmodified world.c
new unmodified frotz.c
...
??? n/a garbage.c~
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] cvsimport: Remove master-updating code
From: smurf @ 2006-03-07 9:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rajkumar S, git
In-Reply-To: <7vek1e6cnk.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3454 bytes --]
The code which tried to update the master branch was somewhat broken.
=> People should do that manually, with "git merge".
Signed-off-by: Matthias Urlichs <smurf@smurf.noris.de>
---
Junio C Hamano:
> I do not understand what cvsimport is trying to do here; I
> _suspect_ the part that updates the "master" branch head might
> be a bug.
>
This should fix it.
---
Documentation/git-cvsimport.txt | 6 ++++++
git-cvsimport.perl | 27 ++-------------------------
2 files changed, 8 insertions(+), 25 deletions(-)
4c28ef8000d68a0736084022a047019dca96c823
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index dfe86ce..57027b4 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -22,6 +22,12 @@ repository, or incrementally import into
Splitting the CVS log into patch sets is done by 'cvsps'.
At least version 2.1 is required.
+You should *never* do any work of your own on the branches that are
+created by git-cvsimport. The initial import will create and populate a
+"master" branch from the CVS repository's main branch which you're free
+to work with; after that, you need to 'git merge' incremental imports, or
+any CVS branches, yourself.
+
OPTIONS
-------
-d <CVSROOT>::
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index b46469a..02d1928 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -452,7 +452,6 @@ chdir($git_tree);
my $last_branch = "";
my $orig_branch = "";
-my $forward_master = 0;
my %branch_date;
my $git_dir = $ENV{"GIT_DIR"} || ".git";
@@ -488,21 +487,6 @@ unless(-d $git_dir) {
$last_branch = "master";
}
$orig_branch = $last_branch;
- if (-f "$git_dir/CVS2GIT_HEAD") {
- die <<EOM;
-CVS2GIT_HEAD exists.
-Make sure your working directory corresponds to HEAD and remove CVS2GIT_HEAD.
-You may need to run
-
- git read-tree -m -u CVS2GIT_HEAD HEAD
-EOM
- }
- system('cp', "$git_dir/HEAD", "$git_dir/CVS2GIT_HEAD");
-
- $forward_master =
- $opt_o ne 'master' && -f "$git_dir/refs/heads/master" &&
- system('cmp', '-s', "$git_dir/refs/heads/master",
- "$git_dir/refs/heads/$opt_o") == 0;
# populate index
system('git-read-tree', $last_branch);
@@ -889,17 +873,11 @@ if (defined $orig_git_index) {
# Now switch back to the branch we were in before all of this happened
if($orig_branch) {
- print "DONE\n" if $opt_v;
- system("cp","$git_dir/refs/heads/$opt_o","$git_dir/refs/heads/master")
- if $forward_master;
- unless ($opt_i) {
- system('git-read-tree', '-m', '-u', 'CVS2GIT_HEAD', 'HEAD');
- die "read-tree failed: $?\n" if $?;
- }
+ print "DONE; you may need to merge manually.\n" if $opt_v;
} else {
$orig_branch = "master";
print "DONE; creating $orig_branch branch\n" if $opt_v;
- system("cp","$git_dir/refs/heads/$opt_o","$git_dir/refs/heads/master")
+ system("git-update-ref", "refs/heads/master", "refs/heads/$opt_o")
unless -f "$git_dir/refs/heads/master";
system('git-update-ref', 'HEAD', "$orig_branch");
unless ($opt_i) {
@@ -907,4 +885,3 @@ if($orig_branch) {
die "checkout failed: $?\n" if $?;
}
}
-unlink("$git_dir/CVS2GIT_HEAD");
--
1.2.GIT
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
You will be run over by a bus.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply related
* Re: Any news on an Eclipse plugin?
From: Noel Grandin @ 2006-03-07 6:59 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060306173229.GA27965@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]
The subversion plugin (subclipse.tigris.org) might be a good starting
point since it delegates a lot of it's low-level work through an
interface called svnClientAdapter. Re-implementing that to talk to git
should get you something useful in a reasonable time-frame.
Note that an eclipse team plugin is a pretty complicated beast.
Shawn Pearce wrote:
>I'm considering starting an Eclipse plugin for GIT. So I did
>some digging to see if any existing projects have anything I can
>contribute to (rather than starting from scratch) but I only turned
>up a thread from May 2005 started by Jon Seymour:
>
> http://www.gelato.unsw.edu.au/archives/git/0505/3357.html
>
>anyone know anything newer? If there's nothing existing worth
>starting with other than the CVS or SVN plugins (as mentioned in
>this thread) I'll probably start putting together a prototype and
>start making it available early next week.
>
>I'm going to carefully read the thread that I linked to above before
>writing anything, so there's no need to start getting into the core
>and not so core discussion again. I'll read it over for myself. :-)
>
>
>
NOTICE: Please note that this email, and the contents thereof,
are subject to the standard Peralex email disclaimer, which may
be found at: http://www.peralex.com/disclaimer.html
If you cannot access the disclaimer through the URL attached
and you wish to receive a copy thereof please send
an email to email@peralex.com
^ permalink raw reply
* Re: git clone does not work with GIT_OBJECT_DIRECTORY set
From: Junio C Hamano @ 2006-03-07 6:29 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: git
In-Reply-To: <20060306013854.GH20768@kvack.org>
Benjamin LaHaise <bcrl@kvack.org> writes:
> On Sun, Mar 05, 2006 at 05:33:25PM -0800, Junio C Hamano wrote:
>> Please try it without GIT_OBJECT_DIRECTORY and see it works
>> correctly (I think it should). If that is the case, maybe
>> git-clone should explicitly unset GIT_OBJECT_DIRECTORY.
>
> Nope. There is no .git/objects directory, so how would it be able to
> find the objects?
Ah, I misunderstood what you were trying to do here. What you
meant with this is:
$ git clone linux-2.6.git bootcache.git
* linux-2.6.git is a local directory with HEAD, refs/* and stuff
but does not have objects/.
* bootcache.git is a local directory to be created anew.
Even though linux-2.6.git does not have objects subdirectory, it
is usually not a problem for you because you use GIT_OBJECT_DIRECTORY
for that.
Short answer for this is: sorry, "git clone" barebone Porcelain
does not support such a configuration if your source repository
is local. It works for destination, though:
$ export GIT_OBJECT_DIRECTORY=/tmp/foobla
$ git clone git://git.kernel.org/.../linux-2.6.git bootcache.git
You will get a single pack in /tmp/foobla/pack and would not
even have bootcache.git/.git/objects directory.
I should probably add that GIT_OBJECT_DIRECTORY environment
variable has outlived its usefulness. Initially we added that
flexibility without really knowing where it would lead us, but
it has turned out that often we would want the refs and objects
go hand-in-hand. Two or more repositories sharing the object
pool to save storage initially sounded a good idea, but that
would make fsck-objects cumbersome (you have to learn to ignore
dangling warnings, which makes checking rather pointless), and
packing less useful (you need to collect refs in all the
repositories that share the object pool).
I think the recommended way these days to set up multiple
repositories that work on related projects is to set up a single
clone from external source (e.g. linux-2.6.git), and make a set
of local "-l -s" clones out of it, and then fetch forked
upstreams into them. It would go something like this:
(initial setup)
$ git clone --bare git://git.kernel.org/.../torvalds/linux-2.6.git \
linux-2.6.git
(do this only once for each forked upstream)
$ git clone -l -s -n linux-2.6.git netdev-2.6
$ cd netdev-2.6
$ ed .git/remotes/origin ;# adjust to jgarzik tree's location
$ mkdir .git/refs/stashed
$ mv .git/refs/heads .git/refs/tags .git/refs/stashed
$ mkdir .git/refs/heads .git/refs/tags
$ git fetch -k
$ cp .git/refs/heads/origin .git/refs/heads/master
$ rm -fr .git/refs/stashed
$ git checkout
(update the shared master tree from time to time)
$ cd linux-2.6.git
$ GIT_DIR=. git fetch-pack \
git://git.kernel.org/.../torvalds/linux-2.6.git
(working in the individual forked tree is just as usual)
$ cd netdev-2.6
$ git fetch ;# or git pull
I think the part for each forked upstream above that consists of
10 or so commands above can be more or less automated. The part
that needs human input is the adjusting of .git/remotes/origin,
which depends on where each forked upstream tree is and what
branches there are of interest.
^ permalink raw reply
* Re: cvsimport woes
From: Junio C Hamano @ 2006-03-07 5:34 UTC (permalink / raw)
To: Rajkumar S; +Cc: git, Matthias Urlichs
In-Reply-To: <440C68B9.9030305@asianetindia.com>
I've run your reproduction recipe and also looked at #git log
from yesterday.
Here is what I see immediately after the initial cvs import:
$ git show-branch
* [master] Initial revision
! [origin] Initial revision
! [start] Imported sources
---
+ [start] Imported sources
*++ [master] Initial revision
And here is what I get immediately after the second one:
$ git show-branch
* [master] v2.0
! [origin] v2.0
! [start] Imported sources
---
*+ [master] v2.0
+ [start] Imported sources
*++ [master^] Initial revision
$ git diff --cached --abbrev -r
:100644 100644 b8b933b... e251870... M file.txt
:100644 100644 b8b933b... e251870... M file1.txt
I think what is happening is that cvsimport updates origin and
master branch HEAD without updating the working tree. I am not
sure what the cvsimport command line you used is intended to do:
git cvsimport -v -k -u -m -d $CVSROOT -C git/ src
Specifically, what branch, if any, is used as the "tracking
branch" (i.e. stores the unmodified copy from CVS)? I presume
it is "origin", in which case, I would have expected to see
something like this instead.
$ git show-branch
* [master] Initial revision
! [origin] v2.0
! [start] Imported sources
---
+ [origin] v2.0
+ [start] Imported sources
*++ [master^] Initial revision
$ git diff --cached --abbrev -r
(empty)
Then I would understand what cvsimport author means by "it does
not do fast forward, you have to do it yourself". What it means
is that the import only updates the tracking branch but does not
update your working tree; merging the updates to the tracking
branch made from the foreign SCM into your working branch is
left for you to perform whenever it is convenient for you to do
(meaning, you may have some intermediate change in your master
branch in which case you would first commit them first and then
merge from CVS). And if that is they way cvsimport is intended
to be used, then you would at this point do:
$ git pull . origin
to do the fast forward.
I do not understand what cvsimport is trying to do here; I
_suspect_ the part that updates the "master" branch head might
be a bug.
Smurf, mind clarifying what is happening here for me please?
^ permalink raw reply
* Re: git-status too verbose?
From: Joshua N Pritikin @ 2006-03-07 5:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacc36r4v.fsf@assigned-by-dhcp.cox.net>
On Mon, Mar 06, 2006 at 04:21:52PM -0800, Junio C Hamano wrote:
> HEAD->index index->files
> ------------------------------------------------
> hello.c unmodified modified
> world.c modified unmodified
> frotz.c new unmodified
> ...
> garbage.c~ ??? n/a
For what it's worth, this chart immediately made sense to me and I would
prefer it to the current git-status output.
^ permalink raw reply
* Re: git-unpack-objects < pack file in repository doesn't work!
From: Shawn Pearce @ 2006-03-07 4:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkvn54sv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > I totally didn't expect that behavior. But I should have. It makes
> > perfect sense.
>
> Good to hear that you two did not lose any data. I think the
> command should be documented as "not for interactive use without
> understanding what it does" ;-).
>
> What was the reason you wanted to use it? I think we should
> have a wrapper command to do what you wanted to achieve, so that
> people do not have to run unpack-objects by hand.
Don't bother.
I wanted to explode a pack because I'm starting work on an Eclipse
plugin for GIT. I thought I'd try going down the road of letting
the plugin read the repository directly, and write loose objects
directly, but leave pack construction to the native C code. So I
tried to clone my local GIT repository to a new directory (thus
had no loose objects at all) and unpack it to get loose objects.
That didn't go so well. :-)
So now I'm currently just playing around with a tiny repository I
created for testing (something like 50 objects total). Since I have
never packed it everything is loose, and that's working out OK...
I've already got loose object reading working, but thanks to
the trivially simple repository format in GIT (thanks Linus,
et.al.!) that amounted to a trivial Java implementation so its
nothing to really brag about yet. :-)
--
Shawn.
^ permalink raw reply
* Re: PATCH: Allow format-patch to attach patches
From: Mike McCormack @ 2006-03-07 3:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpskz5aqh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> The only two and half minor issues I might have about this are:
>
> (1) is the type text/x-patch appropriate?
I'm no expert on MIME types, unfortunately. Maybe text/x-diff makes
more sense? A few different projects require one of those two types
for diffs sent as attachments. My main concern is that mailers can
recognize that the attachment is text, then displayed with the message
so that people can see the patch without opening the attachment.
> (2) is it possible to cheaply come up with a safe mime-magic,
> instead of a hardcoded long string and hope it does not
> clash?
I agree that using a hardcoded long string isn't that great. Reading
all of the "diff-tree -p" output seems a bit expensive. How about using
some part of the patch's SHA1 combined with date/time?
> The remaining half issue is if would it make sense to sometimes
> optionally use non 8-bit CTE for the patch part.
Maybe allow something like:
git-format-patch --attach=quoted-printable
where the default would be 8bit. This require adding a perl script for
each Content-Transfer-Encoding that we support.
Mike
^ permalink raw reply
* Re: PATCH: Allow format-patch to attach patches
From: A Large Angry SCM @ 2006-03-07 3:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike McCormack, git
In-Reply-To: <7vpskz5aqh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Nicely done.
...
> The only two and half minor issues I might have about this are:
>
...
>
> (2) is it possible to cheaply come up with a safe mime-magic,
> instead of a hardcoded long string and hope it does not
> clash?
Base64 encode a large number (160?) of bits from /dev/urandom.
^ permalink raw reply
* Re: git-unpack-objects < pack file in repository doesn't work!
From: Junio C Hamano @ 2006-03-07 3:09 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060307022926.GB29180@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I totally didn't expect that behavior. But I should have. It makes
> perfect sense.
Good to hear that you two did not lose any data. I think the
command should be documented as "not for interactive use without
understanding what it does" ;-).
What was the reason you wanted to use it? I think we should
have a wrapper command to do what you wanted to achieve, so that
people do not have to run unpack-objects by hand.
One thing I _could_ think of is to explode a contaminated pack
so that you can repack. For example, every time I do "git
repack -a -d", the resulting pack ends up containing a couple of
commits from my "pu" branch that will become dangling when I
redo "pu" the next time. But then "git repack -a -d" is so
inexpensive these days, without unpacking things first, I do not
see the point of exploding a pack using unpack-objects in the
first place.
^ permalink raw reply
* Re: cvsimport woes
From: Martin Langhoff @ 2006-03-07 3:06 UTC (permalink / raw)
To: Rajkumar S; +Cc: git
In-Reply-To: <440C68B9.9030305@asianetindia.com>
On 3/7/06, Rajkumar S <rajkumars@asianetindia.com> wrote:
> You can use this script to reproduce this problem.
Rajkumar, does it work better if you add "sleep 10" before each
invocation of git-cvsimport?
cheers,
martin
^ permalink raw reply
* Re: git-unpack-objects < pack file in repository doesn't work!
From: Shawn Pearce @ 2006-03-07 2:29 UTC (permalink / raw)
To: git
In-Reply-To: <200603070213.02805.blaisorblade@yahoo.it>
Blaisorblade <blaisorblade@yahoo.it> wrote:
> It's not a bug, it's an undocumented feature. It should be documented as
> "git-unpack-objects < $pack; rm $pack" is something one would deem correct at
> first glance (luckily I just moved the pack away and did git-fsck-cache).
>
> To write an object, git-unpack-objects ends in
>
> unpack-objects.c:write_object -> sha1_file.c:write_sha1_file:
>
> /* Normally if we have it in the pack then we do not bother writing
> * it out into .git/objects/??/?{38} file.
> */
>
> This indeed works, so the files aren't unpacked.
Funny, I just did the exact same thing today, scratched my head and
said ``what did I just do!?!?!'' as I had deleted the pack before
discovering that nothing was actually unpacked. *sigh* At least
it was a clone of the real repository and thus didn't matter to me.
I totally didn't expect that behavior. But I should have. It makes
perfect sense.
--
Shawn.
^ permalink raw reply
* git-unpack-objects < pack file in repository doesn't work!
From: Blaisorblade @ 2006-03-07 1:13 UTC (permalink / raw)
To: git
It's not a bug, it's an undocumented feature. It should be documented as
"git-unpack-objects < $pack; rm $pack" is something one would deem correct at
first glance (luckily I just moved the pack away and did git-fsck-cache).
To write an object, git-unpack-objects ends in
unpack-objects.c:write_object -> sha1_file.c:write_sha1_file:
/* Normally if we have it in the pack then we do not bother writing
* it out into .git/objects/??/?{38} file.
*/
This indeed works, so the files aren't unpacked.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: PATCH: Allow format-patch to attach patches
From: Junio C Hamano @ 2006-03-07 1:01 UTC (permalink / raw)
To: Mike McCormack; +Cc: git
In-Reply-To: <440C352C.9070009@codeweavers.com>
Nicely done.
Especially I like the part that you explicitly set charset to
UTF-8 to the primary part.
The only two and half minor issues I might have about this are:
(1) is the type text/x-patch appropriate?
(2) is it possible to cheaply come up with a safe mime-magic,
instead of a hardcoded long string and hope it does not
clash?
You can just say "Yes it is an established practice, widely
accepted and that is what you are responding to so obviously you
can grok it ;-)" to (1). About (2), you would probably need to
read the "diff-tree -p" output beforehand if we want to be
absolutely sure, so punting on the issue like this might be the
best practical approach for now, but I am asking it anyway
because people may have better ideas.
The remaining half issue is if would it make sense to sometimes
optionally use non 8-bit CTE for the patch part. I do _NOT_
want to receive CTE=QP patch myself, nor I want to encourage it
(actually I would want to actively discourage it), but I do not
mind if people find use of such a patch in a distant corner of
the galaxy where I do not have to touch such a patch.
^ permalink raw reply
* Re: git-status too verbose?
From: Junio C Hamano @ 2006-03-07 0:21 UTC (permalink / raw)
To: Eric Jaffe, Carl Worth; +Cc: git
In-Reply-To: <38b80e980603040952j15152a21h2c903bd011d7e905@mail.gmail.com>
"Eric Jaffe" <jaffe.eric@gmail.com> writes:
> I was wondering if anyone else thinks that git-status should be more
> like "git-diff --name-status". That is,
> # A a/newfile.c
> # M a/oldfile.c
>
> instead of
> # new file: a/newfile.c
> # modified: a/oldfile.c
Why do people think mysterious single letter abbreviation is
better than spelled out words in an output meant for human
consumption?
The tag letters you get from "ls-files -t" are inconsistent with
what you would get from all the other git tools for historical
reasons, so if you want to do a single-letter abbreviation, you
first need to come up with a set of letters and translate the
output from ls-files -t into that.
Although I personally like Carl's suggestion a lot, I am still
ambivalent about it a bit.
I agree that it would be useful if we had a tool that showed the
two status that matter for each file, grouped together on one
line, e.g.
HEAD->index index->files
------------------------------------------------
hello.c unmodified modified
world.c modified unmodified
frotz.c new unmodified
...
garbage.c~ ??? n/a
for the current index file and the current HEAD commit.
You obviously need to learn how to read it though. The first
column means what you _would_ commit if you just said "git
commit" without doing anything else now; the second column is
what you _could_ commit if you did some update-index and then
said "git commit" (or ran "git commit" with paths arguments).
I think it is a valid view for people who know how internally
git barebone porcelain works using git lowlevel, and to them
(including me), the above is more concise and appear useful.
But I am not sure if it is appropriate for "git status", which
is the tool for commit-preview. The index "git status" is
showing is the index you would get if you were to run "git
commit" with the same set of parameters, exactly for that reason
(e.g. "git status -a -v" would see "unmodified" for all tracked
paths in index->files column in the above output).
^ permalink raw reply
* Re: SSH with alternative port number?
From: Brandon Philips @ 2006-03-06 21:59 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20060306214418.66E153525CB@atlas.denx.de>
Hello Wolfgang-
man(5) ssh_config
Add something like this to your .ssh/config file:
Host example
Hostname ssh.example.com
Port 2222
User wolfgang
Then use "example" as the hostname for the git commands instead of
ssh.example.com.
Best,
Brandon
--
http://ifup.org
On 22:44 Mon 06 Mar , Wolfgang Denk wrote:
> Hi,
>
> is there any way to specify an alternative port number for SSH based
> remote repository access?
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> "Here's a fish hangs in the net like a poor man's right in the law.
> 'Twill hardly come out." - Shakespeare, Pericles, Act II, Scene 1
> -
> 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
* Re: SSH with alternative port number?
From: Belmar-Letelier @ 2006-03-06 22:01 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20060306214418.66E153525CB@atlas.denx.de>
Wolfgang Denk a écrit :
> Hi,
>
> is there any way to specify an alternative port number for SSH based
> remote repository access?
>
> Best regards,
>
> Wolfgang Denk
>
Use your .ssh/config file
$ more /home/luis/.ssh/config
host 217.111.187.226
hostname bmi
port 1234
Luis
--
Luis Belmar-Letelier
^ permalink raw reply
* SSH with alternative port number?
From: Wolfgang Denk @ 2006-03-06 21:44 UTC (permalink / raw)
To: git
Hi,
is there any way to specify an alternative port number for SSH based
remote repository access?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Here's a fish hangs in the net like a poor man's right in the law.
'Twill hardly come out." - Shakespeare, Pericles, Act II, Scene 1
^ permalink raw reply
* Re: Looking for SCM that lets me publish part of a repository
From: Sam Vilain @ 2006-03-06 20:58 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1141608679.16980.12.camel@mattlaptop>
Matt McCutchen wrote:
>Dear GIT people,
>
>For the last week or so, I have been looking for a SCM system to hold
>many of my projects, some of which are available to the public and
>others of which are not. It would be nice if I could use a single large
>private repository on my computer with each project in a separate
>folder. Then I would like to pull some of the projects (but not all)
>into a world-readable repository on my Web site. I have looked at
>several SCMs and have not found a way to make any of them do this, but I
>like GIT best on other grounds. Is there a way I can coerce GIT to
>clone and pull one folder out of a repository but ignore the rest?
>
>
SVK works like this, you get one (by default) repository in your ~ which
you then mirror published projects to, and it tracks local changes as a
branch which you can then commit back 'upstream' (or to your published
repository) with.
Jeff King also recently posted a script to extract out a part of a
repository into another one, which is a related concept.
Sam.
^ 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