* Re: [PATCH 4/5] Let git-add--interactive read colors from configuration
From: Junio C Hamano @ 2007-11-23 9:17 UTC (permalink / raw)
To: Jeff King
Cc: Dan Zwell, Git Mailing List, Shawn O. Pearce, Wincent Colaiuta,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld,
Jakub Narebski
In-Reply-To: <20071123090918.GC5196@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Note that there is one tricky part of config_bool, which is what
> config_bool('my.key', undef) should do (is it "default false" or "no
> default"?).
I am glad somebody finally got to the trick question I posed
earlier ;-)
But config_bool('key') and config_bool('key', undef) would both
return undef to say "The value is false" when key does not
exist, so it was not much of a trick. It does not make a
difference if the undef came because the default parameter was
undef, or because there was no default parameter given and the
built-in behaviour of config_bool() was to return undef for a
missing key.
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Jakub Narebski @ 2007-11-23 9:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, Johannes Schindelin, git
In-Reply-To: <7v4pfe7g4e.fsf@gitster.siamese.dyndns.org>
On Thu, 22 Nov 2007, Junio C Hamano :
> "Santi Béjar" <sbejar@gmail.com> writes:
>
>> Sorry but I do not understand this. I think this two lines could be equivalent:
>>
>> git push --bundle bundle.bdl "refs/heads/master:refs/remotes/bundle/master"
>> git bundle create bundle.bdl refs/heads/master ^refs/remotes/bundle/master
>
> Interesting.
>
> $ git push $something ours:theirs
>
> has defined semantics for any value of $something.
>
> * give $something objects it lacks, so that the object $ours
> become complete in there;
>
> * set the ref in $theirs to point at the object $ours.
>
> So "git push bundle.bdl refspec" should:
>
> * First read bundle.bdl, to find out what objects it gives to
> the recipients;
>
> * Add missing objects to it to make it up to date wrt "ours",
> iow, fetching from the updated bundle would now give "ours";
>
> * Record the object "ours" as "theirs" ref, iow, listing
> the updated bundle would show "theirs" ref pointing at that
> object.
>
> If bundle.bdl does not exist yet, it is like pushing into a
> freshly initialized empty repository.
But for that I think "git bundle" should learn new subcommand:
"git bundle update", which would use refs existing in given
bundle as prerequisites, and either update bundle (create anew
or just concatenate next pack) or create incremental bundle.
Something similar to incremental mode or update command of
archivers...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Jakub Narebski @ 2007-11-23 9:28 UTC (permalink / raw)
To: David Kågedal; +Cc: git, Jonas Juselius
In-Reply-To: <87tzneu1tw.fsf@lysator.liu.se>
On Thu, 22 Nov 2007, David Kågedal wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> A few comments (from what I checked so far):
>>
>> 1. It is "man git-checkout" (or "git checkout --help"),
>> not "man git checkout"
>
> Or "git help checkout", which is what I usually use (for some reason).
Or, at least for now "git checkout --help", which requires only
adding "--help" at the end. At least for now because some commands
return short summary for "--help" and I think it is considered
that it should be done that way for all porcelain commands.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Junio C Hamano @ 2007-11-23 9:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Santi Béjar, Johannes Schindelin, git
In-Reply-To: <200711231018.49322.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Thu, 22 Nov 2007, Junio C Hamano :
>> "Santi Béjar" <sbejar@gmail.com> writes:
>>
>>> Sorry but I do not understand this. I think this two lines could be equivalent:
>>>
>>> git push --bundle bundle.bdl "refs/heads/master:refs/remotes/bundle/master"
>>> git bundle create bundle.bdl refs/heads/master ^refs/remotes/bundle/master
>>
>> Interesting.
>>
>> $ git push $something ours:theirs
>>
>> has defined semantics for any value of $something.
>> ...
>> If bundle.bdl does not exist yet, it is like pushing into a
>> freshly initialized empty repository.
>
> But for that I think "git bundle" should learn new subcommand:
> "git bundle update", which would use refs existing in given
> bundle as prerequisites, and either update bundle (create anew
> or just concatenate next pack) or create incremental bundle.
>
> Something similar to incremental mode or update command of
> archivers...
I was disagreeing with Santi's "'push --bundle' and 'bundle
create' can be equivalent". They can't be, as "push" is always
"update" and never "create". So I do not quite get your "But for
that I think"; I think you are just agreeing with me.
Even if we taught "push" to create (which I doubt would happen
due to its security and administrative implications), it would
not make the two any closer to being equivalent. For them to
become equivalent, we would need to have "push" unlearn how to
update, which would never happen ;-).
^ permalink raw reply
* Re: [PATCH] Converted git-merge-ours.sh -> builtin-merge-ours.c
From: Jakub Narebski @ 2007-11-23 9:42 UTC (permalink / raw)
To: git
In-Reply-To: <4745E45C.7@gmail.com>
Thomas Harning wrote:
> diff --git a/git-merge-ours.sh b/git-merge-ours.sh
> deleted file mode 100755
> index c81a790..0000000
> --- a/git-merge-ours.sh
> +++ /dev/null
Shouldn't script version be moved to contrib/examples/ as is git.git
policy, or is it too simple script?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] git-cvsserver runs hooks/post-receive
From: Michael Witten @ 2007-11-23 9:12 UTC (permalink / raw)
To: git, gitster; +Cc: Michael Witten
git-cvsserver just did the following:
(1) run hooks/update
(2) commit if hooks/update passed
This commit simply adds:
(3) run hooks/post-receive
Also, there are a few grammar cleanups and
consistency improvements.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
git-cvsserver.perl | 27 ++++++++++++++++++++-------
1 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 0d55fec..8d4d735 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -1211,13 +1211,13 @@ sub req_ci
chdir $tmpdir;
- # populate the temporary index based
+ # populate the temporary index
system("git-read-tree", $parenthash);
unless ($? == 0)
{
die "Error running git-read-tree $state->{module} $file_index $!";
}
- $log->info("Created index '$file_index' with for head $state->{module} - exit status $?");
+ $log->info("Created index '$file_index' for head $state->{module} - exit status $?");
my @committedfiles = ();
my %oldmeta;
@@ -1237,7 +1237,7 @@ sub req_ci
my ( $filepart, $dirpart ) = filenamesplit($filename);
- # do a checkout of the file if it part of this tree
+ # do a checkout of the file if it is part of this tree
if ($wrev) {
system('git-checkout-index', '-f', '-u', $filename);
unless ($? == 0) {
@@ -1324,11 +1324,11 @@ sub req_ci
exit;
}
- # Check that this is allowed, just as we would with a receive-pack
- my @cmd = ( $ENV{GIT_DIR}.'hooks/update', "refs/heads/$state->{module}",
+ ### Emulate git-receive-pack by running hooks/update
+ my @hook = ( $ENV{GIT_DIR}.'hooks/update', "refs/heads/$state->{module}",
$parenthash, $commithash );
- if( -x $cmd[0] ) {
- unless( system( @cmd ) == 0 )
+ if( -x $hook[0] ) {
+ unless( system( @hook ) == 0 )
{
$log->warn("Commit failed (update hook declined to update ref)");
print "error 1 Commit failed (update hook declined)\n";
@@ -1337,6 +1337,7 @@ sub req_ci
}
}
+ ### Update the ref
if (system(qw(git update-ref -m), "cvsserver ci",
"refs/heads/$state->{module}", $commithash, $parenthash)) {
$log->warn("update-ref for $state->{module} failed.");
@@ -1344,6 +1345,18 @@ sub req_ci
exit;
}
+ ### Emulate git-receive-pack by running hooks/post-receive
+ my $hook = $ENV{GIT_DIR}.'hooks/post-receive';
+ if( -x $hook ) {
+ open(my $pipe, "| $hook") || die "can't fork $!";
+
+ local $SIG{PIPE} = sub { die 'pipe broke' };
+
+ print $pipe "$parenthash $commithash refs/heads/$state->{module}\n";
+
+ close $pipe || die "bad pipe: $! $?";
+ }
+
$updater->update();
# foreach file specified on the command line ...
--
1.5.3.5.1623.g37154
^ permalink raw reply related
* git --prune --aggresive
From: Jakub Narebski @ 2007-11-23 9:58 UTC (permalink / raw)
To: git
2396:[gitweb/web@git]# git gc --aggresive --prune
usage: git-gc [--prune] [--aggressive]
2397:[gitweb/web@git]# git gc --prune --aggresive
usage: git-gc [--prune] [--aggressive]
2398:[gitweb/web@git]# git --version
git version 1.5.3.5
Either usage string should be fixed, as it suggests that you can specify
both --aggresive and --prune, or git-gc should.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Jakub Narebski @ 2007-11-23 10:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, Johannes Schindelin, git
In-Reply-To: <7vejehux3y.fsf@gitster.siamese.dyndns.org>
On Fri, 23 Nov 2007, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> On Thu, 22 Nov 2007, Junio C Hamano :
>>> "Santi Béjar" <sbejar@gmail.com> writes:
>>>
>>>> Sorry but I do not understand this. I think this two lines could be equivalent:
>>>>
>>>> git push --bundle bundle.bdl "refs/heads/master:refs/remotes/bundle/master"
>>>> git bundle create bundle.bdl refs/heads/master ^refs/remotes/bundle/master
>>>
>>> Interesting.
>>>
>>> $ git push $something ours:theirs
>>>
>>> has defined semantics for any value of $something.
>>> ...
>>> If bundle.bdl does not exist yet, it is like pushing into a
>>> freshly initialized empty repository.
>>
>> But for that I think "git bundle" should learn new subcommand:
>> "git bundle update", which would use refs existing in given
>> bundle as prerequisites, and either update bundle (create anew
>> or just concatenate next pack) or create incremental bundle.
>>
>> Something similar to incremental mode or update command of
>> archivers...
>
> I was disagreeing with Santi's "'push --bundle' and 'bundle
> create' can be equivalent". They can't be, as "push" is always
> "update" and never "create". So I do not quite get your "But for
> that I think"; I think you are just agreeing with me.
Bad choice of words on my part... and I didn't parse that you were
disagreeing as well as commenting. :-/
> Even if we taught "push" to create (which I doubt would happen
> due to its security and administrative implications), it would
> not make the two any closer to being equivalent. For them to
> become equivalent, we would need to have "push" unlearn how to
> update, which would never happen ;-).
I also think that pushing to bundle might be not a good idea;
but I think that "git clone <bundle>" should just work.
Nevertheless I think that having "git bundle update" or
"git bundle create --reference=<old bundle>" (or both) would be
a good thing, as it would free us from remembering or tagging when
last bundle was created.
Could anyone who uses "git bundle" actively raise a voice?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git Screencast ?
From: Andreas Ericsson @ 2007-11-23 10:05 UTC (permalink / raw)
To: Michael Donaghy; +Cc: git
In-Reply-To: <fi5bet$brl$1@ger.gmane.org>
Michael Donaghy wrote:
>
> also , what do you think of git-gui ? , I think it is the best one
>
I don't use it. Partly because I tested it out when it was far from
ready and am still somewhat traumatized by the experience, and partly
because I'm very comfortable with the command-line tools and have
found a workflow that works nicely for me.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git --prune --aggresive
From: Jakub Narebski @ 2007-11-23 10:08 UTC (permalink / raw)
To: git
In-Reply-To: <200711231058.46578.jnareb@gmail.com>
Jakub Narebski wrote:
> 2396:[gitweb/web@git]# git gc --aggresive --prune
> usage: git-gc [--prune] [--aggressive]
> 2397:[gitweb/web@git]# git gc --prune --aggresive
> usage: git-gc [--prune] [--aggressive]
> 2398:[gitweb/web@git]# git --version
> git version 1.5.3.5
>
> Either usage string should be fixed, as it suggests that you can specify
> both --aggresive and --prune, or git-gc should.
I'm very sorry, my mistake: --aggresive instead of --aggressive.
Please disregard this message...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git Screencast ?
From: Johannes Gilger @ 2007-11-23 10:14 UTC (permalink / raw)
To: Michael Donaghy; +Cc: git
In-Reply-To: <fi5bet$brl$1@ger.gmane.org>
On 22/11/07 20:47, Michael Donaghy wrote:
> Yes thank you , although a screen cast would still be ideal , the
> documentation is very good,
> also , what do you think of git-gui ? , I think it is the best one
Hi Michael,
I think you're trying to hide the complexity of git. The problem with
graphical tools is that they hide complexity from the user, which in
some cases is only possibly/good if the user has understood the
underlying principles already. Also I think that there are many things
which can be done much quicker using a command-line than any gui (as all
of the people here will agree). Git is not Time-Machine (this thing from
Apple). It is also no good idea to try to view git from a svn's point of
view, or try to compare commands. It took me a while to get over that
and accept that git is different. I was frustated (and still am
sometimes) but i finally understood the whole concept.
About screencasts: I haven't watched that many screencasts in general,
but I can hardly imagine that they are better way of teaching things
than reading a manual. Watching someone type in commands, hitting
"Pause", then trying it myself doesn't seem more intuitive to me than
just reading a manual and typing the commands given in regular
intervals. Maybe someone can enlighten me about the use of screencasts
(in a command-line environment).
Greetings,
Jojo
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Santi Béjar @ 2007-11-23 10:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Johannes Schindelin, git
In-Reply-To: <7vejehux3y.fsf@gitster.siamese.dyndns.org>
On Nov 23, 2007 10:31 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> I was disagreeing with Santi's "'push --bundle' and 'bundle
> create' can be equivalent". They can't be, as "push" is always
> "update" and never "create". So I do not quite get your "But for
> that I think"; I think you are just agreeing with me.
>
> Even if we taught "push" to create (which I doubt would happen
> due to its security and administrative implications), it would
> not make the two any closer to being equivalent. For them to
> become equivalent, we would need to have "push" unlearn how to
> update, which would never happen ;-).
>
OK. So git push will never understand bundles.
My motivation was to have a similar workflow with bundles as with
pushes, or at least as similar as possible. So another possible
workflow would be with a:
git bundle push [<bundle> [<refspec>]]
that creates a bundle
# Have a project with different branches (master, next, pu)
$ git bundle push bundle.bdl
# would create a complete bundle.bdl with all the local branches (with HEAD)
# You send it to the other person and he does:
$ git clone bundle.bdl project
$ cat .git/config
...
[remote "origin"]
url = /path/to/bundle.bdl
fetch = +refs/heads/*:refs/remotes/origin/*
# He makes changes, commits and so on and then he wants to send to back a bundle
$ git bundle push [<remote>]
# This creates an incremental bundle with the local branches (with
HEAD) as specified
# by remote.<remote>.* (possibly with an implicit "push" line
"refs/heads/*:refs/heads/*"
# And considering the remotes/origin/* as the bases for the bundle
# Then I got it and do a:
$ git remote add bundle /path/to/bundle
$ git fetch
# Now maybe I just want to send him the master branch
$ git bundle push origin master:master
# If I want to send him a complete bundle
$ git bundle push
The important part, for me, is to keep remote tracking branches to
know the bases for the next bundle. It does not matter if it is "git
push", "git bundle push", "git push --bundle", "git bundle update",
...
Santi
^ permalink raw reply
* Re: [PATCH 5/5] Added diff hunk coloring to git-add--interactive
From: Jeff King @ 2007-11-23 10:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dan Zwell, Git Mailing List, Shawn O. Pearce, Wincent Colaiuta,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld,
Jakub Narebski
In-Reply-To: <7v1wai3qrw.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 22, 2007 at 01:37:55PM -0800, Junio C Hamano wrote:
> > Unfortunately, there is a historical wart that probably still needs
> > supporting, which is that the original names were diff.color.*. Or have
> > we officially removed support for that yet?
>
> Neither officially or unofficially yet, but we can start the
> process of making it official with an early announcement. I do
> not think we would hurt people as long as a long enough advance
> notice is given.
Andy Parkins added color.* (and removed documentation for *.color)
almost a year ago (in a159ca0c). But I don't think there has been an
official deprecation notice.
> I however am wondering if we need to have so many "enable color
> support" switches. color.status, color.diff, and now yet
> another color.interactive? Who sets color.status and/or
> color.interactive to auto without setting color.diff to auto as
> well?
Yes, I have often thought this, as well, and a "color.all" would
probably be convenient.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-11-23 10:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vve7tuz3a.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 23, 2007 at 12:48:25AM -0800, Junio C Hamano wrote:
> * jk/send-pack (Tue Nov 20 06:18:01 2007 -0500) 29 commits
> + send-pack: cluster ref status reporting
Did we decide that printing the "maybe you need to pull" hint is not
worth doing?
> * jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
> . handle renames using similarity engine
> . introduce generic similarity library
> . change hash table calling conventions
>
> This was an attempt to use different strategy to speed up
> similarity computation, but does not work quite well as is.
This is still on my long-term todo list, but obviously needs quite a bit
of cleanup. Eventually I will get around to it.
I wonder if it is worth dropping from 'pu'. It doesn't pass the tests,
making it harder to play with other pu topics, and it is not being
actively worked on or tested by anyone.
-Peff
^ permalink raw reply
* [PATCH] Update RelNotes for 1.5.4 to reflect change in git-status output.
From: David Symonds @ 2007-11-23 11:13 UTC (permalink / raw)
To: Junio Hamano; +Cc: git, David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
Documentation/RelNotes-1.5.4.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/RelNotes-1.5.4.txt b/Documentation/RelNotes-1.5.4.txt
index a4a2a7f..70d1d6c 100644
--- a/Documentation/RelNotes-1.5.4.txt
+++ b/Documentation/RelNotes-1.5.4.txt
@@ -86,6 +86,10 @@ Updates since v1.5.3
to allow checking out a path outside the current directory
without cd'ing up.
+ * "git status" from a subdirectory now shows relative paths
+ which makes copy-and-pasting for git-checkout/git-add/git-rm
+ easier.
+
* Output processing for '--pretty=format:<user format>' has
been optimized.
--
1.5.3.1
^ permalink raw reply related
* Re: git --prune --aggresive
From: Matthieu Moy @ 2007-11-23 11:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200711231108.16676.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Jakub Narebski wrote:
>
>> 2396:[gitweb/web@git]# git gc --aggresive --prune
>> usage: git-gc [--prune] [--aggressive]
>> 2397:[gitweb/web@git]# git gc --prune --aggresive
>> usage: git-gc [--prune] [--aggressive]
>> 2398:[gitweb/web@git]# git --version
>> git version 1.5.3.5
>>
>> Either usage string should be fixed, as it suggests that you can specify
>> both --aggresive and --prune, or git-gc should.
>
> I'm very sorry, my mistake: --aggresive instead of --aggressive.
> Please disregard this message...
Now, for the cool thing: with the latest git, I get the following.
$ git gc --aggresive --prune
error: unknown option `aggresive' <----- this is what you wanted.
usage: git-gc [options]
--prune prune unreferenced objects
--aggressive be more thorough (increased runtime)
--auto enable auto-gc mode
$ _
Thanks, parse_options.[ch]!
--
Matthieu
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Johannes Schindelin @ 2007-11-23 12:18 UTC (permalink / raw)
To: Santi Béjar; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <8aa486160711230213q6038037epe2cbd0240db8b612@mail.gmail.com>
Hi,
On Fri, 23 Nov 2007, Santi B?jar wrote:
> My motivation was to have a similar workflow with bundles as with
> pushes, or at least as similar as possible. So another possible workflow
> would be with a:
>
> git bundle push [<bundle> [<refspec>]]
>
> that creates a bundle
What about
git bundle create retort.bundle --all \
--not $(git ls-remote the-other.bundle | cut -c1-40)
Hmm?
If you need that quite often, it should not be hard at all for you to add
an option to the "create" named "--haves-from=<bundle>".
But I'd rather script it.
Ciao,
Dscho
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Nguyen Thai Ngoc Duy @ 2007-11-23 12:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711210336210.27959@racer.site>
On Nov 21, 2007 10:40 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> [WIP: this does not handle tags yet, and it lacks a test script
> as well as documentation.]
>
> This program dumps (parts of) a git repository in the format that
> fast-import understands.
>
> For clarity's sake, it does not use the 'inline' method of specifying
> blobs in the commits, but builds the blobs before building the commits.B
>
> ---
> I am way too tired now to continue, but maybe someone else wants
> to pick up the ball.
Well, I would better be back on setup_git_directory() than picking up
the ball. I have a suggestion though. git-fast-export and
git-fast-import should support bundle. Bundle is very handy for
transferring a bunch of commits, but it does not (cannot?) hold tags
and branches. With git-fast-{im,ex}port, we will have a perfect
transportation for disconnected development.
> Oh, and it relies on "int" being castable to void * and vice
> versa. Is anybody aware of a platform where this can lead to
> problems?
>
> And yes, I will add a copyright when I woke up again.
--
Duy
^ permalink raw reply
* Re: Adding push configuration to .git/config
From: MichaelTiloDressel @ 2007-11-23 13:07 UTC (permalink / raw)
To: prohaska; +Cc: git
On Nov 22, 2007, at 12:23 PM, Johannes Schindelin wrote:
>You know that I believe the current default is not such a
>choice.
To me the default is not very clear. I read somewhere (I wish I could
find where that was again)
that push will e.g. push all the remotes that do not contain a push line
by default
(or maybe only in case the remote belonging to the current branch does
not contain a push?).
Anyway the way I try at the moment to have push by default only push the
current branch
is by setting up a separate remote for each branch even if they belong
to the same remote
subdirectory. In addition I have a remote named origin which contains a
line:
push = nothing:nowhere
which creates an error for the default case that has no explicit remote.
My .git/config looks something like this:
[remote "origin"
url = git+ssh://myuid@server/gitrepos/myprogit
fetch = +refs/heads/master:refs/remotes/origin/master
fetch =
+refs/heads/TopicA_v0.14_Branch:refs/remotes/origin/TopicA_v0.14_Branch
fetch =
+refs/heads/mypro-v0.31_Branch:refs/remotes/origin/mypro-v0.31_Branch
push = nothing:nowhere
[remote "master"]
url = git+ssh://myuid@server/gitrepos/myprogit
fetch = +refs/heads/master:refs/remotes/origin/master
push = refs/heads/master:refs/heads/master
[remote "topicA"]
url = git+ssh://myuid@server/gitrepos/myprogit
fetch =
+refs/heads/TopicA_v0.14_Branch:refs/remotes/origin/TopicA_v0.14_Branch
push =
refs/heads/TopicA_v0.14_Branch:refs/heads/TopicA_v0.14_Branch
[remote "mypro-v0.31"]
url = git+ssh://myuid@server/gitrepos/myprogit
fetch =
+refs/heads/mypro-v0.31_Branch:refs/remotes/origin/mypro-v0.31_Branch
push =
refs/heads/mypro-v0.31_Branch:refs/heads/mypro-v0.31_Branch
[branch "master"]
remote = master
merge = refs/heads/master
[branch "mypro-v0.31_Branch"]
remote = mypro-v0.31
merge = refs/heads/mypro-v0.31_Branch
[branch "TopicA_v0.14_Branch"]
remote = topicA
merge = refs/heads/TopicA_v0.14_Branch
Cheers,
Michael
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-11-23 13:23 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20071123103003.GB6754@sigill.intra.peff.net>
Hi,
On Fri, 23 Nov 2007, Jeff King wrote:
> On Fri, Nov 23, 2007 at 12:48:25AM -0800, Junio C Hamano wrote:
>
> > * jk/send-pack (Tue Nov 20 06:18:01 2007 -0500) 29 commits
> > + send-pack: cluster ref status reporting
>
> Did we decide that printing the "maybe you need to pull" hint is not
> worth doing?
Maybe we could change the (non-fast forward) message into (non-fast
forward; need to pull?).
Just an idea.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Mention that git-rm can be an appropriate resolution as well as git-add.
From: David Symonds @ 2007-11-23 13:38 UTC (permalink / raw)
To: Junio Hamano; +Cc: git, David Symonds
Especially when using git-cherry-pick, removing files that are unmerged can be
a logical action. This patch merely changes the informative text to be less
confusing.
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
builtin-revert.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index 365b330..d9ed40d 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -366,7 +366,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
die ("Error wrapping up %s", defmsg);
fprintf(stderr, "Automatic %s failed. "
"After resolving the conflicts,\n"
- "mark the corrected paths with 'git add <paths>' "
+ "mark the corrected paths with 'git add <paths>' or 'git rm <paths>' "
"and commit the result.\n", me);
if (action == CHERRY_PICK) {
fprintf(stderr, "When commiting, use the option "
--
1.5.3.1
^ permalink raw reply related
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-23 14:31 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0711230431x1b0432f6uc9472b2f67514463@mail.gmail.com>
Hi,
On Fri, 23 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> On Nov 21, 2007 10:40 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > [WIP: this does not handle tags yet, and it lacks a test script
> > as well as documentation.]
> >
> > This program dumps (parts of) a git repository in the format that
> > fast-import understands.
> >
> > For clarity's sake, it does not use the 'inline' method of specifying
> > blobs in the commits, but builds the blobs before building the commits.B
> >
> > ---
> > I am way too tired now to continue, but maybe someone else wants
> > to pick up the ball.
>
> Well, I would better be back on setup_git_directory() than picking up
> the ball.
Concur.
> I have a suggestion though. git-fast-export and git-fast-import should
> support bundle.
I think this is not what fast-export and fast-import are about. They use
an easy to generate, and easy to edit, format.
Bundles are optimised transport mechanisms for sneaker net. They are not
to be meant to be easy to edit, but as small as possible.
> Bundle is very handy for transferring a bunch of commits, but it does
> not (cannot?) hold tags and branches.
But they can! Nothing prevents you from calling
git bundle create a1.bundle refs/tags/v1.0.0 refs/heads/next
(At least this is the idea, haven't tested yet).
Ciao,
Dscho
^ permalink raw reply
* Re: Temporary directories getting errantly added into trees
From: Marco Costalba @ 2007-11-23 14:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sam Vilain, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711221052280.27959@racer.site>
On Nov 22, 2007 11:55 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> But I don't know about QGit, StGit, etc...
>
QGit does not rely on .dotest or any other temporary file produced by git
Interface with git is only through git commands.
Thanks
Marco
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Junio C Hamano @ 2007-11-23 15:06 UTC (permalink / raw)
To: Santi Béjar; +Cc: Junio C Hamano, Jakub Narebski, Johannes Schindelin, git
In-Reply-To: <8aa486160711230213q6038037epe2cbd0240db8b612@mail.gmail.com>
"Santi Béjar" <sbejar@gmail.com> writes:
> OK. So git push will never understand bundles.
Why not? Because you will not code it?
I am not opposed to the notion of "pushing to a bundle to
update it." I am just saying that "pushing to create" only for
bundle and not regular repository is very inconsistent.
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Santi Béjar @ 2007-11-23 15:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Johannes Schindelin, git
In-Reply-To: <7vabp5uhke.fsf@gitster.siamese.dyndns.org>
On Nov 23, 2007 4:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Santi Béjar" <sbejar@gmail.com> writes:
>
> > OK. So git push will never understand bundles.
>
> Why not?
Sorry, I misunderstood you, because pushing to an existing
bundle loses information, and that is also inconsistent with pushing
to regular repositories.
> Because you will not code it?
>
> I am not opposed to the notion of "pushing to a bundle to
> update it." I am just saying that "pushing to create" only for
> bundle and not regular repository is very inconsistent.
Santi
^ 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