* Re: [PATCH] Documentation/gitcli.txt: dashed forms not allowed anymore
From: Miklos Vajna @ 2009-01-01 14:40 UTC (permalink / raw)
To: jidanni; +Cc: git, gitster
In-Reply-To: <87ljtvmygk.fsf@jidanni.org>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
On Thu, Jan 01, 2009 at 12:39:39PM +0800, jidanni@jidanni.org wrote:
> - * it's preferred to use the non dashed form of git commands, which means that
> - you should prefer `"git foo"` to `"git-foo"`.
> + * it's required to use the non dashed form of git commands, which means that
> + you must use `"git foo"` and not `"git-foo"`. The latter no longer works.
I would append: "unless you add the output of `git --exec-path` to your
PATH."
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] builtin-apply: prevent non-explicit permission changes
From: Junio C Hamano @ 2009-01-01 13:00 UTC (permalink / raw)
To: Alexander Potashev; +Cc: Git Mailing List
In-Reply-To: <20081230235357.GA12747@myhost>
Alexander Potashev <aspotashev@gmail.com> writes:
> builtin-apply.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-apply.c b/builtin-apply.c
> index 07244b0..071f6d8 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -630,7 +630,7 @@ static int gitdiff_index(const char *line, struct patch *patch)
> memcpy(patch->new_sha1_prefix, line, len);
> patch->new_sha1_prefix[len] = 0;
> if (*ptr == ' ')
> - patch->new_mode = patch->old_mode = strtoul(ptr+1, NULL, 8);
> + patch->old_mode = strtoul(ptr+1, NULL, 8);
> return 0;
> }
>
> @@ -2447,6 +2447,7 @@ static int check_preimage(struct patch *patch, struct cache_entry **ce, struct s
> if (st_mode != patch->old_mode)
> fprintf(stderr, "warning: %s has type %o, expected %o\n",
> old_name, st_mode, patch->old_mode);
> + patch->new_mode = st_mode;
Can you do this unconditionally, overwriting whatever we read from the
patch header metainfo lines?
^ permalink raw reply
* Re: shallow clone, shallow fetch?
From: Sitaram Chamarty @ 2009-01-01 9:25 UTC (permalink / raw)
To: git
In-Reply-To: <877i5fohwr.fsf@jidanni.org>
On 2009-01-01, jidanni@jidanni.org <jidanni@jidanni.org> wrote:
> Last week I did git-clone --depth 1 This week I wanted to freshen my
> repository, with the same goal: "I don't care about history, just
> fast forward me with the least bytes transfered." But all I can find
> is just plain git pull. Did I achieve my goal?
> $ git pull
> remote: Counting objects: 7007, done.
> remote: Compressing objects: 100% (3057/3057), done.
> remote: Total 7007 (delta 4280), reused 6076 (delta 3625)
> Receiving objects: 100% (7007/7007), 2.96 MiB | 26 KiB/s, done.
> Resolving deltas: 100% (4280/4280), done.
> From git://git.kernel.org/pub/scm/git/git
> 2fa431b..bbbb865 html -> origin/html
> a9012e3..936b705 maint -> origin/maint
> dfd79c7..794d84e man -> origin/man
> 159c88e..c32f76f master -> origin/master
> 3b9b952..6f67462 next -> origin/next
> + b14a7fb...89bdc19 pu -> origin/pu (forced update)
The hashes certainly agree with what I have (just did a pull
this minute), except I also have a new branch called
"origin/todo" at SHA1=6670008 which you seem to be missing.
I'm not familiar enough with shallow clones to draw any
conclusions though :-(
^ permalink raw reply
* Re: git has modified files after clean checkout
From: Caleb Cushing @ 2009-01-01 8:48 UTC (permalink / raw)
To: David Aguilar; +Cc: git
In-Reply-To: <402731c90812311541v28ac9617ge52e0e5c0f1298d2@mail.gmail.com>
> The files you mention contain CRLF. Do you have core.autocrlf set
> globally somewhere, perhaps in your ~/.gitconfig?
yes I have it set to input
> Anyways.. like I said -- I couldn't reproduce your problem so this is
> pure speculation on my part =)
it's inconsistent although I see something more often than not, and
only with this particular repository. Sometimes it's one set of files
other times it's others. this time it was 2 sometimes it's more like
40 (just throwing numbers around) and that can be the same unchanged
clone. seem to happen on checkout. heck even noticed a git reset
--hard HEAD didn't clear it all the first time today, in one case.
after sleep I'll see if 1.6.1 fixes my issue.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: git-difftool
From: Ping Yin @ 2009-01-01 7:38 UTC (permalink / raw)
To: Matthieu Moy; +Cc: David Aguilar, git
In-Reply-To: <vpqhc4kz5zh.fsf@bauges.imag.fr>
On Thu, Jan 1, 2009 at 12:04 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> David Aguilar <davvid@gmail.com> writes:
>
>> The usual use case for this script is when you have either
>> staged or unstaged changes and you'd like to see the changes
>> in a side-by-side diff viewer (e.g. xxdiff, tkdiff, etc).
>>
>> git difftool [<filename>*]
>
> Is it not a complex way of saying
>
> GIT_EXTERNAL_DIFF=xxdiff git diff
$ cat mydiff
#!/bin/bash
exec vimdiff $2 $5
then i run
$ GIT_EXTERNAL_DIFF=mydiff git diff
but it gives me the error
Vim: Warning: Output is not to a terminal
$ ps -ef | grep vimdiff
ping 20284 20283 1 15:37 pts/13 00:00:00 vimdiff
/tmp/.diff_XXXQK6 index.php
^ permalink raw reply
* Re: git-difftool
From: Boyd Stephen Smith Jr. @ 2008-12-31 21:20 UTC (permalink / raw)
To: David Aguilar; +Cc: git, Matthieu Moy
In-Reply-To: <402731c90812311211p548c49d3p100f79ddee7163b0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 981 bytes --]
On Wednesday 2008 December 31 14:11:07 you wrote:
> On Wed, Dec 31, 2008 at 8:04 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> > David Aguilar <davvid@gmail.com> writes:
> >> The usual use case for this script is when you have either
> >> staged or unstaged changes and you'd like to see the changes
> >> in a side-by-side diff viewer (e.g. xxdiff, tkdiff, etc).
> >>
> >> git difftool [<filename>*]
> >
> > Is it not a complex way of saying
> >
> > GIT_EXTERNAL_DIFF=xxdiff git diff
> >
> > ?
>
> Hmm... in theory, yes, but in practice, no.
> xxdiff is too gimp to handle what 'git diff' hands it =)
What about something like:
git diff | xxdiff -
I normally use:
git diff | kompare -
and it works fine.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Documentation/gitcli.txt: dashed forms not allowed anymore
From: jidanni @ 2009-01-01 4:39 UTC (permalink / raw)
To: git; +Cc: gitster
Non dashed command forms now mandatory.
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/gitcli.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
index 29e5929..9f582f6 100644
--- a/Documentation/gitcli.txt
+++ b/Documentation/gitcli.txt
@@ -45,8 +45,8 @@ disambiguating `\--` at appropriate places.
Here are the rules regarding the "flags" that you should follow when you are
scripting git:
- * it's preferred to use the non dashed form of git commands, which means that
- you should prefer `"git foo"` to `"git-foo"`.
+ * it's required to use the non dashed form of git commands, which means that
+ you must use `"git foo"` and not `"git-foo"`. The latter no longer works.
* splitting short options to separate words (prefer `"git foo -a -b"`
to `"git foo -ab"`, the latter may not even work).
--
1.6.0.6
^ permalink raw reply related
* [PATCH] Documentation/git-bundle.txt: Dumping contents of any bundle
From: jidanni @ 2009-01-01 4:24 UTC (permalink / raw)
To: peff, gitster; +Cc: mdl123, spearce, git
In-Reply-To: <20081219205100.GA26671@coredump.intra.peff.net>
>>>>> "JK" == Jeff King <peff@peff.net> writes:
JK> AFAIK, there is no tool to try salvaging strings from an incomplete pack
JK> (and you can't just run "strings" because the deltas are zlib
JK> compressed). So if I were in the police forensics department, I think I
JK> would read Documentation/technical/pack-format.txt and start hacking a
JK> solution as quickly as possible.
Hogwash. Patch follows. Maybe even better methods are available.
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-bundle.txt | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 1b66ab7..80248f5 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -164,6 +164,28 @@ $ git pull bundle
would treat it as if it is talking with a remote side over the
network.
+DUMPING CONTENTS OF ANY BUNDLE
+-----------------------
+
+Even if we cannot unbundle a bundle,
+
+------------
+$ git init
+$ git bundle unbundle mybundle.bun
+error: Repository lacks these prerequisite commits...
+------------
+
+We can still examine all the data contained within,
+
+------------
+$ sed '/^PACK/,$!d' mybundle.bun > mybundle.pack
+$ git unpack-objects < mybundle.pack
+$ cd .git/objects
+$ ls ??/*|tr -d /|git cat-file --batch-check
+$ ls ??/*|tr -d /|git cat-file --batch
+------------
+
+
Author
------
Written by Mark Levedahl <mdl123@verizon.net>
--
1.6.0.6
^ permalink raw reply related
* Re: shallow clone, shallow fetch?
From: jidanni @ 2009-01-01 2:54 UTC (permalink / raw)
To: git
In-Reply-To: <87vdt24zz4.fsf@jidanni.org>
Last week I did git-clone --depth 1 This week I wanted to freshen my
repository, with the same goal: "I don't care about history, just
fast forward me with the least bytes transfered." But all I can find
is just plain git pull. Did I achieve my goal?
$ git pull
remote: Counting objects: 7007, done.
remote: Compressing objects: 100% (3057/3057), done.
remote: Total 7007 (delta 4280), reused 6076 (delta 3625)
Receiving objects: 100% (7007/7007), 2.96 MiB | 26 KiB/s, done.
Resolving deltas: 100% (4280/4280), done.
From git://git.kernel.org/pub/scm/git/git
2fa431b..bbbb865 html -> origin/html
a9012e3..936b705 maint -> origin/maint
dfd79c7..794d84e man -> origin/man
159c88e..c32f76f master -> origin/master
3b9b952..6f67462 next -> origin/next
+ b14a7fb...89bdc19 pu -> origin/pu (forced update)
Merge made by recursive.
Documentation/Makefile | 9 +++++----
Documentation/RelNotes-1.6.1.1.txt | 23 +++++++++++++++++++++++
Documentation/cat-texi.perl | 8 ++++++--
Documentation/git-reset.txt | 29 ++++++++++++++++++++++++++++-
builtin-pack-objects.c | 9 ++++++++-
builtin-reset.c | 26 ++++++++++++++++++--------
gitweb/gitweb.perl | 5 +++--
t/t5302-pack-index.sh | 1 +
8 files changed, 92 insertions(+), 18 deletions(-)
create mode 100644 Documentation/RelNotes-1.6.1.1.txt
^ permalink raw reply
* Re: why still no empty directory support in git
From: Anatol Pomozov @ 2009-01-01 2:50 UTC (permalink / raw)
To: Liu Yubao; +Cc: Ping Yin, Git Mailing List
In-Reply-To: <4959BB07.6000106@gmail.com>
Hi
On Mon, Dec 29, 2008 at 10:09 PM, Liu Yubao <yubao.liu@gmail.com> wrote:
>
> Ping Yin wrote:
> > Yes, i know this topic has been discussed for many times. However, i
> > am still not clear about the real reason.
> >
> > So which is the reason?
> >
> > 1. it's by design, intentional
> It's saied somewhere git is a "stupid content tracker", it cares file content
> not file name, and empty directories will complicate the merge algorithm
> unnecessarily.
Could you please explain how will it complicate merging. What is the
difference between merging 2 directories with 0 and 5 files and
merging 2 directories with 5 and 10 files?
+1 that git should respect empty directories. Git should handle file
content and not decide for user does he want to keep empty directory
in the source tree or not.
--
anatol
^ permalink raw reply
* Re: git has modified files after clean checkout
From: David Aguilar @ 2008-12-31 23:41 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0812311223g2b6e8476y84b23c19977dfd10@mail.gmail.com>
On Wed, Dec 31, 2008 at 12:23 PM, Caleb Cushing <xenoterracide@gmail.com> wrote:
> here's what I did
>
> rm -r portage
> git clone git@github.com:xenoterracide/portage.git
Here's the anonymous clone URL (the one you provided is private)
$ git clone git://github.com/xenoterracide/portage.git
Read on below...
> cd portage
> git checkout origin/regen2 -b regen2
> git status
>
> # On branch regen2
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified:
> x11-themes/metacity-themes/files/metacity-themes-1.0-gentoo.diff
> # modified:
> x11-themes/metacity-themes/files/metacity-themes-1.2-gentoo.diff
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> why are there files claiming to be modified? this is a clean clone.
> I've had this before I usually end up doing a git reset --hard HEAD,
> but I'm thinking it's a bug, since I've seen it vary on the same clone
> and sometimes even disappear.
>
> git version 1.6.0.6
> --
> Caleb Cushing
>
> http://xenoterracide.blogspot.com
I followed the steps above and did not run into any such issues.
$ git status
# On branch regen2
nothing to commit (working directory clean)
$ git version
git version 1.6.1.28.gc32f76
(Junio's latest master at the moment)
Here's my quick guess based on what I'm seeing --
The files you mention contain CRLF. Do you have core.autocrlf set
globally somewhere, perhaps in your ~/.gitconfig?
It's possible that the autocrlf stuff is messing with those files.
They seem to be a mix of both unix LF and CRLF (the CRLF stuff doesn't
start until line 104 of
x11-themes/metacity-themes/files/metacity-themes-1.0-gentoo.diff, for
example, which is kinda odd but maybe be intentional?)
Check your autocrlf settings.
The following commands print out nothing for me:
$ git config core.autocrlf
$ git config --global core.autocrlf
Anyways.. like I said -- I couldn't reproduce your problem so this is
pure speculation on my part =)
Good luck,
--
David
^ permalink raw reply
* git has modified files after clean checkout
From: Caleb Cushing @ 2008-12-31 20:23 UTC (permalink / raw)
To: git
here's what I did
rm -r portage
git clone git@github.com:xenoterracide/portage.git
cd portage
git checkout origin/regen2 -b regen2
git status
# On branch regen2
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified:
x11-themes/metacity-themes/files/metacity-themes-1.0-gentoo.diff
# modified:
x11-themes/metacity-themes/files/metacity-themes-1.2-gentoo.diff
#
no changes added to commit (use "git add" and/or "git commit -a")
why are there files claiming to be modified? this is a clean clone.
I've had this before I usually end up doing a git reset --hard HEAD,
but I'm thinking it's a bug, since I've seen it vary on the same clone
and sometimes even disappear.
git version 1.6.0.6
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: git-difftool
From: David Aguilar @ 2008-12-31 20:11 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqhc4kz5zh.fsf@bauges.imag.fr>
On Wed, Dec 31, 2008 at 8:04 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> David Aguilar <davvid@gmail.com> writes:
>
>> The usual use case for this script is when you have either
>> staged or unstaged changes and you'd like to see the changes
>> in a side-by-side diff viewer (e.g. xxdiff, tkdiff, etc).
>>
>> git difftool [<filename>*]
>
> Is it not a complex way of saying
>
> GIT_EXTERNAL_DIFF=xxdiff git diff
>
> ?
>
> (My 2 cents, and happy new year ;-)
>
> --
> Matthieu
>
Hmm... in theory, yes, but in practice, no.
xxdiff is too gimp to handle what 'git diff' hands it =)
For example:
$ GIT_EXTERNAL_DIFF=echo git diff test
test /tmp/.diff_1dh4TW 9daeafb9864cf43055ae93beb0afd6c7d144bfa4 100644 test 0000
$ GIT_EXTERNAL_DIFF=xxdiff git diff test
xxdiff (cmdline.cpp:762):
You can specify at most 3 filenames.
Extra arguments: " 100644 test 0000000000000000000000000000000000000000 100644"
Use 'xxdiff --help' for more information.
external diff died, stopping at test.
I checked the git-diff documentation and could not find a way to
inhibit the sha1, mode, etc. args that are sent to GIT_EXTERNAL_DIFF
(nor should there be, I presume).
I'm all for finding the simplest way and GIT_EXTERNAL_DIFF seems like
the right entry point. What I should do is change the script so that
it handles all of the choosing-a-merge-tool-logic and just have git
call it via GIT_EXTERNAL_DIFF. That would definitely simplify the
script since 'git diff' would be handling all of the tmp file and
option processing logic. wow, I really like that idea. Thanks for
the tip!
Happy new year,
--
David
^ permalink raw reply
* [JGIT PATCH] Improve the sideband progress scaper to be more accurate
From: Shawn O. Pearce @ 2008-12-31 19:04 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <20081231073505.GA22551@spearce.org>
By matching only whole lines we should be able to improve the
progress scaper so we avoid ugly output like we had been seeing:
EGIT.contrib/jgit clone git://repo.or.cz/libgit2.git LIBGIT2
Initialized empty Git repository in /home/me/SW/LIBGIT2/.git
Counting objects: 547
Compressing objects: 100% (192/192)
ts: 100% (192/192)
Compressing objects: 100% (192/192)
ng objects: 100% (192/192)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> Would it be hard to get the progress look better?
Maybe this does the trick. Its hard to reproduce so its hard to
come up with the condition that was giving us the problem before.
I suspect its because we were getting line fragments on the sideband
channel, but I'm not sure that was really the case.
.../jgit/transport/SideBandInputStream.java | 37 +++++++++++++++++--
1 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/SideBandInputStream.java b/org.spearce.jgit/src/org/spearce/jgit/transport/SideBandInputStream.java
index 3ec9bff..f0ba3d3 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/SideBandInputStream.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/SideBandInputStream.java
@@ -73,10 +73,10 @@
private static final int CH_ERROR = 3;
private static Pattern P_UNBOUNDED = Pattern.compile(
- ".*?([\\w ]+): (\\d+)(, done)?.*", Pattern.DOTALL);
+ "^([\\w ]+): (\\d+)( |, done)?.*", Pattern.DOTALL);
private static Pattern P_BOUNDED = Pattern.compile(
- ".*?([\\w ]+):.*\\((\\d+)/(\\d+)\\).*", Pattern.DOTALL);
+ "^([\\w ]+):.*\\((\\d+)/(\\d+)\\).*", Pattern.DOTALL);
private final PacketLineIn pckIn;
@@ -84,6 +84,8 @@
private final ProgressMonitor monitor;
+ private String progressBuffer = "";
+
private String currentTask;
private int lastCnt;
@@ -160,7 +162,31 @@ private void needDataPacket() throws IOException {
}
}
- private void progress(final String msg) {
+ private void progress(String pkt) {
+ pkt = progressBuffer + pkt;
+ for (;;) {
+ final int lf = pkt.indexOf('\n');
+ final int cr = pkt.indexOf('\r');
+ final int s;
+ if (0 <= lf && 0 <= cr)
+ s = Math.min(lf, cr);
+ else if (0 <= lf)
+ s = lf;
+ else if (0 <= cr)
+ s = cr;
+ else
+ break;
+
+ final String msg = pkt.substring(0, s);
+ if (doProgressLine(msg))
+ pkt = pkt.substring(s + 1);
+ else
+ break;
+ }
+ progressBuffer = pkt;
+ }
+
+ private boolean doProgressLine(final String msg) {
Matcher matcher;
matcher = P_BOUNDED.matcher(msg);
@@ -175,7 +201,7 @@ private void progress(final String msg) {
final int cnt = Integer.parseInt(matcher.group(2));
monitor.update(cnt - lastCnt);
lastCnt = cnt;
- return;
+ return true;
}
matcher = P_UNBOUNDED.matcher(msg);
@@ -189,7 +215,10 @@ private void progress(final String msg) {
final int cnt = Integer.parseInt(matcher.group(2));
monitor.update(cnt - lastCnt);
lastCnt = cnt;
+ return true;
}
+
+ return false;
}
private String readString(final int len) throws IOException {
--
1.6.1.59.g6f6746
--
Shawn.
^ permalink raw reply related
* Re: gitweb $export_ok question
From: Thomas Amsler @ 2008-12-31 18:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git@vger.kernel.org
In-Reply-To: <6db6bed70812311013l3cf575c1y874e71e70d1dde57@mail.gmail.com>
One more question. Now, on the gitweb home page, the project name
hyper link shows up as:
authz.git/.git
where it used to be just:
authz.git/
is there a way to configure this so that it doesn't show the trailing .git?
Best,
-- Thomas
On Wed, Dec 31, 2008 at 10:13 AM, Thomas Amsler <tpamsler@ucdavis.edu> wrote:
> That did the trick. It wasn't quite clear from the documentation that the
> file defined by $export_ok has to be located in repository/.git/
>
> Thank you for your help.
>
> Best,
> -- Thomas
>
>
>
> On Wed, Dec 31, 2008 at 1:00 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>
>> Thomas Amsler wrote:
>>
>> > Thank you for your information.
>> >
>> > I have just tried that but the repository doesn't show up in gitweb
>> >
>> > - added to /etc/gitweb.conf
>> > -- $export_ok = "gitweb-export-ok"
>> > - touched the "gitweb-export-ok" file in the repository
>> > -- touch /path-to-repo/repository/authz.git/gitweb-export-ok
>> >
>> > Then gitweb reports:
>> >
>> > 404 - No projects found
>> >
>> > Does the gitweb-export-ok file need to be part of the repo so that it
>> > is
>> > tracked?
>>
>> No, gitweb-export-ok file has to be in $GIT_DIR (like description file),
>> not part of repo.
>>
>> As to "No projects found" error: what is your $projectroot? Is it
>> either "/path-to-repo/repository" or "/path-to-repo"? Is repository
>> readable and searchable for the web server user (does it have correct
>> permissions)?
>> --
>> Jakub Narebski
>> Poland
>> --
>> 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
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Sitaram Chamarty @ 2008-12-31 16:33 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LNX.1.00.0812311103000.19665@iabervon.org>
On 2008-12-31, Daniel Barkalow <barkalow@iabervon.org> wrote:
>> $ git checkout . // tidy up current commit
>> $ git checkout <version> // roll back
> Either that, or:
>
> $ git checkout <version>
> $ git checkout .
>
> (it doesn't matter whether you get rid of the local modifications and
> deletions before switching, or switch first, and then get rid of any
> remaining local modifications and deletions)
>
> You may also want:
>
> $ git clean
I think "git checkout -f <version>" will do *all* of that.
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Daniel Barkalow @ 2008-12-31 16:24 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gjfnsb$5ph$4@ger.gmane.org>
On Wed, 31 Dec 2008, Zorba wrote:
> Ok, now I'm following you, cos I just "broke" checkout again by deleting
> files from working dirs before running it.
>
> git-checkout takes into account the state of the working tree in the commit
> it is run FROM, as well as the commit it is checking out.
>
> It relies on the working tree being in synch with the commit it is run from.
> If I delete files, I screw around with this initial state.
> Files that git-checkout is relying on to be there are not copied in by it,
> so if I've deleted (or modified) those files, hard luck.
It's not relying on these files to be there; it's actually aware that
they're not there. It thinks that any modifications you've made might be
important work, and carefully preserves it.
Actually, it should be telling you the changes that it's carrying over
with lines like:
D ABC.txt
(which indicated that you've deleted ABC.txt, and it's keeping that
modification)
> I remember s/o saying git minimizes file I/O, and this whats happening here.
>
> It puts a big demand on the user, to keep their index & working dir in synch
> with whats in the commit.
The user is hopefully not going to make a lot of random undesired changes
in general. It's hard to get much done that way. If you have made changes,
you can use "git checkout ." to get the versions back from the index, or
"git checkout HEAD ." to get them back from the commit.
> Ah,
>
> $ git checkout .
>
> will restore the state of the working dir to be in synch with the CURRENT
> commit, so it will be safe to checkout other branches
>
> BINGO !!
> what I need to do is run the sequence
>
> $ git checkout . // tidy up current commit
> $ git checkout <version> // roll back
>
> n'est pas ?
Either that, or:
$ git checkout <version>
$ git checkout .
(it doesn't matter whether you get rid of the local modifications and
deletions before switching, or switch first, and then get rid of any
remaining local modifications and deletions)
You may also want:
$ git clean
To get rid of untracked files you may have around (use "git clean -x" if
you also want to get rid of files you've told git to ignore).
Incidentally, if your goal is to give someone a copy of the state as of a
particular version, you can use:
$ git archive --format=zip <commit> > version.zip
This doesn't involve your working directory at all, and just generates a
zip file out of the history. I find that this means I rarely actually care
about having a working directory that's free of random junk.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-difftool
From: Matthieu Moy @ 2008-12-31 16:04 UTC (permalink / raw)
To: David Aguilar; +Cc: git
In-Reply-To: <20081226013021.GA15414@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> The usual use case for this script is when you have either
> staged or unstaged changes and you'd like to see the changes
> in a side-by-side diff viewer (e.g. xxdiff, tkdiff, etc).
>
> git difftool [<filename>*]
Is it not a complex way of saying
GIT_EXTERNAL_DIFF=xxdiff git diff
?
(My 2 cents, and happy new year ;-)
--
Matthieu
^ permalink raw reply
* RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Daniel Barkalow @ 2008-12-31 16:00 UTC (permalink / raw)
To: Conor Rafferty; +Cc: Boyd Stephen Smith Jr., Jeff Whiteside, git
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D38@ALTMORE-SVR.altmore.local>
On Wed, 31 Dec 2008, Conor Rafferty wrote:
> And you would be wrong, IMHO. Many people have untracked files or
> directories in their working directory ('cause they are working there)
> that they don't want deleted willy-nilly. Build files, modifications
> that should be on a different branch, etc. There's another thread
> active on the list complaining that git removes too much from the
> working tree.
>
> ** An SCM should be able to cope with both use cases. In fact I make it
> easy for the SCM by deleting EVERYTHING from the working directory,
> before calling git-checkout.
In this case, git thinks you actually meant to delete those tracked files,
and does its best to not undelete them unless you ask it to get them back.
Git is very careful not to lose your changes, which is very nice most of
the time, but means that you can't make changes and expect git to lose
them.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [EGIT PATCH] Add an import wizard for Eclipse projects as part of clone
From: Shawn O. Pearce @ 2008-12-31 15:54 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1230720969-1735-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> This adds an optional page for importing Eclipse style projects
> as part of the clone operation.
>
> This patch I think, greatly simplifies getting an Eclipse based project
> into the workbench.
Yes, yes it does!
> I'm mostly interested in comments on pure bugs. E.g. know it's
> blocking when the user selects to import the projects as part of the
> clone process, I also know I'm reusing internal messages and not supplying
> NLS style constansts for all textx.
I noticed you mispelled "showImportWizard" as "showImportWizarad",
but otherwise it looks reasonable to me. I'd like to see the NLS
stuff extracted out before we apply the patch though.
The blocking part is annoying, but there isn't really a better
way to do it. What would be worse is going into the background,
then popping open a modal dialog when it completes, as it would
really disrupts the user. So just don't clone massive projects
and expect to use your workbench at the same time. :-)
--
Shawn.
^ permalink raw reply
* Re: Do moves add to repository size?
From: Simon Chiang @ 2008-12-31 15:53 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0812310717w341f05b5qeb058ff1c2db19d2@mail.gmail.com>
Great thanks! I suspected that was the case.
^ permalink raw reply
* Re: [EGIT PATCH] Remove unused NLS messages and texts
From: Shawn O. Pearce @ 2008-12-31 15:44 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1230720430-1182-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> public class CoreText extends NLS {
> - /** */
> - public static String AssumeUnchangedOperation_failed;
> -
> - /** */
> - public static String AssumeUnchangedOperation_adding;
Nope, this is used by AssumeUnchangedOperation.
--
Shawn.
^ permalink raw reply
* Re: Do moves add to repository size?
From: Alex Riesen @ 2008-12-31 15:17 UTC (permalink / raw)
To: Simon Chiang; +Cc: git
In-Reply-To: <85fafb0c0812310111s552247em5f0ca57b737aedc3@mail.gmail.com>
2008/12/31 Simon Chiang <simon.a.chiang@gmail.com>:
> Hey, I'm quite curious to know if moves/renames duplicate the file
> content in the repository (and hence grow the repository size) or if
> they just change the location of the content. I want to drastically
> reorganize a repository and I'm wondering if will double it in size.
It wont double its size, but it will grow a little: the tree objects
which contain names of the data (the file names) will be all changed.
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Boyd Stephen Smith Jr. @ 2008-12-31 15:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Conor Rafferty, Jeff Whiteside, Daniel Barkalow, git
In-Reply-To: <7v7i5hymp7.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]
On Tuesday 30 December 2008, Junio C Hamano <gitster@pobox.com> wrote
about 'Re: for newbs = little exercise / tutorial / warmup for windows and
other non-sophisticated new Git users :-) [Scanned]':
>"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
>> "git checkout <branch> <paths>" is similar to "hg revert -r <branch>
>> <paths>",
>
>No it is not.
>
>The form of the command is makes this request:
>
> Please look into that named <tree-ish>, and check out the named
> <paths> out of it to my work tree.
That seems similar to "hg revert":
Using the -r option, revert the given files or directories to their
contents as of a specific revision.
> Because the reason I want them in
> my work tree is so that I can include them as part of the next commit
> I am preparing to create in the index, please update these paths in
> my index while at it.
This part is odd to me, but does make some sense. I can only think of a
few reasons to retrieve a file from a different tree-ish without
immediately turning around and doing "git add <bar>".
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Sitaram Chamarty @ 2008-12-31 13:48 UTC (permalink / raw)
To: git
In-Reply-To: <gjfnsb$5ph$4@ger.gmane.org>
On 2008-12-31, Zorba <cr@altmore.co.uk> wrote:
> It puts a big demand on the user, to keep their index & working dir in synch
> with whats in the commit.
or they could just use "git checkout -f tag_to_goto" I
suppose...
^ 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