[lkml]   [2005]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    SubjectRe: Updated git HOWTO for kernel hackers

    On Wed, 22 Jun 2005, Jeff Garzik wrote:
    > The output isn't terribly helpful:

    Yeah. The good news is that if something bad happens, it surely lets you
    know, and it's very verbose about that.

    I should probably remove the "Fragment applied at offset xx" thing, it was
    basically a debugging message to make sure that I applied patch fragments
    correctly even if the line offset given in the patch was sligthly off..

    > Outputting the following (stolen from 'git commit') would be far more
    > useful:
    > modified: Documentation/networking/cxgb.txt
    > modified: drivers/net/chelsio/Makefile
    > deleted: drivers/net/chelsio/ch_ethtool.h
    > modified: drivers/net/chelsio/common.h
    > modified: drivers/net/chelsio/cphy.h
    > modified: drivers/net/chelsio/cpl5_cmd.h
    > modified: drivers/net/chelsio/cxgb2.c
    > deleted: drivers/net/chelsio/cxgb2.h
    > modified: drivers/net/chelsio/elmer0.h
    > modified: drivers/net/chelsio/espi.c
    > modified: drivers/net/chelsio/espi.h
    > modified: drivers/net/chelsio/gmac.h
    > modified: drivers/net/chelsio/mv88x201x.c
    > deleted: drivers/net/chelsio/osdep.h
    > modified: drivers/net/chelsio/pm3393.c
    > modified: drivers/net/chelsio/regs.h
    > modified: drivers/net/chelsio/sge.c
    > modified: drivers/net/chelsio/sge.h
    > modified: drivers/net/chelsio/subr.c
    > modified: drivers/net/chelsio/suni1x10gexp_regs.h
    > deleted: drivers/net/chelsio/tp.c
    > deleted: drivers/net/chelsio/tp.h
    > modified: include/linux/pci_ids.h

    How about this patch? Then you can say

    git-apply --stat --summary --apply --index /tmp/my.patch

    and it will not only apply the patch, but also give a diffstat and a
    summary or renames etc..

    This also removes the "Fragment.." debugging message.

    Btw, "--stat" and "--summary" normally turn off the "apply" flag, so
    "--apply" has to come _after_ the stat/summary thing, fwiw:

    diff --git a/apply.c b/apply.c
    --- a/apply.c
    +++ b/apply.c
    @@ -860,7 +860,6 @@ static int find_offset(const char *buf,
    n = (i >> 1)+1;
    if (i & 1)
    n = -n;
    - fprintf(stderr, "Fragment applied at offset %d\n", n);
    return try;

    @@ -1434,6 +1433,10 @@ int main(int argc, char **argv)
    check_index = 1;
    + if (!strcmp(arg, "--apply")) {
    + apply = 1;
    + continue;
    + }
    if (!strcmp(arg, "--show-files")) {
    show_files = 1;
    > > Also, you can do
    > >
    > > git commit <list-of-files-to-commit>
    > >
    > > as a shorthand for
    > >
    > > git-update-cache <list-of-files-to-commit>
    > > git commit
    > >
    > > which some people will probably find more natural.
    > It would be natural if it functioned like 'bk citool' ;-)
    > git commit --figure-out-for-me-what-files-changed
    > 'git diff' can do this, so it's certainly feasible.

    Well, it _does_ do that. That's what the "git status" thing does, and look
    at the initial commit message comments that it prepares for you: it tells
    you which files are modified but haven't been marked for check-in etc.

    But the thing is, you need to have a graphical tool for that. I don't want
    to have some silly command line that asks for each modified file whether
    you want to include that file in the commit or not.

    So this is where "git" ends, and a nice user interface (written by
    somebody else than me) begins. Ie this is a cogito-like thing.

    > > "git-whatchanged" is useful if you actually want to see what the commits
    > > _changed_, and then you often want to use the "-p" flag to see it as
    > > patches. Also, it's worth pointing out the fact that you can limit it to
    > > certain subdirectories (or individual files) etc, ie:
    > >
    > > git-whatchanged -p drivers/net
    > >
    > > since that is often what people want.
    > >
    > > But if you just want the log, "git log" is faster and simpler and more
    > > correct.
    > I usually want just two things:
    > 1) browse the log
    > 2) list changes in local tree that are not in $remote_tree, a la
    > bk changes -L ../linux-2.6
    > I agree that seeing the merge csets is useful, that is why [being
    > ignorant of 'git log'] I used git-changes-script.

    For (1) "bk log" is good. For (2) you'll have to use your own script, or
    just have the remote tree as a branch in the same tree, in which case you
    can do

    git log remotebranch..mybranch

    and it will do what you expect. In fact, since "HEAD" is the default
    branch for the final one, you can do

    git log remotebranch..

    and you'll get the log of everything that is in your HEAD but it _not_ in
    the "remotebranch" branch.

    Btw, if you have the remote as a branch in your own tree, you can also do

    gitk remotebranch..mybranch

    which is a really nice way of graphically seeing "what is in 'mybranch'
    that is not in 'remotebranch'".

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-11-18 23:46    [W:0.027 / U:3.032 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site