Re: [Xen-devel] Moving xen*.hg to git

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-02-21 at 15:51 +0000, Jan Beulich wrote:
> >>> On 21.02.13 at 16:18, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Thu, 2013-02-21 at 14:55 +0000, Jan Beulich wrote:
> >> >>> On 20.02.13 at 16:27, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> >> > If any committer needs help getting git to work please feel free to
> >> > ask.  git has many advantages but its user interface has received very
> >> > mixed reviews.  We appreciate that you might need handholding.  So if
> >> > you get confused, or into trouble, do consult.
> >> 
> >> So one thing I found very handy with hg was that there was a
> >> single line history with easy to look at changeset numbers. Is there
> >> any way to achieve the same with git? I'm asking particularly in the
> >> context of backporting: In order to pick changes from unstable (now
> >> master), so far I simply scanned the history, tracking (on a sheet of
> >> paper) at which c/s I last left off.
> > 
> > Something like git log --oneline?
> > 
> > You can also git log --pretty=format:%...
> 
> The question is whether these, just like the web interface, sort
> by commit time rather than commit order.

git rev-list mentions --topo-order and --date-order, and git log just
forwards these on. I think --date-order is what you want?

Not sure about the webterface.

> And ideally it would be doable both locally and from the web
> interface, yet I don't see the web interface having any way to
> control how it sorts its output.
> 
> > Where there are various available %foo described in the manpage.
> > 
> > git doesn't really have a concept of the shorter sequential numbers
> > which mercurial has. The closest I can think of is the sort of thing
> > which git describe outputs.
> 
> Again, it depends how the number produced here gets calculated,
> i.e. whether it remains stable over the lifetime of a tree regardless
> of what commits get pulled (and merges get done).

That isn't true of the Mercurial ones either. At least not in general,
perhaps our not-very-branching structure makes it mostly true in
practice.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel