* Re: Tracking CVS
From: Petr Baudis @ 2006-06-22 13:58 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606220541y15d66fa6t33ab0c80ae05f764@mail.gmail.com>
Dear diary, on Thu, Jun 22, 2006 at 02:41:16PM CEST, I got a letter
where Jon Smirl <jonsmirl@gmail.com> said that...
> I'm tracking cvs using this sequence.
>
> cvs update
> cg rm -a
> cg commit
> cg add -r .
> cg commit
>
> Is there a way to avoid the two commits? If you do the add with out
> the intervening commit it just adds the files back.
I think the most straightforward way is:
cvs update
cg-rm -a
cg-status -wns \? | xargs cg-add
cg-commit
If you want to be careful about filenames polluted by non-newline
whitespaces,
cg-status -wns \? | tr '\n' '\0' | xargs -0 cg-add
If you want to be safe even with filenames containing newlines, you need
to go at the Git level:
git-ls-files -z --others | \
xargs -0 git-update-index --add --
Perhaps we might make a special command which would sync the index set
with the working copy set...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: git pull w/o checkout?
From: Mathieu Chouquet-Stringer @ 2006-06-22 13:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: Jeff King, git
In-Reply-To: <6C519A4B-9253-49BB-BF68-DCD557DACCB7@kernel.crashing.org>
galak@kernel.crashing.org (Kumar Gala) writes:
> Ahh, I see. I can than just copy the 'origin' ref over 'master'.
Or use git fetch -u ?
--
Mathieu Chouquet-Stringer mchouque@free.fr
^ permalink raw reply
* Re: git pull w/o checkout?
From: Jakub Narebski @ 2006-06-22 13:32 UTC (permalink / raw)
To: git
In-Reply-To: <A4C01915-3337-460C-BE19-7AC17249BE50@kernel.crashing.org>
Kumar Gala wrote:
>
> On Jun 22, 2006, at 8:13 AM, Jeff King wrote:
>
>> On Thu, Jun 22, 2006 at 08:10:10AM -0500, Kumar Gala wrote:
>>
>>>> git-fetch?
>>> Its the first half, still need to resolve FETCH_HEAD, HEAD, etc..
>>
>> Can you elaborate on what you're trying to accomplish?
>
> A local mirror of a git tree. I can do the clone easy enough, its
> trying to figure out the updates after the fact that is the issue.
Assuming typical configuration, with the following in remotes/origin
---[ <path-to-repo>/.git/remotes/origin ]----
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: refs/heads/master:refs/heads/origin
Pull:+refs/heads/pu:refs/heads/pu
Pull: refs/heads/man:refs/heads/man
Pull: refs/heads/html:refs/heads/html
Pull: refs/heads/next:refs/heads/next
Pull: refs/heads/todo:refs/heads/todo
Pull: refs/heads/maint:refs/heads/maint
---------------------------------------------
to update your repository, do:
$ git checkout master
$ git fetch origin
Any branch except listed ot fhose fetched to will do, or even any command
that leaves HEAD different than one of the branches fetched to. Everything
is updated. Then you can do the second part of pull, using
$ git checkout master
$ git pull . master
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Make -p --stat and --stat -p behave like --patch-with-stat
From: Timo Hirvonen @ 2006-06-22 13:25 UTC (permalink / raw)
To: junkio; +Cc: git
git log log only
git log --stat log with stat
git log -p log with patch
git log --stat -p log with patch (no stat!)
git log -p --stat log with stat (no patch!)
git log --patch-with-stat log with patch and stat
This patch makes -p --stat and --stat -p work like --patch-with-stat.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
Maybe DIFF_FORMAT_* should be reworked instead but this was easy.
Only negative impact of this patch is that if you have a alias
l=log --stat
then you can't override --stat with "git l -p", it will still show
diffstat, but I don't think it matters.
diff.c | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 9e9cfc8..75632d3 100644
--- a/diff.c
+++ b/diff.c
@@ -1382,16 +1382,27 @@ int opt_arg(const char *arg, int arg_sho
int diff_opt_parse(struct diff_options *options, const char **av, int ac)
{
const char *arg = av[0];
- if (!strcmp(arg, "-p") || !strcmp(arg, "-u"))
+ if (!strcmp(arg, "-p") || !strcmp(arg, "-u")) {
+ if (options->output_format == DIFF_FORMAT_DIFFSTAT) {
+ // --stat -p
+ options->with_stat = 1;
+ }
options->output_format = DIFF_FORMAT_PATCH;
+ }
else if (opt_arg(arg, 'U', "unified", &options->context))
options->output_format = DIFF_FORMAT_PATCH;
else if (!strcmp(arg, "--patch-with-raw")) {
options->output_format = DIFF_FORMAT_PATCH;
options->with_raw = 1;
}
- else if (!strcmp(arg, "--stat"))
- options->output_format = DIFF_FORMAT_DIFFSTAT;
+ else if (!strcmp(arg, "--stat")) {
+ if (options->output_format == DIFF_FORMAT_PATCH) {
+ // -p --stat
+ options->with_stat = 1;
+ } else {
+ options->output_format = DIFF_FORMAT_DIFFSTAT;
+ }
+ }
else if (!strcmp(arg, "--check"))
options->output_format = DIFF_FORMAT_CHECKDIFF;
else if (!strcmp(arg, "--summary"))
--
1.4.0.g5fdc-dirty
^ permalink raw reply related
* Re: git pull w/o checkout?
From: Jeff King @ 2006-06-22 13:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: git
In-Reply-To: <6C519A4B-9253-49BB-BF68-DCD557DACCB7@kernel.crashing.org>
On Thu, Jun 22, 2006 at 08:20:51AM -0500, Kumar Gala wrote:
> Ahh, I see. I can than just copy the 'origin' ref over 'master'.
You can, though I'm not sure you even need to. If you're simply wanting
to mirror a git branch without checking out, then you're already done.
The mirror is just in 'origin', not 'master'.
-Peff
^ permalink raw reply
* Re: git pull w/o checkout?
From: Kumar Gala @ 2006-06-22 13:20 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060622131730.GB7168@coredump.intra.peff.net>
On Jun 22, 2006, at 8:17 AM, Jeff King wrote:
> On Thu, Jun 22, 2006 at 08:13:54AM -0500, Kumar Gala wrote:
>
>> that's what I want, however fetch isn't updating any refs/ as far as
>> I can tell.
>
> It won't update the ref for the branch you're on; it will update the
> head for the remotes (try running git-show-branch before and after
> your
> fetch, and you should see an update on 'origin' or whatever remote
> you're fetching).
Ahh, I see. I can than just copy the 'origin' ref over 'master'.
thanks
- kumar
^ permalink raw reply
* Re: [WORKAROUND] gitk lower pane scrollbar extends past gitk window
From: Jakub Narebski @ 2006-06-22 13:19 UTC (permalink / raw)
To: git
In-Reply-To: <e7di0n$7hh$1@sea.gmane.org>
It looks like gitk incorrectly saves the geometry in ~/.gitk
I have to remove it before running gitk (well, it would be
enough to remove geometry section).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git pull w/o checkout?
From: Jeff King @ 2006-06-22 13:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: git
In-Reply-To: <6F96D77C-FE27-4B74-ADBF-9964B5FD72DF@kernel.crashing.org>
On Thu, Jun 22, 2006 at 08:13:54AM -0500, Kumar Gala wrote:
> that's what I want, however fetch isn't updating any refs/ as far as
> I can tell.
It won't update the ref for the branch you're on; it will update the
head for the remotes (try running git-show-branch before and after your
fetch, and you should see an update on 'origin' or whatever remote
you're fetching).
-Peff
^ permalink raw reply
* Re: git pull w/o checkout?
From: Kumar Gala @ 2006-06-22 13:15 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060622131344.GA7168@coredump.intra.peff.net>
On Jun 22, 2006, at 8:13 AM, Jeff King wrote:
> On Thu, Jun 22, 2006 at 08:10:10AM -0500, Kumar Gala wrote:
>
>>> git-fetch?
>> Its the first half, still need to resolve FETCH_HEAD, HEAD, etc..
>
> Can you elaborate on what you're trying to accomplish?
A local mirror of a git tree. I can do the clone easy enough, its
trying to figure out the updates after the fact that is the issue.
- k
^ permalink raw reply
* Re: git pull w/o checkout?
From: Kumar Gala @ 2006-06-22 13:13 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: git
In-Reply-To: <20060622131129.GB5134@spinlock.ch>
On Jun 22, 2006, at 8:11 AM, Matthias Kestenholz wrote:
> * Kumar Gala (galak@kernel.crashing.org) wrote:
>> I trying to see if there is a way to get the effect of a git-pull w/o
>> getting the checked out files.
>>
>> Any ideas?
>
> Do you want to fetch remote changes without merging them into your
> working tree? If you, "git fetch" is your friend.
that's what I want, however fetch isn't updating any refs/ as far as
I can tell.
> By the way, pull does the equivalent of a fetch and a subsequent
> merge.
right, its the merge that seems to be doing the checkout.
- k
^ permalink raw reply
* Re: git pull w/o checkout?
From: Jeff King @ 2006-06-22 13:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: git
In-Reply-To: <E333ADD9-1096-4137-9D72-D58A8E2A5582@kernel.crashing.org>
On Thu, Jun 22, 2006 at 08:10:10AM -0500, Kumar Gala wrote:
> >git-fetch?
> Its the first half, still need to resolve FETCH_HEAD, HEAD, etc..
Can you elaborate on what you're trying to accomplish?
-Peff
^ permalink raw reply
* Re: [PATCH] Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.
From: Petr Baudis @ 2006-06-22 13:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yakov Lerner, git
In-Reply-To: <7vwtb9veqv.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Jun 22, 2006 at 09:19:52AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> For that matter, I do not think tracking prefix_SQ makes much
> sense since what matters are bindir, gitexecdir and template_dir
> which are already covered, and prefix is merely a convenience to
> set these three (four, counting GIT_PYTHON_DIR; we probably
> should add it to TRACK_CFLAGS).
$(prefix) will be passed to perl/Makefile.PL.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: git pull w/o checkout?
From: Matthias Kestenholz @ 2006-06-22 13:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: git
In-Reply-To: <E65F8DB5-677B-4C7B-A4EC-5F6FB76D6E9A@kernel.crashing.org>
* Kumar Gala (galak@kernel.crashing.org) wrote:
> I trying to see if there is a way to get the effect of a git-pull w/o
> getting the checked out files.
>
> Any ideas?
Do you want to fetch remote changes without merging them into your
working tree? If you, "git fetch" is your friend.
By the way, pull does the equivalent of a fetch and a subsequent
merge.
Matthias
^ permalink raw reply
* Re: git pull w/o checkout?
From: Kumar Gala @ 2006-06-22 13:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060622130523.GA6893@coredump.intra.peff.net>
On Jun 22, 2006, at 8:05 AM, Jeff King wrote:
> On Thu, Jun 22, 2006 at 07:51:56AM -0500, Kumar Gala wrote:
>
>> I trying to see if there is a way to get the effect of a git-pull w/o
>> getting the checked out files.
>
> git-fetch?
Its the first half, still need to resolve FETCH_HEAD, HEAD, etc..
- k
^ permalink raw reply
* Re: git pull w/o checkout?
From: Jeff King @ 2006-06-22 13:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: git
In-Reply-To: <E65F8DB5-677B-4C7B-A4EC-5F6FB76D6E9A@kernel.crashing.org>
On Thu, Jun 22, 2006 at 07:51:56AM -0500, Kumar Gala wrote:
> I trying to see if there is a way to get the effect of a git-pull w/o
> getting the checked out files.
git-fetch?
-Peff
^ permalink raw reply
* git pull w/o checkout?
From: Kumar Gala @ 2006-06-22 12:51 UTC (permalink / raw)
To: git
I trying to see if there is a way to get the effect of a git-pull w/o
getting the checked out files.
Any ideas?
thanks
- kumar
^ permalink raw reply
* Tracking CVS
From: Jon Smirl @ 2006-06-22 12:41 UTC (permalink / raw)
To: git
I'm tracking cvs using this sequence.
cvs update
cg rm -a
cg commit
cg add -r .
cg commit
Is there a way to avoid the two commits? If you do the add with out
the intervening commit it just adds the files back.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Incremental CVS update
From: Jon Smirl @ 2006-06-22 12:26 UTC (permalink / raw)
To: Keith Packard, git
cvsps keeps it's incremental status in ~/.cvps/*. parsecvs might want
to keep it's status in the .git repository and use tags to locate it.
You could even have a utility to show when and what was imported. By
keeping everything in git it doesn't matter who runs the incremental
update commands.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] rebase --merge: fix for rebasing more than 7 commits.
From: Eric Wong @ 2006-06-22 11:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsh1tvt1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > * I wanted to raise my confidence level in the new rebase --merge
> > code, so I did a little exercise which resulted in finding this
> > buglet.
> >...
> > So the exercise went like this:
> >...
> > With this fix, the above works beautifully. I am reasonably
> > happy with this shiny new toy. Good job, Eric! and thanks.
:) Thanks for the extra QA and fix.
> By the way, I do not quite understand the reasoning behind not
> moving the head being rebased until the finalization phase.
That's because my original patch that only used git-merge, which didn't
let me manually commit with all the information from a previous commit.
> Also I think --skip would be straightforward. What you look at
> in call_merge() is the current HEAD, the commit being rebased
> and its direct parent (actually what you are interested in are
> trees of these commits and not ancestry chains among them -- if
> we can tell git-merge-recursive not to try its own "recursive"
> merge base finding but just use what we give it as the base, I
> could sleep better. I think the current code could misbehave in
> funnier ancestry graph if we allow it to pick merge base on its
> own), so skipping is just a matter of, eh, skipping the commit.
Another consequence of relying on plain git-merge in my original
patch. --skip should be very doable now that we can specify
the correct base. I'll look into it more when I'm more awake.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] gitweb: whitespace cleanup around '='
From: Junio C Hamano @ 2006-06-22 10:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e7doc6$sg7$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> I remember discussing things with Timo and was putting it on
>> hold since I knew you were also actively futzing on gitweb.
>
> So when I apply someone else patches should I reply to the post
> with patch I have applied with
>
> Acked-by: Jakub Narebski <jnareb@gmial.com>
>
> to notify of that fact?
Acked-by does not mean you've applied it to your tree, and even
if it did, it is unfair to expect me to remember that fact when
I review your patch later. In this particular case, a note in
the patch to say it depends on such and such that _I_ do not
seem to have yet would have been more appropriate.
Acked-by would also be helpful when a de-facto owner of the code
wants to push acceptance of others' patches, but that is
independent from stating what a patch's prerequisites are.
Anyhow, I've reviewed Timo's patch (which made sense to me too),
and your whitespace fixes and pushed out the result, which
hopefully will be propagating to the mirrors soon. Overall, I
would say that the clean-up on gitweb so far is reasonably
straightforward. I have been running "next" version of gitweb
on my private machine and haven't found regression.
I'll go to bed now. Thanks for the patches.
^ permalink raw reply
* Re: [PATCH] gitweb: whitespace cleanup around '='
From: Santi Béjar @ 2006-06-22 10:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e7dp9m$v48$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> I'm very sorry, I forgot that I applied Timo Hirvonen patch
>>>
>>> "[PATCH] gitweb: Start search from HEAD"
>>> Message-ID: <20060620152515.23e59396.tihirvon@gmail.com>
>>
>> But I think what you have is this one instead:
>>
>> Message-ID: <20060620164105.7276a45f.tihirvon@gmail.com>
>
> Is the 'note' extension to commit header implemented yet? It it is,then it
> would be nice if git-am recorded original email message-ids in the note
> header. Usually it is of no interest to user, so it should be hidden by
> default.
I put it at the end of the commit message, like the Signed-of-by
lines. And, yes, it would be nice if git-am would add it (--message-id
flag?). If more people is interested I'll try to send a patch.
Santi
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Dennis Stosberg @ 2006-06-22 10:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e7bhlf$5j2$1@sea.gmane.org>
Jakub Narebski wrote:
> So now you have extra git redirector being spawned, instead of extra shell
> being spawned.
Most of the commands that Gitweb uses are built-ins, so there
shouldn't be any extra overhead by calling "git command" instead of
"git-command". If I haven't missed one, git-annotate is the only one
which is not a built-in.
Regards,
Dennis
^ permalink raw reply
* Re: [PATCH] gitweb: whitespace cleanup around '='
From: Jakub Narebski @ 2006-06-22 9:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vodwlsfek.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> I'm very sorry, I forgot that I applied Timo Hirvonen patch
>>
>> "[PATCH] gitweb: Start search from HEAD"
>> Message-ID: <20060620152515.23e59396.tihirvon@gmail.com>
>
> But I think what you have is this one instead:
>
> Message-ID: <20060620164105.7276a45f.tihirvon@gmail.com>
Is the 'note' extension to commit header implemented yet? It it is,then it
would be nice if git-am recorded original email message-ids in the note
header. Usually it is of no interest to user, so it should be hidden by
default.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: whitespace cleanup around '='
From: Jakub Narebski @ 2006-06-22 9:37 UTC (permalink / raw)
To: git
In-Reply-To: <7vodwlsfek.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I remember discussing things with Timo and was putting it on
> hold since I knew you were also actively futzing on gitweb.
So when I apply someone else patches should I reply to the post
with patch I have applied with
Acked-by: Jakub Narebski <jnareb@gmial.com>
to notify of that fact?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: whitespace cleanup around '='
From: Junio C Hamano @ 2006-06-22 9:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e7dh1c$61n$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> I thought we were both reasonably sure that we are now in
>> sync... I could apply it by hand but once I start doing that
>> I'm afraid we will never converge.
>>
>> It's quite frustrating.
>
> I'm very sorry, I forgot that I applied Timo Hirvonen patch
>
> "[PATCH] gitweb: Start search from HEAD"
> (<20060620152515.23e59396.tihirvon@gmail.com>)
> http://permalink.gmane.org/gmane.comp.version-control.git/22197>
>
> on top of 'next'.
I remember discussing things with Timo and was putting it on
hold since I knew you were also actively futzing on gitweb.
But I think what you have is this one instead:
Message-ID: <20060620164105.7276a45f.tihirvon@gmail.com>
I applied it in jn/gitweb topic and then applied your whitespace
fixes on top of the result, after discarding the whitespace
cleanup I sent out earlier. So let's make sure we are resync'ed
and continue from here. I'll push out the updated "next"
soonish.
^ 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