* Re: git stash list with more than 10 items?
From: Jeff King @ 2009-10-12 17:52 UTC (permalink / raw)
To: Jef Driesen; +Cc: git
In-Reply-To: <havj2n$d85$1@ger.gmane.org>
On Mon, Oct 12, 2009 at 05:47:34PM +0200, Jef Driesen wrote:
> Is it possible to make "git stash list" show more than 10 items?
Try "git stash list -30".
Stash listing is internally just "git log -g refs/stash", so you can
pass any formatting or limiting arguments you want there (see the git
log documentation for ideas). If no arguments are given, we pass "-10".
-Peff
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: sylvain @ 2009-10-12 17:59 UTC (permalink / raw)
To: git
In-Reply-To: <20091012012826.7sffggwmm8sk0cc8@webmail.demarque.qc.ca>
Hello there. I know I was being goofy, but here is the real down to
earth question :
Is there a known bug/feature that prevents Git from being used at "/"?
It seems that there is a problem either at "git init" or "git add"
when the repository is located at "/.git". (Git 1.6.4.4, see example
below)
Thank you!
Quoting sylvain@demarque.qc.ca:
> Git is good, Git is great! All praise the Git! :-D
>
> What do you people think about this strange phenomena?
>
> localhost / # git --version
> git version 1.6.4.4
>
> localhost / # git init
> Initialized empty Git repository in //.git/
>
> localhost / # cd etc
> localhost etc # git add X11/xorg.conf
> fatal: pathspec 'etc/X11/xorg.conf' did not match any files
>
> Aside from the obvious question of why would I want to Git the whole
> tree ("But all files deserve the Holy Presence of the Git!"), why does
> Git refuse the love offering from "/etc/X11/xorg.conf"? Is it because
> it contains font directory configurations?
>
> Commit and [ENTER] to all,
>
> S! :-)
> --
> 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: Git: "No you can't handle my root!" (?)
From: Steven Noonan @ 2009-10-12 18:06 UTC (permalink / raw)
To: sylvain; +Cc: git
In-Reply-To: <20091012135910.ujqifycf9cwsk4ss@webmail.demarque.qc.ca>
I've had this problem too, but I eventually realized it was git's way
of telling me I shouldn't do that. But even so, it'd be good if we
_could_.
- Steven
On Mon, Oct 12, 2009 at 10:59 AM, <sylvain@demarque.qc.ca> wrote:
> Hello there. I know I was being goofy, but here is the real down to
> earth question :
>
> Is there a known bug/feature that prevents Git from being used at "/"?
> It seems that there is a problem either at "git init" or "git add"
> when the repository is located at "/.git". (Git 1.6.4.4, see example
> below)
>
> Thank you!
>
> Quoting sylvain@demarque.qc.ca:
>
>> Git is good, Git is great! All praise the Git! :-D
>>
>> What do you people think about this strange phenomena?
>>
>> localhost / # git --version
>> git version 1.6.4.4
>>
>> localhost / # git init
>> Initialized empty Git repository in //.git/
>>
>> localhost / # cd etc
>> localhost etc # git add X11/xorg.conf
>> fatal: pathspec 'etc/X11/xorg.conf' did not match any files
>>
>> Aside from the obvious question of why would I want to Git the whole
>> tree ("But all files deserve the Holy Presence of the Git!"), why does
>> Git refuse the love offering from "/etc/X11/xorg.conf"? Is it because
>> it contains font directory configurations?
>>
>> Commit and [ENTER] to all,
>>
>> S! :-)
>> --
>> 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
> --
> 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: Merge (or maybe rebase) question
From: Alex Riesen @ 2009-10-12 18:13 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0910120455k7ab5aa5ag8d701050e7acec5f@mail.gmail.com>
On Mon, Oct 12, 2009 at 13:55, Howard Miller <howard@e-learndesign.co.uk> wrote:
> Another how best to do this.
>
> - I have my project all nicely in git with all the different releases
> and versions in there going back years. Happy :-)
>
> - I have a customer who has heaviliy modified an oldish version of the
> software.
>
> - I have identified the version that they modified and created a
> branch in my git repo based on that version (i.e. what they would have
> started with before modifying it)
That's the branch where you should apply their changes. Let name it "theirs".
And I assume your normal branch is called master.
> - Their changes where applied to a simple download - no version
> control, no nothing.
>
> I now need to update them to the latest version of the software - can
> git help me here or is it all a disaster?
You can have it with both merge and rebase.
Merge:
$ git checkout master
$ git merge theirs
Now your master contains a tree where their and your changes
are mixed. Exactly how they are mixed (IOW, how you resolved
conflicts, what exactly have you taken from their tree, etc) is
recorded in the merge commit. You can't export this information out
of Git repo (so it is readily and simply usable without Git, that is).
That's usually not a problem.
Rebase:
$ git checkout theirs^0
$ git rebase master
The rebase can cause conflicts.
$ git branch new-theirs
$ git checkout new-theirs
Now you are on a branch which contains their changes on top of your
current development branch. The software as "they" had it is in "theirs".
You can export their changes to your *current* tree to anyone as patches.
No one can tell anything about where the changes were created in the
first place (the "base"), though. That's the major downside of the approach.
> PS. To make matters worse - their original is full of expanced CVS
> $Id:$ tags so it will look to git like every single file has changed.
You can filter them out using you favorite editor or scripting language
and commit the filtered tree. Gits merge considers only the final
states of the branches it merges.
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Alex Riesen @ 2009-10-12 18:15 UTC (permalink / raw)
To: Steven Noonan; +Cc: sylvain, git
In-Reply-To: <f488382f0910121106h64571b93jb92372a1d7720b10@mail.gmail.com>
On Mon, Oct 12, 2009 at 20:06, Steven Noonan <steven@uplinklabs.net> wrote:
> I've had this problem too, but I eventually realized it was git's way
> of telling me I shouldn't do that. But even so, it'd be good if we
> _could_.
It's more of "a note to the future generation of developers": "Hey guys,
we didn't need that working, but if you have a night to spare could you
please finish that?"
^ permalink raw reply
* Re: Filesystem has no item: Working copy path [...] does not exist in repository at /usr/bin/git-svn line 3856
From: Eric Wong @ 2009-10-12 18:20 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List
In-Reply-To: <9accb4400910120848n6a1e4036l5e45ce3882deb5aa@mail.gmail.com>
Daniele Segato <daniele.bilug@gmail.com> wrote:
> Hi,
> i'm trying to clone a public SVN repo (user = guest, password is
> empty/blank/not neeeded)
>
> this was my steps:
>
> $ git --version
> git version 1.5.6.5
Hi Daniele,
First I thought this was a problem fixed in
83c2fcff214fe89649fcd88e095d9961a36b53dd (git v1.6.2 or later),
but then I tried running it just to make sure.
> $ mkdir plugins
> $ cd plugins
> $ git svn init http://svn.liferay.com/repos/public/plugins -T trunk -b
> branches # doesn't have tags
> $ git svn fetch
> [...]
> # it takes hours.....
> [...]
> r25355 = ee13a19e656e6f96b1ebb562b10ee7fa688921df (svn/trunk)
> Filesystem has no item: Working copy path 'plugins/branches/trunk'
> does not exist in repository at /usr/bin/git-svn line 3856
>
>
> after that revision it give me that error... and then stops.
> if I issue again the git svn fetch it keep telling me the error and I
> can't complete the cloning.
This is a namespace conflict, the "trunk" ref is conflicting with a
(what seems to be a miscreated) branch named "trunk". I anticipated
this problem originally but figured it was rare/uncommon enough that I
didn't want to burden users by prefixing all branches with something:
------------------------------------------------------------------------
r25364 | michael.hashimoto | 2009-01-21 14:06:53 -0800 (Wed, 21 Jan 2009) | 1 line
Changed paths:
A /plugins/branches/trunk
Created directory 'plugins/branches/trunk'.
------------------------------------------------------------------------
r25365 | michael.hashimoto | 2009-01-21 14:07:15 -0800 (Wed, 21 Jan 2009) | 1 line
Changed paths:
D /plugins/branches/trunk
Removed plugins/branches/trunk
Since it looks pretty obvious that "trunk" was miscreated here from the
revision history, you can skip these two revisions in your import by
recontinuing the clone with "git svn fetch -r25365:HEAD"
If you encounter this problem further in a non-workaroundable way,
you can prefix the local branches refs:
Replace:
[svn-remote "svn"]
branches = plugins/branches/*:refs/remotes/svn/*
With:
[svn-remote "svn"]
branches = plugins/branches/*:refs/remotes/svn/branches/*
I didn't do this by default since I figured very few people would create
a branch named "trunk" (and those who did, did it accidentally as it
seems to be the case here).
Hope that helps.
--
Eric Wong
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: sylvain @ 2009-10-12 18:20 UTC (permalink / raw)
To: Alex Riesen; +Cc: Steven Noonan, git
In-Reply-To: <81b0412b0910121115s26c6c08s1ea54c28851faf05@mail.gmail.com>
Quoting Alex Riesen <raa.lkml@gmail.com>:
> On Mon, Oct 12, 2009 at 20:06, Steven Noonan <steven@uplinklabs.net> wrote:
>> I've had this problem too, but I eventually realized it was git's way
>> of telling me I shouldn't do that. But even so, it'd be good if we
>> _could_.
>
> It's more of "a note to the future generation of developers": "Hey guys,
> we didn't need that working, but if you have a night to spare could you
> please finish that?"
Ok, then I won't wait for it to work. I will dive in Git's code and
play the "future generation of developers" part... some day. ;-)
Thank you! :-)
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Markus Heidelberg @ 2009-10-12 18:30 UTC (permalink / raw)
To: sylvain; +Cc: git
In-Reply-To: <20091012012826.7sffggwmm8sk0cc8@webmail.demarque.qc.ca>
sylvain@demarque.qc.ca, 12.10.2009:
> Git is good, Git is great! All praise the Git! :-D
>
> What do you people think about this strange phenomena?
>
> localhost / # git --version
> git version 1.6.4.4
>
> localhost / # git init
> Initialized empty Git repository in //.git/
>
> localhost / # cd etc
> localhost etc # git add X11/xorg.conf
> fatal: pathspec 'etc/X11/xorg.conf' did not match any files
"git add etc/X11/xorg.conf" works, seems to be a bug.
Markus
^ permalink raw reply
* Re: git refuses to work with gvim
From: Joshua Roys @ 2009-10-12 18:29 UTC (permalink / raw)
To: Matthieu Moy; +Cc: sebastian, git
In-Reply-To: <vpq8wfgg4u1.fsf@bauges.imag.fr>
On 10/12/2009 08:43 AM, Matthieu Moy wrote:
> sebastian@CoLi.Uni-SB.DE writes:
>
>> # git commit something
>> fatal: no commit message? aborting commit.
>> #
>
> The problem is that gvim returns immediately, and lets the window
> opened (try it in a terminal, "gvim foo.txt" returns immediately). Git
> expects the commit message to be written and saved when $EDITOR
> returns.
>
> A quick search for "wait" in the man pages tells me that
>
> GIT_EDITOR='gvim -f' git commit
>
> works.
>
> (BTW, this is in no way specific to Git, 99% applications calling
> $EDITOR will expect the same behavior)
>
Hello,
Also, a :help nofork leads to gui-fork and guioptions, which tells you
that you can add the following to .vimrc (not .gvimrc, see :help go-f):
set guioptions+=f
--
Joshua Roys
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Alex Riesen @ 2009-10-12 18:30 UTC (permalink / raw)
To: sylvain; +Cc: Steven Noonan, git
In-Reply-To: <20091012142017.vrs4v2cc8wgws8g4@webmail.demarque.qc.ca>
On Mon, Oct 12, 2009 at 20:20, <sylvain@demarque.qc.ca> wrote:
> Quoting Alex Riesen <raa.lkml@gmail.com>:
>> It's more of "a note to the future generation of developers": "Hey guys,
>> we didn't need that working, but if you have a night to spare could you
>> please finish that?"
>
> Ok, then I won't wait for it to work. I will dive in Git's code and play the
> "future generation of developers" part... some day. ;-)
>
> Thank you! :-)
>
Hmm... This strategy to encourage new contributors didn't quite worked out.
Must try something else next time. Do you like sweets? Just asking...
^ permalink raw reply
* Re: backup git repo on every commit
From: Christian Himpel @ 2009-10-12 18:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Israel Garcia, git
In-Reply-To: <20091012141544.GF9261@spearce.org>
On Mon, Oct 12, 2009 at 07:15:44AM -0700, Shawn O. Pearce wrote:
> Israel Garcia <igalvarez@gmail.com> wrote:
> git remote add --mirror backup you@another.host:path/to/backup.git
>
> cat >.git/hooks/post-commit
> #!/bin/sh
> git push backup
> ^D
>
> chmod a+x .git/hooks/post-commit
Since this is meant as a backup, is there also a sane way to push the
reflog entries as well? Or is it okay just to copy .git/logs to the
backup repository?
Thanks,
chressie
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Jeff King @ 2009-10-12 18:35 UTC (permalink / raw)
To: sylvain; +Cc: Alex Riesen, Steven Noonan, git
In-Reply-To: <20091012142017.vrs4v2cc8wgws8g4@webmail.demarque.qc.ca>
On Mon, Oct 12, 2009 at 02:20:17PM -0400, sylvain@demarque.qc.ca wrote:
> >It's more of "a note to the future generation of developers": "Hey guys,
> >we didn't need that working, but if you have a night to spare could you
> >please finish that?"
>
> Ok, then I won't wait for it to work. I will dive in Git's code and
> play the "future generation of developers" part... some day. ;-)
>
> Thank you! :-)
I think that it sort of works, actually. It seems to do OK if you do
something like:
$ GIT_DIR=/path/to/store/repo; export GIT_DIR
$ GIT_WORK_TREE=/; export GIT_WORK_TREE
$ git init
$ cd /etc/whatever
$ git add .
But it does not work if you try to make things work automatically:
$ cd /
$ git init
$ cd /etc/whatever
$ git add .
So probably the bug is in detecting the location of the work tree when
it is not explicitly given. You can use the explicit style as a
workaround for now.
-Peff
^ permalink raw reply
* Re: Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Björn Steinbrink @ 2009-10-12 18:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Euguess, Mikael Magnusson, Matthieu Moy, Jeff King, Jay Soffian,
git
In-Reply-To: <alpine.DEB.1.00.0910120941150.4985@pacific.mpi-cbg.de>
On 2009.10.12 09:49:50 +0200, Johannes Schindelin wrote:
> On Tue, 6 Oct 2009, Euguess@gmail.com wrote:
> > I'ma new user of git and I don't think i will ever have a commit in
> > git.git, because I'm not a programmer (I'm QA).
[...]
> > As for the solution i would choose the "simplest thing that will work" -
> > so i think that we just have to notify user about his suicide attempt to
> > checkout nonlocal branch and offer him a correct syntax to go with.
> >
> > Something like below should work:
> >
> > % git clone git://git.git git
> > % git checkout next
> > You're attempting to checkout to non-local branch. This will lead to your HEAD
> > being detached (our team is on its way!).
> > Do you want to check out local branch 'next' tracking 'origin/next' instead?
> > y/n
> >
> > if yes, then:
> > Created branch "next" tracking "origin/next"
> > You can update it with 'git pull'.
> >
> > If no - abort or continue with checkout to nonlocal branch? ('m not sure if
> > detaching HEAD can provide some benefits if done on purpose)
> >
> > I hope I'm not missing anything...
>
> No, I think that is something perfectly fine to expect in a software whose
> UI complexity is unfortunately pretty much in disagreement with its
> internal complexity.
>
> One thing one might add for the technically inclined folks (i.e. those who
> need to implement, and to see that Git is in dear need of some
> user-friendliness first): "git checkout" is a porcelain (i.e. a program
> meant for end-user consumption), and as such should not have a problem to
> react to isatty(0) (i.e. "is the input coming directly from the
> console?").
So I didn't mean to chime in, but anyway... A few days ago, uau on #git
said that he thinks that "git clone" shouldn't create any branch heads
at all. Instead, git should learn to do something like "svn up", when
the user checked out a remote tracking branch. That was specifically
meant for users that _don't_ commit, like, say, QA guys ;-)
I didn't quite agree on the idea (feel free to tell me that I just blank
out UI problems :-p), but anyway, I felt like coming up with some hack
that achieves said functionality. The result was inspired by "git
checkout -" and looks at HEAD's reflog to figure out whether the user
has checked out a remote tracking branch the last time he used checkout
to switch branches. I dared to call it "git-up" in my $HOME/bin ;-)
#!/bin/bash
MODE=${1:---merge}
RTB=$(git rev-parse --symbolic-full-name $(git reflog | grep 'checkout: moving from .* to' | head -1 | sed -e 's/.* to //'))
if [ ${RTB:0:13} != "refs/remotes/" ]
then
echo "You're not on a remote tracking branch"
exit 1
fi
SRTB=${RTB#refs/remotes/}
REMOTE=${SRTB%/*}
git fetch $REMOTE
git reset $MODE $RTB
It's obviously basically just "git reset" on crack, happily dropping
local commits. A "real" implementation would likely have to have more
checks to ensure that the user is using it in an expected way (like
checking that refs/remotes/whatever..HEAD is empty). And it could be
made to work with regular branch heads as well then, as a "fast-forward
only" way of updating (think "git merge --ff-only", but in a less
illogical way, as "--ff-only" actually means "don't create a merge",
which is kinda weird, at least to me).
As I said, I don't really agree on the idea of not creating any branch
heads on "clone", but maybe it's because I'm not a "don't commit, just
watch" person. And the theoretical "git up" command might be handy for
guys that just want to follow things, and thus don't really need branch
heads. At the moment, I don't have any intentions to improve the hack
(also due to lack of time), but if it seems worthwhile to anyone, feel
free to pick it up.
Björn, -ENOPATCH ;-)
^ permalink raw reply
* Re: backup git repo on every commit
From: Shawn O. Pearce @ 2009-10-12 18:37 UTC (permalink / raw)
To: Christian Himpel; +Cc: Israel Garcia, git
In-Reply-To: <20091012183504.GA3872@mrslave>
Christian Himpel <chressie@googlemail.com> wrote:
> Since this is meant as a backup, is there also a sane way to push the
> reflog entries as well? Or is it okay just to copy .git/logs to the
> backup repository?
There isn't a way to transfer reflogs, but one could rsync them
over to the backup. Some records might be missing their SHA-1 in
the backup if that particular object wasn't pushed there, but the
reflog code is generally tolerant of those garbage records.
--
Shawn.
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Matthieu Moy @ 2009-10-12 19:02 UTC (permalink / raw)
To: sylvain; +Cc: git
In-Reply-To: <20091012012826.7sffggwmm8sk0cc8@webmail.demarque.qc.ca>
sylvain@demarque.qc.ca writes:
> localhost / # cd etc
> localhost etc # git add X11/xorg.conf
> fatal: pathspec 'etc/X11/xorg.conf' did not match any files
cd ..
git add etc/X11/xorg.conf
works. I don't know why the other doesn't (just tested adding from an
untracked directory in another project, it does work).
If you want to version a large directory like /, I'd advise putting
"*" in /.gitignore to make sure Git never tries to traverse the whole
filesystem.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Questions about the new
From: Dmitry Potapov @ 2009-10-12 19:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Sergio, git
In-Reply-To: <4AD31EBF.6090307@viscovery.net>
On Mon, Oct 12, 2009 at 02:19:11PM +0200, Johannes Sixt wrote:
>
> With grafts you can only change parenthood; with replace entries you can
> change parenthood *and* all other aspects of a commit (message, author,
> committer, dates).
Actually, you can. I have written a script that did exactly this. It
required to modify parents to point to the new commit. The tricky part
was that modification could be on top of other modifications, but I was
able to handle this case too. Yet, my script was so hackish that I have
never dared to share it with someone (and I used it only couple times
during CVS to Git conversion).
>
> Hence, replace entries are more general than grafts.
I think both mechanism are theoretically equivalent, but with grafts,
it was rather difficult to replace objects (but not impossible!).
> The problem with grafts was that, for example, git-pack-objects obeyed the
> graft, and could create a broken repository by removing grafted-away
> objects. And since git-fsck also obeyed the graft, it did not notice the
> breakage.
Moreover, grafted-away objects could be removed by the garbage collector...
Dmitry
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: sylvain @ 2009-10-12 19:08 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Riesen, Steven Noonan, git
In-Reply-To: <20091012183519.GA10686@coredump.intra.peff.net>
Quoting Jeff King <peff@peff.net>:
> On Mon, Oct 12, 2009 at 02:20:17PM -0400, sylvain@demarque.qc.ca wrote:
>
> I think that it sort of works, actually. It seems to do OK if you do
> something like:
>
> $ GIT_DIR=/path/to/store/repo; export GIT_DIR
> $ GIT_WORK_TREE=/; export GIT_WORK_TREE
> $ git init
> $ cd /etc/whatever
> $ git add .
>
> So probably the bug is in detecting the location of the work tree when
> it is not explicitly given. You can use the explicit style as a
> workaround for now.
>
> -Peff
Thank you! Great idea!
export GIT_DIR=/root/.git
export GIT_WORK_TREE=/
echo "*" >> /root/.git/info/exclude
The Golden Solution of the Gods! :-D
^ permalink raw reply
* Re: Supressing sorting of trees
From: Martin Langhoff @ 2009-10-12 19:36 UTC (permalink / raw)
To: Sal Mangano; +Cc: git
In-Reply-To: <loom.20091012T182258-9@post.gmane.org>
On Mon, Oct 12, 2009 at 6:51 PM, Sal Mangano
<smangano@into-technology.com> wrote:
> 2) I can use Git unchanged but preserve order by storing some information in
> each sub tree (e.g. an extra blob) which retains the real order. I can also
This #2 is your best bet by far. An extra blob in each subdir is just
one option, you can handle this "extra metadata" in a number of ways
-- maybe external to git, on a separate history will work best.
The downsides of messing with internal tree handling of git are so
staggering that you'd do better to throw git away.
(this is from experience of abusing git to various purposes that have
little to do with version control :-) )
In other words: Shaun and Dscho are right, so right that it hurts.
hth,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* [PATCH] git-stash documentation: mention default options for 'list'
From: Miklos Vajna @ 2009-10-12 19:37 UTC (permalink / raw)
To: Jeff King; +Cc: Jef Driesen, git
In-Reply-To: <20091012175201.GA10263@coredump.intra.peff.net>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
I just noticed this was not mentioned in the manpage.
Documentation/git-stash.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 3f14b72..fafe728 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -78,7 +78,8 @@ stash@{1}: On master: 9cc0589... Add git-stash
----------------------------------------------------------------
+
The command takes options applicable to the 'git-log'
-command to control what is shown and how. See linkgit:git-log[1].
+command to control what is shown and how. If no options are set, the
+default is `-n 10`. See linkgit:git-log[1].
show [<stash>]::
--
1.6.4
^ permalink raw reply related
* Re: [PATCH] git-stash documentation: mention default options for 'list'
From: Jeff King @ 2009-10-12 19:39 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Jef Driesen, git
In-Reply-To: <20091012193739.GR23777@genesis.frugalware.org>
On Mon, Oct 12, 2009 at 09:37:39PM +0200, Miklos Vajna wrote:
> I just noticed this was not mentioned in the manpage.
Thanks, looks like an improvement to me.
-Peff
^ permalink raw reply
* Re: quote in help code example
From: Miklos Vajna @ 2009-10-12 19:40 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091012102926.GA3937@debian.b2j>
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
On Mon, Oct 12, 2009 at 06:29:26PM +0800, bill lam <cbill.lam@gmail.com> wrote:
> In git man, eg. git help filter-branch
> The code examples for command line or shell scripts inside .ft pairs
> use (smart?) quote instead of single quotes, like
>
> .ft C
> git filter-branch --tree-filter ´rm filename´ HEAD
> .ft
>
> Is this intentional or just some configuration problem during
> compiling.
Just a guess: do you have docbook-xsl >=1.73.0 and you did not set
ASCIIDOC_NO_ROFF?
Try rebuilding the documentation using 'make ASCIIDOC_NO_ROFF=YesPlease'.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Let --decorate show HEAD position
From: Thomas Rast @ 2009-10-12 20:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, René Scharfe
In-Reply-To: <4c70c935ab67266684aa14e38e276795cf1776db.1255337211.git.trast@student.ethz.ch>
Thomas Rast wrote:
> diff --git a/log-tree.c b/log-tree.c
> index 1618f3c..f7d54f2 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -43,6 +43,7 @@ void load_ref_decorations(int flags)
> if (!loaded) {
> loaded = 1;
> for_each_ref(add_ref_decoration, &flags);
> + head_ref(add_ref_decoration, &flags);
> }
> }
Damn, this fails tests and I only just noticed while testing another
series. Sorry for the noise, reroll upcoming...
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Supressing sorting of trees
From: Salvatore Mangano @ 2009-10-12 20:02 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90910121236x6bbe258bwa3bc3fdcc54de524@mail.gmail.com>
On Oct 12, 2009, at 3:36 PM, Martin Langhoff wrote:
> On Mon, Oct 12, 2009 at 6:51 PM, Sal Mangano
> <smangano@into-technology.com> wrote:
>> 2) I can use Git unchanged but preserve order by storing some
>> information in
>> each sub tree (e.g. an extra blob) which retains the real order. I
>> can also
>
> This #2 is your best bet by far. An extra blob in each subdir is just
> one option, you can handle this "extra metadata" in a number of ways
> -- maybe external to git, on a separate history will work best.
>
> The downsides of messing with internal tree handling of git are so
> staggering that you'd do better to throw git away.
>
> (this is from experience of abusing git to various purposes that have
> little to do with version control :-) )
>
> In other words: Shaun and Dscho are right, so right that it hurts.
>
Thanks Martin. I suspect you, Shaun and Dscho are correct. But, can
anyone point to specific code
that would allow me to see first hand that this is hopeless. So far,
based on the code I looked at, I see
it as problematic but not hopeless. Here I define "problematic" as
having to change a few files and/or
avoid using some features while "hopeless" meaning I'd have to change
almost very single plumbing
command.
^ permalink raw reply
* Re: Supressing sorting of trees
From: Martin Langhoff @ 2009-10-12 20:24 UTC (permalink / raw)
To: Salvatore Mangano; +Cc: git
In-Reply-To: <DF65B4B0-62B1-4469-99E1-3305434F9D59@into-technology.com>
On Mon, Oct 12, 2009 at 10:02 PM, Salvatore Mangano
<smangano@into-technology.com> wrote:
> point to specific code
Shaun pointed out some very core code. And it is just a core concept.
Just read up on the core organizing concept that is the "tree". Git
relies on the layout of the tree being strictly deterministic.
It is a prevalent assumption in the whole codebase.
Yes you can change it, but assume you will have to audit/rewrite 80%
of the core code.
Want "proof"? Go change it, then try "make test", or reimport a large
repository try to use the git commands over it. We'll relax and watch
the fireworks :-)
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* [PATCH v2] Let --decorate show HEAD position
From: Thomas Rast @ 2009-10-12 20:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, René Scharfe
In-Reply-To: <200910122206.23044.trast@student.ethz.ch>
'git log --graph --oneline --decorate --all' is a useful way to get a
general overview of the repository state, similar to 'gitk --all'.
Let it indicate the position of HEAD by loading that ref too, so that
the --decorate code can see it.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
I wrote:
> Damn, this fails tests and I only just noticed while testing another
> series. Sorry for the noise, reroll upcoming...
log-tree.c | 1 +
t/t4013/diff.log_--decorate=full_--all | 2 +-
t/t4013/diff.log_--decorate_--all | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 1618f3c..f7d54f2 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -43,6 +43,7 @@ void load_ref_decorations(int flags)
if (!loaded) {
loaded = 1;
for_each_ref(add_ref_decoration, &flags);
+ head_ref(add_ref_decoration, &flags);
}
}
diff --git a/t/t4013/diff.log_--decorate=full_--all b/t/t4013/diff.log_--decorate=full_--all
index 903d9d9..d155e0b 100644
--- a/t/t4013/diff.log_--decorate=full_--all
+++ b/t/t4013/diff.log_--decorate=full_--all
@@ -1,5 +1,5 @@
$ git log --decorate=full --all
-commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (refs/heads/master)
+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, refs/heads/master)
Merge: 9a6d494 c7a2ab9
Author: A U Thor <author@example.com>
Date: Mon Jun 26 00:04:00 2006 +0000
diff --git a/t/t4013/diff.log_--decorate_--all b/t/t4013/diff.log_--decorate_--all
index 954210e..fd7c3e6 100644
--- a/t/t4013/diff.log_--decorate_--all
+++ b/t/t4013/diff.log_--decorate_--all
@@ -1,5 +1,5 @@
$ git log --decorate --all
-commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (master)
+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, master)
Merge: 9a6d494 c7a2ab9
Author: A U Thor <author@example.com>
Date: Mon Jun 26 00:04:00 2006 +0000
--
1.6.5.62.g4370d.dirty
^ permalink raw reply related
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