git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH 00/23] RFC: Introducing git-test, git-atomic, git-base and git-work

From
Jon Seymour <jon.seymour@gmail.com>
Date
Apr 23, 2011, 07:22 UTC
Message-ID
<1303543372-77843-1-git-send-email-jon.seymour@gmail.com>
This series is posted in order to solicit feedback about some commands I'd like to propose for inclusion in git. 
The commands are:
   git test
   git atomic
   git base
   git work

git work ========

git work depends on the other 3 commands. 

git work is the command I have been using every day myself for the last 8 months. It is the primary means I use to manage my working tree.

The basic idea of git work is to help manage a private working tree using the following principles:
* all dependencies received from others are merged into the 'base' of the working tree
  git work merge some-dependency
     - merges some-dependency into $(git base) producing (1)
     - rebases $(git base)..HEAD onto (1) producing (2)
     - resets the current branch to (2)
     - updates $(git base) to refer to (1)
* all unpublished work is managed as a linear sequence of commits on top of the 'base' of the working tree
  so, 
   git work --as-refs # shows you a symbolic range for your current work
   git work # shows you a SHA1 range for your current work
   gitk $(git work) # shows you your unpublished work
   git diff $(git work) # shows you the diff of your current work
* prior to publishing work, you rebase it onto an appropriate base commit
  so,
  git branch topic upstream/master # choose the base commit for the topic
  git work update topic HEAD~3     # pull the top 3 commits off the working tree onto the topic
    - rebases HEAD~3..HEAD onto topic to produce (1)
    - merges topic into $(git base) to produce (2)
    - rebases $(git base)..HEAD~3 onto (2) to produce (3)
    - resets the current branch to (3)
    - resets $(git base) to (2)

The nice thing about managing your work tree this way is that your working tree remains relatively stable (it always contains everything you have recently been working on) and your topic branches remain clean (i.e. they never contain any other cruft from your working tree).

git base ========

git base is a command that is heavily relied on by git work, and is occasionally used by the user to reset the base of their working tree.

git base tries to automagically maintain the base of the working tree by maintaining an invariant that the path between the base and the tip of the current branch should never traverse a merge. If it ever finds the invariant violated, it calls 'git base reset' to attempt to restore the invariant.

For more information about git base, refer to the Documentation/git-base.txt

git atomic ========== git atomic is more an experiment than anything else. The idea is to run another git operation "atomically". The git operation either succeeds or it fails. If it fails, git branch attempts to restore the working tree and current branch to the state they were in to their original state prior to the comamnd being run.

The reason I need something like this is that git work performs several operations in sequence some of which I can't guarantee will work. I don't want the user to work out what they have to do to recover, so I try to restore to the state they were originally in.

Note: the current implementation doesn't handle rebase failures properly and would probably needed
to be cleaned up a little before being accepted into the mainline.

git test ======== This is another experiment. The idea is to provide a uniform way to test for various conditions into the working tree, index and repo. For example:

    git test --not-unstaged --branch-exists foobar
will fail if there are unstaged files in the working tree or the branch foobar does not exist.

As I say, git atomic and git test are somewhat experimental. I don't really care about those commands and if the consensus is that git doesn't need them, I am happy to rework git base and git work to not use them.

