* Re: Cygwin error?
From: Andreas Ericsson @ 2008-11-20 8:57 UTC (permalink / raw)
To: nadim khemir; +Cc: git
In-Reply-To: <200811191857.30793.nadim@khemir.net>
nadim khemir wrote:
> Hi, Given:
>
> $ git pull
> remote: Counting objects: 46, done.
> ...
> Updating b80286d..a543dae
> error: Untracked working tree file 'xxx.txt' would be overwritten by merge.
>
>
> This is due to a rename of xxx.txt to Xxx.txt. I understand that this is due
> to files being just case preserving on Cycwin/Win32.
>
> The only I found was to remove the xxx.txt localy and do a pull. The
> interresting thing is that Xxx.txt is no present in my file system. I can
> check it out from HEAD though.
>
> What did I missunderstood and do wrong?
>
You ran into a corner-case. Git expects the "Xxx.txt" and "xxx.txt" to be
different. Cross-OS projects should never, ever rename files so that they
end up with case ambiguity. Since they did, the only thing you can really
do is this:
git fetch
rm xxx.txt
git reset --hard origin/master; # or whatever branch you're interested in
I'm afraid you'll have problems with this until all the branches you're
interested in have this change.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git workshop in Sweden/Denmark
From: Andreas Ericsson @ 2008-11-20 8:53 UTC (permalink / raw)
To: nadim khemir; +Cc: git
In-Reply-To: <200811191858.21990.nadim@khemir.net>
nadim khemir wrote:
> Hi,
>
> Lund.pm and Data-foreningen are trying to organize a 'git' workshop.
>
> The workshop will consist of a presentation in the morning followed by a lunch
> in a local restaurant and a workshop after lunch.
>
Sweet! :)
> We already have a location where the workshop will take place. Most probably
> a Saturday to allow as many people as possible to join us. The location is in
> Malmö the biggest town in the south of Sweden and only 30mn by train from
> Copenhagen capital of Danmark. We, of course, welcome people from other places
> too.
>
> We are already working on securing one or two speakers that will enlighten us.
>
> I would like the git community to help us with:
>
> - has a git workshop already been organized?
> is there material that we could get?
> any conference organization existing (something like YAPC)?
>
> - what's the interrest? I'm sure I can get 30 ppl to join but if there is
> interrest we can organize something bigger.
>
I'll be there if I can.
> - Can you be :
> - a speaker
> - a sponsor
>
I've been speaking enough on oss conferences this year and feel I don't
have time to spend on making slides and preparing for another conference,
but I'd love to attend and can almost certainly help out on the workshop
if needed.
> - If you come, what would you like to learn, discuss?
>
I'm primarily interested in finding developers that want to integrate git
with other applications, such as IDE's. I need to know what they would
need from a git library so I can properly prioritize the different todos
for libgit2.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git bisect do not work when good reversion is newer than bad reversion
From: Andreas Ericsson @ 2008-11-20 8:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Cai, Crane, git
In-Reply-To: <7vljvfswek.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> "Cai, Crane" <Crane.Cai@amd.com> writes:
>
>> Hi Junio,
>>
>> Sorry to disturb you. Here the requirement I met can not find answer
>> from website. That's why I directly ask you.
>>
>> I need to use "git bisect" to find what patch can fix a problem.
>> I found v2.6.25 has this problem.
>> And v2.6.26 does NOT has this problem.
>>
>> Then I use bisect as this:
>>
>> #git bisect start
>> #git bisect good v2.6.26
>> #git bisect bad v2.6.25
>>
>> No reversion cut via these steps. Do you know whether git command can
>> achieve this requirement or not?
>
> You can use "git bisect" to find a single change that fixed the issue
> (_provided if_ such a single change exists). There is a small mental
> trick you need to exercise.
>
> First, realize that bisect is about "it used to be like this, but later it
> turned into that. Where did that single transition from this to that
> happened"? Usually, "this" is "had this particular bug and was broken"
> and "that" is "that bug was fixed and things work smoothly". In your
> case, however, "this" is "broken" and "that" is "fixed". IOW, the
> question you ask "bisect" is "it used to be broken but later it was fixed;
> where did that exactly happen?".
>
> The mental trick is to swap "good" and "bad" in order to adjust to your
> use, because you are using bisect in a reverse way from the usual. Usual
> case uses "good" mark "this" while "bad" is used to mark "that" in the
> sentence "it used to be like this, but later it turned into that".
>
> So what you would do is...
>
> (1) First of all, write on a piece of paper:
>
> good - the version _STILL_ has the bug.
> bad - the version does not have the bug _ANYMORE_
>
> (2) Start with "git bisect v2.6.25 v2.6.26";
>
> (3) As you test each revision, look at the memo you made. Say
> "good" if it still has the bug you are interested in; say
> "bad" if it does not have the bug anymore..
>
> cf. http://thread.gmane.org/gmane.comp.version-control.git/86063
>
Or start your bisect run with this:
git config alias.fixed "!git bisect bad"
git config alias.buggy "!git bisect good"
Then you can run "git fixed" if the bug is fixed, and "git buggy" if the
bug is present.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git and mtime
From: Andreas Ericsson @ 2008-11-20 8:39 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Arafangion, Roger Leigh, git
In-Reply-To: <vpqhc63zrz2.fsf@bauges.imag.fr>
Matthieu Moy wrote:
> Arafangion <thestar@fussycoder.id.au> writes:
>
>> You should probably fix your build script,
>
> ccache should help:
>
> http://ccache.samba.org/
>
Not for docbook/flex/yacc stuff, which is what was causing trouble.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git and mtime
From: Andreas Ericsson @ 2008-11-20 8:38 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: Roger Leigh, git
In-Reply-To: <C33ABF98-2E52-4928-BF79-CB3B6A8460DB@feinheit.ch>
Matthias Kestenholz wrote:
> Hi,
>
> On 19.11.2008, at 12:37, Roger Leigh wrote:
>
>> Hi folks,
>>
>> I'm using git to store some generated files, as well as their sources.
>> (This is in the context of Debian package development, where entire
>> upstream release tarballs are injected into an upstream branch, with
>> Debian releases merging the upstream branch, and adding the Debian
>> packaging files.)
>>
>> The upstream release tarballs contains files such as
>> - yacc/lex code, and the corresponding generated sources
>> - Docbook/XML code, and corresponding HTML/PDF documentation
>>
>> These are provided by upstream so that end users don't need these tools
>> installed (particularly docbook, since the toolchain is so flaky on
>> different systems). However, the fact that git isn't storing the
>> mtime of the files confuses make, so it then tries to regenerate these
>> (already up-to-date) files, and fails in the process since the tools
>> aren't available.
>>
>> Would it be possible for git to store the mtime of files in the tree?
>>
>
> This subject comes up from time to time, but the answer always
> stays the same: No. The trees are purely defined by their content, and
> that's by design.
>
> If you do not want to regenerate files that are already up-to-date,
> you need multiple checkouts of the same repository.
>
Or a make-rule that touches the files you know are up to date. Since you
control the build environment, that's probably the simplest solution.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Git.pm
From: Petr Baudis @ 2008-11-20 8:34 UTC (permalink / raw)
To: nadim khemir; +Cc: git
In-Reply-To: <200811191856.44252.nadim@khemir.net>
Hi,
On Wed, Nov 19, 2008 at 06:56:44PM +0100, nadim khemir wrote:
> Hi, I'm new on this mailing list and quite new to git too. I named on irc that
> I develop mainly in Perl (http://search.cpan.org/~nkh/) when I do open
> source. I heard that Git.pm needed some love and I can take over its
> maintenance if there are things that need to be done.
>
> I need to know:
>
> - what needs to be done
> - who was doing maintenanace before
> - how do you want to release it (perl modules are best placed on CPAN
> (too))
> - what (and who) is depending on Git.pm
> - what would be expected of me
I know it's quite some time since you wrote this mail originally -
have you read the Lea's thread I have recommended? What is your current
plan?
I think the current rough consensus in the Git community is to go with
Lea's design and implementation after extending it with a nice way to
run arbitrary Git commands. This is also desirable since then we can use
her patches to make gitweb use Git.pm.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* git-svn confused by "empty" (svn prop change) commit
From: paulfred @ 2008-11-20 3:11 UTC (permalink / raw)
To: git
I've been using git and git-svn to commit to a central SVN repository for
the last several months. It's been working great so far, well enough that
I really, *really* don't want to go back.
But yesterday, someone committed a number of changes to svn:properties,
and there were no tree changes. git-svn now fails to dcommit anything,
instead giving me the following output:
$ git svn dcommit
Committing to https://project.com/svn/trunk ...
No changes
68af7eb26504e324cd6e3a2d50cd0562852a2dca~1 == 68af7eb26504e324cd6e3a2d50cd0562852a2dca
W: 68af7eb26504e324cd6e3a2d50cd0562852a2dca and refs/remotes/trunk differ, using rebase:
:040000 040000 7d76021c10cebf4a0b5c8fdf614bec8e66734a28 197442c7bd8c29cdd11f52ffb18fbd882d1c7f50 M eu
Current branch master is up to date.
# of revisions changed
before:
683a4ed53d8859f184733eaeebc6fcb904aa1e3b
10e85dc1c3b03b77dcabb53b26893b2d30bd56c5
07c1f476b6a5feae410e315cae57d878e898896d
27aad097ace7ec5db128032f29d775791463ddc7
[...several commits omitted...]
751e53e536c98bf9ee1bd8b876c56f06f6b6b059
after:
68af7eb26504e324cd6e3a2d50cd0562852a2dca
683a4ed53d8859f184733eaeebc6fcb904aa1e3b
10e85dc1c3b03b77dcabb53b26893b2d30bd56c5
07c1f476b6a5feae410e315cae57d878e898896d
27aad097ace7ec5db128032f29d775791463ddc7
[...all the same commits again omitted...]
751e53e536c98bf9ee1bd8b876c56f06f6b6b059
If you are attempting to commit merges, try running:
git rebase --interactive --preserve-merges refs/remotes/trunk
Before dcommitting
It's strange that it wanted to rebase, since I had already rebased on top of
remotes/trunk, and I have exactly one commit I'm trying to dcommit. After
rebasing, it appears to bail because 68af7e is in one list and not the other.
Well, 68af7e happens to be the commit with no tree changes, only svn property
changes. And yet "git branch --contains 68af7e" output includes master. (hmm,
but not remotes/trunk. Shouldn't it? master^ == remotes/trunk)
Anyway, git svn rebase continues to pull in new changes from everyone else,
but won't dcommit mine.
Based on a suggestion from irc, I tried --no-rebase, and got:
Attempting to commit more than one change while --no-rebase is enabled.
If these changes depend on each other, re-running without --no-rebase may be required. at /usr/local/libexec/git-core/git-svn line 447.
No changes
68af7eb26504e324cd6e3a2d50cd0562852a2dca~1 == 68af7eb26504e324cd6e3a2d50cd0562852a2dca
Unable to extract revision information from commit 683a4ed53d8859f184733eaeebc6fcb904aa1e3b~1
But I don't know what to do with that error message. Is it looking for the git-svn-id's?
Other (perhaps important) details: I created the repository several months
ago,and only recently put "[svn] noMetadata = true" in my config file because
I'm the only person on the team using git, and nobody else wanted to see the
git-svn-id messages.
This is git version 1.6.0.4.761.g47577 on OS X 10.5.
I suppose I could nuke everything and clone another shallow copy of the code
from some point after the bad commit, but I'd be happy with any kind of
work around that gets me dcommitting again.
Thanks!
--Paul
^ permalink raw reply
* [PATCH] Fix misleading wording for git-cherry-pick
From: Bryan Drewery @ 2008-11-20 5:11 UTC (permalink / raw)
To: gitster; +Cc: git
Documentation for -n implies that -x is normally
used, however this is no longer true.
Signed-off-by: Bryan Drewery <bryan@shatow.net>
---
Documentation/git-cherry-pick.txt | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index 837fb08..b764130 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -55,13 +55,12 @@ OPTIONS
-n::
--no-commit::
- Usually the command automatically creates a commit with
- a commit log message stating which commit was
- cherry-picked. This flag applies the change necessary
- to cherry-pick the named commit to your working tree
- and the index, but does not make the commit. In addition,
- when this option is used, your index does not have to match
- the HEAD commit. The cherry-pick is done against the
+ Usually the command automatically creates a commit.
+ This flag applies the change necessary to cherry-pick
+ the named commit to your working tree and the index,
+ but does not make the commit. In addition, when this
+ option is used, your index does not have to match the
+ HEAD commit. The cherry-pick is done against the
beginning state of your index.
+
This is useful when cherry-picking more than one commits'
--
1.5.6.4
^ permalink raw reply related
* Re: Git commit won't add an untracked file given on the command line
From: Miles Bader @ 2008-11-20 5:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mark Burton, Francis Galiegue, git
In-Reply-To: <alpine.DEB.1.00.0811191036340.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I use the staging area a lot, so I think I have a pretty clear idea of
>> what it's "about", but I also often use "commit FILE" or "commit -a" for
>> simple cases; even when splitting a change into multiple commits, it's
>> often more convenient to do "commit FILE..." instead of "add FILE;
>> commit".
>
> What I meant was this: the "commit <file>" paradigm is not what you should
> do most of the time. In order to work with the staging area efficiently,
> you should make staging and committing two separate steps.
>
> So my point is this: stage first, verify, then commit. That saves you a
> lot of embarrassment.
You seem to be saying that you think that using staging area explicitly
is necessary or somehow "more efficient" for making good commits, but on
the face of it, that's simply not true.
I'm extremely careful about committing clean changes, and do a lot of
testing and pre-commit diffing. For complex changes which need to be
split, the staging area is indeed a very useful tool, and I'm very glad
git has it -- but it's hardly necessary for _all_ commits, and my
experience is that in practice, many commits are indeed the simple sort
which for which it's superfluous. My goal is not to "work with the
staging area efficiently", it's to "make good/clean/tested commits,
efficiently".
Obviously this depends on work style, and subject matter. Sometimes one
_needs_ to make biggish changes and split them for commiting, and some
people like to use that work style even when it's not strictly
necessary. Other times, changes are more obviously independent, and can
be done, tested, and commited in a serial fashion without any splitting.
Perhaps, given your work style or the type of work you, you use the
staging area 99% of the time. For your case, maybe any git features
which bypass the staging area are simply unneeded complexity. However,
my own experience suggests that this is not universally true. I'd say I
use the staging area for maybe 50% of commits.
One of the nice thing about git is the way that it tries to cater to
multiple work styles, so it seems wrong to reject a useful feature
simply because you want to "encourage" people to use your preferred work
style, when that work style is not obviously better. [Of course there
can be other good reasons to reject this feature -- maybe it's too
dangerous or mucks up the code.]
> I regularly encounter people who never call "git diff --cached" before
> committing, and guess who introduces all kinds of debug statements and
> other cruft into their commits? Exactly.
[I'm not sure what the point of that was... for the record, no I'm not
one of "those people". When I use the staging area, I use "git diff
--cached"; when I don't use the staging area, I "git diff" instead...]
-Miles
--
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.
^ permalink raw reply
* git-status for submodules
From: Chris Frey @ 2008-11-20 3:36 UTC (permalink / raw)
To: git
Hi,
I'm using git 1.6.0.4 and trying to make submodules work for me. The
init/add/update steps are a bit tedious, but workable. The problem I have
is when I make a change in a submodule, then git-status does not show
the change.
For example, assuming a directory structure like: super and super/sub
cd super
vi newsuper
vi existing_file
cd sub
vi newsub
cd ..
git status
This will show newsuper as needing to be added, and existing_file as changed,
but newsub will not appear.
Is there a way to accomplish this?
Thanks,
- Chris
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: Junio C Hamano @ 2008-11-20 0:36 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, Mark Burton, git
In-Reply-To: <alpine.LNX.1.00.0811191809430.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> There are two possible limits that would preserve your case while handling
> Mark's case: one is to only look at untracked files at all for names that
> don't match any tracked files, and the other (independantly) is to treat
> names as single filenames instead of patterns for untracked files.
>
> Either of these (or both) should keep the existing behavior for using a
> pattern on the command line as a filter for which of the tracked files to
> commit (since any pattern of tracked files won't be the name of an
> individual untracked file).
Perhaps. I am starting to think that "Did you forget to 'git add'?" is
actually the best behaviour we can have ;-)
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: Daniel Barkalow @ 2008-11-19 23:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Mark Burton, git
In-Reply-To: <7v7i6zs4ay.fsf@gitster.siamese.dyndns.org>
On Wed, 19 Nov 2008, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > I don't think that's what Mark wants, in this case. He's looking for the
> > ability to have "git commit" act on a temporary index created by adding to
> > the parent commit explicitly named files which aren't in the non-temporary
> > index.
>
> Ah, I think that it would not be an entirely unreasonable thing to do
> (cf. Message-Id: <7vtza4trdp.fsf@gitster.siamese.dyndns.org>).
>
> You can say "git add that/directory" and .gitignore mechanism protects you
> from crufts in that/directory, so fearing "git commit that/directory" to
> add random junk to the next commit is not a reason to fear it.
>
> But that is a huge behaviour change. For example, I have a handful test
> scripts in my t/ directory (all named following the usual t????-*.sh
> naming convention) that I do not want to commit. Today, after making
> changes to the tracked test scripts, I can rely on "git commit t/" not to
> include them in the commit, and I've _learned_ to trust that behaviour.
> I'd be surprised if others who have used git for more than a few months
> haven't done so as well.
>
> Allowing what Mark wants without any explicit user customization will be a
> disaster to the end user experience.
There are two possible limits that would preserve your case while handling
Mark's case: one is to only look at untracked files at all for names that
don't match any tracked files, and the other (independantly) is to treat
names as single filenames instead of patterns for untracked files.
Either of these (or both) should keep the existing behavior for using a
pattern on the command line as a filter for which of the tracked files to
commit (since any pattern of tracked files won't be the name of an
individual untracked file).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: Junio C Hamano @ 2008-11-19 23:51 UTC (permalink / raw)
To: Mark Burton; +Cc: Daniel Barkalow, Johannes Schindelin, git
In-Reply-To: <20081119233027.17687dd5@crow>
Mark Burton <markb@ordern.com> writes:
>> Allowing what Mark wants without any explicit user customization will be a
>> disaster to the end user experience.
>
> If the ability to commit a currently untracked file/tree whilst
> preserving the index is really worth having (and that's debatable, as
> the git user community has survived until now without that capability)
> then another option (say, -O) could be added to git-commit that does
> what -o does but allows untracked files/trees to be specified - that
> way, the current behaviour would remain unchanged and the above
> mentioned disaster averted.
Heh, I apparently failed to convey what I wanted to say with "without any
explicit user customization" part of my message. IOW, I think you are
saying the same thing as what I wanted to say from the opposite angle.
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: Mark Burton @ 2008-11-19 23:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Johannes Schindelin, git
In-Reply-To: <7v7i6zs4ay.fsf@gitster.siamese.dyndns.org>
Hi,
> Allowing what Mark wants without any explicit user customization will be a
> disaster to the end user experience.
If the ability to commit a currently untracked file/tree whilst
preserving the index is really worth having (and that's debatable, as
the git user community has survived until now without that capability)
then another option (say, -O) could be added to git-commit that does
what -o does but allows untracked files/trees to be specified - that
way, the current behaviour would remain unchanged and the above
mentioned disaster averted.
Cheers,
Mark
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: Junio C Hamano @ 2008-11-19 23:07 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, Mark Burton, git
In-Reply-To: <alpine.LNX.1.00.0811191247560.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I don't think that's what Mark wants, in this case. He's looking for the
> ability to have "git commit" act on a temporary index created by adding to
> the parent commit explicitly named files which aren't in the non-temporary
> index.
Ah, I think that it would not be an entirely unreasonable thing to do
(cf. Message-Id: <7vtza4trdp.fsf@gitster.siamese.dyndns.org>).
You can say "git add that/directory" and .gitignore mechanism protects you
from crufts in that/directory, so fearing "git commit that/directory" to
add random junk to the next commit is not a reason to fear it.
But that is a huge behaviour change. For example, I have a handful test
scripts in my t/ directory (all named following the usual t????-*.sh
naming convention) that I do not want to commit. Today, after making
changes to the tracked test scripts, I can rely on "git commit t/" not to
include them in the commit, and I've _learned_ to trust that behaviour.
I'd be surprised if others who have used git for more than a few months
haven't done so as well.
Allowing what Mark wants without any explicit user customization will be a
disaster to the end user experience.
^ permalink raw reply
* Re: [PATCH] Retain multiple -q/-v occurrences in git pull
From: Tuncer Ayaz @ 2008-11-19 23:00 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: Junio C Hamano, git
In-Reply-To: <4ac8254d0811191458r2a205be3w4a412553edc9b07f@mail.gmail.com>
[re-sent due to propagated wrong Junio address. sorry.]
On Wed, Nov 19, 2008 at 12:46 PM, Constantine Plotnikov
<constantine.plotnikov@gmail.com> wrote:
> On Tue, Nov 18, 2008 at 1:09 AM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
>> To support counting -q/-v options in git pull retain
>> them by concatenating.
>>
> [rest of message cut]
>
> By the way, there is yet another way to invoke git fetch. It is "git
> remote update". Possibly it should support "-v" and "-q" options for
> consistency as well.
Yes, we could add -q to builtin-remote and also make sure that it
passes the already existing -v and maybe a yet-to-be-added -q to
the fetch command.
I want to be first sure what the overall strategy regarding -q/-v is.
Right now we have some code which uses OPT__VERBOSE/OPT__QUIET
and some new code which uses the newly-added OPT__VERBOSITY.
These are the options I can see:
1) Use the old and new macros and decide in each module which one to use
2) Get rid off OPT__VERBOSE and OPT__QUIET and use OPT__VERBOSITY only
3) Think about new ways to handle all of this. Possibly some new print_* macros?
Any opinions?
^ permalink raw reply
* Re: [PATCH] Retain multiple -q/-v occurrences in git pull
From: Tuncer Ayaz @ 2008-11-19 22:47 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git, gitster
In-Reply-To: <85647ef50811190346x11aea0fay3a8a7dfd8ddf6abc@mail.gmail.com>
On Wed, Nov 19, 2008 at 12:46 PM, Constantine Plotnikov
<constantine.plotnikov@gmail.com> wrote:
> On Tue, Nov 18, 2008 at 1:09 AM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
>> To support counting -q/-v options in git pull retain
>> them by concatenating.
>>
> [rest of message cut]
>
> By the way, there is yet another way to invoke git fetch. It is "git
> remote update". Possibly it should support "-v" and "-q" options for
> consistency as well.
Yes, we could add -q to builtin-remote and also make sure that it
passes the already existing -v and maybe a yet-to-be-added -q to
the fetch command.
I want to be first sure what the overall strategy regarding -q/-v is.
Right now we have some code which uses OPT__VERBOSE/OPT__QUIET
and some new code which uses the newly-added OPT__VERBOSITY.
These are the options I can see:
1) Use the old and new macros and decide in each module which one to use
2) Get rid off OPT__VERBOSE and OPT__QUIET and use OPT__VERBOSITY only
3) Think about new ways to handle all of this. Possibly some new print_* macros?
Any opinions?
^ permalink raw reply
* Re: [git-p4] Can't submit: Something I do in a wrong way.
From: Evgeniy Ivanov @ 2008-11-19 22:16 UTC (permalink / raw)
Cc: git
In-Reply-To: <49247E5D.7070601@gmail.com>
Retried and noticed that if I do:
/dir1/1> git-p4 submit --git-dir=../../git/1/ --origin=master
Then everything works fine. Strange, but docs say:
"This requires a Perforce checkout separate to your git
repository. To submit all changes that are in the current git branch but
not in
the "p4" branch (or "origin" if "p4" doesn't exist) simply call
git-p4 submit
in your git repository."
And my approach is a bit vice versa.
Any suggestions? I can go with it, but I want almost forget about thing
that I have perforce :)
Evgeniy Ivanov wrote:
> Hi list,
> I need a help with git-p4.
>
> There are //1, //2, //3 in perforce's depot, and /dir1 is a client's root.
> So:
> Root: /dir1/
> //1/... //client/1... etc
> I've checkouted //1, //2 and //3.
>
> In /git I did "git clone //1; git clone //2", So I have /git/1, /git/2.
> Now I run in /git/1 "git-p4 submit commitBr" and choose 'y' to sync,
> where comitBr has one more commit than master.
> I get "Path /git/1/... is not under client's root /dir1/". Without
> syncing it says I have opened files, but when I do in /dir1/1 "p4 -a
> revert" I get: "file(s) not opened on this client".
> Looks like "git-p4 rebase" works fine.
>
> Also I tried to keep git in the same dir as perforce workspace: I did 1
> commit and then failed to do anything, because got strange conflicts.
>
>
> P.S. Please don't forget to keep me in CC :)
>
>
--
Cheers, Evgeniy.
Key fingerprint: F316 B5A1 F6D2 054F CD18 B74A 9540 0ABB 1FE5 67A3
^ permalink raw reply
* Re: removing svn remotes
From: Matt Graham @ 2008-11-19 21:26 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20081119083219.GB3538@atjola.homenet>
On Wed, Nov 19, 2008 at 03:32, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2008.11.18 20:47:24 -0500, Matt Graham wrote:
>> Hi,
>> I have a svn repo cloned into a git repo. There are several remote
>> refs that are there that I don't care about and don't want to fetch.
>>
>> git svn fetch --fetch-all gets a bunch of stuff from branches I don't want
>> git svn fetch requires I checkout the branches I care about before fetching
>>
>> git svn fetch doesn't accept a branch name
>> git remote rm isn't able to see the svn remotes
>>
>> Is there a way to either:
>> 1) get rid of the svn remotes that I don't want?
>> 2) fetch only the remotes that I do want?
>
> Uhm, are you talking about remote tracking branches (what "git branch
> -r" shows), or svn-remotes (not sure if git-svn can list them, they're
> in .git/config)?
>
> The behaviour you describe doesn't match my experience with git-svn, so
> maybe you could elaborate a bit on the exact problem?
Sorry the question was not clear.
git branch -r -d
did exactly what I need. I guess I just didn't know how to ask for
it. Another happy discovery.
Using git branch -r -d, I was able to delete my svn-remotes.
Now when I run git svn fetch --fetch-all, it appears to fetch only
from the remaining branches that I didn't delete. I hope that
clarifies it.
thank you!
^ permalink raw reply
* [git-p4] Can't submit: Something I do in a wrong way.
From: Evgeniy Ivanov @ 2008-11-19 21:00 UTC (permalink / raw)
To: git
Hi list,
I need a help with git-p4.
There are //1, //2, //3 in perforce's depot, and /dir1 is a client's root.
So:
Root: /dir1/
//1/... //client/1... etc
I've checkouted //1, //2 and //3.
In /git I did "git clone //1; git clone //2", So I have /git/1, /git/2.
Now I run in /git/1 "git-p4 submit commitBr" and choose 'y' to sync,
where comitBr has one more commit than master.
I get "Path /git/1/... is not under client's root /dir1/". Without
syncing it says I have opened files, but when I do in /dir1/1 "p4 -a
revert" I get: "file(s) not opened on this client".
Looks like "git-p4 rebase" works fine.
Also I tried to keep git in the same dir as perforce workspace: I did 1
commit and then failed to do anything, because got strange conflicts.
P.S. Please don't forget to keep me in CC :)
--
Cheers, Evgeniy.
Key fingerprint: F316 B5A1 F6D2 054F CD18 B74A 9540 0ABB 1FE5 67A3
^ permalink raw reply
* Recommended steps for a "subsystem maintainer" ?
From: Gary Yang @ 2008-11-19 20:47 UTC (permalink / raw)
To: git
Hi,
The doc,http://www.kernel.org/pub/software/scm/git/docs/gitcore-tutorial.html at "Working with Others" recommended steps for a "subsystem maintainer".
See below. But, I do not understand the step 3. Copy over the packed files from "project lead" public repository to your public repository.
The step 1 used git-clone. That means, I got the code including histories as well. Why do I need step 3 to get the packed files?
If I really need the packed files, how do I get it? As an example, I need to get the packed files for http://git.denx.de/?p=u-boot.git;a=summary .
How can I get the files something like, pack-d5ef1966072c86ef5108ac57525b802581de5d21.idx and pack-d5ef1966072c86ef5108ac57525b802581de5d21.pack ?
The snapshot dose not have the packed files. They are all text files.
A recommended work cycle for a "subsystem maintainer" who works on that project and has an own "public repository" goes like this:
1. Prepare your work repository, by git-clone the public repository of the "project lead". The URL used for the initial cloning
is stored in the remote.origin.url configuration variable.
2. Prepare a public repository accessible to others, just like the "project lead" person does.
3. Copy over the packed files from "project lead" public repository to your public repository, unless the "project lead" repository lives on the same machine as yours. In the latter case, you can use objects/info/alternates file to point at the repository you are borrowing from.
4. Push into the public repository from your primary repository. Run git-repack, and possibly git-prune if the transport used for pulling from your repository supports packed repositories.
5. Keep working in your primary repository. Your changes include modifications of your own, patches you receive via e-mails, and merges resulting from pulling the "public" repositories of your "project lead" and possibly your "sub-subsystem maintainers".
You can repack this private repository whenever you feel like.
6. Push your changes to your public repository, and ask your "project lead" and possibly your "sub-subsystem maintainers" to pull from it.
7. Every once in a while, git-repack the public repository. Go back to step 5. and continue working.
Thank you,
Gary
^ permalink raw reply
* Re: New converstion tool: svn2git.py
From: Neil Schemenauer @ 2008-11-19 20:40 UTC (permalink / raw)
To: Kevin Menard; +Cc: git
In-Reply-To: <7e3605160811191139t34c5de7q1912475f778386e8@mail.gmail.com>
On Wed, Nov 19, 2008 at 02:39:26PM -0500, Kevin Menard wrote:
> You may want to look at this Ruby implementation for more ideas:
>
> http://github.com/nirvdrum/svn2git/
>
Hi Kevin,
Thanks for the link. I see that git-svn does most of the heavy
lifting and now I see that it does try to intelligently handle
branches and tags by looking for a suitable parent commit. I will
have to look closer at what it's doing. Maybe it is sufficient for
my task.
Regards,
Neil
^ permalink raw reply
* Re: git workshop in Sweden/Denmark
From: Christian Couder @ 2008-11-19 20:35 UTC (permalink / raw)
To: nadim khemir; +Cc: git
In-Reply-To: <200811191858.21990.nadim@khemir.net>
Le mercredi 19 novembre 2008, nadim khemir a écrit :
> Hi,
>
> Lund.pm and Data-foreningen are trying to organize a 'git' workshop.
Nice!
> The workshop will consist of a presentation in the morning followed by a
> lunch in a local restaurant and a workshop after lunch.
>
> We already have a location where the workshop will take place. Most
> probably a Saturday to allow as many people as possible to join us. The
> location is in Malmö the biggest town in the south of Sweden and only
> 30mn by train from Copenhagen capital of Danmark. We, of course, welcome
> people from other places too.
Great, but some people may have exhausted their git available time with
GitTogether'08 (see below).
> We are already working on securing one or two speakers that will
> enlighten us.
>
> I would like the git community to help us with:
>
> - has a git workshop already been organized?
> is there material that we could get?
> any conference organization existing (something like YAPC)?
There was GitTogether'08 one month ago, see:
http://git.or.cz/gitwiki/GitTogether
Some material is available from the "Speakers" section of the page.
Other material may be available from the wiki (perhaps
http://git.or.cz/gitwiki/GitLinks).
But there is no conference organization.
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH 3/3] builtin-branch: use strbuf in rename_branch()
From: Lars Hjemli @ 2008-11-19 19:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Miklos Vajna, git
In-Reply-To: <alpine.DEB.1.00.0811190209470.30769@pacific.mpi-cbg.de>
On Wed, Nov 19, 2008 at 02:11, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 18 Nov 2008, Junio C Hamano wrote:
>
>> Miklos Vajna <vmiklos@frugalware.org> writes:
>>
>> > - snprintf(logmsg, sizeof(logmsg), "Branch: renamed %s to %s",
>> > - oldref, newref);
>> > + strbuf_addf(&logmsg, "Branch: renamed %s to %s",
>> > + oldref.buf, newref.buf);
>>
>> I am wondering why nobody has complained until now, but shouldn't this
>> be oldname and newname?
>
> I think that was the intention. Lars?
Some background: the message was first generated internally (in
c976d415) by refs.c:rename_ref() and thus it made sense to use the
full refname. Sometime later (in 678d0f4c), rename_ref() was modified
to get the message as an argument from
builtin_branch.c:rename_branch() but the format of the message was
kept (almost) identical.
Personally, I think it's nice if the reflog contains the full refname.
--
larsh
^ permalink raw reply
* Re: New converstion tool: svn2git.py
From: Kevin Menard @ 2008-11-19 19:39 UTC (permalink / raw)
To: Neil Schemenauer; +Cc: git
In-Reply-To: <20081119191320.GA20870@arctrix.com>
Hi Neil,
You may want to look at this Ruby implementation for more ideas:
http://github.com/nirvdrum/svn2git/
I forked it from a project originally by James Coglan, but should be
able to answer most questions about it.
--
Kevin
On Wed, Nov 19, 2008 at 2:13 PM, Neil Schemenauer <nas@arctrix.com> wrote:
> Hi,
>
> I'm working on a tool to do conversions from SVN to git using a SVN
> dump. It's in early development but perhaps some people would be
> interested in it:
>
> http://python.ca/nas/python/svn2git.py
>
> I would like to improve it so that it intelligently converts SVN
> branches and tags into git branches (when possible). The basic idea
> is to map SVN paths into git branches, e.g. trunk -> master,
> branches/foo -> branch-foo, tags/bar -> tags-bar. Next, specific
> SVN dump actions like:
>
> Node-path: branches/foo
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 3
> Node-copyfrom-path: trunk
>
> need to be detected and the commit needs to performed with the
> correct parent. One complication is that SVN can create a branch or
> tag from anywhere, for example, the action
>
> Node-path: tags/bar
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 3
> Node-copyfrom-path: trunk/subdir
>
> would create tags/bar based on revision 3 of trunk/subdir. There
> doesn't seem to be a good way to convert that into git. I was
> thinking that the tags-bar branch in that case would have no parent.
> Would git still efficently pack that or would you end up with extra
> blobs?
>
> Neil
> --
> 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
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