* 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
* 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
* 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
* 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: 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: [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: 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: 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: 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: 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: [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: 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: 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
* [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: 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
* 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: 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
* Added macro support to qgit
From: Marco Costalba @ 2006-06-22 14:04 UTC (permalink / raw)
To: git; +Cc: proski
I have pushed some patches that add macros to qgit.
>From menu bar it is possible to run a macro created by a fancy new
dialog invoked by 'Macros->Setup macros...' menu.
See http://digilander.libero.it/mcostalba/macros_menu.png
http://digilander.libero.it/mcostalba/macros_dialog.png
A macro can be associated to a any sequence of commands or to an
external script.
In case of commands sequence, these will be wrapped up in a temporary
script and executed as a whole.
A macro can also ask for command line arguments before to be run so to
allow for maximum flexibility. In case of multi commands sequence
given command line arguments will be bounded to first one only.
While a macro is running a terminal window is shown to display the
corresponding output.
qgit repository is: git://git.kernel.org/pub/scm/qgit/qgit.git
Comments and feedback are welcomed.
Marco
^ permalink raw reply
* Re: Tracking CVS
From: Jon Smirl @ 2006-06-22 14:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060622135831.GB21864@pasky.or.cz>
On 6/22/06, Petr Baudis <pasky@suse.cz> wrote:
> 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...
How about a cg-sync? Tracking cvs (or other SCM) with git is probably
a common activitiy while you try to convince the other CVS users to
switch. It is probably worth a little write up in the readme on the
best way to do it.
cg-sync should probably default to having a prompt before actually
adding/removing the files. Add a -f or something to get rid of the
prompt.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Ryan Anderson @ 2006-06-22 14:47 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: Jakub Narebski, git
In-Reply-To: <20060622100024.G7f491d4a@leonov.stosberg.net>
On Thu, Jun 22, 2006 at 12:00:25PM +0200, Dennis Stosberg wrote:
> 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.
git-annotate is a Perl script anyway, so it's not unreasonable to
consider making it a .pm module and just using it directly in gitweb.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* gitweb refactoring
From: Jakub Narebski @ 2006-06-22 15:30 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> > Jakub Narebski wrote:
>>
>>> * Refactor generation of navigation bar. There are at least two
>>> implementations of that. With hash dispatch it would be easy to
>>> list all possibilities.
>>
>> Actually I think that whole gitweb.cgi needs refactoring, badly.
>> Generation of navigation bar is only one, admittedly worst,
>> example of code duplication.
>
> Yes. I liked what xmms2 folks did to the navbar exactly for
> that reason. We would be better off to first clean up what we
> currently have before starting to build too much on it.
So lets talk about gitweb refactoring.
Currently gitweb subroutines can be divided into following categories:
1. "Action" subroutines, which do all the work, i.e. they output whole
contents of the page. Currently they are named git_$action, e.g.
git_summary(), git_log(), git_blob(), git_heads(),... , git_blame().
The list includes "hidden" actions, namely git_logo(), git_opml(), and
git_project_list(). There is nothing 'git' about those subroutines.
How should they be named? What prefix to use? action_summary(),
write_summary(), output_summary(), out_summary(), gitweb_summary()?
2. Miscelanous "HTML" subroutines, outputting fragments of HTML code, like
git_header_html, git_footer_html and die_error; or returning fragment of
HTML code, like format_log_line_html. Refactoring should put all the work
into such subroutines.
3. Many helper subroutines:
- related o HTML or HTTP: esc_param, esc_html, mimetype_guess_file,
mimetype_guess, git_blob_plain_mimetype, age_class
- mangling git output: unquote, age_class, age_string, mode_str, file_type
- other helper subroutines: chop_str, date_str, get_file_owner,
validate_input
4. Subroutines which invoke git commands, usually using "-|" LIST magic
output call: git_get_type($hash), git_get_project_config($key) and
git_get_project_config_bool($key), git_get_hash_by_path($base, $path).
Including git_read_tag($hash) and git_read_commit($hash) which fills
%tag/%co object with information from parsing tag/commit.
Unusual in this set git_read_head($project) which sets $ENV{GIT_DIR}
temporarily and git_diff_print($from_id, $from_name, $to_id, $to_name,
$format = "html") which does the work for blobdiff and blobdiff_plain using
temporary files (new git probably can do this without need for temporaru
files)
5. Subroutines which directly access git repository, sometimes calling
subroutines mentioned above, including: git_read_hash (which needs
refactoring itself I think), git_read_description, git_read_projects,
read_info_ref, git_read_refs (instead of using git-branch or git-tag -l,
which also parses information into %ref_item hash).
6* Listed in the sets above are suroutines which parse info into hash or
array of hashes/hashrefs: git_read_tag, git_read_commit, git_read_refs.
Other multi-line output like 'ls-tree' output is parsed and output line by
line.
Some of those subroutines probably will find the way to Git.pm. But in all
they need to be cleanly separated into classed if possible, and reworked to
do one thing and do it well. Passing parameters instead of relying on
global variables would help porting to mod_perl, for example.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 4/4] upload-pack/fetch-pack: support side-band communication
From: Jon Loeliger @ 2006-06-22 16:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vpsh2xcv1.fsf@assigned-by-dhcp.cox.net>
On Wed, 2006-06-21 at 19:17, Junio C Hamano wrote:
> > Somehow this does not work when connecting to git daemon that
> > runs under inetd. Fixes appreciated.
>
> This seems to fix it.
> - fclose(stderr); //FIXME: workaround
> + freopen("/dev/null", "w", stderr);
>
Sweet. Thanks!
jdl
^ permalink raw reply
* Re: Tracking CVS
From: Junio C Hamano @ 2006-06-22 17:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060622135831.GB21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> 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 --
If you want to avoid "xargs -0", you can replace it with
"git-update-index -z --stdin" I think.
> Perhaps we might make a special command which would sync the index set
> with the working copy set...
I think that makes sense. Something like what "git-commit -a"
does before making a commit.
^ permalink raw reply
* Re: [PATCH] Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.
From: Junio C Hamano @ 2006-06-22 17:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060622131235.GA21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> 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.
Then probably it shouldn't; instead we woulld probably want to
pass the moral equivalent of GIT_PYTHON_DIR.
^ permalink raw reply
* Re: Tracking CVS
From: Jakub Narebski @ 2006-06-22 17:14 UTC (permalink / raw)
To: git
In-Reply-To: <7vveqtp1dl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>> Perhaps we might make a special command which would sync the index set
>> with the working copy set...
>
> I think that makes sense. Something like what "git-commit -a"
> does before making a commit.
Isn't that what "git update-index --again" does?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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