Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 17 9月, 2012 6 次提交
    • P
      git p4: test clean-up after failed submit, fix added files · f7fbc981
      由 Pete Wyckoff 提交于 
      Test a variety of cases where a patch failed to apply to
p4 and had to be cleaned up.

If the patch failed to apply cleanly, do not try to remove
to-be-added files, as they have not really been added yet.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      f7fbc981
    • P
      git p4: standardize submit cancel due to unchanged template · 5a41c16a
      由 Pete Wyckoff 提交于 
      When editing the submit template, if no change was made to it,
git p4 offers a prompt "Submit anyway?".  Answering "no" cancels
the submit.

Previously, a "no" answer behaves like a "[s]kip" answer to the
failed-patch prompt, in that it proceeded to try to apply the
rest of the commits.  Instead, put users back into the new
"[s]kip / [c]ontinue" loop so that they can decide.  This makes
both cases of patch failure behave identically.

The return code of git p4 after a "no" answer is now the same
as that for a "skip" due to failed patch; update a test to
understand this.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      5a41c16a
    • P
      git p4: move conflict prompt into run, add [q]uit input · 7e5dd9f2
      由 Pete Wyckoff 提交于 
      When applying a commit to the p4 workspace fails, a prompt
asks what to do next.  This belongs up in run() instead
of in applyCommit(), where run() can notice, for instance,
that the prompt is unnecessary because this is the last commit.

Offer two options about how to continue at conflict: [s]kip or
[q]uit.  Having an explicit "quit" option gives git p4 a chance
to clean up, show the applied-commit summary, and do tag export.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      7e5dd9f2
    • P
      git p4: remove submit failure options [a]pply and [w]rite · 449bb9cf
      由 Pete Wyckoff 提交于 
      When a patch failed to apply, these interactive options offered
to:

    1) apply the patch anyway, leaving reject (.rej) files around, or,
    2) write the patch to a file (patch.txt)

In both cases it suggested to invoke "git p4 submit --continue",
an unimplemented option.

While manually fixing the rejects and submitting the result might
work, there are many steps that must be done to the job properly:

    * apply patch
    * invoke p4 add and delete
    * change executable bits
    * p4 sync -f renamed/copied files
    * extract commit message into p4 change description and
      move Jobs lines out of description section
    * set changelist owner for --preserve-user

Plus the following manual sync/rebase will cause conflicts too,
which must be resolved once again.

Drop these workflows.  Instead users should do a sync/rebase in
git, fix the conflicts there, and do a clean "git p4 submit".
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      449bb9cf
    • P
      git p4: gracefully fail if some commits could not be applied · 67b0fe2e
      由 Pete Wyckoff 提交于 
      If a commit fails to apply cleanly to the p4 tree, an interactive
prompt asks what to do next.  In all cases (skip, apply, write),
the behavior after the prompt had a few problems.

Change it so that it does not claim erroneously that all commits
were applied.  Instead list the set of the patches under
consideration, and mark with an asterisk those that were
applied successfully.  Like this example:

    Applying 592f1f9 line5 in file1 will conflict
    ...
    Unfortunately applying the change failed!
    What do you want to do?
    [s]kip this patch / [a]pply the patch forcibly and with .rej files / [w]rite the patch to a file (patch.txt) s
    Skipping! Good luck with the next patches...
    //depot/file1#4 - was edit, reverted
    Applying b8db1c6 okay_commit_after_skip
    ...
    Change 6 submitted.
    Applied only the commits marked with '*':
      592f1f9 line5 in file1 will conflict
    * b8db1c6 okay_commit_after_skip

Do not try to sync and rebase unless all patches were applied.
If there was a conflict during the submit, there is sure to be one
at the rebase.  Let the user to do the sync and rebase manually.

This changes how a couple tets in t9810-git-p4-rcs.sh behave:

    - git p4 now does not leave files open and edited in the
      client

    - If a git commit contains a change to a file that was
      deleted in p4, the test used to check that the sync/rebase
      loop happened after the failure to apply the change.  Since
      now sync/rebase does not happen after failure, do not test
      this.  Normal rebase machinery, outside of git p4, will let
      rebase --skip work.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      67b0fe2e
    • P
      git p4 test: remove bash-ism of combined export/assignment · 8c291350
      由 Pete Wyckoff 提交于 
      Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8c291350
  3. 16 8月, 2012 5 次提交
  5. 11 8月, 2012 2 次提交
    • P
      git svn: reset invalidates the memoized mergeinfo caches · 61b472ed
      由 Peter Baumann 提交于 
      Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30),
