* Re: [PATCH/RFC 3/4] git check-ref-format --print
From: Shawn O. Pearce @ 2009-10-12 23:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Jens Lehmann, git
In-Reply-To: <7veip8e302.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> I understand that you prefer the latter between "there is no tool; the
> caller is responsibile to make sure it feeds us canonical representation"
> and "there is a tool that makes a slightly malformed string into canonical
> form for the callers to use before calling us." And that would be my
> preference between these two as well.
...
> But now I have spelled this out, I do not see much upside for rejecting,
> and more importantly, I think it would be an independent issue. We can
> reject or just keep normalizing silently, and a tool to show the
> normalized name would be useful and necessary regardless of that.
I agree with the last paragraph here, we shouldn't reject, but
instead keep the current state but encourage tools to use the new
canonical print tool to clean up a name if they want to hang onto the
string the user entered and it needs to exactly match for-each-ref
sort of output.
--
Shawn.
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Miklos Vajna @ 2009-10-12 23:19 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <76c5b8580910121448q67edd935wb189c8a6f9af2f2e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 492 bytes --]
On Mon, Oct 12, 2009 at 05:48:14PM -0400, Eugene Sajine <euguess@gmail.com> wrote:
> Yes, I might be stubborn, but is just because i feel that i can
> contribute into making git better, although I'm not a developer.
In a distrubuted environment, there is no need to define who is a
developer and who is not. And contributing is allowed to anyone as long
as you sign the Develoer's Certificate of Origin. :)
(See
http://repo.or.cz/w/git.git?a=blob;f=Documentation/SubmittingPatches;hb=HEAD)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git-pack-objects gitattributes?
From: Nasser Grainawi @ 2009-10-12 23:00 UTC (permalink / raw)
To: Git Mailing List
Hello,
I'm trying to avoid doing delta compression on a number of large binary files.
I got a suggestion to use $GIT_DIR/info/attributes and a line like this:
*.bin -delta
This doesn't seem to show a big improvement (and honestly I can't find where in
the git-pack-objects source the value of this attribute is used).
Could someone shed some light on this attribute and any other improvements I
could make for efficiently serving up a repo over git-daemon with near-weekly
revisions of 100MB+ files?
Thanks,
Nasser
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #02; Sun, 11)
From: Junio C Hamano @ 2009-10-12 22:52 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091012051442.GB23007@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Oct 11, 2009 at 08:18:17PM -0700, Junio C Hamano wrote:
>
>> * jk/1.7.0-status (2009-09-05) 5 commits.
>> - docs: note that status configuration affects only long format
>> (merged to 'next' on 2009-10-11 at 65c8513)
>> + commit: support alternate status formats
>> + status: add --porcelain output format
>> + status: refactor format option parsing
>> + status: refactor short-mode printing to its own function
>> (this branch uses jc/1.7.0-status.)
>>
>> Gives the --short output format to post 1.7.0 "git commit --dry-run" that
>> is similar to that of post 1.7.0 "git status".
>>
>> * jc/1.7.0-status (2009-09-05) 4 commits.
>> (merged to 'next' on 2009-10-11 at 9558627)
>> + status: typo fix in usage
>> + git status: not "commit --dry-run" anymore
>> + git stat -s: short status output
>> + git stat: the beginning of "status that is not a dry-run of commit"
>> (this branch is used by jk/1.7.0-status.)
>>
>> With this, "git status" is no longer "git commit --dry-run".
>
> Hmm. I thought you wanted to re-order some of these for to put the
> porcelain and short formats into v1.6.6, but leave the status switchover
> for v1.7.0.
We could build an alternate history between 3fa509d..46b77a6, revert the
merges 9558627 and 65c8513, and merge the alternate history. But is the
short format support so solid that it deserves to be in 1.6.6 in the
current shape?
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-12 22:49 UTC (permalink / raw)
To: Thomas Rast
Cc: Johannes Schindelin, Euguess, Mikael Magnusson, Matthieu Moy,
Jeff King, Jay Soffian, git
In-Reply-To: <200910122340.13366.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Your idea is also a backwards incompatible change, so we can just as
> well implement the original suggestion and force scripts (or us) to
> use some other means when they want to detach. Say, why not just
> invent an option along the lines of
>
> git checkout {-d|--detach} $ref
>
> to make it explicit.
Or can't you go the other way, say
git checkout -t $remote_tracking
to create a local branch forking from the named remote tracking branch?
^ 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 22:45 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List
In-Reply-To: <1255382764.15646.5.camel@localhost>
Daniele Segato <daniele.bilug@gmail.com> wrote:
> In this case the repo was public, what should I do to debug some git-svn
> issue like that if I encounter a problem with a non-public repo?
> May be there is some debug flag I could enable? Or I had to
> guess/explore the svn tree?
I rely on the output of "svn log -v" extensively.
I'll also use strace, ltrace, tcpdump and/or put print statements
(combined with Data::Dumper) in various places of git-svn.
Unfortunately the git-svn code is quite ugly and I still haven't had the
time or energy to clean it up myself :<
--
Eric Wong
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: sylvain @ 2009-10-12 22:04 UTC (permalink / raw)
To: Daniele Segato; +Cc: git
In-Reply-To: <1255383459.15646.10.camel@localhost>
Quoting Daniele Segato <daniele.bilug@gmail.com>:
> Il giorno lun, 12/10/2009 alle 01.28 -0400, sylvain@demarque.qc.ca ha
> scritto:
>> localhost / # git init
>
> I don't see the point of using git on the root directory :)
>
> but that made me think that it could actually be a good idea
> for /etc/ :)
> I happen to modify some configuration and then I forgot which one... and
> sometimes updates broke something
>
>
> And that make me think of another question...
>
> is there a way to have a git repo for a subset of directory that match a
> pattern?
>
> for instance...
>
> can I have a git report of $HOME/.* (without . and ..)? (all user
> setting)
>
> Or better: provide a list of directory under $HOME I want to track
>
> Instead of providing the list of directory I want to ignore i would like
> to provide the list of the directory and files I want to track :)
>
> I probably am going out of topic here but I hope you forgive me :)
I am still a Git newbee, but I am using GNU/Linux for a long time now.
I have just reformatted my disk and installed Gentoo and I have to
setup all these little things all over again. Since I clean install
only every couple of years, I often forget some details, etc.
So I am trying something new. I have my "home Git" at "~/.git" and the
"root Git" at "/root/.git" with the GIT_WORK_TREE at "/". Both have
"*" in "info/exclude", so I do provide my list of directories and
files I want to track explicitly by adding them one by one.
My home Git takes care of .bash* .vim* .emacs*, firefox passwords and
bookmarks, etc. My root git takes care of some "/etc", "/var" configs,
etc. (That is the reason why I wanted it on "/", because some
configuration tweaks are done outside of "/etc". Oh, I forgot to
mention "/usr/src/linux/.config")
My hope is that next time I'll clean install my system, I won't have
to backup my whole disk and then mount it again to recover configs
pieces by pieces. I'll just copy my two Git repositories and I'll
should be OK.
All praise the Git. :-)
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Avery Pennarun @ 2009-10-12 21:57 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List
In-Reply-To: <1255383459.15646.10.camel@localhost>
On Mon, Oct 12, 2009 at 5:37 PM, Daniele Segato <daniele.bilug@gmail.com> wrote:
> can I have a git report of $HOME/.* (without . and ..)? (all user
> setting)
>
> Or better: provide a list of directory under $HOME I want to track
>
> Instead of providing the list of directory I want to ignore i would like
> to provide the list of the directory and files I want to track :)
You can probably do pretty much anything you want by twiddling with
options in .gitignore. You should be able to add "don't ignore" names
by starting them with !, iirc.
Avery
^ permalink raw reply
* Re: [RFC PATCH 0/5] Pretty formats for reflog data
From: Thomas Rast @ 2009-10-12 21:52 UTC (permalink / raw)
To: Jeff King; +Cc: Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <20091012213756.GA12166@coredump.intra.peff.net>
Jeff King wrote:
>
> I'm not sure if people will like having a longer [stash] list in a
> pager than a shorter list without one (I personally can't remember
> ever using "git stash list", so I have no strong opinion).
True. Then again we patched git-stash(1) to recommend stash/pop over
stash/apply, so we should actively show the user that s/he has a long
stash list and may want to apply them somewhere.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Questions about the new
From: Christian Couder @ 2009-10-12 21:54 UTC (permalink / raw)
To: Sergio Callegari; +Cc: Johannes Sixt, git
In-Reply-To: <4AD3619C.6010808@gmail.com>
On Monday 12 October 2009, Sergio Callegari wrote:
> Thanks Johannes for all the detailed explanations
>
> Johannes Sixt <j.sixt <at> viscovery.net> writes:
[...]
> > 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).
> >
> > Hence, replace entries are more general than grafts.
>
> Limiting the discussion to commit objects, I think there are two
> possible scenarios.
>
> 1) You create new commits objects as needed
> 2) You do not.
>
> If you follow 1), I believe grafts and replace entries have exactly the
> same flexibility.
>
> If I happen not to like commit B in A---B---C and I want A---B'---C
> where B' has
> completely different aspects from B I can either replace B by B' or
> graft away
> B, pretending that the parent of A is B
You mean "pretending that the parent of C is A", right?
> But there are many things that can be done with grafts merely adding a
> graft (e.g. cutting away a part of history, joining history), that
> cannot be done with replace entries without creating new commits objects.
Yes, but when you create a graft, you add a new line in the graft file. You
don't get the grafts for free.
> I was asking because I was wandering whether replace entries were first
> or later
> meant to make grafts deprecated. I hope not, because for a few things
> working on
> arcs seems still nice.
I don't think they will be deprecated soon. And anyway there will probably
be a warning when a graft is used if it is deprecated.
[...]
> > > Conversely, I guess
> > > you can always simulate a replace entry with the graft mechanism,
>
> without the
>
> > > need to add any extra commit object. Am I overlooking something?
> >
> > You cannot; see above.
>
> Well, I meant for what regards commit objects only.
>
> If I want to replace some commit X by some commit X' I merely need to
> modify the
> parent information of all the commits that are child of X so that they
> pretend
> to be child of X', or am I missing something?
If you use git replace you just need to create commit X' and then use "git
replace X X'". If you use grafts, yes, you have to modify the parent
information of all the commits that are child of X.
> > You can even replace tree objects and blob objects
> > using replace entries, IIUC, but you cannot do that with grafts.
>
> Definitely right!
>
> > > 2) Is it currently possible to use a replace entry to replace a
>
> commit object
>
> > > with nothing? Namely if B has A as its sole parent, is it possible
>
> to have a
>
> > > replace entry such as A-sha1 becomes null, to pretend that B is a
>
> hierarchy
>
> > > root?
> >
> > Sure. Just make a commit object that does not have parents.
>
> OK, you need to create a new commit object. At the beginning for some
> reason I
> thought that you could replace an object
> with "nothing" or 00000000000000000000000000000000000000000000
>
> > > 3) If I remember correctly, there was a reason why grafts were not
>
> considered
>
> > > suitable for transferring across repos. Can someone remind me about
>
> it? How
>
> > > does the replace mechanism address this issue?
> >
> > 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.
> >
> > OTOH, history walkers (upload-pack, send-pack, pack-objects) and fsck
> > never obey replace entries in the history. But they do keep track of
> > them (and the history that they reference) because they are referenced
>
> from the
>
> > refs/replace namespace.
>
> Thanks for the explanation. Can this be made possible for grafts too?
> Wouldn't
> it be a matter of having history walkers never obey grafts but keep track
> of them (i.e. of the history of the parenthood they reference)?
The problem is that grafts are special, so all the history walking commands
should be changed to deal with them specially. With the replace mechanism,
commits and refs are used, and all the commands already know how to deal
with them.
> Like we have "annotated" or heavyweight tags living as objects in the
> database,
> would it be possible or make sense to have annotated grafts or replace
> entries,
> so that one can express why, by whom and when history was changed?
There is a patch series about "notes" floating around that deals with
annotating any commit. So it could be used for that.
And anyway when you create the replacement commit, you can state in the
commit message that it is a replacement commit, who created it, etc.
Regards,
Christian.
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Eugene Sajine @ 2009-10-12 21:48 UTC (permalink / raw)
To: Johannes Schindelin, Jakub Narebski; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0910120201350.4985@pacific.mpi-cbg.de>
Hi,
Somebody from development camp recently complained here that there is
no many end users "chiming" about issues in the mailing list. Well,
don't tell i didn't try;)
First I tried to use gitweb.url, gitweb.description and gitweb.owner
files and none of them worked... gitweb is unable to pickup the info
from those files.
Although it successfully interactively picks up info from description
and cloneurl files. I didn't find a substitution for gitweb.owner...
I might be sent to RTFM again, but i would like to bring an attention
to the fact that setting up bare repo with these simplest parameters
as well as setting up gitweb is a USABILITY NIGHTMARE for beginners. I
would even say more: while gitweb is very flexible and powerful, all
its flexibility and power is hidden behind unusable management
interface, which IMHO requires a lot of improvements . Rebuilding to
configure? Perl look-and-feel for configuration variables? I think
this is not the way to configure web applications no matter how smart
and flexible application should be. There are some problems with XML,
I don't care. Let's use simple property file. 1 property file! and let
gitweb read it. don;t like this solution, propose yours..
But leaving the emotions aside and once again -
On Sun, 11 Oct 2009, Jakub Narebski wrote:
>And this would be best left for a custom script creating repositories
>and their git hosting related configuration. Such script of necessity
>would have to be site-specific, or at least contain site-specific
>configuration, like:
>* whether to use gitweb.owner or filesystem uid + GECOS is enough
>* whether to use gitweb.description or description file
>* whether to use gitweb.url, cloneurl file, or let gitweb autogenerate
>clone / fetch URL from base URL
I don't get it. I'm talking specifically about gitweb bundled into git
package by default. It was bundled as i understand to provide full
solution (I don't see any other reason). What the heck is wrong with
continuing to move in this direction? I'm not talking about to enforce
gitweb usage, but just simplify the setup and configuration of a tool
provided by default...
If the user chooses default solution, what is wrong with providing
some usable way of doing things?
Don't want to use git clone, fine. But, please, please save me from
rebuilding gitweb, creating manually those files and putting info
inside... It is 21st century or what?;)
>* gitosis / gitlite configuration, if needed, or setup of public keys
>for SSH authentication
Are they included into git bundle? I didn't see those tools there...
>* project README.html file, if used
>etc.
Yes, I might be stubborn, but is just because i feel that i can
contribute into making git better, although I'm not a developer. And i
think usability is the thing which all beginners would thank you
for... i understand that this issue is not the end of the world and i
will finally overcome the burden, i will develop my script and stuff,
I hope somebody would support me in this:)
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Thomas Rast @ 2009-10-12 21:40 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>
Johannes Schindelin wrote:
> On Tue, 6 Oct 2009, Euguess@gmail.com wrote:
> > in case if you didn't do that and you try to checkout you will end up
> > having detached HEAD which is quite scary;) for non-experienced user and
> > as i see might lead to some unnecessary questions in this list or on IRC
> > channel...
[...]
> 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?").
Sadly git-checkout seems to be stuck between being declared a
porcelain, but at the same time being an extremely important command
for scripts all over. (There are probably others in the same place:
reset comes to mind.)
Your idea is also a backwards incompatible change, so we can just as
well implement the original suggestion and force scripts (or us) to
use some other means when they want to detach. Say, why not just
invent an option along the lines of
git checkout {-d|--detach} $ref
to make it explicit. We have to resort to more arcane means to
*reliably* detach anyway, like 'git checkout master^0'. Then in some
future release, git-checkout will start making DWIM branches if the -d
is not given.
And while we're there, --attach would be a nice complement to force
refs/heads/foo to attach.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Daniele Segato @ 2009-10-12 21:37 UTC (permalink / raw)
To: sylvain; +Cc: git
In-Reply-To: <20091012012826.7sffggwmm8sk0cc8@webmail.demarque.qc.ca>
Il giorno lun, 12/10/2009 alle 01.28 -0400, sylvain@demarque.qc.ca ha
scritto:
> localhost / # git init
I don't see the point of using git on the root directory :)
but that made me think that it could actually be a good idea
for /etc/ :)
I happen to modify some configuration and then I forgot which one... and
sometimes updates broke something
And that make me think of another question...
is there a way to have a git repo for a subset of directory that match a
pattern?
for instance...
can I have a git report of $HOME/.* (without . and ..)? (all user
setting)
Or better: provide a list of directory under $HOME I want to track
Instead of providing the list of directory I want to ignore i would like
to provide the list of the directory and files I want to track :)
I probably am going out of topic here but I hope you forgive me :)
^ permalink raw reply
* Re: [RFC PATCH 0/5] Pretty formats for reflog data
From: Jeff King @ 2009-10-12 21:37 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <cover.1255380039.git.trast@student.ethz.ch>
On Mon, Oct 12, 2009 at 11:02:29PM +0200, Thomas Rast wrote:
> > 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".
>
> This seems fairly arbitrary, doesn't it? My own working theory is
> that Nanako put it in because the git-log|sed construct inherently
> bars any way to a pager, so it needs to be cut short.
Yes, it's arbitrary, though it is probably a reasonable estimate for the
intended use of stash. It's a stack, so you generally are only
interested in the last couple of entries.
What's much worse though is that the logic is not "if you told me how
many to show, show that; otherwise, show 10". Instead it is "if you
gave me no options, default the size of the list. But if you gave me
any options, even if they have nothing whatsoever to do with limiting
the size of the list, then show all".
So something like "git stash list --date=relative" suddenly shows many more
stashes than just "git stash list". It would be nice to fix that.
> So suppose we could somehow get rid of the |sed... like if we had
> --pretty specifiers for the reflog information.
I'm not sure if people will like having a longer list in a pager than a
shorter list without one (I personally can't remember ever using "git
stash list", so I have no strong opinion).
But certainly the idea of adding pretty format specifiers to access
reflog data seems like a good idea on its own.
-Peff
^ permalink raw reply
* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Anders Kaseorg @ 2009-10-12 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5t8coex.fsf@alter.siamese.dyndns.org>
On Mon, 12 Oct 2009, Junio C Hamano wrote:
> I offhand do not see a good rationale for such a shortcut to finish
> bisect and switch to another branch (IOW, I understand "it is shorter to
> type", but I do not see "it is often done and very useful"), but I am
> open to be enlightened by a workflow where such a shortcut is useful.
I agree that ‘git bisect reset <branch>’ is a confusing shortcut. It only
really made sense before Git supported detached HEADs, and you needed to
be on a branch all the time. I think that lifting the arbitrary
restriction to branch names makes it less confusing, but if you want to
remove the argument altogether, that would eliminate the confusion
entirely.
I had in mind only one case where ‘git bisect reset <commit>’ would be
useful. I often don’t even remember what commit I was on before I started
a bisect, much less believe that I want to immediately switch back to it.
I would prefer to be able to clean the bisection state without checking
out another commit at all, because that takes forever and invalidates my
compiled tree. This is what ‘git bisect reset HEAD’ would do if it
worked.
Perhaps it makes sense to add a command that just clears the bisection
state. ‘git bisect stop’?
Anders
^ permalink raw reply
* Re: Filesystem has no item: Working copy path [...] does not exist in repository at /usr/bin/git-svn line 3856
From: Daniele Segato @ 2009-10-12 21:26 UTC (permalink / raw)
To: Eric Wong; +Cc: Git Mailing List
In-Reply-To: <20091012182018.GA14143@dcvr.yhbt.net>
Il giorno lun, 12/10/2009 alle 11.20 -0700, Eric Wong ha scritto:
> 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.
thank you for taking the time
> 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"
I thought it could be a problem like this but I asked before re-fetching
all the repository (just to be sure)..
unfurtunately I already deleted all the .git directory so i'll have to
start again...
> 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.
Yes it really help...
But I'll change it like this instead:
[svn-remote "svn"]
url = http://svn.liferay.com/repos/public
fetch = plugins/trunk:refs/remotes/svn/master
branches = plugins/branches/*:refs/remotes/svn/*
I think it will do as long as they didn't created some branch named
"master" :)
In this case the repo was public, what should I do to debug some git-svn
issue like that if I encounter a problem with a non-public repo?
May be there is some debug flag I could enable? Or I had to
guess/explore the svn tree?
thank you Eric
regards,
Daniele
^ permalink raw reply
* Re: [PATCH v2] Let --decorate show HEAD position
From: Thomas Rast @ 2009-10-12 21:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, René Scharfe
In-Reply-To: <7vk4z0e31e.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> I see HEAD is given at the front in the sample output, which I think also
> makes sense. Is it because it is pushed the last? If so, the same commit
> at the tip of branch alpha and beta are decorated with beta and then
> alpha, I have to wonder...?
Indeed. I wrote this off as a lucky coincidence coming from HEAD
sorting before any lowercase letters, but it's exactly as you say:
commit a0f7579d38feb8c4d87282a6cecbc6778908f19f (test-b, test-a, next)
Merge: 01287fd 548bc3a
Author: Thomas Rast <trast@student.ethz.ch>
[...]
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [RFC PATCH 5/5] stash: change built-in ref to 'stash' instead of 'refs/stash'
From: Thomas Rast @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jef Driesen; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <cover.1255380039.git.trast@student.ethz.ch>
'git stash list' now always shows 'refs/stash@{...}' instead of
'stash@{...}', because that's what we specify for the ref.
Since git checks .git/$ref, .git/refs/$ref and only then
.git/refs/{branches,tags,remotes}, we can drop the prefix. This only
affects people who have .git/stash, who were never able to refer to
their stashes by stash@{...}. (Sadly, now they won't be able to use
git-stash anymore at all.)
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-stash.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 08a7669..8bf464b 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -19,7 +19,7 @@ cd_to_toplevel
TMP="$GIT_DIR/.git-stash.$$"
trap 'rm -f "$TMP-*"' 0
-ref_stash=refs/stash
+ref_stash=stash
if git config --get-colorbool color.interactive; then
help_color="$(git config --get-color color.interactive.help 'red bold')"
--
1.6.5.64.g01287
^ permalink raw reply related
* [RFC PATCH 4/5] stash list: drop the default limit of 10 stashes
From: Thomas Rast @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jef Driesen; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <cover.1255380039.git.trast@student.ethz.ch>
'git stash list' had an undocumented limit of 10 stashes, unless other
git-log arguments were specified. This surprised at least one user,
but possibly served to cut the output below a screenful without using
a pager.
Since the last commit, 'git stash list' will fire up a pager according
to the same rules as the 'git log' it calls, so we can drop the limit.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-stash.sh | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 8fbf10a..08a7669 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -382,11 +382,6 @@ test -n "$seen_non_option" || set "save" "$@"
case "$1" in
list)
shift
- if test $# = 0
- then
- set x -n 10
- shift
- fi
list_stash "$@"
;;
show)
--
1.6.5.64.g01287
^ permalink raw reply related
* Re: [PATCH 1/2] user-manual: add global config section
From: Junio C Hamano @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Felipe Contreras, git, J. Bruce Fields
In-Reply-To: <20091011222729.GA5114@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> This is very early in the manual, where every word counts. I am not
> very good at wording and do not have any better suggestions, but would
> it be possible to more efficiently convey this:
>
> Git reads its per-user configuration from ~/.gitignore.
>
> That file can also be manipulated with the "git config"
> command, which can be convenient in scripts or when using
> operating systems like Windows where it is not clear where
> the home directory is.
>
> For example, if your terminal supports it, you can tell Git
> to use color in the output for commands such as "git diff"
> with "git config --global color.ui auto".
>
> For more information and a list of possible settings, see
> git-config(1).
The way how the above introduces the "git config" command to people who
see git for the first time makes sense. Unfortunately, --global and
per-user do not "click" together when given in isolation, and I think it
would help if it is explained this way, using a setting that can validly
be either per-user or project specific:
Various configuration variables affect how git operates. Some are
specific to the user (e.g. if you prefer to see the output in colour),
while some are specific to a repository (e.g. what other repositories
it interacts with). Git reads from ~/.gitconfig file to learn your
personal settings and .git/config file of the repository you are
working in to learn the repository settings.
These are plain text files that you can view or edit in your text
editor, but they also can be manipulated with the "git config"
command, which is convenient in scripts or ...
For example, if you want to use a particular e-mail address only while
working in the current repository, you would set "user.email" variable
to that e-mail address in the repository configuration file (i.e.
.git/config) with this command:
git config user.email your@email.address.xz
If on the other hand you want to use the same address for any project
you work with, you can instead set this in your personal configuration
file (i.e. ~/.gitconfig) with this command:
git config --global user.email your@email.address.xz
For more information ...
Since this is an end-user material, I deliberately omitted talking about
the --system (i.e. /etc/gitconfig) in the above.
^ permalink raw reply
* [RFC PATCH 2/5] Introduce new pretty formats %g and %G for reflog information
From: Thomas Rast @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jef Driesen; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <cover.1255380039.git.trast@student.ethz.ch>
Add two new pretty escapes: %g expands to the reflog selector (i.e.,
branch@{number} or branch@{date}) and %G expands to the reflog
message.
We use the newly refactored selector formatting function and introduce
another wrapper to get the reflog message.
Unfortunately, we also need to pass down the reflog_walk_info from
show_log(), so this commit touches a lot of (unrelated) callers to
pretty_print_commit() and format_commit_message() to accomodate the
extra argument.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
archive.c | 2 +-
builtin-branch.c | 3 ++-
builtin-checkout.c | 2 +-
builtin-commit.c | 4 ++--
builtin-log.c | 2 +-
builtin-merge.c | 2 +-
builtin-rev-list.c | 2 +-
builtin-shortlog.c | 2 +-
builtin-show-branch.c | 2 +-
commit.h | 7 +++++--
log-tree.c | 4 ++--
pretty.c | 20 +++++++++++++++++---
reflog-walk.c | 16 ++++++++++++++++
reflog-walk.h | 7 +++++++
14 files changed, 58 insertions(+), 17 deletions(-)
diff --git a/archive.c b/archive.c
index 0cc79d2..d325ce3 100644
--- a/archive.c
+++ b/archive.c
@@ -48,7 +48,7 @@ static void format_subst(const struct commit *commit,
strbuf_add(&fmt, b + 8, c - b - 8);
strbuf_add(buf, src, b - src);
- format_commit_message(commit, fmt.buf, buf, DATE_NORMAL);
+ format_commit_message(commit, fmt.buf, buf, DATE_NORMAL, NULL);
len -= c + 1 - src;
src = c + 1;
}
diff --git a/builtin-branch.c b/builtin-branch.c
index 9f57992..d90bfaf 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -388,7 +388,8 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
commit = item->commit;
if (commit && !parse_commit(commit)) {
pretty_print_commit(CMIT_FMT_ONELINE, commit,
- &subject, 0, NULL, NULL, 0, 0);
+ &subject, 0, NULL, NULL, 0, 0,
+ NULL);
sub = subject.buf;
}
diff --git a/builtin-checkout.c b/builtin-checkout.c
index d050c37..b6b9c45 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -303,7 +303,7 @@ static void describe_detached_head(char *msg, struct commit *commit)
{
struct strbuf sb = STRBUF_INIT;
parse_commit(commit);
- pretty_print_commit(CMIT_FMT_ONELINE, commit, &sb, 0, NULL, NULL, 0, 0);
+ pretty_print_commit(CMIT_FMT_ONELINE, commit, &sb, 0, NULL, NULL, 0, 0, NULL);
fprintf(stderr, "%s %s... %s\n", msg,
find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV), sb.buf);
strbuf_release(&sb);
diff --git a/builtin-commit.c b/builtin-commit.c
index 200ffda..d63d467 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -685,7 +685,7 @@ static int message_is_empty(struct strbuf *sb)
commit = get_revision(&revs);
if (commit) {
strbuf_release(&buf);
- format_commit_message(commit, "%an <%ae>", &buf, DATE_NORMAL);
+ format_commit_message(commit, "%an <%ae>", &buf, DATE_NORMAL, NULL);
return strbuf_detach(&buf, NULL);
}
die("No existing author found with '%s'", name);
@@ -943,7 +943,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
if (!log_tree_commit(&rev, commit)) {
struct strbuf buf = STRBUF_INIT;
- format_commit_message(commit, format + 7, &buf, DATE_NORMAL);
+ format_commit_message(commit, format + 7, &buf, DATE_NORMAL, NULL);
printf("%s\n", buf.buf);
strbuf_release(&buf);
}
diff --git a/builtin-log.c b/builtin-log.c
index 25e21ed..57df76e 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -1305,7 +1305,7 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
if (verbose) {
struct strbuf buf = STRBUF_INIT;
pretty_print_commit(CMIT_FMT_ONELINE, commit,
- &buf, 0, NULL, NULL, 0, 0);
+ &buf, 0, NULL, NULL, 0, 0, NULL);
printf("%c %s %s\n", sign,
sha1_to_hex(commit->object.sha1), buf.buf);
strbuf_release(&buf);
diff --git a/builtin-merge.c b/builtin-merge.c
index b6b8428..70f1488 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -291,7 +291,7 @@ static void squash_message(void)
strbuf_addf(&out, "commit %s\n",
sha1_to_hex(commit->object.sha1));
pretty_print_commit(rev.commit_format, commit, &out, rev.abbrev,
- NULL, NULL, rev.date_mode, 0);
+ NULL, NULL, rev.date_mode, 0, NULL);
}
if (write(fd, out.buf, out.len) < 0)
die_errno("Writing SQUASH_MSG");
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 4ba1c12..78659c8 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -98,7 +98,7 @@ static void show_commit(struct commit *commit, void *data)
struct strbuf buf = STRBUF_INIT;
pretty_print_commit(revs->commit_format, commit,
&buf, revs->abbrev, NULL, NULL,
- revs->date_mode, 0);
+ revs->date_mode, 0, NULL);
if (revs->graph) {
if (buf.len) {
if (revs->commit_format != CMIT_FMT_ONELINE)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index 4d4a3c8..128b382 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -160,7 +160,7 @@ void shortlog_add_commit(struct shortlog *log, struct commit *commit)
struct strbuf buf = STRBUF_INIT;
pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &buf,
- DEFAULT_ABBREV, "", "", DATE_NORMAL, 0);
+ DEFAULT_ABBREV, "", "", DATE_NORMAL, 0, NULL);
insert_one_record(log, author, buf.buf);
strbuf_release(&buf);
return;
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index be95930..73ea7ce 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -294,7 +294,7 @@ static void show_one_commit(struct commit *commit, int no_name)
if (commit->object.parsed) {
pretty_print_commit(CMIT_FMT_ONELINE, commit,
- &pretty, 0, NULL, NULL, 0, 0);
+ &pretty, 0, NULL, NULL, 0, 0, NULL);
pretty_str = pretty.buf;
}
if (!prefixcmp(pretty_str, "[PATCH] "))
diff --git a/commit.h b/commit.h
index f4fc5c5..93efeeb 100644
--- a/commit.h
+++ b/commit.h
@@ -69,14 +69,17 @@ enum cmit_fmt {
extern char *reencode_commit_message(const struct commit *commit,
const char **encoding_p);
extern void get_commit_format(const char *arg, struct rev_info *);
+struct reflog_walk_info;
extern void format_commit_message(const struct commit *commit,
const void *format, struct strbuf *sb,
- enum date_mode dmode);
+ enum date_mode dmode,
+ struct reflog_walk_info *reflog_info);
extern void pretty_print_commit(enum cmit_fmt fmt, const struct commit*,
struct strbuf *,
int abbrev, const char *subject,
const char *after_subject, enum date_mode,
- int need_8bit_cte);
+ int need_8bit_cte,
+ struct reflog_walk_info *reflog_info);
void pp_user_info(const char *what, enum cmit_fmt fmt, struct strbuf *sb,
const char *line, enum date_mode dmode,
const char *encoding);
diff --git a/log-tree.c b/log-tree.c
index 1618f3c..e75f953 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -179,7 +179,7 @@ void get_patch_filename(struct commit *commit, int nr, const char *suffix,
if (commit) {
int max_len = start_len + FORMAT_PATCH_NAME_MAX - suffix_len;
- format_commit_message(commit, "%f", buf, DATE_NORMAL);
+ format_commit_message(commit, "%f", buf, DATE_NORMAL, NULL);
if (max_len < buf->len)
strbuf_setlen(buf, max_len);
strbuf_addstr(buf, suffix);
@@ -408,7 +408,7 @@ void show_log(struct rev_info *opt)
need_8bit_cte = has_non_ascii(opt->add_signoff);
pretty_print_commit(opt->commit_format, commit, &msgbuf,
abbrev, subject, extra_headers, opt->date_mode,
- need_8bit_cte);
+ need_8bit_cte, opt->reflog_info);
if (opt->add_signoff)
append_signoff(&msgbuf, opt->add_signoff);
diff --git a/pretty.c b/pretty.c
index f5983f8..0b67580 100644
--- a/pretty.c
+++ b/pretty.c
@@ -7,6 +7,7 @@
#include "mailmap.h"
#include "log-tree.h"
#include "color.h"
+#include "reflog-walk.h"
static char *user_format;
@@ -443,6 +444,7 @@ struct chunk {
struct format_commit_context {
const struct commit *commit;
enum date_mode dmode;
+ struct reflog_walk_info *reflog_info;
unsigned commit_header_parsed:1;
unsigned commit_message_parsed:1;
@@ -701,6 +703,14 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
case 'd':
format_decoration(sb, commit);
return 1;
+ case 'g': /* reflog handle */
+ if (c->reflog_info)
+ get_reflog_selector(sb, c->reflog_info, c->dmode);
+ return 1;
+ case 'G': /* reflog message */
+ if (c->reflog_info)
+ get_reflog_message(sb, c->reflog_info);
+ return 1;
}
/* For the rest we have to parse the commit header. */
@@ -741,13 +751,15 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
void format_commit_message(const struct commit *commit,
const void *format, struct strbuf *sb,
- enum date_mode dmode)
+ enum date_mode dmode,
+ struct reflog_walk_info *reflog_info)
{
struct format_commit_context context;
memset(&context, 0, sizeof(context));
context.commit = commit;
context.dmode = dmode;
+ context.reflog_info = reflog_info;
strbuf_expand(sb, format, format_commit_item, &context);
}
@@ -902,7 +914,8 @@ void pp_remainder(enum cmit_fmt fmt,
void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
struct strbuf *sb, int abbrev,
const char *subject, const char *after_subject,
- enum date_mode dmode, int need_8bit_cte)
+ enum date_mode dmode, int need_8bit_cte,
+ struct reflog_walk_info *reflog_info)
{
unsigned long beginning_of_body;
int indent = 4;
@@ -911,7 +924,8 @@ void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
const char *encoding;
if (fmt == CMIT_FMT_USERFORMAT) {
- format_commit_message(commit, user_format, sb, dmode);
+ format_commit_message(commit, user_format, sb, dmode,
+ reflog_info);
return;
}
diff --git a/reflog-walk.c b/reflog-walk.c
index 9478dbc..929f025 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -265,6 +265,22 @@ void get_reflog_selector(struct strbuf *sb,
strbuf_addch(sb, '}');
}
+void get_reflog_message(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info)
+{
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
+ struct reflog_info *info;
+
+ if (!commit_reflog)
+ return;
+
+ info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ size_t len = strlen(info->message);
+ if (len > 0)
+ len--;
+ strbuf_add(sb, info->message, len);
+}
+
void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
enum date_mode dmode)
{
diff --git a/reflog-walk.h b/reflog-walk.h
index 74c9096..986121f 100644
--- a/reflog-walk.h
+++ b/reflog-walk.h
@@ -3,6 +3,8 @@
#include "cache.h"
+struct reflog_walk_info;
+
extern void init_reflog_walk(struct reflog_walk_info** info);
extern int add_reflog_for_walk(struct reflog_walk_info *info,
struct commit *commit, const char *name);
@@ -10,5 +12,10 @@ extern void fake_reflog_parent(struct reflog_walk_info *info,
struct commit *commit);
extern void show_reflog_message(struct reflog_walk_info *info, int,
enum date_mode);
+extern void get_reflog_message(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info);
+extern void get_reflog_selector(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info,
+ enum date_mode dmode);
#endif
--
1.6.5.64.g01287
^ permalink raw reply related
* [RFC PATCH 3/5] stash: Use new %g/%G formats instead of sed
From: Thomas Rast @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jef Driesen; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <cover.1255380039.git.trast@student.ethz.ch>
With the new formats, we can rewrite 'git stash list' in terms of an
appropriate pretty format, instead of hand-editing with sed. This has
the advantage that it obeys the normal settings for git-log, notably
the pager.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-stash.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 4febbbf..8fbf10a 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -205,8 +205,7 @@ have_stash () {
list_stash () {
have_stash || return 0
- git log --no-color --pretty=oneline -g "$@" $ref_stash -- |
- sed -n -e 's/^[.0-9a-f]* refs\///p'
+ git log --format="%g: %G" -g "$@" $ref_stash
}
show_stash () {
--
1.6.5.64.g01287
^ permalink raw reply related
* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Junio C Hamano @ 2009-10-12 21:06 UTC (permalink / raw)
To: Anders Kaseorg; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0910121237540.2223@dr-wily.mit.edu>
Anders Kaseorg <andersk@MIT.EDU> writes:
> ‘git bisect reset’ could already checkout an arbitrary commit if you
> were on a detached HEAD before starting the bisection. This lets you
> specify an arbitrary commit to ‘git bisect reset <commit>’.
>
> This also provides a way to clean the bisection state without moving
> HEAD: ‘git bisect reset HEAD’.
>
> Signed-off-by: Anders Kaseorg <andersk@mit.edu>
> ---
> git-bisect.sh | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/git-bisect.sh b/git-bisect.sh
> index 6f6f039..d319b9f 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -311,8 +311,7 @@ bisect_reset() {
> }
> case "$#" in
> 0) branch=$(cat "$GIT_DIR/BISECT_START") ;;
> - 1) git show-ref --verify --quiet -- "refs/heads/$1" ||
> - die "$1 does not seem to be a valid branch"
> + 1) git rev-parse --verify "$1^{commit}" || exit
> branch="$1" ;;
> *)
> usage ;;
Thanks.
The "one parameter" case dates back to the original bisect implementation
in commit 8cc6a08 (Making it easier to find which change introduced a bug,
2005-07-30), and the only reason of existence for that case was that the
code looked like this back then:
bisect_reset() {
case "$#" in
0) branch=master ;;
1) test -f "$GIT_DIR/refs/heads/$1" || {
echo >&2 "$1 does not seem to be a valid branch"
exit 1
}
branch="$1" ;;
*)
usage ;;
esac
...
An important difference to notice, compared to a more recent version, is
that we did not remember (nor use) the original branch, and without an
argument we always switched to 'master'. Back then, the user who started
bisecting a side branch needed to remember the name of the branch before
starting the bisection, and needed to give that to the reset subcommand.
Because we remember where we came from these days, I do not think it makes
much sense to even keep this "one parameter" case, let alone extending
this interface to allow switching to an arbitrary commit.
I even think that the support for an explicit branch name in the reset
subcommand should eventually be deprecated, perhaps unless it matches what
is stored in BISECT_START.
The documentation, does not even talk about what the optional <branch>
argument is good for, even though it lists the optional <branch> in the
synopsis section.
Having said all that, four years and two months are looooooong time in git
timescale, and I am discounting, without any evidence to judge either way,
the possibility that people may have learned during that time to (ab)use
this as a (very useful?) shortcut to finish the current bisection and
switch to some entirely different branch.
I offhand do not see a good rationale for such a shortcut to finish bisect
and switch to another branch (IOW, I understand "it is shorter to type",
but I do not see "it is often done and very useful"), but I am open to be
enlightened by a workflow where such a shortcut is useful.
^ permalink raw reply
* [RFC PATCH 0/5] Pretty formats for reflog data
From: Thomas Rast @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jef Driesen, Jef Driesen; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <20091012175201.GA10263@coredump.intra.peff.net>
[I forgot to address the list on the first batch, sorry for the spam.]
Jeff King wrote:
> 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".
This seems fairly arbitrary, doesn't it? My own working theory is
that Nanako put it in because the git-log|sed construct inherently
bars any way to a pager, so it needs to be cut short.
So suppose we could somehow get rid of the |sed... like if we had
--pretty specifiers for the reflog information.
Sadly
git log -g --format="%h %g: %G"
still fails to exactly replicate the reflog format: if the reflog was
cut off during garbage collection, the last entry refers to a no
longer existing commit causing a stray ':' on that line. Oh, well.
It's also still RFC because:
* I don't like the massive code churn in 2/5, maybe someone sees a
better option.
* 5/5 has a pretty lame excuse. I could also just change it in 'git
stash list' to limit the backwards-incompatibility damage, but
that's also a maintenance headache.
Thomas Rast (5):
reflog-walk: refactor the branch@{num} formatting
Introduce new pretty formats %g and %G for reflog information
stash: Use new %g/%G formats instead of sed
stash list: drop the default limit of 10 stashes
stash: change built-in ref to 'stash' instead of 'refs/stash'
archive.c | 2 +-
builtin-branch.c | 3 +-
builtin-checkout.c | 2 +-
builtin-commit.c | 4 +-
builtin-log.c | 2 +-
builtin-merge.c | 2 +-
builtin-rev-list.c | 2 +-
builtin-shortlog.c | 2 +-
builtin-show-branch.c | 2 +-
commit.h | 7 +++-
git-stash.sh | 10 +-----
log-tree.c | 4 +-
pretty.c | 20 +++++++++++--
reflog-walk.c | 72 ++++++++++++++++++++++++++++++++++---------------
reflog-walk.h | 7 +++++
15 files changed, 94 insertions(+), 47 deletions(-)
^ permalink raw reply
* [RFC PATCH 1/5] reflog-walk: refactor the branch@{num} formatting
From: Thomas Rast @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jef Driesen; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <cover.1255380039.git.trast@student.ethz.ch>
We'll use the same output in an upcoming commit, so refactor its
formatting (which was duplicated anyway) into a separate function.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
reflog-walk.c | 56 ++++++++++++++++++++++++++++++++++----------------------
1 files changed, 34 insertions(+), 22 deletions(-)
diff --git a/reflog-walk.c b/reflog-walk.c
index 5623ea6..9478dbc 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -241,36 +241,48 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)
commit->object.flags &= ~(ADDED | SEEN | SHOWN);
}
-void show_reflog_message(struct reflog_walk_info *info, int oneline,
+void get_reflog_selector(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info,
+ enum date_mode dmode)
+{
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
+ struct reflog_info *info;
+
+ if (!commit_reflog)
+ return;
+
+ strbuf_addf(sb, "%s@{", commit_reflog->reflogs->ref);
+ if (commit_reflog->flag || dmode) {
+ info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ strbuf_addf(sb, "%s", show_date(info->timestamp,
+ info->tz,
+ dmode));
+ } else {
+ strbuf_addf(sb, "%d", commit_reflog->reflogs->nr
+ - 2 - commit_reflog->recno);
+ }
+
+ strbuf_addch(sb, '}');
+}
+
+void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
enum date_mode dmode)
{
- if (info && info->last_commit_reflog) {
- struct commit_reflog *commit_reflog = info->last_commit_reflog;
+ if (reflog_info && reflog_info->last_commit_reflog) {
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
struct reflog_info *info;
+ struct strbuf selector = STRBUF_INIT;
info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ get_reflog_selector(&selector, reflog_info, dmode);
if (oneline) {
- printf("%s@{", commit_reflog->reflogs->ref);
- if (commit_reflog->flag || dmode)
- printf("%s", show_date(info->timestamp,
- info->tz,
- dmode));
- else
- printf("%d", commit_reflog->reflogs->nr
- - 2 - commit_reflog->recno);
- printf("}: %s", info->message);
+ printf("%s: %s", selector.buf, info->message);
}
else {
- printf("Reflog: %s@{", commit_reflog->reflogs->ref);
- if (commit_reflog->flag || dmode)
- printf("%s", show_date(info->timestamp,
- info->tz,
- dmode));
- else
- printf("%d", commit_reflog->reflogs->nr
- - 2 - commit_reflog->recno);
- printf("} (%s)\nReflog message: %s",
- info->email, info->message);
+ printf("Reflog: %s (%s)\nReflog message: %s",
+ selector.buf, info->email, info->message);
}
+
+ strbuf_release(&selector);
}
}
--
1.6.5.64.g01287
^ 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