* [PATCH 4/4] builtin-fast-export.c: handle nested tags
From: Erik Faye-Lund @ 2009-03-22 21:50 UTC (permalink / raw)
To: git; +Cc: gitster, Erik Faye-Lund
In-Reply-To: <1237758620-6116-3-git-send-email-kusmabite@gmail.com>
When tags that points to tags are passed to fast-export, an error saying
"Tag [TAGNAME] points nowhere?". This fix calls parse_object() on the object
before referencing it's tag, to ensure the tag-info is fully initialized. In
addition, it inserts a comment to point out where nested tags are handled. This
is consistent with the comment for signed tags.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
builtin-fast-export.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index c3ce320..8083c5f 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -362,7 +362,10 @@ static void get_tags_and_duplicates(struct object_array *pending,
break;
case OBJ_TAG:
tag = (struct tag *)e->item;
+
+ /* handle nested tags */
while (tag && tag->object.type == OBJ_TAG) {
+ parse_object(tag->object.sha1);
string_list_append(full_name, extra_refs)->util = tag;
tag = (struct tag *)tag->tagged;
}
--
1.6.2.1.226.gcb2dd
^ permalink raw reply related
* [PATCH 3/4] builtin-fast-export.c: fix crash on tagged trees
From: Erik Faye-Lund @ 2009-03-22 21:50 UTC (permalink / raw)
To: git; +Cc: gitster, Erik Faye-Lund
In-Reply-To: <1237758620-6116-2-git-send-email-kusmabite@gmail.com>
If a tag object points to a tree (or another unhandled type), the commit-
pointer is left uninitialized and later dereferenced. This patch adds a default
case to the switch that issues a warning and skips the object.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
builtin-fast-export.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index 02bad1f..c3ce320 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -375,6 +375,10 @@ static void get_tags_and_duplicates(struct object_array *pending,
case OBJ_BLOB:
handle_object(tag->object.sha1);
continue;
+ default: /* OBJ_TAG (nested tags) is already handled */
+ warning("Tag points to object of unexpected type %s, skipping.",
+ typename(tag->object.type));
+ continue;
}
break;
default:
--
1.6.2.1.226.gcb2dd
^ permalink raw reply related
* Re: [PATCH] remote: improve sorting of "configure for git push" list
From: Junio C Hamano @ 2009-03-22 21:58 UTC (permalink / raw)
To: Jay Soffian
Cc: Jeff King, Johannes Schindelin, Johannes Sixt, Git Mailing List
In-Reply-To: <76718490903220747p74cf3704vbbbc085c28a105b2@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Sun, Mar 22, 2009 at 4:59 AM, Jeff King <peff@peff.net> wrote:
>> The data structure used to store this list is a string_list
>> of sources with the destination in the util member. The
>> current code just sorts on the source; if a single source is
>> pushed to two different destination refs at a remote, then
>> the order in which they are printed is non-deterministic.
>> ...
> Ack. There is one thing I wonder though. Is this even a sane config?
I do not think of a workflow that this feature is absolutely necessary in
the sense that it cannot be worked around if you removed it, but that is
not what you asked.
I wouldn't be surprised if there are some kernel subsystem maintainers who
usually push to their master but when they push their finished goods to
their for-linus branch make sure they update their master at the same time.
Configuring their local for-linus to push to master and for-linus may be
one way to do so.
In a one-branch project with two people, it is not entirely inconceivable
to arrange for me to push to master and junio while you to push to master
and jay, in order to keep track.
^ permalink raw reply
* Re: [PATCH/RFD] builtin-revert.c: release index lock when cherry-picking an empty commit
From: Junio C Hamano @ 2009-03-22 21:58 UTC (permalink / raw)
To: Jeff King; +Cc: Mike Ralphson, git
In-Reply-To: <20090322094139.GA10599@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> [this is a follow-up on the "eval 'false\n\n'" returns 0 issue on
> FreeBSD]
Thanks for keeping track of this one.
> Thanks for looking this up, Mike. It sounds like FreeBSD is probably the
> only problematic one. I confirmed that the problem still exists in
> FreeBSD 7.1, and I've mailed the git ports maintainer off-list to
> make him aware of the issue. So we'll see what happens.
>
> Junio, do you want to put anything in the release notes warning people
> who build from source that this is a potential issue? Do you want
> something in the Makefile detecting that the shell is broken?
A sentence or two in INSTALL will not hurt.
I would not worry too much about the test scripts, but I would worry more
about getting phantom bug reports for our shell script Porcelains that get
hit by this. Earlier I mentioned bisect is the only heavy user, but the
issue is more severe with filter-branch that is designed to eval end user
scripts (calls to 'eval "$filter_frotz"' check the exit status and die on
failure---with trailing blank lines the failure the filter reports will
not get caught).
^ permalink raw reply
* Re: [PATCH 3/7] check-ref-format --branch: give Porcelain a way to grok branch shorthand
From: Junio C Hamano @ 2009-03-22 21:58 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git
In-Reply-To: <36ca99e90903220318g2cfb192fi9d4ef0da95e1a65b@mail.gmail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
>> int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
>> {
>> + if (argc == 3 && !strcmp(argv[1], "--branch")) {
>> + struct strbuf sb = STRBUF_INIT;
>> + strbuf_branchname(&sb, argv[2]);
>
> strbuf_branchname() will be introduced in the next patch!
Good eyes; thanks.
^ permalink raw reply
* Re: [PATCH 1/8] builtin-apply: use warning() instead of fprintf(stderr, "warning: ")
From: Junio C Hamano @ 2009-03-22 21:58 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <20090322113646.GL27459@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Thu, Feb 19, 2009 at 10:11:24PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
>> Jeff King <peff@peff.net> writes:
>>
>> > Other than that, these all look pretty straightforward. Probably the
>> > shell scripts should be switched to match, too. But it would be nice to
>> > hear from Junio first that this cleanup is even desired (so you don't
>> > waste time).
>>
>> I think it is a good thing to do. If the pre-release-freeze is a good
>> time to do so it is a different matter. A good way to judge would be
>> how much of these overlap with "git diff master next" (smaller the better,
>> obviously).
>
> Should I rebase the series against current master and resend?
Yes, please, if the overlap with "diff master next" is small enough.
^ permalink raw reply
* Re: [PATCH] builtin-fast-export.c: add default case to avoid crash on corrupt repo
From: Junio C Hamano @ 2009-03-22 21:58 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Erik Faye-Lund, git, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <40aa078e0903220522g66cf2172l9f1a43ed562cc4d3@mail.gmail.com>
Erik Faye-Lund <kusmabite@googlemail.com> writes:
> Anyway, I guess this makes the most sense as a four-patch series:
> 1) Add test-cases for tags of tag objects, tag objects of tag objects,
> tags of trees and tag objects of trees.
> 2) Turn the existing error into a warning
> 3) Add the missing warning and remove the crash
> 4) Fix fast-export to export tags pointing to tags.
>
> Makes sense?
Yes.
I suspect we will hear an argument that say the dying is deliberate
because pretending to have produced a faithful export while some
information is lacking is bad and warnings are easy to miss, and I would
certainly understand that argument.
We have similar issue with signed tags and filter-branch, which strips the
signature when it rewrites the history. I recall the code originally died
for the same reasoning, but asking "it died; what can the user do now?"
made us realize that it is the best we can do to make best-effort
reproduction with a warning when losing information.
This falls into the same category. I think "we die by default if we
cannot give a faithful reproduction, and the user needs to give an
explicit permission (e.g. --force option) to lose information", is a very
sensible thing to do, but "we die if we cannot export some things, and we
refuse to produce an approximation." without an escape hatch is not.
^ permalink raw reply
* Re: [PATCH 13/16] t3700: Skip a test with backslashes in pathspec
From: Junio C Hamano @ 2009-03-22 21:59 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200903221755.44642.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> On Sonntag, 22. März 2009, Junio C Hamano wrote:
>> I do not think the justification for this change is explained well enough.
>>
>> The test prepares a file whose name consists of "ef, oh, bra, oh, you,
>> ket, bee, ei and are" (no backslashes), and passes a filespec that quotes
>> bra and ket with backslash so glob won't misinterpret as if we are asking
>> to add "ef oh followed by either oh or you followed by bee ei are". There
>> is no path that has a backslash in it involved.
>>
>> If this does not work on Windows, there is something else going on. Is it
>> that the shell eats one level of backslash too much or something?
>
> I added these two paragraphs:
Thanks; pulled.
^ permalink raw reply
* Re: [PATCH] Respect core.autocrlf when preparing temporary files for external diff
From: Junio C Hamano @ 2009-03-22 21:59 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: Jeff King, Johannes Schindelin, git
In-Reply-To: <bdca99240903220830u50999dfcnee0f0091b4dec835@mail.gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> Me being the reporter of the original msysGit issue #177, I'd like to
> clarify that my intention not necessarily was to make
> "core.autocrlf=true" affect temporary files (i.e. to "smudge" them),
> but to ensure that the files fed into "git diff" are always generated
> / acquired in a consistent way, so that they are in fact comparable.
Thanks. I think everybody involved in the thread is in agreement with
that.
> I'd also be happy with a solution that always feeds clean files into
> "git diff", although that would probably mean that we could not reuse
> working tree files if "core.autocrlf=true" is set.
When we generate diff internally, even when we borrow from the work tree,
we clean it before using. See diff_populate_filespec(), ll.1900-1915.
Borrowing done by diff_tempfile(), which currently does not run clean, and
the call to prep_temp_blob() in ll.2030-2035 that gives a temporary file
without convert_to_working_tree() are inconsistent, as pointed out by you
and Dscho.
If you run "git diff <filename>" after cloning, I expect that no temporary
files are involved, _unless_ you have some settings that force "git diff"
not to use the internal diff. Do you use GIT_EXTERNAL_DIFF? Do you use
"textconv" attribute? What external program do you invoke from these
mechanisms, and what does it expect to see as its input?
The discussion in the last few messages in this thread speculates that the
external programs are more likely to expect representations suitable in
the work tree, aka "smudged", than "clean" one. It would be nice to get a
datapoint from you as the original reporter to confirm or refute that
speculation.
^ permalink raw reply
* Re: [PATCH v2] githooks documentation: post-checkout hook is also called after clone
From: Junio C Hamano @ 2009-03-22 21:59 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git, patnotz, peff
In-Reply-To: <49C6878E.8060509@web.de>
Thanks, both.
^ permalink raw reply
* Re: [Gittogether] Re: GitTogether '09
From: Sam Vilain @ 2009-03-22 22:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git, gittogether
In-Reply-To: <alpine.DEB.1.00.0903181551380.10279@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
>>> Last year Google provided two international airplane tickets and was
>>> able to host us, we can at least ask them to host us again this year
>>> (if that is what we decide on).
>>>
>> Did Google do two international tickets last year for Git?
>>
>
> I do not think so. Mugwump got the international airplane ticket, AFAIR,
> and warthog the local "ticket".
>
Right, and we decided to give Christian back his air fare with some of
the Mentor treasure, so that was the second international ticket
essentially paid by Google.
Speaking of spoils, I'm now on Vendor number 3 for the T-Shirts which
are apparently in a print queue now. It's a depressing that it's now
longer since the conference than til the next one :(
I'll be contacting everyone off-line asking for their size requirements
and following up those who didn't send me addresses yet..
Sam.
^ permalink raw reply
* [PATCH] Improve error message about fetch into current branch
From: Alex Riesen @ 2009-03-22 22:07 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
Otherwise, it is hard to guess why the fetch failed.
Make sure we at least mention that the repository must be bare.
Also the current branch is printed.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
In particular, a repository not marked bare with core.bare is, for
some reason, considered non-bare even if there is no work tree nor
index. I found about the message while trying to run git remote,
in an essentially bare repository without core.bare set. Funny,
git --bare fetch worked properly, but git --bare remote update failed:
$ GIT_TRACE=1 ~/projects/git/git --bare remote -v update
trace: built-in: git 'remote' '-v' 'update'
Updating origin
trace: run_command: 'fetch' '-v' 'origin'
trace: exec: 'git' 'fetch' '-v' 'origin'
trace: built-in: git 'fetch' '-v' 'origin'
fatal: Refusing to fetch into current branch refs/heads/master
error: Could not fetch origin
$ git --bare fetch -v origin
From git://git.kernel.org/pub/scm/linux/hotplug/udev
= [up to date] master -> master
$
Looks like --bare is lost somewhere.
builtin-fetch.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 7fb35fc..7293146 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -544,7 +544,8 @@ static void check_not_current_branch(struct ref *ref_map)
for (; ref_map; ref_map = ref_map->next)
if (ref_map->peer_ref && !strcmp(current_branch->refname,
ref_map->peer_ref->name))
- die("Refusing to fetch into current branch");
+ die("Refusing to fetch into current branch %s "
+ "of non-bare repository", current_branch->refname);
}
static int do_fetch(struct transport *transport,
--
1.6.2.1.316.g4241
^ permalink raw reply related
* Newbie: Do I need to download the entire repo to work on just 1 file?
From: Anthony Rasmussen @ 2009-03-22 22:08 UTC (permalink / raw)
To: git
Hi all,
The large website has a developers-only version of the site published on a server, which is tracked by git.
I
only have to work on 1 file. I'd like to work on it, test changes on
the dev site, work on it some more, then commit when ready.
Do I have to download the entire rep onto my laptop in order to do this? I have read and read, but I am quite confused :)
Thanks for your help!
_________________________________________________________________
Get quick access to your favorite MSN content with Internet Explorer 8.
http://ie8.msn.com/microsoft/internet-explorer-8/en-us/ie8.aspx?ocid=B037MSN55C0701A
^ permalink raw reply
* Re: [Gittogether] Re: GitTogether '09
From: Sam Vilain @ 2009-03-22 22:01 UTC (permalink / raw)
To: Sam Vilain; +Cc: Johannes Schindelin, gittogether, git, Shawn O. Pearce
In-Reply-To: <49C6B4E6.8030000@vilain.net>
Sam Vilain wrote:
> I'll be contacting everyone off-line asking for their size requirements
I meant off-list, clearly :-)
Sam.
^ permalink raw reply
* Re: [RFC] git gui doesn't call post-checkout hook on checkout or clone
From: Jeff King @ 2009-03-22 22:33 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git, gitster, spearce
In-Reply-To: <49C65DF1.8030608@web.de>
On Sun, Mar 22, 2009 at 04:49:05PM +0100, Jens Lehmann wrote:
> When checking out or cloning via git gui, the post-checkout
> hook is not called. This is a bit unexpected ...
>
> The reason is that git gui uses git read-tree with the -u
> option and not git checkout and git clone. I changed git
> read-tree to call the post-checkout hook when called with
> -u and it seems to solve the problem. I would make a patch
> for that if you want.
>
> But is this the right way to do this? Seems like we could
> surprise some users of git read-tree with this change in
> behaviour.
No, I think plumbing should not generally call hooks. The right solution
would be to have git-gui call the post-checkout hook.
-Peff
^ permalink raw reply
* Re: [PATCH/RFD] builtin-revert.c: release index lock when cherry-picking an empty commit
From: Jeff King @ 2009-03-22 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Ralphson, git
In-Reply-To: <7veiwpdxtg.fsf@gitster.siamese.dyndns.org>
On Sun, Mar 22, 2009 at 02:58:35PM -0700, Junio C Hamano wrote:
> > Junio, do you want to put anything in the release notes warning people
> > who build from source that this is a potential issue? Do you want
> > something in the Makefile detecting that the shell is broken?
>
> A sentence or two in INSTALL will not hurt.
>
> I would not worry too much about the test scripts, but I would worry more
> about getting phantom bug reports for our shell script Porcelains that get
> hit by this. Earlier I mentioned bisect is the only heavy user, but the
> issue is more severe with filter-branch that is designed to eval end user
> scripts (calls to 'eval "$filter_frotz"' check the exit status and die on
> failure---with trailing blank lines the failure the filter reports will
> not get caught).
Agreed. The good news is that the /bin/sh people are treating it like a
bug:
http://lists.freebsd.org/pipermail/freebsd-standards/2009-March/001721.html
so it will hopefully be fixed soon. It might still be worth warning
users of older releases in INSTALL, though.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH 8/8] user-manual: simplify the user configuration
From: Wincent Colaiuta @ 2009-03-22 22:42 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1237745121-6325-9-git-send-email-felipe.contreras@gmail.com>
El 22/3/2009, a las 19:05, Felipe Contreras escribió:
> This is shorter, avoids the burder to think about the format of the
> configuration file, and git config is already used in other places in
> the manual.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> Documentation/user-manual.txt | 8 +++-----
> 1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-
> manual.txt
> index b7678aa..c6ed940 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1015,13 +1015,11 @@ Telling git your name
> ---------------------
>
> Before creating any commits, you should introduce yourself to git.
> The
> -easiest way to do so is to make sure the following lines appear in a
> -file named `.gitconfig` in your home directory:
> +easiest way is to use the linkgit:git-config[1] command:
>
> ------------------------------------------------
> -[user]
> - name = Your Name Comes Here
> - email = you@yourdomain.example.com
> +$ git config --global user.name "Your Name Comes Here"
> +$ git config --global user.email you@yourdomain.example.com
> ------------------------------------------------
>
> (See the '"CONFIGURATION FILE"' section of linkgit:git-config[1] for
> --
> 1.6.2.1.352.gae594
See this lengthy thread:
http://article.gmane.org/gmane.comp.version-control.git/106634
Wincent
^ permalink raw reply
* Re: [PATCH] Respect core.autocrlf when preparing temporary files for external diff
From: Sebastian Schuberth @ 2009-03-22 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Johannes Schindelin, git
In-Reply-To: <7vljqxcj84.fsf@gitster.siamese.dyndns.org>
> If you run "git diff <filename>" after cloning, I expect that no temporary
> files are involved, _unless_ you have some settings that force "git diff"
> not to use the internal diff. Do you use GIT_EXTERNAL_DIFF? Do you use
> "textconv" attribute? What external program do you invoke from these
> mechanisms, and what does it expect to see as its input?
As I prefer graphical diff tools, I do not use internal diff, but
Beyond Compare [1]. In order to do that I have configured
diff.external to point to a wrapper script that contains the following
lines:
---8<---
#!/bin/bash
# diff is called with 7 parameters:
# path old-file old-hex old-mode new-file new-hex new-mode
"C:/Program Files/Beyond Compare 3/BCompare.exe" "$2" "$5" | cat
---8<---
As Beyond Compare is a stand-alone diff / merge tool, it expects to be
working on regular files in the file system. And to be hostest, I did
not know about the "textconv" attribute until now.
> The discussion in the last few messages in this thread speculates that the
> external programs are more likely to expect representations suitable in
> the work tree, aka "smudged", than "clean" one. It would be nice to get a
> datapoint from you as the original reporter to confirm or refute that
> speculation.
I agree to the speculations. IMHO calling an external diff tool with
two revisions of a file should result in the same as e.g. checking out
the two revisions in two different working trees and then launching
the user's external diff tool on the two working tree files.
[1] http://www.scootersoftware.com/
--
Sebastian Schuberth
^ permalink raw reply
* Re: Git for Windows 1.6.2.1-preview20090322
From: Jeff King @ 2009-03-22 22:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0903222149330.10279@pacific.mpi-cbg.de>
On Sun, Mar 22, 2009 at 10:17:23PM +0100, Johannes Schindelin wrote:
> - Some commands are not yet supported on Windows and excluded from the
> installation; namely: git archimport, git cvsexportcommit, git
> cvsimport, git cvsserver, git filter-branch, git instaweb, git
> send-email, git shell.
A few people have asked about filter-branch on Windows recently; JSixt
indicated that it works from his built version:
http://article.gmane.org/gmane.comp.version-control.git/112103
Is it time to include it?
-Peff
^ permalink raw reply
* Re: [RFC/PATCH 8/8] user-manual: simplify the user configuration
From: Felipe Contreras @ 2009-03-22 23:01 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <0A3F8ECD-EEFA-4DB0-AFED-AEE7DAFE8DB3@wincent.com>
On Mon, Mar 23, 2009 at 12:42 AM, Wincent Colaiuta <win@wincent.com> wrote:
> El 22/3/2009, a las 19:05, Felipe Contreras escribió:
>
>> This is shorter, avoids the burder to think about the format of the
>> configuration file, and git config is already used in other places in
>> the manual.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>> Documentation/user-manual.txt | 8 +++-----
>> 1 files changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
>> index b7678aa..c6ed940 100644
>> --- a/Documentation/user-manual.txt
>> +++ b/Documentation/user-manual.txt
>> @@ -1015,13 +1015,11 @@ Telling git your name
>> ---------------------
>>
>> Before creating any commits, you should introduce yourself to git. The
>> -easiest way to do so is to make sure the following lines appear in a
>> -file named `.gitconfig` in your home directory:
>> +easiest way is to use the linkgit:git-config[1] command:
>>
>> ------------------------------------------------
>> -[user]
>> - name = Your Name Comes Here
>> - email = you@yourdomain.example.com
>> +$ git config --global user.name "Your Name Comes Here"
>> +$ git config --global user.email you@yourdomain.example.com
>> ------------------------------------------------
>>
>> (See the '"CONFIGURATION FILE"' section of linkgit:git-config[1] for
>> --
>> 1.6.2.1.352.gae594
>
> See this lengthy thread:
>
> http://article.gmane.org/gmane.comp.version-control.git/106634
I've obviously seen that thread because I started it.
Can you write more than one line to explain your point?
--
Felipe Contreras
^ permalink raw reply
* Re: Newbie: Do I need to download the entire repo to work on just 1 file?
From: Sverre Rabbelier @ 2009-03-22 23:00 UTC (permalink / raw)
To: Anthony Rasmussen; +Cc: git
In-Reply-To: <BLU121-W15DB0E5CEBC1DA697E5ED8B4950@phx.gbl>
Heya,
On Sun, Mar 22, 2009 at 23:08, Anthony Rasmussen <evoluenta@hotmail.com> wrote:
> Do I have to download the entire rep onto my laptop in order to do this? I have read and read, but I am quite confused :)
Yes, you do, in general though, git repositories are quite compact
compared to, say, a svn checkouts. It is not unheard of that the full
git clone is smaller than the same code as svn checkout.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Newbie: Do I need to download the entire repo to work on just 1 file?
From: Geoffrey Lee @ 2009-03-22 23:06 UTC (permalink / raw)
To: git
In-Reply-To: <fabb9a1e0903221600j22cf028fl903aef8076e53777@mail.gmail.com>
On Sun, Mar 22, 2009 at 4:00 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Sun, Mar 22, 2009 at 23:08, Anthony Rasmussen <evoluenta@hotmail.com> wrote:
>> Do I have to download the entire rep onto my laptop in order to do this? I have read and read, but I am quite confused :)
>
> Yes, you do, in general though, git repositories are quite compact
> compared to, say, a svn checkouts. It is not unheard of that the full
> git clone is smaller than the same code as svn checkout.
It depends on what you mean by "entire repo". Of course you need all
the source files to compile, but you do not need past revisions. Take
a look at the --depth parameter for git-clone.
-Geoffrey Lee
^ permalink raw reply
* Re: Newbie: Do I need to download the entire repo to work on just 1 file?
From: Nicolas Sebrecht @ 2009-03-22 23:10 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0903221600j22cf028fl903aef8076e53777@mail.gmail.com>
On Mon, Mar 23, 2009 at 12:00:59AM +0100, Sverre Rabbelier wrote:
>
> Heya,
>
> On Sun, Mar 22, 2009 at 23:08, Anthony Rasmussen <evoluenta@hotmail.com> wrote:
> > Do I have to download the entire rep onto my laptop in order to do this? I have read and read, but I am quite confused :)
Please, wrap your lines to something convenient (72-80 characters max).
> Yes, you do
No, you don't. Why not use the '--depth <depth>' option of 'git clone' ?
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Newbie: Do I need to download the entire repo to work on just 1 file?
From: Sverre Rabbelier @ 2009-03-22 23:10 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: git
In-Reply-To: <20090322231002.GA12974@vidovic>
Heya,
On Mon, Mar 23, 2009 at 00:10, Nicolas Sebrecht
<nicolas.s-dev@laposte.net> wrote:
> No, you don't. Why not use the '--depth <depth>' option of 'git clone' ?
That depends on if he wants to push back to the original repo or not, right?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Respect core.autocrlf when preparing temporary files for external diff
From: Junio C Hamano @ 2009-03-22 23:12 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: Jeff King, Johannes Schindelin, git
In-Reply-To: <bdca99240903221548y38f31177q6abb88c2f7f87a73@mail.gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> writes:
>> The discussion in the last few messages in this thread speculates that the
>> external programs are more likely to expect representations suitable in
>> the work tree, aka "smudged", than "clean" one. It would be nice to get a
>> datapoint from you as the original reporter to confirm or refute that
>> speculation.
>
> I agree to the speculations. IMHO calling an external diff tool with
> two revisions of a file should result in the same as e.g. checking out
> the two revisions in two different working trees and then launching
> the user's external diff tool on the two working tree files.
Ok.
^ 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