git-svn has maintained some private per-repository caches in
.git/svn/.caches to avoid refetching and recalculating some
mergeinfo-related information with every 'git svn fetch'.

This memoization can cause problems, e.g consider the following case:

SVN repo:

  ... - a - b - c - m  <- trunk
          \        /
            d  -  e    <- branch1

The Git import of the above repo is at commit 'a' and doesn't know about
the branch1. In case of an 'git svn rebase', only the trunk of the
SVN repo is imported. During the creation of the git commit 'm', git svn
uses the svn:mergeinfo property and tries to find the corresponding git
commit 'e' to create 'm' with 'c' and 'e' as parents. But git svn rebase
only imports the current branch so commit 'e' is not imported.
Therefore git svn fails to create commit 'm' as a merge commit, because one
of its parents is not known to git. The imported history looks like this:

  ... - a - b - c - m  <- trunk

A later 'git svn fetch' to import all branches can't rewrite the commit 'm'
to add 'e' as a parent and to make it a real git merge commit, because it
was already imported.

That's why the imported history misses the merge and looks like this:

  ... - a - b - c - m  <- trunk
          \
            d  -  e    <- branch1

Right now the only known workaround for importing 'm' as a merge is to
force reimporting 'm' again from SVN, e.g. via

  $ git svn reset --revision $(git find-rev $c)
  $ git svn fetch

Sadly, this is where the behavior has regressed: git svn reset doesn't
invalidate the old mergeinfo cache, which is no longer valid for the
reimport, which leads to 'm' beeing imprted with only 'c' as parent.

As solution to this problem, this commit invalidates the mergeinfo cache
to force correct recalculation of the parents.

During development of this patch, several ways for invalidating the cache
where considered. One of them is to use Memoize::flush_cache, which will
call the CLEAR method on the underlying Memoize persistency implementation.
Sadly, neither Memoize::Storable nor the newer Memoize::YAML module
introduced in 68f532f4 could optionally be used implement the
CLEAR method, so this is not an option.

Reseting the internal hash used to store the memoized values has the same
problem, because it calls the non-existing CLEAR method of the
underlying persistency layer, too.

Considering this and taking into account the different implementations
of the memoization modules, where Memoize::Storable is not in our control,
implementing the missing CLEAR method is not an option, at least not if
Memoize::Storable is still used.

Therefore the easiest solution to clear the cache is to delete the files
on disk in 'git svn reset'. Normally, deleting the files behind the back
of the memoization module would be problematic, because the in-memory
representation would still exist and contain wrong data. Fortunately, the
memoization is active in memory only for a small portion of the code.
Invalidating the cache by deleting the files on disk if it isn't active
should be safe.
Signed-off-by: NPeter Baumann <waste.manager@gmx.de>
Signed-off-by: NSteven Walter <stevenrwalter@gmail.com>
Signed-off-by: NEric Wong <normalperson@yhbt.net>
      61b472ed
    • R
      git svn: handle errors and concurrent commits in dcommit · e48fb750
      由 Robert Luberda 提交于 
      dcommit didn't handle errors returned by SVN and coped very
poorly with concurrent commits that appear in SVN repository
while dcommit was running. In both cases it left git repository
in inconsistent state: index (which was reset with `git reset
--mixed' after a successful commit to SVN) no longer matched the
checkouted tree, when the following commit failed or needed to be
rebased. See http://bugs.debian.org/676904 for examples.

This patch fixes the issues by:
- introducing error handler for dcommit. The handler will try
  to rebase or reset working tree before returning error to the
  end user. dcommit_rebase function was extracted out of cmd_dcommit
  to ensure consistency between cmd_dcommit and the error handler.
- calling `git reset --mixed' only once after all patches are
  successfully committed to SVN. This ensures index is not touched
  for most of the time of dcommit run.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
      e48fb750
  7. 10 8月, 2012 1 次提交
  9. 09 8月, 2012 3 次提交
  11. 08 8月, 2012 3 次提交
  13. 07 8月, 2012 19 次提交
  15. 06 8月, 2012 1 次提交