* Re: git-fetching from a big repository is slow
From: Geert Bosch @ 2006-12-14 19:05 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Schindelin, Andy Parkins, git
In-Reply-To: <4581685D.1070407@op5.se>
On Dec 14, 2006, at 10:06, Andreas Ericsson wrote:
> It wouldn't work for this particular case though. In our
> distribution repository we have ~300 bzip2 compressed tarballs with
> an average size of 3MiB. 240 of those are between 2.5 and 4 MiB, so
> they don't drastically differ, but neither do they delta well.
>
> One option would be to add some sort of config option to skip
> attempting deltas of files with a certain suffix. That way we could
> just tell it to ignore *.gz,*.tgz,*.bz2 and everything would work
> just as it does today, but a lot faster.
Such special magic based on filenames is always a bad idea. Tomorrow
somebody
comes with .zip files (oh, and of course .ZIP), then it's .jpg's other
compressed content. In the end git will be doing lots of magic and
still perform
badly on unknown compressed content.
There is a very simple way of detecting compressed files: just look
at the
size of the compressed blob and compare against the size of the
expanded blob.
If the compressed blob has a non-trivial size which is close to the
expanded
size, assume the file is not interesting as source or target for deltas.
Example:
if (compressed_size > expanded_size / 4 * 3 + 1024) {
/* don't try to deltify if blob doesn't compress well */
return ...;
}
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Shawn Pearce @ 2006-12-14 19:46 UTC (permalink / raw)
To: Geert Bosch; +Cc: Andreas Ericsson, Johannes Schindelin, Andy Parkins, git
In-Reply-To: <C287764F-6755-4291-A87A-3E8816E90B49@adacore.com>
Geert Bosch <bosch@adacore.com> wrote:
> Such special magic based on filenames is always a bad idea. Tomorrow
> somebody
> comes with .zip files (oh, and of course .ZIP), then it's .jpg's other
> compressed content. In the end git will be doing lots of magic and
> still perform
> badly on unknown compressed content.
>
> There is a very simple way of detecting compressed files: just look
> at the
> size of the compressed blob and compare against the size of the
> expanded blob.
> If the compressed blob has a non-trivial size which is close to the
> expanded
> size, assume the file is not interesting as source or target for deltas.
>
> Example:
> if (compressed_size > expanded_size / 4 * 3 + 1024) {
> /* don't try to deltify if blob doesn't compress well */
> return ...;
> }
And yet I get good delta compression on a number of ZIP formatted
files which don't get good additional zlib compression (<3%).
Doing the above would cause those packfiles to explode to about
10x their current size.
--
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-14 19:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Shawn Pearce
In-Reply-To: <Pine.LNX.4.64.0612141251520.18171@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> I'd say screw that. The solution should really be this patch:
>
> diff --git a/environment.c b/environment.c
> index 84d870c..98275b2 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -15,7 +15,7 @@ int use_legacy_headers = 1;
> int trust_executable_bit = 1;
> int assume_unchanged;
> int prefer_symlink_refs;
> -int log_all_ref_updates;
> +int log_all_ref_updates = 1;
> int warn_ambiguous_refs = 1;
> int repository_format_version;
> char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
>
That changes what the command does to existing repositories,
which is somewhat impolite.
I am not opposed too much to an updated version of the tool that
sets the configuration on by default for newly created
repositories, though.
^ permalink raw reply
* [PATCH] Enable reflogs by default in all repositories.
From: Shawn O. Pearce @ 2006-12-14 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre, Carl Worth, Andy Parkins
In-Reply-To: <Pine.LNX.4.64.0612141251520.18171@xanadu.home>
New and experienced Git users alike are finding out too late that
they forgot to enable reflogs in the current repository, and cannot
use the information stored within it to recover from an incorrectly
entered command such as `git reset --hard HEAD^^^` when they really
meant HEAD^^ (aka HEAD~2).
So enable reflogs by default in all future versions of Git, unless
the user specifically disables it with:
[core]
logAllRefUpdates = false
in their .git/config or ~/.gitconfig.
Documentation was also updated to indicate the new default behavior.
We probably should start to teach usuing the reflog to recover
from mistakes in some of the tutorial material, as new users are
likely to make a few along the way and will feel better knowing
they can recover from them quickly and easily, without fsck-objects'
lost+found features.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/config.txt | 3 ++-
environment.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a3587f8..e093bcd 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -80,7 +80,8 @@ core.logAllRefUpdates::
This information can be used to determine what commit
was the tip of a branch "2 days ago". This value is
- false by default (no automated creation of log files).
+ true by default to activate automated creation of log
+ files for all branch heads.
core.repositoryFormatVersion::
Internal variable identifying the repository format and layout
diff --git a/environment.c b/environment.c
index 84d870c..98275b2 100644
--- a/environment.c
+++ b/environment.c
@@ -15,7 +15,7 @@ int use_legacy_headers = 1;
int trust_executable_bit = 1;
int assume_unchanged;
int prefer_symlink_refs;
-int log_all_ref_updates;
+int log_all_ref_updates = 1;
int warn_ambiguous_refs = 1;
int repository_format_version;
char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
--
^ permalink raw reply related
* Re: What's in git.git (stable)
From: Shawn Pearce @ 2006-12-14 20:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vy7pa45m8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > I'd say screw that. The solution should really be this patch:
> >
> > diff --git a/environment.c b/environment.c
> > index 84d870c..98275b2 100644
> > --- a/environment.c
> > +++ b/environment.c
> > @@ -15,7 +15,7 @@ int use_legacy_headers = 1;
> > int trust_executable_bit = 1;
> > int assume_unchanged;
> > int prefer_symlink_refs;
> > -int log_all_ref_updates;
> > +int log_all_ref_updates = 1;
> > int warn_ambiguous_refs = 1;
> > int repository_format_version;
> > char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
> >
>
> That changes what the command does to existing repositories,
> which is somewhat impolite.
Yes, but users are forgetting to enable them. They will work in
a new repository having that feature, move to an older one and not
have it, but expect it to be there.
As I recall the primary objection to enabling them by default
when I first introduced them was that core.logAllRefUpdates=true
meant that refs/tags/<name> were also being logged. This was not a
great idea as tags generally did not change once they were created.
You fixed that and now it just makes sense to enable it for branch
heads all of the time.
> I am not opposed too much to an updated version of the tool that
> sets the configuration on by default for newly created
> repositories, though.
I almost did that in my patch - but decided against it for the
reason I just noted above.
Does anyone on the mailing list really have an objection to having
reflogs on by default?
About the only trouble that can cause is a failed push when
git-receive-pack needs to generate the reflog entry but cannot
get the user's committer data because their gecos information
doesn't exist.
--
^ permalink raw reply
* Re: What's in git.git (stable)
From: Nicolas Pitre @ 2006-12-14 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn Pearce
In-Reply-To: <7vy7pa45m8.fsf@assigned-by-dhcp.cox.net>
On Thu, 14 Dec 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > I'd say screw that. The solution should really be this patch:
> >
> > diff --git a/environment.c b/environment.c
> > index 84d870c..98275b2 100644
> > --- a/environment.c
> > +++ b/environment.c
> > @@ -15,7 +15,7 @@ int use_legacy_headers = 1;
> > int trust_executable_bit = 1;
> > int assume_unchanged;
> > int prefer_symlink_refs;
> > -int log_all_ref_updates;
> > +int log_all_ref_updates = 1;
> > int warn_ambiguous_refs = 1;
> > int repository_format_version;
> > char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
> >
>
> That changes what the command does to existing repositories,
> which is somewhat impolite.
You must be kidding, aren't you?
Just in case you really are serious, let's pretend that being impolite
for something that has the potential of saving people's arses is
certainly worth it, much more that the little inconvenience of having
log files mysteriously appear and make no harm otherwise.
> I am not opposed too much to an updated version of the tool that
> sets the configuration on by default for newly created
> repositories, though.
Hmmm....
Well it is just that I strongly believe users with existing repos have
no really valid reason to not have this feature enabled. But making it
on in a default config file at repo creation time is better than
nothing.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Nicolas Pitre @ 2006-12-14 20:22 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061214200245.GP1747@spearce.org>
On Thu, 14 Dec 2006, Shawn Pearce wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> > That changes what the command does to existing repositories,
> > which is somewhat impolite.
>
> Yes, but users are forgetting to enable them. They will work in
> a new repository having that feature, move to an older one and not
> have it, but expect it to be there.
I concur entirely.
> > I am not opposed too much to an updated version of the tool that
> > sets the configuration on by default for newly created
> > repositories, though.
>
> I almost did that in my patch - but decided against it for the
> reason I just noted above.
>
> Does anyone on the mailing list really have an objection to having
> reflogs on by default?
I certainly don't.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-14 20:35 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061214200245.GP1747@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Does anyone on the mailing list really have an objection to having
> reflogs on by default?
When you talk about potential breakage for existing users, you
should not be asking people on THIS list. You instead should
talk with or at least think about people on linux-kernel, x.org
and wine people, and possibly others. git is maturing, and we
cannot expect that most of the users are paying attention to
what is happening on this list anymore.
I 100% agree that it makes sense to have reflog enabled for a
repository with an associated worktree. I would say that we do
not even need it to be conditional on the configuration variable
for such a repository.
My answer to your question is:
kernel.org:/pub/scm/
I would REALLY be worried to have reflog enabled at a public
distribution point where the only ways the owners interact with
it daily are 'git push' and 'git pull'. As you mentioned, there
is one extra potential receive-pack failure, and in general it
is one more thing that can go wrong, and hard to notice breakage
because it is on the other side of the connection.
Worse yet, there is no easy way to garbage collect. Even in an
end-user repository with a worktree, the only way to garbage
collect older reflog entries is to edit the reflog files to
remove the top part.
Maybe a check to say if $GIT_DIR is ".git" or ends with "/.git"
then enable it and otherwise honor the configuration variable,
without changing the default in the code (with your patch) nor
in the default configuration ("enable for new repositories" as I
suggested) might be a workable compromise.
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Junio C Hamano @ 2006-12-14 20:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612141732410.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> git-show-ref traverses every single _local_ tag when called. This is to
> overcome the problem that tags can be packed now, so a simple file
> existence check is not sufficient.
Is "traverses every single _local_ tag" a fact? It might go
through every single _local_ (possibly stale) packed tag in
memory but it should not traverse $GIT_DIR/refs/tags.
If I recall correctly, show-ref (1) first checks the filesystem
"$GIT_DIR/$named_ref" and says Ok if found and valid; otherwise
(2) checks packed refs (reads $GIT_DIR/packed-refs if not
already). So that would be at most one open (which may fail in
(1)) and one open+read (in (2)). Unless we are talking about
fork+exec overhead, that "traverse" should be reasonably fast.
Where is the bottleneck?
^ permalink raw reply
* Re: [PATCH] "master" should be treated no differently from any other branch
From: Junio C Hamano @ 2006-12-14 20:41 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612141519.44294.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> "master" shouldn't get special treatment
In principle yes.
However, the fmt-merge-message was designed so for a very
practical reason --- to keep Merge commit log messages Linus
makes in the kernel repository short and readable.
When your workflow is heavily based on merges from topics to
more than one maintenance tracks (say, 'maint' and 'master') and
the policy is to keep older maintenance tracks to be subsets of
newer maintenance tracks (e.g. changes applicable to an older
maintenance track are first merged into 'maint' and then 'maint'
is merged into 'master'), being able to see the patchflow is
sometimes handy [*1*].
I do not have issues against making git-status to always note
which branch the commit is going to be made, though.
[Footnote]
*1* Right now we do not have --only-merges option to log family,
so I use "show-branch maint master | grep '^ *-'" instead to get
this information.
^ permalink raw reply
* Re: [PATCH] git-reset [--mixed] <tree> [--] <paths>...
From: Junio C Hamano @ 2006-12-14 20:41 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <slrneo2atm.nqa.Peter.B.Baumann@xp.machine.xx>
Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de>
writes:
> Why not make
>
> git-reset --hard <treeish> -- file
>
> aquivalent to
>
> git-checkout <treeish> -- file
Theoretically we could, but I'd rather keep "reset --hard"
something that people would think a bit about before actually
running (I am not enthused about giving "reset --mixed" this
feature for the same reason, but I think it is safe enough).
I'd want to avoid overloading different meanings to the --hard
form. Mis-typing checkout (say, accidentally having <RETURN>
before "-- file" part while cut & paste) would not be so
dangeous; mis-typing "reset --hard" the same way could be
disastrous.
> PS: Your patch didn't apply cleanly.
As I said there is one bug I've fixed in my tree but the
branches were not pushed out yet.
^ permalink raw reply
* Re: [PATCH] INSTALL: no need to have GNU diff installed
From: Eric Wong @ 2006-12-14 20:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0612141139540.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> Since a long time, we have inbuilt diff generation.
We still require it for running tests. And git-rerere just
added a dependency on it (my fault :)
--
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-14 20:50 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Shawn Pearce
In-Reply-To: <Pine.LNX.4.64.0612141507200.18171@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
>> That changes what the command does to existing repositories,
>> which is somewhat impolite.
>
> You must be kidding, aren't you?
I am dead serious. I do not have _any_ issue on existing
repositories with a working tree, but I care deeply about public
distribution points. See my other message.
^ permalink raw reply
* Re: git-svnimport breakage as of git-1.4.4
From: Daniel Drake @ 2006-12-14 21:05 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: git
In-Reply-To: <20061214022142.GA14521@sashak.voltaire.com>
On Thu, 2006-12-14 at 04:21 +0200, Sasha Khapyorsky wrote:
> Try this please:
>
>
> diff --git a/git-svnimport.perl b/git-svnimport.perl
> index cbaa8ab..071777b 100755
> --- a/git-svnimport.perl
> +++ b/git-svnimport.perl
Thanks, it now works for both forms of command line arguments.
--
Daniel Drake
Brontes Technologies, A 3M Company
^ permalink raw reply
* Re: What's in git.git (stable)
From: Andy Parkins @ 2006-12-14 21:02 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612141221300.18171@xanadu.home>
On Thursday 2006, December 14 17:23, Nicolas Pitre wrote:
> Well, people are used to say they've "reverted" a change. Although the
> command might appear slightly misnamed wrt its operation, it still does
> what most people are expecting from such a name.
Actually , not only is git-revert misnamed, it doesn't match up with most
other SCMs.
"svn revert" is git-reset.
"bzr revert" is git-reset.
"darcs revert" is git-reset.
"hg revert" is git-reset.
"svk revert" is git-reset.
"monotone revert" is git-reset.
Most people must surely be expecting it to do what it does in every other SCM;
as it doesn't my argument is that we should just drop the name "revert" and
call it git-invert instead, which is more accurately named and doesn't
conflict with the standard meaning.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: git-svnimport breakage as of git-1.4.4
From: Sasha Khapyorsky @ 2006-12-14 21:20 UTC (permalink / raw)
To: Daniel Drake; +Cc: git, Dongsheng Song
In-Reply-To: <1166130300.21982.0.camel@systems03.lan.brontes3d.com>
On 16:05 Thu 14 Dec , Daniel Drake wrote:
> On Thu, 2006-12-14 at 04:21 +0200, Sasha Khapyorsky wrote:
> > Try this please:
> >
> >
> > diff --git a/git-svnimport.perl b/git-svnimport.perl
> > index cbaa8ab..071777b 100755
> > --- a/git-svnimport.perl
> > +++ b/git-svnimport.perl
>
> Thanks, it now works for both forms of command line arguments.
Thanks for reporting. I still run git-svnimport against
http://tortoisesvn.tigris.org/svn/tortoisesvn, works fine up to now.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-14 21:22 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612140959.19209.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
>> > Tell them if they
>> > made a branch as well, which branch they are now on.
>>
>> I think you are talking about "checkout -b" not commit here;
>> this might be a borderline (branch creation is less often done
>> and it might warrant assuring feedback), but I think it still
>> falls into the "doing exactly what it was told to do" category.
>
> You're right, I was. The reason I think feedback is useful is
> because of the two ways of making a new branch:
>
> - git-branch XYZ
> This makes a new branch but DOESN'T leave me on XYZ
> - git-commit -b XYZ
> This makes a new branch and switches to XYZ
>
> I can't tell you the number of times I get this wrong. It's not because I
> don't know if I stop to think, it's because I'm thinking about the project,
> not the VCS.
This is interesting. You said "commit -b", were pointed out
that you were talking about "checkout -b", and just after saying
"yup, that is right, I was", you again say "commit -b".
Maybe the users often need this sequence (I personally don't,
but others might):
$ git checkout ;# or the previous day ended with a clean state
$ edit edit hack
$ git checkout -b XYZ ;# the changes are about different stuff
$ git commit ;# commit the changes there
$ git checkout master ;# or whatever branch you usually are on
and "git commit -b <newbranch>" might be a handy shortcut for
the last three commands. I dunno.
And if we had such a variant of commit, then it is doing
something unusual, so I would not oppose (actually I would
probably favor) if the transcript went something like this:
$ git commit -b XYZ -m "implement 'foo' subcommand" -a
committed changes to newly created branch XYZ, back on 'master'.
$ git show-branch master XYZ
* [master] finishing touches to 'hello world'
! [XYZ] implement foo subcommand
--
+ [XYZ] implement foo subcommand
-- [master] finishing touches to 'hello world'
$ exit
Earlier I said that the command should be silent if it did
exactly what it was told to do with some 'unless'es.
* If the command fails, we should report (no question).
* If the command succeeds the usual way, staying silent is
preferable, at least to me.
* If the command can have more than one mode of successful
outcome, stating success in which way is not a useless
verbosity. E.g. 'git merge' should probably tell you if it
did a usual three-way or a fast-forward (if the difference
matters). Especially reporting an unusual case a bit more
verbosely than usual is a good thing.
^ permalink raw reply
* Re: [PATCH] "master" should be treated no differently from any other branch
From: Andy Parkins @ 2006-12-14 21:23 UTC (permalink / raw)
To: git
In-Reply-To: <7vejr22ose.fsf@assigned-by-dhcp.cox.net>
On Thursday 2006, December 14 20:41, Junio C Hamano wrote:
> However, the fmt-merge-message was designed so for a very
> practical reason --- to keep Merge commit log messages Linus
> makes in the kernel repository short and readable.
I'm only after consistency; how about the reverse solution: drop the "into"
completely?
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Torgil Svensson @ 2006-12-14 21:27 UTC (permalink / raw)
To: R. Steve McKown; +Cc: Linus Torvalds, git
In-Reply-To: <e7bda7770612100347j78854d79x547084972ed14e99@mail.gmail.com>
On 12/10/06, Torgil Svensson <torgil.svensson@gmail.com> wrote:
> What if we use linus "module" file concept and allow the link objects
> to track subtrees? An object may look like this:
>
> commit: <SHA1>
> link: <SHA1> /path/to/remote/tree/or/blob
> Special customer release for a specific HW platform
> ---------------------------------------------------
> "Lib1/lib1.h" -> "<lib1-commit>/headers/lib1.h"
> "Lib1/lib1.so" -> "<build-environment-commit>/i386/Lib1/lib1.so"
> "App1_binary" -> "<build-environment-commit>/i386/App1/App1_binary"
This example is somewhat complex since the build for lib1.so and the
header-file might not has gone through the same commit on the lib1
subproject. Consider this example:
lib1 - library project (source tracking)
------------------------------------------
Blob: /src/lib1.h
app1 - application project (source tracking)
-----------------------------------------
Link: /headers/lib1.h -> <lib1-commit1>/src/lib1.h
build1 - Build project (binary build tracking)
------------------------------------
Link: /src/lib1 -> <lib1-commit2>/
Link: /src/app1 -> <app1-commit>/
Blob: /i386/lib1/lib1.so
Blob: /i386/app1/app1
Release Project (file compilation tracking)
-----------------------------------
Link: /headers/lib1.h -> <lib1-commit3>/src/lib1.h
Link: /bin/lib1.so -> <build1-commit>/i386/lib1/lib1.so
Link: /bin/app1 -> <build1-commit>/i386/app1/app1
<lib1-commit1>, <lib1-commit2> and <lib1-commit3> should be the same,
dictated by the app1 project. Can we enforce this in the modules file
or should the different supermodules fix this somehow using
scripts/hooks?
How do the super-projects in this case get access to the blobs pointed
by the links - transparent or explicit in the build-process?
^ permalink raw reply
* Re: [PATCH] "master" should be treated no differently from any other branch
From: Junio C Hamano @ 2006-12-14 21:30 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612142123.16291.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Thursday 2006, December 14 20:41, Junio C Hamano wrote:
>
>> However, the fmt-merge-message was designed so for a very
>> practical reason --- to keep Merge commit log messages Linus
>> makes in the kernel repository short and readable.
>
> I'm only after consistency; how about the reverse solution: drop the "into"
> completely?
I guess that question indicates that the part of my message you
did not quote was not written cleanly enough.
^ permalink raw reply
* Re: git-svnimport breakage as of git-1.4.4
From: Junio C Hamano @ 2006-12-14 21:32 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: git
In-Reply-To: <20061214212033.GG7838@sashak.voltaire.com>
Sasha Khapyorsky <sashak@voltaire.com> writes:
> On 16:05 Thu 14 Dec , Daniel Drake wrote:
>> On Thu, 2006-12-14 at 04:21 +0200, Sasha Khapyorsky wrote:
>> > Try this please:
>> >
>> >
>> > diff --git a/git-svnimport.perl b/git-svnimport.perl
>> > index cbaa8ab..071777b 100755
>> > --- a/git-svnimport.perl
>> > +++ b/git-svnimport.perl
>>
>> Thanks, it now works for both forms of command line arguments.
>
> Thanks for reporting. I still run git-svnimport against
> http://tortoisesvn.tigris.org/svn/tortoisesvn, works fine up to now.
An applicable version of the patch with proposed commit log
message would be much appreciated.
^ permalink raw reply
* Re: Ignoring local changes
From: Pazu @ 2006-12-14 21:36 UTC (permalink / raw)
To: Rogan Dawes; +Cc: git
In-Reply-To: <4581C1D4.7080102@dawes.za.net>
2006/12/14, Rogan Dawes <discard@dawes.za.net>:
> Why not remove it from the repo, then set .gitignore?
>
> If it is generated code, or compiled code, it probably shouldn't be in
> the repo in the first place . . . Simply correct that mistake, and you
> are good to go.
Basically, because I don't want to mess with the upstream. I know, I
can remove them only from my local branch, and never push the commit
that removed the files, and that's what I'll probably do if there's no
other way -- but it would be best if I could just ignore the files. It
doesn't sound unreasonable, does it?
^ permalink raw reply
* Re: git-svnimport breakage as of git-1.4.4
From: Sasha Khapyorsky @ 2006-12-14 21:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejr217v7.fsf@assigned-by-dhcp.cox.net>
On 13:32 Thu 14 Dec , Junio C Hamano wrote:
> >
> > Thanks for reporting. I still run git-svnimport against
> > http://tortoisesvn.tigris.org/svn/tortoisesvn, works fine up to now.
>
> An applicable version of the patch with proposed commit log
> message would be much appreciated.
Sure.
Wanted at least to finish the test (it is running yet), then will
submit the patch in conventional way.
^ permalink raw reply
* Re: [PATCH] "master" should be treated no differently from any other branch
From: Andy Parkins @ 2006-12-14 21:37 UTC (permalink / raw)
To: git
In-Reply-To: <7virge17yh.fsf@assigned-by-dhcp.cox.net>
On Thursday 2006, December 14 21:30, Junio C Hamano wrote:
> I guess that question indicates that the part of my message you
> did not quote was not written cleanly enough.
It was; I'm just stupid.
Let's make the special case "linux-master" and then Linus gets what he wants
and consistency is restored.
No? Okay, I give up then. :-)
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: Ignoring local changes
From: Rogan Dawes @ 2006-12-14 21:27 UTC (permalink / raw)
To: Pazu; +Cc: git
In-Reply-To: <9e7ab7380612140855p1f4ee6c1l5ef24c4d1d169da6@mail.gmail.com>
Pazu wrote:
> 2006/12/14, Andreas Ericsson <ae@op5.se>:
>
>> Correction: I just tested this, and while git-add won't touch the file,
>> git-update-index will, and git-status still shows it as modified.
>
> Yes, and that's exactly my problems. There are a number of
> modified/removed files in my working copy that were previously added
> to the repository, and git-status shows them as modified/removed, even
> when they're listed in .gitignore or .git/info/exclude
>
>> This feels like a bug to me.
>
> Dunno, sounds like this is by design. I acknowledge that my situation
> is unusual, and most often, you'll want to always track a file once
> it's been added to the repository.
>
> -- Pazu
Why not remove it from the repo, then set .gitignore?
If it is generated code, or compiled code, it probably shouldn't be in
the repo in the first place . . . Simply correct that mistake, and you
are good to go.
^ 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