* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Stephan Beyer @ 2008-10-29 1:01 UTC (permalink / raw)
To: Jeff King; +Cc: David Symonds, git, gitster
In-Reply-To: <20081029003931.GA7291@sigill.intra.peff.net>
Hi,
> > --- /dev/null
> > +++ b/git-staged.sh
> > @@ -0,0 +1,2 @@
> > +#!/bin/sh
> > +exec git diff --cached $*
>
> This is broken for arguments with spaces. Use "$@" instead.
>
> But I think this isn't a serious patch anyway, so we are probably
> wasting too much time on it. ;P
I'm still not understanding, what it's for.
Usability? Because doing
git config --global alias.staged 'diff --cached'
is lame?
Regards,
Stephan
PS: Btw, if ever meant serious, it's missing an insertion into
command-list.txt and serious documentation.
But I think you know that. :-)
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* exporting the last N days of a repository
From: Geoff Russell @ 2008-10-29 1:01 UTC (permalink / raw)
To: git
I want to export "the last N days" of a repository to create a copy
which has an origin which is
the state of the repository N days ago and has all the history between
then and now.
Can fast-export do this?
Cheers,
Geoff Russell
^ permalink raw reply
* [PATCH] git show <tree>: show mode and hash, and handle -r
From: Johannes Schindelin @ 2008-10-29 1:09 UTC (permalink / raw)
To: gitster, git, schacon
Now, git show <tree> shows some more information, and with the -r option,
it recurses into subdirectories.
Requested by Scott Chacon.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
The only quirk is the command line parsing for -r: we cannot use
DIFF_OPT_TST(&rev.diffopt, RECURSIVE), because that is switched
on not only by cmd_log_init(), but implicitly by
diff_setup_done(), because FORMAT_PATCH is selected by git-show.
builtin-log.c | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 3796dda..b00d353 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -297,8 +297,12 @@ static int show_tree_object(const unsigned char *sha1,
const char *base, int baselen,
const char *pathname, unsigned mode, int stage, void *context)
{
- printf("%s%s\n", pathname, S_ISDIR(mode) ? "/" : "");
- return 0;
+ int *recursive = context;
+ printf("%06o %s %.*s%s%s\n", mode,
+ find_unique_abbrev(sha1, DEFAULT_ABBREV),
+ baselen, base,
+ pathname, S_ISDIR(mode) ? "/" : "");
+ return *recursive ? READ_TREE_RECURSIVE : 0;
}
int cmd_show(int argc, const char **argv, const char *prefix)
@@ -306,6 +310,7 @@ int cmd_show(int argc, const char **argv, const char *prefix)
struct rev_info rev;
struct object_array_entry *objects;
int i, count, ret = 0;
+ int tree_recursive = 0;
git_config(git_log_config, NULL);
@@ -319,6 +324,11 @@ int cmd_show(int argc, const char **argv, const char *prefix)
rev.always_show_header = 1;
rev.ignore_merges = 0;
rev.no_walk = 1;
+ for (i = 1; i < argc && strcmp(argv[i], "--"); i++)
+ if (!strcmp(argv[i], "-r")) {
+ tree_recursive = 1;
+ break;
+ }
cmd_log_init(argc, argv, prefix, &rev);
count = rev.pending.nr;
@@ -348,7 +358,7 @@ int cmd_show(int argc, const char **argv, const char *prefix)
name,
diff_get_color_opt(&rev.diffopt, DIFF_RESET));
read_tree_recursive((struct tree *)o, "", 0, 0, NULL,
- show_tree_object, NULL);
+ show_tree_object, &tree_recursive);
break;
case OBJ_COMMIT:
rev.pending.nr = rev.pending.alloc = 0;
--
1.6.0.2.763.g72663
^ permalink raw reply related
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Jeff King @ 2008-10-29 1:05 UTC (permalink / raw)
To: Stephan Beyer; +Cc: David Symonds, git, gitster
In-Reply-To: <20081029010107.GB12065@leksak.fem-net>
On Wed, Oct 29, 2008 at 02:01:07AM +0100, Stephan Beyer wrote:
> I'm still not understanding, what it's for.
> Usability? Because doing
> git config --global alias.staged 'diff --cached'
> is lame?
You are missing some of the context, which is that we just had a big
in-person debate about how the staged nomenclature is confusing. We call
things "cached", "staged", and "index", depending on the command.
So this is an attempt to rectify that.
-Peff
^ permalink raw reply
* Encoding problems using git-svn
From: James North @ 2008-10-29 3:14 UTC (permalink / raw)
To: git
Hi,
I'm using git-svn on a system with ISO-8859-1 encoding. The problem is
when I try to use "git svn dcommit" to send changes to a remote svn
(also ISO-8859-1).
Seems like git-svn is sending commit messages with utf-8 (just a
guessing...) and they look bad on the remote svn log. E.g. "Ca?\241a
de cami?\243n"
I have tried using i18n.commitencoding=ISO-8859-1 as suggested by the
warning when doing "git svn dcommit" but messages still are sent with
wrong encoding.
I'm mising something?
Thanks everyone
^ permalink raw reply
* Re: git export to svn
From: Warren Harris @ 2008-10-29 3:40 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: J.H., git
In-Reply-To: <20081026171519.GD3612@atjola.homenet>
Björn - Thanks again for your help...
On Oct 26, 2008, at 10:15 AM, Björn Steinbrink wrote:
>>
>> Since I'm trying to export my git repo to svn, the svn repo is
>> completely empty.
>
> OK, the "r58084" made me think that your code is based on something
> that
> is already in the SVN repo. But apperently, that's just a shared svn
> repo, right?
Right
>
> This should do and uses a graft to simplify the process a bit:
>
> Initialize git-svn:
> git svn init -s --prefix=svn/ https://svn/svn/SANDBOX/warren/test2
>
> The --prefix gives you remote tracking branches like "svn/trunk" which
> is nice because you don't get ambiguous names if you call your local
> branch just "trunk" then. And -s is a shortcut for the standard
> trunk/tags/branches layout.
>
>
> Fetch the initial stuff from svn:
> git svn fetch
>
> Now look up the hash of your root commit (should show a single
> commit):
> git rev-list --parents master | grep '^.\{40\}$'
>
> Then get the hash of the empty trunk commit:
> git rev-parse svn/trunk
>
> Create the graft:
> echo <root-commit-hash> <svn-trunk-commit-hash> >> .git/info/grafts
>
> Now, "gitk" should show svn/trunk as the first commit on which your
> master branch is based.
>
> Make the graft permanent:
> git filter-branch -- ^svn/trunk --all
>
> Drop the graft:
> rm .git/info/grafts
>
> gitk should still show svn/trunk in the ancestry of master
>
> Linearize your history on top of trunk:
> git svn rebase
>
> And now "git svn dcommit -n" should tell you that it is going to
> commit
> to trunk.
This worked. The only downside was that all of our svn users
subscribed to the checkins mailing list got a flood of messages from
me, but otherwise it worked like a charm. (I see that the original git
commit dates were not preserved in svn, but that doesn't matter too
much...)
>
>
>
> Alternatively, if rebase gives just too many conflicts, you can do:
>
> git svn init -s --prefix=svn/ https://svn/svn/SANDBOX/warren/test2
> git svn fetch
> git checkout -b trunk svn/trunk
> git merge master
> git svn dcommit
>
> That will just create a single huge commit in svn. But the history
> will
> be retained in git. You can then work on the new "trunk" branch or
> move
> your master branch, so it points to the same commit as trunk and then
> drop the "trunk" branch or whatever. It just matters that your new
> work
> is based upon the dcommited merge commit, so "svn/trunk" is in your
> branch's history.
This didn't work for me. (I had tried the first procedure on a test
tree, then this one on a different test tree, and ultimately went back
to the first procedure for my real git repo.) I ended up with an empty
svn tree. For the record, here's what happened:
$ git svn fetch
W: Ignoring error from SVN, path probably does not exist: (175002): RA
layer request failed: REPORT of '/svn/!svn/bc/100': Could not read
chunk size: Secure connection truncated (https://svn)
W: Do not be alarmed at the above message git-svn is just searching
aggressively for old history.
This may take a while on large repositories
r58382 = 9b9d5f01e4a3aca714eb5f61a9f05ab657cc7bc5 (svn/trunk)
Checked out HEAD:
https://svn/svn/test3/trunk r58382
$ git checkout -b trunk svn/trunk
Switched to a new branch "trunk"
$ git merge master
Already up-to-date.
$ git svn dcommit
Committing to https://svn/svn/test3/trunk ...
$ cd tmp/svn-test3/
$ svn co https://svn/svn/test3/trunk
Checked out revision 58385.
$ ls -al trunk/
total 88
drwxr-xr-x 11 warren staff 374 Oct 28 18:15 .
drwxr-xr-x 3 warren staff 102 Oct 28 18:15 ..
drwxr-xr-x 9 warren staff 306 Oct 28 18:15 .svn
Now one thing that might be different than what you prescribed is that
our svn repo uses different conventions for branches and tags, so I
didn't use 'git svn init -s', although I doubt that matters.
Anyway, I'm up and running in svn with your first procedure, so my
problem is solved. Thanks.
Warren
^ permalink raw reply
* [PATCH 1/1] diff: support making output friendlier for fine, grand users
From: Petr Baudis @ 2008-10-29 5:23 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Scott Chacon, Tom Preston-Werner, Jeff King,
J.H., Sam Vilain, Christian Couder, Kai Blin
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Scott Chacon <schacon@gmail.com>
Signed-off-by: Tom Preston-Werner <tom@github.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: J.H. <warthog19@eaglescrag.net>
Signed-off-by: Sam Vilain <sam@vilain.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Kai Blin <kai@samba.org>
Acked-by: Petr Baudis <pasky@suse.cz>
Enabled-by: Cascade "Smooth" Amber <clarity@tiedhouse.com>
---
diff.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index e368fef..0e2c14a 100644
--- a/diff.c
+++ b/diff.c
@@ -2489,6 +2489,9 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
else if (!prefixcmp(arg, "--output=")) {
options->file = fopen(arg + strlen("--output="), "w");
options->close_file = 1;
+ }
+ else if (!strcmp(arg, "--pirate")) {
+ printf("Arrrr! These be yer fine changes, me 'earty!!\n");
} else
return 0;
return 1;
--
1.5.4.5
^ permalink raw reply related
* Re: [PATCH] git show <tree>: show mode and hash, and handle -r
From: Johannes Sixt @ 2008-10-29 7:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git, schacon
In-Reply-To: <alpine.DEB.1.00.0810290207330.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin schrieb:
> Now, git show <tree> shows some more information, and with the -r option,
> it recurses into subdirectories.
>
> Requested by Scott Chacon.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> The only quirk is the command line parsing for -r: we cannot use
> DIFF_OPT_TST(&rev.diffopt, RECURSIVE), because that is switched
> on not only by cmd_log_init(), but implicitly by
> diff_setup_done(), because FORMAT_PATCH is selected by git-show.
This comment should for sure go into the commit message.
-- Hannes
^ permalink raw reply
* nice google video on "contributing with git"
From: Christian MICHON @ 2008-10-29 7:24 UTC (permalink / raw)
To: Git Mailing List, Johannes Schindelin
taken 2 days ago apparently :)
http://www.youtube.com/watch?v=j45cs5_nY2k
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: [VOTE] git versus mercurial
From: Miles Bader @ 2008-10-29 8:15 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <ge70nl$l6t$1@ger.gmane.org>
walt <w41ter@gmail.com> writes:
> The official vote was 19 to 19, plus one for perforce and one
> for svn. Matt has proposed a primary git repository and a mirror
> in hg, and that's being debated now.
Boy, whoever has the popcorn concession must be making a fortune!
-Miles
--
Infancy, n. The period of our lives when, according to Wordsworth, 'Heaven
lies about us.' The world begins lying about us pretty soon afterward.
^ permalink raw reply
* Do most people feel tracking branches useful?
From: Liu Yubao @ 2008-10-29 8:55 UTC (permalink / raw)
To: git
Hi,
I often feel tracking branches are useless to me, because there are remote
branches and I work on my private branch in most time.
repos
|
|-- my (private branch, do my dirty work)
|-- master (tracking branch)
|-- origin/master (remote branch)
To avoid conflict when execute `git pull` and make the history linear, I work
on branch "my" instead of "master". Here is my work flow:
1) use `git fetch` or `git remote update` to synchronize branch "origin/master"
with branch "master" in remote repository;
2) create a new private branch to polish my commits and rebase it against
"origin/master";
3) at last push this new branch to the remote repository or ask the upstream
developer to fetch it(no `git pull` because we want history as linear as possible).
I don't want to bother with the tracking branch "master", it's identical
with "origin/master". Because `git checkout -b xxx <remote_branch>`
will create a tracking branch "xxx" by default, so my question is:
do most people feel tracking branches useful?
BTW: I feel the terminalogy "remote branch" is confused, because I must
synchronize it with `git fetch`. I feel it's better to call it "tracking
branch" // seems will lead to bigger confusion to experienced git users:-(
^ permalink raw reply
* Re: Do most people feel tracking branches useful?
From: Miles Bader @ 2008-10-29 9:08 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <49082514.9050405@gmail.com>
Liu Yubao <yubao.liu@gmail.com> writes:
> do most people feel tracking branches useful?
Extremely useful. I usually keep local branches closely synchronized
with a remote "central" version, and tracking branches make the frequent
push/pull much more convenient.
I often delete the default local "master" branch though, and have only
one local branch per working directory (and like you, use origin/... for
much interbranch synchronization, e.g. rebasing).
-Miles
--
"Whatever you do will be insignificant, but it is very important that
you do it." Mahatma Gandhi
^ permalink raw reply
* Re: Do most people feel tracking branches useful?
From: Andreas Ericsson @ 2008-10-29 9:48 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <49082514.9050405@gmail.com>
Liu Yubao wrote:
> Hi,
>
> I often feel tracking branches are useless to me, because there are remote
> branches and I work on my private branch in most time.
>
> repos
> |
> |-- my (private branch, do my dirty work)
> |-- master (tracking branch)
> |-- origin/master (remote branch)
>
> To avoid conflict when execute `git pull` and make the history linear, I work
> on branch "my" instead of "master". Here is my work flow:
>
Use "git fetch" instead of "git pull" and you won't need the 'my' branch.
If you use "git pull --rebase" you won't need to bother at all.
> 1) use `git fetch` or `git remote update` to synchronize branch "origin/master"
> with branch "master" in remote repository;
> 2) create a new private branch to polish my commits and rebase it against
> "origin/master";
> 3) at last push this new branch to the remote repository or ask the upstream
> developer to fetch it(no `git pull` because we want history as linear as possible).
>
> I don't want to bother with the tracking branch "master", it's identical
> with "origin/master".
Not unless you "git pull" when there's only fast-forward changes.
> Because `git checkout -b xxx <remote_branch>`
> will create a tracking branch "xxx" by default, so my question is:
> do most people feel tracking branches useful?
>
I use them all the time. They're immensely useful to me.
I can't understand why you're working so hard for a linear history, but perhaps
that's just an effect of only having leaf developers. I also can't understand
why you'd want to sync with upstream at all if you're just working on a single
feature/bugfix at the time, since you'd probably be better off by just completing
that single feature in your own time and doing "git pull --rebase && git push"
when you're done.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Do most people feel tracking branches useful?
From: Liu Yubao @ 2008-10-29 9:58 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <buoprlj4vle.fsf@dhapc248.dev.necel.com>
Miles Bader wrote:
> Liu Yubao <yubao.liu@gmail.com> writes:
>> do most people feel tracking branches useful?
>
> Extremely useful. I usually keep local branches closely synchronized
> with a remote "central" version, and tracking branches make the frequent
> push/pull much more convenient.
>
In my work flow, I don't keep changes in local branch for long time,
I rebase it regularly and push them to central branch or discard them
if the upstream rejects.
You are right, I realize tracking branches is useful for people who keeps
local changes for long time and track the upstream branch at the same time.
But I guess an auto-rebasing policy is more sensible than auto-merging policy
because I won't get many useless "Merge branch 'xxx' of ..." messages in the
history.
Another problem about tracking branch is `git pull` won't merge tracking branch
with remote branch when the current branch isn't tracking branch, it warns me
"You asked me to pull without telling me which branch you ....". It's not
convenient to checkout tracking branch and execute `git pull` then switch back
to my working branch.
^ permalink raw reply
* Re: Do most people feel tracking branches useful?
From: Björn Steinbrink @ 2008-10-29 10:03 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <49082514.9050405@gmail.com>
On 2008.10.29 16:55:48 +0800, Liu Yubao wrote:
> Hi,
>
> I often feel tracking branches are useless to me, because there are remote
> branches and I work on my private branch in most time.
>
> repos
> |
> |-- my (private branch, do my dirty work)
> |-- master (tracking branch)
> |-- origin/master (remote branch)
Actually, origin/master is the "[remote] tracking branch". master is
just a branch that has config settings for "git pull" defaults. ;-)
"Remote branches" are the actual branches on a remote repository.
> To avoid conflict when execute `git pull` and make the history linear, I work
> on branch "my" instead of "master". Here is my work flow:
>
> 1) use `git fetch` or `git remote update` to synchronize branch
> "origin/master" with branch "master" in remote repository;
> 2) create a new private branch to polish my commits and rebase it against
> "origin/master";
> 3) at last push this new branch to the remote repository or ask the upstream
> developer to fetch it(no `git pull` because we want history as linear
> as possible).
git pull --rebase
> I don't want to bother with the tracking branch "master", it's identical
> with "origin/master". Because `git checkout -b xxx <remote_branch>`
> will create a tracking branch "xxx" by default, so my question is:
> do most people feel tracking branches useful?
Tracking branches (origin/* etc.) are very useful :-) And branches that
have "git pull" defaults (what you called "tracking branch") are also
useful.
In your case, you probably want:
git checkout -b my-stuff origin/master
git config branch.my-stuff.rebase true
and then you can do:
git pull
Instead of:
git fetch origin
git rebase origin/master
You can also setup branch.autosetuprebase, to automatically get the
rebase setup, so you can skip the call to "git config" above.
And you can just delete the "master" branch if you don't use it. There's
nothing that forces you to keep any branches around that you don't use.
But that doesn't affect the usefulness of tracking branches or branches
that have "git pull" defaults :-)
> BTW: I feel the terminalogy "remote branch" is confused, because I must
> synchronize it with `git fetch`. I feel it's better to call it "tracking
> branch" // seems will lead to bigger confusion to experienced git users:-(
See above, that's already the case ;-)
Björn
^ permalink raw reply
* Re: Do most people feel tracking branches useful?
From: Liu Yubao @ 2008-10-29 10:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <49083166.7090804@op5.se>
Andreas Ericsson wrote:
> Liu Yubao wrote:
>
> Use "git fetch" instead of "git pull" and you won't need the 'my' branch.
> If you use "git pull --rebase" you won't need to bother at all.
>
Thank you very much, I didn't know the "--rebase" option, now I learn
the 'branch.<name>.rebase' configuration too by "git help pull".
[...snip...]
>
> I can't understand why you're working so hard for a linear history, but
> perhaps
> that's just an effect of only having leaf developers. I also can't
> understand
You got it exactly, we are leaf developers and make enhancement mostly,
we don't want the upstream branch full of merging commit for many
not so major changes. I remember keeping linear history is recommended
in git's documentation.
> why you'd want to sync with upstream at all if you're just working on a
> single
> feature/bugfix at the time, since you'd probably be better off by just
> completing
> that single feature in your own time and doing "git pull --rebase && git
> push"
> when you're done.
I only sync when I have finished my enhancement, I don't like merging
when pull.
Yes, I'd better use "git pull --rebase", "pull" is a wonderful command:
pull = fetch + merge, pull --rebase = fetch + rebase, wow!
^ permalink raw reply
* Re: [StGit PATCH] Tutorial: Importing patches
From: Karl Hasselström @ 2008-10-29 10:28 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0810281509r109ee2dby51ee13a250700012@mail.gmail.com>
On 2008-10-28 22:09:52 +0000, Catalin Marinas wrote:
> 2008/10/28 Karl Hasselström <kha@treskal.com>:
> > +The e-mail should be in standard Git mail format (which is what e.g.
> > +stglink:mail[] produces) -- that is, with the patch in-line in the
> > +mail, not attached. The authorship info is taken from the mail
> > +headers, and the commit message is read from the 'Subject:' line and
> > +the mail body.
>
> It actually supports importing diffs from attachments as well as
> long as they are text/plain (the description is expected in the mail
> body).
Yeah, I had a vague recollection that that might be the case, but the
test suite doesn't cover it, and I've actually tried it a few times
and it's never worked for me.
> Anyway, I think we don't have to mention this in the tutorial as
> most people would use the Git mail format anyway.
Yes.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] Use find instead of perl in t5000 to get file modification time
From: Alex Riesen @ 2008-10-29 10:38 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Jeff King, René Scharfe
[-- Attachment #1: Type: text/plain, Size: 909 bytes --]
The test "validate file modification time" was broken on admittedly broken
combination of Windows, Cygwin, and ActiveState Perl. Something (I blame
ActiveState) of the three is very confused about what time zone
to use for the modification time.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
I could not find what exactly does the ActiveState's Perl use for its stat
implementation (and honestly, have no motivation to look harder).
It seems to honor TZ, but the produced time does not seem to be either
local or GMT.
There can be a problem with "-printf": Open Group SUS does not specify
-printf for find(1), so it is probably a problem somewhere. I just don't know.
There is always a fallback, which is to write a small program which calls
native stat(2). Or modify test-chmtime to just print mtime when asked.
t/t5000-tar-tree.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Use-find-instead-of-perl-in-t5000-to-get-file-modifi.patch --]
[-- Type: text/x-diff; name=0001-Use-find-instead-of-perl-in-t5000-to-get-file-modifi.patch, Size: 1470 bytes --]
From 1bd8a9445d9bba463fb1edb758d7760fbf53b03a Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Wed, 29 Oct 2008 10:22:15 +0100
Subject: [PATCH] Use find instead of perl in t5000 to get file modification time
The test was broken on admittedly broken combination of Windows, Cygwin,
and ActiveState Perl.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t5000-tar-tree.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 0f27d73..4eabebd 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -26,6 +26,8 @@ commit id embedding:
. ./test-lib.sh
UNZIP=${UNZIP:-unzip}
+TZ=GMT
+export TZ
SUBSTFORMAT=%H%n
@@ -54,7 +56,7 @@ test_expect_success \
find a -type l | xargs git update-index --add &&
treeid=`git write-tree` &&
echo $treeid >treeid &&
- git update-ref HEAD $(TZ=GMT GIT_COMMITTER_DATE="2005-05-27 22:00:00" \
+ git update-ref HEAD $(GIT_COMMITTER_DATE="2005-05-27 22:00:00" \
git commit-tree $treeid </dev/null)'
test_expect_success \
@@ -90,7 +92,7 @@ test_expect_success \
'validate file modification time' \
'mkdir extract &&
"$TAR" xf b.tar -C extract a/a &&
- perl -e '\''print((stat("extract/a/a"))[9], "\n")'\'' >b.mtime &&
+ find extract/a/a -printf "%T@\\n" >b.mtime &&
echo "1117231200" >expected.mtime &&
diff expected.mtime b.mtime'
--
1.6.0.3.549.gb475d
^ permalink raw reply related
* Re: Do most people feel tracking branches useful?
From: Liu Yubao @ 2008-10-29 10:38 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20081029100313.GP3612@atjola.homenet>
Björn Steinbrink wrote:
> On 2008.10.29 16:55:48 +0800, Liu Yubao wrote:
>> Hi,
>>
>> I often feel tracking branches are useless to me, because there are remote
>> branches and I work on my private branch in most time.
>>
>> repos
>> |
>> |-- my (private branch, do my dirty work)
>> |-- master (tracking branch)
>> |-- origin/master (remote branch)
>
> Actually, origin/master is the "[remote] tracking branch". master is
> just a branch that has config settings for "git pull" defaults. ;-)
>
> "Remote branches" are the actual branches on a remote repository.
>
Oh, I'm misguided by the --track option, thank you for clarifying it!
> In your case, you probably want:
> git checkout -b my-stuff origin/master
> git config branch.my-stuff.rebase true
>
> and then you can do:
> git pull
>
> Instead of:
> git fetch origin
> git rebase origin/master
>
> You can also setup branch.autosetuprebase, to automatically get the
> rebase setup, so you can skip the call to "git config" above.
A new config setting, git amazes me again @_@
It's great, thanks!
>
> And you can just delete the "master" branch if you don't use it. There's
> nothing that forces you to keep any branches around that you don't use.
> But that doesn't affect the usefulness of tracking branches or branches
> that have "git pull" defaults :-)
>
>> BTW: I feel the terminalogy "remote branch" is confused, because I must
>> synchronize it with `git fetch`. I feel it's better to call it "tracking
>> branch" // seems will lead to bigger confusion to experienced git users:-(
>
> See above, that's already the case ;-)
>
Got it, --rebase and config.<branch>.rebase and config.autosetuprebase, thank
you again:-)
> Björn
>
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Wincent Colaiuta @ 2008-10-29 10:59 UTC (permalink / raw)
To: David Symonds; +Cc: git, gitster, Jeff King
In-Reply-To: <1225241048-99267-1-git-send-email-dsymonds@gmail.com>
El 29/10/2008, a las 1:44, David Symonds escribió:
> +SCRIPT_SH += git-staged.sh
Isn't this exactly what aliases are for?
git config --global alias.staged "diff --cached"
(Rather than adding yet another command...)
Wincent
^ permalink raw reply
* Re: Do most people feel tracking branches useful?
From: Andreas Ericsson @ 2008-10-29 11:53 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <49083957.2060702@gmail.com>
Liu Yubao wrote:
> Andreas Ericsson wrote:
>> Liu Yubao wrote:
>>
>> Use "git fetch" instead of "git pull" and you won't need the 'my' branch.
>> If you use "git pull --rebase" you won't need to bother at all.
>>
> Thank you very much, I didn't know the "--rebase" option, now I learn
> the 'branch.<name>.rebase' configuration too by "git help pull".
>
> [...snip...]
>
>> I can't understand why you're working so hard for a linear history, but
>> perhaps
>> that's just an effect of only having leaf developers. I also can't
>> understand
> You got it exactly, we are leaf developers and make enhancement mostly,
> we don't want the upstream branch full of merging commit for many
> not so major changes. I remember keeping linear history is recommended
> in git's documentation.
>
That should probably be rephrased to "Think before you merge" or something
like that. Keeping history linear provides very little value in itself,
but mindlessly criss-cross-merging makes history difficul to review for
no good reason. Any perceived value of mindless merging is quickly
nullified once one starts looking at "git rerere".
The only time you'll run into problems with non-linear history is when
you're bisecting, and bisection ends up at a merge-commit where all the
merged branhces tips' pre-merge work flawlessly, but the merge-commit
itself introduces breakage by erroneously resolving a conflict, or by
introducing changes of its own (git commit --amend, fe).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Do most people feel tracking branches useful?
From: Miles Bader @ 2008-10-29 13:29 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <490833AD.70806@gmail.com>
On Oct 29, 2008 6:58pm, Liu Yubao <yubao.liu@gmail.com> wrote:
> > Extremely useful. I usually keep local branches closely synchronized
> > with a remote "central" version, and tracking branches make the frequent
> > push/pull much more convenient.
>
> In my work flow, I don't keep changes in local branch for long time,
> I rebase it regularly and push them to central branch or discard them
> if the upstream rejects.
>
> You are right, I realize tracking branches is useful for people who keeps
> local changes for long time and track the upstream branch at the same
> time.
I don't keep local changes for a long time, I push daily. The local
tracking branch and the corresponding remote branch are basically copies of
each other, in different locations. I also do regularly rebasing, but
against a _different_ remote branch.
There are never merge commits, because all merges done by pull are
fast-forwards. If I were to push changes from multiple working directories
to the central location, I'd have to be more careful about the pull-merging
-- a rebase-on-pull as you suggest would be useful -- but I generally don't.
-Miles
--
Do not taunt Happy Fun Ball.
^ permalink raw reply
* Re: git bisect view's use of DISPLAY environment variable in Cygwin
From: Hannu Koivisto @ 2008-10-29 13:31 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0810290144450.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I submitted a patch a while ago, saying
>
> bisect view: call gitk if Cygwin's SESSIONNAME variable is set
>
> See
> http://repo.or.cz/w/git/dscho.git?a=commitdiff;h=a2637a3a003646c69ab5a6b85f0ee1bfac15e0b0
Unfortunately this approach doesn't seem to work if you run git
bisect view from, say, cmd (probably applies to other non-Cygwin
shells as well). I'm puzzled as to why this happens; I wrote a
simple shell script that echoes $SESSIONNAME and no matter how I
run it from cmd it always echoes Console.
It's certainly better than nothing and I wouldn't mind it ending up
to the official git but...
--
Hannu
^ permalink raw reply
* Re: [PATCH] git show <tree>: show mode and hash, and handle -r
From: Johannes Schindelin @ 2008-10-29 14:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git, schacon
In-Reply-To: <49080EA4.9080404@viscovery.net>
Hi,
On Wed, 29 Oct 2008, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > Now, git show <tree> shows some more information, and with the -r option,
> > it recurses into subdirectories.
> >
> > Requested by Scott Chacon.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> > The only quirk is the command line parsing for -r: we cannot use
> > DIFF_OPT_TST(&rev.diffopt, RECURSIVE), because that is switched
> > on not only by cmd_log_init(), but implicitly by
> > diff_setup_done(), because FORMAT_PATCH is selected by git-show.
>
> This comment should for sure go into the commit message.
Fair enough.
Junio, you want me to resend?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Brandon Casey @ 2008-10-29 14:33 UTC (permalink / raw)
To: Jeff King; +Cc: Stephan Beyer, David Symonds, git, gitster
In-Reply-To: <20081029010534.GA8833@sigill.intra.peff.net>
Jeff King wrote:
> On Wed, Oct 29, 2008 at 02:01:07AM +0100, Stephan Beyer wrote:
>
>> I'm still not understanding, what it's for.
>> Usability? Because doing
>> git config --global alias.staged 'diff --cached'
>> is lame?
>
> You are missing some of the context,
Yeah, it would have been nice if there was audio.
Anyone take minutes, possibly?
btw the term "staged" makes perfect sense to me, whereas "cached"
was not intuitively obvious to me.
-brandon
^ 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