However, I would like to propose git base and git work as being very useful additions to the git toolset.
Let me know if the consensus is that I should proceed with a submission and I will prepare one.
Jon Seymour (23):
  Introduce git-test.sh and git-test-lib.sh
  Introduce --unstaged.
  Introduce --staged
  Introduce --untracked.
  Introduce --conflicted
  Introduce --rebasing
  Introduce --detached
  Introduce --branch-exists
  Introduce --tag-exists
  Introduce --ref-exists
  Introduce --commit-exists.
  Introduce --checked-out
  Introduce --reachable
  Introduce --tree-same.
  Introduce --same
  misc
  whitespace fix.
  tests --conflicted.
  rebasing: add tests
  test: git test cleanups.
  Introduce git-atomic.
  Introduce git base.
  Introduce support for the git-work command.
 .gitignore                   |    7 +
 Documentation/config.txt     |   10 +
 Documentation/git-atomic.txt |   92 ++++++++
 Documentation/git-base.txt   |  216 ++++++++++++++++++
 Documentation/git-test.txt   |  182 +++++++++++++++
 Documentation/git-work.txt   |  163 ++++++++++++++
 Makefile                     |    7 +
 git-atomic-lib.sh            |   58 +++++
 git-atomic.sh                |    5 +
 git-base.sh                  |  378 +++++++++++++++++++++++++++++++
 git-conditions-lib.sh        |  176 +++++++++++++++
 git-test-lib.sh              |  188 ++++++++++++++++
 git-test.sh                  |   11 +
 git-work.sh                  |  323 +++++++++++++++++++++++++++
 t/t1520-test.sh              |  506 ++++++++++++++++++++++++++++++++++++++++++
 t/t3418-base.sh              |  214 ++++++++++++++++++
 t/t3419-atomic.sh            |   59 +++++
 t/t3421-work.sh              |  174 +++++++++++++++
 18 files changed, 2769 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/git-atomic.txt
 create mode 100644 Documentation/git-base.txt
 create mode 100644 Documentation/git-test.txt
 create mode 100644 Documentation/git-work.txt
 create mode 100644 git-atomic-lib.sh
 create mode 100755 git-atomic.sh
 create mode 100644 git-base.sh
 create mode 100644 git-conditions-lib.sh
 create mode 100644 git-test-lib.sh
 create mode 100755 git-test.sh
 create mode 100644 git-work.sh
 create mode 100755 t/t1520-test.sh
 create mode 100755 t/t3418-base.sh
 create mode 100755 t/t3419-atomic.sh
 create mode 100755 t/t3421-work.sh
-- 
1.7.5.rc1.23.g7f622
Next: Jon Seymour
Message 1 of 29 in “RFC: Introducing git-test, git-atomic, git-base and git-work”
  1. 00/23 RFC: Introducing git-test, git-atomic, git-base and git-workJon Seymour, Apr 23, 2011
  2. 01/23 Introduce git-test.sh and git-test-lib.shJon Seymour, Apr 23, 2011
  3. Drew NorthupApr 27, 2011
  4. 02/23 Introduce --unstaged.Jon Seymour, Apr 23, 2011
  5. 03/23 Introduce --stagedJon Seymour, Apr 23, 2011
  6. 04/23 Introduce --untracked.Jon Seymour, Apr 23, 2011
  7. 05/23 Introduce --conflictedJon Seymour, Apr 23, 2011
  8. 06/23 Introduce --rebasingJon Seymour, Apr 23, 2011
  9. 07/23 Introduce --detachedJon Seymour, Apr 23, 2011
  10. 08/23 Introduce --branch-existsJon Seymour, Apr 23, 2011
  11. 09/23 Introduce --tag-existsJon Seymour, Apr 23, 2011
  12. 10/23 Introduce --ref-existsJon Seymour, Apr 23, 2011
  13. 11/23 Introduce --commit-exists.Jon Seymour, Apr 23, 2011
  14. 12/23 Introduce --checked-outJon Seymour, Apr 23, 2011
  15. 13/23 Introduce --reachableJon Seymour, Apr 23, 2011
  16. 14/23 Introduce --tree-same.Jon Seymour, Apr 23, 2011
  17. 15/23 Introduce --sameJon Seymour, Apr 23, 2011
  18. 16/23 miscJon Seymour, Apr 23, 2011
  19. 17/23 whitespace fix.Jon Seymour, Apr 23, 2011
  20. 18/23 tests --conflicted.Jon Seymour, Apr 23, 2011
  21. 19/23 rebasing: add testsJon Seymour, Apr 23, 2011
  22. 20/23 test: git test cleanups.Jon Seymour, Apr 23, 2011
  23. 21/23 Introduce git-atomic.Jon Seymour, Apr 23, 2011
  24. 22/23 Introduce git base.Jon Seymour, Apr 23, 2011
  25. 23/23 Introduce support for the git-work command.Jon Seymour, Apr 23, 2011
  26. Peter BaumannApr 23, 2011
  27. Jon SeymourApr 23, 2011
  28. Jon SeymourApr 23, 2011
  29. Jon SeymourApr 24, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.