* 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
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Pascal Obry @ 2008-10-29 14:58 UTC (permalink / raw)
To: David Symonds; +Cc: git, gitster
In-Reply-To: <1225237145-95435-1-git-send-email-dsymonds@gmail.com>
What about :
$ git config --global alias.staged "diff --cached"
I'm using this since some time.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Johannes Schindelin @ 2008-10-29 15:08 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: David Symonds, git, gitster, Jeff King
In-Reply-To: <C0BD1E4B-130F-4A16-8865-8EEABE1431FD@wincent.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 859 bytes --]
Hi,
On Wed, 29 Oct 2008, Wincent Colaiuta wrote:
> 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...)
The difference being, of course, that we do not ship default aliases (and
neither do we plan to...).
So saying "this is what aliases are for" you ask for _newbies_ to add it
for themselves. We are talking the same newbies who should be helped by
that command, and typically do not know that there are Git aliases yet.
Even worse, just sum the times it takes everybody to make that alias, and
then compare with the time it would take to include something like David
posted in git.git. It should be obvious that the time balance is
absolutely horrible.
Ciao,
Dscho
^ permalink raw reply
* Re: exporting the last N days of a repository
From: Johannes Schindelin @ 2008-10-29 15:10 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0810281801l29253e02g95c7a6851c4c4db3@mail.gmail.com>
Hi,
On Wed, 29 Oct 2008, Geoff Russell wrote:
> 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?
Yes. See the --since=... option.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Jeff King @ 2008-10-29 15:19 UTC (permalink / raw)
To: Brandon Casey; +Cc: Stephan Beyer, David Symonds, git, gitster
In-Reply-To: <HUCQtsE3HvgGu_KDktGNx0KyijzaFKOESHnzFagEbf4erQlMxjgVNQ@cipher.nrlssc.navy.mil>
On Wed, Oct 29, 2008 at 09:33:08AM -0500, Brandon Casey wrote:
> > You are missing some of the context,
>
> Yeah, it would have been nice if there was audio.
> Anyone take minutes, possibly?
There's no audio. Some of the slides will be available. I took notes on
at least one of the discussions, which I will try to summarize and post.
And I think some of the discussion will end up as patches, which will
hopefully provide full justification in their commit messages. ;)
-Peff
^ permalink raw reply
* Re: [PATCH 1/1] diff: support making output friendlier for fine, grand users
From: Johannes Schindelin @ 2008-10-29 15:28 UTC (permalink / raw)
To: David Brown
Cc: Petr Baudis, git, Scott Chacon, Tom Preston-Werner, Jeff King,
J.H., Sam Vilain, Christian Couder, Kai Blin
In-Reply-To: <20081029150731.GA9942@linode.davidb.org>
Hi,
On Wed, 29 Oct 2008, David Brown wrote:
> On Tue, Oct 28, 2008 at 10:23:52PM -0700, Petr Baudis wrote:
>
> >+ }
> >+ else if (!strcmp(arg, "--pirate")) {
> >+ printf("Arrrr! These be yer fine changes, me 'earty!!\n");
>
> We need to wait until Sept 19 to apply this patch, however.
We could back-date it, of course.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Stephan Beyer @ 2008-10-29 15:22 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Wincent Colaiuta, David Symonds, git, gitster, Jeff King
In-Reply-To: <alpine.DEB.1.00.0810291604200.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Hi,
Johannes Schindelin wrote:
> So saying "this is what aliases are for" you ask for _newbies_ to add it
> for themselves. We are talking the same newbies who should be helped by
> that command, and typically do not know that there are Git aliases yet.
I'm not sure if yet more commands really help newbies.
I *see* the problem that talking about the index, the cache and the staging
area can be difficult to newbies. But then I'd rather vote for "git diff
--staged" (instead of --cached) or "git show --staged" (both make sense
in some way).
Perhaps it is even sufficient to add a help text to "git status", like
this:
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
+# (use "git diff --cached" to see a diff of staged files)
For me, a "git staged" feels wrong without a "git stage" (alias for
"git add") and "git unstage <file>" (alias for "git reset <file>").
And I think the list of examples can easily be continued.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH 1/1] diff: support making output friendlier for fine, grand users
From: David Brown @ 2008-10-29 15:07 UTC (permalink / raw)
To: Petr Baudis
Cc: git, Johannes Schindelin, Scott Chacon, Tom Preston-Werner,
Jeff King, J.H., Sam Vilain, Christian Couder, Kai Blin
In-Reply-To: <1225257832-29086-1-git-send-email-pasky@suse.cz>
On Tue, Oct 28, 2008 at 10:23:52PM -0700, Petr Baudis wrote:
>+ }
>+ else if (!strcmp(arg, "--pirate")) {
>+ printf("Arrrr! These be yer fine changes, me 'earty!!\n");
We need to wait until Sept 19 to apply this patch, however.
David
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Johannes Schindelin @ 2008-10-29 15:48 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Wincent Colaiuta, David Symonds, git, gitster, Jeff King
In-Reply-To: <20081029152202.GA10029@leksak.fem-net>
Hi,
On Wed, 29 Oct 2008, Stephan Beyer wrote:
> For me, a "git staged" feels wrong without a "git stage" (alias for "git
> add") and "git unstage <file>" (alias for "git reset <file>"). And I
> think the list of examples can easily be continued.
http://article.gmane.org/gmane.comp.version-control.git/99340
Thanks,
Dscho
^ 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