filter bzr log by branch nick

I think there are a few possibilities for something like this.

I would probably call it '--nick', just like you can search based on '--message'. 'bzr log --message REGEX' uses a regular expression, rather than a direct match, but I think we could do either for --nick. I wouldn't use a glob, though.

One further possibility, would be to expose something like an SQL layer for queries. A possible implementation is to load all revision information, shove it into a sqlite :memory: file, and then run whatever SQL query the user asked. It would probably be a nice plugin to have around.

It certainly would also be possible to keep the sqlite file around in a cache. Probably more of a plugin than a core feature. But '--nick' could certainly be a core feature. (Since generating branch-nick is a core feature)

On (16/07/07 20:34), John A Meinel wrote:
> I think there are a few possibilities for something like this.
>
> I would probably call it '--nick', just like you can search based on '--
> message'. 'bzr log --message REGEX' uses a regular expression, rather
> than a direct match, but I think we could do either for --nick. I
> wouldn't use a glob, though.
>
> One further possibility, would be to expose something like an SQL layer
> for queries. A possible implementation is to load all revision
> information, shove it into a sqlite :memory: file, and then run whatever
> SQL query the user asked. It would probably be a nice plugin to have
> around.
>
> It certainly would also be possible to keep the sqlite file around in a
> cache. Probably more of a plugin than a core feature. But '--nick' could
> certainly be a core feature. (Since generating branch-nick is a core
> feature)
>

That would give the ultimate flexibility.

An intermediate solution may be to expose a free text search, so that
you can have

  Branch nick: fix-12345

as the query to cover this use case, but it also works for people to
match other things like date, committer etc.

However then you may want to do

  Author: James Westby.*Fix 12345

to match across multiple fields, but then there needs to be an ordering
to the fields defined and maintained. This could be based on bzr log
output, but if new fields are added they would probably go before the
message there, but that may break complicated regexps.

Thanks,

James

--
  James Westby -- GPG Key ID: B577FE13 -- http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Barry Warsaw wrote:
> Public bug reported:
>
> I often don't know how far back I want bzr log to display, except that I know
> I don't want it to go back to the beginning of time. What I really want is to
> see a log of all the changes I made on a particular branch.

Another way of addressing that is to determine the branch-point and show
all logs since then. That would require querying the parent branch,
which could be slow or impossible if the parent branch was non-local.

I think it would be reasonable to store the branch point as local data, too.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGm+JH0F+nu1YWqI0RAoiPAJ97GDvGIfAXpTYy2YukP6Kylmr9eQCfeXKo
wDBqko47NZ5t/06QDA8JxOI=
=s/va
-----END PGP SIGNATURE-----

>
> Bug description:
> I often don't know how far back I want bzr log to display, except that I
> know
> I don't want it to go back to the beginning of time. What I really want is
> to
> see a log of all the changes I made on a particular branch.
>
> It would be nice if I could do something like
>
> bzr log -n my-branch-nick
>
> and see all the revisions that have a matching branch nick.
>

maybe we can do this with a revisionspec eg:
bzr log -c nick:my-branch-nick
bzr log -r nick:my-branch-nick..

I think that a new revisionspec (or two) is the best solution here. I suggest the following new revisionspecs:

  tip:mergerevno_or_nick
  split:mergerevno_or_nick
  join:mergerevno_or_nick

where mergerevno is the first two parts of the revno. Some examples ...

Display a merge by mergerevno:

  bzr log -r1.400.1..tip:1.400

Display a merge by nick including the place it split from the mainline/parent-mergeline:

  bzr log -rsplit:my-fix..-rtip:my-fix

Display what happened on the mainline between my-fix and your-fix:

  bzr log -rjoin:my-fix..join:your-fix

I suspect the nick can change along a mergeline. I think we ought to ignore that and treat the final nick as the one identifying that mergeline.

FWIW, as part of my work on speeding up revno->revision-id lookup, I'm looking at caching mergeline information (in bzr-revnocache initially) so I think we could make the above fast operations via that cache in good time.

Just to chime in the query-language idea, I'd really like to filter by committer — namely to see commits done by me. On one multi-user project I work on, I frequently go back to my previous commits to see how I did something.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/13/2011 12:25 AM, Brian de Alwis wrote:
> Just to chime in the query-language idea, I'd really like to filter
> by committer — namely to see commits done by me. On one multi-user
> project I work on, I frequently go back to my previous commits to
> see how I did something.
>

"bzr log --match-author=XXX" is already present in bzr-2.4.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5wUQ0ACgkQJdeBCYSNAAM9+QCfTxjcf4OPip+Jf/mJmR5tvxKE
OwYAnRuOQtk0+V/PzKeyR/w4cFXU7kMR
=3Nid
-----END PGP SIGNATURE-----